The Art of Algorithmic Density: Deconstructing a 16-Byte x86 Demo

In the world of the demoscene, there is a pursuit of extreme minimalism known as "sizecoding." The goal is to produce the most visually and auditorily complex output possible using the smallest possible binary size. While many developers consider a few kilobytes to be "tiny," a recent project titled Wake up! 16b by HellMood pushes this to a staggering extreme: a fully functional program that generates both a fractal visual and a synchronized soundscape using only 16 bytes of x86 real-mode DOS assembly.

This is not merely a coding trick; it is an exercise in algorithmic density. By leveraging the initial state of hardware memory and the mathematical properties of cellular automata, the program transforms a handful of opcodes into a generative piece of art.

The 16-Byte Source

To understand the magic, we must first look at the code itself. The entire program consists of the following instructions:

int 10h          ; 2 bytes
mov bh, 0xb8     ; 2 bytes
mov ds, bx       ; 2 bytes
L:
lodsb            ; 1 byte
sub si, byte 57  ; 3 bytes
xor [si], al     ; 2 bytes
out 61h, al      ; 2 bytes
jmp short L      ; 2 bytes

At first glance, this looks like a simple loop. However, the complexity arises from how these instructions interact with the IBM PC's hardware architecture.

The Canvas: Leveraging the "Primed Void"

The program begins with int 10h, which sets the video mode to a 40x25 text grid. Crucially, when the BIOS clears the screen, it does not fill the memory with zeros. Instead, it fills the buffer with a pattern of spaces (0x20) and light gray attributes (0x07).

By pointing the data segment (ds) to 0xb800 (the VGA/CGA text buffer), the program doesn't start with a blank slate, but with a pre-existing uniform pattern. This "primed void" serves as the initial seed for the calculations that follow.

The Engine: From Additive Sums to Sierpinski

The core of the program is a loop that performs a read-modify-write operation on memory. To understand the mathematics, the author explains that if the code used add instead of xor and stepped forward by 16 bytes, it would create additive prefix sums. Over time, these sums follow a binomial sequence.

However, the program uses xor. In combinatorics, performing addition modulo two is equivalent to the XOR operation. According to Lucas's theorem, this specific operation on a binomial sequence generates the Sierpinski triangle—a classic fractal.

By using xor [si], al, the program is essentially running a cellular automaton (specifically Rule 60) across the video memory. The memory itself becomes the calculation space, and the resulting bit-patterns are what the user sees on the screen.

Synesthesia: Translating Data to Audio

One of the most impressive aspects of Wake up! 16b is that it produces sound without any dedicated audio logic. This is achieved via the instruction out 61h, al.

Port 61h is the interface for the PC speaker. Bit 1 of the byte sent to this port controls the speaker cone (1 for out, 0 for in). Because the program is calculating a Sierpinski fractal in the al register, it is simultaneously "banging" the speaker with the fractal's geometry.

This results in "bytebeats"—self-similar, tempo-invariant square waves. The sound is further enriched by the fact that the program traverses a 64KB segment. This segment contains not only the video buffer but also shadowed BIOS ROM code, adding a "punky and gritty" texture to the audio that wouldn't exist in a sterile emulator.

The 56-Byte Step: Visual Shearing and Octaves

The program does not move linearly through memory. The combination of lodsb (which increments si) and sub si, byte 57 results in a net movement of -56 bytes per iteration.

This specific offset has two primary effects:

  1. Audio Octave Shift: 56 does not divide the 65,536-byte segment evenly. The loop takes 8,192 steps to wrap around, which effectively halves the fundamental frequency and drops the sound by one octave.
  2. Visual Shearing: On an 80-column screen, moving back 56 bytes is visually equivalent to moving forward 24 bytes (12 columns). This causes the fractal to shear diagonally, appearing as ten pillars of characters moving upward, creating a "Matrix rain" effect.

The Philosophy of Sizecoding

As noted by the community, this level of density often feels like "black magic." One commenter described it as "TRULY art," highlighting the gap between modern industrial software development and the creative exploration of hardware limits.

Wake up! 16b demonstrates a fundamental truth of the demoscene: the most powerful tools are often the constraints themselves. By embracing the hardware's natural state—including its artifacts and BIOS quirks—the author transforms 16 bytes of code into a complex, multisensory experience.

Further Exploration

For those interested in the limits of code density, the following resources provide deeper insight into the culture of sizecoding:

  • Nanogems: A curated selection of the best tiny intros.
  • Sizecoding Wiki: A comprehensive guide to the techniques used to shrink binaries.
  • Rainbow Surf: Another legendary 16-byte x86 demo by Plex.

Sources