1 VESA Super VGA Standard
\r
2 Video Electronics Standards Association
\r
3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
4 2150 North First Street, Suite 360 Phone: (408) 435-0333
\r
5 San Jose, CA 95131-2020 Fax: (408) 435-8225
\r
7 Super VGA BIOS Extension
\r
10 Document Version 1.0
\r
15 To standardize a common software interface to Super VGA video adapters in order
\r
16 to provide simplified software application access to advanced VGA products.
\r
20 The standard provides a set of functions which an application program can use
\r
21 to A) obtain information about the capabilities and characteristics of a
\r
22 specific Super VGA implementation and B) to control the operation of such
\r
23 hardware in terms of video mode initialization and video memory access. The
\r
24 functions are provided as an extension to the VGA BIOS video services, accessed
\r
25 through interrupt 10h.
\r
27 VESA Super VGA Standard VS911022-2
\r
31 1. Introduction ................................................. Page 3
\r
33 2. Goals and Objectives ......................................... 4
\r
34 2.1 Video environment information ........................ 4
\r
35 2.2 Programming support .................................. 4
\r
36 2.3 Compatibility ........................................ 5
\r
37 2.4 Scope of standard .................................... 5
\r
39 3. Standard VGA BIOS ............................................ 6
\r
41 4. Super VGA Mode Numbers ....................................... 7
\r
43 5. CPU Video Memory Control ..................................... 9
\r
44 5.1 Hardware design consideration ........................ 9
\r
45 5.1.1 Limited to 64k/128k of CPU address space ..... 9
\r
46 5.1.2 Crossing CPU video memory window boundaries .. 10
\r
47 5.1.3 Operating on data frolm different areas ...... 10
\r
48 5.1.4 Combining data from two different windows .... 10
\r
49 5.2 Different types of hardware windows .................. 11
\r
50 5.2.1 Single window systems ........................ 11
\r
51 5.2.2 Dual window systems .......................... 11
\r
53 6. Extended VGA BIOS ............................................ 12
\r
54 6.1 Status Information ................................... 12
\r
55 6.2 00h - Return Super VGA Information ................... 12
\r
56 6.3 01h - Return Super VGA mode information .............. 14
\r
57 6.4 02h - Set Super VGA mode ............................. 20
\r
58 6.5 03h - Return Super VGA mode .......................... 20
\r
59 6.6 04h - Save/restore Super VGA video state ............. 21
\r
60 6.7 05h - Super VGGA video memory window control ......... 22
\r
61 6.8 06h - Set/Get Logical Scan Line Length ............... 23
\r
62 6.9 07h - Set/Get Display Start .......................... 24
\r
63 6.10 08h - Set/Get DAC Palette Control .................... 25
\r
65 7. Application Example .......................................... 26
\r
67 VESA Super VGA Standard VS911022-3
\r
70 ~~~~~~~~~~~~~~~~~~~~
\r
71 This document contains a specification for a standardized interface to extended
\r
72 VGA video modes and functions. The specification consists of mechanisms for
\r
73 supporting standard extended video modes and functions that have been approved
\r
74 by the main VESA committee and non-standard video modes that an individual VGA
\r
75 supplier may choose to add, in a uniform manner that application software can
\r
76 utilize without having to understand the intricate details of the particular VGA
\r
79 The primary topics of this specification are definitions of extended VGA video
\r
80 modes and the functions necessary for application software to understand the
\r
81 characteristics of the video mode and manipulate the extended memory associated
\r
82 with the video mode.
\r
84 Readers of this document should already be familiar with programming VGAs at the
\r
85 hardware level and Intel iAPX real mode assembly language. Readers who are
\r
86 unfamiliar with programming the VGA should first read one of the many VGA
\r
87 programming tutorials before attempting to understand these extensions to the
\r
90 VESA Super VGA Standard VS911022-4
\r
92 2. Goals and Objectives
\r
93 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
94 The IBM VGA has become a defacto standard in the PC graphics world. A multitude
\r
95 of different VGA offerings exist in the marketplace, each one providing BIOS or
\r
96 register compatibility with the IBM VGA. More and more of these VGA compatible
\r
97 products implements various supersets of the VGA standard. These extensions
\r
98 range from higher resolutions and more colors to improved performance and even
\r
99 some graphics processing capabilities. Intense competition has dramatically
\r
100 improved the price/performance ratio, to the benefit of the end user.
\r
102 However, several serious problems face a software developer who intends to take
\r
103 advantage of these "Super VGA" environments. Because there is no standard
\r
104 hardware implementation, the developer is faced with widely disparate Super VGA
\r
105 hardware architectures. Lacking a common software interface, designing
\r
106 applications for these environments is costly and technically difficult. Except
\r
107 for applications supported by OEM-specific display drivers, very few software
\r
108 packages can take advantage of the power and capabilities of Super VGA products.
\r
110 The purpose of the VESA VGA BIOS Extension is to remedy this situation. Being a
\r
111 common software interface to Super VGA graphics products, the primary objective
\r
112 is to enable application and system software to adapt to and exploit the wide
\r
113 range of features available in these VGA extensions.
\r
115 Specifically, the VESA BIOS Extension attempts to address the following issues:
\r
116 A) Return information about the video environment to the application, and B)
\r
117 Assist the application in initializing and programming the hardware.
\r
119 2.1 Video environment information
\r
121 Today, an application has no standard mechanism to determine what Super VGA
\r
122 hardware it is running on. Only by knowing OEM-specific features can an
\r
123 application determine the presence of a particular video board. This often
\r
124 involves reading and testing registers located at I/O addresses unique to each
\r
125 OEM. By not knowing what hardware an application is running on, few, if any, of
\r
126 the extended features of the underlying hardware can be used.
\r
128 The VESA BIOS Extension provides several functions to return information about
\r
129 the video environment. These functions return system level information as well
\r
130 as video mode specific details. Function 00h returns general system level
\r
131 information, including an OEM identification string. The function also returns
\r
132 a pointer to the supported video modes. Function 01h may be used by the
\r
133 application to obtain information about each supported video mode. Function 03h
\r
134 returns the current video mode.
\r
136 VESA Super VGA Standard VS911022-5
\r
138 2.2 Programming support
\r
140 Due to the fact that different Super VGA products have different hardware
\r
141 implementations, application software has great difficulty in adapting to each
\r
142 environment. However, since each is based on the VGA hardware architecture,
\r
143 differences are most common in video mode initialization and memory mapping.
\r
144 The rest of the architecture is usually kept intact, including I/O mapped
\r
145 registers, video buffer location in the CPU address space, DAC location and
\r
148 The VESA BIOS Extension provides several functions to interface to the different
\r
149 Super VGA hardware implementations. The most important of these is Function
\r
150 02h, Set Super VGA video mode. This function isolates the application from the
\r
151 tedious and complicated task of setting up a video mode. Function 05h provides
\r
152 an interface to the underlying memory mapping hardware. Function 04h enables an
\r
153 application to save and restore a Super VGA state without knowing anything of
\r
154 the specific implementation.
\r
158 A primary design objective of the VESA BIOS Extension is to preserve maximum
\r
159 compatibility to the standard VGA environment. In no way should the BIOS
\r
160 extensions compromise compatibility or performance. Another but related concern
\r
161 is to minimiza the changes necessary to an existing VGA BIOS. Ram, as well as
\r
162 ROM-based implementations of the BIOS extension should be possible.
\r
164 2.4 Scope of standard
\r
166 The purpose of the VESA BIOS Extension is to provide support for extended VGA
\r
167 environments. Thus, the underlying hardware architecture is assumed to be a
\r
168 VGA. Graphics software that drives a Super VGA board will perform its graphics
\r
169 output in generally the same way it drives a standard VGA, i.e. writing directly
\r
170 to a VGA style frame buffer, manipulating graphics controller registers,
\r
171 directly programming the palette, etc. No significant graphics processing will
\r
172 be done in hardware. For this reason, the VESA BIOS Extension does not provide
\r
173 any graphics output functions, such as BitBlt, line or circle drawing, etc.
\r
175 An important constraint of the functionalities that can be placed into the VESA
\r
176 BIOS Extension is that ROM space is severely limited in certain existing BIOS
\r
179 Outside the scope of this VESA BIOS Extension is the handling of different
\r
180 monitors and monitor timings. Such items are dealt with in other VESA fora.
\r
181 The purpose of the VESA BIOS Extension is to provide a standardized software
\r
182 interface to Super VGA graphics modes, independent of monitor and monitor timing
\r
185 VESA Super VGA Standard VS911022-6
\r
187 3. Standard VGA BIOS
\r
188 ~~~~~~~~~~~~~~~~~~~~~~~~~
\r
189 A primary design goal with the VESA BIOS Extension is to minimize the effects on
\r
190 the standard VGA BIOS. Standard VGA BIOS functions should need to be modified
\r
191 as little as possible. This is important since ROM, as well as RAM based
\r
192 versions of the extensions, may be implemented.
\r
194 However, two standard VGA BIOS functions are affected by the VESA extension.
\r
195 These are Function 00h (Set video mode) and Function 0Fh (Read current video
\r
196 state). VESA-aware applications will not set the video mode using VGA BIOS
\r
197 function 00h. Nor will such applications use VGA BIOS function 0Fh. VESA BIOS
\r
198 functions 02h (Set Super VGA mode) and 03h (Get Super VGA mode) will be used
\r
201 However, VESA-unaware applications (such as old Pop-Up programs and other TSRs,
\r
202 or the CLS command of MS-DOS), might use VGA BIOS function 0Fh to get the
\r
203 present video mode. Later it may call VGA BIOS function 00h to
\r
204 restore/reinitialize the old video mode.
\r
206 To make such applications work, VESA recommends that whatever value returned by
\r
207 VGA BIOS function 0Fh (it is up to the OEM to define this number) should be used
\r
208 to reinitialize the video mode through VGA BIOS function 00h. Thus, the BIOS
\r
209 should keep track of the last Super VGA mode in effect.
\r
211 It is recommended, but not mandatory, to support output functions (such as
\r
212 TTY-output, scroll, set pixel, etc.) in Super VGA modes. If the BIOS extension
\r
213 doesn't support such output functions, bit D2 (Output functions supported) of
\r
214 the ModeAttributes field (returned by VESA BIOS function 01h) should be clear.
\r
216 VESA Super VGA Standard VS911022-7
\r
218 4. Super VGA mode numbers
\r
219 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
220 Standard VGA mode numbers are 7 bits wide and presently range from 00h to 13h.
\r
221 OEMs have defined extended video modes in the range 14h to 7Fh. Values in the
\r
222 range 80h to FFh cannot be used, since VGA BIOS function 00h (Set video mode)
\r
223 interprets bit 7 as a flag to clear/not clear video memory.
\r
225 Due to the limitations of 7 bit mode numbers, VESA video mode numbers are 15
\r
226 bits wide. To initialize a Super VGA mode, its number is passed in the BX
\r
227 register to VESA BIOS function 02h (Set Super VGA mode).
\r
229 The format of VESA mode numbers is as follows:
\r
231 D0-D8 = Mode number
\r
232 If D8 == 0, this is not a VESA defined mode
\r
233 If D8 == 1, this is a VESA defined mode
\r
234 D9-D14 = Reserved by VESA for future expansion (= 0)
\r
235 D15 = Reserved (= 0)
\r
237 Thus, VESA mode numbers begin at 100h. This mode numbering scheme implements
\r
238 standard VGA mode numbers as well as OEM-defined mode numbers as subsets of the
\r
239 VESA mode number. That means that regular VGA modes may be initialized through
\r
240 VESA BIOS function 02h (Set Super VGA mode), simply by placing the mode number
\r
241 in BL and clearing the upper byte (BH). OEM-defined modes may be initialized in
\r
244 To date, VESA has defined a 7-bit video mode number, 6Ah, for the 800x600,
\r
245 16-color, 4-plane graphics mode. The corresponding 15-bit mode number for this
\r
248 The following VESA mode numbers have been defined:
\r
252 15-bit 7-bit Resolution Colors 15-bit 7-bit Columns Rows
\r
253 mode mode mode mode
\r
254 number number number number
\r
255 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
256 100h - 640x400 256 108h - 80 60
\r
259 102h 6Ah 800x600 16 10Ah - 132 43
\r
260 103h - 800x600 256 10Bh - 132 50
\r
263 105h - 1024x768 256
\r
265 106h - 1280x1024 16
\r
266 107h - 1280x1024 256
\r
268 VESA Super VGA Standard VS911022-8
\r
270 10Dh - 320x200 32K (1:5:5:5)
\r
271 10Eh - 320x200 64K (5:6:5)
\r
272 10Fh - 320x200 16.8M (8:8:8)
\r
273 110h - 640x480 32K (1:5:5:5)
\r
274 111h - 640x480 64K (5:6:5)
\r
275 112h - 640x480 16.8M (8:8:8)
\r
276 113h - 800x600 32K (1:5:5:5)
\r
277 114h - 800x600 64K (5:6:5)
\r
278 115h - 800x600 16.8M (8:8:8)
\r
279 116h - 1024x768 32K (1:5:5:5)
\r
280 117h - 1024x768 64K (5:6:5)
\r
281 118h - 1024x768 16.8M (8:8:8)
\r
282 119h - 1280x1024 32K (1:5:5:5)
\r
283 11Ah - 1280x1024 64K (5:6:5)
\r
284 11Bh - 1280x1024 16.8M (8:8:8)
\r
286 VESA Super VGA Standard VS911022-9
\r
288 5. CPU Video Memory Windows
\r
289 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
290 A standard VGA sub-system provides 256k bytes of memory and a corresponding
\r
291 mechanism to address this memory. Super VGAs and their modes require more than
\r
292 the standard 256k bytes of memory but also require that the address space for
\r
293 this memory be restricted to the standard address space for compatibility
\r
294 reasons. CPU video memory windows provide a means of accessing this extended
\r
295 VGA memory within the standard CPU address space.
\r
297 This chapter describes how several hardware implementations of CPU video memory
\r
298 windows operate, their impact on application software design, and relates them
\r
299 to the software model presented by the VESA VGA BIOS extensions.
\r
301 The VESA CPU video memory windows functions have been designed to put the
\r
302 performance insensitive, non-standard hardware functions into the BIOS while
\r
303 putting the performance sensitive, standard hardware functions into the
\r
304 application. This provides portability among VGA systems together with the
\r
305 performance that comes from accessing the hardware directly. In particular, the
\r
306 VESA BIOS is responsible for mapping video memory into the CPU address space
\r
307 while the application is responsible for performing the actual memory read and
\r
310 This combination software and hardware interface is accomplished by informing
\r
311 the application of the parameters that control the hardware mechanism of mapping
\r
312 the video memory into the CPU address space and then letting the application
\r
313 control the mapping within those parameters.
\r
316 5.1.1 Limited to 64k/128k of CPU address space
\r
318 The first consideration in implementing extended video memory is to give access
\r
319 to the memory to application software.
\r
321 The standard VGA CPU address space for 16 color graphics modes is typically at
\r
322 segment A000h for 64k. This gives access to the 256k bytes of a standard VGA,
\r
323 i.e. 64k per plane. Access to the extended video memory is accomplished by
\r
324 mapping portions of the video memory into the standard VGA CPU address space.
\r
326 Every Super VGA hardware implementation provides a mechanism for software to
\r
327 specify the offset from the start of video memory which is to be mapped to the
\r
328 start of the CPU address space. Providing both read and write access to the
\r
329 mapped memory provides a necessary level of hardware support for an application
\r
330 to manipulate the extended video memory.
\r
332 VESA Super VGA Standard VS911022-10
\r
334 5.1.2 Crossing CPU video memory window boundaries
\r
336 The organization of most software algorithms which perform video operations
\r
337 consists of a pair of nested loops: and outer loop over rows or scan lines and
\r
338 an inner loop across the row or scan line. The latter is the proverbial inner
\r
339 loop, which is the bottle neck to high performance software.
\r
341 If a target rectangle is large enough, or poorly located, part of the required
\r
342 memory may be with within the video memory mapped into the CPU address space and
\r
343 part of it may not be addressable by the CPU without changing the mapping. It
\r
344 is desirable that the test for remapping the video memory is located outside of
\r
347 This is typically accomplished by selecting the mapping offset of the start of
\r
348 video memory to the start of the CPU address space so that at least one entire
\r
349 row or scan line can be processed without changing the video memory mapping.
\r
350 There are currently no Super VGAs that allow this offset to be specified on a
\r
351 byte boundary and there is a wide range among Super VGAs in the ability to
\r
352 position a desired video memory location at the start of the CPU address space.
\r
354 The number of bytes between the closest two bytes in video memory that can be
\r
355 placed on any single CPU address is defined as the granularity of the window
\r
356 function. Some Super VGA systems allow any 4k video memory boundary to be
\r
357 mapped to the start of the CPY address space, while other Super VGA systems
\r
358 allow any 64k video memory boundary to be mapped to the start of the CPU address
\r
359 space. These two example systems would have granularities of 4k and 64k,
\r
360 respectively. This concept is very similar to the bytes that can be accessed
\r
361 with a 16 bit pointer in an Intel CPU before a segment register must be changed
\r
362 (the granularity of the segment register or mapping here is 16 bytes).
\r
366 If the granularity is equal to the length of the CPU address space, i.e. the
\r
367 least significant address bit of the hardware mapping function is more
\r
368 significant than the most significant bit of the CPU address, then the inner
\r
369 loop will have to contain the test for crossing the end or beginning of the CPU
\r
370 address space. This is because if the length of the CPU address space (which is
\r
371 the granularity in this case) is not evenly divisible by the length of a scan
\r
372 line, then the scan line at the end of the CPU address will be in two different
\r
373 video memory which cannot be mapped into the CPU address space simultaneously.
\r
375 5.1.3 Operating on data from different areas
\r
377 It is sometimes required or convenient to move or combine data from two
\r
378 different areas of video memory. One example of this is storing menus in the
\r
379 video memory beyond the displayed memory because there is hardware support in
\r
380 all VGAs for transferring 32 bits of video data with an 8 bit CPU read and
\r
381 write. Two separately mappable CPU video memory windows must be used if the
\r
382 distance between the source and destination is larger than the size of the CPU
\r
383 video memory window.
\r
385 5.1.4 Combining data from two different windows
\r
387 The above example of moving data from one CPU video memory window to another CPU
\r
388 video memory only required read access to one window and only required write
\r
389 access to the other window. Sometimes it is convenient to have read access to
\r
390 both windows and write access to one window. An example of this would be a
\r
391 raster operation where the resulting destination is the source data logically
\r
392 combined with the original destination data.
\r
394 VESA Super VGA Standard VS911022-11
\r
396 5.2 Different types of hardware windows
\r
398 Different hardware implementations of CPU video memory windows can be supported
\r
399 by the VESA BIOS extension. The information necessary for an application to
\r
400 understand the type of hardware implementation is provided by the BIOS to the
\r
401 application. There are three basic types of hardware windowing implementations
\r
402 and they are described below.
\r
404 The types of windowing schemes described below do not include differences in
\r
407 Also note that is possible for a VGA to use a CPU address space of 128k starting
\r
410 5.2.1 Single window systems
\r
412 Some hardware implementations only provide a single window. This single window
\r
413 will be readable as well as writeable. However, this causes a significant
\r
414 performance degradation when moving data in video memory a distance that is
\r
415 larger than the CPU address space.
\r
417 5.2.2 Dual window systems
\r
419 Many Super VGAs provide two windows to facilitate moving data within video
\r
420 memory. There are two separate methods of providing two windows.
\r
422 5.2.2.1 Overlapping windows
\r
424 Some hardware implementations distinguish window A and window B by determining
\r
425 if the CPU is attempting to do a memory read or a memory write operation. When
\r
426 the two windows are distinguished by whether the CPU is trying to read or write
\r
427 they can, and usually do, share the same CPU address space. However, one window
\r
428 will be read only and the other will be write only.
\r
430 5.2.2.2 Non-overlapping windows
\r
432 Another mechanism used by two window systems to distinguish window A and window
\r
433 B is by looking at the CPU address within the total VGA CPU address space. When
\r
434 the two windows are distinguished by the CPU address within the VGA CPU address
\r
435 space the windows cannot share the same address space, but they can each be both
\r
438 VESA Super VGA Standard VS911022-12
\r
440 6. Extended VGA BIOS
\r
441 ~~~~~~~~~~~~~~~~~~~~~~~~~
\r
442 Several new BIOS calls have been defined to support Super VGA modes. For
\r
443 maximum compatibility with the standard VGA BIOS, these calls are grouped under
\r
444 one function number. This number is passed in the AH register to the INT 10h
\r
447 The designated Super VGA extended function number is 4Fh. This function number
\r
448 is presently unused in most, if not all, VGA BIOS implementations. A standard
\r
449 VGA BIOS performs no action when function call 4Fh is made. Super VGA Standard
\r
450 VS900602 defines subfunctions 00h through 07h. Subfunction numbers 08h through
\r
451 0FFh are reserved for future use.
\r
453 6.1 Status Information
\r
455 Every function returns status information in the AX register. The format of the
\r
456 status word is as follows:
\r
458 AL == 4Fh: Function is supported
\r
459 Al != 4Fh: Function is not supported
\r
460 AH == 00h: Function call successful
\r
461 AH == 01h: Function call failed
\r
463 Software should treat a non-zero value in the AH register as a general failure
\r
464 condition. In later versions of the VESA BIOS Extension new error codes might
\r
467 6.2 Function 00h - Return Super VGA Information
\r
469 The purpose of this function is to provide information to the calling program
\r
470 about the general capabilities of the Super VGA environment. The function fills
\r
471 an information block structure at the address specified by the caller. The
\r
472 information block size is 256 bytes.
\r
474 Input: AH = 4Fh Super VGA support
\r
475 AL = 00h Return Super VGA information
\r
476 ES:DI = Pointer to buffer
\r
478 Output: AX = Status
\r
479 (All other registers are preserved)
\r
481 VESA Super VGA Standard VS911022-13
\r
483 The information block has the following structure:
\r
486 VESASignature db 'VESA' ; 4 signature bytes
\r
487 VESAVersion dw ? ; VESA version number
\r
488 OEMStringPtr dd ? ; Pointer to OEM string
\r
489 Capabilities db 4 dup(?) ; capabilities of the video environment
\r
490 VideoModePtr dd ? ; pointer to supported Super VGA modes
\r
491 TotalMemory dw ? ; Number of 64kb memory blocks on board
\r
492 Reserved db 236 dup(?) ; Remainder of VgaInfoBlock
\r
495 The VESASignature field contains the characters 'VESA' if this is a valid block.
\r
497 The VESAVersion is a binary field which specifies what level of the VESA
\r
498 standard the Super VGA BIOS conforms to. The higher byte specifies the major
\r
499 version number. The lower byte specifies the minor version number. The current
\r
500 VESA version number is 1.2. Applications written to use the features of a
\r
501 specific version of the VESA BIOS Extension, are guaranteed to work in later
\r
502 versions. The VESA BIOS Extension will be fully upwards compatible.
\r
504 The OEMStringPtr is a far pointer to a null terminated OEM-defined string. The
\r
505 string may used to identify the video chip, video board, memory configuration,
\r
506 etc. to hardware specific display drivers. There are no restrictions on the
\r
507 format of the string.
\r
509 The Capabilities field describes what general features are supported in the
\r
510 video environment. The bits are defined as follows:
\r
512 D0 = DAC is switchable
\r
513 0 = DAC is fixed width, with 6-bits per primary color
\r
514 1 = DAC width is switchable
\r
517 The VideoModePtr points to a list of supported Super VGA (VESA-defined as well
\r
518 as OEM-specific) mode numbers. Each mode number occupies one word (16 bits).
\r
519 The list of mode numbers is terminated by a -1 (0FFFFh). Please refer to
\r
520 chapter 2 for a description of VESA mode numbers. The pointer could point into
\r
521 either ROM or RAM, depending on the specific implementation. Either the list
\r
522 would be a static string stored in ROM, or the list would be generated at
\r
523 run-time in the information block (see above) in RAM. It is the application's
\r
524 responsibility to verify the current availability of any mode returned by this
\r
525 Function through the Return Super VGA mode information (Function 1) call. Some
\r
526 of the returned modes may not be available due to the video board's current
\r
527 memory and monitor configuration.
\r
529 The TotalMemory field indicates the amount of memory installed on the VGA
\r
530 board. Its value represents the number of 64kb blocks of memory currently
\r
533 VESA Super VGA Standard VS911022-14
\r
535 6.3 Function 01h - Return Super VGA mode information
\r
537 This function returns information about a specific Super VGA video mode that was
\r
538 returned by Function 0. The function fills a mode information block structure
\r
539 at the address specified by the caller. The mode information block size is
\r
542 Some information provided by this function is implicitly defined by the VESA
\r
543 mode number. However, some Super VGA implementations might support other video
\r
544 modes than those defined by VESA. To provide access to these modes, this
\r
545 function also returns various other information about the mode.
\r
547 Input: AH = 4Fh Super VGA support
\r
548 AL = 01h Return Super VGA mode information
\r
549 CX = Super VGA video mode
\r
550 (mode number must be one of those returned by Function 0)
\r
551 ES:DI = Pointer to 256 byte buffer
\r
553 Output: AX = Status
\r
554 (All other registers are preserved)
\r
556 The mode information block has the following structure:
\r
558 ModeInfoBlock STRUC
\r
560 ; mandatory information
\r
562 ModeAttributes dw ? ; mode attributes
\r
563 WinAAttributes db ? ; window A attributes
\r
564 WinBAttributes db ? ; window B attributes
\r
565 WinGranularity dw ? ; window granularity
\r
566 WinSize dw ? ; window size
\r
567 WinASegment dw ? ; window A start segment
\r
568 WinBSegment dw ? ; window B start segment
\r
569 WinFuncPtr dd ? ; pointer to windor function
\r
570 BytesPerScanLine dw ? ; bytes per scan line
\r
572 ; formerly optional information (now mandatory)
\r
574 XResolution dw ? ; horizontal resolution
\r
575 YResolution dw ? ; vertical resolution
\r
576 XCharSize db ? ; character cell width
\r
577 YCharSize db ? ; character cell height
\r
578 NumberOfPlanes db ? ; number of memory planes
\r
579 BitsPerPixel db ? ; bits per pixel
\r
580 NumberOfBanks db ? ; number of banks
\r
581 MemoryModel db ? ; memory model type
\r
582 BankSize db ? ; bank size in kb
\r
583 NumberOfImagePages db ? ; number of images
\r
584 Reserved db 1 ; reserved for page function
\r
586 VESA Super VGA Standard VS911022-15
\r
588 ; new Direct Color fields
\r
590 RedMaskSize db ? ; size of direct color red mask in bits
\r
591 RedFieldPosition db ? ; bit position of LSB of red mask
\r
592 GreenMaskSize db ? ; size of direct color green mask in bits
\r
593 GreenFieldPosition db ? ; bit position of LSB of green mask
\r
594 BlueMaskSize db ? ; size of direct color blue mask in bits
\r
595 BlueFieldPosition db ? ; bit position of LSB of blue mask
\r
596 RsvdMaskSize db ? ; size of direct color reserved mask in bits
\r
597 DirectColorModeInfo db ? ; Direct Color mode attributes
\r
598 Reserved db 216 dup(?) ; remainder of ModeInfoBlock
\r
601 The ModeAttributes field describes certain important characteristics of the
\r
602 video mode. Bit D0 specifies whether this mode can be initialized in the
\r
603 present video configuration. This bit can be used to block access to a video
\r
604 mode if it requires a certain monitor type, and that this monitor is presently
\r
605 not connected. Prior to Version 1.2 of the VESA BIOS Extension, it was not
\r
606 required that the BIOS return valid information for the fields after
\r
607 BytesPerScanline. Bit D1 was used to signify if the optional information was
\r
608 present. Version 1.2 of the VBE requires that all fields of the ModeInfoBlock
\r
609 contain valid data, except for the Direct Color fields, which are valid only if
\r
610 MemoryModel field is set to a 6 (Direct Color) or 7 (YUV). Bit D1 is now
\r
611 reserved, and must be set to a 1. Bit D2 indicates whether the BIOS has support
\r
612 for output functions like TTY output, scroll, pixel output, etc. in this mode
\r
613 (it is recommended, but not mandatory, that the BIOS have support for all output
\r
614 functions). If bit D2 is 1 then the BIOS must support all of the standard
\r
617 The field is defined as follows:
\r
619 D0 = Mode supported in hardware
\r
620 0 = Mode not supported in hardware
\r
621 1 = Mode supported in hardware
\r
623 D2 = Output functions supported by BIOS
\r
624 0 = Output functions not supported by BIOS
\r
625 1 = Output functions supported by BIOS
\r
626 D3 = Monochrome/color mode (see note below)
\r
627 0 = Monochrome mode
\r
634 VESA Super VGA Standard VS911022-16
\r
636 Note: Monochrome modes have their CRTC address at 3B4h. Color modes have their
\r
637 CRTC address at 3D4h. Monochrome modes have attributes in which only bit 3
\r
638 (video) and bit 4 (intensity) of the attribute controller output are
\r
639 significant. Therefore, monochrome text modes have attributes of off, video,
\r
640 high intensity, blink, etc. Monochrome graphics modes are two plane graphics
\r
641 modes and have attributes of off, video, high intensity, and blink. Extended
\r
642 two color modes that have their CRTC address at 3D4h are color modes with one
\r
643 bit per pixel and one plane. The standard VGA modes 06h and 11h would be
\r
644 classified as color modes, while the standard VGA modes 07h and 0Fh would be
\r
645 classified as monochrome modes.
\r
647 The BytesPerScanline field specifies how many bytes each logical scanline
\r
648 consists of. The logical scanline could be equal to or larger then the
\r
649 displayed scanline.
\r
651 VESA Super VGA Standard VS911022-17
\r
653 The WinAAttributes and WinBAttributes describe the characteristics of the CPU
\r
654 windowing scheme such as whether the windows exist and are read/writeable, as
\r
657 D0 = Window supported
\r
658 0 = Window is not supported
\r
659 1 = Window is supported
\r
660 D1 = Window readable
\r
661 0 = Window is not readable
\r
662 1 = Window is readable
\r
663 D2 = Window writeable
\r
664 0 = Window is not writeable
\r
665 1 = Window is writeable
\r
668 If windowing is not supported (bit D0 = 0 for both Window A and Window B), then
\r
669 an application can assume that the display memory buffer resides at the standard
\r
670 CPU address appropriate for the MemoryModel of the mode.
\r
672 WinGranularity specifies the smallest boundary, in KB, on which the window can
\r
673 be placed in the video memory. The value of this field is undefined if Bit D0
\r
674 of the appropriate WinAttributes field is not set.
\r
676 WinSize specifies the size of the window in KB.
\r
678 WinASegment and WinBSegment address specify the segment addresses where the
\r
679 windows are located in CPU address space.
\r
681 WinFuncAddr specifies the address of the CPU video memory windowing function.
\r
682 The windowing function can be invoked either through VESA BIOS function 05h, or
\r
683 by calling the function directly. A direct call will provide faster access to
\r
684 the hardware paging registers than using Int 10h, and is intended to be used by
\r
685 high performance applications. If this field is Null, then Function 05h must be
\r
686 used to set the memory window, if paging is supported.
\r
688 The XResolution and YResolution specify the width and height of the video mode.
\r
689 In graphics modes, this resolution is in units of pixels. In text modes, this
\r
690 resolution is in units of characters. Note that text mode resolutions, in units
\r
691 of pixels, can be obtained by multiplying XResolution and YResolution by the
\r
692 cell width and height, if the extended information is present.
\r
694 The XCharCellSize and YCharSellSize specify the size of the character cell in
\r
697 The NumberOfPlanes field specifies the number of memory planes available to
\r
698 software in that mode. For standard 16-color VGA graphics, this would be set to
\r
699 4. For standard packed pixel modes, the field would be set to 1.
\r
701 The BitsPerPixel field specifies the total number of bits that define the color
\r
702 of one pixel. For example, a standard VGA 4 Plane 16-color graphics mode would
\r
703 have a 4 in this field and a packed pixel 256-color graphics mode would specify
\r
704 8 in this field. The number of bits per pixel per plane can normally be derived
\r
705 by dividing the BitsPerPixel field by the NumberOfPlanes field.
\r
707 VESA Super VGA Standard VS911022-18
\r
709 The MemoryModel field specifies the general type of memory organization used in
\r
710 this mode. The following models have been defined:
\r
714 02h = Hercules graphics
\r
715 03h = 4-plane planar
\r
717 05h = Non-chain 4, 256 color
\r
720 08h-0Fh = Reserved, to be defined by VESA
\r
721 10h-FFh = To be defined by OEM
\r
723 In Version 1.1 and earlier of the VESA Super VGA BIOS Extension, OEM defined
\r
724 Direct Color video modes with pixel formats 1:5:5:5, 8:8:8, and 8:8:8:8 were
\r
725 described as a Packed Pixel model with 16, 24, and 32 bits per pixel,
\r
726 respectively. In Version 1.2 and later of the VESA Super VGA BIOS Extension, it
\r
727 is recommended that Direct Color modes use the Direct Color MemoryModel and use
\r
728 the MaskSize and FieldPosition fields of the ModeInfoBlock to describe the pixel
\r
729 format. BitsPerPixel is always defined to be the total memory size of the
\r
732 The NumberOfBanks field specifies the number of banks in which the scan lines
\r
733 are grouped. The remainder from dividing the scan line number by the number of
\r
734 banks is the bank that contains the scan line and the quotient is the scan line
\r
735 number within the bank. For example, CGA graphics modes have two banks and
\r
736 Hercules graphics mode has four banks. For modes that don't have scanline banks
\r
737 (such as VGA modes 0Dh-13h), this field should be set to 1.
\r
739 The BankSize field specifies the size of a bank (group of scan lines) in units
\r
740 of 1KB. For CGA and Hercules graphics modes this is 8, as each bank is 8192
\r
741 bytes in length. For modes that don't have scanline banks (such as VGA modes
\r
742 0Dh-13h), this field should be set to 0.
\r
744 The NumberOfImagePages field specifies the number of additional complete display
\r
745 images that will fit into the VGA's memory, at one time, in this mode. The
\r
746 application may load more than one image into the VGA's memory if this field is
\r
747 non-zero, and flip the display between them.
\r
749 The Reserved field has been defined to support a future VESA BIOS extension
\r
750 feature and will always be set to one in this version.
\r
752 The RedMaskSize, GreenMaskSize, BlueMaskSize, and RsvdMaskSize fields define the
\r
753 size, in bits, of the red, green, and blue components of a direct color pixel.
\r
754 A bit mask can be constructed from the MaskSize fields using simple shift
\r
755 arithmetic. For example, the MaskSize values for a Direct Color 5:6:5 mode
\r
756 would be 5, 6, 5, and 0, for the red, green, blue, and reserved fields,
\r
757 respectively. Note that in the YUV MemoryModel, the red field is used for V,
\r
758 the green field is used for Y, and the blue field is used for U. The MaskSize
\r
759 fields should be set to 0 in modes using a MemoryModel that does not have pixels
\r
760 with component fields.
\r
762 VESA Super VGA Standard VS911022-19
\r
764 The RedFieldPosition, GreenFieldPosition, BlueFieldPosition, and
\r
765 RsvdFieldPosition fields define the bit position within the direct color pixel
\r
766 or YUV pixel of the least significant bit of the respective color component. A
\r
767 color value can be aligned with its pixel field by shifting the value left by
\r
768 the FieldPosition. For example, the FieldPosition values for a Direct Color
\r
769 5:6:5 mode would be 11, 5, 0, and 0, for the red, green, blue, and reserved
\r
770 fields, respectively. Note that in the YUV MemoryModel, the red field is used
\r
771 for V, the green field is used for Y, and the blue field is used for U. The
\r
772 FieldPosition fields should be set to 0 in modes using a MemoryModel that does
\r
773 not have pixels with component fields.
\r
775 The DirectColorModeInfo field describes important characteristics of direct
\r
776 color modes. Bit D0 specifies whether the color ramp of the DAC is fixed or
\r
777 programmable. If the color ramp is fixed, then it can not be changed. If the
\r
778 color ramp is programmable, it is assumed that the red, green, and blue lookup
\r
779 tables can be loaded using a standard VGA DAC color registers BIOS call
\r
780 (AX=1012h). Bit D1 specifies whether the bits in the Rsvd field of the direct
\r
781 color pixel can be used by the application or are reserved, and thus unusable.
\r
783 D0 = Color ramp is fixed/programmable
\r
784 0 = Color ramp is fixed
\r
785 1 = Color ramp is programmable
\r
786 D1 = Bits in Rsvd field are usable/reserved
\r
787 0 = Bits in Rsvd field are reserved
\r
788 1 = Bits in Rsvd field are usable by the application
\r
792 Version 1.1 and later VESA BIOS extensions will zero out all unused fields in
\r
793 the Mode Information Block, always returning exactly 256 bytes. This
\r
794 facilitates upward compatibility with future versions of the standard, as any
\r
795 newly added fields will be designed such that values of zero will indicate
\r
796 nominal defaults or non-implementation of optional features (for example, a
\r
797 field containing a bit-mask of extended capabilities would reflect the absence
\r
798 of all such capabilities). Applications that wish to be backwards compatible to
\r
799 Version 1.0 VESA BIOS extensions should pre-initialize the 256 byte buffer
\r
800 before calling Return Super VGA mode information.
\r
802 VESA Super VGA Standard VS911022-20
\r
804 6.4 Function 02h - Set Super VGA video mode
\r
806 This function initializes a video mode. The BX register contains the mode to
\r
807 set. The format of VESA mode numbers is described in chapter 2. If the mode
\r
808 cannot be set, the BIOS should leave the video environment unchanged and return
\r
809 a failure error code.
\r
811 Input: AH = 4Fh Super VGA support
\r
812 AL = 02h Set Super VGA video mode
\r
814 D0-D14 = Video mode
\r
815 D15 = Clear memory flag
\r
816 0 = Clear video memory
\r
817 1 = Don't clear video memory
\r
819 Output: AX = Status
\r
820 (All other registers are preserved)
\r
822 6.5 Function 03h - Return current video mode
\r
824 This function returns the current video mode in BX. The format of VESA video
\r
825 mode numbers is described in chapter 2 of this document.
\r
827 Input: AH = 4Fh Super VGA support
\r
828 AL = 03h Return current video mode
\r
830 Output: AX = Status
\r
831 BX = Current video mode
\r
832 (All other registers are preserved)
\r
836 In a standard VGA BIOS, function 0Fh (Read current video state) returns the
\r
837 current video mode in the AL register. In D7 of AL, it also returns the status
\r
838 of the memory clear bit (D7 of 40:87). This bit is set if the mode was set
\r
839 without clearing memory. In this Super VGA function, the memory clear bit will
\r
840 not be returned in BX since the purpose of the function is to return the video
\r
841 mode only. If an application wants to obtain the memory clear bit, it should
\r
842 call VGA BIOS function 0Fh.
\r
844 VESA Super VGA Standard VS911022-21
\r
846 6.6 Function 04h - Save/Restore Super VGA video state
\r
848 These functions provide a mechanism to save and restore the Super VGA video
\r
849 state. The functions are a superset of the three subfunctions under standard
\r
850 VGA BIOS function 1Ch (Save/restore video state). The complete Super VGA video
\r
851 state (except video memory) should be saveable/restoreable by setting the
\r
852 requested states mask (in the CX register) to 000Fh.
\r
854 Input: AH = 4Fh Super VGA support
\r
855 AL = 04h Save/restore Super VGA video state
\r
856 DL = 00h Return save/restore state buffer size
\r
857 CX = Requested states
\r
858 D0 = Save/restore video hardware state
\r
859 D1 = Save/restore video BIOS data state
\r
860 D2 = Save/restore video DAC state
\r
861 D3 = Save/restore Super VGA state
\r
863 Output: AX = Status
\r
864 BX = Number of 64-byte blocks to hold the state buffer
\r
865 (All other registers are preserved)
\r
868 Input: AH = 4Fh Super VGA support
\r
869 AL = 04h Save/restore Super VGA video state
\r
870 DL = 01h Save Super VGA video state
\r
871 CX = Requested states (see above)
\r
872 ES:BX = Pointer to buffer
\r
874 Output: AX = Status
\r
875 (All other registers are preserved)
\r
878 Input: AH = 4Fh Super VGA support
\r
879 AL = 04h Save/restore Super VGA video state
\r
880 DL = 02h Restore Super VGA video state
\r
881 CX = Requested states (see above)
\r
882 ES:BX = Pointer to buffer
\r
884 Output: AX = Status
\r
885 (All other registers are preserved)
\r
889 Due to the goal of complete compatibility with the VGA environment, the standard
\r
890 VGA BIOS function 1Ch (Save/restore VGA state) has not been extended to save the
\r
891 Super VGA video state. VGA BIOS compatibility requires that function 1Ch
\r
892 returns a specific buffer size with specific contents, in which there is no room
\r
893 for the Super VGA state.
\r
895 VESA Super VGA Standard VS911022-22
\r
897 6.7 Function 05h - CPU Video Memory Window Control
\r
899 This function sets or gets the position of the specified window in the video
\r
900 memory. The function allows direct access to the hardware paging registers. To
\r
901 use this function properly, the software should use VESA BIOS Function 01h
\r
902 (Return Super VGA mode information) to determine the size, location, and
\r
903 granularity of the windows.
\r
905 Input: AH = 4Fh Super VGA support
\r
906 AL = 05h Super VGA video memory window control
\r
907 BH = 00h Select Super VGA video memory window
\r
911 DX = Window position in video memory
\r
912 (in window granularity units)
\r
914 Output: AX = Status
\r
918 Input: AH = 4Fh Super VGA support
\r
919 AL = 05h Super VGA video memory window control
\r
920 BH = 01h Return Super VGA video memory window
\r
925 Output: AX = Status
\r
926 DX = Window position in video memory
\r
927 (in window granularity units)
\r
932 This function is also directly accessible through a far call from the
\r
933 application. The address of the BIOS function may be obtained by using VESA
\r
934 BIOS Function 01h, Return Super VGA mode information. A field in the
\r
935 ModeInfoBlock contains the address of this function. Note that this function
\r
936 may be different among video modes in a particular BIOS implementation, so the
\r
937 function pointer should be obtained after each set mode.
\r
939 In the far call version, no status information is returned to the application.
\r
940 Also, the AX and DX registers will be destroyed. Therefore, if AX and/or DX
\r
941 must be preserved, the application must do so priot to making the far call.
\r
943 The application must load the input arguments in BH, BL, and DX (for set window)
\r
944 but does not need to load either AH or AL in order to use the far call version
\r
947 VESA Super VGA Standard VS911022-23
\r
949 6.8 Function 06h - Set/Get Logical Scan Line Length
\r
951 This function sets or gets the length of a logical scan line. This function
\r
952 allows an application to set up a logical video memory buffer that is wider than
\r
953 the displayed area. Function 07h then allows the application to set the
\r
954 starting position that is to be displayed.
\r
956 Input: AH = 4Fh Super VGA support
\r
957 AL = 06h Logical Scan Line Length
\r
958 BL = 00h Select Scan Line Length
\r
959 CX = Desired width in pixels
\r
961 Output: AX = Status
\r
962 BX = Bytes Per Scan Line
\r
963 CX = Actual Pixels Per Scan Line
\r
964 DX = Maximum Number of Scan Lines
\r
967 Input: AH = 4Fh Super VGA support
\r
968 AL = 06h Logical Scan Line Length
\r
969 BL = 01h Return Scan Line Length
\r
971 Output: AX = Status
\r
972 BX = Bytes Per Scan Line
\r
973 CX = Actual Pixels Per Scan Line
\r
974 DX = Maximum Number of Scan Lines
\r
978 The desired width in pixels may not be achieveable because of VGA hardware
\r
979 considerations. The next larger value will be selected thta will accommodate
\r
980 the desired number of pixels, and the actual number of pixels will be returned
\r
981 in CX. BX returns a value that, when added to a pointer into video memory, will
\r
982 point to the next scan line. For example, in a mode 13h this would be 320, but
\r
983 in mode 12h this would be 80. DX returns the number of logical scan lines based
\r
984 upon the new scan line length and the total memory installed and useable in this
\r
985 display mode. This function is also valid in text modes. In text modes, the
\r
986 application should find out the current character cell width through normal BIOS
\r
987 functions, multiply that times the desired number of characters per line, and
\r
988 pass the value in the CX register.
\r
990 VESA Super VGA Standard VS911022-24
\r
992 6.9 Function 07h - Set/Get Display Start
\r
994 This function selects the pixel to be displayed in the upper left corner of the
\r
995 display from the logical page. This function can be used to pan and scroll
\r
996 around logical screens that are larger than the displayed screen. This function
\r
997 can also be used to rapidly switch between two different displayed screens for
\r
998 double buffered animation effects.
\r
1000 Input: AH = 4Fh Super VGA support
\r
1001 AL = 07h Display Start Control
\r
1002 BH = 00h Reserved and must be 0
\r
1003 BL = 00h Select Display Start
\r
1004 CX = First Displayed Pixel in Scan Line
\r
1005 DX = First Displayed Scan Line
\r
1007 Output: AX = Status
\r
1010 Input: AH = 4Fh Super VGA support
\r
1011 AL = 07h Display Start Control
\r
1012 BL = 01h Return Display Start
\r
1014 Output: AX = Status
\r
1015 BH = 00h Reserved and will be 0
\r
1016 CX = First Displayed Pixel in Scan Line
\r
1017 DX = First Displayed Scan Line
\r
1021 This function is also valid in text modes. In text modes, the application
\r
1022 should find out the current character cell width through normal BIOS functions,
\r
1023 multiply that times the desired starting character column, and pass that value
\r
1024 in the CX register. It should also multiply the current character cell height
\r
1025 times the desired starting character row, and pass that value in the DX
\r
1028 VESA Super VGA Standard VS911022-25
\r
1030 6.10 Function 08h - Set/Get DAC Palette Control
\r
1032 This function queries and selects the operating mode of the DAC palette. Some
\r
1033 DACs are configurable to provide 6-bits, 8-bits, or more of color definition per
\r
1034 red, green, and blue primary color. The DAC palette width is assumed to be
\r
1035 reset to standard VGA 6-bits per primary during a standard or VESA Set Super VGA
\r
1036 Mode (AX = 4F02h) call.
\r
1038 Input: AH = 4Fh Super VGA support
\r
1039 AL = 08h Set/Get DAC Palette Control
\r
1040 BL = 00h Set DAC palette width
\r
1041 BH = Desired number of bits of color per primary
\r
1042 (Standard VGA = 6)
\r
1044 Output: AX = Status
\r
1045 BH = Current number of bits of color per primary
\r
1046 (Standard VGA = 6)
\r
1049 Input: AH = 4Fh Super VGA support
\r
1050 AL = 08h Set/Get DAC Palette Control
\r
1051 BL = 01h Get DAC palette width
\r
1053 Output: AX = Status
\r
1054 BH = Current number of bits of color per primary
\r
1055 (Standard VGA = 6)
\r
1059 An application can find out if DAC switching is available by querying Bit D0 of
\r
1060 the Capabilities field of the VgaInfoBlock structure returned by VESA Return
\r
1061 Super VGA Information (AX = 4F00h). The application can then attempt to set the
\r
1062 DAC palette width to the desired value. If the Super VGA is not capable of
\r
1063 selecting the requested palette width, then the next lower value that the Super
\r
1064 VGA is capable of will be selected. The resulting palette width is returned.
\r
1066 VESA Super VGA Standard VS911022-26
\r
1068 7. Application Example
\r
1069 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
\r
1070 The following sequence illustrates how an application interface to the VESA BIOS
\r
1071 Extension. The hypothetical application is VESA-aware and calls the VESA BIOS
\r
1072 functions. However, the application is not limited to supporting just
\r
1073 VESA-defined video modes. This it will inquire what video modes are available
\r
1074 before setting up the video mode.
\r
1076 1) The application would first allocate a 256 byte buffer. This buffer
\r
1077 will be used by the VESA BIOS to return information about the video
\r
1078 environment. Some applications will statically allocate this buffer,
\r
1079 others will use system calls to temporarily obtain buffer space.
\r
1081 2) The application would then call VESA BIOS function 00h (Return Super VGA
\r
1082 information). If the AX register does not contain 004Fh on return from
\r
1083 the function call, the application can determine that the VESA BIOS
\r
1084 Extension is not present and handle such situation.
\r
1086 If no error code is passed in AX, the function call was successful. The
\r
1087 buffer has been filled by the VESA BIOS Extension with various
\r
1088 information. The application can verify that indeed this is a valid
\r
1089 VESA block by identifying the characters 'VESA' in the beginning of the
\r
1090 block. The application can inspect the VESAVersion field to determine
\r
1091 whether the VESA BIOS Extension ha sufficient functionality. The
\r
1092 application may use the OEMStringPtr to locate OEM-specific information.
\r
1094 Finally, the application can obtain a list of the supported Super VGA
\r
1095 modes by using the VideoModePtr. This field points to a list of the
\r
1096 video modes supported by the video environment.
\r
1098 3) The application would then create a new buffer and call the VESA BIOS
\r
1099 function 01h (Return Super VGA mode information) to obtain information
\r
1100 about the supported video modes. Using the VideoModePtr obtained in
\r
1101 step 2) above, the application would call this function with a new mode
\r
1102 number until a suitable video mode is found. If no appropriate video
\r
1103 mode is found, it is up to the application to handle this situation.
\r
1105 The Return Super VGA mode information function fills a buffer specified
\r
1106 by the application with information describing the features of the video
\r
1107 mode. The data block contains all the information an application needs
\r
1108 to take advantage of the video mode.
\r
1110 The application would examine the ModeAttributes field. To verify that
\r
1111 the mode indeed is supported, the application would inspect bit D0. If
\r
1112 D0 is clear, then the mode is not supported by the hardware. This might
\r
1113 happen is a specific mode requires a certain type of monitor but that
\r
1114 monitor is not present.
\r
1116 4) After the application has selected a video mode, the next step is to
\r
1117 initialize the mode. However, the application might first want to save
\r
1118 the present video mode. When the application exits, this mode would be
\r
1119 restored. To obtain the present video mode, the VESA BIOS function 03h
\r
1120 (Get Super VGA mode) would be used. If a non-VESA (standard VGA or
\r
1121 OEM-specific) mode is in effect, only the lower byte in the mode number
\r
1122 is filled. The upper byte is cleared.
\r
1124 5) To initialize the video mode, the application would use VESA BIOS
\r
1125 function 02h (Set Super VGA mode). The application has from this point
\r
1126 on full access to the VGA hardware and video memory.
\r
1128 VESA Super VGA Standard VS911022-27
\r
1130 6) When the application is about to terminate, it would restore the prior
\r
1131 video mode. The prior video mode, obtained in step 4) above could be
\r
1132 either a standard VGA mode, OEM-specific mode, or VESA-supported mode.
\r
1133 It would reinitialize the video mode by calling VESA BIOS function 02h
\r
1134 (Set Super VGA mode). The application would then exit.
\r
projects / 16.git / blob