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.
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.
troed wrote: ↑Fri Nov 24, 2017 10:36 am
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.
exxos wrote: ↑Fri Nov 24, 2017 11:46 am
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.