16-bit color photo on 4.3" LCD
Rayman
Posts: 14,641
Starting a new thread as this is something of a milestone (for me anyway)...
This code is showing a 16-bit image stored in HUB RAM on a 4.3" LCD with 480x272 resolution.
This adapter only has 6 of the 16 color bits wired up though. But, I have PCBs on order that will give all 16 bits.
Note that LCD is actually 24-bit, but I'm thinking that it's best to work in 16-bit color or less.
Uses RDFAST and RFWORD to quickly read in words (16-bit color pixels) from HUB.
I have the lower 16 pins of OUTA (P0..P15) for the 16-bit color word.
This lets me use setword to push the next pixel to outa with ease.
Refresh rate is probably fairly low (have to measure), but real chip should have higher clock frequency, so maybe it's OK.
Again, image quality will improve when I get my new PCB...
BTW: You can see the jumper wires that were giving me some trouble in the photo. New PCB should fix that too.
This code is showing a 16-bit image stored in HUB RAM on a 4.3" LCD with 480x272 resolution.
This adapter only has 6 of the 16 color bits wired up though. But, I have PCBs on order that will give all 16 bits.
Note that LCD is actually 24-bit, but I'm thinking that it's best to work in 16-bit color or less.
Uses RDFAST and RFWORD to quickly read in words (16-bit color pixels) from HUB.
I have the lower 16 pins of OUTA (P0..P15) for the 16-bit color word.
This lets me use setword to push the next pixel to outa with ease.
Refresh rate is probably fairly low (have to measure), but real chip should have higher clock frequency, so maybe it's OK.
Again, image quality will improve when I get my new PCB...
BTW: You can see the jumper wires that were giving me some trouble in the photo. New PCB should fix that too.
Comments
I was wondering how you managed top get the data into the P2. Should make a lovely table of 'random' data for further testing my software mult and div routines on the Nano (no cordic).
16-bit mode is widely used on this size lcds.
And it makes a lot of sense for P2 with the word level instructions.
Also, although there are a lot more I/O than P1, it would still be a bit of a waste to do 24 bits.
That all said, I'm not totally decided yet. With faster clock, LUT might allow easy use of 24 colors with 8-bit bitmap...
The PCB will hopefully work for nano. But, prop plug might interfere...
What I did last year when I wanted to plug in a board on my nano setup was solder in a 4-pin header sideways to the propplug header. Then, the prop plug could connect sideways, under the board. Maybe that will still work here...
If you route to a 4 pin hdr from the current Nano connector on your board, but that is a little distance from that connector, would you not get clearance, or does the Nano cover the whole board?
EDIT: Many pro-grade monitors advertise as 30-bit colour. It would be interesting to know if any of those are not dithering.
BTW maybe a short 40-pin flat cable could be used between nano and lcd
It's a trade off of memory & write speed, but the P2 will (hopefully) have plenty for > 16b plans.
I think many LCD's have a choice of 8b bus and 3 writes for 24b colour, which saves pins.
IIRC the SSD1963 has a 2 x 12b mode for yet another combination trade-off of Width cs Speed...
Yes, most embedded control space does not need photo images, but once you have the ability, it does open some appealing use cases :
Code-generated information can become font only, with a general bitmap skin used for the buttons, surrounds, logos, etc.
This 'skin' can be created in higher end graphics tools, with colour blends, drop shadow effects & full logos.
More complex 'plant schematics' can be done the same way - an image skin than has control information superimposed.
It does save pins, but you need 3X the write speed. That might be OK.
I've also seen new LCDs with "MIPI" interface. It's something like DVI, I think.
That looks to be even fewer wires, but superfast interface, might not work with P2 directly.
But, I think plain 24-bit interface will be around for a while.
I think showing a 16-bit per pixel image from HUB is a breakthrough because it's the way I imagine one would mostly use the P2... It's how I use a 3.5" LCD with SSD1921. Basically, the 16bpp image is your single buffered canvas that you write to. You can keep other resources like font and icons in 1, 2, 4, or 8 bpp in RAM and then write them to the buffer to update the screen. This can even work for some games as you can update the screen during vertical refresh. The nice thing about this approach is that the resources don't all have to have the same color palette.
But, I image the best way for games is to double buffer 8bpp. This does require all the resources to have the same color palette....
Lenna looks a lot better now in the full 16-bit color:
Also now, when I look at the P123 image, I think I'm missing a couple rows on the bottom...
Think I have to tweak the driver some...
So, are you using the streamer to do this, or are you just bit banging it?
Oh, I just read back and I understand that you are doing this in software. I've got to get the streamer documented.
Something very strange is going on here with rdfast...
Maybe I should start a different thread for that...
Well, since Chip is looking, I'll just put it here:
I noticed some missing lines in my bitmap image on P123 and fixed it by changing the rdfast origin like this:
So, the image data starts at @hubline like this:
I fixed it for P123 by subtracting 12 lines of data from the start address (-480*12*2).
Why on earth that works is beyond me.
I hope it's a bug...
My main vertical loop issues rdfast to set data origin.
Then, it does 480*272 rfwords and then starts over.
I took a nap and realized what the problem is...
I must be reading in pixels during back porch...
Should have known there was no way for bug to multiple of 480 pixels.
I think I've got it figured out now.
Had one other issue that I just figured out:
The very last line of pixels on the DE2-115 was messed up.
Finally figured out that image was up against the 256k memory limit.
I moved the image starting point from $1000 to $200 and it's all better now.
Shows how important Memory is for display work.
480*272 is a modest resolution and will become more modest as time goes by.
But, it can look nearly is good in 8bpp bitmap mode and then there'd be plenty of room left.
DE-nano can't really show a full screen photo from RAM. But, can from uSD card.
When somebody ports over a fast driver, like fsrw, can show photo...
I did add a uSD card to this board in case we get that going one day...
Next, I think I'd like to work on pixel graphics and also text modes...
Photos of 4.3" photo working properly now on both DE2-115 and P123:
Monochrome screen only takes ~16kB, so should work on nano...
If I did the math right, a 128 character font just fits in the LUT.
I'm wondering if that is a good idea or not...
RDLUT takes 3 clocks where RFLONG takes 2 clocks but takes some setup.
LUT is zero based, so that should make it easier.
Not sure speed difference matters though.
Size seems like it'd be about the same too as need some code to fill LUT.
Raster PAL/NTSC is a different story.
Interesting could be LUT Font, and a mixed Image+font render, that allowed a simple palette choice on Font, and maybe a reduced contrast image fetch for BG ?
I'm thinking of skin design GUIs here.