Tag: demoscene

Posted on

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.

Posted on

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.

Posted on

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

Taper #2 Is Out

The second issue of Taper, a literary magazine featuring small-scale computational work, is now online.

The second issue was edited by Sebastian Bartlett, Lillian-Yvonne Bertram, Angela Chang, Judy Heflin, and Rachel Paige Thompson, working collectively. Bad Quarto (my micropress) publishes the journal.

The call for issue #3 is posted. The deadline is February 18 (2019).

Taper #2 features 18 works by six a., Sebastian Bartlett, Kyle Booten, Angela Chang, Augusto Corvalan, Kavi Duvvoori, Esen Espinsa, Leonardo Flores, Judy Heflin, Chris Joseph, Vinicius Marquet, Stuart Moulthrop, Everest Pipkin, Mark Sample, and William Wu. Go take a look!

Posted on

My @party Talk on Computer-Generated Books

I just gave a talk at the local demoparty, @party. While I haven’t written out notes and it wasn’t recorded, here are the slides. The talk was “Book Productions: The Latest in Computer-Generated Literary Art,” and included some discussion of how computer-generated literary books related to demoscene productions.

Posted on

Salon 256 on May 1

SALON 256 is a forum for presentation and discussion of very small creative computer programs. Such programs have featured in digital art and poetry, electronic literature, computer music, and the demoscene.

YOU are invited to present a tiny program of yours:

Monday May 1 . 5pm-7pm . MIT’s 14E-304

Presenters already confirmed:

  • Mike “Dr.Claw” Piantedosi
  • Angela Chang
  • Sofian Audry
  • Nick Montfort
  • Chris Kerich
  • Willy Wu
  • Henry Lieberman
  • Doug Orleans

Programs in an interpreted language are fine, as long as the code is 256 bytes or less; compiled programs with an executable file of 256b or less are fine, too.

Building 14 also holds the Hayden Library and is not Building E14.
If you’d like to present, leave a comment or sign up at the event.

A Purple Blurb / The Trope Tank production.

Posted on

Tiny Trope Tank Productions

Recently, at the suggestion of our writer in residence, Milton Läufer, we in the Trope Tankt have been producing digital files for discussion at meetings. These productions, almost always computer programs but not constrained to be such, must be at most 256 bytes.

It’s been extremely productive in terms of thinking about digital media, platforms and programming languages, and how we approach creative projects — and even other projects — generally. Postdoctoral researcher Sofian Audry prompted us to discuss this some at the last meeting.

So far we have three sets of 256b files which have landed in this directory, organized by date and with file names that indicate who wrote what:

http://nickm.com/trope_tank/256/

They include work by RA Chris Kerich, who has produced rather demoscene-like visual effects using Python running in a terminal, and by postdoctoral researcher Angela Chang, who has provided short example programs for use in teaching. Angela’s examples show that you don’t have to have hypercompressed, confused code when you write short, interesting programs. You can value clarity and pedagogical usefulness if you like, or you can pack in as much as possible, for instance, in order to produce a visual effect.

Sofian has explored creative computing history by writing a 256b Commodore 64 BASIC program that implements, or at least strongly refers to, the classic Lemonade Stand BASIC program. Milton has generated various compelling visual displays. His and Chris’s most recent programs are less clearly mathematical and regular, instead imitating the natural world.

It was very apropos that Christian Bök pointed me to Dwitter, a framework for making tiny programs that can be easily shared on the Web, just recently. I’m sure we’ll all dig into that soon.

My pieces include one bash script, one Python 3 program, and an executable of 256b written in assembly for the Commodore 64. The Python 3 program is actually a very tiny text adventure, Wastes, and is listed on the Interactive Fiction Database. In fact, I’m pleased to see that at this point, it has one four-star (our of five) review!

Posted on

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

Posted on

This Issue is Full of the Demoscene

It’s also in Polish, and should serve to inspire Anglophones! As my colleagues in Ubu’s homeland explain:

Ha!art 47 demoscene

Last November, the independent Polish publishing house Korporacja Ha!art devoted an issue of its quarterly to the demoscene, a hacker subculture dedicated to creating multimedia computer programs on retro platforms. What we attempt to chronicle is a half-forgotten, mostly European scene of hard-core coders and ephemeral groups, who dedicate hundreds of sleepless nights with their Amigas and Spectrums, trying to outdo one another, to write terser code, to come up with new visual effects, to wow the audience. In the pre-Internet era, they even came up with their own publication and distribution channels. Always eager to present what is little known and under-researched, we trace the roots of the movement in the 1980s and its growth in Piotr Czerski’s exhaustive article; we look more closely at various platforms that formed the core of demoscene (Amiga, ZX Spectrum, Commodore) and at Polish wizards of code (some of whom, interestingly, looked up to Russian hackers); our authors tackle all sorts of ideas from the interplay between demoscene and glitch to schizophrenia as a tool of interpretation in media analysis. They also ponder the problematic relations between flashy, seemingly puerile demoscene productions and digital literature in an attempt to find the missing link in the evolution of electronic art. Trips down the memory lane by Jakub Noniewicz and Yerzmyey let us see demoscene forays into the world of (often irreverent) short stories and generative poetry. In fact, this kind of textual approach to demoscene has not been attempted before. We show how coders, working collaboratively, used computationality and tried multiple genres to bring the lexical and the audiovisual together. Last but not least, the perspectives of guests from across the Atlantic, Val Grimm and Nick Montfort, show how demoscene is, at heart, about breaking free from societal constraints.
The issue is part of Korporacja Ha!art’s effort to present seminal scholarship in digital media.

Posted on

“Textual Demoscene” by Piotr Marecki

A Trope Tank Technical Report (“Trope Report”) on the “Texual Demoscene” has just been posted. Here’s the abstract:

The demoscene is a mainly European subculture of computer
programmers, whose programs generate computer art in real time. The
aim of this report is to attempt a description of the textual
dimension of the demoscene. The report is the effect of efforts to
perform an ethnographic exploration of the Polish computer scene; it
quotes interviews with participants of demo parties, where text
plays a significant role: in demos, real-time texts, IF, mags or
digital adaptations. Media archeology focusing on the textual aspect
of the demoscene is important to understanding the beginnings of
digital literature and genres of digital-born texts.

Piotr Marecki really goes to the “ends of the earth” to investigate this, even reporting on a Polish demoscene production that is a text game and is called The Road to Assland. Here’s the full report.

Posted on

New Report on Nanowatt & World Clock

The latest technical report (or “Trope Report”) to issue from the Trope Tank is TROPE-14-01, “New Novel Machines: Nanowatt and World Clock“ by Nick Montfort:

>My Winchester’s Nightmare: A Novel Machine (1999) was developed to bring the interactor’s input and the system’s output together into a texture like that of novelistic prose. Almost fifteen years later, after an electronic literature practice mainly related to poetry, I have developed two new “novel machines.” Rather than being works of interactive fiction, one (Nanowatt, 2013) is a collaborative demoscene production (specifically, a single-loading VIC-20 demo) and the other (World Clock, 2013) is a novel generator with accompanying printed book. These two productions offer an opportunity to discuss how my own and other highly computational electronic literature relates to the novel. Nanowatt and World Clock are non-interactive but use computation to manipulate language at low levels. I discuss these aspects and other recent electronic literature that engages the novel, considering to what extent novel-like computational literature in general is becoming less interactive and more fine-grained in its involvement with language.

This was the topic of my talk at the recent ELO conference. Share and enjoy!

Posted on

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.

Posted on

Waves 3 Ways at @Party

codewiz and I (nom de nom) showed a wild demo at @party yesterday (June 14) at MIT.

It was “Waves 3 Ways (Topsy’s Revenge).” Indeed, there’s video.

Tesla coilThe concept is based on one-line C programs to generate music, the earliest of which were by viznut. I (nom de nom) wrote a C expression in this style to generate a waveform that could be output as sound but
also consisted of all printable ASCII characters. The source is about 1kb, without much effort at compression. And the sound, in addition to driving speakers, can be (and was) connected to a Tesla coil.

To connect the oneTesla coil he built, codewiz modified the firmware and the control box to allow the audio output to be read by the potentiometer input. He also wrote dsptee.c to improve the way the text scrolls.

Topsy was the elephant electrocuted by Thomas Edison in 1903 to help prove that AC electricity (advocated by Tesla) was unsafe.

My main disappointment was that the projector, which I thought would be HD and thus the same as my display, showed only the left-hand side of the video. I should have checked it more thoroughly before we got started.

We were very pleased to get second place behind a nice oscilloscope demo.

Title sequence from 'Waves 3 Ways'

We signed the production, too, although it's not very visible when it's running.

The final section of the demo is based on the bpNichol poem “Island,” part of his Apple IIe collection First Screening. This poem, in turn, refers to a concrete poem by Ian Hamilton Finlay. I’ve put a video/screencast of the end of the production online.

Posted on

Bitcoin for your Warhol!

Thanks to Golan Levin’s “atypical, anti-disciplinary and inter-institutional” FRSCI lab, the CMU Computer Club, and ROM hacking bit-boy Cory Archangel, several instances of previously unknown visual artwork, done by Andy Warhol on the Amiga 1000 in 1985, have been recovered.

CA$H for your WARHOL sign

Warhol’s use of this classic multimedia system is but one of the many surprising, rich aspects of Amiga history that are carefully detailed by Jimmy Maher in The Future Was Here: The Commodore Amiga. An early topic is the launch of the first Amiga computer at the Lincoln Center, with Andy Warhol and Debbie Harry in attendance and with Warhol producing a portrait of her on the machine during the festivities. Maher also writes about how Warhol’s attitude toward the computer was actually a bit retrograde in some ways: Rather than thinking of the screen as a first-class medium for visual art, he wanted better printers that could produce work in a more conventional medium. The discussion of Warhol’s involvement is but one chapter (actually, less than one chapter) in a book that covers the Amiga’s hardware development, technical advances, relationship to image editing and video processing work, and lively demos — from the early, famous “Boing Ball” demo to the productions of the demoscene. The Future Was Here is the latest book in the Platform Studies series, which I edit with Ian Bogost.

The Future Was Here cover

With these images surfacing now, after almost 30 years, the age-old question “soup or art?” is awakened in us once again. Do we need to print these out to enjoy them? To sell them for cash? Did Warhol invent what is now thought of as the “MS Paint” style, back on the Amiga 1000 in 1985?

Amiga soup can

Note, finally, that there is a detailed report on the recovery project provided in PDF form.

Posted on

No Code: Null Programs

Just posted: **TROPE-13-03 – No Code: Null Programs** by Nick Montfort, in the Trope Report series (technical reports from my lab the Trope Tank at MIT).

>To continue the productive discussion of uninscribed artworks in Craig Dworkin’s _No Medium,_ this report discusses, in detail, those computer programs that have no code, and are thus empty or null. Several specific examples that have been offered in different contexts (the demoscene, obfuscated coding, a programming challenge, etc.) are analyzed. The concept of a null program is discussed with reference to null strings and files. This limit case of computing shows that both technical and cultural means of analysis are important to a complete understanding of programs – even in the unusual case that they lack code.

Please share and enjoy. And do feel free to leave a comment here if anything to add on this topic, or if you have a question about this report. I’d be glad to continue the discussion of these unusual programs.

Posted on

Video of Nanowatt Online

A single-loading VIC-20 demo (3583 bytes) presented on November 30, 2013 at Récursion in Montréal. By Nick Montfort, Michael C. Martin, and Patsy Baudoin (nom de nom, mcmartin, baud 1). This video is of the demo running in the Trope Tank at MIT on December 3, 2013.

Tagged on YouTube as Commodore VIC-20, Samuel Beckett, Electronic Literature, Computer (Musical Instrument), and Demoscene. See also the fuller story about Nanowatt with links to executable code.