OSDev.org

Hi,

I am currently implementing a basic VBE driver and was just wondering more about how VESA works at a hardware level.

The way I understand it, a BIOS programmer adds support for VESA within the BIOS space. Whatever graphics card you are using, the OS can then play nicely with the basic functions of that card. But I believe if I want to use anything above basic VGA in my OS, I would have to write a separate driver for each graphics board.

So how does the BIOS programmer do this? Surely they don't implement a different driver for each video card available. I guess there must be some kind of standard that every graphics card manufacturer follows to enable VESA too? If that is the case, why can't this same level of access be used by OS devvers to provide SVGA support rather than going via real mode interrupts to get and set video modes?

If there are any references where I can read up on this, or anyone has the answers, it will be much appreciated. I've gone for the theory section as I'm not intending to implement anything differently based on the answers - just interested!

Cheers,
Adam

AJ wrote:I am currently implementing a basic VBE driver and was just wondering more about how VESA works at a hardware level.

It doesn't really, it works at the software level. There's a bit of simple hardware support, but that's not VBE-specific.

The way I understand it, a BIOS programmer adds support for VESA within the BIOS space. Whatever graphics card you are using, the OS can then play nicely with the basic functions of that card. But I believe if I want to use anything above basic VGA in my OS, I would have to write a separate driver for each graphics board.

So how does the BIOS programmer do this? Surely they don't implement a different driver for each video card available.

Yes, a different driver is implemented for each video card, or at least for every family of video cards that supports VBE. However, this isn't done by the regular BIOS programmers but by programmers employed by the video card manufacturer.

I guess there must be some kind of standard that every graphics card manufacturer follows to enable VESA too? If that is the case, why can't this same level of access be used by OS devvers to provide SVGA support rather than going via real mode interrupts to get and set video modes?

From what I understand, when the BIOS initializes the system and finds the video card, it loads a video BIOS from the card to 0xC0000 (IIRC). It then calls a function in there to initialize it. That function may hook interrupt 10h to support VBE functionality.

If there are any references where I can read up on this, or anyone has the answers, it will be much appreciated. I've gone for the theory section as I'm not intending to implement anything differently based on the answers - just interested!

I'm not sure where this information can be found [1], but what it comes down to as an OS developer is that if you want to use VBE, you have to use real mode interrupts, v86-mode interrupts, or one of the protected mode interfaces.

[1] Though a bit of it can be found at the top of the Wikipedia page on VBE.

OK - thanks for the answer.

I guess I was also struggling to see how all those different drivers could fit in BIOS space, but if some kind of firmware is copied from the video card to 0xC0000, I suppose that would explain it. All that would have to fit in the BIOS space would be interface code.

Cheers,
Adam

Do you have this doc ? http://www.vesa.org/public/VBE/vbe3.pdf

From what I understand, when the BIOS initializes the system and finds the video card, it loads a video BIOS from the card to 0xC0000 (IIRC). It then calls a function in there to initialize it. That function may hook interrupt 10h to support VBE functionality.

technically, the BIOS code isnt copied to 0xC0000, instead its already at that location (the code is located in ROM/EEPROM on the video card, and that ROM chip is mapped to location 0xC0000)

and there is a BIOS video code located in the system ROM chip, but its extremely minimal, and doesnt support everything (iirc this code doesnt support anything more than CGA, and may not even be completely present on modern systems) this code is, of course, relocated within the 0xE0000-0xFFFFF range belonging to the system BIOS, and the BIOS initially loads this address to the int 10 video handler, but then it checks for RMode expansion cards, by looking for a special signature byte within the add-on ROM located in address range 0xC0000-0xE0000, when it finds the signature bytes, then it knows there is valid ROM at that location, and calls the initialization code, which replaces the int 10 handler with its own code (located in the add-on ROM chip -- normally, VGA ROM is located at 0xC0000, but other chips can be anywhere within that range, and older add-on cards which relied on this for loading drivers/hooking ints/etc would have dip-switches on the card which could change the address of the ROM chips, to avoid using an address already used by another card)