Bad Apple!! — What a Port Proves

The claim usually made for a Bad Apple port is “it runs on X”. It is worth being precise about what that sentence establishes, because the answer varies enormously between the ports in volume three, and because the subject attracts a great deal of loose assertion.

4.1 What is actually being demonstrated

A port demonstrates one or more of four things, and they are not equally interesting.

That the display can be driven at all. The oscilloscope ports are the purest example. Nothing about the instrument is being tested — XY mode is a documented feature that has existed on analogue oscilloscopes for decades, and a signal generator drawing a Lissajous figure does the same thing with less effort. The port demonstrates that the animation can be reduced to a pair of one-dimensional signals. That is a statement about the source material, not about the instrument.

That a data rate can be sustained. The Commodore 64 demo is the clearest case. The machine’s processor is not remarkable and its graphics hardware is well understood; the demonstration is that a floppy drive notorious for being slow can be made to deliver frames faster than the display consumes them, continuously, for three and a half minutes. This is a real engineering result about the platform.

That a codec can be made small enough. The microcontroller ports at the extreme end are compression exercises with a display attached. Fitting 6,570 frames plus audio plus code into 64.5 kilobytes says nothing about the chip beyond its flash size; it says a great deal about how far domain-specific encoding beats general-purpose compression. The chip is the scoreboard, not the subject.

That a mechanism exists where none was intended. The font-file port and the structure-block port are of this kind. They are, functionally, security and capability demonstrations wearing a costume. The interesting sentence is not “a font can play video” but “a font can execute a program of its own choosing in the reader’s text renderer”.

4.2 What it does not prove

A successful port is frequently read as evidence that a device is more capable than it looks. Usually it is not.

Playing the animation requires no logic. There is no decision made, no state evolved, nothing computed from input. A device that can emit a predetermined pattern on a schedule can do it, and a great many things that are not computers can emit a predetermined pattern on a schedule — the EPROM-driven LCD project has no processor, and the breadboard project has neither processor nor memory. When a port succeeds on hardware that looks impossibly limited, the correct conclusion is usually that the display was always capable of being driven and nobody had bothered.

This is the substantive difference from the Doom comparison that is invariably drawn. Running Doom requires executing a program with branching logic, mutable state, and a response to input; a device that runs Doom is a general-purpose computer with useful amounts of memory. A device that plays Bad Apple may be a general-purpose computer, or it may be a ROM wired to a display. The two tests are not the same test, and treating “it plays Bad Apple” as the monochrome equivalent of “it runs Doom” overstates it considerably.

4.3 Where the folklore starts

The subject has a healthy mythology, and some care is warranted.

There is a widely repeated community formulation — sometimes styled “Rule 86” — holding that if a thing exists, Bad Apple can be played on it. It is a joke about the culture rather than a claim about hardware, and it should not be read as an inventory.

There is no authoritative list of ports, and there cannot be one. No registry exists. Much of the work is published only as video, a great deal is never published at all, and the boundary between a port and a novelty is undefined. Any statement about the total number of platforms, or about which was first, is unverifiable. This dive makes no such claim.

Video titles are not documentation. Several frequently cited ports were encountered during this research only as the title of an upload — including a claim of sixty frames per second on a specific Tektronix oscilloscope model driven from a single wire. Claims of that kind may well be entirely true; they simply could not be checked, and are not presented here as established. The ports in volume three were restricted to those with a writeup, a repository, or coverage in a publication that examined the work.

Encyclopaedic coverage is thinner than expected. The English Wikipedia does not maintain a standalone article on the animation; searches redirect into the Touhou Project article, which covers the series rather than the video. The remix’s release date could not be pinned down from the available sources, which variously give 2007 and 2008. For a phenomenon this widely known, the documentary base is surprisingly sparse and rests largely on the projects’ own writeups.

4.4 Why this particular video

A reasonable objection is that any monochrome animation would do. In principle, yes. In practice the choice is not arbitrary, and three properties combine.

It is already one bit deep, with no conversion loss and no dithering decisions to argue about. Its shapes are large and smooth, so it survives downsampling to display sizes where a detailed source would turn to noise. And it is instantly recognisable even at 64 by 48 in black and white, which matters more than it should: a port is a demonstration, and a demonstration that cannot be identified across the room has failed at its actual job.

To that can be added a fourth, non-technical property. It comes with a permissive derivative culture. A community norm of tolerating and encouraging derivative work is why thousands of people have felt free to re-encode, re-render and republish the animation without asking, and that norm — more than any technical property — is why the video is the one that ended up everywhere.

4.5 The honest summary

Porting “Bad Apple!!” to an unlikely platform is a display-driving exercise and a compression exercise wearing the costume of a capability test. The best of them — the breadboard with no processor, the disk-streamed C64 demo, the sixty-four-kilobyte microcontroller build — are genuine engineering with results that transfer to other problems. The bulk of them demonstrate that someone found the datasheet and had a free evening. Both are worth doing. Only the first kind proves anything.