OSDev.org

Hey guys.

Last night I got my 32-bit VGA switch to mode 13h code working, so today I started to try to draw colors using the default palette. Most of the first colors are correct, but color 15 should be white, just like EGA. But on my screen, it shows up light blue, and it's the same on VirtualBox, VMWare and Bochs.

I'm not changing the palette entries at all, so I assume they should match the default palette shown on the Wikipedia page.

Why are some of my colors wrong? I'm using the sample code at these links to set up all of my VGA registers. (I'm in 32-bit mode and not using the BIOS.)

http://files.osdev.org/mirrors/geezer/o ... cs/modes.c
http://ftp.lanet.lv/ftp/mirror/x2ftp/ms ... /modes.asm

There are a few minor differences between these two links where slightly different values are being written to the VGA registers, but I've tried them both and I get the same results.

Has anyone had this problem or know what may be causing it? Do I have to overwrite the VGA palette, or is it safe to assume that the default 256 color palette is set up when the machine boots?

Thanks.

The BIOS also sets the palette when it switches modes.

On CGA, the 16-color palette is completely hardwired. EGA extended this by adding an attribute controller, which could be used to select colors from the hardwired 64-color EGA palette. VGA extends this further by replacing the hardwired palette with RAM.

In video modes that are meant to be compatible with EGA, the BIOS has to fill the palette RAM with the EGA palette. In video modes that are also meant to be compatible with CGA, the BIOS has to program the attribute controller to select the CGA palette from the EGA palette.

Since you've programmed the attribute controller but not the palette RAM, you're seeing the EGA palette that was loaded by the BIOS.

You are correct. The EGA palette is what I'm seeing.

But that just raises more questions.

First, I'm not asking the BIOS to switch video modes at any point. I just use the standard text mode (which uses the CGA palette, I think), and then using VGA ports to switch to mode 13h. So at what point is the palette getting set to the EGA palette?

Second, why is it called the "default VGA palette", if you have to set it up every time the machine boots?

Shouldn't the EGA palette be the "default VGA palette"? Is it just a coincidence that I get the same palette on 3 different VMs? Will I get a different default palette on a physical machine. (I haven't had a chance to test it on a real machine yet.)

Thanks again.

During POST, in order to display POST messages and stuff on the screen.


Because it's the default when you're using the BIOS, without directly programming any of the VGA registers.


If you're not using the BIOS, there is no default palette.


No.


Probably not.

Hi,



There's a DAC, which is a table containing 256 entries that determines the colour. In 256-colour modes the 8-bit colour value selects an entry in the DAC.

There's also 16 palette registers. In 256-colour modes the palette registers are not used. In 16 colour modes, the 4-bit colour value selects a palette register, and the value from the palette register selects an entry in the DAC, like "final_colour = DAC[ palette[four_bit_colour_value] ]".

When switching to a 16 colour mode (where palette registers are used) the VGA ROM configures the DAC for EGA palette ("DAC[15] = light blue") and then configures the palette registers to select CGA colours from the EGA colours ("palette[15] = 63" and "DAC[63] = white").

When switching to a 256 colour mode (where palette registers are not used) the VGA ROM configures the DAC so that "DAC[15] = white".


Cheers,

Brendan

Okay, I am now overwriting the palette with a sort-of "identity mapped" palette where I can easily shift/mask a 32-bit ARGB value down to an 8-bit RGB value (R3G2B3 format), which will map to the identical palette entry. Everything is working great, except for the fact that all of my Gray colors are off, because there's no way get all three color values the same using this format. I may have to put some more thought into it at some point.

Thanks guys.

EDIT: While I was working through my palette issues, I was searching for information about Mode 13h, and I found this YouTube video. He mentions osdev.org, so I figured that it was likely that he has an account on the forum.

AlgorithMan.de
https://m.youtube.com/watch?v=N68cYNWZgy8
http://wyoos.org/

Anyway, I thought it was funny, cause I got to watch someone else write the exact same code that I just got finished writing.

EDIT2: I found him on the forum, but he hasn't been on in nearly a year. I may have to check out some of his other videos. I wonder if he has one on EHCI controllers.

You could always treat the green value as if it were three bits with its lowest bit equal to its highest bit (so the field values of 00, 01, 10, and 11 become 000, 010, 101, and 111 respectively - so your translation code for green becomes the two-step "g = g << 1 + g >> 1; g += g << 3").

It's not quite an even distribution, but it's at least reasonably close (the two intermediate values are -/+5% from the even distribution respectively) and gives true grays.

Hi,



I always use R3G3B2, because (excluding colour blind users) a human eye is more sensitive to green and less sensitive to blue.

For the DAC values I use a "shift and OR" pattern to expand a 3-bit value (for red and green) into a 6-bit value using "x = y << 3 | y", and to expand a 2-bit value (for blue) into a 6-bit value using "x = y << 4 | y << 2 | y". This won't give true greys, but I also use Floyd–Steinberg dithering so the lack of true greys isn't as noticeable.


Cheers,

Brendan