Found the problem with the first columns... It's the size of the file... For some reason, Photoshop (maybe everybody?) tacked on an extra word to the file, guessing so file size is divisible by 4.
This was not properly being accounted for...
Still have a problem with the image though. Think the single line buffer is not working.
Going to switch to double line buffer, like the VGA code has...
Double line buffer fixed the image issues. It's perfect now...
Also seeing that don't really need HSync and VSync. Seems to be fine with DE only.
Think if ever do it again will make those left and right audio instead...
Ok, think figured out that was doing smartpin pulses in a bad way. The silicon doc description of the pulse mode is really bad...
Think decided that want X.[31..16] set to 0 and X.[15..0] set to 1. With this, setting Y with wypin #n gives you an n clock pulse.
Why the above issue happened, still don't know. Think the pulses where coming out on some random cycle that could happen to be good or happen to be bad...
@evanh So the silicon doc suggests that with X=0, that wypin Y will produce a pulse of Y clocks. But, this doesn't work.
Does seem to work when X=1 though...
@Rayman said:
@evanh Well, guess the docs are either wrong or incomplete... X=1 does seem to work though...
You need to look harder at whatever you're doing. The docs aren't wrong, just a little lacking when out of bounds.
I just did some experimenting ... When X[31:16] >= X[15:0] then you get no pulses. When X[31:16] = 0 and X[15:0] > 0 then you get a single pulse of length of X times Y sysclock ticks.
What mode are you using again? I was assuming P_PULSE (%00100). The one used for multiple PSRAM clock pulses.
It has to be that. There's only the two pulse output modes for a specific number.
That's cool, certainly an unexpected way to use it but actually very effective. Good find!
This same board can also drive lower resolution, 480x272 displays.
Here is a driver and slideshow adapted for this resolution.
This is also displaying from PSRAM.
But, it could be adapted to display an image in HUB RAM.
A 16bpp image is only 255 kB in this resolution.
Double buffering is easier in this resolution as display buffer could be in PSRAM and working buffer in HUB RAM.
On the other hand, keeping everything in PSRAM frees up the HUB RAM...
Comments
I will remind of the streamer-based driver I posted earlier (did you end up fixing the latch order for DMA?)
Still don’t have a handle on the streamer…
@Wuerfel_21
I’ll be shipping one of these to you this weekend.
This 4.3” version can also work with lower resolution displays 480x272 think. Want one of these too?
Found the problem with the first columns... It's the size of the file... For some reason, Photoshop (maybe everybody?) tacked on an extra word to the file, guessing so file size is divisible by 4.
This was not properly being accounted for...
Still have a problem with the image though. Think the single line buffer is not working.
Going to switch to double line buffer, like the VGA code has...
Just stop with the BMPs and do raw pixel buffers. Can create them in any imaginable format using ffmpeg.
Double line buffer fixed the image issues. It's perfect now...
Also seeing that don't really need HSync and VSync. Seems to be fine with DE only.
Think if ever do it again will make those left and right audio instead...
Ok, driver seems to be in good shape, there is just one thing that makes me think something is horribly wrong.
It's working fine now, as is.
But, if one adds just one extra variable to the "Start()" method, the video gets corrupted and colors are wrong.
So, this works:
PUB Start(pMailbox) |i 'Start LCD driverBut this doesn't:
PUB Start(pMailbox) |i,j 'Start LCD driverThis makes it really bad:
PUB Start(pMailbox) |i[100] 'Start LCD driverHead scratching here, not sure have seen this kind of thing before...
Ok, think figured out that was doing smartpin pulses in a bad way. The silicon doc description of the pulse mode is really bad...
Think decided that want X.[31..16] set to 0 and X.[15..0] set to 1. With this, setting Y with wypin #n gives you an n clock pulse.
Why the above issue happened, still don't know. Think the pulses where coming out on some random cycle that could happen to be good or happen to be bad...
I assume you are talking about the smartpin that pulses the PSRAM clock pin?
Maybe it's actually Transition mode? Then X = 1 is a clock divider of 2.
Otherwise, Pulse mode X = 1 won't work. X register holds the clock divider in X[15:0], with the mark-space ratio in X[31:16].
EDIT: Actually, X = 1 in Pulse mode is not documented. It's possible it'll act like X = $0001_0002 but with a phase shift.
@evanh So the silicon doc suggests that with X=0, that wypin Y will produce a pulse of Y clocks. But, this doesn't work.
Does seem to work when X=1 though...
No, X = 0 is not valid in any way. Neither is X = 1 though. X = $0001_0002 is smallest valid value.
@evanh Well, guess the docs are either wrong or incomplete... X=1 does seem to work though...
You need to look harder at whatever you're doing. The docs aren't wrong, just a little lacking when out of bounds.
I just did some experimenting ... When X[31:16] >= X[15:0] then you get no pulses. When X[31:16] = 0 and X[15:0] > 0 then you get a single pulse of length of X times Y sysclock ticks.
Ok, that's what I'm doing... X=1 for single pulse of Y ticks.
What mode are you using again? I was assuming P_PULSE (%00100). The one used for multiple PSRAM clock pulses.
It has to be that. There's only the two pulse output modes for a specific number.
That's cool, certainly an unexpected way to use it but actually very effective. Good find!
PS: Here's my tester. Needs a storage scope or logic analyser.
CON _clkfreq = 10_000_000 PUB tester() pinf( 56 addpins 1 ) wrpin( 56 addpins 1, P_PULSE | P_OE ) wxpin( 56, $0001_0002 ) wxpin( 57, $0000_0002 ) pinl( 56 addpins 1 ) wypin( 56 addpins 1, 8 ) repeatJust try editing the genetically superior driver I wrote.
That one I 100% confirmed has the correct edge alignments on the logic analyzer.
I don't know what Rayman is doing with the smartpin. I assumed it was the clock to the PSRAMs but obviously isn't since he only wants one pulse.
The pulse smartpin mode gets the LCD driver to 60 fps by replacing two drvh/drvl combos with two wypin...
Think this is where Chip is attempting to describe this mode:
But, he doesn't say what X.[15..0] does in this case.
Anyway, appears that setting X.[15..0]=1 gives a pulse of Y clocks.
This same board can also drive lower resolution, 480x272 displays.
Here is a driver and slideshow adapted for this resolution.
This is also displaying from PSRAM.
But, it could be adapted to display an image in HUB RAM.
A 16bpp image is only 255 kB in this resolution.
Double buffering is easier in this resolution as display buffer could be in PSRAM and working buffer in HUB RAM.
On the other hand, keeping everything in PSRAM frees up the HUB RAM...