A Commodore 64 at Airport Security

Friday 25 January 2013, 7:28 pm   //  

Boston: No reaction.

Seattle: “No, for real?” “Yes, for real.” “That was my first computer!” “How old is that thing?” “It’s from 1982.” “Hey, that used to be state of the art! But now -” [TSA agent takes phone out of pocket, points to it.] “This has got more processing power!”

Los Angeles: “Sir, please come with me.” [TSA agent swabs power supply for explosives.] “Can you tell me what this is for?” “It’s a computer.” [Older TSA agent arrives.] “Hey! A Commodore 64! That’s a classic!”

10 PRINT Reading / Release Party

Thursday 18 October 2012, 4:04 pm   //////////  

10 PRINT cover

Our first event for 10 PRINT is scheduled for:

Monday
November 12, 2012
7pm

at the

Harvard Book Store
1256 Massachusetts Ave.
Cambridge, MA.

This means, of course, that the book will be printed and available for sale by then, which is less than a month from now.

The Harvard Book Store is an independent book store in Harvard Square, founded in 1932.

Of the ten authors of 10 PRINT, we’re planning to have at least me (Nick Montfort), Patsy Baudoin, and Noah Vawter there for some reading from the book, comments on the titular program and the writing of the book, and discussion. The reading is free and takes place at the bookstore itself, as the page on the event explains.

One-Line C64 BASIC Music

Monday 26 July 2010, 1:10 pm   ////////  

Local sound artist/electronic musician Keith Fullerton Whitman released an extraordinary piece on the b-side of his November 2009 cassette hallicrafters, inc. The piece is called 10 poke 54272+int(rnd(1)*25),int(rnd(1)*256) : goto 10 and is 18 minutes of sound produced by a Commodore 64 emulator running the BASIC program that is the title of the piece.

The memory locations beginning at 54272 are mapped on the Commodore 64 to the registers of the SID (Sound Interface Device). By POKEing random values into them, the SID, although it is a musical chip, is stimulated to produce sounds in what probably seems like a non-musical way: based on the effect of register settings and the sequence produced by the system’s random number generator, a polynomial counter.

I’m listening to the piece running on a hardware C64 now, which is soothing, although it seems like it shouldn’t be. Looking at the code, I note that the program

10 poke 54272+rnd(1)*25,rnd(1)*256 : goto 10

will put the same values into the same memory locations (and therefore SID registers) in the same order. The INT function is unnecessary because all arithmetic in C64 BASIC is done in floating point and then cast to integer whenever necessary. It’s possible that removing these functions will cause the piece to speed up, however, and I suspect it will, even though a BASIC interpreter could skip the unnecessary INT calls to begin with. There would be various ways of determining this, but the one I’d like to try involves getting two C64s, each with one version of the program, and seeing if they go out of phase.

By the way, I say that these two programs will put the same values in the same order because RND(1) returns a deterministic sequence. Any time either of these programs is invoked before other calls to RND are made, they will produce the same sequence. Using RND(0) would seed the random number generator on the jiffy clock, so would do different things depending upon how long the computer had been on before startup.

Thanks to sound artist and digital media scholar Kevin Driscoll, a.k.a. Lone Wolf, for letting me know about this.

Update: Hilariously, I overlooked that Whitman is not the author of this program – he credits Noah Vawter, a.k.a. Shifty, who is currently collaborating with me on a project about a one-line Commodore 64 BASIC program. I guess I was too distracted by that picture of an iPhone running a C64 emulator.

« Previous Page
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
(c) 2017 Post Position | Barecity theme