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.
VGA Mode 13h Palette Wrong [SOLVED]
VGA Mode 13h Palette Wrong [SOLVED]
Last edited by SpyderTL on Sun May 21, 2017 8:59 pm, edited 1 time in total.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
-
- Member
- Posts: 5587
- Joined: Mon Mar 25, 2013 7:01 pm
Re: VGA Mode 13h Palette Wrong
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.
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.
Re: VGA Mode 13h Palette Wrong
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.
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.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
-
- Member
- Posts: 5587
- Joined: Mon Mar 25, 2013 7:01 pm
Re: VGA Mode 13h Palette Wrong
During POST, in order to display POST messages and stuff on the screen.SpyderTL wrote:So at what point is the palette getting set to the EGA palette?
Because it's the default when you're using the BIOS, without directly programming any of the VGA registers.SpyderTL wrote:Second, why is it called the "default VGA palette", if you have to set it up every time the machine boots?
If you're not using the BIOS, there is no default palette.SpyderTL wrote:Shouldn't the EGA palette be the "default VGA palette"?
No.SpyderTL wrote:Is it just a coincidence that I get the same palette on 3 different VMs?
Probably not.SpyderTL wrote:Will I get a different default palette on a physical machine.
Re: VGA Mode 13h Palette Wrong
Hi,
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
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.SpyderTL wrote:You are correct. The EGA palette is what I'm seeing.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: VGA Mode 13h Palette Wrong [SOLVED]
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.
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.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: VGA Mode 13h Palette Wrong [SOLVED]
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").SpyderTL wrote: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.
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.
Re: VGA Mode 13h Palette Wrong [SOLVED]
Hi,
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
I always use R3G3B2, because (excluding colour blind users) a human eye is more sensitive to green and less sensitive to blue.SpyderTL wrote: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.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.