HellMood
yesterday at 11:10 PM
"wake up! 16b" (Outline Demoparty, May 2026, Ommen, NL) is a 16-byte MS-DOS production that uses video memory to calculate a Sierpinski fractal and play it as audio.
Video: https://youtu.be/MvycyU-kLjg | Pouet: https://www.pouet.net/prod.php?which=106210
The 16-Byte Code:
int 10h ; Init Video Mode 0
mov bh, 0xb8 ; Setup VRAM segment
mov ds, bx
L: lodsb ; Load [SI] to AL, inc SI
sub si, 57 ; Move pointer backward
xor [si], al ; Cellular Automaton
out 61h, al ; PC Speaker output
jmp short L ; Infinite loop
1. The Canvas: `int 10h` primes the 40x25 text grid uniformly with ASCII 0x20 and color 0x07. This stable, uniform void is necessary to prevent the cellular automaton from shattering into static.
2. The Fractal (Rule 60): If this loop used `add`, it would create a binomial prefix sum:
A^(p)[k] = 2 \* C(k+p, p-1) mod 256
But substituting `add` with `xor` discards the arithmetic carry, isolating the bit-planes. This turns the math into a pure cellular automaton mapping to Wolfram's Rule 60:
Cell^(p)[k] = Cell^(p-1)[k] XOR Cell^(p)[k-1]
Visualizing Bit 1 propagation over 5 passes (X = set):
P1: X X X X X X X X
P2: . X . X . X . X
P3: X . . X X . . X
P4: . . . X . . . X
P5: X X X . . . . X
P6: . X . . . . . X
P7: X . . . . . . X
3. The Audio: Port `61h` uses Bit 1 to physically move the PC speaker cone. The Sierpinski geometry acts directly as a square-wave audio instruction: alternating bits (like P2) yield high frequencies, while sparse rows (P4) create rhythmic rests.
4. The -56 Byte Step: The pointer's net movement is -56 bytes per loop.
- Visuals: On an 80-byte wide grid, this offset shears the fractal diagonally into 10 evenly spaced, ascending vertical pillars.
- Audio: 56 does not divide the 64KB segment evenly, requiring 8,192 steps (7 full wraps) to complete a cycle. Doubling the macro-cycle halves the fundamental frequency, dropping the audio exactly one octave.
5. Hardware Quirks: The theoretical math expects zeroed memory, but the XOR operation violently collides with the BIOS's 0x20/0x07 initialization. This mutates the pure triangles into a cascade of pseudo-random ASCII glyphs. Because it relies entirely on raw RAM states, the visual and auditory output is highly sensitive to the specific machine or emulator, turning a simple mathematical quirk into a unique audiovisual fingerprint.
Well done! What were you exploring that seeded this in your mind?
Actually a) polymorphic asm instructions, like "add [bx+si],al" which is 0x0000
b) jumping into middle of instructions to save bytes and reuse opcodes
In hundreds of tiny experiments, this one stuck out, just by the sound of it. When i unfolded what's left and removed "the rest" i had a hard time to grasp what's really going on. i myself didnt expect that the explanation would go this deep for just these few bytes xD
There's lots of cool details like this which you share in this thread but aren't present in the writeup, which is a bit of a shame! I'd love to hear more about how you arrived at this sequence of bytes. Was it the same kind of process as Memories or did you have a different approach this time? How do you mean by "unfolded what's left?" Were you generating these experiments manually or automatically?
Hey, Blackle! Yeah, i agree :/ In short, for now: Manually, dozens or hundreds of them. The process was just tinkering around with CAs and sound. "What's left" is how it still sounds remarkably different than it should on a clinically clean memory segment, but in a way that i like much much better xD So the unfolding would be, why does it sound like this, and how can i steer it, and then, how can i minify it. Maybe it can be folded into the original 16 bytes as well =)
Beautiful work, as always! Great to see