As you did unveiled some new ways of thinking (the "magic-7" skipping technic), you can always keep doing it forward, but have to choose a better magic-number, now to be used as an interleaving-step, both in order to foolish the, Clouseau-alike, self-refresh mechanism, from following you closelly (sic), on your ankles, and also to ensure there no gaps would remain into the buffer's addressing scheme.
Sure, both paces (self-refresh-counter increment rate, and screen-refresh-dictated accesses scheduling) could, eventually, hit another synchronization bad-spot, as there are many possible display resolutions (and corresponding Sysclk adjusts), thus the possibility of address-decrementing schemmes to prevail, but, mathematically thinking advices: even them there would be chances to hit some collisions, due to all involved uncertainnities.
With variable-latency-enabled devices there rests the chance of trying to use some "pll-alike technic", by flagging any Hyper acccesses that, effectivelly, calls for 2x latency counts, while doing, simultaneouslly, some "tweaking" at the interveining Hyper_CS-high-time, in order to hit another sweet spot, where they would never get called, at all.
IIRC, it was jmg that did first suggested enlarging the chip un-select time, to give HyperRams enough time to do self-refreshs in between any mandatory accesses, but, further thinking suggests that, if some pll-alike scheme was not used, it'll not ensure some clashes wouldn't happen again.
Those are no news, if you think about any eventual design inconsistenies Hypers could still hide inside. Self-refresh pace is only the most visible one; just remember: stacked-dice devices can't even agree among themselves, to the point they aren't able to give any support to variable latency to be used.
Sometimes, technology opens new sets of concentric pitfalls, like assembled Matryoshka dolls; only the most prominent is visible, from an outside perspective. One should take a deep breath, before sinking his brain into all the possibilities...
There's something else I noticed that was strange with xcont…
I had to split the visible xcont into two in order to synchronize with HyperFlash driver like this:
xcont m_rf1,#0 'visible line
cogatn #(1<<HyperRam_Cog) 'load next line at start of h
xcont m_rf2,#0 'visible line
The S field was originally "#1". But, that didn't work. Seems it has to be "#0".
But, there doesn't seem to be any documentation on what the S field does here...
Here's the 720p @24 Hz, 16bpp on my 55" LG OLED TV.
The TV also supplies the USB power
I notice that same artifact on left edge and bottom row as with the 1080p version above... Seems there's something a hair off with the driver...
But, doesn't work at all on my Samsung 65" "Frame" tv...
I've got WVGA (800x480) working with my computer monitor with clock set to 297 MHz.
Monitor reports 57 Hz refresh. That should work on most monitors.
Also fixed the bug that caused those artifacts on left edge and bottom.
Not really sure what was wrong, but rewrote driver from Chip's example and this time it worked...
Comments
Sure, both paces (self-refresh-counter increment rate, and screen-refresh-dictated accesses scheduling) could, eventually, hit another synchronization bad-spot, as there are many possible display resolutions (and corresponding Sysclk adjusts), thus the possibility of address-decrementing schemmes to prevail, but, mathematically thinking advices: even them there would be chances to hit some collisions, due to all involved uncertainnities.
With variable-latency-enabled devices there rests the chance of trying to use some "pll-alike technic", by flagging any Hyper acccesses that, effectivelly, calls for 2x latency counts, while doing, simultaneouslly, some "tweaking" at the interveining Hyper_CS-high-time, in order to hit another sweet spot, where they would never get called, at all.
IIRC, it was jmg that did first suggested enlarging the chip un-select time, to give HyperRams enough time to do self-refreshs in between any mandatory accesses, but, further thinking suggests that, if some pll-alike scheme was not used, it'll not ensure some clashes wouldn't happen again.
Those are no news, if you think about any eventual design inconsistenies Hypers could still hide inside. Self-refresh pace is only the most visible one; just remember: stacked-dice devices can't even agree among themselves, to the point they aren't able to give any support to variable latency to be used.
Sometimes, technology opens new sets of concentric pitfalls, like assembled Matryoshka dolls; only the most prominent is visible, from an outside perspective. One should take a deep breath, before sinking his brain into all the possibilities...
I had to split the visible xcont into two in order to synchronize with HyperFlash driver like this:
xcont m_rf1,#0 'visible line cogatn #(1<<HyperRam_Cog) 'load next line at start of h xcont m_rf2,#0 'visible lineThe S field was originally "#1". But, that didn't work. Seems it has to be "#0".
But, there doesn't seem to be any documentation on what the S field does here...
It looks perfectly fine too, no flicker (Not sure how that is, but it is...)
There is something extraneous along the left border and on the bottom border as well, but not horrible.
The TV also supplies the USB power
I notice that same artifact on left edge and bottom row as with the 1080p version above... Seems there's something a hair off with the driver...
But, doesn't work at all on my Samsung 65" "Frame" tv...
Maybe it's not the driver but just a not completely supported mode?
Works with both FastSpin and new PropTool.
the 720p mode should work on most HDTVs.
The 1080p mode probably only works with DLP projectors.
Monitor reports 57 Hz refresh. That should work on most monitors.
Also fixed the bug that caused those artifacts on left edge and bottom.
Not really sure what was wrong, but rewrote driver from Chip's example and this time it worked...