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.