Meaning of bytes in Intel GMA950 private buffer, in VGA text mode

Question

When working on the text screen (mode 3, 80x25) both the usual Video Buffer at B800h and the Linear Frame Buffer (LFB) near the end of the 4GB address space are active. I've found that for each character cell on the display, the LFB uses 8 bytes. The first byte (a) represents the ASCII and the second byte (b) represents the attribute.

On an empty display page these 8 bytes look like:

20h,07h,00h,00h,00h,00h,00h,00h
(a) (b) (c) (d) (e) (f) (g) (h)    

Does anyone know what the extra 6 bytes are used for? I observed that only the first (c) and fifth (g) of these mystery bytes are actually refreshed with values that seem random to me. The other 4 bytes remain at zero, but if I put anything in them it survives even a video mode set.

Answer 1

When the GMA950 operates in text video mode, the Graphics Memory is organized as a list of dwords. The 1st byte of each dword matches a byte in display plane 0, the 2nd byte of each dword matches a byte in display plane 1, and so on...

There can be 8 display pages.

GM + 00000000h : Display page 0
GM + 00004000h : Display page 1
GM + 00008000h : Display page 2
GM + 0000C000h : Display page 3
GM + 00010000h : Display page 4
GM + 00014000h : Display page 5
GM + 00018000h : Display page 6
GM + 0001C000h : Display page 7

There can be 8 fonts loaded.

GM + 00000000h : Font block 0
GM + 00008000h : Font block 4
GM + 00010000h : Font block 1
GM + 00018000h : Font block 5
GM + 00020000h : Font block 2
GM + 00028000h : Font block 6
GM + 00030000h : Font block 3
GM + 00038000h : Font block 7

This is how the first 12 bytes of the Graphics Memory are used:

 /------------------------------------------------> character code 1st cell
 |   /--------------------------------------------> attribute byte 1st cell
 |   |   /----------------------------------------> 1st bit pattern 1st ascii
 |   |   |   /------------------------------------> unused (a)
 |   |   |   |   /--------------------------------> unused (b)
 |   |   |   |   |   /----------------------------> unused (b)
 |   |   |   |   |   |   /------------------------> 2nd bit pattern 1st ascii
 |   |   |   |   |   |   |   /--------------------> unused (a)
 |   |   |   |   |   |   |   |   / ---------------> character code 2nd cell
 |   |   |   |   |   |   |   |   |   /------------> attribute byte 2nd cell
 |   |   |   |   |   |   |   |   |   |   /--------> 3rd bit pattern 1st ascii
 |   |   |   |   |   |   |   |   |   |   |   /----> unused (a)
 |   |   |   |   |   |   |   |   |   |   |   |
00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h,00h

(a) These byte aren't used because they match with an unused bit-plane 3

(b) Not using these bytes is the inevitable consequence of the odd/even operation used in the text video mode, where 2 consecutive character codes in the host memory occupy consecutive even addresses in the display memory. Since the bytes marked with (b) correspond to odd adresses they aren't used.

Answer 2

...private buffer...mystery bytes...

There's nothing secretive about it. If it looks like a linear frame buffer, and if it functions like a linear frame buffer, and if it sits where you would expect a linear frame buffer, then most probably it is a linear frame buffer. Henceforward I'll call it the LFB.

To get the address of the LFB on the GMA950 you can use this code:

mov di, 0018h       ;Offset for GMADR
mov bx, 0010h       ;[15-8] Bus=0, [7-3] Device=2, [2-0] Function=0
mov ax, B10Ah       ;Read PCI dword
int 1Ah
and ecx, F0000000h  ; --> ECX is linear address of the LFB

In the 16-color graphics modes the LFB is organized like so:

 --------------------------------- 1st byte of bit-plane 0
 |   ----------------------------- 1st byte of bit-plane 1
 |   |   ------------------------- 1st byte of bit-plane 2
 |   |   |   --------------------- 1st byte of bit-plane 3
 |   |   |   |   ----------------- 2nd byte of bit-plane 0
 |   |   |   |   |   ------------- 2nd byte of bit-plane 1
 |   |   |   |   |   |   --------- 2nd byte of bit-plane 2
 |   |   |   |   |   |   |   ----- 2nd byte of bit-plane 3
 |   |   |   |   |   |   |   |
00h,00h,00h,00h,00h,00h,00h,00h
(a) (b) (c) (d) (e) (f) (g) (h)

The text video modes use a similar organization and thus the bytes at (c) and (g) are tied to bit-plane 2, meaning they represent bit patterns for the character set. Over are the days with cumbersome access to bit-plane 2 for font manipulation!
I don't know why Intel chose to not put a character code at (e) or an attribute byte at (f), but doesn't it at least bear some resemblance with the Odd/Even scheme?

Now until someone else comes up with a better explanation, you can investigate matters further by:

• Writing to all available display pages and seeing where the IGD puts the character codes and attribute bytes.
• Loading extra fonts (through BIOS) and seeing where the IGD stores these.