Page 5 of 24

Re: Project: HDMI/DVI out for STFM

Posted: Fri Nov 10, 2017 12:53 pm
by exxos
:cheer: :cheer: :cheer: :cheer:

Re: Project: HDMI/DVI out for STFM

Posted: Fri Nov 10, 2017 2:12 pm
by IngoQ
Wow, this really looks great, congrats :)

:yay: :bravo:

Re: Project: HDMI/DVI out for STFM

Posted: Fri Nov 10, 2017 4:03 pm
by rpineau
Very nice !
Rodolphe

Re: Project: HDMI/DVI out for STFM

Posted: Fri Nov 10, 2017 7:20 pm
by francouai
:o
Hope to see this card for STE !!

Re: Project: HDMI/DVI out for STFM

Posted: Fri Nov 10, 2017 10:08 pm
by Smonson
francouai wrote:
Fri Nov 10, 2017 7:20 pm
:o
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!

Re: Project: HDMI/DVI out for STFM

Posted: Sun Nov 12, 2017 11:33 am
by exxos
The question is.. can you run troed's Closure demo ;)


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

Re: Project: HDMI/DVI out for STFM

Posted: Mon Nov 13, 2017 10:10 am
by Smonson
exxos wrote:
Sun Nov 12, 2017 11:33 am
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.

Re: Project: HDMI/DVI out for STFM

Posted: Fri Nov 24, 2017 9:40 am
by Smonson
exxos wrote:
Sun Nov 12, 2017 11:33 am
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)

Re: Project: HDMI/DVI out for STFM

Posted: Fri Nov 24, 2017 10:36 am
by troed
Smonson wrote:
Fri Nov 24, 2017 9:40 am
exxos wrote:
Sun Nov 12, 2017 11:33 am
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

Re: Project: HDMI/DVI out for STFM

Posted: Fri Nov 24, 2017 11:46 am
by 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... ?