By ZKman

Here's what you had to say about last month. Be sure and send us more letters soon!

Pyrus

(Editor's Note: This article uses techniques for SCREEN 13. They may not work in other screen modes)

The following is what I have found out through trial and error (as well as a bit of logical guesswork). While I have found it to work on every machine I have tried it with, do not assume it is so for your machine. Instead, pro- ceed with caution. While none of this should cause major problems (ie. I do not believe it will trash your machine or anything), a wrong step could cause your machine to lock up, forcing you to reboot. Anyway, this is intended for informational purposes only. I cannot be held responsible for the use/abuse of the information contained herein, nor can I be held responsible for any damage done to the person or the machine on which the examples contained in this document are run upon. Just the standard disclaimer to CMA!

If you find this information useful, and choose to include the techniques in your own code, please be kind and mention my name. You don't have to do this (hell, if I mentioned everyone's name I have learned from, that list would be a mile long!), but it would be nice.

I wish to thank Jason Grooms - for guiding my first steps into the wonderful world of assembler (back then, 6809), and to Brent Dill, for showing me how to do strange and crazy stuff with GET/PUT, and a host of other tips. Brent, if your read this, contact me. I'm on the 'Net. I know you are worth your salt to find me. L8r!

Calculating the buffer size for GET/PUT in mode 13:

1. Take the width of the area you are getting (in pixels) and multiply it by the height (in lines). This will give you the total number of bytes in the area for the buffer.

2. Find the total number of WORDs to use by dividing the number of bytes by two. We need the total number of WORDs because the smallest variable type we can use is an integer, which is WORD size (2 bytes).

3. We now have the amount of space needed to store the area we want to GET. But BASIC needs a couple of more pieces of information in order for GET and PUT to operate correctly. These two pieces of information are the width and the height of the image! It needs these two items in order for the PUT routine to know when to stop drawing. So, the width and the height of the image area must be stored with the image data itself. These two values are placed into their own WORDs at the start of the buffer. We must add on two WORDs to accomodate this.

4. We now have the total number of WORDs needed to DIMension an integer array to hold our image data. Because the base of the array starts at zero, we will subtract one from our total number of WORDs to DIMension our array:

	DIM buffer%(# of WORDs)

5. Our buffer data layout looks like so:

	WORD	DESCRIPTION
	----	--------------------------------------------------
	   0	Width, contained in the high byte of the WORD.
		This value is in bits (!), and so must be divided
		by 8 to find out the number of pixels (bytes).
	   1    Height, contained in the high byte of the WORD.
		Value in number of lines.
	   2	Start of data...
	   .
	   .
	   .
	  XX	End of data...

Example:

1. We have a 16x16 sprite. So we need 256 bytes in order to hold an area this big.

2. We need the number of WORDs, so we divide by 2, giving us 128 WORDs.

3. We add two words to accomodate the width and height values needed by PUT, giving us a total of 130 WORDs.

4. We subtract 1, and dimension our array:

	DIM buffer%(129)

5. Our buffer data layout looks like so:

	WORD	DESCRIPTION
	----	--------------------------------------------------
	   0	Width, contained in the high byte of the WORD.
		This value is in bits (!), and so must be divided
		by 8 to find out the number of pixels (bytes).
	   1    Height, contained in the high byte of the WORD.
		Value in number of lines.
	   2	Start of data...
	   .
	   .
	   .
	 129	End of data...

Multiple Image Buffers for GET/PUT:

What was shown above was an example for a simple buffer to hold a single image to be used in GET/PUT. Using the above simple example, we would just do the following

		GET(0,0)-(15,15),buffer%
		PUT(100,100),buffer%,PSET

in order to GET/PUT a single simple image. But what if we needed 30 sprites (say for a game)? We could do this

		DIM buffer1%(129), buffer2%(129),...,buffer30%(129)

then use GET/PUT to move everything around, but this is wasteful, and not very easy to work with. What if we wanted animation? What then?

Fortunately, there is an easy way out, using what is called offsetting. We have a buffer of a set size we are GETing and PUTing with. What isn't being shown is what is called the offset. An offset is a number added to a fixed value to obtain a new start value. When we dimension an array, the start of that array is obtained and kept by BASIC (we can use VARSEG and VARPTR to find it if we wanted to). If we say DIM a%(20), then say a%(2)=15, we have used an offset of 2 from the start of the array and placed 15 at that pos- ition in memory. A similar thing is done by GET/PUT. Note the following:

		DIM buffer%(129)
		GET(0,0)-(15,15),buffer%

is the same as:

		DIM buffer%(129)
		GET(0,0)-(15,15),buffer%(0)

We just didn't use the offset of zero in the first example! What would happen if we did the following?:

		DIM buffer%(129)
		GET(0,0)-(15,15),buffer%(10)

We would get an error. This is because we need 130 WORDs of space for the area we are trying to GET, and we only have a total of 130 WORDs to play with. By trying to put an offset of 10 into the mix, we overrun the end of the array by 10 WORDs! The following would work:

		DIM buffer%(139)
		GET(0,0)-(15,15),buffer%(10)

Now WORD number 10 would hold our width and WORD number 11 our height, and 12 through 139 would hold our data. We could then PUT(100,100),buffer%(10),PSET and everything would work fine. Now what would happen if we PUT(100,100), buffer%(0),PSET? We would either get an error or garbage, because PUT wouldn't have the correct width and height info in the first two WORDs! So, we need to keep track of the size so we know what offsets we can use when GETing and PUTing our images.

Our example is a 16x16 sprite. We would like to have 30 of these for our ultra cool game we are writing. We need 130 WORDs for each of these sprites (2 for width/height, 128 for data), and we want 30 sprites, so we need a buffer that is 3900 WORDs long (130 WORDs x 30 sprites). We know that every 130 WORDs is a new sprite, so that will be our offset. If we set our offset to 0, then we are on the first sprite, 130 is the second, 260 is the third, and so on. The following shows how:

		DIM sprite%(3899)
		spritenum%=2
		GET(0,0)-(15,15),sprite%(spritenum%*130)
		spritenum%=5
		PUT(100,100),sprite%(spritenum%*130),PSET

Before you can put a sprite, you obviously need to GET it, so that PUT has the width/height info to work with. So lines 4 and 5 wouldn't work in our example unless we changed line 2 to "spritenum%=5".

We now have an easy way to GET/PUT a whole mess of sprites on the screen using a single buffer that is easily accessible. We could do simple animation with this system. Say our first five sprites were already in the buffer and they were an animation of some type. To flip through them, we would do the following:

		FOR spritenum%=0 TO 4
		  PUT(100,100),sprite%(spritenum%*130),PSET
		NEXT spritenum%

It is that easy.

Our buffer layout now looks like this, for those interested:

	WORD	DESCRIPTION
	----	--------------------------------------------------
	   0	Width, contained in the high byte of the WORD.
		This value is in bits (!), and so must be divided
		by 8 to find out the number of pixels (bytes).
	   1    Height, contained in the high byte of the WORD.
		Value in number of lines.
	   2	Start of sprite0 data...
	   .
	   .
	   .
	 129	End of sprite0 data...

	 130	Width, contained in the high byte of the WORD.
		This value is in bits (!), and so must be divided
		by 8 to find out the number of pixels (bytes).
	 131    Height, contained in the high byte of the WORD.
		Value in number of lines.
	 132	Start of sprite1 data...
	   .
	   .
	   .
	 259	End of sprite1 data...

	 260	Width, contained in the high byte of the WORD.
		This value is in bits (!), and so must be divided
		by 8 to find out the number of pixels (bytes).
	 261    Height, contained in the high byte of the WORD.
		Value in number of lines.
	 262	Start of sprite2 data...
	   .
	   .
	   .
	 389	End of sprite2 data...

And so on...

The only other thing you need to keep in mind is buffer size versus sprite size. As noted before, a 16x16 sprite needs 130 WORDs in order to store it completely in an array. When you have multiple sprites in an array, there is a limit to the size of your array you can have. This limit is 64K - 65536 bytes, or 32768 WORDs. To find out how many sprites you can store in a single array, divide 32768 by the number of WORDs required for each sprite. Drop any values after the decimal (that is, take the integer, drop the remainder), and this is the maximum number of sprites you can store. For our example of a 16x16 sprite (130 WORDs), this works out to be 252 sprites. Take that number and multiple by the number of WORDs per sprite, subtracting 1, to use for DIMensioning the array: DIM buffer%(32759).

The following table breaks down common sprite sizes and array dimensions:

	Sprite Size  Number  Array Size (in WORDs)
	-----------  ------  ---------------------------------
	   8 x 8       963   34 for sprite, 32741 for array
	  16 x 16      252   130 for sprite, 32759 for array
	  32 x 32       63   514 for sprite, 32381 for array
	  64 x 64       15   2050 for sprite, 30749 for array

If you need more sprites, you can split them over two arrays. Animation and such becomes more difficult to handle, but it can be done.

Also remember, the larger the sprite, the more data the computer has to shove around. Stay away from the 64 x 64 sprites, except for maybe big bosses or such. These things are memory HOGS. The only other limit to be aware of is QBASIC's 160K limit on program AND code size. One buffer of sprites (252 sprites) will eat almost 64K, leaving you with less than 100K to put the rest of your code in! QuickBASIC and PowerBASIC users shouldn't have any problem though. Some of these problems may be overcome by using EMS routines to shove the sprite data into extended memory, though.

GETing and PUTing without The BOX:

If you have ever used GET and PUT, you know that when you PUT, a "box" is left around your image obliterating anything under and around your sprite. This looks very ugly and unprofessional in a game. The following shows the best way to get rid of this problem, using a method called sprite masking.

1. First, for each and every sprite you create, create a "mask" for it. This mask is the same size and shape as the original sprite, only it consists of only two colors, 0 and 255 (or &H0 and &HFF for you hex folks). Color all visible portions of the sprite (those portions you want to obscure the background) with color 0. Color all invisible portions of the sprite (those protions you want the background to show through) with color 255. Remember, you need one mask for each sprite, and this will knock your sprite count down by half, so keep it in mind when designing your game.

2. To display your sprite, simply PUT the mask image down using the AND op- erator, then place the sprite image down using the OR operator. The AND and OR operators are called bitwise boolean operators, and have the following truth tables:

	        AND			OR
	-------------------	-------------------
	IN1	IN2	OUT	IN1	IN2	OUT
	-------------------	-------------------
	0	0	0	0	0	0
	1	0	0	1	0	1
	0	1	0	0	1	1
	1	1	1	1	1	1

These tables basically mean the following. If you take two bits and AND or OR them together, the result equals a 1 or a 0 depending on the inputs and the relationship between them in the truth tables for the operator in question. If you understand this - read on. If you understand this and are 10 - 14 years old, you don't need college (just kidding ;).

Now, for what we are doing, we have a background of different byte values (which consist of a series of bits). Our mask only has two values in it, the byte 0 (00000000 in binary) and the byte 255 (11111111 in binary). Let me show you how the magic works:

   A.	Our Background Image	AND	Mask	=	Result

	11110110		      11111111		11110110
	11110110		      11000011		11000010
	11110110		      11000011		11000010
	11110110		      11000011		11000010
	11110110		      11111111		11110110

  B.	Our Result	       OR      Sprite	=	Result

	11110110		      00000000		11110110
	11000010		      00111100		11222210
	11000010		      00111100		11222210
	11000010		      00111100		11222210
	11110110		      00000000		11110110

If you notice, I have used 2s in place of 1s on the final result to show the example better. Those 2s should really be 1s, so don't let that throw you. Suffice to say, if you look carefully, we have placed our 8 x 5 sprite on the background, without the border showing.

GETing and PUTing without The BOX, method 2:

The next best way to GET and PUT without the box showing, is to simply not draw those pixels in the first place. The only way to do that (short of mod- ifying BASIC itself) is to write your own PUT routine, to skip over any pixel of a defined color (0 in our case). This would have two advantages: Number one, your sprite could be drawn faster because you only set the pixels you need, and number two, you wouldn't double your buffer requirements for sprites because you would only need the sprites, and could eliminate the masks! All sounds good until you try to write the thing in BASIC...it is horribly slow (ok, on a fast system, it runs at an acceptable pace). The only way to get around this is to code it in a lower level language (or at least one that can compile down to a faster version). I have done this, and you can find the results of my labor in the ABC Packets. It is called the Blast! library. It allows you to do the above, and much more. Check it out!

nethersoft@hotmail.com

www.fortunecity.com/skyscraper/terabyte/277

Since about January first, the QBASIC community has gone crazy about Sprite based RPG's. Ever since Dark Crown has been released, everyone's wanted to make an RPG. Everyone from newbies to experienced programmers all want to make the all-new epic RPG to take the QBASIC community by storm. Very few RPG's have been finished since the infamous Darkdread disapeared. The reason is that a lot of programmers are very lazy, and have other things to do. RPG's get put on hold, because programmers don't have time, or get too frusterated by "Out of Memory"or other errors to continue. They are usually not taken off of hold, and the idea of the RPG fades in the programmers mind, after a few hours of work, a demo, and ten screenshots are completed. It's pathetic that programmers with so much potential can fail...

We've talked about why RPG's fail, but not why they are started. I think the reason that RPG's are started, and why programmers like to play them so much is because programmers like to do things themselves. They like to figure out puzzles, make goals, and most of them like epic, (mostly fantasy) stories. And of course, all programmers have a passion for playing video games. If you mix these ingredients together, you've got a person that wants to make their own game with a long, epic fantasy story, make their own decisions, not go through some C++ programmer's courses that he lays out in his order, with a story that can't be different every time you play.

What I'm trying to say is that programmers have personalities and hobbies, and are not copies of the other people in their school that do have personalities. They can make their own decisions, and don't depend on someone else to do things for them. They want to play role playing games because they want to play the role of a character, just like they want to play the role of their lives. They want to make an RPG for the same reason: they want make an epic story where you (the player) make the choices for him or her, and make their own story. And they want to do it on QuickBASIC-their hobby.

Now, if you would excuse me, I have to go work on my brand new, epic RPG that's going to take the world by storm. Or not...

SFB2, a wireframe fighter released on October 4th by Lbt1st is the BEST qbasic fighting game ever. Admittenly, it only was going against fairly old titles like "Stick Fighter" and "Sphere Fighter" (which, when released, was one of the best looking qbasic games!). The engine works very well, the graphics, although improvable, do the job, and the help (Dojo Master) is fairly good.

This game offers quite a lot in the way of new gameplay ideas in a fighter; some have not even been seen in professional titles. The basic way to kill a guy (the object of the game is to kill all 12 other fighters) is to punch and kick him till his health goes down, but that's not the only way to win. Each player has an awareness bar...making a big hit on the opponent causes his bar to go down, but it you try a special move (of which there are many!), your awareness will drop. So, if you just use special "super-attacks" and don't fight up-close, you'll kill yourself before you kill the opponent! Also, you can kill your enemy by knocking him into spikes on the wall or ceiling in some levels. Mucho cool!

Graphically, the game looks ok, but has some problems. First, the engine (SLASH) is an all wireframe (like Groov Buggies). Although doing flat-shading might decrease the speed, Qbasic: the Magazine is sure that the game would still play at a good-framerate with the lambert shading, especially if it was done with the asm codes. Also, the wireframe causes some clipping problems; occasionally, it seems as if you're walking right thru the enemy! The final problem is the text...it's regular, background-destroying SCREEN 12 text...it doesn't look pretty. On the other hand, the animation of the characters is supreme, they look very natural when they punch and kick, almost like mo-cap! The particle engine looks very cool too; lots of little red bloods come out of a guy when you pop 'im (heheh).

SFB2 offers alot in the way of customizability. You can assign attributes to your players hand strength, leg strength, etc. (which changes what specials you have available to you). You can even give your guy a big swinging ponytail! The interface is sort of clunky, though, so it might be hard to figure out the first time around.

SFB2 is a fun QB game, and a must download for anyone interested in seeing how to do a good Qbasic game. It's not the greatest ever, but it's sure to eat up a bit of your time, especially considering the amount of strat guides/cheat codes that are being released for it. A very commendable effort; be sure and pick it up.

With the recent releases of Dash and the evidant obsolesance of Blast!, one might wonder if things could get any more confusing, but alas, Angelo Mottola of Enhanced Creations (WS2) has brought into the scene, his own lib, called DIRECTQB.

This lib is actually quite good, not to mention to auto EMS handling with saves mucho mem, but most of it's functions are quite good, and are basically the same as Dash's.

Dash has a sprite scaler and rotator, and DirectQB is going to have them soon, and you can see the two of them playing catch-up against the other, each making versions of the others' subs. DirectQB's flaw though, is in this newest version, 1.1, where it continually crashed on me when trying to play sounds (but from EMS no less) but I'm sure those will be ironed out in no time.

How does DQB stack up against DASH, well, rather nicely really. The EMS support pushes it's rank up high, and it's potential is staggering, but DASH, I'm sure, will meet the challenge.

But in a direct comparison, here is a small test I preformed, this is not to represent the entire lib's preformance, just a hint of info...

I compared the putting of sprites with DirectQB and DashX, I made an ALL.QLB than contained DQB and DASHX in one. I made a simple 30*30 sprite that was GET'ed normally, and put it at 1,1 using DQB and then DASHX. The loop was similar for both...

a! = timer
for k% = 1 to 20000
'the put, whichever one was being tested
next k%
b! = timer
times! = b! - a!

Both were identical, and both just pasted the sprite directly to the screen, as this was just a test of sprite speed. And here are the results on my P2 MMX 233 comp...

DirectQB: 3.621094 seconds
DashX : 3.132813 seconds

This may be different on other comps, but this is what I got, and since TIMER would have been equally inefficient for both, I regard the results as accurate. I tried running it a few times, and the results were basically the same, with only a changed in the 5th sigdig.

I give, DirectQB a rating of 9 out of 10, and I'm sure it will get that extra point when it has been completed.

(Editors Note: This is a review of Version 1.1: Version 1.11 fixed the bug in the sound player and a font maker is in development independently by 19day)

First things first

QB and C++ can't really be compared one next to the other. Obviously, there hasn't been a new version of QB since the early 90's. C++, however, is still constantly updated, which automatically puts it ahead of QB. This wouldn't be that much of a problem, except 386s were still common in 1992, but nowadays, with processors like the K6-2, QB doesn't have the same built-in capabilities as the new versions of C++ that appear regularly.

Learners-language syndrome

(This article is continued from Issue 2. This is all the appendixes and they show you EXACTLY what everything does....also look for an 'svgalib' program at the bottom of this article)

4 Appendices
------------

Appendix A - Required TYPE definitions and descriptions
-------------------------------------------------------

VgaInfoBlock, returned by VESA function &H00.

    TYPE VgaInfoBlock
        VESASignature AS STRING * 4
        VESAVersion AS INTEGER
        OEMStringPtr AS LONG
        Capabilities AS STRING * 4
        VideoModePtr AS LONG
        TotalMemory AS INTEGER
        Reserved AS STRING * 236
    END TYPE

VESASignature - contains the characters "VESA".
VESAVersion - specifies what version of the VESA standard is in use. The higher byte specifies the major version number. The lower byte specifies the minor version number. Features of older versions are guaranteed to work in later versions.
OEMStringPtr - a far pointer to a null terminated OEM-defined string which may be used to identify the video chip, video board, memory configuration, etc. to hardware specific display drivers.
Capabilities - describes what general features are supported. The bits are defined as follows.

                      0    - DAC is switchable
                              0 - DAC is fixed width, with 6-bits per
                                   primary color.
                              1 - DAC width is switchable.
                      1-31 - Reserved
  

ModeInfoBlock, returned by VESA function &H01.

    TYPE ModeInfoBlock
        ModeAttributes AS INTEGER
        WinAAttributes AS STRING * 1
        WinBAttributes AS STRING * 1
        WinGranularity AS INTEGER
        WinSize AS INTEGER
        WinASegment AS INTEGER
        WinBSegment AS INTEGER
        WinFuncPtr AS LONG
        BytesPerScanLine AS INTEGER
        XResolution AS INTEGER
        YResolution AS INTEGER
        XCharSize AS STRING * 1
        YCharSize AS STRING * 1
        NumberOfPlanes AS STRING * 1
        BitsPerPixel AS STRING * 1
        NumberOfBanks AS STRING * 1
        MemoryModel AS STRING * 1
        BankSize AS STRING * 1
        NumberOfImagePages AS STRING * 1
        Rsvd AS STRING * 1
        RedMaskSize AS STRING * 1
        RedFieldPosition AS STRING * 1
        GreenMaskSize AS STRING * 1
        GreenFieldPosition AS STRING * 1
        BlueMaskSize AS STRING * 1
        BlueFieldPosition AS STRING * 1
        RsvdMaskSize AS STRING * 1
        DirectColorModeInfo AS STRING * 1
        Reserved AS STRING * 216
    END TYPE

ModeAttributes - describes certain characteristics of the video mode. Bits are defined as follows.

                            0    - Mode supported in hardware
                                    0 - Mode not supported
                                    1 - Mode is supported
                            1    - 1 (Reserved)
                            2    - Output functions supported by BIOS
                                    0 - Output functions not supported
                                    1 - Output functions are supported
                            3    - Monochrome/colour mode
                                    0 - Monochrome mode
                                    1 - Colour mode
                            4    - Mode type
                                    0 - Text mode
                                    1 - Graphics mode
                            5-15 - Reserved

                            0   - Window supported
                                   0 - Window is not supported
                                   1 - Window is supported
                            1   - Window readable
                                   0 - Window is not readable
                                   1 - Window is readable
                            2   - Window writeable
                                   0 - Window is not writeable
                                   1 - Window is writeable
                            3-7 - Reserved

                            &H00      - Text mode
                            &H01      - CGA graphics
                            &H02      - Hercules graphics
                            &H03      - 4-plane planar
                            &H04      - Packed pixel
                            &H05      - Non-chain 4, 256 colour
                            &H06      - Direct colour
                            &H07      - YUV
                            &H08-&H0F - Reserved, to be defined by VESA
                            &H10-&HFF - To be defined by OEM

                            0 - Colour ramp is fixed/programmable
                                 0 - Colour ramp is fixed
                                 1 - Colour ramp is programmable
                            1 - Bits in Rsvd field are usable/reserved
                                 0 - Bits in Rsvd field are reserved
                                 1 - Bits in Rsvd field are usable

Appendix B - VESA defined screen modes
--------------------------------------

             GRAPHICS MODES                           TEXT MODES
  Mode number    Resolution    Colours      Mode number    Columns    Rows
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  &H100          640x400       256          &H108          80         60
  &H101          640x480       256          &H109          132        25
  &H102          800x600       16           &H10A          132        43
  &H103          800x600       256          &H10B          132        50
  &H104          1024x768      16           &H10C          132        60
  &H105          1024x768      256
  &H106          1280x1024     16
  &H107          1280x1024     256

  &H10D          320x200       32k   (1:5:5:5)
  &H10E          320x200       64k   (5:6:5)
  &H10F          320x200       16.8M (8:8:8)
  &H110          640x480       32k   (1:5:5:5)
  &H111          640x480       64k   (5:6:5)
  &H112          640x480       16.8M (8:8:8)
  &H113          800x600       32k   (1:5:5:5)
  &H114          800x600       64k   (5:6:5)
  &H115          800x600       16.8M (8:8:8)
  &H116          1024x768      32k   (1:5:5:5)
  &H117          1024x768      64k   (5:6:5)
  &H118          1024x768      16.8M (8:8:8)
  &H119          1280x1024     32k   (1:5:5:5)
  &H11A          1280x1024     64k   (5:6:5)
  &H11B          1280x1024     16.8M (8:8:8)

Appendix C - VESA VGA BIOS Extension function reference
-------------------------------------------------------

Function &H00 - Return Super VGA Information
Provides information to the calling program about the general capabilities of the SVGA environment. The function fills an information block of type VgaIngoBlock at the address specified by the caller.

      Input - AH = &H4F
              AL = &H00
              ES:DI = Pointer to buffer

      Output - AX = Status (&H4F if successful)
               (All other registers are preserved)

Function &H01 - Return Super VGA Mode Information
Returns information about a specific SVGA video mode. Fills a mode information block of type ModeInfoBlock at the address specified by the caller.

      Input - AH = &H4F
              AL = &H01
              CX = SVGA video mode
              ES:DI = Pointer to buffer

      Output - AX = Status (&H4F if successful)
               (All other registers are preserved)

Function &H02 - Set Super VGA Video Mode

Initializes a video mode.

Input - AH = &H4F
              AL = &H02
              BX = Video mode
                    Bits 0-14 - Video mode
                         15   - Clear memory flag
                                 0 - Clear video memory
                                 1 - Don't clear video memory

      Output - AX = Status (&H4F if successful)
               (All other registers are preserved)

Function &H03 - Return Current Video Mode
Returns the current video mode in BX. Not limited to SVGA modes, will also return any other video mode.

      Input - AH = &H4F
              AL = &H03

      Output - AX = Status (&H4F if successful)
               BX = Current video mode
               (All other registers are preserved)

Function &H04 - Save/Restore Super VGA Video State
Provides a mechanism to save and restore the SVGA video state.

      Input - AH = &H4F
              AL = &H04
              DL = &H00       Return save/restore state buffer size
              CX = Requested states
                    Bit 0 - Save/restore video hardware state
                        1 - Save/restore video BIOS state
                        2 - Save/restore video DAC state
                        3 - Save/restore SVGA state

      Output - AX = Status (&H4F if successful)
               BX = Number of 64 byte blocks to hold the state buffer
               (All other registers are preserved)

      Input - AH = &H4F
              AL = &H04
              DL = &H01       Save SVGA video state
              CX = Requested states (see above)
              ES:BX = Pointer to buffer

      Output - AX = Status (&H4F if successful)
               (All other registers are preserved)

      Input - AH = &H4F
              AL = &H04
              DL = &H02       Restore SVGA video state
              CX = Requested states (see above)
              ES:BX = Pointer to buffer

      Output - AX = Status (&H4F if successful)
               (All other registers are preserved)

Function &H05 - CPU Video Memory Window Control
Sets or gets the position of the specified window in the video memory. The function allows direct access to the hardware paging registers.

      Input - AH = &H4F
              AL = &H05
              BH = &H00       Select SVGA video memory window
              BL = Window number
                    0 - Window A
                    1 - Window B
              DX = Window position in video memory
                    (in window granularity units)

      Output - AX = Status (&H4F if successful)

      Input - AH = &H4F
              AL = &H05
              BH = &H01       Return SVGA video memory window
              BL = Window number (see above)

      Output - AX = Status (&H4F if successful)
               DX = Window position in video memory
                     (in window granularity units)

Function &H06 - Set/Get Logical Scan Line Length
Sets or gets the length of a logical scan line. This function allows an application to set up a logical video memory buffer that is wider than the displayed area.

      Input - AH = &H4F
              AL = &H06
              BL = &H00       Select scan line length
              CX = Desired width in pixels

      Output - AX = Status (&H4F if successful)
               BX = Bytes per scan line
               CX = Actual pixels per scan line
               DX = Maximum number of scan lines

      Input - AH = &H4F
              AL = &H06
              BL = &H01       Return scan line length

      Output - AX = Status (&H4F if successful)
               BX = Bytes per scan line
               CX = Actual pixels per scan line
               DX = Maximum number of scan lines

Function &H07 - Set/Get Display Start
Selects the pixel to be displayed in the upper left corner of the display from the logical page. This function can be used to pan and scroll around logical screens that are larger than the displayed screen. This function can also be used to rapidly switch between two different displayed screens for double buffered animation effects.

      Input - AH = &H4F
              AL = &H07
              BH = &H00
              BL = &H00       Select display start
              CX = First displayed pixel in scan line
              DX = First displayed scan line

      Output - AX = Status (&H4F if successful)

      Input - AH = &H4F
              AL = &H07
              BL = &H01       Return display start

      Output - AX = Status (&H4F if successful)
               BH = &H00 Reserved and will be 0
               CX = First displayed pixel in scan line
               DX = First displayed scan line

Function &H08 - Set/Get DAC Palette Control
Queries and selects the operating mode of the DAC palette. Some DACs are configurable to provide 6-bits, 8-bits, or more of colour definition per red, green, and blue primary colour. The DAC palette width is assumed to be reset to standard VGA 6-bits per primary during a standard or VESA Set SVGA mode call.

      Input - AH = &H4F
              AL = &H08
              BL = &H00       Set DAC palette width
              BH = Desired number of bits of colour per primary

      Output - AX = Status (&H4F if successful)
               BH = Current number of bits of colour per primary

      Input - AH = &H4F
              AL = &H08
              BL = &H01       Get DAC palette width

      Output - AX = Status (&H4F if successful)
               BH = Current number of bits of colour per primary

Appendix E - Suggested sources
------------------------------