GWBasic Graphics


Screen 0


There are a number of screens available for GWBasic. The default screen is Screen Zero. The display is 15 lines with 80 Characters per line or 2000 characters. This display is a result of the bytes in memory beginning at location B800 hex or 47104 decimal. Each character in the display requires two bytes of memory, the first of which is the ascii equivelant for the character and the second byte is the color attribute. Because the memory location of these data reside in memory, they may be copied to a disk file with the BSAVE instruction and retrieved with a BLOAD instruction under GWBasic program control. It also permits us to examine any byte in memory and change it using the PEEK and POKE instructions. This example is designed to aquaint you with some techniques to do this. It will also become useful for more elaborate display manipulations with the more advanced graphic screen displays later.

Just a reminder that these exercises may be done on a floppy disk. This has the distinct advantage of keeping all the incidental files created in a location where they can be dealt with later. Of course, the exercise may be done on the hard drive, but if some files get misplaces, they may be hard to re-locate for subsequent deletion after the exercise.


Description of the Display Buffer

The display buffer that is responsible for the GWBasic display is a 4000 byte segment of memory beginning at location 47104 (B800 hex) and uses 4000 (FA0) bytes, two bytes to display each of the characters in the display. Run GWBasic under Windows and copy this program into the display using the BWBasic's Edit-paste feature from the drop down menu. The Browser can be showing this example and GWBasic can be run at the same time under Windows.

If you are using Native DOS (Windows isn't running) then the program will need to be typed in because the drop down menu isn't available. Either way will work nicely for this example. If you are using XP, then GWBasic will necessarily be run under the Windows system. Using Windows 98 and earlier, GWBasic can be run from the floppy without calling Windows by booting up on a floppy disk formated as a systems disk with the GWBasic.exe program on it. Both methods have their advantage.

Copy and paste this program to be run with GWBasic......

10 CLS
20 L$= STRING$(60,ASC("*"))
30 PRINT L$;
40 PRINT "The text in this display can be saved to a disk file"
50 PRINT "The name of the screen image file is:    SCREEN.x00"
60 PRINT L$
70 '
80 DEF SEG= &HB800
90 BSAVE "screen.x00", 0, 16384
100 PRINT
110 PRINT "Press any key to continue"
120 N$= INKEY$: IF N$="" THEN 120
130 '
140 CLS
150 PRINT"              The screen has been cleared."
160 PRINT "     Press any key to restore the original sreen image"
170 N$= INKEY$: IF N$="" THEN 170
180 '
190 BLOAD "screen.x00"
200 PRINT: PRINT: PRINT
210 PRINT: PRINT: PRINT
220 PRINT "the original image has been restored and the program terminated."
230 END



The program illustrates the ability to capture the display buffer to a file on the disk.

lines  10-60    create a display message.
lines  80-90    save the display as an image in a file named SCREEN.X00
lines 110-120   halts the program awaiting a key closure
lines 140-170   clears the display and halts the program again
line  190       restores the original image, that is in the image file named SCREEN.X00
lines 200-230    completes the program and terminates.

This may seem like a trivial use of an image file; however, it should be well understood for later use in higher order Screen modes, particulary when creating animation.




The Binary file format

Lets look at the binary file we created that contains our screen image.
First of all, it is binary, not ascii text. Any printable text uses ascii equivelant binary numbers to represent to character that it represents in screen mode 0. Lets create another image file and examine it with DEBUG.

In GWBasic, type in this program:

Ok
list
10 CLS
20 PRINT "0123456789ABCDEF"
30 DEF SEG= &HB800
40 BSAVE "SCREEN.X00", 0, 120
Ok

This is what happens when we run the program:
The screen is cleared, the characters 0 through F are printed at location B800 of the display buffer.
The segment is defined at the beginning of the video buffer and the offset is 0.
Then BSAVE creates the file on the disk in the local directory. (the folder containing GWBasic.exe).
This image definition can be BLOADed back to the display buffer at any offset we choose.

Lets look at the file we created in our local directory named SCREEN.X00. We just over-wrote the file we created earlier. Right click on it and select PROPERTIES in Windows, it has a length of  128 bytes. That is 8 more bytes than the 120 bytes we Bsaved. Where did the extra 8 bytes come from?

Lets examine the file with DEBUG.
Call Debug
n screen.x00         will name the file.
l                            will load the file
d                           will create a dump 128 bytes from the file.

Our DEBUG display will look like this:

-n screen.x00
-l
-d
0AF3:0100  FD 00 B8 00 00 78 00 30-07 31 07 32 07 33 07 34   .....x.0.1.2.3.4
0AF3:0110  07 35 07 36 07 37 07 38-07 39 07 41 07 42 07 43   .5.6.7.8.9.A.B.C
0AF3:0120  07 44 07 45 07 46 07 20-07 20 07 20 07 20 07 20   .D.E.F. . . . .
0AF3:0130  07 20 07 20 07 20 07 20-07 20 07 20 07 20 07 20   . . . . . . . .
0AF3:0140  07 20 07 20 07 20 07 20-07 20 07 20 07 20 07 20   . . . . . . . .
0AF3:0150  07 20 07 20 07 20 07 20-07 20 07 20 07 20 07 20   . . . . . . . .
0AF3:0160  07 20 07 20 07 20 07 20-07 20 07 20 07 20 07 20   . . . . . . . .
0AF3:0170  07 20 07 20 07 20 07 20-07 20 07 20 07 20 07 1A   . . . . . . . ..



DEBUG shows the data beginning at location 0100. This is the location all files are loaded at with DEBUG.
For GWBasic to know where the file was SAVEd from, it need be embedded in the image file.
These data along with the end of file mark make up the extra eight bytes we saw in our Properties statement.

FD 00 identfies the file type.
00 B8 specifies the memory location they were BSAVEd from. (B800  lo byte hi byte)
00 00 specifies the offset from the segment address. (00 00)
78 00 specifies the length of the image. (0078)
30 07 is  the first character, zero followed by the default color definition 07.
31 07 is the second character, one as seen in the ascii display to the right.
20 07 are all space character followed by their color definition.
1A is the end of file marker.
Those 8 bytes, plus the 120 characters make up the 128 byte image file on disk.

When this image is restored by BWBasic, then the starting location the character length and offset of the characters are known from the binary data in the SCREEN.X00 file along with the character definitions. They can easily be restored to the GWBasic screen. They can even be offset and BLOADed with a different offset, if specified.
Its easy to see that an image file could easily be created for GWBasic using DEBUG.



Summary

There is very little need for creating image files for the displays used in Screen 0 mode. It is an important feature using the higher order Screen modes in the Graphics modes. However, it may become useful to capture a number of lines of text from the display to be restored later, using Screen 0. A page of text, containing a program listing may be saved or perhaps a single line of immediate code might be saved. A single "one liner"  entry of keystrokes is easier to save and restore than to need to retype it whenever you wish to execute it with the ENTER key. Especially, since a one liner can be up to 256 characters in length.

Again, this display capture technique does provide a way of understanding the use of the display buffer to display the information on the screen in terms of memory usage. It becomes less frustrating when attempting to use the DOS display compared to the emulated DOS displays provided with the Windows Emulated DOS display.