Atari ST discussion

[c0pperdragon]

@IanSB

I am creating a new thread specific for Atari ST discussions.

I don't have a (nor ever had) and ST myself, so my experience is pretty limited. But I would guess that your auto-detecing solution could be the most general solution and allows a no-hassle access to both games and professional (music?) applications.

Documentation for the video hardware is a bit hard to find, but if the Shifter is indeed a 40pin DIP, a similar solution to my Amiga board should be possible. No idea of the clearance of course and of possible case variants.

Guessing from some pictures it seems that there is an optional RF modulator next to the metal can in which the shifter sits. Removing this RF modulator (when actually installed) gives plenty of space to put the RPi just in the right spot to make the HDMI output accessible from the outside. From an adapter board with the same height profile as for the C64 and Atari 8-bit (40-pin DIP socket with long solder tails), a short 40-pin ribbon cable could go the RPi, through a slit cut in the RF shielding. When the Shifter has an additional 5mm clearance before reaching the metal shield, this should work.

[IanSB]

Here are a couple of photos of the internals with the wire pickups for my tests: I picked up the signals from the connected resistors rather than soldering directly to the shifter but the H and V sync had to be picked up from the modulator input as they are not available on the shifter.

[IanSB]

I moved the screencaps here:

[c0pperdragon]

When you have to collect the signals from different locations, you can't do it with a simple adapter board. Then you could just as wells solder wires to the pins exactly as you are doing now.

For the necessary level shifting your CPLD is already perfect and I guess your already have your complete solution here ;-)

In case you want to avoid overclocking the RPi, I have a proposal (don't know if it is indeed possible with the CPLD):
Always transfer the data for 4 pixels (36 bit) with 3 12-bit transfers (I think that is the width of the data bus from the CPLD to the RPi). This reduces the sampling rate on the RPi from 16 MHz to 12 MHz. You will have to do some bit-shifting to straighten everything out, but it may speed up things just enough.

I am not sure which clock you need to send to the CPLD so it can do all this, but 48Mhz is the lowest frequency from which both 12Mhz and 16Mhz can be derived. Maybe you need 96Mhz anyway for your sampling to work, so at least this calculcation would work out.

[IanSB]

Always transfer the data for 4 pixels (36 bit) with 3 12-bit transfers

I'd already considered something similar for 8 bit capture, sending three 8 bit samples in two 12 bit transfers. These options wouldn't fit in the current CPLD which is nearly 100% full so it would require a dedicated CPLD for such capture but that is no problem due to the in system programming. The other option as you mentioned previously is a completely external solution using three A to D converters (which might even work with the Amiga using 4 bit A to Ds). This would also require a DAC to set the reference voltage for the converters so that the levels can be adjusted to sit between the computer output levels assuming everything was linear enough. Not sure if a standard TV chip could be used for that.

[c0pperdragon]

The true power of the TV sampling chip I mentioned earlier was its ability to lock to the hsync and generate a pixel clock for a configurable pixel count. Your CPLD in conjunction with the RPi already can do exactly that.

With a 8-bit ADC you can later do quite arbitrary quantizations in a digital form. Maybe the CPLD could do that to generate the 8 levels for the Atari ST signals.

For an earlier attempt at an upscaler (with analog inputs), I used this 3-channel ADC: https://www.mouser.at/ProductDetail/238-WM8214SCDS-V It is quite versatile and the digital signal path is multiplexed, so you only need 8 data lines. You can also easily clamp the signals to the black levels to avoid calibration effort. Maybe with a chip like this, you could design a new Analog Board that fits the 8-bit CPLD board but can produce 3x8 bits of data.

[c0pperdragon]

As it turns out this 3-channel ADC is not fast enough for 16Mhz sampling when using all channels.

But I have another idea, stillt: It is actually possible to create an ADC circuit by cascading comparators. For a 3-bit ADC you need 3 comparators (and some resistors) on a low-impedance signal input. Given the current signal interfaces of your latest 6/8 - bit CPLD board, you could design an analog board that would decode 8 different levels on each channel and directly create a 3-bit output for each. This approach is in contrast to a "nomal" DAC that needs a clock input to trigger sampling. I am not sure about the speed of the comparators you are curently using, but maybe they are fast enough to be used at 16 MHz when being cascaded.

All the constraints already imposed by your existing CPLD board and the RPi seem to leave just enough possibilities to support an external Atari ST solution with a specially made analog board. To support both color and mono mode, you need an additional singal input besides the R,G,B,Sync your current analog board has. Keeping a 6-pin configuration, you could re-purpose the VCC pin because the Atari ST does not provide power on the video port, anyway.

Building a DIN-13 adapter cable should not be that difficult (https://www.mouser.at/ProductDetail/CUI-Devices/SD-130?qs=%2Fha2pyFaduidFLkmXIRw9ksFAcwpAAyypzNKe8zYp94%3D). To keep access to the audio signal, you probably need to break it out to an analog phone jack.

[c0pperdragon]

For the analog input stage, I would actually propose a THS7316 video amplifier. This can provide low-impedence signals and automatically adjusts the black levels to a very well defined base voltage. With preceeding trimmer pots on the analog signals you can prepare the levels so they will be correctly detected by the ADC stage.

[c0pperdragon]

After some more thinking and browsing the interwebs on the topic of the Atari ST, it seems to me that the majority of people who have an affection for this machine and would welcome an upscaler of this sort, would not been able to do any serious soldering. A finished transcoder box is probably just what they need. This speaks for the external solution...

[c0pperdragon]

For an enhanced version of the analog board, something like this ADC could be used: It is reasonably cheap and can sample at 20MHz:

https://www.mouser.at/ProductDetail/Texas-Instruments/ADC1175CIMTCX-NOPB?qs=sGAEpiMZZMtgJDuTUz7Xux12P9e9sDTcNIMowTz99lM%3D

[c0pperdragon]

There are requests to pull off the same stunt as for the Amiga now for the Atari ST.
Using only the bare minimum of additional circuitry to bring the necessary pixel data to the Pi.

I guess it could be done fairly easily as long as the screen mode is limited to color only. This may already work with the current RGBtoHDMI software without modification. The circuitry needs to generate basically the exact same signals as the Amiga adapter, but with an 8 MHz pixel clock. As far as I know this can be achieved by overclocking the Pi.

[c0pperdragon]

If I am not mistaken, the default display mode (when no cable is connected to the A/V port) is already color. So such a straight-forward solution will produce HDMI output in color mode. When you connect a monochrome monito to the A/V port, the HDMI output will probably not work any longer or at least not correctly.

[c0pperdragon]

By the way: I have designed a simpler Amiga adapter board that can be put on the Pi Zero and has individual wire points to receive RGB, CSYNC and pixel clock: https://github.com/hoglet67/RGBtoHDMI/tree/master/kicad_AmigaAdapter/Small I guess this could already work with the Atari ST without modification.

[bwmott]

I've built one of c0pperdragon's simple Amiga adapter boards originally developed for the Amiga 600 and wired it up to an Atari Mega ST:

I've connected SYNC to the ST's CSYNC at resistor R116 right before it goes to the monitor port and I've connected CLK to the 8MHz pin on the expansion bus. I'm getting a display (using Beta14); however, there's some significant corruption:

I'm new to using RGBtoHDMI (except for some basic testing on an Amiga 2000 before trying it on the ST), so there are likely settings that I need to adjust. I also need to see if the ST's CSYNC signal is what the adapter board is expecting. I'll post a follow up, if I make any progress. If you have suggestions for things to try, please let me know.

[c0pperdragon]

There are multiple things you can try:
1. For the 8 MHz clock you probably need to overclock the Pi a bit in order to keep up. You can do that with the on-screen menu (probably need a recent firmware beta version from https://github.com/IanSB/RGBtoHDMI/releases/) or by directly modifying the content of the SDcard. 2. Another problem are possibly the long wires, as they can pick up all kind of noise and cause delays and signal distortion on their own. Especially the clock signal is always very sensitive. 3. Third thing is the relationship of the clock edges with the signal edges of the color lines. To judge this, you really would need to do some more measurements with an oscilloscope.

[IanSB]

@bwmott

There is an Atari St profile already in the Beta14 software for the CPLD version.

Go to \Profiles\6-12_BIT_RGB\Atari_ST on the SD card and copy the "Atari_ST.txt" to this folder: \Profiles\Simple (There is also a mono profile but that will only work with the CPLD version)

Reboot the Pi then select the Atari ST profile from the Profiles line on the main menu. This will set up everything for the Atari ST including some overclocking of the Pi You may also need to go into the Sampling menu and change the Sync Edge setting to eliminate any glitches.

[IanSB]

@bwmott

I just remembered that Atari profile is set up for separate H & V syncs and it looks like you are picking up composite sync for c0pperdragon's board so after selecting the profile you will have to go into the Geometry menu and change the Sync setting from H&V to "Composite" for standard negative going composite sync or "Inverted" for positive going composite sync.

Use the Save config option once you have made all the changes you require.

[bwmott]

Thanks for the suggestions. I copied the Atari ST profile as suggested; however, it looks like it is designed for PAL so I made a few adjustments to work better on my NTSC system. Now, I get a stable display in low resolution sometimes:

However, it isn't consistent and sometimes the display will be corrupt:

It looks like this is an issue with the Atari ST, since power cycling the PI doesn't change things, but cycling the ST eventually results in a stable image. Maybe this has something to do with the timing between the CPU and Shifter (e.g., wakeup states https://www.atari-forum.com/viewtopic.php?f=68&t=9056). I'll try looking at things with my oscilloscope to see if I can spot any differences later this week.

I've had no luck getting a stable image when using the ST's medium resolution (640x200). I've also tried using shorter wires as suggested, which didn't appear to change things. To rule out any issues with the motherboard's CSYNC, I tried combining the HSYNC and VSYNC signals using an XNOR gate; however, that didn't change things either.

[IanSB]

@bwmott

Maybe this has something to do with the timing between the CPU and Shifter (e.g., wakeup states

Yes I had noticed something like that with my STFM and the CPLD version where the phase relationship between the sync pulse and the pixel clock would vary by 180 degrees at different times. Fortunately it is easy to vary the sampling phase on the CPLD version from the menus and I found that using a 90 degree sampling phase seemed to work under all conditions although changing that is not easy with c0pperdragon's discrete design.

However your photos are showing a greater amount of jitter than just the one pixel's worth I would expect from that. It might be worth increasing the overclocking values in the settings menu: Set Core to 160 and maybe CPU to 60 to see if that helps. If you get just 1 pixel of jitter after that then the above is the likely explanation.

You can go higher still but depending on your Pi it might start to freeze so you might need a heatsink on it.

I haven't really done any further investigation with the ST beyond my initial proof of concept above but I have recently designed a plug in buffered shifter pickup for the external CPLD board so I will be doing some more testing when that arrives:

Can you post your modified Atari ST profile (Will be in /Saved Profiles on the SD card) Also can you post a photo of the source summary page in the info menu when in both 'good' and 'bad' modes.

[c0pperdragon]

Yes, my adapter relies on a clock signal that has its edges somewhere between the points where the color signals change. In the Amiga this was fairly easy as this provides a 7.x MHz CPU clock and a second signal that is phase shifted by 90 degrees. I have no Atari ST, so I can do no measurements and it is hard to guess how you can most conveniently create such a suitable clock signal from the things actually present in the machine.

[IanSB]

@bwmott

I just released an updated beta16 which has more efficient capture code so can you try that to see if it helps: https://github.com/IanSB/RGBtoHDMI/releases

Copy your custom Atari profile into the appropriate folder after updating the SD card.

[bwmott]

Thanks for the suggestions. I gave beta16 a try; however, I'm getting similar results. Low resolution sometimes works but medium resolution never appears to work. When low resolution does work, it continues to work after power cycling the Pi or soft reseting the ST. Here's the slightly modified profile I'm using for my 60Hz Atari ST:

sampling=0,0,0,0,0,0,0,0,1,0,5,0,0,0,2,0,0,3,0,0,100,256,100,256,100,256,0,256 geometry=176,31,640,202,720,270,1,2,0,2,16000000,1024,7500,262,4,0,0 palette=RrGgBb_(EGA) scanline_level=0 vsync_indicator=1 overclock_core=100

The main changes I made were the 31 offset and 262 lines per frame. I've noticed if the RGBtoHDMI auto profile select feature is enabled (sub-profiles) then the Pi flickers ever second or so. Given this I suspect some additional changes are needed to the profile for 60Hz mode on the Atari ST. Here's the Source Summary for when the screen looks correct in low resolution and when it is corrupt in low resolution:

Except for the small difference in the clock error, everything else looks the same.

[IanSB]

@bwmott

The main changes I made were the 31 offset and 262 lines per frame. I've noticed if the RGBtoHDMI auto profile select feature is enabled (sub-profiles) then the Pi flickers ever second or so. Given this I suspect some additional changes are needed to the profile for 60Hz mode on the Atari ST

Yes you need to set number of lines to 263 as that is what is being detected on the above screen Also you need to adjust the line length to get the PPM error close to 0. That will likely be around 1016 (both in geometry) After those two changes your NTSC profile should be detected automatically Also change the pixel aspect to 2 : 5 for better NTSC Aspect ratio

It does look like the pixel clock phase is randomly different by 180 degrees which is something I noticed on my STFM Have you tried adjusting the sync edge setting in the sampling menu?

[c0pperdragon]

As far as I have understood parts of the schematic, the Atari uses a 32Mhz clock as base to derive all other clocks from, including the CPU clock as well as the clocks for the Shifter. It now looks very much like the 8Mhz CPU clock comes up in some random phase relationship to the clock used by the Shifter. In a bad case, this causes the color signals to change at pretty much the same point when the CPU clock also changes. This causes the flip-flops on the adapter to fetch inconsistent data and there is nothing that can be done about this on the side of the Raspberry Pi.

You could solve the problem by adding a delay of about 30ns to the clock signal before feeding it into the adapter. You could use a simple 74HC04 inverter IC and feed the signal through an even number of gates. With an oscilloscope it should be fairly easy to get close to 30ns (20ns - 40ns should be good enough). Without an oscilloscope, just start with 4 gates which is probably somewhere in the correct range.

[bwmott]

Thanks for the suggestions to improve the video output. I've adjusted the profile as recommended:

sampling=0,0,0,0,0,0,0,0,1,0,5,0,0,0,2,0,0,3,0,0,100,256,100,256,100,256,0,256 geometry=176,31,640,202,720,270,2,5,0,2,16000000,1015,7500,263,4,0,0 palette=RrGgBb_(EGA) scanline_level=0 vsync_indicator=1 overclock_core=100

It looks like 1015 provides the smallest PPM error. The low resolution output is looking great in the "good" case:

However, after power cycling I'm still getting corruption in the display at times. It does seem like this is due to the random phase relationship. I wonder if this might also result in CSYNC being sampled at the wrong time. I didn't have a 74HC04 handy, so I connected a 74LS86 up with each output (O1, O2, O3, O4) feeding into the next XOR gate (acting as not gates). The 8MHz CPU clock was the input to the first gate. In the "good" case, I could use the CPU CLK, O2, or O4 as inputs to the Pi and have a stable display. in the "bad" case only 01 and O3 could be used to get a stable display. I'll experiment with additional delays to see what else I find.

[IanSB]

@bwmott

If you don't have any luck getting the simple board working would you like to try the CPLD version? If so I could send you a set of blank pcbs for the cost of postage as I'd be interested to see if it worked on the Mega ST. I've got my new Shifter pickup board working so the external version is almost completely plug in, only Vsync and Hsync have to be picked up with wires as they aren't on the shifter. Here's the new board:

(I've also designed a similar pickup board for the Amiga)

Here's some output: The CPLD version also supports hires mono mode which the simple board can't:

This is with NTSC aspect ratio conversion enabled: You could actually mount the Pi internally but externally it can also be used on other computers like PCs, Amiga (with above adapter board) etc.

BTW could you recommend any good graphics games or demos. Also any test software that outputs RGB test patterns etc which would make it easier to check that all bits are connected properly

[c0pperdragon]

@bwmott

I am not sure if I made myself clear. It is the clock line from the Atari to the small adapter board that needs the delay. From the adapter to the Pi no adjustments are needed. But maybe you already did that and I just got confused by your description.

[bwmott]

IanSB, I’d love to give the CPLD version a try. Getting blanks pcbs would be great or if the gerber files are available, I can get some made. As far as software to try on the Atari ST, one thing to explore is how demos that produce overscan on the Atari ST work with RGBtoHDMI. These demos achieve increased screen resolution by switching resolutions at certain times during the frame to bypass normal operations. The first link below lists demos that used these techniques and the second link has a collection of Atari ST demos that might be useful:

https://aldabase.com/atari-st-fullscreen-demos-history/ http://www.atarimania.com/top-atari-demo-atari-st-_D_S_D.html

Another thing to try out would be Spectrum 512, which allowed displaying images with more than 16 colors per scanline on the Atari ST:

https://doudoroff.com/atari/spectrum.html

c0pperdragon, my description wasn’t clear, sorry about that. I connected the delay between the clock from the Atari ST to the small adapter board (not directly to the Pi). I have some 74HC04s on hand now, so I”m going to give that a try as well as see if I can figure out which signals are different between getting a stable and unstable screen using an oscilloscope. Unfortunately, work is crazy busy right now, so it might be a week or so before I dig into it some more.

[IanSB]

@bwmott

IanSB, I’d love to give the CPLD version a try. Getting blanks pcbs would be great or if the gerber files are available

You will need at least the issue 4 12 bit main CPLD board (gerber link on page): https://github.com/hoglet67/RGBtoHDMI/wiki/Bill-of-Materials-%2812-Bit-Board%29

As a minimal solution for initial experimentation you could connect that directly to the shifter as you have done with c0pperdragons board as it has all 12 RGB bits, H & V sync, +5v and ground available on the pads for the P2 and P5 connectors (Clock signal not required as the CPLD regenerates it)

However to make a nearly completely plug in version as shown in my photos above you will need two additional PCBs: First is the 12 bit extender board (gerber link on page): https://github.com/hoglet67/RGBtoHDMI/wiki/Bill-of-Materials-%2812-Bit-Extender%29 This plugs into the CPLD board underneath and brings all the above signals from P2 and P5 on to a single 16 way connector which is outside the recommended case so you can easily swap cables for different sources. (The 16 way connector wouldn't fit on the CPLD board so the signals had to be split)

Finally you need a shifter pickup board which fits between the shifter IC and socket to pick up the 12 bits of RGB data and power. Unfortunately H and V sync aren't present on the shifiter so you have to pick them up on separate wires which feed back into the board so they can be added to the 16 way header.

There are two implementations of that (gerbers in zips): An unbuffered board: https://github.com/IanSB/RGBtoHDMI/blob/dev/Kicad_Atari_ST_12Bit_UnBuffered_Pickup/V1/ A buffered board with two TSSOP buffer ICs https://github.com/IanSB/RGBtoHDMI/blob/dev/Kicad_Atari_ST_12Bit_Buffered_Pickup/V1/

The buffered board is preferable if you are going to use a long cable but does require soldering two TSSOP 74HC245 packages Note both of these boards should be 0.8mm or 1.0mm thick rather than the standard 1.6mm because they use turned pin sockets that are mounted through the board so they need to be as thin as possible to allow the pins of the socket to plug into the Atari board. (If the pins are too short for the Atari socket, plug the pins into a second turned pin socket underneath)

I don't know how quickly you can get boards made but I'm in the UK so postage will take some time if you want me to send them. Let me know which way you want to do this.

[bwmott]

@IanSB Thanks for all the links and details. I've placed an order for all 3 PCBs (buffered pickup board), so now I just need to get the components ordered. Looking forward to getting it built!

[IanSB]

@bwmott

There isn't a BOM for the Atari pickup board yet as I haven't documented it but it's as follows: U1 - 40 way Turned Pin socket (Note the PCB holes are larger than normal and this is fitted through the board) U2 - 74HC245 TSSOP U3 - 74HC245 TSSOP

C1 & C2 100nF 0603

J1 - 2 pin right angle 0.1" pitch pin header Pin 1 = Hsync in, Pin 2 = Vsync in from suitable pickup points You will need a matching cable connector or just solder the two wires directly to the board J2 - 16 pin (2x8) 0.1" pitch right angle pin header

You will also need some 16 way ribbon cable and two 16 way IDC connectors

As mentioned, a second 40 way turned pin socket might be needed to sit between the above board and the Atari as the pins through the board might not be long enough for a secure connection to the shifter socket.

I also used a switch connected to the mono sense input on the Atari video connector to select bootup in mono or colour mode

[bwmott]

@IanSB Thanks for the list of parts for the Atari pickup! I've ordered all of the components and they should arrive in the next week or so.

[stevenptimms]

Hi @IanSB is there any chance you'd let me test out your cpld board? If you have some pcb spare. I have a range of Ataris I'd like to test it with. I still don't have the PiRGB yet, but I am in a waiting list from over on stardot. I'm in the UK. Cheers. edit: I'm Steve on page 6 of the forum requests :)

[bfollowell]

Seeing that this supports all three native ST resolutions, I am very interested in this project. I'm curious about two things.

My first question concerns high resolution. I know on the original ST, there was a pin that had to be grounded I believe in order to initiate booting into high resolution. How is this done with this mod/board?

My second question concerns sound. Is sound somehow passed to the RPi so that it can be encoded into the HDMI stream, so that audio and video can both be handled by one HDMI cable and not having to mess with external speakers etc.?

Thanks.

[IanSB]

@stevenptimms

is there any chance you'd let me test out your cpld board

Yes, I do have a few pcbs so could add one to your PiRGB order. I will be sending out some boards soon.

[IanSB]

@bfollowell

booting into high resolution. How is this done with this mod/board?

You fit a switch to the AV connector to ground the mono detect pin to select bootup in mono mode.

Is sound somehow passed to the RPi so that it can be encoded into the HDMI stream

No, sound isn't supported at the moment and it may be very difficult to add as there aren't enough spare GPIOs or CPU time to process the sound signal. HDMI monitors/TVs that have built in speakers usually have a 3.5mm analog audio jack that can be used to override the HDMI audio input so this isn't usually a problem and you pick up the audio from the normal AV connector. If you really need audio on the HDMI signal for use with a HDMI switcher etc. then that can be added using a HDMI audio embedder / inserter.

[stevenptimms]

@IanSB Cheers Ian :) I'll watch out for a pm on stardot

[bfollowell]

Yeah, I don't see extra audio inputs on HDMI sources, at least in the U.S. I have 7 TVs, all from Samsung and LG, all made within the past ten years, and not a single one of them has an extra audio input on an HDMI source. I really wish they did.

On Tue, Feb 16, 2021 at 7:22 AM IanSB notifications@github.com wrote:

@bfollowell https://github.com/bfollowell

booting into high resolution. How is this done with this mod/board?

You fit a switch to the AV connector to ground the mono detect pin to select bootup in mono mode.

Is sound somehow passed to the RPi so that it can be encoded into the HDMI stream

No sound isn't supported at the moment and it may be very difficult to add as there aren't enough spare GPIOs or CPU time to process the sound signal. HDMI monitors/TVs that have built in speakers usually have a 3.5mm analog audio jack that can be used to override the HDMI audio input so this isn't usually a problem and you pick up the audio from the normal AV connector. If you really need audio on the HDMI signal for use with a HDMI switcher etc. then that can be added using a HDMI audio embedder / inserter.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/c0pperdragon/Amiga-Digital-Video/issues/6#issuecomment-779833068, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOUCGLW5XMITOF4ZJ7VTJ3S7JWQDANCNFSM4Q57XM3A .

[bwmott]

@IanSB

I finally received all of the PCBs as well as the components to build the boards. Overall the board assembly went well:

However, after trying to fit everything into my Atari Mega ST, I noticed the right angle 16 pin header on the Atari ST Shifter pickup board was rather close to the system's oscillator. I could still connect the ribbon cable to it; however, it was a rather tight fit.

Since the Atari Mega ST has plenty of space above the board, I decided to go with a vertical 16 pin header instead of the right angle header:

Here's a view of the installed board and you can see where I'm picking up the HSYNC and VSYNC signals near the GLUE chip in the background (there's also a cable connected to CSYNC; however, that's not being used).

Here's the assembled unit with the Atari Mega ST screen showing on the TV in the background:

I'm looking forward to playing around with it to see how well it works with various software titles. Initial testing looks good in both low and medium resolution. Haven't tried high resolution yet.

[AdamKlob]

Could You test 2 demoscene productions: https://demozoo.org/productions/154344/ https://demozoo.org/productions/151600/ They do overscan tricks, and 50/60Hz changes in frame.

[AdamKlob]

Oh, and: "SHUT UP AND TAKE MY MONEY!" :P

[bwmott]

@AdamKlob I believe those demos are for Atari STe machines, so I can't test them on my Mega ST. However, I have tested other demos that use overscan tricks and they appear to be working without issues. Here's a screenshot from the Darwin's Dilemma demo as well as from viewing an MPP format image (http://github.com/zerkman/mpp) that uses lots of palette switches per scan line:

I believe both of these use overscan tricks. The only thing I've noticed that seems a little odd is that the "sync" LED on the RGBtoHDMI's 12-bit board starts blinking when using these and if I turn on the RGBtoHDMI's V Sync Indicator option, I see several lines drawn at different vertical locations down the screen. Not sure if it's related to the overscan tricks being used or something I haven't configured properly.

[AdamKlob]

@bwmott grea. I'll try to get some STFM titles for You to test. Any chances for STE version?

[AdamKlob]

@bwmott, good demo to test might be Alien's 4 bit sync scroll in PYM.

[tomtebloss]

@bwmott try Closure by Sync

[IanSB]

@bwmott Glad to see you got it working OK.

the "sync" LED on the RGBtoHDMI's 12-bit board starts blinking when using these

That means the frame or line timing doesn't match either the 50Hz or 60Hz standard profiles. Custom profiles can be created for any demos that change the output timing like that and they will be auto selected when such timing is detected. If you post the system summary page for any demo that has a flashing genlock led I should be able to create an initial profile to test with them although it will likely require you to do some final tweaking. You can screencap menu pages by pressing up and down buttons at the same time.

[bwmott]

@IanSB

After looking at it some more, I think it has to do with my TV not dealing with 50Hz very well. I had forced the TV to use 60Hz in the RGBtoHDMI settings to get around an oddly stretched display when programs switched to 50Hz. I noticed that I could switch back to EDID (50Hz / 60Hz), if I also adjusted the RGBtoHDMI's output to something like 1360x768 instead of using the Auto resolution mode (Auto defaults to 1080p). With these setting changes, the LED doesn't blink; however, the TV does display a warning message for a few seconds when the 50Hz switch first occurs.

I ran some additional tests with some of the demos mentioned by @tomtebloss and @AdamKlob. Alien's 4 bit sync scroll in PYM appears to work without issues. Closure by Sync has some corruption in the first few scanlines when graphics are displayed there. In the following screenshots this shows up as odd color pixels at the top. I checked to see if this corruption was visible when using my Framemeister to view the ST's output and it wasn't.

I also tried out the SNDH v4.4 update demo which has a full screen display. Initially, I noticed some of the left and right side of the screen was being cropped, so I increased the Max H Width in the RGBtoHDMI's Geometry settings. I increased it to 768, which allows most of the visible screen to be displayed:

If I continue to increase the Max H Width to try and get the remaining overscan pixels on the left and right (there are still a few pixels in some of the later screens in the demo that aren't visible using 768), I start to get small sampling errors on some scanlines. In the following screenshot you can see a few pixels in the letters which are shifted left by a pixel here and there:

It looks like the ST can display up to 413 horizontal pixels in low resolution using overscan tricks (http://ae.dhs.nu/hatari_overscan/), so I was trying to increase the Max H Width to something closer to 800, but I couldn't get an image without the sampling errors beyond a width of 768.

@AdamKlob Since the STE machines have a different shifter IC in them the shifter pickup board that @IanSB designed for the STs will not work with it. The STE shifter uses an 84-pin quad package, so it would be more challenging to design a pickup board for it, but it might be possible. Looking at the STE's schematics, it appears that the 12-bits of RGB data go through a resistor network to create the analog RGB signals, so in the worst case the RGB data could be tapped from the resistors (similar to what I was doing back in my post on Jan 23 where I connected to resistors on my Mega ST to serve as input to c0pperdragon's board).

[stevenptimms]

@IanSB sorry I know you haven't been well, but just checking if I'm still on your list on stardot. I was on page 6/Steve.

[RetroBitsAndBytes]

Will anybody be selling these boards (populated ie. ready to install)...?

[IanSB]

@stevenptimms

Yes I got about half way through page 5

[IanSB]

@bwmott

In the following screenshot you can see a few pixels in the letters which are shifted left by a pixel here and there

Some things to try which might help with that: Increase the core overclock value a little and save before exiting the menus. (Too high a value might cause lockups) Increase the multiplier to x10 (anything higher will probably not work reliably) and then tweak the sampling phase again. You will likely have to set the sampling phase manually to a compromise value due to the random clock phase relationship discussed above.