Vesa Bios

The VesaBios, not to be confused with the Vesa Local Bus, was a standard set of interrupt calls offered to 16-bit applications by video cards (or, in some cases, TSRs like Sci-Tech Display Doctor). Programs -- mostly 16-bit DOS programs and 32-bit ones using DPMI -- made interrupt calls with registers loaded with certain values, and they could thereby find out what video modes were available, set one of them, and get the physical address of the frame buffer (which could then be converted to a usable address with a DPMI call). Many DJGPP programs and libraries used VESA to do graphics. Many DOS games, too.

VesaBios was a standard created by the Video Electronics Standards Association (http://www.vesa.org/) and implemented by a wide variety of video card manufacturers. By enabling that standard set of calls, manufacturers made it unnecessary for many applications to know details about how the cards' registers were laid out.

Actually, the general idea of a BIOS is pretty cool; if there were a standard CPU or at least a standard instruction set, then every piece of hardware could include its own drivers in ROM, and thus OSes wouldn't need to include drivers, and the drivers would be available to every OS in a standard way. (Doesn't OpenFirmware do this?)

Now we're all supposed to be good Windows citizens and use DirectDraw.

There is a project called VdmSound which adds a Sound Blaster emulation to the DOS boxes in all flavors of Windows NT. The author says he might be able to expand it to emulate a VesaBios as well. It will do this through DirectDraw.

DosBox supports some VESA graphics.

Linux is capable of accessing the VesaBios. The Linux community at first rejected the VesaBios standard because it was 16-bit. Later, early versions of the x86 "FrameBuffer console" in Linux worked by issuing the necessary calls to the VesaBios while the boot-loader was still in 16-bit mode. The Vesa 3.0 standard was an effort to make the VesaBios more useful from 32-bit protected mode code and operating systems, and today SVGALib can access cards in a "VESA mode." I think there is also a VESA X11 driver.

Linux now supports VESA through the FrameBuffer device, /dev/fb0.

VesaBios supported one feature that is not supported by DirectDraw: hardware scrolling. There would be a system call to set a graphics mode where the "logical screen size" was larger than the "physical screen size." For example, you could set a physical screen size of 800x600 but a logical screen size of 900x700. Then there was another system call to set the "origin" of the display. Set it to (0,0) and you could see everything from (0,0) to (799,599), but set it to (100,100) and you could see everything from (100,100) to (899,699). Some 2D games used hardware scrolling to reduce the amount of drawing they had to do when the player moved left and right.

There is another reason why this is interresting : in order to compute the offset of one pixel, you have to compute x+y*logical_width. The multiplication is slow compared to the addition, therefore a logical_width that is an exponent of two is nice (just shift, don't multiply). Yet another good reason to distinguish between logical and physical size is when you do windowing : you can fully describe a sub-window in a larger window or physical screen by adding an offset and a pitch (logical size) to the good old (width,height) information.

To my knowledge, DirectDraw does not support hardware scrolling: the logical screen size must match the physical screen size. This is true even though (and perhaps because) Windows seems to use hardware scrolling itself. You can prove that Windows is using it this way: if your Windows desktop is 1600x1200, and your game switches to 640x480 while staying at the same color depth, then Windows will basically set the physical screen size to 640x480 but leave the logical screen size at 1600x1200. DirectDraw returns a "pitch" which is basically the number of bytes you should add to a pointer to move down one pixel to the next scan line. In my experience, this pitch is always equal to your original desktop width. In bytes.

However, this limitation may not be that big of a factor anymore. In DirectX 9, you aren't going to get direct access to the frame buffer anymore. What you will have to do instead is kind of interesting:

You create a big texture and draw on that.
To update the screen, you use Direct3D (or OpenGL, it doesn't matter) to draw one texture-mapped polygon, a rectangle as big as the screen which bears that texture.
If you want to do Vesa-style scrolling, just make the texture and its polygon larger than the screen, and scroll around by displacing the polygon.
As an added bonus, you can not only do hardware scrolling, but hardware scaling. This means your programs can use "graphics resolutions" that aren't supported in the hardware, and the hardware will scale it with anti-aliasing, just like on a laptop.
You can also do hardware rotation and perspective if you're into cheap video effects like rotating your screen, flipping it over in 3-D, etc.
If you have two screens (in memory), you can use hardware alpha blending to smoothly fade from one to the other.
In Longhorn (now known as Vista), Microsoft plans to display each window as a textured polygon, and Longhorn will support these kinds of cheap 3-D effects. I'm sure it will get very annoying after a while.
Some of these effects are already used in Winamp 3, but you need Windows 2000 or higher to see them.

On modern systems, all this is supposed to be just as fast as the VesaBios used to be.