Best way for 8-bit color on 24-bit lcd ?
Rayman
Posts: 14,876
I've decided to try to make an 8-bit driver board for my 3.5" touchscreens.
The current driver is 6 bit (2 bits per color). There, it was fairly simple to decide how to best connect the pins, although I needed help...
The answer was like this:
10101010
01010101
Now, I'm getting greedy after figuring out that I don't really need the HS and VS sync signals, giving me two extra bits for color. I've read on wikipedia about some old 8-bit modes...
But, the question is how best to connect the pins... Want evenly spaced color levels. Also, want true gray scale, like before on at least 4 levels...
Anyway, here's my solution. If anybody knows a better way, I'd love to hear it!
For Green and Red:
10010101
01001010
00100000
For Blue:
10110101
01001010
The current driver is 6 bit (2 bits per color). There, it was fairly simple to decide how to best connect the pins, although I needed help...
The answer was like this:
10101010
01010101
Now, I'm getting greedy after figuring out that I don't really need the HS and VS sync signals, giving me two extra bits for color. I've read on wikipedia about some old 8-bit modes...
But, the question is how best to connect the pins... Want evenly spaced color levels. Also, want true gray scale, like before on at least 4 levels...
Anyway, here's my solution. If anybody knows a better way, I'd love to hear it!
For Green and Red:
10010101
01001010
00100000
For Blue:
10110101
01001010
622 x 407 - 7K
Comments
You might consider a color difference method of coding.
If you used 2bits for Red and Blue difference signals, and 4bits for luminance you could get the Green from a 256 byte table.
that way you could effectively have nearly 4bits per color.
Perry
That would raise the cost a bit more that I'd like though...
you probably would need 3cogs synchronized though.
but there would be much less hardware with 3 dutyDACs driving the VGA RGB pins.
it would then be possible to do greater color depths with 2byte pixels
you also might need sample and holds after each dutyDac so you hit the sample enable after all DACs are set.
OOP's sorry I misunderstood, your driving 24 bits not a VGA interface
Perry
I think the way you have it is about the best that can be done, giving blue levels at 0, 74, 181, 255.
The Prop as a CLUT? Interesting idea, wonder whether that could be made to work.
I was just thinking yesterday at having a look at some old ISA vga boards (Orchid, Tseng Labs, etc), see what chips they used for the lookup table / DAC.
I think the CLUT could work for me only because I can drop the pixel clock to 5 MHz or so and still be OK. It seems hard though, now that I think about it...
Maybe I'll have to look up Beau's Prop-Prop code and see how fast that can go with more pins...
Some of the LCD datasheets I've looked at don't specify a minimum clock. I wonder if that is for real and they can really be run slow, like 1MHz or below, or whether they haven't bothered filling in that box of the datasheet because they assume everyone works at the nominal frequency? Would love to know...
If you used a second prop as CLUT I'm guessing it would really only tie up one cog, correct? Or I suppose you could split off into colour planes and use 3 cogs if there was some advantage. The other cogs and spare RAM might be good for USB host, etc...
Sure it can drive a 16x4 LCD. Parallax sell this one, and they include example code. This would be a great place to start.
Rayman here is the expert supplier & coder on some cheap and very popular graphic LCDs that make use of the Prop's ability to display graphics - see his website . Some are cheaper than 16x4 LCDs (!)
My calculations show that you'd get the best separations for red and green with:
01001001
10010010
This yields a suboptimal setting for blue, however, in order to obtain pure grays:
10010010
with gray values at 0, 109, 146, and 255.
Just out of curiosity, how did you arrive at your bit codes?
Thanks,
-Phil
Thanks for your help while do you mean that I have to use the LCD made by parallax only or anyone else 20x4 LCD. In addition dose it support the Chinese character. Thanks a lot!
My first try was:
Blue (same as before)
10101010
01010101
Red&Green
10000000
01010101
00101010
But, I soon figured out that that was a terrible choice...
daniel, I'm sure you can use any character LCD you want. I'd be surprised if you can't find one with Chinese font, seeing how most of them are probably made in China... But, if you really, can't, I sell a graphical monochrome LCD dipslay at GadgetGangster.com...
But, after second thought, the economics don't support it... Actual plan is to use a Solomon graphics chip, which costs the same, but has a lot more functionality...
Ray, can you explain how you accomplish this? Is it something we could do with the 4.3" as well? (Just off the top of my head... since it is a fixed timing signal... so could it be that simple... feed the HS of a clock and a VS off the clock*height?)
Bill
Both ways work, but the DE way lets me generate 8-bit color with just 1 cog.
My 4.3" lcds don't have a DE option. But, perhaps you could do the same thing using 2 syncronized cogs...
-Phil
-Phil
I think it could be done in one cog though, might have to give that a try someday...
-Phil
Correct, although I use up to seven cogs depending on the driver and its memory and rendering cog (points, lines, sprites etc) requirements. I can reduce that by 1 or 2 cogs.
Phil:
I considered that, but have not had time to experiment with changing vcfg during sync. If the change takes place immediately and does not mess with the PLL, it should work fine...
Between you guys I ended up adding a new item to my TODO list.
It works! Now have 8 levels of red and green, keeping 4 levels of blue and 4 grays...