Nerd content and
cringe since 1999
Alexander Grupe


A 512-byte intro for Lovebyte 2024. Given that it has no effects, it might have been a good fit for the 512 byte executable music competition, but I had already squeezed out so many bytes to set up the display… :)

Edit: No, wait… the tiny executable music compo was 256 bytes max – that would have been hard.

Update: It got a place on the podium, winning 2nd place in the compo!

I wanted to do something with sizecode-compatible sample generation again, and include some algorithmic musical elements. This was inspired by last year’s exquisite Amiga entry Throwing Shapes by gigabates, worthy winner of the oldschool 512 byte compo.

So much space

Also, this was a welcome opportunity to enjoy the huge amount of extra space you get with a “half-bootblock” of 512 bytes instead of a proper Amiga executable file (like hypotrain or Arrr512) – 502* usable bytes instead of 476! Especially interesting when used in conjunction with the Salvador/ZX0 packer, which seems to be the sweet spot for payloads under 1 KB.

* That is, when using the root block trick:

        ; Boot block header (at the very start of the disk)
        dc.b    'DOS',0 ; 4 bytes: DOS header 
        dc.l    0       ; 4 bytes: checksum
        dc.l    880     ; 4 bytes: root block
        ; start of your code -- 12 bytes gone

        ; Abusing the root block field
        dc.b    'DOS',0
        dc.l    0
root:   dc.l    $dff000 ; or some other data
        move.l  root(pc),a6

        ; Now you have 4 bytes of data in a register of your
        ; choice using only 4 bytes instead of 6!
        ; move.l  #$dff000,a6 = 2c7c 00df f000
        ; move.l  root(pc),a6 = 2c7a fffa
        ; This works because the disk header is present in
        ; memory when your code is started, just as it is
        ; stored on disk.

In total, I was able to use 736 “payload” bytes for the intro. In particular:

Boot header and decruncher108 bytes
Code and data, uncompressed736 bytes
Code and data, after ZX0 compression403 bytes
Total size511 bytes


Nothing wild going on here: A snare drum, a hi-hat, two square waves. Using a sine wave as the base for the snare drum seems like overkill, but it sounds great. Originally I also had a bass drum, but I ditched that in favor of having two square wave voices.

But the samples are not really static: During playback, the widths of the square waves are constantly modified at different speeds, resulting in a nifty effect that sounds like a filter being opened and closed. Observe:

Constant square wave
Changing square wave

What stress?

I started about a week before the deadline to code some bits here and there to see how far I would come. I always wanted try the “update waveforms during playback” idea, and it turned out nice. Technically, the intro also does some kind of algorithmic music generation, even if it’s only turning single notes off and on at random.

I chose to name it “strss” during night-time development when I experimented with different notes and percussion arrangements to make it sound more interesting. At that point, it looked and sounded like this:

Ugh. I like the final version better now. And I think it’s funny to still it call it “strss”, with its calm, meditative soundscape and all.

I’m not even mad about having no proper visual effect. There should™ have been some wiggle room for something nicer, given enough time and inspiration, but with this production, that was what I was trying to avoid: strss


previous next close