The Commodore 64

Imagine it's 1982 and you've just sat down in front of your Commodore 64. 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"[1] in the Random Graphics section of the manual caught your eye:

Imagine it's 1982 and you've just sat down in front of your Commodore 64. 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"[1] in the Random Graphics section of the manual caught your eye:

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 introducing the idea of a character code and then pointing out the importance of the number 205.5 specifically. The explanation of how the code works is followed by something even more valuable: an invitation to modify the code, change it, and make it your own based on what you've read.

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 introducing the idea of a character code and then pointing out the importance of the number 205.5 specifically. The explanation of how the code works is followed by something even more valuable: an invitation to modify the code, change it, and make it your own based on what you've read.

[Brief Corporate History Goes Here]

[Brief Corporate History Goes Here]

The manual not only gets you started with the basics, it begins to point out specific ways that you can tweak the program to change how it functions. It begins with the value 205.5. When this number is summed with RND(1), which chooses a decimal between 0 and 1, the result is a value between 205.5 and 206.5. 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.

The manual not only gets you started with the basics, it begins to point out specific ways that you can tweak the program to change how it functions. It begins with the value 205.5. When this number is summed with RND(1), which chooses a decimal between 0 and 1, the result is a value between 205.5 and 206.5. 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.

Great, you have not only learned to program a maze, but you have also learned how to modify it by controlling the ratio between the "/" and "\" characters that form it. But what exactly did you change? There is no code that explicitly sets the probability of either character appearing on the screen. You never even tell the C64 that it should round off the fractional 205.x and 206.x values to whole numbers. You achieved the effect of changing the character's frequency indirectly by taking advantage of the programming environment of BASIC and the inherent properties of the Commodore 64 platform.

Great, you have not only learned to program a maze, but you have also learned how to modify it by controlling the ratio between the "/" and "\" characters that form it. But what exactly did you change? There is no code that explicitly sets the probability of either character appearing on the screen. You never even tell the C64 that it should round off the fractional 205.x and 206.x values to whole numbers. You achieved the effect of changing the character's frequency indirectly by taking advantage of the programming environment of BASIC and the inherent properties of the Commodore 64 platform.

Computer languages are like any other written language in that a certain set of assumptions must be shared between those who are reading them before they can make any sense. Writers in French have agreed to read from the left side of a page to the right side, whereas Arabic writers go from right to left. An English apostrophe has been agreed to have a functional meaning that is determined by the reader seeing it in the context of its surrounding text. Similarly, BASIC also makes some assumptions about the meaning of the code a programmer writes, including the expectation that the function CHR$(x) will only have values of x that are whole numbers. The fact that BASIC is running on the Commodore 64 specifically introduces even more assumptions, like the idea that a screen will always be 40 characters wide. A few of the unspoken agreements between programmers, BASIC, and the Commodore 64 include:

Computer languages are like any other written language in that a certain set of assumptions must be shared between those who are reading them before they can make any sense. Writers in French have agreed to read from the left side of a page to the right side, whereas Arabic writers go from right to left. An English apostrophe has been agreed to have a functional meaning that is determined by the reader seeing it in the context of its surrounding text. Similarly, BASIC also makes some assumptions about the meaning of the code a programmer writes, including the expectation that the function CHR$(x) will only have values of x that are whole numbers. The fact that BASIC is running on the Commodore 64 specifically introduces even more assumptions, like the idea that a screen will always be 40 characters wide. A few of the unspoken agreements between programmers, BASIC, and the Commodore 64 include:

<blockquote>10 PRINT CHR$(205.5+RND(1));: GOTO 10</blockquote>

<blockquote>10 PRINT CHR$(205.5+RND(1));: GOTO 10</blockquote>

<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>

''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).

''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).

[[Image:PET_Keyboard.png|thumb|400px|The PET 2001 chicklet keyboard, with the visually complementary arrangement of graphic characters on the keys.]]

[[Image:PET_Keyboard.png|thumb|400px|The PET 2001 chicklet keyboard, with the visually complementary arrangement of graphic characters on the keys.]]

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.

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.

<blockquote>'''''Set background color to dark blue'''''<br />

<blockquote>'''''Set background color to dark blue'''''<br />

[[File:10print-colors.gif|600px|thumb|center|10-Print with the colors changed]]

[[File:10print-colors.gif|600px|thumb|center|10-Print with the colors changed]]

<blockquote>''Set background color to dark blue''<br />

<blockquote>''Set background color to dark blue''<br />

[tk-Somebody with more experience in using raster mode than me (John) might want to write this; alternatively, I can come back to it when I have more time for research.]

[tk-Somebody with more experience in using raster mode than me (John) might want to write this; alternatively, I can come back to it when I have more time for research.]

<blockquote>''Set background color to dark blue''<br />

<blockquote>''Set background color to dark blue''<br />

[[File:10-print-poke.gif|600px|thumb|center|10-Print using POKE instead of PRINT]]

[[File:10-print-poke.gif|600px|thumb|center|10-Print using POKE instead of PRINT]]

<blockquote>''Set background color to dark blue''<br />

<blockquote>''Set background color to dark blue''<br />

[[File:10-print-noscroll.gif|600px|thumb|center|10-Print without scrolling]]

[[File:10-print-noscroll.gif|600px|thumb|center|10-Print without scrolling]]

There are many ways to program a computer. This is true in the general sense--that is, when setting out to work creatively with computers, a wide range of options are available. But it is also true in a more specific way: given a particular computer and a particular idea, there are often many different ways to accomplish a goal computationally. Today's computing systems make such a fact obvious: if one wanted to produce a computer generated maze similar to 10 Print on a contemporary Mac, for example, a whole range of options are available: a UNIX command line script like BASH or Perl; a MacOS-native environment like Cocoa; a cross-platform graphics rendering library like SDL, which is often programmed in C++; a cross-platform scripting environment like Python; an object-oriented graphics sketching tool like Processing; a multimedia authoring tool like Flash, a web-based environment like Javascript and the HTML5 Canvas, and many more.

There are many ways to program a computer. This is true in the general sense--that is, when setting out to work creatively with computers, a wide range of options are available. But it is also true in a more specific way: given a particular computer and a particular idea, there are often many different ways to accomplish a goal computationally. Today's computing systems make such a fact obvious: if one wanted to produce a computer generated maze similar to 10 Print on a contemporary Mac, for example, a whole range of options are available: a UNIX command line script like BASH or Perl; a MacOS-native environment like Cocoa; a cross-platform graphics rendering library like SDL, which is often programmed in C++; a cross-platform scripting environment like Python; an object-oriented graphics sketching tool like Processing; a multimedia authoring tool like Flash, a web-based environment like Javascript and the HTML5 Canvas, and many more.

Like every BASIC program, 10 Print is high-level. It relies on abstracted operations like PRINT and RND to perform complex tasks that would require considerably greater effort to accomplish at a low-level. For this reason, it is useful to compare the BASIC version of 10 Print on the C64 with its equivalent in 6502 assembly. Doing so will help clarify what features of the program, if any, are unique to its BASIC implementation.

Like every BASIC program, 10 Print is high-level. It relies on abstracted operations like PRINT and RND to perform complex tasks that would require considerably greater effort to accomplish at a low-level. For this reason, it is useful to compare the BASIC version of 10 Print on the C64 with its equivalent in 6502 assembly. Doing so will help clarify what features of the program, if any, are unique to its BASIC implementation.

10 Print is a "native" BASIC program, which is just to say that it was originally written in BASIC for the C64, and not first rendered in assembly and later reimplemented. For that reason, no canonical assembly program exists. As with literary translation or artistic adaptation, there are multiple ways to recast a computer program from one language into another, even on a relatively simple system like the C64, and even with a relatively simple program like 10 Print. The following rendition was authored by Ian Bogost, Stephane Hockenhull, and Nick Montfort, in the context of the demo scene event @party in July 2010.

10 Print is a "native" BASIC program, which is just to say that it was originally written in BASIC for the C64, and not first rendered in assembly and later reimplemented. For that reason, no canonical assembly program exists. As with literary translation or artistic adaptation, there are multiple ways to recast a computer program from one language into another, even on a relatively simple system like the C64, and even with a relatively simple program like 10 Print. The following rendition was authored by Ian Bogost, Stephane Hockenhull, and Nick Montfort, in the context of the demo scene event @party in July 2010.

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.

Learning Through Play

Learning Through Play

Finding the Assumptions

Finding the Assumptions

[1] Commodore 64 User's Guide, p 53.

[1] Commodore 64 User's Guide, p 53.