This website is a gallery of tiny demos scraped from demoscene aggregator pouet.net, all MS-DOS .COM files smaller than 1024 bytes, emulated in the browser for your casual enjoyment. Some are stunning, some more basic, some interactive. Some are weird, some don't work, and others straight up crash the emulator.
But there are a lot of gems in there, and it's all there to click around and enjoy without the hassle of loading them into an emulator.
It wasn't my original idea to build this gallery. Originally, I just wanted to upgrade Demo Baker.
Back in 2020, I had a dim flicker of brain cell activity: I saw "fits in a tweet" sites like dwitter, the Windows 95 "app" was fresh in memory, and cool boot sector games were getting on HackerNews, and thought "how come no one's made an app-in-a-tweet site for x86?". Turns out they did, but I didn't notice at the time.
So I barrelled ahead and built a web-app that took an entire 512 bytes boot sector demo, encoded it as base64,
and embedded it a URL:
The site ran completely client-side from GitHub static pages, and allowed me to share links on forums to playable browser demos of interesting MBR and DOS demos I found, without needing any server-side storage. The whole x86 app fits in a link!
This year I set out to upgrade Demo Baker to use the new, dynamic WASM version of V86, improve the presentation a bit, and allow things like titles.
But I thought, 90% of the things I use this app for comes from pouet.net. What if you could just drop in a URL from a product page and automatically run the demo?
Even better, pouet has an API!
So I scripted up a test to run the demo, and... remembered why CORS exists:
pouet's API server doesn't support cross-origin browser requests, so API calls from my website to theirs won't work. And I'm too cheap and lazy to write a proxy - I want all this to be hosted statically from Github pages. So, plan A is out.
1,000 tiny demos are still tiny. If I downloaded 10,000 1k demos from Pouet, the result would be about 10MB, which doesn't sound terrible. So, plan B: What if you provided the URL, and the app fetched the appropriate demo from a secret cache?
The owners of pouet, wonderful people that they are, also provide a weekly data dump of their product index. That archive was 300MB though, too big to host in a GitHub page, so a little cleaning was needed. I wrote a NodeJS script to go through the giant JSON file and:
- Filter out demos that are larger than 1k and not DOS-based
- Strip out unneccessary metadata
- Follow the embedded link to download the demo
- Encode the demo in base64 and stuff in the JSON
Pretty straightforward... except when it wasn't:
- Many of the downloads are in .zip, .rar, .7z, .arj archives, etc.
- Some archives didn't have COM files or had COM files larger than 1k
- Many demos were linked to an HTML page like this:
- Many links were broken/unsafe/etc
But all that could be worked around. When filenames had an archive extension, I used a NodeJS 7zip binding to search them for .COM files. scene.org has beautifully static and easy to scrape HTML, so if a URL contains "scene.org" the script follows the link. And it has lots of corner case handlers for missing .COM files, bad links, etc.
In the end, 2,629 demos were successfully fetched and stored in a JSON that was about 1.411 MB long, just enough to fit on a 3.5" floppy.
[
{
"name":"HaNsA KaOs",
"id":"698",
"content":"uBMAzRB...zRC0TM0hAAAA"
}, {
"name":"Bump Is Possible",
"id":"1380",
"content":"kLkAEIzIAu...sPSTs"},
},
/* ... +2,627 entries */
]When you visit the old version of the demo baker page, it automatically started playing the boot sector pillman game by nanochess. Classic boot sector feat, but a little boring after 100 refreshes. So instead I rigged it to play a random demo from the index, and...
Cool. Refresh....
Is that depth of field!? Refresh...
Psychodelic. Refresh...
This went on for an hour before I realized, this random demo should be the whole thing. I built a gallery with back, random forward buttons, the title of each demo, and a link back to the pouet page. An <input> with <datalist> served as a good enough search bar to look demos up by title.
V86 boots FreeDOS remarkably fast - in just a few seconds, vs. my memories of waiting a minute or two for the bootup screen to test the RAM and honk the floppy drive like a horn. But it would spike my dopamine a bit better if I didn't have to wait between clicks.
Luckily, v86 has a save state API which dumps and restores RAM. I rigged the website to save the state two seconds after the emulation started - just before startup finished.
The result is 8MB, which is big but will compress well with gzip. Now, right after starting emulation, it loads the save
At this point, I realized there really needs to be a link on each demo to the author's page. So, I wrote one last script to augment the demo list with the author using the original data dump. But it turns out the "author" field is pretty complicated:
- The demos can have one or more groups
- The demos can have one or more people in "credits"
- If nothing else, the demo has an uploader
But, no matter what, someone gets credited now.
I'm unreasonably happy with this throwaway project - I'm Pygmalion over here. Staring at a random parade of tiny demos is incredibly hypnotic and beautiful.
Not all the demos work well, many have palette issues and some trigger illegal opcode errors. But this has actually help me find a few issues to improve v86.
Copyright is reserved by the creators. Legally, I consider this site an archive, like demozoo, or scene.org, or youtube which already host all these demos. Its new purpose is to help you discover, appreciate, and learn more about forgotten, somewhat modest, but still extremely cool old demos.
This is a one-off project for me and I don't intend to update the list week to week. If a demo author finds their work here and doesn't want it here, please file a github issue and I'll promptly remove it.
Now, please enjoy this rotating 3d hat