“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!
WOW! That is relay all I have to say.
Agreed.
WOW! Is insufficient for this, I think we’re going to have to invent a new word!
Eagleweagleblarkblark?
Well there are no bad ideas…
Just when I thought he’d spent his 256. it continues, and continues!
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.
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).
Yeah, poor Truck. We were concerned he’ll be having a stroke over this one XD
But … HOW?
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.
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 :(
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!
Sarcasm is completely lost on you, isn’t it? :)
Wooosh….
Me thinks your sarcasm detector might need adjustment ;-)
thats_the_joke.jpeg.zip.zip.zip.zip.zip.gz.bz2.7z
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.)
Obviously being ironical. You’d zip, then run length encode, RAR, zip, RLE… etc! Tut! (DRFAy to see if this is right)
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.
Nice amount of scens, but “Puls” by Řrřola is still my favorite 256b.
https://www.pouet.net/prod.php?which=53816
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
https://www.youtube.com/watch?v=R35UuntQQF8
If they managed to hide a virus in the Youtube video, they deserve access to my computer. I’d tip my hat to them.
Puls : WOW! I can see why. Thats insane. Reading the source; the maths involved is insane.
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….
Technically you can’t make any program on a MS-DOS machine fit in 256B because the disk allocation unit is 4 kb and the memory segment unit is 64 kb.
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.
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.)
My first HD wasn’t 100 MB, it was 10 MB for $300.
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.”
Well that’s a fine example of pedantry at its worst.
Puts all those claims of bloatware into (true) perspective, doesn’t it!
I recently replaced a Java app with a C compiled x86 app. 1000 times less ram used. And probably more than a 1000 times faster, because the entire thing is cashed.
If this were a smartphone app, you’d be missing the Mega suffix
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!
Well it is math and it isn’t, I was personally taken by the Sierpinksi triangles fractal and wondered how the hell classic PC hardware could calculate that fast enough, but it was something of a trick… http://www.sizecoding.org/wiki/Memories#Sierpinski_rotozoomer
the audio has been DMCA pulled…
I’m not sure which leaves me more speechless
Only the audio of SOME part of the 7h long video. This demo is just fine. It started playing muted on my box so check the player’s speaker icon.
I am using this example to beat up my company colleagues when they whinge about not being able to fit their embedded app into 1MB… ;^)
But it’s not a DOS/Linux/Win32 FAT executable!
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?
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.
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!
That surely fits into the keyboard buffer
256 bytes is something a number human could memorize.
Now I want to see a limerick that’s actually a program.
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)
To put it into perspective, its two times an IPV6 address.
Witchcraft!!
http://www.ronybc.com/fire.php
(DOS and Win 98/XP versions)
+1 for posting the source and explanation. I feel more confident about diving into x86 assembly now.
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 !
256 bytes ?!? O, What a Luxury !
Look at this (And many other.) 128B demo.
http://www.pouet.net/prod.php?which=63518
No need to do condescending! That demo is just one effect, this demo is multiple! Did you even watch it?
One effect ? Look, displaying labyrinth and moving through it with a mouse and all in only 128 bytes ?
Did You even watch it ?
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.
Hi! The author here ;) Like mentioned in the writeup (http://www.sizecoding.org/wiki/Memories#Raycast_bent_tunnel) “Wolf128” was a good inspiration for my own “Wolf64”, basically the same, but in half the bytes ;) https://www.pouet.net/user.php?who=97586 I then included a 50 byte version into “Memories”.
The final freedos version with an extra Amiga Ball (still 256 bytes) is available =)
https://www.youtube.com/watch?v=wlW84fEHngM