nanogui: 16bit color depth in microwindows
Subject:
Re(2): [nanogui] 16bit color depth in microwindows
From:
"William Mohat" ####@####.####
Date:
30 Oct 2001 13:55:16 -0000
Message-Id: <fc.000f6801002a7b953b9aca009dbc37b3.2a7c86@telos-systems.com>
Some detail on the 16 bit / pixel problem (TRUECOLOR565):
We are using a StrongARM processor, with EXTERNAL Epson
LCD controllers. Here's why:
The LCD controller inside the StrongARM
takes up a lot of the CPU's memory bandwidth, and it tends
to "break up" the video display if any peripheral injects any "wait
states". The internal LCD controllers are also not fast enough for
TFT panels larger than about 1/2 VGA in size. Going with
an external LCD controller solves the "video breakup" problems
(i.e. flicker, speckles and jitter in the display), and also lets
your CPU run about 30% faster.....
The DOWNSIDE of the external Epson LCD controllers is as
follows:
1) Almost all of the Epson "embedded" LCD controllers have
16 bit CPU data interfaces. And, MicroWindows (as well
as most other LINUX software) expects to do optimized
32-bit data transfers to the video memory. Now, this is
not a problem if your CPU (or it's external support chip set)
supports "dynamic bus sizing".......which takes a 32-bit
"write cycle" and (in hardware) automatically breaks it up
into two 16-bit write cycles. However, the StrongARM
(as well as many other embedded CPUs) do not support
this. As a result, when running in 16 bit / pixel mode, the
software tries to write two pixels at a time. Only ONE
gets to the video memory......the other 16 bits of data goes
to the "bit bucket", and leaves a black spot on the screen.
The solution is to look at all of the drawing routines, and
"un-optimize" them to do two 16-bit writes in software
wherever 32-bit writes are attempted. The amount of
work to do this is not trivial, but we have most of this
done already. If Greg is interested, we can submit our
"patches" back to him so MicroWindows can support
other people's 16-bit video projects as well. (I would
have thought the Epson software people would have
been behind this effort, but they aren't.)
2) The Epson LCD controllers (the simpler ones anyways)
do not have internal pallettes. When running in 565
mode, you have fixed bit assignments to each bit
in a word of video memory.
This cannot be changed, so "pallette support" and
color mapping has to be handled externally in software.
Now, we have tried all of the MicroWindows demos.
Everything runs just fine .... even the "Alpha Blending" demo
(the one with the red car that has text overlays over it) ... these
demos all look just perfect on the Epson system. And those
are a mix of 8 bit/pixel to 24 bit/pixel source files. But, none
of the demos are in 16 bit TRUECOLOR565 mode.....
Our problem comes in when we are trying to run some software
that was originally intended for Windows CE. We know the original
software authors did .GIF and / or .BMP images, and used some
sort of WinCE function to get them painted on WinCE's LCD
screens. Now, these pictures look just fine when we try to
display them on a desktop LINUX PC, running under x11.c
MicroWindows. But, on a StrongARM under the fb.c LCD "framebuffer
driver", the same image is visible, but the colors are all out of whack.
There clearly is a pallette / color mapping problem here, but we
have no idea where.
Now, simple GWES graphics calls under Windows CE (draw line,
draw text, fill area) all work just fine. There must be some sort of
"display .GIF" function that is not handling the pallettes correctly ...
or at least that is our assumption. Of course, we don't have source
code for ANYTHING under WinCE. What a pain...
Has anyone seen this before? Any pointers?
Bill Mohat
Telos Systems
