The Commodore 64
From Maze
(Difference between revisions)
(Fixed list) | (Made the keyboard map section a sidebar, starting to modify hidden code) | ||
| Line 46: | Line 46: | ||
<blockquote>10 PRINT CHR$('''''round down('''''205.5+RND(1)''''')'''''); : GOTO 10</blockquote> | <blockquote>10 PRINT CHR$('''''round down('''''205.5+RND(1)''''')'''''); : GOTO 10</blockquote> | ||
| − | The process of choosing a random number is described elsewhere in this book, but one key feature of 10-Print's environment that makes the random number useful is its ability to automatically truncate decimals. The equation used to determine which character code to display, 205.5+RND(1), results in values between 205.500000 and 206.500000 and includes 6 digits after the decimal. Character codes, however, are integer values. In many environments the programmer would need to include a separate function to round off the equation output and create an integer that would be recognized as a character code, potentially pushing the 10-Print program beyond a single line. The Commodore 64 BASIC environment simply truncates the decimal value, resulting in character codes of either 205 or 206. | + | The process of choosing a random number is described elsewhere in this book, but one key feature of 10-Print's environment that makes the random number useful is its ability to automatically truncate decimals. The equation used to determine which character code to display, 205.5+RND(1), results in values between 205.500000 and 206.500000 and includes 6 digits after the decimal. Character codes, however, are integer values. In many environments the programmer would need to include a separate function to round off the equation output and create an integer that would be recognized as a character code, potentially pushing the 10-Print program beyond a single line. BASIC's CHR$() function simply truncates the decimal value, resulting in character codes of either 205 or 206. |
| − | Modified version: not possible | + | How can the assumption be changed? There is no way for CHR$() to render fractional numbers. The number CHR$() uses to display a character has to correspond to a position in the PETSCII chart, which only contains whole number indices (see sidebar for more on PETSCII). |
| + | |||
| + | === Sidebar: Keyboard and Character Map, Hardware and Software === | ||
| + | |||
| + | [[Image:PET_Keyboard.png|thumb|400px|The PET 2001 chicklet keyboard, with the visually complementary arrangement of graphic characters on the keys.]] | ||
| + | |||
| + | As we will see when exploring visual alternatives below, the PETSCII CHR table contains few related graphical characters the are next to each other and can be easily addressed by offsets -- in fact, many related images (sets of corners, mirror images) appear to have been randomly scattered through the space. This lack of adjacency complicates our ability to generate graphics using a simple offset -- in fact, to use anything but an offset of one, we have to cast the random number generator's float result to an int before multiplying. | ||
| + | |||
| + | [[Image:C64_PETSCII_chart.png|thumb|300px|Chart of unshifted PETSCII characters displaying on a Commodore 64]] | ||
| + | |||
| + | Why is the order of graphical characters in the PETSCII table so haphazard? The answer is that arrangement was dictated, not by logically grouping index numbers (a program-up strategy), but by arranging them visually on the PET keyboard design (a hardware-down strategy). Because the PET 2001 keyboard was a chicklet variant of the QWERTY arrangement, yet lacking the row offsets that QWERTY designer Christopher Sholes originally created for mechanical typewriter levers, its grid of keys presented a clear canvas for logical groupings of related symbols. Thus we can see four corners of a square grouped on OPL:, four arcs of a circle on UIJK, and four suits of a card deck on ASZX. | ||
| + | |||
| + | This visual logical grouping, however, occurs in the space of the QWERTY keyboard arrangement, which originally attempted to minimize mechanical jams in typewriters by maximizing the distance between common letter pairs. As a side-effect of this principle, few adjacent letters pairs in the alphabetic sequence are actually visual neighbors on the QWERTY keyboard. Other related graphical characters, while adjacent on the physical keyboard, are effectively scrambled by the QWERTY layout before being placed in the alphabetized PETSCII index. This preserves their logical relationship to the keys (any graphical character can be transformed into its letter, or vice-versa, by a fixed offset). However it obfuscates their relationship to each other. The only alphabetically adjacent keys found in QWERTY rows are: | ||
| + | |||
| + | * FG (102/103) | ||
| + | * JK (106/107) | ||
| + | * NM (110/109) (reversed) | ||
| + | * OP (111/112) | ||
| + | |||
| + | Not coincidentally, our ''10 Print'' one-liner uses the NM pair – because it is visible on the interface, because it is elegant and concise in the code, and because the output is surprising, given the context of maze-like computer graphics at the time. On the PET, all of the other pairs also bear related graphical characters, and we will try each of them below -- but only NM will produce something more structural than textural. | ||
===Colors=== | ===Colors=== | ||
| Line 54: | Line 73: | ||
<blockquote>'''''Set background color to dark blue'''''<br /> | <blockquote>'''''Set background color to dark blue'''''<br /> | ||
'''''Set text color to light blue'''''<br /> | '''''Set text color to light blue'''''<br /> | ||
| − | 10 PRINT CHR$(205.5+RND(1)); : GOTO 10</blockquote> | + | 10 PRINT CHR$(''round down(''205.5+RND(1)'')''); : GOTO 10</blockquote> |
| − | The first environmental setting is apparent before the program is written; the default text and background colors of the Commodore 64. While these defaults can be overridden easily enough – text colors in BASIC on the Commodore 64 are printable characters so adding PRINT CHR$(30), for example, would make the text green; background colors are similarly changeable using POKE – the original 10-Print program outputs using the pre-existing conditions of the environment. | + | Even before a user begins typing 10-Print into their Commodore 64, it has set an aspect of the environment that will greatly effect the program's output: the default text and background colors of the Commodore 64. While these defaults can be overridden easily enough – text colors in BASIC on the Commodore 64 are printable characters so adding PRINT CHR$(30), for example, would make the text green; background colors are similarly changeable using POKE – the original 10-Print program outputs using the pre-existing conditions of the environment. |
| − | Modified version: | + | How can the assumption be changed? Add a few lines that set the text and background colors: |
<pre>5 PRINT CHR$(30) | <pre>5 PRINT CHR$(30) | ||
6 POKE 53281, 0 | 6 POKE 53281, 0 | ||
| Line 196: | Line 215: | ||
The output of the assembly program is essentially identical to 10 Print (it runs a bit faster, because the microprocessor is running machine instructions directly, rather than interpreting them first as BASIC commands and functions. But the program that generates that output is really no more or less lengthy or complex than is the BASIC program. When measured in bytes, the assembly program is even shorter than its BASIC cousin (22 bytes for the assembly program, compared to 36 bytes, or characters, for the BASIC program). While the assembly program is clearly more esoteric and less human readable than the BASIC one, its implementation teaches us that the abstraction that makes the emergent elegance of 10 Print's output possible in such a small set of instructions is not a feature of the BASIC interpreter, but of the underlying hardware itself. | The output of the assembly program is essentially identical to 10 Print (it runs a bit faster, because the microprocessor is running machine instructions directly, rather than interpreting them first as BASIC commands and functions. But the program that generates that output is really no more or less lengthy or complex than is the BASIC program. When measured in bytes, the assembly program is even shorter than its BASIC cousin (22 bytes for the assembly program, compared to 36 bytes, or characters, for the BASIC program). While the assembly program is clearly more esoteric and less human readable than the BASIC one, its implementation teaches us that the abstraction that makes the emergent elegance of 10 Print's output possible in such a small set of instructions is not a feature of the BASIC interpreter, but of the underlying hardware itself. | ||
| − | == Keyboard and Character Map, Hardware and Software == | ||
| − | |||
| − | [[Image:PET_Keyboard.png|thumb|400px|The PET 2001 chicklet keyboard, with the visually complementary arrangement of graphic characters on the keys.]] | ||
| − | |||
| − | As we will see when exploring visual alternatives below, the PETSCII CHR table contains few related graphical characters the are next to each other and can be easily addressed by offsets -- in fact, many related images (sets of corners, mirror images) appear to have been randomly scattered through the space. This lack of adjacency complicates our ability to generate graphics using a simple offset -- in fact, to use anything but an offset of one, we have to cast the random number generator's float result to an int before multiplying. | ||
| − | |||
| − | [[Image:C64_PETSCII_chart.png|thumb|300px|Chart of unshifted PETSCII characters displaying on a Commodore 64]] | ||
| − | |||
| − | Why is the order of graphical characters in the PETSCII table so haphazard? The answer is that arrangement was dictated, not by logically grouping index numbers (a program-up strategy), but by arranging them visually on the PET keyboard design (a hardware-down strategy). Because the PET 2001 keyboard was a chicklet variant of the QWERTY arrangement, yet lacking the row offsets that QWERTY designer Christopher Sholes originally created for mechanical typewriter levers, its grid of keys presented a clear canvas for logical groupings of related symbols. Thus we can see four corners of a square grouped on OPL:, four arcs of a circle on UIJK, and four suits of a card deck on ASZX. | ||
| − | |||
| − | This visual logical grouping, however, occurs in the space of the QWERTY keyboard arrangement, which originally attempted to minimize mechanical jams in typewriters by maximizing the distance between common letter pairs. As a side-effect of this principle, few adjacent letters pairs in the alphabetic sequence are actually visual neighbors on the QWERTY keyboard. Other related graphical characters, while adjacent on the physical keyboard, are effectively scrambled by the QWERTY layout before being placed in the alphabetized PETSCII index. This preserves their logical relationship to the keys (any graphical character can be transformed into its letter, or vice-versa, by a fixed offset). However it obfuscates their relationship to each other. The only alphabetically adjacent keys found in QWERTY rows are: | ||
| − | |||
| − | * FG (102/103) | ||
| − | * JK (106/107) | ||
| − | * NM (110/109) (reversed) | ||
| − | * OP (111/112) | ||
| − | |||
| − | Not coincidentally, our ''10 Print'' one-liner uses the NM pair -- because it is visible on the interface, because it is elegant and concise in the code, and because the output is surprising, given the context of maze-like computer graphics at the time. On the PET, all of the other pairs also bear related graphical characters, and we will try each of them below -- but only NM will produce something more structural than textural. | ||
== Notes == | == Notes == | ||
