tricky wrote: ↑
Mon Jul 09, 2018 5:29 pm
I am hoping that it can be squeezed in to the PI (after h-sync and before the end of h-total) so that the CPLD doesn't have to know. I think you said (but I can't find it now) that the h-sync is passed through to the PI.
The idea (without knowing what you are doing!) is to have the frame buffer wider than what is displayed (probably already the case) and to start filling it at an offset calculated from the centre of the h-sync.
If the h-sync changes width, but the offset also changes giving the same centre, the widths could be used as binary (wide=1, narrow=0) to transfer 32 (maybe up to 39) bytes per frame. The timing would be too tight to do much, but could be used to set a NuLA style palette before starting a game, trigger a re-calibration or set whatever else might be accessible through the menu you were describing.
I'm not sure that's going to work, for the following reason:
The CPLD passes data to the Pi in units of 4-pixels (a quad). The Pi then collects two quads (8 pixels), packs these into a 32-bit word, and writes this to the frame buffer. You can see the inner loop that does all that here:
https://github.com/hoglet67/RGBtoHDMI/b ... _fb.S#L236
It's hard to see how you could change this code to introduce an N pixel offset, where N could be 0, 1, 2, 3, 4, etc calculated from the width of hsync. It would certainly be much more complicated.
It's conceptually easier to push this down to the CPLD.
The current CPLD uses 66 out of 72 macro cells, so there is a small amount of free space.
I've just tried adding the logic that I outlined earlier, and it seems to still fit. My only concern is there is no guarantee that that offsets introduced are whole pixels wide, so this may well mess up the sampling points.
I'll try this out tomorrow.
Is there any kind of a test program I can use that will vary the sync width?