Hacker News Reader

HellMoodon "8-pinski" – sierpinski animation and bytebeat in EIGHT bytes x86 code

Youtube Capture: https://www.youtube.com/watch?v=9A-XJjnU5Oo

    X: lds si,[bx+si]
    add al,0xad
    out 61h,al
    jmp short X+1

HellMoodon "Boing " in 64 Bytes

For 486, no FPU, for MsDos FreeDos, WinXP Dos, DosBox-X ... i made that rather in a hurry, so right now i have a version without background but wall bouncing like the original. But since the competition is already over, i will tinker a bit to make it perfect :)

the blank code for everbody who can read it ^^ you can paste it to http://twt86.co/ to run in a browser

  org 100h
  mov al,0x13
  les bp,[bx]
  int 0x10
  X: sub dh,95
  mov al,[bp+si]
  add dl,al
  imul al
  sub dh,ah
  mov bx,dx      
  mov al,bh      
  imul al        
  xchg ax,dx    
  imul al       
  add dx,ax   
  mov ch,7
  imul ax,di,byte 102
  sub ch,dh
  jle F        
  mov al,bl    
  cbw           
  idiv ch        
  add al,[bp+si] 
  xor al,bh      
  and al,16    
  mov al,31      
  jnz F           
  add al,9     
  F: stosb
  mov ax,0xCCCC
  mul di 
  adc byte [bp+si],cl 
  jmp short X

HellMoodon Multicore suppport for DOS is real – partly

Those people should also definitely check out "Mariana" (2024), a 256 byte demo from the same author, using the same techniques, which was even nominated for the Meteoriks Award for that year.

https://www.pouet.net/prod.php?which=96105

https://2025.meteoriks.org/laureates/#nominees-ota

  Features:
  - Multithreading (using all CPU cores & hyper-threads)
  - Full HD / HiColor (1920x1080 / 16 bpp)
  - 128-iterative fractal on FPU
  - Pure DOS (no drivers, no DPMI)

HellMoodon Wake up! 16b

Howdy =) I didn't spot your analysis back then, but it's (still) spot on. A tiny addition, 0xA0000 to 0xB0000 is VGA memory when using graphics modes, so it's quite safe to write there until it flows into the visual text mode memory.

HellMoodon Wake up! 16b

It requires specific graphics card setup ( it simulates an old system) Use the provided config from here https://www.pouet.net/prod.php?which=106210 Edit: for Dosbox X

HellMoodon Wake up! 16b

At the same event I released "Broccolori", a 32 Byte fractal for old-school PCs.

https://www.pouet.net/prod.php?which=106205

Related to the Dragon Fractal, with a twist:)

HellMoodon Wake up! 16b

Author of "wake up" here. Yes, that one reactivated me again. We thought (as size coding community) that we found every cellular automaton trick years ago, but then Plex came around and showed us otherwise ♥

HellMoodon Wake up! 16b

Author of "wakeup" here. You would would need between 32 and 64 bytes. I have something that almost looks like one in 32 but it's not published yet ;)

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

"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

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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 ;)

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

"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 ;)

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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 =)

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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 =)

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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 =)

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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.

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

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

HellMoodon WriteUp: 16 Bytes of x86 that turn Matrix rain into sound

"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.

HellMoodon A whole boss fight in 256 bytes

Well, it would be 2^(7*8) = 72057594037927936 possible intros. Someone/something has to generate, run and evaluate them all. Theoretically it's the "halting problem" all over, to wait for the "final output" of each intro. The 16 byte effect for example takes a while to achieve its final form. So even if it is somehow managed to evaluate 1000 intros per second, we are looking at about 2 million years of time to really test ALL possible 7 byte intros.

HellMoodon A whole boss fight in 256 bytes

Thanks :)

and yes, your observations are spot on.

HellMoodon A whole boss fight in 256 bytes

I ran a patched version of it on WinXP (DOS NTVDM), the sound works there! But it requires a few extra bytes to enable MIDI UART Mode first. On DosBox-X, this can simply be set in the config ;)

HellMoodon Revision Demoparty 2026: Razor1911 [video]

i second that. "Second Nature" is also my party favorite! https://www.youtube.com/watch?v=KFVxntafsXM&t=1764s

HellMoodon A whole boss fight in 256 bytes

it's fine, you're right ;)

i'm thinking of making that interactive, remove (a bit of) sound and plot timing (which takes surprisingly many bytes!)

but i won't spoil anything until it's ready ;)

HellMoodon A whole boss fight in 256 bytes

I mean, give it a try?

the source is right there ;)

HellMoodon A whole boss fight in 256 bytes

You can (on real MSDOS!) go as low as 6 bytes

https://www.pouet.net/prod.php?which=63538

But most people wouldn't find that visually satisfying

The technical details why this works are very interesting though :)

HellMoodon A whole boss fight in 256 bytes

I mean now that the (human written) source for this is out in the wild, of course it can ;)

HellMoodon A whole boss fight in 256 bytes

https://www.pouet.net/prod.php?which=105909

The "silent" version is only 219 bytes

A new version that adds new features into

the remaining bytes is in the works

HellMoodon A whole boss fight in 256 bytes

Absolutely!

For all lovers of 256Bb intros (and 128,64 and so on) there is a curated "best of" selection maintained by Demosceners : https://nanogems.demozoo.org/#256_byte_intros "A mind is born" is of course included there =)