The program is called “Introduction” – a small, size-restricted program that… well, it basically does something cool. The name is a demoscene term, and originates from the introductory screens that hacking teams used to insert at the beginning of games as they cracked the copyright protections. Today, introductions exist largely for their own sake, and are also entered into competitions to see who can do the most with the least.
There are many such competitions, and “Wake up!” Recently one of the more prominent ones, Netherlands-based Demoparty, took second place in the 128-byte category at Outline 2026. And while the other entrants are all undeniably impressive – including the winner, Plex’s Alien Hangar, which creates a fully procedural 3D environment through which a camera moves smoothly and seamlessly – many of those programs occupied the full 128 bytes allowed by the category. “Wake up!” achieves its effect with an eighth of that – only 16 bytes, which frankly sounds like witchcraft.
The project is the work of a developer known as Helmud, who also entered several other projects into the competition. He wrote a long blog post explaining how to “Wake Up!” Functions, and even if you’re not a programmer – and frankly, I certainly am not, as is about to become painfully obvious – it’s still interesting to read how someone can create something like this with so little actual code. Then how does it work?
How ‘Wake Up!’ works
Before considering how Helmud accomplished this, let’s take a look at the following code, which is “Wake up!” Completely:
int 10h
mov bh, 0xb8
mov ds, bx
L:
lodsb
sub si, byte 57
xor [si], al
out 61h, al
jmp short L
To figure 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 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, that is, the portion of system memory that the program can use for its output. Any data in the text buffer is printed to the text window, so these lines set 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 on the screen, a program would use an instruction to send these two bytes to the text buffer every time it ‘printed’, but the output of this program instead edits the buffer directly, cutting out the instruction steps while the results are still displayed as ASCII characters on the screen, 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 kind of index number for the actual character, while the other specifies the color of the character. So for every two bytes in the text buffer, one character is drawn on the screen. For example, if the first byte was the hexadecimal number 6F and the second was 02, you would 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.
generate text
This is 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 basically a bookmark, called “L”. The instruction on the fifth line loads the current data segment bytes into a one-byte memory unit in the processor called the accumulator.
The sixth line subtracts 57 bytes from this value and stores the result in a variable named “SI”. The seventh line performs a special OR operation on the value of SI and the value in the accumulator, stores the result in the accumulator and overwrites the previous data.
We’ll come to the eighth line in a bit, but the last line redirects the program back to bookmark “L”, creating an endless loop of operations.
OK, but what? Is happening?
Even Helmud says “I had a hard time understanding what exactly was going on,” so if your head hurts (as 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 at that location, and then loads it into the accumulator.
It then subtracts 57 bytes from that value, performs a special OR operation using the two inputs, and loads the result back into the accumulator. The use of a one-byte accumulator means that 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 after each 16-step “pass” the accumulator value becomes approximately 2. Since 02 is the ASCII code for “green”, I’m guessing that’s why the text remains green, but I could be very wrong about this.
Yet, regardless of the exact details, the point is that the program produces a loop of values that are expressed as characters on the screen. This is where the visuals come from.
What about that beat?
But what about music? For this, we need to understand how the x86 assembly interfaces with ancient PC speakers. This is the simplest interaction possible: sending a 1 to the speaker moves its cone out, while a 0 pulls it back in. That’s 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 are repeated over and over again, which makes them effectively square waves. On their own, these waves will produce clean, pleasant tones. This is obviously not what we hear – instead, the soundtrack is a kind of distorted, pulsating rhythm. This is because, as Helmud points out, it’s not just square waves that are output to the speaker; This is also the “Shaded Video ROM BIOS Code”.
What does this mean? As far as I can tell, older PCs often cache code stored in relatively slow ROM into faster RAM to speed up performance – and in this case, the cached BIOS code that controls the operation of the video hardware is hidden at the far end of the program’s memory space. It is never overwritten by the program’s output (which is good, otherwise the whole thing would probably crash), but it gets incorporated into the information sent to the speaker. In doing so, it provides what Helmud calls “the secret ingredient of the punky and gritty sound” that is quite different from the expected Sierpinski line based overlaid rectangular wave ByteBeat.
So there you have it. This way you create some great music and a compelling pattern of characters in 16 bytes. If you don’t understand it all, never fear, neither did I. (And if you also DidPlease feel free to let me know in the comments section what I did wrong!) But either way, the result is undeniably good.
<a href