5

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.

Ross Ridge
  • 35,323
  • 6
  • 64
  • 105
Sep Roland
  • 20,265
  • 3
  • 36
  • 58
  • 1
    VGA doesn't provide a linear frame buffer. Any linear frame buffer you're accessing would be provided by some sort of extension to VGA (eg. VESA VBE). The VESA VBE standard only supports the linear frame buffer in VESA modes and only in those modes that particular card provides support for a linear frame buffer. VESA doesn't provide any mapping between the VGA memory regions (A0000 to BFFFF) and the linear frame buffer. In non-linear modes the linear frame buffer may not even be present in the physical address space, and the location of buffer can move depending on the mode. – Ross Ridge Mar 28 '16 at 19:46
  • @RossRidge I've tested this on an *Intel Graphics Media Accelerator 950* straight from the DOS prompt without ever going through the VBE interface. The LFB works nonetheless - meaning I can read from it and write to it (and see the screen change). – Sep Roland Mar 28 '16 at 20:35
  • 3
    Yah, so? You found a non-standard extension to VGA. Maybe Intel documents what this region of memory you're using is for and how its used, but probably not. You call it a linear frame buffer, but you unless found it through some documented interface like VESA VBE, Intel probably considers it a private region of device memory for their use only. So should you. – Ross Ridge Mar 28 '16 at 20:50

2 Answers2

4

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.

Sep Roland
  • 20,265
  • 3
  • 36
  • 58
  • 1
    Thanks for the concise answer, especially the explanation for why the odd character bytes go unused. – kiwidrew Jan 08 '20 at 08:10
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.
Fifoernik
  • 9,411
  • 1
  • 18
  • 26
  • 1
    Except it doesn't look like a linear frame buffer, it has gaps between characters. Gaps that you're forced to speculate on and can't fully explain. According to your bit-plane graphics mode theory they should be 2 bytes long instead of 6. Ironically, the standard and well defined CGA-compatible frame buffer does have the linear layout you'd expect. Which begs the question, why fool around with this undocumented region of memory that only sort of resembles a linear frame buffer, if there's a documented linear frame buffer at B8000h available for you to use? – Ross Ridge Apr 01 '16 at 17:56
  • @RossRidge Why are you so uninquisitive? My "bit-plane graphics mode theory" is far from theory, it's practice. Everything I wrote is fact, no speculation involved. You should get over your aversion to calling this memory region a linear frame buffer. – Fifoernik Apr 02 '16 at 13:54
  • You're only speculating that the layout being using might be somehow related to the 16-colour graphics mode layout you described. You haven't provided any facts on how the extra 6 bytes are actually used. You haven't actually answered the question. – Ross Ridge Apr 02 '16 at 19:20
  • 1
    @Fifoernik Thanks for your answer. In retrospect I could have known that the bytes at (c) and (g) had to be bit patterns. I had already observed that they appeared in clusters every 128 bytes. – Sep Roland Apr 10 '16 at 14:18