View Full Version : Color problem (NV 420 Go)

01-05-07, 05:14 PM

I do not know if this problem belongs here or to the hardware page.

I use Solaris on a laptop computer with an "420 Go" graphics card. The Solaris driver does not support this card however the "vesa driver" can use 1024x768x16 Mio. colors.

However I use a special background image. This image looks like only 64K colors and not 16M colors are used. For a foto 64K colors are enough but on the background image you see steps in the "fading colors".

By writing some test bytes directly to the screen memory (Address 0xA0000) I found out that the graphics card is really running in 16 Mio colors mode with four bytes per pixel (GG BB RR 00) but that the graphics card does not correctly display the colors of the image that are correct in the video memory.

Using Windows and Linux (original NV driver) the image is displayed correctly.

I do not know if it is that simple but if "only" some registers in the card had to be set (written to using the "out" instruction) I could write a device driver that simply changes the registers' values.
The NV driver seems to replace the card's firmware. This is too complicated for me!!

Anyone who has more information?


--- EDIT ---
To get more information about this problem I used the following test image:
The image has a size of 256xN while pixel (X,Y) has the color value (R,G,B)=(X/2, 127-X/2, 0).
The color should "fade" from red to green in 128 steps. However it fades in 32 steps.
This means to me that only 18 of the 24 color bits are used by the card's hardware.
I booted the old MS-DOS and found out that when using the on-board video BIOS of the card there is the same color problem so I think the actual problem is that the on-board video BIOS does not do all the settings the nVidea driver does.

01-13-07, 02:13 AM

I did some re-engineering and found out the following:
The card has three memory spaces in the PCI area:
1) 16 MB - Graphics registers
2) 64 MB - Video memory (as A0000h, but linear and not banked)
3) 512 KB - This is not used by the Linux driver

I could also find out some locations of registers in the 16 MB area.
The computer crashes when I read out certain locations in the first 6 MB of the 16 MB area. I'd like to know why.

I'll try to continue to re-engineer the driver to write a tool that
- resolves the color problem
- enables me to use a second display in "copy mode"


--- EDIT ---
I found out that the external video connector works when the monitor is connected when powering up the system. So I do not need to write an additional tool/driver for this.

The external video connector works with 16 million colors while the laptop's display works with 256 K colors. I still wonder why because I want to have my 16 million colors on the laptop's display.

After starting the nvidia driver under Linux (starting the X server and terminating it) the on-board video bios displays 16 million colors, too, but causes a crash of the system after less than one second. Therefore I'm sure that the nvidia driver sets any registers that allow the use of 16 million colors. I still want to know what registers.

I'll give up re-engineering because it takes too much time.

01-14-07, 02:21 AM
I found out the following:

In some web pages I read that many LCDs only support 6 bit color depth.

Many graphics cards or can use deithering in this case so the difference between real 24 bit and "emulated" 24 bit can not be seen by the user.

Theoretically this can be done by the software (the X server), too.

The 420 Go seems to support this feature by hardware.

My solution was simple: I took my background image (the reason why I want the 24 bit DAC) and deithered it with the algorithm described on the web pages.


03-05-07, 01:04 AM

I found out the sequence to switch the second screen (external video connector) on or off:

Read port 0x3CC (inb instructon). If bit 0 is set use ports 0x3D4/0x3D5, otherwise use ports 0x3B4/0x3B5 (this is true for every graphics card of every manufacturer).

Now the following sequence (here: 3D4/3D5) is done:
Write 0x1F to port 0x3D4.
Write 0x57 to port 0x3D5 (write 0x57 to register 0x1F).
(Maybe a short delay is required here.)
Write 0x1A to port 0x3D4.
Read port 0x3D5 (read register 0x1A).
To enable the external video output clear bits 6&7 (and value with 0x3F).
To disable the external video output set bit 7 (or value with 0x80).
Write the new value back to port 0x3D5 (update register 0x1A).

(Sometimes the sequence does not work so you should do it multiple times.)

I managed to write an application that works under OpenSolaris using the "vesa" video driver that enables or disables the external video port.