Graphics and the Reset Code

You may have wondered about the semicolon we had you place after the B$ in line 40. If this line were text rather than graphics data, this semicolon would cause the text and the Reset Code (CHR$(27)“@“) in line 80 to be placed in the same text buffer and consequently the Reset Code would wipe the text out. This doesn’t happen with the graphics command and its data because the CHR$(27)“K” command itself dumps everything from the buffer to the printer. By the time the Reset Code makes its appearance, both the command and its data are gone.

To see this in action, add a line to your program:50 INPUT A

The INPUT causes the program run to pause for you to see that the graphics design is printed before the program reaches the Reset Code in line 80. To let the program finish, press your carriage-return key.

There’s an important correlation to note. Anything that was in the buffer prior to the graphics string remains unscathed, and anything left behind is erased. To verify this, make these changes in your program:

35 LPRINT "PROTECTED TEXT";50 LPRINT "THIS WILL NOT PRINT"; and RUN it once.

PROTECTED TEXT

In general, you need to remember that the Reset Code doesn’t affect graphics data, but it may affect companion text.

Graphics and low ASCII codes

Sending the codes between zero and 31 from BASIC can be a problem when you are printing graphics just as it is when you are printing text. The problem again is that most computer systems handle some of these codes in a special way instead of delivering them to the printer.

For example, one computer system handles form feeds by itself. It counts lines to keep track of the top of form. If a program sends the CHR$ command with the number that ASCII designates as the code

144