Amazing Quest Q&A

Amazing Quest should be completely open to the interpretation of players, to their appreciation of it, and, if they choose, to their rejection of it.

I refrained from discussing anything about the game during the IF Comp. Now that it’s over, I am glad to answer some questions that have arisen—with the earnest hope that my answers don’t preclude people from coming up with their own interpretations and responses.

These aren’t really frequently asked questions, but they are all actually questions that have been asked at least once. When I quote directly, the quotations are from anonymous feedback from IF Comp players. Whether quoted or in paraphrase, all of these are real questions or responses that I’ve gotten.

Q: Are you trolling? Making a joke? Playing a prank?

A: No.

Q: Why did you enter this thing, which isn’t very much like IF as we understand it, in the IF Comp?

A: Because I hoped some people would enjoy it and be provoked by it (in a positive way) when they encountered this game in the context of the Comp. That may have only happened twelve times, based on the ratings that were greater than 5, but perhaps I provided some interest and joy to these twelve players that outweighed the other players’ confusion and disappointment.

Q: As a computer program, what exactly is Amazing Quest?

A: A quasi-spoiler here, but: it is a 12-line Commodore 64 BASIC program, with each line being of the maximum length that can be typed in: 80 characters, using all keyword abbreviations and other shortcuts. That makes it the maximal Commodore 64 BASIC program that will fit on one screen. On the second half of the last logical line (line 11), which is the last physical line of the screen, I included a sort of informal all-permissive free software license.

Q: Is this an experiment?

A: I don’t find it interesting to produce any IF, other digital games, other digital literature, or other digital art, unless what I’m doing is an experiment. So, of course.

Q: Is this a parody?

A: I don’t consider it to be, since you’re asking me. If you have thoughtfully considered the game and that’s what you take away from it, I respect your view.

Q: What am I supposed to do when playing this?

A: Since you’ve asked me, I’ve tried to explain this quite explicitly in the introduction: “If you allow your imagination to help you elaborate each stop on your journey, and if you truly get into the mindset of the returning wanderer, Amazing Quest will offer you rewards as you play it again and again.” You can read that, and the game, however you want, but I’d say that Amazing Quest prompts you to imagine, from the standpoint of the main character. So, imagine.

Q: “Oh hey, it’s A Space Odyssey!”

A: For me at least, I did consider Amazing Quest to be a serious engagement with Homer’s Odyssey, and that was one of the things that motivated my work on the project. I’m glad that some people saw this aspect of the project. I hope that enriched some people’s experience of it.

Q: “I found the intro and strategy guide more compelling than the game itself.”

A: Personally I would have preferred that all elements of Amazing Quest (the introduction, the strategy guide, the BASIC game itself) had worked together to good effect for you, but I’m glad that you liked something about the project. My development of the short framing texts was meant to relate to the way that early games had similar supporting materials that were essential to the experience. In any case, I am glad someone liked these texts, because it took me a long time to type them up on my Smith Corona Classic 12 without making any mistakes.

Q: “I don’t suspect that you’re in it for the ratings.”

Only one of more than 100 games was going to win the Comp. (Well, this year it happens to be two, because of a tie—but you get my point.) I made this game for the IF Comp so that players would encounter Amazing Quest and play it in that context, in case they found it compelling in that context.

Q: “I guess the point was go ‘behind the scenes’ and read the program in BASIC? That isn’t a particularly interesting goal…”

A: It wasn’t interesting to you, but there are many people in the world. One player ported the game to BBC Micro BASIC, so it seems like the nature of this game as a BASIC program was somehow interesting to that person. Even apparently simple projects like this may have many complex aspects to them which aren’t evident at first. And perhaps only a very few people will be interested in particular aspects. So in this case, perhaps this “behind the scenes” aspect is important to the person who ported it to the BBC Micro, and maybe it will be interesting to people who know Commodore 64 BASIC very well. I’m frankly surprised that someone engaged with the BASIC program so thoroughly during the Comp. It easily could have taken a few decades for anyone to really become interested in the game’s code, if that was ever going to happen.

Q: SPOILER, select the following text to read: The player’s input has no effect on the outcome, and that’s stupid.

A: Although this isn’t a question, I’ll mention: If you understand a little more about Commodore 64 BASIC, you’d find that the user’s input does have an effect on the outcome.

Q: SPOILER, select the following text to read: Okay, but whether you answer yes or no has no effect on the outcome.

A: This, while also not a question, is true. So, let’s begin with whether this is fair to players of the game. Does that contradict anything said on the main page (“I must decide as if it all depends on me, trust as if it all depends on the gods”), within the game itself (“The gods grant victory”), in the introduction, or in the strategy guide? And in terms of how this game relates to the Odyssey, in which a character is fated to return home, alone, from the beginning, and is then brought home by the will of the gods—is there any contradiction there? To continue along these lines, even understanding this aspect of the game, if you decided to go on raids at every opportunity, plundering away, would that be any different than if you always declined to raid? Is your intentional choice irrelevant, even if the outcome is “random”? With all of this in mind, consider something more concrete and immediate. Let’s consider people who live in the United States who voted in the 2020 election. Why would they do that? Realistically, an individual’s vote had no more effect than any one particular Y/N response in Amazing Quest. Let’s heap one more thing on here, purely related to what one might call gameplay. If you want to imagine what’s going on—a journey home—why would this particular property of the game in any way stifle your imagination?

Q: Was this project motivated by anything besides the Odyssey?

A: Yes. I’ll be discussing this and other matters related to Amazing Quest at the Seattle area IF meetup, which will take place online on December 13, 2020 at 2pm PST. If you want to join, you’ll need to email the organizers; see the forum for more information. I hope this group doesn’t regret their plan to host the author of the 98th place IF Comp 2020 game! I’m certainly still looking forward to discussing Amazing Quest.

A Bit about Alphabit

During Synchrony 2019, on the train from New York City to Montreal, two of us (nom de nom and shifty) wrote a 64 byte Commodore 64 program which ended up in the Old School competition. (It could have also gone into the Nano competition for <=256 byte productions.) Our Alphabit edged out the one other fine entry in Old School, a Sega Genesis production by MopeDude also written on the train.

The small program we wrote is not a conventional or spectacular demo; like almost all of the work by nom de nom, it uses character graphics exclusively. But since we like sizecoding on the Commodore 64, we wanted to explain this small program byte by byte. We hope this explanation will be understandable to interested people who know how to program, even if they may not have much assembly or C64 experience.

To get Alphabit itself, download the program from and run it in a C64 emulator or on some hardware Commodore 64. You can see a short video of Alphabit running on Commodore 64 and CRT monitor, for the first few seconds, for purposes of illustration.

              starting here,
              these bytes load
at:     02 08 01 00 00 9E 32 30
$0808   36 31 00 00 00 20 81 FF
$0810   C8 8C 12 D4 8C 14 D4 C8
$0818   8C 20 D0 AD 12 D0 9D F4
$0820   D3 8C 18 D4 D0 F5 8A 8E
$0828   0F D4 AE 1B D4 E0 F0 B0
$0830   F6 9D 90 05 9D 90 D9 AA
$0838   88 D0 E0 E8 E0 1B D0 DB

Load address. Commodore 64 programs (PRG files) have a very simple format: a two-byte load address, least significant byte first, followed by the machine code which will be loaded at that address. So this part of the file says to load at $0802. The BASIC program area begins at $0801, but as explained next, it’s possible to cheat and load the program one byte higher in memory, saving one byte in the PRG file.

BASIC bootloader, $0802–$080c: This program starts with a tiny BASIC program that will run when the user types RUN and presses ENTER. When run, this program, a bootloader, will execute the main machine code. In this case the program is “0 SYS2061” with the line number represented as 00 00, the BASIC keyword SYS represented by a single byte, 9E, and its argument “2061” represented by ASCII-encoded digits: 32 30 36 31. When run, this starts the machine code program at decimal address 2061, which is $080D, the beginning of the next block of bytes.

Advanced note: Normally a BASIC program would need at least one more byte, because two bytes at $0801 and $0802 are needed to declare the “next line number.” You would have to specify where to go after the first line has finished executing. But for our bootloader, any non-null next line number will work as the next line number. Our program is going to run the machine code at $080d (decimal 2061) and then break. So we only need to fulfill one formal requirement: Some nonzero value has to be written to either $0801 or $0802. For our purposes, whatever is already in $0801 can stay there. That’s what allows this program to load at $0802, saving us one byte.

On the 6502: There are three “variables” provided by this processor, the accumulator (a general-purpose register, which can be used with arithmetic operations) and the x and y registers (essentially counters, which can be incremented and decremented).

Initialization, $080d–$081a: This sets up two aspects of the demo, sound and graphics. Actually, after voice 3 is initialized, it is used not only to make sound, but also to generate random numbers for putting characters on screen. This is a special facility of the C64’s sound chip; when voice 3 is set to generate noise, one can also retrieve random numbers from the chip.

The initialization proceeds by clearing the screen using the Kernal’s SCINIT routine. When SCINIT finishes, the y register has $84 in it. It turns out that for our purposes the noise waveform register and the sustain-decay register can both be set to $85, so instead of using two bytes to load a new value into y (ldy #$85), the program can simply increment y (iny), which takes only one byte. After storing $85 in those two registers, the goal is to set the border color to the same as the default screen color, dark blue, $06. Actually any value with 6 for a second hex digit will work, so again the program can increment y to make it $86 and then use this to set the border color. Finally, the y register is going to count down the number of times each letter (A, B, C … until Z) will be written onto the screen. Initially, the program puts ‘A’ on screen $86 times (134 decimal); for every subsequent letter, it puts the letter on screen 256 times — but that comes later. The original assembly for this initialization:
    iny         ; $85 works for the next two...
    sty $d412   ; voice 3 noise waveform
    sty $d414   ; voice 3 SR
    iny         ; $86 works; low nybble needs to be $6
    sty $d020   ; set the border color to dark blue
Each letter loop, first part, $081b–$0826: This loop counts through each of the 26 letters. The top part of the loop has a loop within it in which some of the sound is produced; then there is just a single instruction after that.

Fortunately, the x register already is set up with $01, the screen code of the letter ‘A’, thanks to SCINIT. In this loop, the value of the current raster line (the lowest 8 bits of a 9-bit value, to be precise) is loaded into the accumulator. The next instruction stores that value in a memory location indexed by x; as x increases during the run of the program, this memory location will eventually be mapped to the sound chip registers for voices 1 and 2, starting at $d400, and this will make some sounds. This is what gives some higher-level structure to the sound in the piece, which would otherwise be completely repetitive. After this instruction, however many characters are left to put onto the screen (counting down from 255 to 0) goes into the volume register, which causes the volume to quickly drop and then spike to create a rhythmic effect. With the noise turned on it makes a percussive sound. All of this takes place again and again until that raster line value is 0, which happens twice per frame, 120 times a second.

After all of this, the value in x (which letter, A–Z, is the current one) is transferred into the accumulator, necessary because of how the rest of the outer loop is written. The original assembly for the beginning of the outer loop:
    lda $d012   ; get raster line (lowest 8 bits)
    sta $d3f4,x ; raster line --> some sound register
    sty $d418   ; # of chars left to write --> volume
    bne raster
Get random, $0827–$0830: This code does a bit more sound work, using the x register to set the frequency. Since this is the current letter value, it increases throughout the run of the program, and the pitch generally rises. Then, a random value (well, not truly random, but “noisy” and produced by the sound chip’s noise generator) is loaded in that x register, with the program continuing to get the value until it is in the range $00–$ef (decimal 0–239). If the value has to be obtained multiple times, frequency gets set multiple times, too, adding some glitchiness to the sound. Because the random value is bounded, the program will place the characters in a 40 character × 6 line (240 character) region.
    stx $d40f       ; current letter --> freq
    ldx $d41b       ; get random byte from voice 3
    cpx #240
    bcs random
Each letter loop, last part, $0831–$083a: In the bottom part of this loop, the characters are put onto the screen by writing to screen memory and color memory. Screen memory starts at $0400, and $0590 is the starting point of our 6-line rectangle in the middle of the screen. The corresponding point in color memory is $d990. Our current character (A–Z) is in the accumulator at this point, while the x register, used to offset from $0590 and $d990, has a random value. After putting the accumulator’s value (as a letter) into screen memory and (as a color) into color memory, the accumulator is transferred back into the x register, a counter. Then the y register (counting down to 0) is decremented. The program keeps doing this whole process, the “each letter loop,” until y reaches 0.
    sta $0590,x  ; jam the current letter on screen
    sta $d990,x  ; make some colors with the value
    bne raster
Outer loop, $083b–$083f: This is the code for counting from 1 to 26, A to Z. Since the x register stores the current letter, it is incremented here. It is compared with decimal 27; if the register has that value, the program is done and it will fall through to whatever is next in memory … probably $00, which will break the program, although anything might be in memory there. It would have been nice to have an explicit brk as part of this PRG, but hey, this is a 64-byte demo with a BASIC bootloader, written one day on a train. If the program has more letters to go through, it branches all the way back up to the beginning of the “each letter loop.”
    cpx #27     ; have we gotten past ‘Z’?
    bne raster

Running All Night

A recent production of mine, Running All Night, was shown at Babycastles in New York recently during the Playdate, July 23-August 7, 2015.

The piece is a 128-byte Commodore 64 program that functions as a clock or timer. It was executing during the whole show and presented a different image every moment of the day. Here’s once glance as what it looked like as it ran on a TV turned to face the window.

Running All NIght at Babycastles

There was also a TV inside and a single page (dot-matrix printed) of the assembly source code.

@Party 2015 Productions

I had five productions (one of them a collaboration) this time around at @Party, the Boston-area demoparty.

Browser demo: “More Tongue.” This was, well, not really a standard demo, even for a browser demo, that generates nonsense poems with compact code. Like everything at demoparties, it’s been released, but I’m going to work on a post-party version, so I’m leaving the party version out of this list.

Wild: “Shortcat.”

Shortcat is a very simple encoding scheme to make bytes (thus computer programs) into pleasing Unicode tweets, IMs, etc. #demoscene

Encoder: cat x.prg | perl -pe 'binmode STDOUT,":utf8";tr/\x00-\xff/\x{2500}-\x{25ff}/;' > x.txt #demoscene

Decoder: cat x.txt | perl -pe 's/[\x00-\x7f]//g;s/\xe2(.)(.)[^\xe2]\*/chr((ord($1)-148)\*64+ord($2)-128)/eg;' > x.prg #demoscene

To decode, copy the Shortcat string to a new text file, save it, decode. ASCII (incl. spaces & newlines) will be ignored #demoscene

When decoding, don’t include other Unicode besides the Shortcat string in your selection #demoscene

Add a hashtag (e.g., #c64) and/or other info (e.g., SYS4096) to help people run the program. That’s it. Nanointros everywhere! #demoscene

Check this Tweet for an example.

Executable music: “Dial Up” by devourant & nom de nom.


Play it in an HTML5 player.

Intro: “Chronon,” a 32-byte Commodore 64 program.

PRG file. Source.

PET Code

Demo: “PET Code,” a 128-byte Commodore 64 program that is a demake of Jörg Piringer’s “Unicode.”

PRG file, demo version (runs once & ends). PRG file, looping version. Source.

Thanks to Metoikos, Dr. Claw, Luis, and other organizers and volunteers for putting this year’s party on – and to Boston Cyberarts and the sponsors of the event.

“Apple II vs. Commodore 64” Trope Tank Video

Apple Commodore videoErik Stayton’s 12-minute video “Apple II vs. Commodore 64” is now up on YouTube. It’s shot in the Trope Tank with him in conversation with me there. We discuss several of the things you’d experience in emulation, but also make reference to material specifics of these systems and the two specific computers and controllers that were used.

Erik played three quite different games that we had on hand, on disk, for both systems: Skyfox, World Karate Championship, and Hacker. Besides discussing graphics and sound quality, we also talk about the playability of these games with the controllers we have and issues such as loading times.

NYPL Builds Book Covers from PETSCII

GOTO80 tipped me off that the NYPL is experimenting with using PETSCII (the character set used on the Commodore 64 and other Commodore computers) to generate covers for e-books that don’t have them. There is also a cover generator under development that uses illustrations.

Generated covers (from the New York Public Library Labs)

The PETSCII generator is specificaly inspired by 10 PRINT, and of course, it leads leads me to ask … will they use this system to generate a cover for the e-book version of 10 PRINT?

A Companion Disk for 10 PRINT

A C64 Running the 10 PRINT DiskMartin Schemitsch (a.k.a. Martinland) has compiled and released a disk to accompany our book 10 PRINT CHR$(205.5+RND(1)); : GOTO 10, one that’s full of BASIC and assembly programs. These include the programs in the book and the later, more compact versions of our demo thread. The disk was just released at Commodore-Treffen Graz $14, and of course the disk image is available for download. It’s a nice companion to the 10 PRINT book and a Commodore 64 emulator, although, as you can see, it also works perfectly well on a vintage Commodore 64.

Happy 50th to BASIC

Dartmouth is celebrating the 50th anniversary of BASIC tomorrow with several events, including the premiere of a documentary on BASIC that I hope to see soon. I teach two classes tomorrow; those and my other meetings will make it impossible for me to stop by, even though Dartmouth is not very far away.

There’s also a celebratory Time article about BASIC, one that is packed with nice photos, scans, and GIFs showing how programs were listed and how they ran. The GIFs include a sped-up one of 10 PRINT running in an emulator, and there’s a link to 10 PRINT CHR$ (205.5 + RND (1)); : GOTO 10, our book (by Nick Montfort, Patsy Baudoin, John Bell, Ian Bogost, Jeremy Douglass, Mark C. Marino, Michael Mateas, Casey Reas, Mark Sample, and Noah Vawter).

I do genuinely appreciate the link and the article overall – there’s excellent discussion of popular programming, recollections of personally writing BASIC, BASIC in books and magazines, and even David Brin’s 2006 Salon article – but it’s too bad our book is (twice) referred to as “a book of essays” when it is actually a single book-length academic study of the title program; quite in distinction to a book of essays, it was written by the ten of us in a single voice. The book, which among other things provides the major academic study of BASIC this century, is also available for free online and anyone can download/open it in seconds to check it out. And if such a glance entices a reader, he or she may, like the popular BASIC programmer of the late 1970s and 1980s, dive further in and learn about formal, material, cultural, historical, and other aspects of the title program, the Commodore 64, BASIC, and more.

Photos from “Programs at an Exhibition”

Here’s some documentation of “Programs at an Exhibition” by Nick Montfort & Páll Thayer, an exhibit of five Commodore 64 BASIC programs and five Perl programs at the Boston Cyberarts Gallery, March 6-16, 2014.


The front of the gallery hosts a Commodore 64 running Nick Montfort’s “After Jasper Johns” (left) and an Intel/Ubuntu computer running Páll Thayer’s “Flag” (right). These two pieces respond to and rework the famous 1954 painting, Flag, which is in the collection of the MoMA. Jasper Johns, we salute you.

Take some code

Visitors are invited to take cards with all of the code to the five one-line BASIC programs and the five Perl programs that are running in the gallery. For you online visitors to this documentation, a disk image of the five C64 BASIC programs can be downloaded; VICE or another C64 emulator can be used to load, run, list, and modify the five programs on that image. (Except for “Zen for Commodore 64,” the programs do have to be retyped or broken into several lines to be modified.) Also, Páll Thayer’s entire Microcodes series, which includes the exhibited programs and which Thayer began in 2009, is online.

How to explain...

Páll Thayer’s “How to explain Perl to a dead hare,” based on the similarly-named 1965 performance by Joseph Beuys. The Perl program reads the Perl documentation aloud, one word at a time. The Perl documentation, incidentally, is really quite amusing to listen to.


Páll Thayer’s “Erased de Kooning” enacts (repeatedly, in this instance) the erasure of one of Willem de Kooning’s drawings by Robert Rauschenberg.

Not shown but also in the exhibit are Páll Thayer’s “Seedbed” and “Untitled composition.”


Nick Montfort’s five Commodore 64 programs running on five of the taupe keyboard-and-CPU units. Two of the monitors, the smaller ones, are NEC 12″ CRTs; the other three are Commodore 1702 CRT monitors. On the middle display, one of the zip paintings generated by “After Barnett Newman” can be seen.


On the left, Nick Montfort’s “After François Morellet,” which presents in one-character form all of the paintings that Morellet would have eventually painted if he continued to do other panels in his 1958 “6 répartitions aléatoires de 4 carrés noirs et blancs d’après les chiffres pairs et impairs du nombre Pi.” On the right, the instance of Nick Montfort’s “After Jasper Johns” that is running on a CRT monitor.

As with all of the programs, the complete code is presented along with the work’s title, the year of development, and the aritst’s name. The BASIC programs are also written out in a clearer form, with comments.

Not shown up close but also in the exhibit, in addition to “After Barnett Newman,” are Nick Montfort’s “Zen for Commodore 64” and “After Damien Hirst.”

10 PRINT Gets 10 SUNG

Or at least inspires a song and video…

Confounded to Corruption

The musical group Bedford Level Experiment writes of their song “Confounded to Corruption” and of the video for it:

>We’ve been reading the book 10 PRINT CHR$(205.5+RND(1)); : GOTO 10 and became very inspired by the section on procedurally generated art. All the footage in this video was generated by Commodore 64 programs written by us, including a 6502 assembly version of 10 PRINT. The lyrics were also generated algorithmically; Sonnet 64 and some commentary on it from Wikipedia were fed into an old Amiga program called NIALL, and the output was edited together into something resembling lyrics. The corruption the sonnet underwent became the theme of the song and video.

The line of verse the lyrics are based on,

>Or state itself confounded to decay

is, quite aptly, line 10 of Shakespeare’s sonnet 64.

“Programs at an Exhibition” March 6-16

Nick Montfort & Páll Thayer

Programs at an Exhibition

At the Boston Cyberarts Gallery
141 Green Street, Jamaica Plain, MA 02130
Located in the Green Street T Station on the Orange Line
Phone number: 617-522-6710

The exhibit runs March 6 through March 16.

Opening: 6pm-9pm, Thursday March 6.

A snapshot of 'After Jasper Johns,' Nick Montfort, installed at the Boston Cyberarts Gallery

Part of the life of remarkable artworks is that they are appropriated, transformed, and made new. In Programs at an Exhibition, two artists who use code and computation as their medium continue the sort of work others have done by representing visual art as music, by recreating performance pieces in Second Life, and by painting a mustache and goatee on a reproduction of the Mona Lisa. Programs at an Exhibition presents computer programs, written in Perl and Commodore 64 BASIC, each running on its own dedicated computer. The 20th century artworks reenvisioned in these programs include some by painters and visual artists, but also include performances by Joseph Beuys and Vito Acconci. All of the underlying code is made available for gallery visitors to read; they are even welcome to take it home, type it in, and run or rework these programs themselves.

The programs (Commodore 64 BASIC by Nick Montfort, Perl by Páll Thayer) re-create aspects of the concepts and artistic processes that underlie well-known artworks, not just the visual appearance of those works. They participate in popular and “recreational” programming traditions of the sort that people have read about in magazines of the 1970s and 1980s, including Creative Computing. Programmers working in these traditions share code, and they also share an admiration for beautiful output. By celebrating such practices, the exhibit relates to the history of art as well as to the ideals of free software and to the productions of the demoscene. By encouraging gallery visitors to explore programming in the context of contemporary art and the work of specific artists, the exhibit offers a way to make connections between well-known art history and the vibrant, but less widely-known, creative programming practices that have been taken up in recent decades by popular computer users, professional programmers, and artists.

The Perl programs in the exhibit are from Microcodes, a series of very small code-based artworks that Páll Thayer began in 2009. Each one is a fully contained work of art. The conceptual meaning of each piece is revealed through the combination of the title, the code and the results of running them on a computer. Many contemporary programmers view Perl as a “dated” language that saw its heyday in the early ages of the World Wide Web as the primary language used to combine websites with databases. Perl was originally developed by Larry Wall, whose primary interest was to develop a language for parsing text. Because of his background in linguistics, he also wanted the language to have a certain degree of flexibility which has contributed to its motto, “There’s more than one way to do it.” “That motto, ‘TMTOWTDI,’ makes Perl challenging for professional programers who have to take over other’s people code and may struggle to make sense of it,” Thayer said. “But it’s one of the main reasons that Perl, a very expressive programming language, appealed to me in developing this project. This flexibility encouraged Perl programmers to explore individual creative expression in the writing of functional code.”

“Páll’s work in Microcodes engages explicitly with the way computer programs are read by people and hwo they have meanings to those trying to understand them, modify them, debug them, and develop them further,” Nick Montfort said. “The Perl programs in Microcodes are quite readerly when compared to my BASIC programs. I’ve tried to engage with a related, but different documented historical tradition — the one-line BASIC program — as it works in a particular computer, the Commodore 64, and to dive into what that particular computer can do using a very limited amount of code, given these many formal, material, and historical specifics. Because my programs are harder to understand, even though they are written in a more populist programming language, I’m including versions of the program that I have rewritten in a clearer form and that include comments.” Montfort’s related projects include a collaborative book, written with nine others in a single voice, that focuses on a particular Commodore 64 BASIC one-liner. The book, published in 2012, is named after the program that is its focus, 10 PRINT CHR$(205.5+RND(1)); : GOTO 10. Montfort also writes short programs to generate poetry. These include two collections of Perl programs that are constrained in size: his ppg256 series of 256-character programs, and a set of 32-character concrete poetry generators, Concrete Perl. His book #! (pronounced “Shebang”) collects these and other poetry generators, along with their output, and is forthcoming from Counterpath Press.

Nick Montfort develops literary generators and other computational art and poetry, and has participated in dozens of collaborations. He is associate professor of digital media at MIT and faculty advisor for the Electronic Literature Organization, whose Electronic Literature Collection Volume 1 he co-edited. Montfort wrote the book of poems Riddle & Bind and co-wrote 2002: A Palindrome Story with William Gillespie. The MIT Press has published four of Montfort’s collaborative and individually-authored books: The New Media Reader (co-edited with Noah Wardrip-Fruin), Twisty Little Passages, Racing the Beam (co-authored with Ian Bogost), and most recently 10 PRINT CHR$(205.5+RND(1)); : GOTO 10, a collaboration with Patsy Baudoin, John Bell, Ian Bogost, Jeremy Douglass, Mark C. Marino, Michael Mateas, Casey Reas, Mark Sample, and Noah Vawter that Montfort organized. Nick Montfort’s site, with his digital poems and a link to a free PDF of 10 PRINT:

Páll Thayer is an Icelandic/American artist working primarily with computers and the Internet. He is a devout follower of open-source culture. His work is developed using open-source tools and source code for his projects is released under a GPL license. His work has been exhibited at galleries and festivals around the world with solo shows in Iceland, Sweden, and New York and notable group shows in the US, Canada, Finland, Germany, and Brazil. Páll Thayer has an MFA degree in visual arts from Concordia University in Montréal. He is an active member of Lorna, Iceland’s only organization devoted to electronic arts. He is also an alumni member of The Institute for Everyday Life, Concordia/Hexagram, Montréal. Páll Thayer currently works as a lecturer and technical support specialist at SUNY Purchase College, New York. Páll Thayer’s Microcodes site:

Ten programs will be exhibited, running on ten computers. Two of them, one in Perl by Páll Thayer and one in Commodore 64 BASIC by Nick Montfort, are based on the same artwork, Jasper Johns’s Flag:
Flag: Pall Thayer

Flag: Pall Thayer

Flag · Páll Thayer
Perl program · 2009

After Jasper Johns: Nick Montfort

After Jasper Johns: Nick Montfort

After Jasper Johns · Nick Montfort
one-line Commodore 64 BASIC program · 2013

The C64 in the NYT

My colleague Myke pointed out this New York Times column about the Commodore 64, which waxes nostalgic and also points out how the computer opened up possibilities for new programmers to explore and learn. Myke also pointed out, quite aptly, that the photo, which is supposed to be of a Commodore 64, is actually of a 1541 disk drive. Alas, the Grey Lady, in reference to the rainbow-logoed computer, nods…

“Programs at an Exhibition” Opens March 6

I’ll post more on this soon, but for now, let me invite you to the opening of my & Páll Thayer’s show at the Boston Cyberarts Gallery: 141 Green Street, Jamaica Plain, MA 02130, located in the Green Street T Station on the Orange Line, 617-522-6710.

The opening is 6pm-9pm on Thursday March 6.

The exhibit (which will be up March 6-16) will feature ten programs (five in Commodore 64 BASIC by Nick Montfort, five in Perl by Páll Thayer), each running on its own computer. The programs re-create aspects of the concepts and artistic processes that underlie well-known artworks, not just the visual appearance of those works. They participate in popular and “recreational” programming traditions of the sort that people read about in magazines of the 1970s and 1980s, including _Creative Computing._ Programmers working in these traditions share code, and they also share an admiration for beautiful output. By celebrating such practices, the exhibit relates to the history of art as well as to the ideals of free software and to the productions of the demoscene. By encouraging gallery visitors to explore programming in the context of contemporary art and the work of specific artists, the exhibit offers a way to make connections between well-known art history and the vibrant, but less widely-known, creative programming practices that have been taken up in recent decades by popular computer users, professional programmers, and artists.

Flag: Pall Thayer

Flag: Pall Thayer

Flag · Páll Thayer
Perl program · 2009

After Jasper Johns: Nick Montfort

After Jasper Johns: Nick Montfort

After Jasper Johns · Nick Montfort
one-line Commodore 64 BASIC program · 2013