Bochs Graphics Adaptor in 4 bits-per-pixel mode

[Walling]

Hi,

I want to share some of my experiments. I'm playing around with Bochs Graphics Adaptor for the moment. I've got most of it working. In 8, 15, 16, 24 and 32 BPP modes it behaved like I expected, but I stumbled upon a few funny things in 4 BPP mode.

Initially I believed the 4 BPP mode would have a memory layout like this:

Code: Select all

Color bit: 3 2 1 0 3 2 1 0   3 2 1 0 3 2 1 0   3 2 1 0 3 2 1 0   3 2 1 0 3 2 1 0
          ,-------.-------. ,-------.-------. ,-------.-------. ,-------.-------.
          |MSB X X|X X LSB| |X X X X|X X X X| |X X X X|X X X X| |X X X X|X X X X|
          `-------'-------' `-------'-------' `-------'-------' `-------'-------'
           Pixel 1 Pixel 0   Pixel 3 Pixel 2   Pixel 5 Pixel 4   Pixel 7 Pixel 6

Color bit: 3 2 1 0 3 2 1 0   3 2 1 0 3 2 1 0   3 2 1 0 3 2 1 0   3 2 1 0 3 2 1 0
          ,-------.-------. ,-------.-------. ,-------.-------. ,-------.-------.
          |X X X X|X X X X| |X X X X|X X X X| |X X X X|X X X X| |X X X X|X X X X|
          `-------'-------' `-------'-------' `-------'-------' `-------'-------'
           Pixel 9 Pixel 8   Pixel11 Pixel10   Pixel13 Pixel12   Pixel15 Pixel14

Ie. using a half byte per pixel. I couldn't be more wrong and naive. It didn't work. Actually it gave some wierd images with a lot of vertical lines. I went ahead to read the wiki here and here. Of course it sounds like a lot of hassle splitting up the color bits of a single pixel to 4 different planes, but it just requires some coding. But again, it didn't work. Instead I ended of with my drawing multiple times on the screen in various colors. What I've found out is that the memory layout of BGA in 4 BPP mode is like this:

Code: Select all

           Color bit 0       Color bit 1       Color bit 2       Color bit 3
          ,---------------. ,---------------. ,---------------. ,---------------.
          |MSB X X X X LSB| |X X X X X X X X| |X X X X X X X X| |X X X X X X X X|
          `---------------' `---------------' `---------------' `---------------'
    Pixel: 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7

           Color bit 0       Color bit 1       Color bit 2       Color bit 3
          ,---------------. ,---------------. ,---------------. ,---------------.
          |X X X X X X X X| |X X X X X X X X| |X X X X X X X X| |X X X X X X X X|
          `---------------' `---------------' `---------------' `---------------'
    Pixel: 8 9 101112131415  8 9 101112131415  8 9 101112131415  8 9 101112131415

Ie. byte 0 represents 8 pixels in plane 0, byte 1 represents the same 8 pixels in plane 1, byte 2 is plane 2, byte 3 is plane 3, byte 4 is plane 0 (just the next 8 pixels), etc.

Is that normal behaviour or is it a bug in BGA? On the vgabios news site (updated some time in 2006??) they say they fixed a lot of bugs relating to 4 BPP, but maybe they newer really got it right?

When that worked I also wanted to play with the DAC palette. I already got it to work nicely in 8 BPP mode, where you have 256 colors. If you draw pixel with the value X you have to update DAC palette entry no. X. Plain and simple. But not in 4 BPP mode! Here is a table representing pixel values and their DAC palette entry, when using BGA in 4 BPP mode:

Code: Select all

  Pixel value:  DAC palette entry:
  ------------  ------------------
            0    0
            1    1
            2    2
            3    3
            4    4
            5    5
            6   20  <-- how wierd is that?
            7    7
            8   56
            9   57
           10   58
           11   59
           12   60
           13   61
           14   62
           15   63

I made a test drawing with colors extracted from DAC (converted into 8 bit using formula x*255/63 because DAC use 6 bit colors): screenshot.

Maybe I should add this info to the wiki on Bochs VBE extensions.

[Combuster]

A framebuffer doesn't usually have planes, hence the 16-color mode is fanned out over 4 bytes rather than one which is indexed with a special VGA register.
Ironically, you can get a real VGA in the first mode you listed (see the VGA hardware article you mentioned) but AFAIK bochs won't do that.

As for the color, I guess its the EGA palette that's messing you up. I don't know the original values by hard so I can check it for sanity. I know for one that I never bothered to do the color logic for the VGA Hardware article

[Walling]

A framebuffer doesn't usually have planes, hence the 16-color mode is fanned out over 4 bytes rather than one which is indexed with a special VGA register.

That makes sense.

Ironically, you can get a real VGA in the first mode you listed (see the VGA hardware article you mentioned) but AFAIK bochs won't do that.

Too bad, I think that mode is easier to understand.

As for the color, I guess its the EGA palette that's messing you up. I don't know the original values by hard so I can check it for sanity. I know for one that I never bothered to do the color logic for the VGA Hardware article

Thank you. This helped me doing some Google searches and I found this:

In this mode, one bit from each of the four 8-bit planes in the 32-bit memory is used to form a 16 color value. This is shown in the diagram below, where the most significant bit of each of the four planes is shifted out into a pixel value, which is then sent to the attribute controller to be converted into an index into the DAC palette.

Unfortunately the link to "Attribute Controller Operation -- details on the conversion of sequenced display data into DAC input. (WIP)" is broken. But the page on Attribute Controller Registers exists and how to access attribute the registers. So I managed to change the palette by accessing the attribute controller. Here is the code:

Code: Select all

void attr_controller_set_palette(int pixel_color, int dac_palette_index) {
    if (pixel_color < 0x0 || pixel_color > 0xF) return;
    if (dac_palette_index < 0x0 || dac_palette_index > 0x3F) return;
    const int input_status_1_register = 0x3DA;
    const int address_data_register   = 0x3C0;
    // Reset the flip-flop in attribute controller. Now it expects an adress.
    inb(input_status_1_register);
    // Read the current address and save it.
    int old_address = inb(address_data_register);
    // Write the address we want to change the value for.
    outb(address_data_register, pixel_color);
    // Write the new value.
    outb(address_data_register, dac_palette_index);
    // Write the old address. (to commit the data write?)
    outb(address_data_register, old_address);
}

The attribute controller also has other nice registers, like the Overscan Palette Index. I wish I had a CRT monitor to play with.

[Combuster]

There is an in-depth discussion about the AC in Michael Abrash Graphics Programming Black Book (chapter 33). Google for a free copy

[Walling]

There is an in-depth discussion about the AC in Michael Abrash Graphics Programming Black Book (chapter 33). Google for a free copy

I downloaded it and it's great. Thank you.

[djmauretto]

Ciao
If you want learn about 4bpp graphic chech my vesa info utility here
http://forum.osdev.org/viewtopic.php?f= ... 9&start=30
Ciao

[jal]

What I've found out is that the memory layout of BGA in 4 BPP mode is like this:

Code: Select all

           Color bit 0       Color bit 1       Color bit 2       Color bit 3
          ,---------------. ,---------------. ,---------------. ,---------------.
          |MSB X X X X LSB| |X X X X X X X X| |X X X X X X X X| |X X X X X X X X|
          `---------------' `---------------' `---------------' `---------------'
    Pixel: 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7

           Color bit 0       Color bit 1       Color bit 2       Color bit 3
          ,---------------. ,---------------. ,---------------. ,---------------.
          |X X X X X X X X| |X X X X X X X X| |X X X X X X X X| |X X X X X X X X|
          `---------------' `---------------' `---------------' `---------------'
    Pixel: 8 9 101112131415  8 9 101112131415  8 9 101112131415  8 9 101112131415

Ie. byte 0 represents 8 pixels in plane 0, byte 1 represents the same 8 pixels in plane 1, byte 2 is plane 2, byte 3 is plane 3, byte 4 is plane 0 (just the next 8 pixels), etc.

Is that normal behaviour or is it a bug in BGA?

This is normal chained-plane behaviour. It is also used for mode 13h, compared to mode X where the bytes are actually in different planes.

On the vgabios news site (updated some time in 2006??) they say they fixed a lot of bugs relating to 4 BPP

I'm not sure vgabios has anything to do with it, as the BGA is the emulated hardware, not the BIOS.

When that worked I also wanted to play with the DAC palette. I already got it to work nicely in 8 BPP mode, where you have 256 colors. If you draw pixel with the value X you have to update DAC palette entry no. X. Plain and simple. But not in 4 BPP mode!

As you have already found out, there's some EGA compatability stuff kicking in :).

Maybe I should add this info to the wiki on Bochs VBE extensions.

I created that page, so please add any information you can :).


JAL

[Walling]

Of course vgabios has nothing to do with it. Thank you for pointing that out to me.

I have added some information on the wiki about Bochs Graphics Adaptor. I hope you like it.

[jal]

I have added some information on the wiki about Bochs Graphics Adaptor. I hope you like it.

Yeah cool, nice images. Thanx.


JAL