---[ Graphics: VESA Bios Extensions Part I ]----------[05/10/2008]---
by Timothy Trussell
---[ Where We Are ]--------------------------------------------------
My previous three series of columns, Graphics of the First, Second
and Third Kinds, all utilized the same video mode, 13h, working with
the 320x200x256 contiguous memory, single plane resolution available
on all VGA cards.
---[Note]------------------------------------------------------------
As with my previous columns, the code for this column will be written
for the 32Forth system - the DOS DPMI version of Rick van Norman's
OS2FORTH package, available on the Taygeta Scientific site, which
can be downloaded from the following address:
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/OS-2/
My GotFK, GotSK and GotTK columns are also archived at this address.
--------------------------------------------------------[End Note]---
The next logical step would be to cover the Mode X resolutions, that
Michael Abrash introduced to the world in his Dr. Dobbs Journal
columns in @1991, and which I *have* been working on a library of, to
use with Forth. However, Mode X will have to wait for a while, as
the direction of my research has required the development of the
tools needed for the higher resolutions available from my video card.
---[ Beyond Mode 13h and Mode X ]------------------------------------
The next higher resolutions include the 640x480, 800x600, 1024x768
and 1280x1024 modes.
These modes are capable of displaying a vast number of colors, from
the basic 256 colors we have in Mode 13h, stepping up to 32,768 color
15-bit mode, 65,536 color 16-bit mode, 16,777,216 color 24-bit mode,
and the full-bore 32-bit mode (with lots more than 16 million).
We will continue to work with the 8-bit, 256-color modes here.
There are three basic methods of accessing the video memory for these
modes:
1. BIOS
The easiest method of plotting pixels to these modes, and by far
the slowest possible way to do it. Been there. Done that. It's
a new millenium.
The second and third methods involve working with the VESA BIOS, that
is included in your (modern) VGA video card. I have references that
indicate that from the time when the PCI interface was introduced,
almost all video cards from that time on have the VESA interface in
their on-board BIOS systems.
2. Bank Switching
This uses a pair of "windows" that let you work with the video
memory in small slices - from 4096 to 65536 bytes per slice,
depending on the specifications and capabilties of the card.
The VGA registers have to be programmed to change where in
video memory the window is pointing, so that the program can
access more than the initial 64k of video memory.
As you might guess, there can be a lot of VGA register
programming involved, and this - by itself - inherently slows
down program execution.
For reference, the 640x480x256 mode is an array of 307,200 bytes
consisting of four 65,536-byte banks of memory, and 45,056 bytes
of a fifth bank.
Something as simple as plotting a line from the top, left (0,0)
coordinate to the bottom right (639,479) coordinate is now
complicated by the fact that the PutPixel routine will have to
check - FOR EACH PIXEL - if it is necessary to change to a new
window segment in the video bank mapping, when plotting the
pixel data directly to the video memory.
A cleverly coded BlitBuffer routine can minimize the overhead
that is involved by transferring complete banks, one after the
next, with only a single reprogramming call per bank being
copied from a double buffer in main memory.
3. Linear Frame Buffer (LFB)
This method involves arranging the video card display memory so
that it is mapped into the physical address space of the
computer's memory. Effectively, in a 32-bit programming
environment, the video display memory becomes one large array
which can be accessed as easily as the video memory of the
standard Mode 13h resolution - or a double buffer array.
This column will concentrate on the third method, the Linear Frame
Buffer.
---[ The Linear Frame Buffer ]---------------------------------------
The LFB lets you access your video card memory as a single, large
array, without the hassles involved in bank switching.
In our 32-bit programming environment, we are then able to plot
graphics data as easily as we could in Mode 13h, without requiring
any further VGA register manipulations once the graphics mode has
been initialized - unless we want to (like, for palettes and such).
My video card has 256 megabytes of memory on it, so implementing the
LFB can get the entire 256 megs mapped directly into the CPU's memory
map.
Even though I will only be using a small amount of the available
memory (1024x768=768432 bytes), the rest could be used as double
buffers, texture maps, a RAM drive, or whatever else I want (during
the time my program has control of the video card).
To do this requires an interface to the VESA Bios Extensions that
are part of the video card BIOS of (most) VGA cards.
My research into the subject of implementing the VBE includes the
following article written by Vertigo in 1997:
+--[ VGOVBE20.TXT ]------------------------------[Star of Extract]--+
| |
| Vesa 2.0 implementation, activation, and just plain how it works |
| |
|-------------------------------------------------------------------+
| |
| Doc by: Vector/Vertigo |
| |
| revision history: |
| |
| 24/03/97 v1.0 - Initial version |
| |
| |
+--[ INTRODUCTION ]-------------------------------------------------+
| |
| The reason of this tut is because lately the trend is been moving |
| on to Vesa 2.0. Vesa 2.0 is a standard that enables all cards to |
| be able to do certain acts, using the same exact functions. These |
| commands are quite basic, but very powerful. One can use high |
| resolutions and high colors, just as easy as writing to the normal|
| VGA mode 13h. |
| |
| Unfortunately, there is no good documentation out there on how to |
| set the Vesa 2.0 modes (which are a little harder to set than mode|
| 13h). There are a few libraries out there that give the user the |
| functions to set Vesa 2.0. But obviously most people out there |
| don't want to have to kludge in someone elses libraries just to |
| use this. Also, many people who do manage to set the modes, notice|
| that for some reason their code is very buggy. This is usually |
| because they forgot to set LFB, remap the LFB, check to see if the|
| mode is available, or even if they are setting the right mode. |
| |
+--[ BEFORE WE START ]----------------------------------------------+
| |
| This TXT assumes that you have knowledge of working with VGA mode |
| 13h and protected mode. Also, some knowledge of assembler would be|
| beneficial =). The PMode Header you use MUST support DPMI function|
| 800h. (DOS32 Free Version does not=( ). |
| |
+--[ WHAT WE WANT ]-------------------------------------------------+
| |
| First lets ask ourselves, what would the perfect Vesa 2.0 mode |
| setting library do for us? Well this is what we need: |
| |
| A) Most important, we want usage of an LFB (Linear Frame Buffer). |
| This allows us to write to video memory just as easy as writing|
| to mode 13h. I read in imphobia that All PCI video cards |
| support LFB, and most cards found on 486's support it, so |
| requiring support for bank switched modes should not be |
| neccessary (Thank god). |
| |
| B) We want to remap this LFB to usable memory. Most times the Vesa|
| mode will work without doing this, but we should do this to get|
| 100% compatibility. |
| |
| C) We also want good error detection. Like selecting an |
| unavailable mode, and detecting to see if Vesa 2 is available. |
| |
| D) The interface should be easy & intuitive. Instead of selecting|
| a mode, we should pass an X resolution, Y resolution, and Bit |
| Depth. Not only is this easier, but the Vesa standard states |
| that modes do not need be static. |
| |
| So, in the future, mode 147h may not always be 320*240*32Bits. |
| |
| E) We want to receive as much information as possible. We want to |
| know how many bits are R, G, and B, where they start, and what |
| order they are in. We want to know how much available video |
| memory there is, etc. |
| |
+--[ WHAT TO DO ]---------------------------------------------------+
| |
| Okey, first, lets lay out the functions we are going to make: |
| |
+--[ VBEINFO *vbeDetect(void) ]--- |
| |
| This will detect to see if Vesa 2.0 is available, and return |
| information on the video card. |
| |
+--[ long vbeGetModeInfo(int mode,VBEMODEINFO *bla) ]--- |
| |
| This will get every bit of info on a video mode, resolution, |
| depth, video window stuff, bit organizing, etc... and return it|
| into bla. It will return a 1 on success (Mode found, etc..) and|
| 0 on failure. |
| |
+--[ VBESURFACE *vbeOpen(long X,long Y,long BPP) ]--- |
| |
| This will actually set the mode. It will set an X*Y*BPP mode |
| (BPP being bits per pixel, not bytes). It will return a pointer|
| to VBESURFACE, containing the location of LFB, the actual mode |
| number, bits & bytes per pixel,etc... |
| |
+--[ vbeClose(VBESURFACE *bla) ]--- |
| |
| Of course we need to close the mode. This will get rid of all |
| the VBE stuff, and return us to good old mode 3h. |
| |
+--[ vbeSetScanWidth(long width) ]--- |
| |
| This function will set the logical scanline width of video |
| memory. This way we can set how far we can horizontally scroll.|
| Remember, to set a pixel we use |
| |
| (x+(y*logicalWidth)) |
| not |
| (x+(y*screenWidth)) |
| |
| Unless you make them the same. Which for starting out, we will.|
| We will set this in pixels. |
| |
+--[ long vbeGetScanWidth(void) ]--- |
| |
| This function returns the logical scan width. We will get this |
| in pixels. |
| |
+--[ vbeSetStart(long X,long Y) ]--- |
| |
| This will flip the screen to a certain X and Y position in |
| video memory. Very useful for page flipping and scrolling. |
| |
+--[ vbeGetStart(int *X, int *Y) ]--- |
| |
| This will return the screens logical X & Y position in video |
| memory. |
| |
+--[ vbeVR() and vmode(int mode) ]--- |
| |
| Complimentary functions that wait for the vertical retrace (so |
| there is no screen shearing), and set a standard vga mode |
| respectively. |
| |
+--[ LETS START THE CODE ]------------------------------------------+
| |
| Please note, I will not list the structures here, as they are VERY|
| commented in the code, and quite large. I also won't go through |
| the code step by step, but rather explain what is happening. I |
| would recommend either printing the code up, or having it on hand |
| in another window. |
| |
| Also note that we are going to be calling most functions through |
| real mode, this is because many VBE functions require the real |
| mode trait of passing pointers through ES:DI. |
| |
+--[ DPMI Interrupts ]----------------------------------------------+
| |
| First, I will list the DPMI interrupts we are going to use: |
| (All DPMI interrupts use INT 31h) |
| |
+-= Allocate Dos Memory =- |
| AX = 0100h |
| BX = # of paragraphs to allocate. (A paragraph is 16 bytes) |
|Returns: |
| AX = Real mode segment of Block. |
| DX = Selector for the allocated block. |
| CF = 0 on success,1 on error |
| |
| We are going to need this function to allocate memory for our |
| information blocks. Like VBEINFO and such. |
| |
| |
+-= Free Dos Memory =- |
| AX = 0101h |
| DX = Selector of Block |
|Return |
| CF = 0 on success, 1 on error |
| |
| Free the memory we just allocated of course. |
| |
| |
+-= Simulate Real Mode Interrupt =- |
| AX = 0300h |
| BL = Interrupt number |
| BH = should be kept to 0. |
| CX = Number of words to copy from protected to Real mode |
| stack. |
| ES:DI = selector:offset or RM structure (See RMREGS in asm code)|
|Returns: |
| RMREGS = Filled with return info |
| CF = 1 on error, 0 on success |
| |
| We need this function to make real mode calls from protected mode.|
| |
| |
+-= Physical Address Mapping =- |
| AX = 0800h |
| BX:CX = Physical address we want to map. |
| SI:DI = Size we want to map |
|Return: |
| CF = 0 on success, 1 on error |
| BX:CX = linear address that maps the memory |
| |
| This function is very helpful, because it lets us write to memory |
| we normally wouldn't be able to reach. Since a video card may be |
| crazy enough to put its LFB out there ;). |
| |
| |
+-= Free Physical Address Mapping =- |
| AX = 0801h |
| BX:CX = Address returned by function 0800h. |
|Return |
| CF = 0 on success, 1 on error. |
| |
| Free up the memory we mapped, like the good coders we are =). |
| |
+--[ VBE Interrupts ]-----------------------------------------------+
| |
| Now that we have the DPMI interrupts out of the way, I will list |
| the VBE interrupts we will be using. |
| |
| Remember that some of them will be called through a real mode |
| interrupt. All Vesa interrupts use INT 10h. |
| |
| VBE instructions will always return 04Fh in EAX. if a VBE function|
| does not return this, it means there was an error (VBE driver not |
| loaded and such). |
| |
+-= Return VBE controller Info =- |
| AX = 4F00h |
| ES:DI = Pointer to 512 Allocated bytes to put VbeInfoBlock |
| |
| This function will put a lot of info about the video card into a |
| VbeInfoBlock pointed to by ES:DI (So it needs to be called from |
| real mode). Remember to set VbeSignature inside VbeInfoBlock to |
| 'VBE2'. This will tell the interrupt that we want VBE 2.0 |
| information returned. After the Int is called, 'VESA' should be |
| returned in VBE Signature. To see everything returned, check the |
| VbeInfoBlock structure in the code. |
| |
| |
+-= Return VBE Mode Info =- |
| AX = 4F01h |
| CX = Mode Number |
| ES:DI = Pointer to ModeInfoBlock structure. |
| |
| This will fill up a ModeInfoBlock pointed to by ES:DI (also needs |
| to be called from RM) with all sorts of goodies about the mode in |
| CX. To see everything returned, please check ModeInfoBlock |
| structure inside the code. |
| |
| |
+-= Set VBE Mode =- |
| AX = 4F02h |
| BX = Mode Number. |
| Bits 9-13 must be 0. |
| OR bit 14 with 1 to indicate we want to use LFB. |
| OR bit 15 with 1 to clear video memory. |
| |
| Here is the Actual meat of the mode setting. You will notice that |
| there is no structure passed here. That is because all the info on|
| the mode is obtained through Function 4F01h (Like LFB location and|
| stuff). Notice that since we don't need to pass info through ES:DI|
| this function can be called Directly. |
| |
| |
+-= Get/Set Display Start =- |
| AX = 4F07h |
| CX = First Displayed Pixel Scanline (X pos) |
| DX = First Displayed Scanline (Y pos) |
| BH = Must be kept to 0 |
| BL = 0 to set display, |
| 1 to get display, |
| 80h=Set during V. Retrace. |
|Return: |
| AX = VBE return status (Returned in ALL functions) |
| BH = Always 00h. |
| CX = First Displayed Pixel Scanline (On get display) |
| DX = First Displayed Scanline (On get display) |
| |
| Imagine the screen as a small rectangle, held completely inside a |
| larger rectangle (video memory). This function will move the |
| little rectangle around the big rectangle very smoothly. This |
| allows such things as page flipping,and scrolling at very high |
| speeds. This same function is also used to get the location of the|
| screen in memory, by setting BL to 1. |
| |
+-= Get/Set Logical Display Width =- |
| AX = 4F06h |
| BX = 0 to set width in pixels, 2 to set width in bytes, |
| 1 to get width, 3 to get maximum width. |
| CX = Width in pixels (Or bytes, depending upon BX) to set |
| width. |
|Return: |
| AX = VBE return status (returned in ALL functions) |
| BX = Width in bytes of scanline. |
| CX = Width in pixels. |
| DX = Maximum number of scanlines. |
| |
| This sets or gets the width we want the big rectangle of video |
| memory holding our screen to be. This way we can scroll |
| horizontally as well as vertically. The only problem with this is |
| that finding Y coordinates varies with the logical scanline width.|
| (PixelPos= x+(y*LogicalWidth)) |
| |
+--[ Whats In The Functions ]---------------------------------------+
| |
| It feels good to get all those damn interrupts out of the way. Now|
| I can safely explain all the functions in pseudocode. After this, |
| you should be able to piece the actual ASM code together with this|
| pseudocode quite smoothly. |
| |
+-= VBEINFO *vbeDetect(void) =- |
| start: |
| 'DPMI 100h' Get memory to put vbeInfo Block into |
| Ready RmRegs for 'VBE 4F00h' |
| Put VBE2 into vbeInfo.VbeSignature |
| 'DPMI 300h' Call VBE 4F00h in real mode. |
| Check to see If everything ok. |
| 'DPMI 101h' Free the vbeInfoBlock |
| end: |
| |
+-= int vbeGetModeInfo(int mode,VBEMODEINFO *bla) =- |
| start: |
| call VbeDetect JIK |
| 'DPMI 100h' Get memory to put modeInfo Block into |
| Ready RMREGS for 'VESA 4F01h' |
| 'DPMI 300h' to call VBE 4f01h in real mode |
| move everything from modeInfo Block to bla |
| free modeInfo Block with 'DPMI 101h' |
| return Success |
| End: |
| |
+-= VBESURFACE *vbeOpen(int X,int Y,int BPP) =- |
| start: |
| Make sure we arent already in a vesa mode |
| call VbeDetect JIK |
| 'DPMI 100h' to allocate for ModeInfo block (To check every |
| available mode) |
| Go through all available modes returned by VbeDetect until |
| finding a match |
| OR the Mode found with 4000h to say we want LFB |
| If It worked, map the LFB memory to accessible memory with |
| 'DPMI 800h' |
| Set vbeInit variable so from now on we know a mode is set |
| Make sure logical scanline width is equal to screen scanline |
| width. |
| Set everything in the return structure |
| end: |
| |
+-= vbeClose(VBESURFACE *bla) =- |
| start: |
| Check to see if a vbe mode is set |
| Free the mapped LFB memory with 'DPMI 801h' |
| Set VGA mode 0x3h |
| end: |
| |
|-= Almost direct functions: =--------------------------------------+
| |
+-= vbeSetScanWidth(int width) =- |
| Set logical screen width in pixels, with 'VBE 4F06h' |
| |
+-= int vbeGetScanWidth( void) =- |
| Get logical screen width in pixels, with 'VBE 4F06h' |
| |
+-= vbeGetStart(int *X, int *Y) =- |
| Get logical screen pos with 'VBE 4F07h' |
| |
+-= vbeSetStart(int X, int Y) =- |
| Set logical screen pos with 'VBE 4F07h' |
| |
+--[ VGOVBE20.TXT ]-------------------------------[End of Extract]--+
There we are. And you thought implementing VESA would be hard.
All we need to do now is convert that pseudo-code into Forth code,
and we'll have a working VESA interface.
The first step is to create the required data structures for the VESA
interface information.
Using the EDO (GT Hawkins) nomenclature, we have the following:
S{
{1WORD}-DEF :: .VBESignature \ 'VESA' 4 byte signature
{2BYTE}-DEF :: .VBEVersion \ VBE version number
{1WORD}-DEF :: .OemStringPtr \ Pointer to OEM string
{1WORD}-DEF :: .Capabilities \ Capabilities of video card
{1WORD}-DEF :: .VideoModePtr \ Pointer to supported modes
{2BYTE}-DEF :: .TotalMemory \ Number of 64kb memory blocks
{2BYTE}-DEF :: .OemSoftwareRev \ OEM Software revision number
{1WORD}-DEF :: .OemVendorNamePtr \ Pointer to Vendor Name string
{1WORD}-DEF :: .OemProductNamePtr \ Pointer to Product Name string
{1WORD}-DEF :: .OemProductRevPtr \ Pointer to Product Revision str
222 BYTE* :: .reserved1[] \ Pad to 256 byte block size
256 BYTE* :: .OemDATA[] \ Scratch pad for OEM data
}S vbeinfo-obj
which defines a 512-byte record, which we will fill when performing
the query to see if VESA exists on the system.
---[Note]------------------------------------------------------------
In a 32-bit Forth implementation, a WORD of data is comprised of four
bytes, as opposed to 2 bytes in a 16-bit Forth.
Hence, in the above definition, the .VBESignature element defines a
structure element that is composed of four bytes of data, while the
.VBEVersion element defines a structure element of 2 bytes of data.
Someone attempting to cross-code this for use with a 16-bit Forth
will have to keep this in mind when converting these structures for
use in the 16-bit environment.
--------------------------------------------------------[End Note]---
Next, we have the data structure that defines the information for
each of the different possible modes that VESA can initialize the
video card with:
S{
\ Mandatory information for all VBE revisions:
{2BYTE}-DEF :: .ModeAttributes \ mode attributes
{1BYTE}-DEF :: .WinAAttributes \ window A attributes
{1BYTE}-DEF :: .WinBAttributes \ window B attributes
{2BYTE}-DEF :: .WinGranularity \ window granularity
{2BYTE}-DEF :: .WinSize \ window size
{2BYTE}-DEF :: .WinASegment \ window A start segment
{2BYTE}-DEF :: .WinBSegment \ window B start segment
{1WORD}-DEF :: .WinFuncPtr \ pointer to window function
{2BYTE}-DEF :: .BytesPerScanLine \ bytes per scan line
\ Mandatory information for VBE 1.2 and above:
{2BYTE}-DEF :: .XResolution \ horizontal resolution in pixels
{2BYTE}-DEF :: .YResolution \ vertical resolution in pixels
{1BYTE}-DEF :: .XCharSize \ character cell width in pixels
{1BYTE}-DEF :: .YCharSize \ character cell height in pixels
{1BYTE}-DEF :: .NumberOfPlanes \ number of memory planes
{1BYTE}-DEF :: .BitsPerPixel \ bits per pixel
{1BYTE}-DEF :: .NumberOfBanks \ number of banks
{1BYTE}-DEF :: .MemoryModel \ memory model type
{1BYTE}-DEF :: .BankSize \ bank size in KB
{1BYTE}-DEF :: .#ImagePages \ number of images
{1BYTE}-DEF :: ._Reserved \ reserved for page function
\ Direct Color fields (req'd for direct/6 and YUV/7 memory models)
{1BYTE}-DEF :: .RedMaskSize \ size of red mask in bits
{1BYTE}-DEF :: .RedFieldPos \ bit pos of lsb of red mask
{1BYTE}-DEF :: .GreenMaskSize \ size of green mask in bits
{1BYTE}-DEF :: .GreenFieldPos \ bit pos of lsb of green mask
{1BYTE}-DEF :: .BlueMaskSize \ size of blue mask in bits
{1BYTE}-DEF :: .BlueFieldPos \ bit pos of lsb of blue mask
{1BYTE}-DEF :: .RsvdMaskSize \ size of reserved mask in bits
{1BYTE}-DEF :: .RsvdFieldPos \ bit pos of lsb of reserved mask
{1BYTE}-DEF :: .DirectColorInfo \ direct color mode attributes
\ Mandatory information for VBE 2.0 and above:
{1WORD}-DEF :: .PhysBasePtr \ flat frame buffer address
{1WORD}-DEF :: .OffScreenMemPtr \ start of offscreen memory ptr
{2BYTE}-DEF :: .OffScreenMemSize \ amount of offscreen memory in
\ 1k units
206 BYTE* :: .reserved2[] \ pad to 256 byte block size
}S vbemodeinfo-obj
Finally, we need a data structure that defines the current VESA
mode that has been initialized:
S{
{1WORD}-DEF :: .vbeMode \ VBE mode number
{1WORD}-DEF :: .width \ width of screen
{1WORD}-DEF :: .height \ height of screen
{1WORD}-DEF :: .bits \ bits per pixel
{1WORD}-DEF :: .depth \ bytes per pixel
{1WORD}-DEF :: .^lfb \ pointer to LFB
}S vbesurface-obj
---[ Wrapping Up ]---------------------------------------------------
In Part II of this column, we will code the first module required for
implementing a VESA package, the VBEDetect word.
VBEDetect will tell us if VESA is present on the computer, and fills
the VESAINFO structure that gives us the overall information about
the video card.
------------------------------------------------------[End GVBE01]---
