Remarks: Maze Walker
From Maze
(Difference between revisions)
(→Stabilizing the Maze) | (→Stabilizing the Maze) | ||
| Line 76: | Line 76: | ||
The characters displayed on the C64 screen are stored in one of these special regions of memory, called video memory. Display hardware continuously scans video memory, reading character codes, looking up the bitmap describing each character, and drawing each character pixel-by-pixel onto the screen. Thus, even when no user code is executing, and the C64 is just sitting with text visible on the screen, the illusion of stable text is underwritten by frenetic activity, as character codes are accessed, bitmaps looked up, and characters painstakingly drawn, pixel by pixel, over and over again. So even in a one-line program like 10 PRINT, layers of process complexity underwrite the abstractions which provide the visual experience of an endlessly scrolling maze-like pattern. | The characters displayed on the C64 screen are stored in one of these special regions of memory, called video memory. Display hardware continuously scans video memory, reading character codes, looking up the bitmap describing each character, and drawing each character pixel-by-pixel onto the screen. Thus, even when no user code is executing, and the C64 is just sitting with text visible on the screen, the illusion of stable text is underwritten by frenetic activity, as character codes are accessed, bitmaps looked up, and characters painstakingly drawn, pixel by pixel, over and over again. So even in a one-line program like 10 PRINT, layers of process complexity underwrite the abstractions which provide the visual experience of an endlessly scrolling maze-like pattern. | ||
| + | |||
| + | To create a stable screen-sized maze, we will use POKE to bypass PRINT's virtual teletype and directly place PETSCII codes in video memory. Rather than iterating from 1 to 1000, the FOR loop must iterate over the 1000 character locations in video memory, which begins at memory location 1024. | ||
| + | |||
| + | <pre> | ||
| + | 1 PRINT CHR$(147) | ||
| + | 10 FOR X = 1024 TO 2023 | ||
| + | 20 POKE X,205.5+RND(1) | ||
| + | 30 NEXT X | ||
| + | 40 GOTO 40 | ||
| + | </pre> | ||
| + | |||
| + | Here we meet our last surprise in stabilizing the maze. This program does finally produce a stable screen-full of maze, but the foreground and background color is inverted [figure]. Replacing the PETSCII code 205 with 109 (employed in one of the variations of 10 PRINT) produces something even further from the maze, two different graphic characters entirely. It turns out there are two different layers of character encodings used in the C64, the PETSCII codes, and screen codes. As discussed in [chapter], PETSCII codes extend ASCII to include C64 specific graphics characters. Screen codes, on the other hand, are used to directly index character memory to look up the 8 by 8 grid pixel pattern for an individual character. That is screen code 0 refers to the first 8 by 8 character in character memory, screen code 1 to the next character in character memory and so forth. Since PETSCII, like ASCII, includes codes for non-printing control characters (characters with no visual representation), it would be more awkward to use the PETSCII codes as character memory indices, since the first visible character appears at PETSCII 32. By PRINTing PETSCII 109 and using PEEK to look in video memory, one finds that the resulting screen code is 77; this makes sense, as 109 - 32 (subtracting the first 32 non-printing PETSCII characters) is 77. The PETSCII code 205 also works to produce the forward and backward slanting maze characters because the PETSCII characters in the range 192 to 223 mirror the characters in the range 96 to 127; so PETSCII codes 205 and 206 represent the same characters as 109 and 110. But this means that PRINT, and the kernal routine called by PRINT, have to perform a somewhat complex mapping between PETSCII and the screen codes employed by the display system. In bypassing PRINT by POKEing directly to video memory, awareness of the double layer of character encodings was forced upon us. Somewhat amusingly, the use of the BASIC command POKE is forcing closer attention to C64 hardware concerns than lower level assembly language program described in Remark: Thread. This is because thread makes use of a kernal character output routine, which is performing the PETSCII to screen code mapping, while POKE bypasses the kernal; the assembly language equivalent would be to use the sta opcode to directly store a screen code in video memory. | ||
| + | |||
| + | The following BASIC program finally produces a stable screen full of maze pattern. | ||
| + | |||
| + | <pre> | ||
| + | 1 PRINT CHR$(147) | ||
| + | 10 FOR X = 1024 TO 2023 | ||
| + | 20 POKE X,77.5+RND(1) | ||
| + | 30 NEXT X | ||
| + | 40 GOTO 40 | ||
| + | </pre> | ||
