Atari ST discussion

[c0pperdragon]

Atari ST discussion

[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 ***@***.***> 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 <#6 (comment)>, 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.

[IanSB]

@RetroBitsAndBytes

I will be eventually.

[methanoid]

@RetroBitsAndBytes

I will be eventually.

For STE (pretty please) ??

[ijor]

Hi,

Great work! A couple of comments and recommendations:

It is not absolutely necessary to connect the HSYNC and VSYNC signals. It is possible to infer syncing from DE. This might, perhaps, fail in a couple of cases that alter syncing in the middle of the frame (not sure how the converter would handle that anyway). But implementing autosync would allow a solderless plug in into the Shifter socket.

OTOH, if you want a perfect implementation, connecting the sync signals is not enough. You have to connect BLANK as well because some demos assert BLANK in the middle of the frame intentionally.

[aotta]

@ianb:
hi Ian, I tested the wiring with a 1024 STE, it works but not all colours are right.... i soldered R3,B3, and G3 to corresponding Shifter output, while in kicad adapter's schema they are all connected to "mono"... is that what i've to do?

[IanSB]

@aotta

I tested the wiring with a 1024 STE, it works but not all colours are right

The STE is 12bpp. The earlier Atari ST machines were 9bpp so on those Ataris I connected the unused R3, G3, B3 inputs to mono so that the converter could auto switch between mono and colour modes.
However on the STE you should connect R3, G3, B3 to the corresponding R3, G3, B3 outputs on the STE and then change the sampling mode from 9bpp to 12bpp in the sampling menu. The converter will not be able to auto switch to mono mode on the STE.

[aotta]

@aotta

I tested the wiring with a 1024 STE, it works but not all colours are right

The STE is 12bpp. The earlier Atari ST machines were 9bpp so on those Ataris I connected the unused R3, G3, B3 inputs to mono so that the converter could auto switch between mono and colour modes.
However on the STE you should connect R3, G3, B3 to the corresponding R3, G3, B3 outputs on the STE and then change the sampling mode from 9bpp to 12bpp in the sampling menu. The converter will not be able to auto switch to mono mode on the STE.

Thank you @IanSB ! with 12bpp sampling i get colour closer to RGB output, but still some difference... it seems to me that 16 way connector in 12 bit externder V2 is different from the one in Atari adapter schematics... is it right?

And, bigger issue, RGBtoHDMI switch to the Mono subprofile, but only black screen. STE needs a different profile?

[IanSB]

@aotta

it seems to me that 16 way connector in 12 bit externder V2 is different from the one in Atari adapter schematics... is it right?

The Atari adapter matches the V2 12 bit extender but the V1 12 bit extender has a slightly different pinout on the 16 way for pins 2, 3 & 4 (I think you had some V1 boards made before I posted the V2)

On V1 12 bit extender
Pin2 = B0
Pin3 = G1
Pin4 = R0

On V2 12 bit extender
Pin2 = R0
Pin3 = B0
Pin4 = G1

And, bigger issue, RGBtoHDMI switch to the Mono subprofile, but only black screen. STE needs a different profile?

Mono mode won't work with the STE unless you make up a separate cable because there are no spare inputs to connect the mono signal.
You could make up a separate cable for mono mode that plugs into the Atari video connector as the sync and mono signals are TTL levels (connect mono to G3).

[aotta]

@IanSB thanks Ian, you was right (as always), my adapter is an issue 1! i used it in the STFM and didn't notice the wrong colours..
I'll try to swap the pin 2-4, and adding a switch to mono->G3 and mono-detect->GND, and i'll report if it will work fine.

[aotta]

I can confirm that a switch for Mono/G3 works fine, with autoswitching subprofile too!

[methanoid]

Thanks @aotta for confirming it works... Are you recording somewhere what you did exactly and what connections to where.. doesnt look like same board I see for Amiga (obviously) so no idea where to source the board!

[aotta]

@methanoid , i didn't record the single steps, but i simply solder separately each wire of the 16 IDC cable following the STE schematic:

the 12 bits color to R0-3,G-3,B0-3, Vsync and Hsync to the two resistor near L404 and L405 (i can't remember the resistors' code, but in my STE they wasn't the R435 and R437 showed in schematic), and +5V and GND in the opposite sides of C412:

for the "Mono" output, as reported above, i added a switch to select connection to R416 or R430 and G3 wire (and shorting pin 1 and 14 in the video connector for forcing STE to Hires).
That's all, but i'll try to help you if you need more info.

[lopezpb]

I have assembled RGBtoHDMI set for Atari ST but unfortunately there is a problem after starting the computer, it displays the message "no sync detected" and the image flashes (automatically selects the profile for Amstrad_CPC), only restart rpi0 or a few restarts helps, after that it selects the Atari ST profile. IMHO Vsync and Hsync are correctly connected to the pin 4 and 5 RF modulator.

I recorded video with the problem:
https://www.youtube.com/watch?v=wk3WJtIX_Uk

Everything works fine, when I copy the Atari_ST profile to the / Profiles / 6-12_BIT_RGB_Analog folder and after start, select it.

https://youtu.be/MgbGX0Sxb2E

Additionally I did tests:

• on my second 520STFM it's exactly the same,
• on the second RGBtoHDMI, no change,
• I also checked older FW versions, no changes.

Vsync and Hsync signal is on 12 Bit Board, do you have any advice, what else can you check?

Although everything seems to work fine as an analog, either there is a software bug or I am doing something wrong.

ps. I'm sorry for my english.

[IanSB]

@lopezpb

The problem is that your board is falsely detecting that an analog board is fitted and switching to the analog profile set.

Detection of the analog board is made by looking at the P19 (DETECT) line on pin 1 of P5. This is pulled low by one of the 4.7K resistors in the SIL resistor network RN3 and the analog board when fitted pulls this high using a 1K resistor thus indicating that an analog board is connected.

For some reason that line P19 is reading high so there may be a short connected to that line.

You need to check around pin 1 of P5 and also pin 19 of the CPLD as it may be shorted to pin 18 or 20

Try connecting a voltmeter or oscilloscope to P19 to see what level it is at (It should be 0V)

Also you need to change the picture size setting on your TV as it is zooming in by 5% and cropping part of the menu.

[lopezpb]

I have checked, there are no short between pins 18/19/20 on CLDP.

On P19 is 8MHz signal

[IanSB]

@lopezpb

On P19 is 8MHz signal

That's definitely wrong and looks like the PSYNC signal which is on pin 22 of the CPLD (last pin on that row of pins) so check for a short between pin 19 and pin 22.

Check that resistor network RN3 is fitted the right way, the pin 1 "dot" on the package should be close to SW3

Also look at the signal on the "DAT" pin of P5 with your oscilloscope as that line can affect the state of P19

EDIT: also check any of the other unused pins on P5 (M7, Mux, DAT, CLK, STB) for the 8 Mhz signal

[lopezpb]

That's definitely wrong and looks like the PSYNC signal which is on pin 22 of the CPLD (last pin on that row of pins) so check for a short between pin 19 and pin 22.

Signal on pin 19 and 22 are the same but there are no short

Check that resistor network RN3 is fitted the right way, the pin 1 "dot" on the package should be close to SW3

It's ok I've checked it

Also look at the signal on the "DAT" pin of P5 with your oscilloscope as that line can affect the state of P19

No, signal on DAT is quite different

EDIT: also check any of the other unused pins on P5 (M7, Mux, DAT, CLK, STB) for the 8 Mhz signal

I've checked all board and 8MHz signal is on pin 19/22 CLDP, GPIO17_psync, P19 and 6 pin of resistor network.

[aotta]

@lopezpb are you sure you got good hsync & vsync? Did you checked them with scope? In some motherboard without modulator (like mine) you have to get them elsewhere

[lopezpb]

@aotta Yes, it's the same signal as on GLUE chip (Hsync pin 37 and Vsync pin 38)

[IanSB]

@lopezpb

Actually thinking about it, the 8Mhz can appear on P19 under certain circumstances so that might be OK

One other way for the board to be incorrectly identified is for one of the 12 bits going from the CPLD to the Pi Zero to not be connected: (These 12 bits normally send the video data to the Pi but also send the version number of the CPLD and the top bit indicates analog or digital interface.

Check that the following two pins are connected:
Pin 1 of the CPLD to Pin 33 of the Pi zero

Also you mention above that you tried on two RGBtoHDMI boards but do you have two Pi zeros as well? If not, try another Pi zero as a faulty Pi zero was the problem with another issue recently with one GPIO bit stuck at 0v

EDIT:
Also check that pin 1 of RN3 is connected to ground

[lopezpb]

I checked with another Rpi0 - no changes. I put together the third RGBtoHDMI set and it behaves exactly the same.
I have traced all the connections according to the diagram:
https://raw.githack.com/hoglet67/RGBtoHDMI/dev/Kicad_6Bit/v4/rgb-to-hdmi.pdf
and everything looks fine.

Also check that pin 1 of RN3 is connected to ground

Yes it is.

I have no ideas what else to check, maybe purchased CLDP are damaged in some way? but they program without problems and it is unlikely that three different chips are damaged in the same way, although they are from the same supplier.

[lopezpb]

I think I found my mistake, I have resistor network 4606X-102-472LF instead 4606X-101-472LF.

[IanSB]

@lopezpb

I think I found my mistake, I have resistor network 4606X-102-472LF instead 4606X-101-472LF

Yes that would cause the problem as the P19 detect line wouldn't be pulled low, instead it would be connected to the B0 line.

EDIT: B0, not DAT

[IanSB]

@lopezpb

To test this you can remove the resistor pack and put a single 4.7K resistor between pins 1 and 6 of RN3 (any value from 1K up to about 47 K should work for a temporary test). The other pins of RN3 on R0,G0,B0,G1 don't really need the pull downs as they are connected to valid signals anyway for the Atari ST (Same for RN1 & RN2).

[lopezpb]

I used 5 x 4.7K resistors, now everything works fine. I ordered 4606X-101-472LF but I have to wait 6 weeks for them.

Thank you IanSB for your help!.

[lopezpb]

Back to the Atari STE version, I think it could be make like in a board for the Xtraram extensions with pins plugged into the SGT Shifter, from what I can see all the necessary signals are in one row.

Xtra-ram pcb:

GST Shifter

[lopezpb]

Since I had a few requests to show how it looks in action, below is a video with a demo run and mono mode on RGBtoHDMI with full screen scaling.

Atari 520ST 2MB, CT'ide + RGBtoHDMI

https://youtu.be/feqQMbEpsVg

[bfollowell]

It looks really good. It’s a beautiful, crystal clear image. Personally though, I despise stretched screens. Is there anyway to maintain the original aspect ratio, or is that taken care of in the display settings? Thanks for the video.

On Mon, Jun 7, 2021 at 3:25 AM lopezpb ***@***.***> wrote: Since I had a few requests to show how it looks in action, below is a video with a demo run and mono mode on RGBtoHDMI with full screen scaling. Atari 520ST 2MB, CT'ide + RGBtoHDMI https://youtu.be/feqQMbEpsVg — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOUCGL4ZE43RYDV3CM3V7LTRR7ADANCNFSM4Q57XM3A> .

-- Sent from Gmail Mobile

[lopezpb]

Of course you can set different screen aspect ratio settings such as e.a. 4:3. I will try to get a video with different settings, although I don't know if the mobile phone will catch diferences with soft and softer.

"A number of options are available:
Auto
Integer / Sharp
Integer / Soft
Integer / Softer
Interpolate 4:3 / Soft
Interpolate 4:3 / Softer
Interpolate Full / Soft
Interpolate Full / Softer"

[bfollowell]

No need to post another video, unless you just want to. I appreciate it though. It just seems that most of the videos and images I've seen show a stretched desktop, so I'd started to wonder if the aspect ratio was locked at 16:9. Thanks for the video and the information.

…

On Mon, Jun 7, 2021 at 5:10 AM lopezpb ***@***.***> wrote: Of course you can set different screen aspect ratio settings such as e.a. 4:3. I will try to get a video with different settings, although I don't know if the mobile phone will catch diferences with soft and softer. "A number of options are available: Auto Integer / Sharp Integer / Soft Integer / Softer Interpolate 4:3 / Soft Interpolate 4:3 / Softer Interpolate Full / Soft Interpolate Full / Softer" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOUCGKTN6EPFFVSDN5FE7DTRSLKRANCNFSM4Q57XM3A> .

[pixelk0]

Just made my 5 RGB2HDMI and order the PCBs for 5 12bit extenders and 5 ST buffered board (I only need 2, but minimum batch sizes and orders...).
Is there a reason for the discrepancy in the Capacitor footprints between the main board ( 0805 100nF ) and buffer board ( 0603 100nF ) as I had to order two batches to satisfy the different part sizes ?
The Atari ST boards and connections lack a Wiki page and I had to dig a bit to gather the informations. I'm not complaining and am very glad that such a solution exists and is available (by the way, thank you for your incredible work !), I just want to offer to help to create the "missing" wiki page if you think it's a valid idea.
By the way, would those long pins (initially for wire-wrapping) be adequate for the buffer board ? https://www.ebay.com/itm/180598510456
--EDIT on 2021-06-23 --
Just realized as I've got an STE, the buffer boards will be useless to me :/
I also found this more clear diagram of the output circuitry here : https://info-coach.fr/atari/hardware/video.php

[IanSB]

@pixelk0
Sorry I haven't added any wiki info for the ST yet. As you noted the buffer board is for the ST and you will have to manually solder the cable from the 16 way 12 bit extender board to the RxGxBx lines coming from the video chip on the STE. It's probably easier to solder to the video chip side of the resistors in the DAC.

The pinout of the 16 way connector can be found in the cables section of the wiki:
https://github.com/hoglet67/RGBtoHDMI/wiki/Cables

If you use a 2 pole changeover switch you can solder one pole to switch either G3 or MONO from the video chip to be connected to G3 on the RGBtoHDMI and the other pole can be used to ground the auto detect mono input when the MONO signal is connected to RGBtoHDMI so that mono hires works as well.

[pixelk0]

Thank you. I couldn't wait and soldered directly my ribbon (a snip from a SCSI 50 ribbon) from the source resistors to the pin on the 12bit board issue 4, where I soldered the pull-up resistors on the top to get more space underneath.
I initially inverted H-Sync and V-Sync which resulted in no sync at all of course.

I didn't solder the monochrome pin as I have no real use for the high res mode yet and I can display it directly in VGA.
I soldered my power pins (+5V and GND) on C413

My V & H-Sync

--- EDIT ---

After correcting the sync swap, I have a clearer image, but not fully. The picture is constantly wobbly.

20210625222536.MP4

I'll read the rest of the wiki to see if I find how I can try to tweak it. but so far it's better than any analog output I ever got. Thank you !

--- EDIT 2 ---

The wobble stopped in low res without any conscious action but a reboot. It persists in mid res.
And for further reference, on my 520 STE Mainboard, my soldering points :

--- EDIT 3 ---

After a successfull auto calibration, the screen wobble is gone, in low and medium res. GREAT SUCCESS. I tried Spectrum 512, and Photochrome with a TGA picture and it displays flawlessly.

--- EDIT 4 ---

More and more people (in Atari-Forum ) want to buy the surplus boards from me, how can I pay back to this project ? I don't want to profit from your work.

[IanSB]

@pixelk0

More and more people (in Atari-Forum ) want to buy the surplus boards from me, how can I pay back to this project ? I don't want to profit from your work.

Maybe I'll set up a donation page or something.

The main reason I haven't documented the Atari connection yet is that I want to investigate an alternative way of connecting the sync signals. It has been suggested that I use the DE signal as a substitute sync source instead which would make the basic ST upgrade entirely plugin and leave the vsync input free to be optionally connected to the blank input which is currently ignored. I undestand that some demos assert the blank signal during active video and that would have no effect at the moment.

Also the sampling phase (in the sampling menu) will have to be set to a compromise value manually rather than running an auto calibrate because of the problem with the sync signals randomly shifting 180 degrees with respect to the pixels on power up.

BTW on you STE the crystal is 32.084998Mhz which means a pixel clock of 16.042499Mhz. My ST uses a 32Mhz crystal / 16Mhz pixel clock. Is that normal for all STEs and is there a reason for the difference?

EDIT: The DE / blank suggestion was made by @ijor above in this thread

EDIT2: It looks like the Closure by Sync demo posted above by @bwmott shows the problem of ignoring the BLANK signal as there a a few lines of garbage at the top of the screen.

[pixelk0]

Just redid a capture and the Pixel Clock is now captured at 16042513 Hz from RGB2HDMI source page
PAL French 520STe

According to the STe schematics, it is the good value for U402 :

I captured Closure (before correcting the colour bits, but that should only affect... colours.

With RGB2HDMI https://youtu.be/H2aNV49jq9s
And a SCART2HDMI https://youtu.be/OiSwB3mTZGs

[IanSB]

@pixelk0

I captured Closure (before correcting the colour bits, but that should only affect... colours.

Looking at the STE schematic, the 84 pin shifter chip has a BLANK input so it is doing the blanking internally in the chip and should work correctly.

On my ST the 40 pin shifter chip doesn't have a BLANK input and blanking is done by an external analog circuit after the DAC so RGBtoHDMI needs the BLANK signal only on systems with the 40 pin shifter. If you look at your version of Closure and compare to @bwmott 's screencap above, your version shows black at the top and his shows garbage (running on a 40 pin shifter).
See:
#6 (comment)

As it's only required for the 40 pin chip I could implement that functionality on the pickup board by using the buffer chips to force the 12 bits to zero when blanking is active. The alternative would be to implement blanking in the CPLD and feed the blank signal in on the VSYNC input but that would mean using composite sync or maybe the DE signal on the HSYNC input. Composite sync isn't available on the ST so will have to be made by ORing the two signals together.

I'm not sure if there is enough space in the CPLD to implement blanking but I will try that first.

I haven't investigated the use of the DE signal suggested by @ijor yet.

[IanSB]

@pixelk0

I've fixed the blanking problem with a CPLD and software update plus a small mod to the pickup board:
Before the fix:

After the fix:

As this only affects the 9 bit per pixel RGB output on the 40 pin shifter I used one of the unused bits (B3) on the 12 bit input so no changes were needed to the existing H and V sync inputs. (G3 is used for the mono input and R3 is still unused).
The mod requires the track going between B3 and G3 to be cut on the pickup board and then a wire soldered from B3 (Pin 15 of header) to the !BLANK signal.

[IanSB]

@bwmott
@lopezpb

I have updated the software and CPLD to fix the blanking problem on the Atari ST (see above screencaps):
Download the latest beta (currently beta35):
https://github.com/IanSB/RGBtoHDMI/releases
(Wipe the SD card and install the new files).
You must update the RGB CPLD to the latest version (v94)

You must also make the following modification (output will be not be visible until the mod is made):
On the underside of the 40 pin shifter pickup board cut the track going to pin 15 of the header (B3):

Solder a wire from Pin 15 to the BLANK signal from Glue pin 36
This signal is also on three diodes near the shifter (see ST schematic)

[IanSB]

@aotta
@pixelk0
I have changed the way that the STE is connected so that the mono signal doesn't need to be switched and it now works in a similar way to the ST.
Please download beta 35 as above:
https://github.com/IanSB/RGBtoHDMI/releases
(Wipe the SD card and install the new files).
You must update the RGB CPLD to the latest version (v94)

You must also make the following changes to the STE connection:
Connect composite sync to the HSYNC input of RGBtoHDMI (Wire 12)
Composite sync should be available on U211C pin 6 (74LS04) also on U403 (MC1377) Pin 2 (See STE Schematic)
Connect MONO to the VSYNC input of RGBtoHDMI (Wire 14)

After these changes, the mono video will automatically be selected when the mono sense input is grounded on the STE video connector just like the ST. You can test this by inserting a low value resistor or wire link between pins 4 and 13 of the video socket.

I have also updated the cables page with the new ST and STE connections:
https://github.com/hoglet67/RGBtoHDMI/wiki/Cables

Can you test that this works OK as I don't have an STE

[aotta]

@IanSB: new wiring and sw for STE works, but i got some dirty lines with monochrome's setting:

I don't know if it's a poor cabling from mine, or some setting to tune better... any hints?

[IanSB]

@aotta

How long is your ribbon cable?

It might be crosstalk on the cabling or noise in the composite sync but try the following:

Connect the composite sync pickup point to the inverted composite sync signal which is on pin 5 of U211C (same 74LS04). This signal is also on Pin 3 of U209 (74LS86)

You will have to change the Sync setting in the Geometry menu from "composite" to "inverted" (Twice, for both the normal sub-profile and the mono sub-profile)

[aotta]

Ian, no difference with inverted comp from pin 5... the strange thing it's that it starts fine, and garbage appears after a minute and stays

[aotta]

... and auto calibrate, sometimes finishes with a blank screen.
With previous cabling and software, i had no issue at all

[aotta]

@IanSB i think the issue is in the auto calibrate routines... if i manually set sampling to phase=1 and pixel h offset to 7, i get a clear screen with no garbage!

[IanSB]

@aotta

i think the issue is in the auto calibrate routines... if i manually set sampling to phase=1 and pixel h offset to 7, i get a clear screen with no garbage!

OK thanks it looks like there is a bug in the sampling phase code as you can set the phase from 0-5 in x4 mode and it should only set from 0-3.
I'll fix that and upload a new beta to try soon

[aotta]

@IanSB thank you, in the meanwhile, it works fine with the setting manually changed, even with sampling phase 0!
Waiting for beta 36!

[IanSB]

@aotta

Beta 36 is uploaded, I hope this one is OK!

NOTE: You MUST reprogram your CPLD if you used Beta 35

[aotta]

@IanSB you made your homework well! ;) now auto calibrating works flawless, thank you!

[aotta]

now i can switch "on the fly" from mono to colour ouput only changing setting with my homemade tool! ;)

[IanSB]

@aotta

now auto calibrating works flawless

Thanks for testing, this will now be the official way to connect the STE.

now i can switch "on the fly" from mono to colour ouput only changing setting with my homemade tool! ;

I'll have to make one of those (just orderd an ST video plug). I'm currently poking a wire into the video socket on my STFM!

Perhaps you could look at Apple IIGS when possible as there may still be some issues:
Current discussion here:
hoglet67/RGBtoHDMI#209

BTW is your IIGS NTSC or PAL?

[aotta]

Thanks @IanSB , i missed the discussion here, but i had in list the IIgs testing since red about it on stardot's forum. But the STE was under my bed, the IIgs is on top of the wardrobe, and i'll have to find the ladder! ;)
And, i'm not sure if mine is PAL or NTSC, since i remember had to mod the psu from 110v to 220v, but i use a scart adapter with my tv and it works fine.... i'll check it and will report the progress