RUN

From Maze

Imagine it's 1981[2?] and you've just sat down in front of your Commodore 64 (C64). As you stare at the television set attached to this small computer-in-a-keyboard object, you see the word "READY" and a blinking cursor. Earlier in the day a "neat little program"<ref name="c64" /> in the Random Graphics section of the manual caught your eye: <ref name="multiple">Commodore 64 User's Guide, p 53.</ref>

 10 PRINT "{SHIFT-CLR/HOME}"
 20 PRINT CHR$(205.5 + RND(1));
 40 GOTO 20 
 

After you carefully type it[2], you input "RUN". The screen erupts into motion as lines flow onto the screen. As each row fills with symbols, it starts drawing on the next line. When the screen is full, the entire maze moves up and leaves space at the bottom for new characters to fill. The result is a dynamic maze:

[INSERT TWO FIGURES]

The three lines of code that create this continually generating maze do so because of the specific design of the C64, paired with the design of the BASIC language in which the program is written. The manual explains the code element by element, first pointing out the importance of the number 205.5. When this number is summed with RND(1), the result is a value between 205.5 and 206.5 because RND(1) calculates a value between 0 and 1. By design, the CHR$ function ignores fractional values, so numbers from 205.5 to 205.999 become 205 and numbers between 206 and 206.5 become 206. The program draws the maze because 205 is the C64 code for “\”, 206 is the code for “/” and because CHR$ draws those graphics to the screen.

We can test this by checking Appendix F in the manual (“ASCII and CHR$ Codes”) or inputting a short one-line program to print the character corresponding to 205 to the console:

 PRINT CHR$(205)

This places “\” on screen. We can test the other value writes “/”by inputting this:

 PRINT CHR$(206)

Now that we've established the transcoded identity of 205 and 206, we can focus on the fifty-fifty chance that each has to draw to the screen. Over a long period of time, the maze has roughly an even amount of these two graphics to give it balance. The manual suggests, “If you'd like to experiment with this program, try changing 205.5 by adding or subtracting a couple tenths from it. This will give either character a greater chance of being selected.” This suggestion increases the chances for one character to be selected over the other. Changing 205.5 to 205.1 gives the value 205 a 90% chance of drawing, which strongly affects the visual quality of the maze:

[INSERT FIGURE]

Replacing 205.5 with 205.9 gives the value 206 a 90% chance of drawing:

[INSERT FIGURE]

The code continually draws characters to the screen until the program is stopped because of line 40. Each time that line of code runs, the program jumps back to line 20 as defined by the GOTO command and makes the calculation to draw either the “\” or “/” graphic. This continuous loop defines the generative nature of the maze.

The dimensions and density of the maze are defined by the C64 specifications and the attached television. The screen is divided into 40 units wide and 25 high; each unit is a 8 x 8 pixel grid. The large border that surrounds the maze is required by the wide variation within cathode ray tube (CRT) televisions of the era. The CRT screen of different televisions framed the pixels differently, making only a subset of pixels in the center reliable for display. The 32 pixels borders on the left and right and 35 pixel borders on the top and bottom reduce the usable display to 320 wide by 200 pixels high.

The three-line program introduced here is nearly equivalent to the one-line namesake of this book:

10 PRINT CHR$(205.5 + RND(1)); : GOTO 10

The only difference is the condensed version doesn't clear the screen as in the first line of the expanded code. The first line of the three-line program clears the screen and places the first character in the upper left. The one-line program starts placing characters at the current location on screen and gradually pushes the other characters up as the maze draws:

[INSERT TWO FIGURES]

Notes

{{reflist}}

[1] [2] It's unclear why the lines are ordered 10, 20, 40, but the omission of 30 is likely a copy error in the manual and therefore not of importance in discussing the code.