Remarks: Maze Walker
From Maze
(Difference between revisions)
(→Stabilizing the Maze) | (→Stabilizing the Maze) | ||
| Line 72: | Line 72: | ||
To fill the whole screen with a stable maze, the program should loop for 1000 characters instead of 400. However, instead of filling the whole screen, the screen scrolls up by two lines when the last character is printed. This is verified by printing 999 characters, which almost perfectly fills the screen, leaving one blank space in the lower right-hand corner [image?]. This is the same ragged scrolling behavior observed at the bottom of the screen in the original, infinitely scrolling version of 10 PRINT. The seemingly innocent PRINT command, which promises to simply place text on the screen, is doing something more. As discussed in [C64 chapter], PRINT is actually enforcing the concept of 80 character logical lines, on top of the C64's 40 character wide screen. So, starting with a blank screen, when the 1000th character is printed, this happens to be the 80th character of the last logical line on the display, causing the screen to scroll by two physical (40 character) lines to make room for the next 80 character logical line. Two layers of code underwrite the operation of PRINTing to the screen: code in the BASIC interpreter, which handles the various language-specific features associated with PRINT, such as formatting operations like the semi-colon, and code specific to the C64 hardware platform, invoked by the BASIC interpreter, providing facilities such as the ability to output a character to the screen. So to generate our screen full of stable maze, a mechanism other than the virtual teletype enforced by PRINT and its two layers of language platform and hardware platform code, must be used. | To fill the whole screen with a stable maze, the program should loop for 1000 characters instead of 400. However, instead of filling the whole screen, the screen scrolls up by two lines when the last character is printed. This is verified by printing 999 characters, which almost perfectly fills the screen, leaving one blank space in the lower right-hand corner [image?]. This is the same ragged scrolling behavior observed at the bottom of the screen in the original, infinitely scrolling version of 10 PRINT. The seemingly innocent PRINT command, which promises to simply place text on the screen, is doing something more. As discussed in [C64 chapter], PRINT is actually enforcing the concept of 80 character logical lines, on top of the C64's 40 character wide screen. So, starting with a blank screen, when the 1000th character is printed, this happens to be the 80th character of the last logical line on the display, causing the screen to scroll by two physical (40 character) lines to make room for the next 80 character logical line. Two layers of code underwrite the operation of PRINTing to the screen: code in the BASIC interpreter, which handles the various language-specific features associated with PRINT, such as formatting operations like the semi-colon, and code specific to the C64 hardware platform, invoked by the BASIC interpreter, providing facilities such as the ability to output a character to the screen. So to generate our screen full of stable maze, a mechanism other than the virtual teletype enforced by PRINT and its two layers of language platform and hardware platform code, must be used. | ||
| + | |||
| + | Fortunately, BASIC provides the commands POKE and PEEK to directly write and read physical memory addresses. These commands provide a mechanism for subverting the language abstractions of BASIC, giving the BASIC programmer access to the arbitrary memory manipulation available via assembly language opcodes. If computer memory truly consisted only of data and code, as described by the von Neumann architecture, then POKE and PEEK would have limited utility to the BASIC programmer, merely providing a less convenient mechanism than variables for storing data, as well as the somewhat esoteric ability for a program to modify its own code during execution. But the C64 employs a common computer architecture approach of memory-mapped hardware registers. With memory mapping, in addition to the standard memory space that stores code and data, there are memory addresses for hardware registers that directly control the execution of the machine. These special memory addresses include control for input and output devices, such as screens, keyboards, and printers. On the C64, the BASIC interpreter and operating system code that create abstractions such as PRINT's virtual teletype, perform their lowest level operations by writing and reading these special memory addresses. By providing POKE and PEEK, which were not available in the original Dartmouth BASIC [I don't think memory-mapping was common in 1964, so POKE and PEEK would have had limited utility - further BASIC was operating in a time-sharing environment, so you wouldn't have wanted to provide individual programs access to hardware registers anyway - if we want to go into this, it would be wherever we want to introduce POKE and PEEK], Commodore BASIC provides a backdoor by which BASIC programmers can directly manipulate hardware registers that would typically only be accessible to assembly language programmers. | ||
