In an age of complex programming languages and application packages that ship with massive storage requirements, it’s easy to forget what pure assembly—low-level code that passes direct instructions to your computer’s processor—is capable of. In the case of “Wake Up!”, it only needs 16 bytes to produce a Matrix-inspired visualization with an accompanying soundtrack.
The program is what’s called an “intro”—a short, size-restricted program that… well, that does something cool, basically. The name is a demoscene term, and it originates in the introductory screens that hacking crews used to insert at the start of games on which they’d cracked the copyright protection. Today, intros largely exist for their own sake, and also to be entered into competitions to see who can do the most with the least.
There’s a host of such competitions, and “Wake Up!” recently won second place in the 128-byte category at one of the more prominent ones, Netherlands-based demoparty Outline 2026. And while the other entrants are all undeniably impressive—including the winner, Plex’s Alien Hangar, which creates a full procedural 3D environment through which a camera moves smoothly and seamlessly—many of those programs all occupied the full 128 bytes allowed by the category. “Wake Up!” achieves its effect with one-eighth of that—only 16 bytes, which frankly feels like sorcery.
The project is the work of a developer who goes by the name Hellmood, who also entered several other projects into the competition. They wrote a lengthy blog post that details how “Wake Up!” functions, and even if you’re not a programmer—and to be clear, I most definitely am not, as is about to become painfully clear—it’s still fascinating to read how one goes about creating something like this with so little actual code. So how on earth does it work?
How ‘Wake Up!’ works
Before diving into how Hellmood pulled this off, let’s look at the following code, which is “Wake Up!” in its entirety:
int 10h
mov bh, 0xb8
mov ds, bx
L:
lodsb
sub si, byte 57
xor [si], al
out 61h, al
jmp short L
To find out what’s going on, let’s take the program line by line.
The first line boots the computer into an old-style DOS window, with a 40×25 character resolution.
The second and third lines load the memory addresses for the window’s text buffer into the program’s data segment, i.e. the portion of system memory the program can use for its output. Any data in the text buffer gets printed in the text window, so these lines set up the canvas for the program to ‘paint’ and the result will be displayed on the screen.
Writing directly to the text buffer is a clever trick: usually, to print a character to the screen, a program would use an instruction to send these two bytes to the text buffer every time it ‘prints’, but this program’s output instead edits the buffer directly, cutting out instruction steps while the results still get displayed on screen as ASCII characters, thereby reducing the program’s data footprint.
DOS uses ASCII characters, which are represented in memory as two one-byte values, one of which serves as a sort of index number for the actual character, with the other specifying the character’s color. So for every two bytes in the text buffer, one character is drawn on screen. For example, if the first byte was the hexadecimal number 6F and the second was 02, you’d get a green lowercase “o”. So once these two bytes are written to the text buffer, they will automatically be displayed in the program window.
Generating the text
That’s how the text is displayed, but how is it generated? This is where it gets complicated.
If we look at the code, we see that the fourth line is essentially a bookmark, which is called “L”. The instruction on the fifth line loads the current data segment byte into a one-byte memory unit in the processor called an accumulator.
The sixth line subtracts 57 bytes from this value and stores the result in a variable called “SI”. The seventh line performs an exclusive OR operation on the value of SI and the value in the accumulator, storing the result in the accumulator and overwriting the previous data.
The eighth line we’ll come to in a bit, but the final line redirects the program back to the bookmark “L”, creating an endless loop of operations.
OK, but what’s happening?
Even Hellmood says that “I had a hard time to grasp what’s really going on,” so if your head hurts (like mine did), don’t feel too bad. As I understand it, each processor clock cycle, the program starts at a given memory location, looks at the value stored in that location, and then loads it into the accumulator.
It then subtracts 57 bytes from that value, performs an exclusive OR operation using the two inputs, and loads the result back into the accumulator. The use of the one-byte accumulator means the value in the accumulator never exceeds 255—i.e. the maximum value that can be stored in a single byte. And somehow, the method used means that the accumulator value wraps around to 2 after each 16-step “pass.” Since 02 is the ASCII code for “green”, I’m guessing this is why the text remains green, but I may be very wrong about this.
Still, regardless of the exact details, the point is that the program generates a loop of values that are expressed on screen as characters. This is where the visuals come from.
What about that beat?
But what about the music? For this, we need to understand how x86 assembly interfaces with the ancient PC speaker. It’s the simplest interaction possible: sending a 1 to the speaker causes its cone to be pushed out, while a 0 pulls it back in again. This is what the eighth line of code does—it outputs the eight bits in the accumulator to the speaker.
And the thing is, these eight bits repeat over and over, which makes them effectively square waves. On their own, these waves would produce clean, pleasant tones. This is clearly not what we hear—instead, the soundtrack is a kind of distorted, pulsing rhythm. This is because, as Hellmood explains, it’s not just the square waves that are output to the speaker; it’s also the “shadowed video ROM BIOS code.”
What does this mean? As far as I can tell, old PCs often cached the code stored in relatively slow ROM into quicker RAM to speed up performance—and in this case, the cached BIOS code that governed the video hardware’s operation is lurking at the far end of the program’s memory space. It’s never overwritten by the program’s output (which is good, otherwise the whole thing would probably crash), but it does get swept up into the information sent to the speaker. In doing so, it provides what Hellmood calls “the secret ingredient to the punky and gritty sound that differs quite a bit from the expected Sierpinski line based overlayed rectangle wave bytebeat.”
So, there you have it. That’s how you generate some cool-ass music and a kinda hypnotic pattern of characters in 16 bytes. If you didn’t understand it all, then never fear, neither did I. (And if you did, please feel free to tell me in the comment section what I got wrong!) But either way, the result is undeniably cool.
