Poetix

February 14 is Valentine’s Day for many; this year, it’s also Ash Wednesday for Western Christians, both Orthodox and unorthodox. Universally, it is Harry Mathews’s birthday. Harry, who would have been 94 today, was an amazing experimental writer. He’s known to many as the first American to join the Oulipo.

Given the occasion, I thought I’d write a blog post, which I do very rarely these days, to discuss my poetics — or, because mine is a poetics of concision, my “poetix.” Using that word saves one byte. The term may also suggest an underground poetix, as with comix, and this is great.

Why write poems of any sort?

Personally, I’m an explorer of language, using constraint, form, and computation to make poems that surface aspects of language. As unusual qualities emerge, everything that language is entangled with also rises up: Wars, invasions, colonialism, commerce and other sorts of exchange between language communities, and the development of specialized vocabularies, for instance.

While other poets have very different answers, which very often include personal expression, this is mine. Even if I’m an unusual conceptualist, and more specifically a computationalist, I believe my poetics have aspects that are widely shared by others. I’m still interested in composing poems that give readers pleasure, for instance, and that awaken new thoughts and feelings.

Why write computational poems?

Computation, along with language, is an essential medium of my art. Just as painters work with paint, I work with computation.

This allows me to investigate the intersection of computing, language, and poetry, much as composing poems allows me to explore language.

Why write tiny computational poems?

Often, although not always, I write small poems. I’ve even organized my computational poetry page by size.

Writing very small-scale computational poems allows me to learn more about computing and its intersection with language and poetry. Not computing in the abstract, but computing as embodied in particular platforms, which are intentionally designed and have platform imaginaries and communities of use and practice surrounding them.

For instance, consider the modern-day Web browser. Browsers can do pretty much anything that computers can. They’re general-purpose computing platforms and can run Unity games, mine Bitcoin, present climate change models, incorporate the effects of Bitcoin mining into climate change models, and so on and so on. But it takes a lot of code for browsers to do complex things. By paring down the code, limiting myself to using only a tiny bit, I’m working to see what is most native for the browser, what this computational platform can most **essentially* accomplish.

Is the browser best suited to let us configure a linked universe of documents? It’s easy to hook pages together, yes, although now, social media sites prohibit linking outside their walled gardens. Does it support prose better than anything else, even as flashy images and videos assail us? Well, the Web is predisposed to that: One essential HTML element is the paragraph, after all. When boiled down as much as possible, there might be something else that HTML5 and the browser is really equipped to accomplish. What if one of the browser’s most essential capabilities is that of … a poetry machine?

One can ask the same questions of other platforms. I co-authored a book about the Atari VCS (aka Atari 2600), and while one can develop all sorts of things for it (a BASIC interpreter, artgames, demos, etc.), and I think it’s an amazing platform for creative computing, I’m pretty sure it’s not inherently a poetry machine. The Atari VCS doesn’t even have built-in characters, a font in which to display text. On the other hand, the Commodore 64 allows programmers to easily manipulate characters; change the colors of them individually; make them move around the screen; replace the built-in font with one of their own; and mix letters, numbers, and punctuation with an set of other glyphs specific to Commodore. This system can do lots of other things — it’s a great music machine, for instance. But visual poetry, with potentially characters presented on a grid, is also a core capability of the platform, and very tiny programs can enact such poetry.

I’ve written at greater length about this in “A Platform Poetics / Computational Art, Material and Formal Specificities, and 101 BASIC POEMS.” In that article, I focus on a specific, ongoing project that involves the Commodore 64 and Apple II. More generally, these are the reasons I continue to pursue to composition of very small computational poems on several different platforms.

A 6 byte Commodore 64 Demo

What if I told you ... 7e 00 8d 20 d0 50 is a Commodore 64 demo

If you thought my last post about a 32 byte (plus 2 byte load address) Commodore 64 demo was esoteric, wait until you burrow into this one.

Back in March at Lovebyte I released a C64 demo that is a total of 6 bytes. I contrived this one so that the 4b of code ends up overwriting part of a zero-page routine that runs every time RETURN is pressed. The effect is a pulsing pattern on the border. (You can just as easily make the screen pulse, which I personally find less aesthetically pleasing because the pulsing in that case happens over any text that is on the screen. It’s also a bit more eye watering and more likely to trigger seizures.) While it’s a very simple effect, I don’t know of any demo at all for this platform that has this file size or any smaller one. Some extensive trickery was involved in injecting my code into existing memory contents to produce this effect.

You can download the demo, NONMONOCHROME.

For my several readers who enjoy reading 6502 assembly, here’s what I did:

; NONMONOCHROME
; 6b C64 demo (2b header + 4b)
; by nom de nom/TROPE

; RETURN to begin.
;
; This demo loops about every 1.45 seconds (on an NTSC
; machine).
;
; Holding down a key while this runs will produce an extra
; effect.
;
; RUN STOP - RESTORE will stop the program, but as soon as
; RETURN is pressed the demo will just start again. To
; restore normal function, it's necessary to power-cycle
; the C64.

.outfile    "nonmonochrome"

.word $007e  ; Wedge the code into CHRGET on the zero page.
.org  $007e  ; Note that CHRGET itself begins at $0073.

sta $d020    ; Set the border color with whatever's in the
; accumulator. The value varies as the code from $73
; through $7e runs. It oscillates between black and white
; for one phase and colorful for another phase. A detailed
; explanation of why is provided below.

.byte $50    ; This makes the next instruction bvc, clobbering
; $20. The following value in memory, $f0, had been used as
; beq. $50 $f0 = bvc $73, which (infinitely) takes us back to
; the beginning of CHRGET at $0073.

; A disassembly of CHRGET, left, and how it's been modified,
; right:
;
; .org  $0073                 .org  $0073
;
; chrget   inc txtptr         nonmono  inc txtptr
;          bne chrgot                  bne chrgot
;          inc txtptr+1                inc txtptr+1
; chrgot   lda                chrgot   lda
; txtptr   .word $0207        txtptr   .word $0207
; pointb   cmp #$3a                    cmp #$3a
;          bcs exit                    sta $d020
;          cmp #$20                    bvc nonmono
;          beq chrget
;          sec
;          sbc #$30
;          sec
;          sbc #$d0
; exit     rts

; CHRGET keeps increasing TXTPTR until it reaches the end of
; whatever BASIC input it's reading -- whether in immediate
; mode or when reading a BASIC program.
;
; NONMONO, however, loops forever and keeps increasing TXTPTR
; until it overflows past $ffff back to $0000.
;
; Because of the LDA TXTPTR, the accumulator is being
; consecutively loaded with each of the bytes in the C64's
; 64kb of accessible RAM and ROM. Then, after the CMP
; (which does nothing but slow the demo down by two cycles
; per loop), the contents of the accumulator are stored
; so as to set the border color.
;
; A large region of the C64's memory has $0 or $1 as the
; low nibble -- at least at power on, with no BASIC program
; loaded. Thus, black or white. Then, another large region
; (including ROM and the zeropage) has more "interesting"
; contents which manifest themselves as colors.

My demo was also taken up as an object of discussion in the first 7 minutes and 30 seconds of this YouTube video, where some of this explanation is provided as the demo runs on a C64c. This a later model of the Commodore 64, not the system I used in testing it, so the pulsing effect is slightly different. Among other things, my name for the demo, NONMONOCHROME, makes less sense when it’s running on this computer!

It could be an interesting challenge for others to try writing a Commodore 64 demo of only 6 bytes total, or of fewer bytes. For reasons I’d be glad to discuss, it seems to me that injecting the code into some productive context (an existing routine such as CHRGET or elsewhere in memory) is the only workable approach.

C64 Coding Under (Many) Constraints

Screenshot from Tyger Tyger; black and white border, scattering of orange and black characters on blue

Yesterday I wrote a little demoscene production, an intro, called “Tyger Tyger.” It’s a Commodore 64 machine language program with 32 bytes of code and the requisite 2 byte header, found on all C64 PRG files. It only garnered third place out of five entries in the 256b compos at @party 2021, behind two impressive entries that were for a different platform (DOS) and went to the limit of allowable code (eight times as much).

I wrote this intro under a formal constraint (32 bytes of machine language code) and several process constraints. Specifically, I wrote it all yesterday, mostly on a Amtrak train, finishing up the sound once I got to the party itself in Somverville. I also exclusively used a hardware Commodore 64 running Turbo Macro Pro v1.2, rather than cross-assembling the code on a contemporary computer and testing it on an emulator. To be specific, I used an unofficial hardware version of the Commodore 64 called the Ultimate 64, which is a modern FPGA implementation of Commodore’s hardware—not, however, an emulator. I placed a SID chip (a 6581) in the machine, so the only analog component that would otherwise need to be emulated was an authentic original.

Writing the code exclusively on the train provided me with some additional challenges, because the power kept cutting out and my system (which has to be plugged into AC power) shut off each time.

I’d never used any version of Turbo Macro Pro before, neither the C64 assembler nor TMPx, the cross-assembler. I figured out the basics of how to use the editor and learned the syntax the assembler used. It’s quite an excellent piece of software—thanks, Style!

And tremendous thanks to Dr. Claw, who put on a safe, responsible, demoparty—masks required when not eating, full vaccination required for all. It was a tiny one, yes, but it was a party! The event continues the important social and artistic traditions of the North American demoscene.

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 intfiction.org 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 nickm.com 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:
raster:
    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
    txa
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.
random:
    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
    tax
    dey
    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.”
    inx
    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.

((((t\*2^12018^t>>16)&42)\*(t^12)&t>>5)>>3|t\*9&(t&4^42)>>5)-1

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.

Exterior

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.

Erased...

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

All_5_C64s

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.

Morellet_and_Johns

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.