Project: HDMI/DVI out for STFM

[exxos]

[IngoQ]

Wow, this really looks great, congrats

[rpineau]

Very nice !
Rodolphe

[Smonson]

Hope to see this card for STE !!

It's only possible to do this when he ST has a separate, external shifter. The STE shifter is integrated into a great big chip that handles lots of other things as well, so although it seems possible to do the same thing in principle (replace the entire chip by an FPGA), I don't have what I would need to attempt it, such as an STE for starters.

Sorry about that!

[exxos]

The question is.. can you run troed's Closure demo


http://www.pouet.net/prod.php?which=66787

[Smonson]

The question is.. can you run troed's Closure demo

http://www.pouet.net/prod.php?which=66787

If it uses overscan, it will probably display the leftmost 320 pixels of each line and the topmost 200 lines. But it's possible for everything the real shifter can do to be supported properly, as long as the frame rate is one of the standard ~50Hz, ~60Hz, or 72.1Hz ones... I'll give this a try eventually but assuming it's 50Hz it'll have to wait until next time I set everything up in front of the TV... probably on the weekend.

I'm on the lookout for a small cheap TV, but for now I'm just using an LCD monitor, so limited to 60 or 71.2Hz modes.

[Smonson]

The question is.. can you run troed's Closure demo

I got around to testing this, and another demo that uses overscan, and I discovered something interesting, and annoying. My FPGA lost sync with the incoming video data, which means it couldn't track the correct number of CPU cycles between DEs.

I think that means the total cycle count for each frame is not one of the standard ones* (50Hz, 60Hz, 71.2Hz). I'm not sure what the exact count is, but I obviously need to do a lot of research into what is actually going on in the machine before this can be displayed. I know that the line frequency is toggled in order to skip over the part of the pixel or scanline count where the MMU would normally decide when to stop sending data. But I didn't realise that the actual length of the scanlines (or the number of scanlines in the frame) would change!

It could mean that each programmer, doing their own overscan implementation in a slightly different way, could come up with a different video mode from every other programmer. I hope not, because right now my implementation is based around the three normal video mode timings: 896x501, 1016x262, and 1024x313, and it's a fair bit of work to change it.

At the end of the day, it should still be possible to support everything that the Atari can throw, by storing all the measured video timings in registers and then basing the output video format on that. But it means a lot more work will be involved.

It might not be possible to support a video mode where each video frame is a different length, or if some scanlines are longer or shorter than others. The perils of going from analogue to digital.

(* Another possibility is that there are scanlines generated all the way through the VBL, so there's no way to tell where the frame begins)

[troed]

The question is.. can you run troed's Closure demo

I got around to testing this, and another demo that uses overscan, and I discovered something interesting, and annoying. My FPGA lost sync with the incoming video data, which means it couldn't track the correct number of CPU cycles between DEs.

I think that means the total cycle count for each frame is not one of the standard ones* (50Hz, 60Hz, 71.2Hz). I'm not sure what the exact count is, but I obviously need to do a lot of research into what is actually going on in the machine before this can be displayed. I know that the line frequency is toggled in order to skip over the part of the pixel or scanline count where the MMU would normally decide when to stop sending data. But I didn't realise that the actual length of the scanlines (or the number of scanlines in the frame) would change!

It could mean that each programmer, doing their own overscan implementation in a slightly different way, could come up with a different video mode from every other programmer. I hope not, because right now my implementation is based around the three normal video mode timings: 896x501, 1016x262, and 1024x313, and it's a fair bit of work to change it.

At the end of the day, it should still be possible to support everything that the Atari can throw, by storing all the measured video timings in registers and then basing the output video format on that. But it means a lot more work will be involved.

It might not be possible to support a video mode where each video frame is a different length, or if some scanlines are longer or shorter than others. The perils of going from analogue to digital.

(* Another possibility is that there are scanlines generated all the way through the VBL, so there's no way to tell where the frame begins)

You're correct in that there are many demos that do some scanlines of irregular length (508 cycles - "60Hz", vs 512 cycles - "50Hz") etc, but I don't think {Closure} is one of those. I took great care when making it to be "sync clean". I do manipulate when the MMU sends data (number of pixels per line) of course, but if you're triggering on cycles and not DE then I would think it should work. All frames should be 160256 cycles long.

Please feel free to ask any number of questions you might have regarding overscan/sync scroll tricks. I'm very interested myself in getting HDMI out on my main STE so I'll be happy to lend any aid I can.

/Troed

[exxos]

The time between Vsync pulses should be constant though ? As troed said, 160256 cycles, so I assume Vsync, then 160256 cycles, then Vsync ?

Though I think Vsync pulses half way though the last scan line... ?

[Smonson]

You're correct in that there are many demos that do some scanlines of irregular length (508 cycles - "60Hz", vs 512 cycles - "50Hz") etc, but I don't think {Closure} is one of those. I took great care when making it to be "sync clean". I do manipulate when the MMU sends data (number of pixels per line) of course, but if you're triggering on cycles and not DE then I would think it should work. All frames should be 160256 cycles long.

Thanks for responding Troed! I don't know much about the ramifications of the overscan techniques in practice. Only the theory that I have read, mainly in Alien's write-up.

Because the shifter doesn't see vsync and hsync, I don't use them at all. But so far it hasn't been necessary because the leading edge of DE is all you need in order to know when a scanline has begun, and therefore if you know how long each line is, you can add hsync near the end. Same principle for vsync: I detect the first scanline in the frame by a DE-to-DE delay of longer than 2048 32MHz clock cycles.

I'll have to get it under the oscilloscope and see if DE not taking a break is the problem here. If that's not it, I'll write a verilog program to indicate what the frame length actually is. From what you've said, it sounds like that's going to be the most likely cause of the problem though, and the solution may be to find a new way to detect which is the first scanline in a frame.

I'm very interested myself in getting HDMI out on my main STE so I'll be happy to lend any aid I can.

I don't have an STE, but it looks like the shifter is inside a much bigger 84-pin ASIC. Fortunately there's tons of room in the Cyclone-II so reimplementing the whole thing should be possible, so it could become a similar project. I've only used about 1,500 LEs out of 4,600 available, to get this far. And since this is literally the first time I've ever used an FPGA, I assume my verilog code is very inefficiently using the LEs.

The time between Vsync pulses should be constant though ? As troed said, 160256 cycles, so I assume Vsync, then 160256 cycles, then Vsync ?

Though I think Vsync pulses half way though the last scan line... ?

It should be a constant, yeah... I hope it is!

Vsync will be taking place during some of those cycles near the end. I think it goes for 2 scanlines, but I could be remembering wrong... HDMI hardly cares about the hsync and vsync signals, on my TV I think they can even be emitted during active video and it still works fine. With HDMI it also receives another 2 sync signals which are asserted when displayable pixels are being emitted, which is a lot more useful than hsync and vsync.

It's just past midnight here, unfortunately I won't have time to confirm anything until tomorrow at least.