alt.hn

4/5/2026 at 10:32:12 PM

A whole boss fight in 256 bytes

 https://hellmood.111mb.de//A_whole_boss_fight_in_256_bytes.html

by HellMood

4/7/2026 at 9:58:13 PM

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

by lucb1e

4/8/2026 at 1:31:27 AM

And it came in 5th place in the competition. The winner was this one which is 16 bytes...

https://www.youtube.com/watch?v=QKLhH_ANwIc

by philxor

4/8/2026 at 7:08:43 AM

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

by HellMood

4/7/2026 at 10:02:44 PM

I clicked on this fearing it was a "256 bytes of JS" (plus X GB of browser), and was pleasantly surprised it was actually 256 bytes.

by flopsamjetsam

4/7/2026 at 11:58:35 PM

Had a similar thought. In theory, you're right, though in practice today it's "256 bytes of binary plus X MB of DOS emulator".

by xg15

4/8/2026 at 1:13:33 AM

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.

by gmueckl

4/8/2026 at 1:29:46 AM

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

by bpeebles

4/8/2026 at 5:19:27 AM

The VBIOS is around 32-64k. The modesetting path is probably a few k.

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.

by userbinator

4/8/2026 at 2:05:05 AM

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.

by aidenn0

4/8/2026 at 7:44:36 AM

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?

by rob74

4/8/2026 at 11:18:46 AM

MIDI is a protocol for describing audio.

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.

by xnorswap

4/8/2026 at 12:50:57 PM

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

by rob74

4/8/2026 at 9:18:30 AM

Thanks :)

and yes, your observations are spot on.

by HellMood

4/8/2026 at 10:45:58 AM

256 bytes (plus X kB of BIOS) (plus Y kB of hardware schematics)

by direwolf20

4/8/2026 at 8:24:26 AM

But there's nothing stopping you running it on a real DOS machine.

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

by ErroneousBosh

4/8/2026 at 8:18:44 AM

Well, it's "256 bytes of x86" (plus X KB of VESA bios) (plus Y KB of FM synth patches) (plus Z KB of microcode) (plus...)

by TapamN

4/8/2026 at 6:08:35 AM

Or a 256 bytes prompt

by rwoerz

4/8/2026 at 9:59:16 AM

That actually deserves a competition of its own. Just what can you accomplish with a 256 bytes prompt? Or maybe 32 bytes, to compensate for expressiveness of natural language.

by TeMPOraL

4/8/2026 at 12:32:52 PM

Would that be reproducible / replayable?

by M95D

4/7/2026 at 10:21:13 PM

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.

by rustystump

4/7/2026 at 10:52:16 PM

This is probably in reference to things like Dwitter.net (https://news.ycombinator.com/item?id=46557489), where the browser (plus the Dwittet-specific runtime harness) contributes significantly higher-level functions than traditional demoscene targets like DOS PCs.

It’s just a different thing. I see no “hate”, only an expression of preference for “bare-metal” demos.

by layer8

4/8/2026 at 2:57:32 AM

Here's a 13-byte demo that runs on Chrome browsers:

    chrome://dino

by selcuka

4/7/2026 at 11:45:00 PM

It is misleading to say "I wrote X in 1k bytes" when those 1k bytes were library calls to library calls totaling 300MB.

by irishcoffee

4/8/2026 at 7:42:31 AM

Yeah, but it's a slippery slope, because no program runs in complete isolation. Even on the simplest 8 bit machines where there is no OS to speak of, you are still benefitting from the capabilities of the hardware - generating sound and music with the C64's SID takes a lot less bytes (and still sounds much better) than trying to do something comparable with more primitive hardware like the PC speaker. That's probably also the reason why this demo uses MIDI.

by rob74

4/8/2026 at 12:18:00 AM

Right... on the flipside its one thing to where it is X+minor overhead inclined lib calls

Then a whole nother level of awesome where its literally just ASM

by whaleofatw2022

4/8/2026 at 10:47:46 AM

if your OpenGL driver had a glDoACoolDemo(); function, you wouldn't be allowed to call it. But if you find that among the regular functions are some code blocks that just happen to form a cool demo, you can use them and take credit for your discovery...

by direwolf20

4/7/2026 at 10:35:58 PM

Probably because JS has larger runtime, in JS you don't have to write about most of the low level code. So it's easier to squeeze code in JS than in ASM or machine code.

by senfiaj

4/5/2026 at 10:32:12 PM

Technical write up for "Endbot" 256 bytes MSDOS program with plot, sync, sound, and payoff. Released April 4th at Revision Demoparty 2026.

by HellMood

4/8/2026 at 3:56:52 PM

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.

by gavinray

4/8/2026 at 3:31:16 AM

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.

by s3anw3

4/8/2026 at 1:55:02 AM

Audio doesn't work, but here's an emulator link

https://parkertomatoes.github.io/v86/?type=com&content=aACgB...

by parkertomatoes

4/8/2026 at 7:11:46 AM

The sound works in DosBox-X if you use the providesd config file

It also works on real old DOS PCs (or Windows XP/98 "DOS") but it would require changing a few bytes, mainly to setup UART MIDI mode

by HellMood

4/7/2026 at 9:41:14 PM

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)

by ale42

4/8/2026 at 9:16:18 AM

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

by HellMood

4/8/2026 at 4:59:13 AM

We're gonna find that Claude Mythos can do something like this in 255 bytes

by bitwize

4/8/2026 at 7:24:33 AM

Optimizing away one byte of this, given the source code? Yeah, could happen. Making a good 256 byte demo from scratch? No way.

by streetfighter64

4/8/2026 at 7:26:23 AM

I mean, give it a try?

the source is right there ;)

by HellMood

4/8/2026 at 7:22:55 AM

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

by HellMood

4/8/2026 at 7:32:10 AM

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

by rob74

4/8/2026 at 7:37:03 AM

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

by HellMood

4/8/2026 at 9:48:37 AM

What a throwback! Reminds me of older gameboy games! Really nice project!

by JoshBlythe

4/7/2026 at 10:44:27 PM

[dead]

by Anmol-Baranwal