All Forums
 Hardware
 Displays
 Colors not correct on 4bbp mono display
 Forum Locked
 Send Topic to a Friend
 Printer Friendly
Author Topic  

akidder

1519 Posts

Posted - 12 Mar 2002 :  15:55:40  Show Profile  Email Poster
Q: I'm using a 4bpp mono display (Optrex 50840). When I display a bitmap, the colors seem scrambled. How can I fix this?

[The following information may not apply to all CE builds]

The answer to this question is a bit long. See the Background section for details. We provide the solution first:

1. Your system's CE display drivers were probably configured to use 8bbp instead of 4bpp. In the ADSLOAD.REG file, change the setting to 4bpp as follows:

[HKEY_LOCAL_MACHINE\Drivers\Display]
"BitsPerPixel"=dword:04

2. You will find that colors (shades of gray) are now displayed correctly. However, now adjacent pixels are swapped. This makes it espcially difficult to read text! You have two choices. Pick the one that's easiest to implement.

2A. Use New 4bpp CE Display Drivers
The upcoming release of ADS CE builds includes a feature that swaps the 4bpp pixels in the display driver. Activate 4bpp pixel swapping in the driver with the following entry in the ADSLOAD.REG file:

[HKEY_LOCAL_MACHINE\Drivers\Display]
"PixelOrderChangeOn4BPP"=dword:0

Preliminary tests indicate about a 2.5x performance decrease in GDI operations, but since the panel is small and passive, performance is still high.

2B. Rewire the Cable.
Swap adjacent data bits in the cable (D0<->D1, D2<->D3). On Graphics Clien Plus, Graphics Master and Bitsy display connectors, these signals correspond to LDD0-LDD3 ("Blue1-4"), respectively.

If you pursue this option, disable software pixel swapping in ADSLOAD.REG by setting the following key:

[HKEY_LOCAL_MACHINE\Drivers\Display]
"PixelOrderChangeOn4BPP"=dword:1


Background

It appears that somewhere in the early development of the CE kernel, there was a mistake in the 4bpp cable to the reference platform used to develop the StrongARM display driver. The error was easy to miss.

The StrongARM reads 8-pixel chunks at a time (32 bits) from the frame buffer. The LSB of each 32-bit word is the left-most pixel on the display. If you look at the frame buffer as a byte-wise buffer, the left-most pixel in each nibble pair must be placed at the LSB, not the MSB. This appears to have been counterintuitive to the display driver developers.

Because ADS doesn't have access to the 4bpp core of the CE kernel's display drivers, we cannot change the driver. We can only provide a high-level (and slower) workaround, or a cable "correction" as the founding developers appear to have implemented.


-----------------------
Drew Kidder
ADS Technology Transfer
  Topic  
 Forum Locked
 Send Topic to a Friend
 Printer Friendly
Jump To:
Eurotech Support Forums © Eurotech Inc. Go To Top Of Page
This page was generated in 0.02 seconds. Snitz Forums 2000