3

I'm not really wanting to know the ins and outs of VGA but rather the basic principle of how it works (and with integrated graphics), The Intel website says -

enter image description here

So this stolen memory is used as the frame buffer for the VGA adapter and any reads/writes by the VGA graphics controller will be going and coming from there?

Example system with 1MB stolen VGA memory-

enter image description here

So if the above system was running in VGA mode and something was written to the legacy VGA address range (0xA0000 - 0xbffff), what would the process be?

Currently my understanding is that the memory controller would forward it from the CPU to the VGA adapter and then using the graphics translation table (GTT) it would translate this into a physical address at the top of DRAM between the range of 03F0_OOOOh - 03FF_FFFFh?

Would this mean that the legacy VGA memory range 0xA0000 - 0xbffff is not accessible in DRAM as the VGA adapter is using the address range for MMIO?

If anyone could help with those questions it would be greatly appreciated,

Thanks.

RJSmith92
  • 373
  • 1
  • 3
  • 9

1 Answers1

2

it has been quite a few years I wrote something directly for VGA so take that in mind.

The old legacy stuff (CGA/EGA,VGA) mapped all VRAM memory access to two segments only (2 x 64KByte)

  1. graphic modes

    A000:0000 - A000:FFFF

  2. text modes

    B800:0000 - B800:FFFF

    So booth #1 and #2 64 KByte chunks of memory are not directly accessible instead VGA forwards its own memory there. With integrated cards + shared memory they do not have own memory so the chipset takes it from the global memory (usually from the top address space). In that case yes the memory is not accessible by HW (unless some feature of the chipset is used). The memory space in global memory is usually remapped or used for shadow of ROMs

  3. gfx-BIOS

    all legacy gfx cards has its own ``BIOS FLASH/EEPROM/EPROM/PROM` memory. I can't remember exactly how that works but as I remember expansion BIOS area starts around

    C000:0000

    where all BIOS able HW map their BIOS memory (not only gfx cards and not only entire segment in size).

    Now there are many gfx modes that need more than 64KB of VRAM so you call gfx BIOS to map appropriate memory segment to A000:0000 or set it by control registers by IO operations on gfx IO ports. Gfx card remap memory and then you can use it ...

  4. VESA

    VESA VRAM can be accessed in the same way as on old legacy gfx stuff but VESA add LFB (linear frame buffer) support which can map entire VRAM to memory not just single segment and also can use extended memory (on just base it would have not much use).

As I wrote before it has been some years I deal with this stuff so if I am wrong please edit or add comment ...

Spektre
  • 49,595
  • 11
  • 110
  • 380
  • Thanks for the answers. I understand VGA now but still a little confused with GFX-BIOS and VESA. For example if I had a graphics card installed that when enumerated was assigned the legacy VGA address range and E0000000h - EFFFFFFFh, how would the process work when Windows displays it's splash screen before the video driver is loaded? – RJSmith92 Apr 25 '14 at 21:33
  • 2
    CGA/EGA/VGA/VESA do not need any drivers, all is done through their BIOS which is hooked/integrated to interrupt: int 10h. – Spektre Apr 25 '14 at 22:40
  • I meant that Windows uses VESA to display the splash screen before it loads the video driver for the GPU. – RJSmith92 Apr 25 '14 at 23:38
  • yeas I get that, all modern gfx chips still has EGA/VGA/VESA compatibility (otherwise there will be no info screen at startup/boot no boot menus ...) you can communicate with all gfx cards through int 10h in booth real and protected mode without any driver. int10h jumps into gfx BIOS and execute code from it (to set txt/gfx mode, set page to work with remap LFB and much more) with just few asm lines see MS-DOS int 10h docs ... also all this can be done by few IO ports (at least VGA IOs are standardized) – Spektre Apr 26 '14 at 06:58
  • so boot splash screens just set video mode and copy image page by page to A000:0000 – Spektre Apr 26 '14 at 06:59
  • gfx driver on windows goes around BIOS on board the gfx and use its own routines to access non legacy stuff like GPU pipeline ... this is also a bit faster because you do not need to use interrupt which complicated things a little in the past – Spektre Apr 26 '14 at 07:03
  • Thanks for this, appreciate it. Regarding the gfx BIOS, when the BIOS initializes it and maps it to an area between C8000 - E0000, does the gfx BIOS then update the Interrupt Vector Table with its mapped address so that INT 10h interrupts are mapped the to card? – RJSmith92 Apr 26 '14 at 19:32
  • do not know that mechanism but I suspect that it has something to do with Mother-Board BIOS + PnP and non PnP ISA/PCI/PCIe/AGP HW handling. odd that no one join this question ... (maybe because this is more about HW thes Programing) – Spektre Apr 27 '14 at 15:32
  • Thanks anyway. Last question I promise, I was reading that the older VBE standard 1.2 that it used to be implemented in a software driver rather than in the Video BIOS. How would this work when writing software if you don't know if you are using BIOS interrupts to access VBE or calls to a driver? – RJSmith92 Apr 27 '14 at 15:49
  • 1
    the same ... they just use own subroutines instead of int 10h (only use the IO ports of the VESA gfx and for compatbility support also overwrite interrupt 10h) . nice example was UNIVBE which could use custom resolutions and features, even add VESA 2.0 standard to VESA 1.2 cards. it was awesome ... – Spektre Apr 27 '14 at 18:16
  • Sorry for not getting this. So if an application was written to use int 10h for display but was running on a system that was using a display driver for VBE rather than a video bios what would happen? – RJSmith92 Apr 27 '14 at 18:33
  • 1
    the VBE driver overwrite the interrupt vectors to access its own handler. so App calls the int 10h but it do not jump to gfx BIOS instead it jumps to some TSR routine handler of the VBE driver ... – Spektre Apr 27 '14 at 18:38
  • Ahh right now I understand. Thanks for all your help. – RJSmith92 Apr 27 '14 at 19:10