Atari ST monochrome mode without internal modification

[c0pperdragon]

One of my customers has the use case that he only needs the Atari ST in monochrome mode. His specific machine (a Mega ST) seems to be very space constraint so he would not be able to add the pickup-board under the Shifter.
Ist there any reason why a purely external solution would not work? Just a cable to take hsyc, vsync, mono from the video port and feed it into a digital RGBtoHDMI (via a 16-pin connector). Looking at the schematic, it seems the mono signal is basically a TTL digital signal.

It would be great if such a solution could also be used with the Mono & Lumacode board, but merging hsync, vsync and mono into one signal is not really feasable, given that the circuitry would need to work without power supply (no power available either from the ST nor from the RGBtoHDMI in this configuration).

[IanSB]

@c0pperdragon

Just a cable to take hsyc, vsync, mono from the video port and feed it into a digital RGBtoHDMI

Yes that should work.

It would be great if such a solution could also be used with the Mono & Lumacode board

That should also work. You would have to change all the solder bridges to configure the Lumacode board to accept separate H and V syncs and video on three TRRS inputs:
Tip = Mono Video
Ring1 = Hsync
Ring2 = Vsync

This means cutting the track jumpers:
JP5 1-2
JP6 1-2
JP7
JP8

Then add solder bridges to:
JP5 2-3
JP6 2-3

This would also require a new profile.

[c0pperdragon]

I did some experiments with my signal generator (I don't have an ST) to create some form of 72Hz monochrome analog signal. It seems the 32MHz pixel clock is quite beyond what the RGBtoHDMI Mono & Lumacode can do.
So for the ST, the only option is still a digital RGBtoHDMI, even if only the monochrome mode is needed.
But I will try to offer the aforementioned cable for a non-mod option.

[IanSB]

@c0pperdragon

It seems the 32MHz pixel clock is quite beyond what the RGBtoHDMI Mono & Lumacode can do

What multiplier setting did you use?
The YUV firmware has a fixed x8 multiplier so it would not work with that as 32x8 = 256Mhz and the sample clock limit is about 180Mhz. The RGB firmware has an adjustable clock multiplier and setting to x4 would use a clock of 32x4 = 128Mhz which is within the limit. The comparators are rated up to around 100Mhz so should cope with a 32Mhz signal

You can use the existing mono sub-profile from the Atari ST profile as a starting point but will probably need to adjust the analog threshold levels.

Edit:
Also you would need to use 3bpp sampling or lower as higher bit depth reduces the maximum pixel clock rate and the YUV firmware is fixed at 6bpp.

[c0pperdragon]

Using the RGB firmware and setting sample depth to 1 bit totally worked! There is even quite some margin now for setting the sample phase. I guess a real Atari ST will not produce such a perfectly timed signal as my test device, but it will very likely be good enough.
So, to make a solution that fits into the family, I need to make an adapter plug that creates such a mono signal with embedded csync, exposed on an RCA socket. XOR-ing hsync,vsync is good enough, as shown by my demonstration. The real issue now is that the atari video connector provides no power. Maybe I can harvest just enough power from the csync output to drive the circuit.

[c0pperdragon]

I close this as my current solution for the Atari ST now uses the RGBtoHDMI with analog inputs (6 pin IDC connector) and this works without any active or passive components. Just wiring and plugs.