16-bit color photo on 4.3" LCD

RaymanRayman Posts: 11,494
edited 2015-10-25 - 17:01:19 in Propeller 2
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.


640 x 480 - 96K
640 x 480 - 105K
«1

Comments

  • Great job! This is going to be very exciting with the new chip and LCD projects. Why is it best for 16 bits, is this due to faster ram access at 16 versus 24 bit access? How much visible loss( noticable loss) compared to 24 bits?
  • Rayman wrote: »
    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.

    Well done!

    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).

  • Really nice work Rayman. Is the new PCB for the 1-2-3 or nano or both?
  • RaymanRayman Posts: 11,494
    edited 2015-10-25 - 21:05:58
    From what I've seen, you can't tell difference between 24 and 16 bits on LCD.
    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...
  • Rayman wrote: »
    From what I've seen, you can't tell difference between 24 and 16 bits on LCD.
    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.

    The PCB will hopefully work for nano. But, prop plug might interfere...
    Could you put a 4 pin 0.1" header on board for connecting the PropPlug? Or alternatively use the other Nano connector on which outa /ina appears. I'm currently driving some 'helper' leds in my code for visual debug on outa, so they do work.


  • I didn't see a way to do that or to easily avoid covering the prop plug...

    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...
  • When I said other header I meant for video output. Depending which pins you intend to fully use.

    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?
  • evanhevanh Posts: 10,088
    edited 2015-10-25 - 22:23:35
    Even the large desktop/laptop/TV, so called 24-bit, LCD's are mostly only 18-bit native. The built-in scan converters will be doing either spacial (on high dpi displays) or temporal (on low dpi displays) dithering. Maybe the expensive "pro" grade monitors are true 24-bit colour ... maybe.

    EDIT: Many pro-grade monitors advertise as 30-bit colour. It would be interesting to know if any of those are not dithering.
  • When I say built-in scan converter, I'm talking about the whole monitor/TV rather than the LCD itself. Laptops/Phones have the option of doing such features on the GPU but I can't say what is typical.
  • That's what I think to, but a side of me is still greedy and wants all 24 bits...

    BTW maybe a short 40-pin flat cable could be used between nano and lcd
  • jmgjmg Posts: 14,540
    Rayman wrote: »
    That's what I think to, but a side of me is still greedy and wants all 24 bits...

    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...


  • T ChapT Chap Posts: 4,039
    edited 2015-10-26 - 00:33:50
    I don't imagine any applications for myself with photo images, mostly just graphics for touch screen applications on the Newhaven 4.3 and maybe 5.0. 24bit is way overkill for most applications on LCD I think. It is great to see the progress happening on this.
  • jmgjmg Posts: 14,540
    edited 2015-10-26 - 01:57:00
    T Chap wrote: »
    I don't imagine any applications for myself with photo images, mostly just graphics for touch screen applications on the Newhaven 4.3 and maybe 5.0. ..

    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.
  • I have seen 8-bit bus with 3 writes for 24-bit RGB being used with SSD1928.
    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....
  • Got my boards in yesterday... Made a couple mistakes, but miraculously they are all easy to fix.

    Lenna looks a lot better now in the full 16-bit color:
    640 x 480 - 81K
  • Just tried it on DE2-115 and noticed a vertical sync issue...

    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...
    640 x 480 - 89K
  • cgraceycgracey Posts: 13,125
    edited 2015-10-31 - 17:16:52
    Rayman wrote: »
    Got my boards in yesterday... Made a couple mistakes, but miraculously they are all easy to fix.

    Lenna looks a lot better now in the full 16-bit color:

    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.
  • RaymanRayman Posts: 11,494
    edited 2015-10-31 - 17:23:07
    I'm using RDFAST, so I guess that is not the streamer, right?

    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:
  • RaymanRayman Posts: 11,494
    edited 2015-10-31 - 17:30:04
    I think there's something wrong with rdfast.

    I noticed some missing lines in my bitmap image on P123 and fixed it by changing the rdfast origin like this:
    'Main Loop
    VerticalLoopStart
    		'Setup to fast Read in 480*272 words from hub
    		rdfast	#0,##($1000-480*12*2)'hubLine1
    

    So, the image data starts at @hubline like this:
    orgh $1000
    'alignl
    HubLine1
    WORD   $AA09, $A20A, $AA0A, $A9E9, $AA29, $AA29, $AA09, $A9E9, $B229, $A9E9, $B229, $AA09, $A9E9, $B1E9, $A9E9, $A9C9
    WORD   $A9C9, etc...
    

    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.
  • Here's the source code:
  • Darn, wrong file, now I have to post again...
  • If your data starts at $1000, you would do 'RDFAST #0,##$1000', I would think.
  • Could there be some dummy preamble data that the LCD expects?
  • RaymanRayman Posts: 11,494
    edited 2015-10-31 - 18:07:42
    Never mind, Sorry...
    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.
  • Ok, got it all sorted out. Sorry for another false alarm.

    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.
  • Super!
  • jmgjmg Posts: 14,540
    Rayman wrote: »
    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.
  • RaymanRayman Posts: 11,494
    edited 2015-10-31 - 22:48:43
    The DE2-115 doesn't really have room to do anything else but show this image.
    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:
    640 x 480 - 88K
    640 x 480 - 91K
  • Just thinking about 8x16 font and monochrome graphics...
    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.

  • jmgjmg Posts: 14,540
    Rayman wrote: »
    Not sure speed difference matters though.
    Speed should not matter too much for LCD writes ?
    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.
Sign In or Register to comment.