VGA Mode 12h

[neon]

Hey everyone

Im experimenting with VGA Mode 12h. Its not using the BIOS ints so it is possible that the initial setting in a register might be at fault.. Im not sure though.

The problem comes when rendering to the display. Here is my current code. It is supposed to fill video display with a light blue color. It works fine in Bochs (tested in two versions) but not VirtualPC...which is what the problem is.

In VirtualPC, this is the result (Warning: a little straining on the eyes): Link to Image

I am new to this mode so I am not quite sure where to look for in this. Does anyone have any suggestions that might cause something like this?

Here is my current test code... Im not sure if Im doing something wrong or not...

Code: Select all

PBYTE VideoMemory = 0xa0000;

//! select graphics bit mask register
outportb (0x3ce, 8);

//! mask all planes
outportb (0x3cf, 0xff);

//! select graphics mode register
outportb (0x3ce, 5);

//! select write mode 2 (replicate bits 0-3 of data across all 4 planes)
outportb (0x3cf, 2);

//! write pixels...
for (x=0; x<(640/8) *479; x++)
	VideoMemory [x] = 0x9; //! write the pixel (light blue)

Thanks for any help or suggestions

[Troy Martin]

Congratulations: It looks like the same problem as what happens when you try generating 8x8 characters in that video mode (well, the dots at least.)

Try clearing the screen first in text mode before switching to 640x480. Blame the creepy MCGA text mode Virtual PC emulates.

[neon]

Thanks for the response,

I have nulled out text mode memory before switching video modes:

Code: Select all

unsigned char *videoram = (unsigned char *) 0xb8000;
int i=0;
for (i=0; i<(80*25)*2;i++)
	videoram [i] = 0;

...Same problem though happens. Works fine in Bochs, same problem with VPC. I havn't heard of that problem with VPC, Ill need to look into that.

Does anyone have any more suggestions?

[Troy Martin]

VPC is a sketchy emulator. The emulated video card, the S3 Trio, is a subset of the real deal. The emulation doesn't support 24- or 15-bit colour modes, nor is the "VGA" exactly VGA-compliant in the sense that it's more like MCGA (notice the 640x400 text mode, not 720x400.)

EDIT: http://blogs.msdn.com/virtual_pc_guy/

[neon]

You know what? I had the Bios set the mode instead of my current setup and not only do I get a different, more pleasant bluish color on both Bochs and VPC when my rendering code runs, but.. well.. it works in VPC indicating its my initial setup of the video mode that's wrong. (VPC indicated that its the same resolution+bit depth as the mode that I was trying to set...)

When I get my VGA book back tomorrow Ill be able to double check all of the VGA registers for Mode 12h to see if I made a mistake or not. (I used the values from the wiki article.. I am thinking there is an error in it somewhere.)

I will let you know if I find anything...

[pcmattman]

Just speculating, but are you sure you have an LFB? Otherwise you may need to handle bit planes.

[neon]

Thanks for your response.

The posted code writes each byte to all four bit planes per pixel (assuming I wrote it right, anyways...) If there is an error, please let me know.

I am thinking the rendering code is working considering that it runs fine in VPC and Bochs when I let the Bios set the video mode rather then myself manually doing it. This makes me believe that its my mode setting (probably register settings) that the error is at. I can post my current register settings for it may help.

[clange]

Hi

About the difference in color. The BIOS might change the palette. Do you do that too? Just a thought.

You can also double check against this http://files.osdev.org/mirrors/geezer/o ... cs/modes.c. I use those values and it seems to work fine. The palette is mapped a bit weird though (I didn't bother to investigate - I just worked around it).

This is the table I use to map palette values (all values are decimal) (palette index => pixel / color value):

Code: Select all

0 => 0
1 => 1
2 => 2
3 => 3
4 => 4
5 => 5
20 => 6
7 => 7
56 => 8
57 => 9
58 => 10
59 => 11
60 => 12
61 => 13
62 => 14
63 => 15

If anyone knows why this is needed I would love to hear about it. Using the 720x480x4 values from the same source uses a "normal" 1-to-1 mapping.

Hope this helps.

clange

[neon]

About the difference in color. The BIOS might change the palette. Do you do that too? Just a thought.

No, I dont change the palette so I would assume itll still use the default palette.

You can also double check against this http://files.osdev.org/mirrors/geezer/o ... cs/modes.c. I use those values and it seems to work fine.

Wow, I forgot about that page. Some of the registers I have are different, so Ill be sure to test it with those settings.

I will let you know how it goes. Thanks for the help

[Combuster]

Re:VirtualPC: It has the best VGA emulation of all the VMs I have seen. Bochs on the other hand is broken in that respect, only emulating the closest "standard" mode to whatever you set it, having broken memory layouts and lots of other things that stop you from you using the VGA's more obscure features. Besides, running text in 640x400 is not a bug per se - its still 80x25 like one would expect from that mode.

About the difference in color. The BIOS might change the palette. Do you do that too? Just a thought.

In 16-color mode, the color logic works the same as in text mode, so there shouldn't be a difference there.

My subconcousness says its something about odd-even addressing that's off. But then again, I have just copy-pasted a register dump from real hardware which Just Works.

[Troy Martin]

Besides, running text in 640x400 is not a bug per se - its still 80x25 like one would expect from that mode.

I never said it was a bug; I just said it wasn't entirely VGA standard-compliant. 720x400 is VGA. 640x400 is MCGA (or VGA with some tweaking.) Also, VGA and MCGA fonts are slightly different; if I can find a dump I'll illustrate for both 8x16/9x16 and 8x8/9x8.

[clange]

In 16-color mode, the color logic works the same as in text mode, so there shouldn't be a difference there.

My subconcousness says its something about odd-even addressing that's off. But then again, I have just copy-pasted a register dump from real hardware which Just Works.

I was very surprised to discover that the 640x480x4 mode I entered handled the palette weird. I used the values from from Geezer and just assumed that the first 16 colors of the palette was used. The table I use to correct was just derived by trial-and-error since that was easier than to figure out what was wrong with the VGA values.

Could you please share the register values that you use for 640x480x16 (or I could be less lazy and just write the register dumper myself ) It feels wrong that I need a hack like this.

clange

[Combuster]

Use the source, young padawan
|
|
v

[neon]

Could you please share the register values that you use for 640x480x16 (or I could be less lazy and just write the register dumper myself ) It feels wrong that I need a hack like this.

I tried the register values from the link provided, and, surprisingly, it was worse then before... Ill be resetting the registers based on what Mode 12h is supposed to be according to my book and, if it works, post it here for you

[neon]

Yey! It worked

The register values for Mode 12h from my book were a little different then that text document though (Unless the 640x480x16 register setup in that array is not the same as Mode 12h?

Anyways, heres the register setup in case anyone is interested. Seems to work great in both VPC and Bochs:

Code: Select all

/* Register set up for mode 12h */
BYTE mode12[] = {
	0xe3,0,0x70,4, /* Misc Output, Feature Control, ETC */
	3,1,0xf,0,6, /* Sequencer */

	0x5f,0x4f,0x50,0x82,0x54,
	0x80,0x0b,0x3e,0,0x40,
	0,0,0,0,0,0x59,0xea,0x8c,0xdf,
	0x28,0x0,0xe7,0x4,0xe3,0xff, /* CRT Controller */

	0,0,0,0,0,0,5,0xf,0xff,	/* Graphics Controller */
	0,1,2,3,4,5,0x14,7,0x38,0x39,0x3a,0x3b,0x3c,0x3d,0x3e,0x3f,
	1,0,0xf,0,0 /* Attribute Controller */
};

Thank you everyone for there help