Project: HDMI/DVI out for STFM
Posted: Fri Nov 10, 2017 12:53 pm
We welcome retro users & hardware gurus alike! Come and join the party :)
https://www.exxosforum.co.uk/forum/
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.Hope to see this card for STE !!
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.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
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.
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.Smonson wrote: ↑Fri Nov 24, 2017 9:40 amI 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)
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.troed wrote: ↑Fri Nov 24, 2017 10:36 am 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.
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.
It should be a constant, yeah... I hope it is!