Advanced SVGA II by Anthony Tyler 08.01.99
|Hi, everybody, and welcome back to part 2 of "Advanced SVGA". First of all I recommend that you read part 1 of this series, before you read this, because this builds on the knowledge we acquired in part 1. This time, we will learn how to write pixels to the screen in a 640x480 screen mode. Okay, enough of the introduction! Let's start programming!||download the files|
SUB Pixel (X%, Y%, R%, G%, B%)
Let us begin to analyze this code. The first line is:
offset& = (Y% * 4) * 640& + (X% * 4)
This is the most important part, of the sub. What this does is it calculates where we should put the pixel. The reason we multiply the X and Y values by 4 is because each pixel takes four bytes(red, green, blue, and reserved). Reserved can be any value, and it does not effect the pixel. We multiply the Y * 4 by 640 because that is the width of X, video memory is stored the same in SVGA modes as in VGA modes:
0 1 2 3 4 5 6 7 8 9 640 641 642 643 644 645 646 647 648 649
We then just add the X value(times 4). The next piece of code is:
BANK% = INT(offset& \ 65536)
This calculates our bank. Since screen modes can only be accessed 64k at a time(65536 bytes). We must divide our offset by 64k to find the right bank. This is rather simple to understand.
offset& = offset& - 65536 * BANK%
This piece of code adjusts our offset to be within the 64k boundaries. Since we found the right bank. We then must subtract the bank * 65536 by our offset. For example, when we calculate our offset we get 65537. We find that our bank is bank 1. We then must find where in this bank, is our pixel. We do this calculation offset& = offset& - 65536 * BANK%. And our result is 1, so our pixel is at offset 1 in the first bank. Our next piece of code, is the bank setting code.
IF BANK% <> curbank% THEN
This code saves us quite a bit of time. What it does is checks to see if the BANK our pixel is at is the BANK we are already at. If not, we set the BANK and change the variable curbank% to equal our current BANK, if so we do not need to waste our time setting a bank that we are already at.
DEF SEG = &HA000
The final piece of code, is the code that actually sets the pixel. All we do is set the segment to the video segment, and POKE the RGB values in reverse order. We do this because that is the way VESA made it.
Without a great knowledge of assembly language this code would be very hard to decipher, therefore I will not step through this code line by line. Optimizing it in assembly language made the procedure 20 times faster. Well, since this document is getting pretty large, I guess I will wrap up this part. The next part of this series will be on more pixel drawing, and maybe line and circle drawing (thru the Bresenham Algorithms). Oh, and before I forget get our current library here. Have fun! Happy programming!!
"SVGA" is not a standard as VGA was, it's just a term meaning "Super
VGA" which represents any card using features above and beyond the
VGA standard (i.e., uses more than the computer vga card's on-board
memory). After the first few years of svga (much like in 3d
acceleration now) had a standards called the VESA VGA BIOS Extensions
introduced, which specifies certain pixel size and colour depths to be
standard (such as 640x480x65k or 1024x768x16m). Later on, a standard called
UVGA (Ultimate VGA) was coined to represent a colour depth of 1024x768
or higher, but never caught on, which is why SVGA's various sizes and color
amounts (basically, anything over 640x480x16 is svga) amount to a somewhat confusing
With VESA BIOS, which represents nearly every 2d card nowadays, though, there's
less to worry about in terms of whether your code will work on a certain computer.
All the SVGA tuts at qb:tm use VESA BIOS calls.
With VESA BIOS, which represents nearly every 2d card nowadays, though, there's less to worry about in terms of whether your code will work on a certain computer. All the SVGA tuts at qb:tm use VESA BIOS calls.