STFM to DVI/HDMI project

[Smonson]

A project that's been keeping me busy lately...

I've interfaced my 1040STFM to a Cyclone-II FPGA through the shifter socket in order to generate TMDS signalling. The result is a purely digital signal path from ST to DVI or HDMI monitor/TV. When finished this will support all colour and monochrome video mode and refresh rate combinations, with or without borders. As a bonus, the palette registers can be upgraded from 9 to 12 bits, like on the STE.

So far I have just one progress photo to share. This odd picture is my machine booted up without keyboard or FDD connected. It's in mono video mode, but TOS is drawing the low-res desktop size because my stripboard prototype only has a one-way bus connection, so the Atari can only write the shifter registers but not read them back, and it's confused about which res it's in.

[czietz]

Cool! Please keep posting updates.

[Smonson]

Here's a better pic.



The next bit of progress will probably be after I get proper boards made. Right now, there's so much electromagnetic noise on the data lines that my prototype (which is connected to the shifter socket through an 8cm long ribbon cable) keeps experiencing glitches. Analogue stuff is not my forte, so I haven't been able to keep the noise out.

[arf]

I've interfaced my 1040STFM to a Cyclone-II FPGA through the shifter socket in order to generate TMDS signalling. The result is a purely digital signal path from ST to DVI or HDMI monitor/TV.

Marvellous project! Very cool. I hope the excitement in the audience won’t lead to understandable requests of creeping featurism, which will make finishing the project even harder. Although, it would be cool if it also could ……

[MM41]

Very nice project !

[mikro]

Absolutely awesome to see an Atari HW project coming from Down under!

[bladeomega]

Nice work Smonson, and very good news for our Atari-Community. Keep it up!

[TheNameOfTheGame]

This project is very welcome indeed!

[ijor]

Cool indeed!

Mostly out of curiosity, can you share some technicals? Are you just scan doubling, adapting the clock to match the nominal HDMI frequency, or implementing a full frame buffer?

[Atari030]

Just when you think things can't get any better...... brilliant.

[Smonson]

Thanks for all the good vibes

Mostly out of curiosity, can you share some technicals?

Glad to. This is at heart a scan doubler, so there are two buffers for scanlines, which are alternately written to or read from, and there is a one-scanline delay introduced. The FPGA is running on a 32MHz clock like the original shifter, and all video modes will use the 32MHz pixel clock with a 10x PLL. The Atari clock is generated by the FPGA and I cycle-count the length of DE to get into synch. I'm generating a 640x400 image from that using the same timing as the Atari did. I've also tested 720x480 video mode which gives a 40-pixel border all around.

It won't work with an STE obviously, because there's no separate shifter.

It does work with VGA - but why would you?

It should be possible to automatically detect the presence of overscan by counting the LOAD pulses, to enable borders - in theory.

[ijor]

This is at heart a scan doubler ... The FPGA is running on a 32MHz clock like the original shifter, and all video modes will use the 32MHz pixel clock with a 10x PLL.

My question had to do with the frequency of the HDMI connection. Some people claim that some TVs/monitors are very picky and expect the exact HDMI specifications which requires very specific dot clocks. There is also some debate how much (un)common are US TVs that accept 50 Hz from the HDMI interface.

I cycle-count the length of DE to get into synch.

Interesting. So you don't read the sync signals coming from GLUE? You infer them from DE?

It should be possible to automatically detect the presence of overscan by counting the LOAD pulses, to enable borders - in theory.

That's one method. But you are already measuring DE, and the number of LOAD pulses depend directly on DE.

[Smonson]

My question had to do with the frequency of the HDMI connection. Some people claim that some TVs/monitors are very picky and expect the exact HDMI specifications which requires very specific dot clocks. There is also some debate how much (un)common are US TVs that accept 50 Hz from the HDMI interface.

There's no need to adapt the clock. The minimum pixel clock for HDMI is 25MHz, and 50Hz operation is guaranteed in the HDMI spec (not for DVI though).

Interesting. So you don't read the sync signals coming from GLUE? You infer them from DE?

I'm reading all the sync signals from the shifter socket. I only count the length of DE to confirm that it's in sync. If there's a discrepancy there, then the timing of the scanline buffers being swapped will be wrong.

That's one method. But you are already measuring DE, and the number of LOAD pulses depend directly on DE.

In normal video modes, the number of LOADs corresponds to the number of pixels on the scanline, so I've assumed that in overscan it means there must be more LOADs to be done. I'll let you know when I get up to that stage.

[ijor]

... and 50Hz operation is guaranteed in the HDMI spec (not for DVI though).

Are you sure? Where do you see that in the specs? In the specs I have (not the latest that are not public) I don't see that.

I do see some modes at 50Hz listed in the specs. But if I read the specs correctly, those modes are mandatory only as long as 50Hz is supported at all.

I'm reading all the sync signals from the shifter socket.

Not sure I understand what you mean, there are no actual sync signals (HSYNC and VSYNC) at shifter.

In normal video modes, the number of LOADs corresponds to the number of pixels on the scanline, so I've assumed that in overscan it means there must be more LOADs to be done.

That's correct. Just be aware that in the typical overscan modes the number of LOADs is not multiple of four. So there are more LOADs than the corresponding pixels.

[AdamK]

Great stuff. 2 questions:
1) What about border&other trick effects?
2) What about STE?

[Smonson]

Are you sure? Where do you see that in the specs? In the specs I have (not the latest that are not public) I don't see that.

I do see some modes at 50Hz listed in the specs. But if I read the specs correctly, those modes are mandatory only as long as 50Hz is supported at all.

...actually, that does sound familiar. Well, at least in Australia, LCD TVs always support both 50 and 60Hz so I hope it's the same elsewhere. It's gotta be easier than finding one of those MultiSync monitors.

I'm reading all the sync signals from the shifter socket.

Not sure I understand what you mean, there are no actual sync signals (HSYNC and VSYNC) at shifter.

Right, I don't mean video sync signals, just the control signals for the shifter, DE, LOAD, CS, and RW.

[Smonson]

Great stuff. 2 questions:
1) What about border&other trick effects?
2) What about STE?

With video mode 720x480 I can get 40 pixels per side to make room for overscan techniques... I don't actually know the full resolution of the frame with full border overscan techniques. It may be possible to go to a bigger resolution, especially in colour where the scanline is a maximum of 1024 pixels wide at 50Hz, 800 or 900 across could work.

It won't work for STE, sorry. There's no external shifter, so getting the video data becomes more difficult, you would have to solder quite a few wires into the main board.

[troed]

Of course the Shifter is a separate chip also on STE. On some revisions of the GST-MCU the Blitter has been included in that chip, but the Shifter is still separate.

[alexh]

Nice project. Good luck. I'll be following. James Boulton, co-author of the SainT emulator and creator of the Atari Lynx and Jaguar flash cards was doing a project like this. I think it is on hold but his project was discussed on this forum.

It won't work for STE, sorry. There's no external shifter, so getting the video data becomes more difficult, you would have to solder quite a few wires into the main board.

Of course the Shifter is a separate chip also on STE. On some revisions of the GST-MCU the Blitter has been included in that chip, but the Shifter is still separate.

On the GST-MCU revisions of the STe the shifter is inside a surface mount QFP (impossible to add an adaptor)

Earlier STe revisions have the Shifter as a PLCC chip some are in a socket others surface mount. You could make a board for these motherboards.

[troed]

On the GST-MCU revisions of the STe the shifter is inside a surface mount QFP (impossible to add an adaptor)

Earlier STe revisions have the Shifter as a PLCC chip some are in a socket others surface mount. You could make a board for these motherboards.

Well all STEs have a GST-MCU (MMU+Glue) - but later editions also have the Blitter in there.

"Original STE motherboard": https://www.qwant.com/?q=ste%20motherbo ... 1e3a3b646f

GST-MCU that includes the Blitter: https://www.qwant.com/?q=ste%20motherbo ... source=web

... but I don't think I've seen one where the Shifter is in another package, so then that was unknown to me. I agree not all are socketed like the examples above. edit: Oh, sorry, QFP _is_ the regular non-socketed surface mounted version. Yes, I think I've seen those. Not difficult to solder to

[Smonson]

I see. Well, I guess if they expose all the shifter's buses and control lines then they could work!

But first I have to make this one work reliably.

[Smonson]

Wow, I just found that thread by SainT - his project and mine are incredibly similar. I hope I don't fall into the same trap that stopped him from finishing it (I don't have kids so that's a start).

[beel1]

Your results look very promising, congratulations!
May I ask you what dev board you are using? Or maybe you made your own?

[Smonson]

Just a generic EP2C5 mini-board, they are great!

[beel1]

Indeed!
How did you hook up the HDMI connector?