I'm more impressed by the eerie beauty of it than the technical achievement, even if the code was orders of magnitude larger it would still be wonderful.
"Spongy" was one of my inspirations to try something similar in 64 bytes.
Of course it's not the same, but "flying through a 3D grayscale orthogonal structure" is actually possible in 64
Apologies for the cursing, but that is the most bat shit insane demo I have ever seen. I'll just leave you with the top comment on the video: "Witches have been burnt for lesser sorcery"
I thought this was going to convert a matrix rain into sound but it does visual and sound. Amazing. And it is almost like a decent track, music is going round in my head now.
Is this a program or a secret key that unlocks a beast? Not sure!
Quite incredible. This comment is larger.
Seems like this does the reverse of the C64 demo "A Mind Is Born" (https://linusakesson.net/scene/a-mind-is-born/): that one is making music first, and simultaneously interprets it as graphics. Of course that C64 demo is huge compared to this x86 one :)
In that way the title is misleading. My original "m8trix" from 2014 already did smear pseudorandom letters across the screen ( in 8 bytes, then in 7 ) https://www.pouet.net/prod.php?which=63126 and i always wondered how i could make it "sound good". But chronologically in the development of "wakeup" the sound was first. Since you "see what you hear" it doesnt really matter, but "16 bytes that turn sierpinski sound into matrix rain" would be true too =)
For a more laid-back chill 'rain' demo, have a look at "Rainy 32b" 32-byte x86 demo:
Hey, glad you like this as well. Fun fact, i had a COVOX version which even sounded better, but didnt work sometimes ... so i handed in the "slightly worse" version xD
Ranked 6th. WriteUp is ranked 2nd. Makes one wonder about the other entries.
"Rainy" was a 32 bytes production in a (strong!) 256byte competition
"Wakeup" was a 16 bytes production in a (strong ^^) 128byte competition
Sometimes, content to size ratio wins. Other times, not so much ;)
Very impressive what people can craft in an order of magnitude fewer bytes than this comment!
Oh yes, that was one of my first demoscene productions :)
Actually, just a few days ago, i had the chance to run a modified CGA 8086 version of this on a real old piece of hardware
https://youtu.be/XLrjChvJf0k
It must be magic. I don't believe it's possible in such short snippet of code.
It kind of still is! The pure sound shouldnt even sound like that, so i have to still dig around memory configurations and initalizations (graphics card wise) to 100% explain why it sounds a tad different than it should.
Magic or mystic. Not only that it's possible, but that it could be found. I lack words.
Remarkably, sending this entire mixed-data byte directly to system port 61h, which historically manages various low-level motherboard controls, does not disrupt the system. In standard DOS environments and modern emulators, pushing these extra bits to the port is effectively harmless.
If anyone is curious what the other bits do and how the PC speaker really works:
...and I wouldn't be surprised if some chipset put more hazardous functionality in those reserved bits.
I tested this on a real FreeDos based notebook and it survived ;) But seriously, on more modern systems it doesnt do anything harmful anymore, while i have read that on older systems, you could provoke a system crash this way. Which then would create the interesting task of designing the CA in a way that it "avoids" the hazardous values. For now it seems that "anything goes", at least on all my semi-old and newer systems. DosBox Emulators literally dont care ;)
How does the sierpinski fractal relate to the rain effect?
TLDR: Each time step, another sierpinski triangle line is a) played on the speaker b) drawn to the screen with stepsize of 56. You can sense the motion, but not really see it, since it's 8192 "pixels wide" but one line of chars is just 80 bytes. One a much much much bigger screen, you could see the triangle. Or, if you dont "skip pixels" and draw it all at once, you would see it as well. In fact, i did a version at the very the same party that does that, but the specific sound gets lost on that one
Very cool!
Was super surprised the sound actually sounded coherent, versus something like static or noise.
Was it unexpected for you too or do you think there could be property of the computation that would suggest it?
It was and is still super unepxected! i created a lot of "noise" or "CA" sound intros but this one stands out. The specific spice here is how memory is initialized on "clear screen" and whats "before" and "after" the actual visible memory. The "pure" sound is also lovely (i can carefully set everything with a few more bytes to make it sound the same on all systems) but this spicy difference i still to have fully understand makes it sound even better imho =)
[dead]
"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.
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 =)
My most favourite demo is "Freespin" which runs entirely on a floppy drive without a computer. Crazy stuff.
https://www.youtube.com/watch?v=zprSxCMlECA
My favorite is 'spongy', an underwater journey through a Menger-sponge fractal in 128 bytes:
https://www.pouet.net/prod.php?which=53871
https://www.youtube.com/watch?v=36BPql6Nl_U
I'm more impressed by the eerie beauty of it than the technical achievement, even if the code was orders of magnitude larger it would still be wonderful.
"Spongy" was one of my inspirations to try something similar in 64 bytes.
Of course it's not the same, but "flying through a 3D grayscale orthogonal structure" is actually possible in 64
https://www.pouet.net/prod.php?which=78044
What. The. Actual. Fuck!
Apologies for the cursing, but that is the most bat shit insane demo I have ever seen. I'll just leave you with the top comment on the video: "Witches have been burnt for lesser sorcery"
I thought this was going to convert a matrix rain into sound but it does visual and sound. Amazing. And it is almost like a decent track, music is going round in my head now.
Is this a program or a secret key that unlocks a beast? Not sure!
Quite incredible. This comment is larger.
Seems like this does the reverse of the C64 demo "A Mind Is Born" (https://linusakesson.net/scene/a-mind-is-born/): that one is making music first, and simultaneously interprets it as graphics. Of course that C64 demo is huge compared to this x86 one :)
In that way the title is misleading. My original "m8trix" from 2014 already did smear pseudorandom letters across the screen ( in 8 bytes, then in 7 ) https://www.pouet.net/prod.php?which=63126 and i always wondered how i could make it "sound good". But chronologically in the development of "wakeup" the sound was first. Since you "see what you hear" it doesnt really matter, but "16 bytes that turn sierpinski sound into matrix rain" would be true too =)
For a more laid-back chill 'rain' demo, have a look at "Rainy 32b" 32-byte x86 demo:
https://www.pouet.net/prod.php?which=86923
https://www.youtube.com/watch?v=iCgIQuPHb5w
Hey, glad you like this as well. Fun fact, i had a COVOX version which even sounded better, but didnt work sometimes ... so i handed in the "slightly worse" version xD
Ranked 6th. WriteUp is ranked 2nd. Makes one wonder about the other entries.
"Rainy" was a 32 bytes production in a (strong!) 256byte competition "Wakeup" was a 16 bytes production in a (strong ^^) 128byte competition
Sometimes, content to size ratio wins. Other times, not so much ;)
There are several tiny demos on pouet.net, such as this 32 bytes dragon fractal: https://m.pouet.net/prod.php?which=63522
Very impressive what people can craft in an order of magnitude fewer bytes than this comment!
Oh yes, that was one of my first demoscene productions :)
Actually, just a few days ago, i had the chance to run a modified CGA 8086 version of this on a real old piece of hardware https://youtu.be/XLrjChvJf0k
The same author wrote a long writeup a number of years back on their other demo "Memories." It is a great read! http://www.sizecoding.org/wiki/Memories
It must be magic. I don't believe it's possible in such short snippet of code.
It kind of still is! The pure sound shouldnt even sound like that, so i have to still dig around memory configurations and initalizations (graphics card wise) to 100% explain why it sounds a tad different than it should.
Magic or mystic. Not only that it's possible, but that it could be found. I lack words.
Remarkably, sending this entire mixed-data byte directly to system port 61h, which historically manages various low-level motherboard controls, does not disrupt the system. In standard DOS environments and modern emulators, pushing these extra bits to the port is effectively harmless.
If anyone is curious what the other bits do and how the PC speaker really works:
https://fd.lod.bz/rbil/ports/keyboard/p0060006f.html#table-P...
https://forum.vcfed.org/index.php?threads/pc-speak-technical...
...and I wouldn't be surprised if some chipset put more hazardous functionality in those reserved bits.
I tested this on a real FreeDos based notebook and it survived ;) But seriously, on more modern systems it doesnt do anything harmful anymore, while i have read that on older systems, you could provoke a system crash this way. Which then would create the interesting task of designing the CA in a way that it "avoids" the hazardous values. For now it seems that "anything goes", at least on all my semi-old and newer systems. DosBox Emulators literally dont care ;)
How does the sierpinski fractal relate to the rain effect?
TLDR: Each time step, another sierpinski triangle line is a) played on the speaker b) drawn to the screen with stepsize of 56. You can sense the motion, but not really see it, since it's 8192 "pixels wide" but one line of chars is just 80 bytes. One a much much much bigger screen, you could see the triangle. Or, if you dont "skip pixels" and draw it all at once, you would see it as well. In fact, i did a version at the very the same party that does that, but the specific sound gets lost on that one
https://www.pouet.net/prod.php?which=106206 https://www.youtube.com/watch?v=OVk-iP93ZEs
Very cool! Was super surprised the sound actually sounded coherent, versus something like static or noise. Was it unexpected for you too or do you think there could be property of the computation that would suggest it?
It was and is still super unepxected! i created a lot of "noise" or "CA" sound intros but this one stands out. The specific spice here is how memory is initialized on "clear screen" and whats "before" and "after" the actual visible memory. The "pure" sound is also lovely (i can carefully set everything with a few more bytes to make it sound the same on all systems) but this spicy difference i still to have fully understand makes it sound even better imho =)
[dead]
"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:
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:
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: Visualizing Bit 1 propagation over 5 passes (X = set): 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
Great stuff!