A Jaw-Dropping Demo In Only 256 Bytes

“Revision” is probably the Olympics of the demoscene. The world’s best tiny graphics coders assemble, show off their works, and learn new tricks to pack as much awesome into as few bytes as possible or make unheard-of effects on limited hardware. And of course, there’s a competition. Winning this year’s 256-byte (byte!) competition, and then taking the overall crowd favorite award, was [HellMood]’s Memories.

If you watch it in the live-stream from Revision, you’ll hear the crowd going (virtually) wild, and the announcer losing his grip and gasping for words. It’s that amazing. Not only are more effects put into 28 bytes than we thought possible, but there’s a full generative MIDI score to go with it. What?!?

But almost as amazing is [HellMood]’s generous writeup of how he pulled it off. If you’re at all interested in demos, minimal graphics effects, or just plain old sweet hacks, you have your weekend’s reading laid out for you. [HellMood] has all of his references and influences linked in as well. You’re about to go down a very deep rabbit hole.

The version of “Memories” presented here works in the DosBox emulator, and takes advantage of some of the particular architecture, but the general principles should be generalizable everywhere else. And if you’re not constrained to 256 bytes, such as if you’re using the comparably spacious flash ROM of any ten-cent microcontroller, you’ve got some wiggle room.

We’ve featured some pretty amazing demos in the last couple years, but they’ve been written for the incredibly luxurious SEGA Genesis and Amiga platforms. And as awesome as they are, both are characterized by sweet graphics and music that was composed using off-device resources and take up ridiculous amounts of memory in comparison. [HellMood]’s “Memories” is written, and optimized, in straight assembly.

Will we ever see more bang for the byte? We don’t expect to, but we’re more than happy to be surprised! Give us what you’ve got!

58 thoughts on “A Jaw-Dropping Demo In Only 256 Bytes

  1. I write x86 assembly for a living, and this is jaw dropping. I read HellMood’s write-up on how it was done, and i am still in awe of what HellMood did. Honestly, only a few Hackaday readers can truly appreciate how phenomenally efficient this code is.

  2. Jawdropping – very nice to see the code, although I am not an Intel code reader, I am able to grasp what is done and it is just great to see how all the timing and memory shortcuts we used to use in the 70s/80s to do graphics are “common sense” now :-)

    Really great stuff (on the input side, I mean).

    1. That guy is a ridiculous caricature of… i don’t know what – himself? A garbage truck? I really wish he didn’t represent the demo scene, especially the US – because he’s a weirdo and only makes awkward remarks and befuddled commentary. It’s time for him to retire.

  3. CLEARLY this demo was actually coded in 47 MB worth of x86 assembly and it was then pkzip’d repeatedly until it was only 256 bytes. If you unzip it 14 nested times, you will get the original size. You’ll need a crap ton of EMS to run it though :(

    1. Some people recognize a genius when they see one. Some will only see a poser…

      Clearly you have no idea pkzipping a pkzipped file will not decrease its size.

      And you are clearly following one the rules of comment sections: “Don’t read the article but comment anyway.” If you had read the article, you would see that the guy even posted the source code. And it’s not even close to 10kb of source!

        1. It might have got bigger when you gzipped it (Due to extra care to use totally unencumbered algos gzip can be a little less efficient than commercial zip implementations) but that last 7zip could have done 10%… (If turned up to max, noticed that when I zipped up a load of old DOS stuff that had been zipped with an early 2000s implementation, I just wanted to tidily package a bunch of zip files in one, but noticed 7zip managed to compress them further.)

      1. If you zip the same file over and over you will end up with a file that is one byte long.

        Yes, there are only 255 possible files out there. 0 is a reserved value.

        Not many people know that.

    1. I’d be worried about downloading that… because whoever wrote that is probably able to shoehorn a virus which routes video, audio and keyboard use to an IP address into 2 instructions

  4. Demos don’t get the attention they deserve, IMO. There’s very little else out there that combines aural/visual art and science at that level. I’d consider some of the demos out there to be among some of the greatest artworks I’ve experienced.

    As for this demo, well, I’d just like to say that I probably can’t make a hello world program fit in 256B….

      1. Technically incorrect. The “disk allocation unit” is 512 bytes on a floppy disk (and early hard disks), and the minimum amount of memory between segments is 16 bytes, which is called a “paragraph”. It is also the minimum amount one can allocate via DOS.

        1. The physical sector size remained at 512 for BIOS and HD controller compatibility but logical sector sizes ran up to 8kB with FAT16 but were often smaller, as anyone with an ounce of sense didn’t want 2000 windows ini and config files taking up 16MB of precious spinning rust when they could use smaller sector sizes on a smaller partition and only lose 4MB. (Note for the younger on disk space management “in the day”, pretend $300 only bought you a 100 GB hard drive, now pretend GB are MB, that’s where we were.)

          1. I had a full height one of those I got in a cheap XT to mess with. “How does it run?” people asked “Like a washing machine” I’d say. “Don’t you mean like a sewing machine?” me “Nope, it takes a minute to get to full spin and vibrates everything in the same room.”

  5. It’s pattern generating code like this that always blows my mind! I can’t wrap my head around how to think through these patterns and how to conceive the code to generate them.
    Where do you learn this? Is it more a mathematical exercise, and thus mathematicians are more adept at this?
    Same goes for the various patterns generated in, say, an LED cube matrix where the ball bounces around inside the cube.
    And all in 256 bytes is astounding.
    bravo!

    1. It is a DOS executable (a .com file to be specific). Admittedly this version will only run in DOSBox, and the version that will run in generic WinXP DOS is a whole seven bytes bigger. Practically scandalous I know, but hey, what were you going to do with those 7b anyway, double the length of the filename?

  6. Very impressive and more so considering the size of the instructions on that hardware.

    Not to take away from the author, Steve Wozniak’s floating point implementation for 6502 in 256 bytes is a personal favorite and his self calibrating floppy controller is equally fine. http://www.6502.org/source/floats/wozfp1.txt

    How about source code size? I have a copy of a floppy controller and file system written in Forth where the Forth source fits in a 1K “screen”. I can’t remember the compiled size.

  7. My hat is very firmly OFF to this guy! I used to write games in Z80 assembler in the 80s so I know all about right memory budgets. I was saying to myself… okay, that’s a nice compilation of 256byte demos edited together in the video. BOOM HEAD EXPLODES!

    1. Try remembering 256 bites of pie :) (that’s pi in base-256 not base-10). 256 bytes is 2048 bits of entropy. The average password contains about 30..60 bits (two words up to 10 random generated characters)

  8. One of the first(?) 256 byte compo’s held back in 1998, I managed a snake game. Looking at it years later, I looked at the source, went thru it, made changes whilst scrolling down without putting much thought into it, and quickly and easily got it down to 190 bytes without any real optimising. That just comes down to fiddling with asm for a few years, and just learning as time goes by the quick size optimisations that can easily be done… which I guess just comes down to experience. Blokes that have been mucking around with asm day in and day out for years and years, can probably just write demos in hex without giving things any real thought.

    For one of the 256 byte compo’s in 2000(?) I managed a rotating random seipinski’s triangle, after putting weeks into it. No plagerisation there. It used the big and cumbersome three random-point matrix calculation routine, was clumsy, but worked.

    Have absolutely nothing but full respect for the writers of all optimised small demos, such as ‘puls’ (mentioned above) and this ‘memories’ demo; Them dudes be knowing their stuffs !

        1. No need to be on the defensive here! You start with a smart-ass post. Handling mouse-movements in DOS isn’t that expensive in terms of bytes, and the labyrinth itself isn’t that much more impressive than even one of the effects in this demo. But whatever dude, chill.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.