---------------------------------------------------------------------- P o w e r P r o g r a m m i n g ---------------------------------------------------------------------- Scenic Views by way of the Video Map by Larry Stone Creating an attractive set of screens for your program is, often times, more important than WHAT your program actually does or doesn't do. As Marshall McCluine would say, "the medium is the message". Packaging is everything when selling to the public. After all, how much research, development, and skill went into the "growing" of America's favorite pet, the "pet rock"? None. However, plenty of resources were involved in packaging and promoting it so that the con- sumer would buy it. Computer software is packaged twice. The first packaging is the box itself and is more important for selling games or Vapor-Ware. The next type of packaging is within the software itself. It is the bells and whistles, the pizzazz; the sizzle along with the steak. It is what turns dull, boring, productive software into productive software that is exciting and fun to use. Our bell and whistle stop will be, where else - the monitor. To navigate the monitor, we will need a good map, a video map. Understanding and playing with the video map is the key to many a bell and a whistle. The video map holds text mode screens in a simple and redundant fashion. It is this simplicity and redundancy that allows us to create dazzling windows that implode, slide, push and pop into view. The map is an area of memory that can be considered a grid holding character and color information inside of alternating cells. If we designate a capital "C" to represent "character" and "A" for "color Attribute", we could depict the map as: 012345... ...159 CACACACACACACACACACACACACACACACACACACACACACACACACACACACACACA CACACACACACACACACACACACACACACACACACACACACACACACACACACACACACA CACACACACACACACACACACACACACACACACACACACACACACACACACACACACACA Each column contains either character data or color data but not both. Each "CA" pair represents data for one column-row location on a monitor. This means that there are 80 pairs per row or, 160 pieces of information per row. Knowing this makes accessing the map easier. If we want to read or write to row 1, column 1 (PRINT 1, 1), we go to the map and put our character into position "0" and our color into "1". PRINT 1, 80 would have a map address of 158 for the character and 159 for the color. PRINT 2, 1 address would be 160 and 161. An 80x25 mode screen is mapped from position 0 to 3999 (4000 positions). A screen in 80x50 starts at 0 and ends at 7999 (8000 positions). Knowing how the video map stores data makes it easy to build an array for our windows. The easiest array to build would be an integer array that corresponds to every element in the map. To create a one to one array would require an array DIMensioned for 4000 elements with The QBNews Page 14 Volume 1, Number 5 December 1, 1990 an 80x25 text screen. An array of 8000 elements would be required for an 80x50 screen. Although these arrays make our programming very easy due to the one to one correlation, they are, never-the-less, very in- efficient. This is because a simple integer is a two byte word. The video map uses one integer to hold information for each "CA" pair. The high byte holds character information and the low byte holds the color data. When we make an integer array DIMmed to 4000 elements, there is 4000 bytes of wasted space (each integer is a two byte word - hence, an array DIMmed to 4000 elements uses 8000 bytes.) What we want is an 2000 elements array that houses 4000 bytes. Because we are going for memory efficiency, and because we access into the video map by POKEing one byte at a time, we need a translator to move data from our arrays to the map and back. In other words, we will need to combine bytes into integers and extract bytes from integers. When we do so, we need a convenient method to keep track of where we are in both the map and the array. I find that the easi- est way to do this is to simply keep track of where we are in the map then divide that number by two to correlate it to our position in the array. Fancy screen writes are, generally, accomplished by manipulating data from our array via one or more loops and STEPping through these loops in a manner that will write our screen in a dazzling manner. The accompanying code (DAZZLING.BAS and DAZZDEMO.BAS) illustrates eleven different, dazzling screen writes. Because each of these methods are performed in two different ways (top to bottom, bottom to top and, right to left, left to right), the effect is 22 completely different screen routines in only three subprograms. In addition to the fancy screen display routines, the code supplies five other useful routines. ReadBinFile reads a disk file that was formed by a simple binary dump of the video map. You could create your screens using TheDraw, save your files using the "BIN" option and read them into your screen array with ReadBinFile. An 80x25 text screen will produce a 4000 byte BIN file. This type of file is fast to read into arrays and they are slightly smaller than a Bsave file (4007 bytes). The two BIN files used by my sample code, CRESCENT.BIN and SHUTTLE.BIN are re-creations of screens used by The Crescent Software Support BBS and a modified shuttle used by TheDraw as one of their samples. The ReadBinFile rou- tine also does something no others of its ilk do. It can read the screen to into a row position other than row number one. This allows a screen that was saved in 80x25 mode to be re-positioned for higher resolutions (80x43 or 80x50). The sample code, DAZZDEMO, creates 10 leading rows for high resolution. It then uses the StuffMess routine to fill these leading (and trailing rows). In this manner, one screen can be saved in a low resolution mode and expanded for high resolution systems. The StuffMess subprogram stuffs a message into a screen array BEFORE it is displayed on the monitor. Pass it the message string, the array to stuff, and the fore and background colors, and the row and column location. DAZZDEMO.BAS uses this routine to create a second story to the QBNews Software Library building and to expand the planet The QBNews Page 15 Volume 1, Number 5 December 1, 1990 earth when it runs on a video system that supports screen modes 80x43 or 80x50. If you study the accompanying code,you will notice that when StuffMess adds a second story to the QBNews Library, it uses a string that is 800 bytes long. The call to StuffMess simply locates the Mess string at row 1, column 1. StuffMess, in conjunction with the Curtain routine, produces the illusion of the shuttle doors opening. This is accomplished by filling the monitor with the bytes from the array with the shuttle picture. Once the picture is displayed, StuffMess is used to "redraw" that portion of the array that contains the shuttle doors. The array is, again, sent to the monitor only, this time, it is dis- played over the original shuttle picture with a call to the Curtain routine. The Curtain routine redisplays the shuttle from the middle outward. The effect is that the shuttle doors appear to open before your very eyes! TickPause is a simple delay that pauses in increments of 18 ticks per second. Simply pass in the number of ticks to pause. TickPause does NOT use BASIC's TIMER and, as consequence, does not access any of the Floating point library. This can translate as a huge savings in the compiled size of your exe files (DAZZLING, with it's 8 subprograms that perform 27 routines, compiles to only 7,100 bytes or so). GetMonitorSeg returns the starting address of the video map. If it senses a color system, it returns &HB800. Otherwise, it returns &HB000 as the starting address. Shake is a slight modification of a routine originally published at the end of 1988 by HumbleWare Custom Programming. It reprograms the 6845 CRT controllers viewport into video RAM. The shaking screen produced is quite radical. Don't watch it if you are prone to getting sea sick. Two other routines that are worth mentioning are not included in DAZZLING.BAS but are part of the demo program, DAZZDEMO. One uses the WIDTH statement to test and set your monitor for it's highest resolu- tion. If your monitor is EGA or VGA, "WIDTH , 43" or "WIDTH , 50" will force 80x43 / 80x50 screen mode. This technique uses error trapping. If someone knows how to test for a system's capability to use 80x43 or 80x50 modes without error trapping, I sure would like to know how. The other routine creates a continuous noise by reprogramming the timer with a new clock rate and outputs this straight to the speaker. This routine is one among several, useful sound routines published in "Inside Microsoft BASIC", by the Cobb Group, July 1990. If you don't subscribe to this magazine, this little routine should wet your whistle. If you compile DAZZLING.BAS as an object module, three variables must be declared as COMMON SHARED within your main code: Monitor AS INTEGER, ScrnEls AS INTEGER, and MaxLine AS INTEGER. To simplify your coding and to assure that the COMMON SHARED blocks will be the same, the code includes DAZZLING.BI which contains the declarations for the routines and COMMON SHARED blocks required. If you compile DAZZLING for use with your other code, REM $INCLUDE: 'DAZZLING.BI' immediately The QBNews Page 16 Volume 1, Number 5 December 1, 1990 after your last DECLARE and prior to your COMMON SHARED statement. Or, you could modify DAZZLING.BI and re-compile as your needs dictate. Follow the instructions at the top of DAZZLING.BAS and DAZZDEMO.BAS for linking and compiling into a stand alone program. One final note. The fancy screen routines used by DAZZLING.BAS use the POKE command. On older CGA systems, using a POKE to the sys- tem's monitor may cause snow because these old CGA systems cannot handle the direct screen activity during re-trace. ********************************************************************** Larry Stone is President of LSRGroup and is involved in writing software for marine and aquatic research, as well as, data acquisition software systems. He has also authored various shareware programs such as "SERVICES", a file, directory, disk and archive manager rated a trophy by the "PUBLIC BRAND SOFTWARE" shareware catalog. Larry can be reached at LSRGroup, P.O. Box 5715, Charleston, OR 97420, or in care of this newsletter or, contact him via The Empire Builder BBS 1:356/0 1:356/1 1:356/4 (14400 Baud), (503) 888-4121. ********************************************************************** [EDITOR'S NOTE] All code for this article can be found in the file DAZZLING.ZIP.