LarryL’s blog - creating an ATX version of the Phoenix H5

[LarryL]

Thanks for posting. This looks very exciting. I am watching with interest.

I don't know if it is practical but if you can route digital Red Green Blue + Hsync + Vsync +5v +gnd to a header (approx 16 pins) you could easily add HDMI output to the ATX back-plate (which would look like a gfx card) using a SiPeed Tang Nano 9k which are about $10

The logical design for an equivalent of an RGB2HDMI using a Tang Nano 9k has already been written. As well as outputting over HDMI it can also output via MIPI camera connector.

Why would you want that?

It can connect to a PiStorm for automatic switching between Native gfx and VDI gfx card.

exactly - already inside

VGA_Header.png (12.07 KiB) Viewed 2390 times

The pinout matches e.g. this
The RGB signals are coming from the Falcon DAC, being part of the H5 design
I have also added a separate pin-header, having HSYNC/VSYNC/BLANK

[Mikerochip]

Hi!

I built the Angel_X micro ATX ST mobo, and something I found I dearly missed, once I had it built, was the ST High video signals.
(Missed as in, missing from the design ethos, not missing entirely. It works fine from the DIN13)

So, I bodged in the two missing signals to the RGB 2x8 riser, and I can only suggest you do the same.

One for Mono out, one for mono enable.

Having a "VGA" riser that can't actually use the ST native VGA signal is a bit of a pain

If nothing else, it will let you make a switch to enable ST high, without having to use the 13 pin DIN.
(Which would have been quite an easy addition, I think)

People might ask why have this, when you're probably going to make use of other video cards...
Because! It's like not having the cartridge port. It's not really a 100% compatible ST without it
(Or, that's my opinion, anyhow...)

If you're adding in the RJ11 connector for Mega/TT/MSTE Keyboard, why not add the 7 pin riser for the standard ST/Falcon keyboard too?
No reason other than to give the end user more options/flexibility!
It's really nice to be able to test a PS/2, ST, TT keyboard all from the one machine.

If you're adding an Eiffel, and the PIC, I have two suggestions: One, use the new firmware from the Polish atari forum, which solves the right mouse button/fire problem that was never addressed in the existing (final) firmware, and two, have an enable jumper, for the PIC 5v line?

It's nice to have the Eiffel, but, if you do want to switch/test another keyboard, you can't once the Eiffel PIC is actually installed.

[DoG]

I don't know if it is practical but if you can route digital Red Green Blue + Hsync + Vsync +5v +gnd to a header (approx 16 pins) you could easily add HDMI output to the ATX back-plate (which would look like a gfx card) using a SiPeed Tang Nano 9k which are about $10

exactly - already inside

The RGB signals are coming from the Falcon DAC, being part of the H5 design
I have also added a separate pin-header, having HSYNC/VSYNC/BLANK

I think he's after the 9 pins from the shifter directly (pin 21-29). Before the Falcon DAC. Blanking signal would probably be nice too.

[alexh]

I think he's after the 9 pins from the shifter directly (pin 21-29). Before the Falcon DAC. Blanking signal would probably be nice too.

Yes the signals before the DAC. No point going to Analog and back again.

[LarryL]

I think he's after the 9 pins from the shifter directly (pin 21-29). Before the Falcon DAC. Blanking signal would probably be nice too.

Yes the signals before the DAC. No point going to Analog and back again.

Ah, OK.

Well, this is how it looks in a standard ST (used a 1040STFM schematic)

Shifter_STFM.png (689.1 KiB) Viewed 2382 times

You are looking for the three combined signals of R0-2/G0-2/B0-2, right?

But: in the H5, these signals are not combined, but go directly to the DAC

Shifter_H5.png (54.77 KiB) Viewed 2382 times

So I would need to add the combining resistors again and route the three signals (together with HSYNC/VSYNC/BLANK) to a common point - ideally a separate 2x8p header, right?

Need to check, if this would fit...

[alexh]

It should be the signals that feed into the DAC.

Traditionally Video DAC inputs are :

• 24-bits or 16-bits for colour (Red 5-bits, Green 6-bits, Blue 5-bits) - On the ST there will probably only be 9-bits driven (512 colours)
• pixel (dot) clock (might not be necessary)
• hsync
• vsync

You can see the shifter adapters for the Raspberry Pi Zero implementation of RGB2HDMI

https://blog.jokielowie.com/en/2022/06/ ... y-pi-zero/

[LarryL]

It should be the signals that feed into the DAC.

Traditionally Video DAC inputs are :

• 24-bits or 16-bits for colour (Red 5-bits, Green 6-bits, Blue 5-bits) - On the ST there will probably only be 9-bits driven (512 colours)
• pixel (dot) clock (might not be necessary)
• hsync
• vsync

You can see the shifter adapters for the Raspberry Pi Zero implementation of RGB2HDMI

https://blog.jokielowie.com/en/2022/06/ ... y-pi-zero/

got it, so basically this

RGB2HDMI_ST.png (239.91 KiB) Viewed 2366 times

Means, we can spare the ST-Pickup-Board, used for RGB2HDMI

[alexh]

Yes that's it.

Making the connector match the existing RGB2HDMI pickup board connector pinout is a good idea.

If there was room for the buffer... even better

[LarryL]

If there was room for the buffer... even better

we have a saying in Germany: "if you give someone your little finger, your hand will be gone soon"

[LarryL]

Yes that's it.

Making the connector match the existing RGB2HDMI pickup board connector pinout is a good idea.

If there was room for the buffer... even better

it is a tight fit, but it works...

RGB2HDMI_Pickup.png (191.1 KiB) Viewed 2339 times

RGB2HDMI_Pickup_PCB.png (72.08 KiB) Viewed 2339 times