Project: HDMI/DVI out for STFM

[exxos]

[IngoQ]

Wow, this really looks great, congrats

[rpineau]

Very nice !
Rodolphe

[francouai]

Hope to see this card for STE !!

[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... ?