exxos's Atari, Amiga & retro forum

alexh wrote: 22 Feb 2024 08:26 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 :D 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

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 :P

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 :D
(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.

LarryL wrote: 22 Feb 2024 09:56

alexh wrote: 22 Feb 2024 08:26 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 :D

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. ;)

DoG wrote: 22 Feb 2024 11:15 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.

alexh wrote: 22 Feb 2024 11:25

DoG wrote: 22 Feb 2024 11:15 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) 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 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...

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/

alexh wrote: 22 Feb 2024 11:49 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 Means, we can spare the ST-Pickup-Board, used for RGB2HDMI

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 :)

alexh wrote: 22 Feb 2024 12:38
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" :lol:

alexh wrote: 22 Feb 2024 12:38 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...