wake up! 16b: 16 Bytes of x86 Assembly Generates Fractal Video and Audio Simultaneously

The demoscene tradition of pushing hardware to its limits often produces remarkable feats of optimization, but few examples illustrate algorithmic density as starkly as 'wake up! 16b'. Released at Outline Demoparty in May 2026, this 16-byte x86 real-mode DOS assembly program simultaneously generates a visual Sierpinski fractal pattern and an accompanying audio tone through a single computational process. Its significance lies not in the end result alone, but in the specific techniques used to achieve dual-purpose output within such severe constraints.

The program begins with a standard BIOS video mode setup: int 10h initializes 40x25 text mode, pointing the data segment to 0xB800—the physical address of VGA/CGA text buffer memory. Crucially, the BIOS does not zero this memory during initialization; instead, it fills each character cell with 0x20 (ASCII space) in the first byte and 0x07 (light gray on black) in the second byte. This creates a uniform but non-zero starting state across the 2,000-character buffer (4,000 bytes total), which the algorithm relies on for predictable behavior.

The core loop consists of just six instructions: lodsb (load byte from [SI] into AL, increment SI), sub si, byte 57 (decrement SI by 57), xor [si], al (XOR AL with byte at [SI]), out 61h, al (send AL to port 61h), and jmp short L (jump to start). The net effect of lodsb followed by sub si, byte 57 is a backward step of 56 bytes per iteration. Since each character cell occupies two bytes (attribute + ASCII), this equates to moving 28 cells backward in video memory.

The fractal generation emerges from the XOR operation. When analyzing the algorithm in isolation—assuming zeroed memory, replacing XOR with ADD, and stepping forward 16 bytes—the process computes a running prefix sum across the 64KB segment. After 4,096 iterations (65,536 / 16), the segment wraps cleanly due to the 8-bit accumulator's behavior. However, the actual code uses XOR instead of ADD and steps backward by 56 bytes. This transforms the operation into a cellular automaton where each new state depends on the current cell and its left neighbor: new_state = current_state XOR left_neighbor. With the initial value of 2 (binary 00000010) implied by the uniform memory state, this isolates bit-plane 1 and produces patterns identical to Rule 60 in Stephen Wolfram's elementary cellular automata—a known generator of Sierpinski triangle patterns when visualized over time.

The audio output exploits a hardware quirk of the PC speaker. Port 61h's bit 1 directly controls the speaker cone: setting it to 1 pushes the cone outward, 0 allows it to return. Since the algorithm specifically toggles only bit 1 of AL (via the XOR operation on the isolated bit-plane), the sequence of values sent to port 61h becomes a direct waveform representation of the fractal's temporal evolution. A step size of 16 bytes would yield a fundamental frequency based on 4,096 iterations per segment sweep, but the actual -56 byte step changes the dynamics significantly.

Because gcd(56, 65536) = 8, the loop only visits memory offsets that are multiples of 8, requiring 8,192 iterations to cover all accessible addresses and wrapping the segment 7 times before returning to offset 0. This doubles the cycle length compared to a 16-byte step, halving the fundamental audio frequency (dropping it by one octave). Visually, the -56 byte step maps to a diagonal shear on the 40-column screen: moving backward 56 bytes is equivalent to moving forward 24 bytes modulo 80 bytes (the width of the text buffer in bytes). Since each character is 2 bytes, this is a 12-column shift. With gcd(12, 40) = 4, the algorithm visits exactly 10 evenly spaced vertical columns (40 / 4), ascending the screen as the fractal pattern renders.

The dual-use of memory is particularly notable. While bit 1 of each byte drives the audio output via port 61h, the remaining seven bits are written directly to the ASCII character portion of video memory. This creates a chaotic visual texture of pseudo-random glyphs alongside the structured fractal pattern in the attribute bytes. Remarkably, sending this mixed data to port 61h does not cause hardware issues in standard DOS environments or emulators like DOSBox, as the port ignores bits outside its defined function—a fortunate coincidence that enables the audio-visual coupling without additional code.

However, this elegance comes with critical limitations. The algorithm's behavior is highly sensitive to the initial state of video memory. The theoretical model assumes the uniform 0x20/0x07 pattern set by BIOS interrupt 10h, but real-world variations exist: different VGA BIOS implementations, emulator quirks, or residual data from prior execution can leave non-uniform values in upper memory regions. Since the loop continuously reads and XORs against existing memory contents, these variations directly alter both the visual output (glyph patterns and fractal shearing) and audio timbre. Achieving identical output across all hardware would require explicit memory initialization—but adding such setup would exceed the 16-byte constraint, forcing a trade-off between purity and portability.

From a technical perspective, 'wake up! 16b' exemplifies how extreme constraints can reveal unexpected synergies between computational domains. It transforms a limitation—video memory's dual role as display and storage—into a feature by exploiting the mathematical properties of XOR in cellular automata and the specific behavior of legacy hardware ports. While not a practical technique for general software development, it offers valuable insights into algorithmic reuse, emergent behavior from simple rules, and the importance of understanding hardware-specific quirks when operating at the edge of feasibility. The demo remains a compelling case study in how demoscene practices continue to explore the boundaries of what computation can achieve within minimal resources.