I am a huge fan of the demoscene, and have been for many years now.
If you’ve not heard of the “Demoscene” or the “Demos” within the realms of computer experience, it’s worth it, heavily, to check it all out. For decades, majestically talented programmers, artists and musicians have created top-notch experiences on a massive range of computers and then gave this hard work, sometimes weeks or months or even years of effort, away for free.
Nine years ago (!) I was entranced enough about it to try to explain it in a week of postings here: 1 2 3 4 5 6 – and if you don’t have the time to read them all, I’ll summarize thus: The Demoscene is an incredible artistic subculture that creates unique and amazing things, also subject to behind-the-scenes drama and cattiness that all thriving creative cultures do. And the result of their efforts are amazing displays you can enjoy online or in person around the world.
The side effect of this work, however, is how much intense processing and power a system showing a demo might need to have. And demos can be brutal when it comes to system requirements on modern systems. They’re not subject to the requirements of, say, a game that has to play on as wide a set of machines as possible to ensure biggest sales. They’ll come right out and demand top of the line bleeding edge acid dogfood specs, because they can. When parties, held around the world to show off these works, are showing these programs, they have machines that might as well eat meat.
There’s another class of demo, which attempts to put the most amount of power in as tiny a space as possible. We’re talking executable sizes of 256 bytes, or 1024, or 8k, or 64k and so on. It allows a limit on the programming side that favors efficiency and skill in compactness. Let’s set those aside for the purposes of this entry.
And then there are console demos.
Not only do we have demos that are exercising the latest and greatest. We also have demos that are written to use the most basic hardware out there: game consoles. The limited platforms that are machines like the Atari 2600 or Sega Genesis provide a level playing field for artists making a mark within the demoscene. Make these limited machines do something out of the ordinary, and you will get lots of positive attention from your contemporaries, because you obviously worked hard to squeeze this performance out of these things.
To get that special performance, you often have to do insane coding to the console, so that it does things it was never designed to do, and to find weird explosive bugs or undocumented behavior that you can bring to the forefront. It’s obscure, strange magic and it’s as intense as possible for the hardware.
You might see where this is going.
As of this writing I have put 120 console-based demos into the Internet Archive and gotten them emulated in the browser.
Because not everyone has a ROM burner for an old console (or even the old console) at their fingertips, the ROM files made for these demos are either left up languishing, or are often loaded into emulators, or even just turned into YouTube videos to give people an idea of what they’re looking at. It’s generally accepted that playing videos in lieu of getting stuff executed on actual hardware is a necessary but sad evil. And of course emulators have been there for some time, although with many of the same problems that Emularity/JSMESS was meant to address (taking a while to assemble, no one-click referencing for your friends, etc.)
What we have here is instantaneous demos in your browser. You click on these, and it boots up an emulated console playing the demo.
On one level, that’s all you need to know. Go forth and try them out. Every entry has a link back to a page about the given demo so you can see them under other circumstances or fall into a hole seeing all the amazing demos there are out there.
But I wanted to cover a few more things.
With the integration of JSMESS’s aspects into MAME, comes near-instant turnaround for upgrading the emulation on the Internet Archive. If someone patches or improves a platform supported in MAME, we can have it running on the Archive, and all the programs that use that supported platform running the updated code… in about 10 minutes. Before, it was a little more involved, so if someone did the work, we might still lag on the repair for days or weeks or even in a few cases, years. So that is gone, and with it, any hesitation to encourage people to join development of MAME to make emulation on it as accurate as possible.
You see, these demos I’ve thrown in, and more coming, will likely not be 100% accurate on the browser emulation system. These are tough little nuts when it comes to undocumented tricks and traps to make things go. It’s not a surprise the emulators will fall down. But that’s great. It means there’s a demonstrable, viewable program that will show the problem at hand and encourage improvements.
MAME is open-source in the proper licensed sense now. There’s no reason for people to not be porting over compatible code or improvements into it. The changes will be reflected on the browser emulation as well as MAME’s many other platforms. It’d be excellent work to do. And the reward will be to make things run even more accurately for other, non-demo items.
These two factors are why I’m pushing for this now. I want to see the loop close and for us to see improvements in emulation with a large range of talent joining into this great cause. MAME is a fantastic emulator. It needs more people to do the very intense grunt work of making pixel/speed-perfect emulations of these platforms, before we have no platforms to reference.
And for everyone else…. there’s some damned fine work in these demos, and if I can cause hundreds or thousands more to see and respect these works than had seen them up to this point… that’s a pretty nice day all around.