That domain is such a blast from the past for me. I spent so many hours working on projects with free webhosting as a teen!
dang/HN: this domain should probably be added to the list where the subdomain is shown next to the title, since subdomains are users' webspaces. (Might be a good candidate for the public suffix list: "[DNS labels] under which Internet users can (or historically could) directly register names".)
The demoscene has a curated collection of "best 16 bytes ever"
https://nanogems.demozoo.org/#16_byte_intros
As well as 32,64 and so on ...
It even goes down to 8(!) Byte productions
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.
I think there are some standard header bytes, so the number of combinations of the interesting parts might be much smaller. Also I said less than 7 bytes, so it's actually 281474976710656 . If header bytes reduce 1 or 2 bytes, it will be 4294967296 - 1099511627776. 1099511627776 / 1000 / 60 / 60 / 24 / 365 is around 35 years.
Unless I'm overlooking something, the demo only requires DOSBox to have a machine with predefined execution speed. There are no DOS interrupt calls that I can see. Other than that, the program could probably even be trivially modified to fit in a floppy disk MBR and could potentially run without underlying OS.
To be more exact (in an excessive way), it uses the BIOS's code to set the video mode (INT 10h) which is probably a few dozen bytes (at least?) although I have been remiss at not ever reading them. And it depends on DOS configuring the memory space to leave an INT 20h call (to terminate the program) at a place that's easy to RET to. But, yeah, very little extra. But I'm not being negative at all and this is pretty nice code and on the impressive side of 256 byte demos from the 80s and 90s (and onward).
Yes, this is very minimal; if it were self-booting the INT 20h call wouldn't be needed, but there's no getting around the INT 10h, unless you specialize for very specific hardware.
The entire 5150 BIOS fit in 8k, so even if it were laden with BIOS calls (which it's not) then that would be an upper-bound.
Also, MIDI - I'm not very familiar with demo programming, but I guess using MIDI saves a lot of bytes compared to trying to do something similar with only the PC speaker?
Sure, it saves a lot of bytes compared to PCM encoded wave-form data, but it's not really cheating anything unless we also consider the red, blue and green parts of the computer monitor to be cheating because we're not outputting colours as raw wavelengths, but instead the monitor is decoding compressed signals into actual colours.
What is this "cheating" you speak of? I wasn't expressing any judgement, just saying that using MIDI helps save bytes. But now that you mention it, the bitmapped graphics that we take for granted nowadays also help (it gives you a whole memory space to work with that doesn't count towards the length of your program, rather than having to "race the beam" -https://en.wikipedia.org/wiki/Racing_the_Beam). Not sure if there's a demoscene for the Atari 2600, but that would probably be the most "bare-metal" you could get...
Why is that bad? If the bytes could easily run within the same constraint in another env/language why the hate?
I am with u on the excessive ram of browsers. It is insane. Still, it is one of the most portal and easy ways to share something. Heck, u can run a dos emulator in your browser.
This takes me back to the NES era, where developers squeezed entire worlds into a few kilobytes of ROM. What blows my mind here is that even the NES had ~40KB of program space — and this entire boss fight, complete with sprite animation, scrolling landscape, and MIDI music, fits in 256 bytes. The NES ROM header alone is 16 bytes. Incredible work.
Didn't run it (yet) but it looks nice. Great that some people are still able to optimize code! I'm wondering if this would run on actual hardware (VGA + a sound card supporting MPU401 emulation)
My favorite SNES game (Uncharted Waters 2) is a 2MB ROM.
I think about that every time I send a screenshot. The depth, complexity, and audiovisual beauty of that game stuffed into a space roughly a few times larger than a capture of my 1440p monitor in 2026.
Hate to be that guy, but I just can't help it: this is an impressive demo, but for me a "boss fight" is something interactive, which this program obviously isn't. That's probably the reason why the title of the article is (now?) simply "Endbot", while the name of the HTML file is (still?) "A_whole_boss_fight_in_256_bytes.html".
52 comments
dang/HN: this domain should probably be added to the list where the subdomain is shown next to the title, since subdomains are users' webspaces. (Might be a good candidate for the public suffix list: "[DNS labels] under which Internet users can (or historically could) directly register names".)
https://www.youtube.com/watch?v=QKLhH_ANwIc
[1] https://tromp.github.io/blog/2026/01/28/largest-number-revis...
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 :)
https://www.reddit.com/r/tinycode/comments/1se0iyt/writeup_f...
The entire 5150 BIOS fit in 8k, so even if it were laden with BIOS calls (which it's not) then that would be an upper-bound.
And it depends on DOS configuring the memory space to leave an INT 20h call (to terminate the program) at a place that's easy to RET to.
This has always been the case, and actually inherited from CP/M.
Sure, it saves a lot of bytes compared to PCM encoded wave-form data, but it's not really cheating anything unless we also consider the red, blue and green parts of the computer monitor to be cheating because we're not outputting colours as raw wavelengths, but instead the monitor is decoding compressed signals into actual colours.
and yes, your observations are spot on.
I expect someone will then say "though in practice today it's 256 bytes of binary plus a whopping 64kB of BIOS ROM and 16kB of video RAM" ;-)
I am with u on the excessive ram of browsers. It is insane. Still, it is one of the most portal and easy ways to share something. Heck, u can run a dos emulator in your browser.
https://parkertomatoes.github.io/v86/?type=com&content=aACgB...
I think about that every time I send a screenshot. The depth, complexity, and audiovisual beauty of that game stuffed into a space roughly a few times larger than a capture of my 1440p monitor in 2026.
The "silent" version is only 219 bytes
A new version that adds new features into
the remaining bytes is in the works