A screenshot of the world's first 64kB boomer shooter

QUOD Is A Quake-Like In Only 64kB

The demoscene is still alive and well, and the proof is in this truly awe-inspiring game demo by [daivuk] : a Quake-like “boomer shooter” squeezed into a Windows executable of only 64 kB he calls “QUOD”. We’ve included the full explanation video below, but before you check out all the technical details, consider playing the game. It’ll make his explanations even more impressive.

OK, what’s so impressive? Well, aside from the fact that this is a playable 3D shooter in 64kB, with multiple enemies, multiple levels, oodles of textures, running, jumping et cetera–it’s so Quake-like he’s using TrenchBroom to make the levels. Of course he’s reprocessing them into a more space-efficient, optimized format. Yeah, unlike the famous .kkrieger and a lot of other demos in the 64kB space, this isn’t all procedurally generated. [daivuk] did make his own image editing program for procedurally generated textures, though. Which makes sense: as a PNG, the QUOD logo is probably half the size of the (compressed) executable.

The low-poly models are created in Blender, and all created to be symmetric–having the engine mirror the meshes saves 50% of the vertex data. . Blender is just exporting half of a low-poly mesh; just as he wrote his own image editor, he has his own bespoke model tool. This allows tiling model elements, as well as handling bones and poses to keyframe the model’s animation.

Audio is treated similarly to textures and meshes: built up at runtime from stored data and a layered series of effects. When you realize all the sounds were put together in his sound tool from square and sine waves, it makes it very impressive. He’s also got an old-style tracker to create the music. All of these tools output byte arrays that get embedded directly in the game code.

The video also gets into some of his optimization techniques; we like his use of a map file and analyzing it with a python tool to find the exact size of game elements and test his optimizations thereby. One thing he notes is that his optmizations are all for space, not for speed. Except, perhaps, for one thing: [daivuk] created a new language and virtual machine for the game, which seems downright extravagant. It actually makes sense, though, as the virtual machine can be optimized for the limits of the game, as he explains starting at about 20 minutes into the video. Apparently it saved a whole 2kB, which seems like nothing these days but actually let [daivuk] fit an extra level into his 64kB limit. Sure, it’s still bigger than Quake13k–and how did we never cover that?–but you get a lot more game, too.

So, to recap: [daivuk] didn’t just make a game with an impressively tiny size on disk, he made the entire toolchain, and a language for it to boot. If you think this is overoptimized, check out Wolfenstien in 600 lines of AWK. Of course in spite of the 1980s file size, this needs modern hardware to run. You can get surprising graphics performance from a fraction of that, like this ATtiny sprite engine.

Thanks to [Keith Olson] for the tip, which probably took up more than 64kB on our tips line.

Continue reading “QUOD Is A Quake-Like In Only 64kB”

A New Cartridge For An Old Computer

Although largely recognizable to anyone who had a video game console in the 80s or 90s, cartridges have long since disappeared from the computing world. These squares of plastic with a few ROM modules were a major route to get software for a time, not only for consoles but for PCs as well. Perhaps most famously, the Commodore VIC-20 and Commodore 64 had cartridge slots for both gaming and other software packages. As part of the Chip Hall of Fame created by IEEE Spectrum, [James] found himself building a Commodore cartridge more than three decades after last working in front of one of these computers.

[James] points out that even by the standards of the early 80s the Commodore cartridges were pretty low on specs. They’re limited to 16 kB, which means programming in assembly and doing things like interacting with video hardware directly. Luckily there’s a treasure trove of documentation about the C64 nowadays as well as a number of modern programming tools for them, in contrast to the 80s when tools and documentation were scarce or nonexistent. Hardware these days is cheap as well; the cartridge PCB and other hardware cost only a few dollars, and the case for it can easily be 3D printed.

Burning the software to the $3 ROM chip was straightforward as well with a TL866 programmer, although [James] left a piece of memory management code in the first pass which caused the C64 to lock up. Removing this code and flashing the chip again got the demo up and running though, and it’ll be on display at their travelling “Chips that Changed the World” exhibit. If you find yourself in the opposite situation, though, we’ve also seen projects that cleverly pull the data off of ancient C64 ROM chips for preservation.

An Amiga Demo With No CPU Involved

Of the machines from the 16-bit era, the Commodore Amiga arguably has the most active community decades later, and it’s a space which still has the power to surprise. Today we have a story which perhaps pushes the hardware farther than ever before: a demo challenge for the Amiga custom chips only, no CPU involved.

The Amiga was for a time around the end of the 1980s the most exciting multimedia platform, not because of the 68000 CPU it shared with other platforms, but because of its set of custom co-processors that handled tasks such as graphics manipulation, audio, and memory. Each one is a very powerful piece of silicon capable of many functions, but traditionally it would have been given its tasks by the CPU. The competition aims to find how possible it is to run an Amiga demo entirely on these chips, by using the CPU only for a loader application, with the custom chip programming coming entirely from a pre-configured memory map which forms the demo.

The demoscene is a part of our community known for pushing hardware to its limits, and we look forward to seeing just what they do with this one. If you have never been to a demo party before, you should, after all everyone should go to a demo party!


Amiga CD32 motherboard: Evan-Amos, Public domain.

Kaleidoscopico Shows Off Pi Pico’s Capabilities

In the early days of computing, and well into the era where home computers were common but not particularly powerful, programming these machines was a delicate balance of managing hardware with getting the most out of the software. Memory had to be monitored closely, clock cycles taken into account, and even video outputs had to be careful not to overwhelm the processor. This can seem foreign in the modern world where double-digit gigabytes of memory is not only common, it’s expected, but if you want to hone your programming skills there’s no better way to do it than with the limitations imposed by something like a retro computer or a Raspberry Pi Pico.

This project is called Kaleidoscopio, built by [Linus Åkesson] aka [lft] and goes deep into the hardware of the Pi Pico in order to squeeze as much out of the small, inexpensive platform as possible. The demo is written with 17,000 lines of assembly using the RISC-V instruction set. The microcontroller has two cores on it, with one core acting as the computer’s chipset and the other acts as the CPU, rendering the effects. The platform has no dedicated audio or video components, so everything here is done in software using this setup to act as a PC from the 80s might. In this case, [lft] is taking inspiration from the Amiga platform, his favorite of that era.

The only hardware involved in this project apart from the Pi Pico itself are a few resistors, an audio jack, and a VGA port, further demonstrating that the software is the workhorse in this build. It’s impressive not only for wringing out as much as possible from the platform but for using the arguably weaker RISC-V cores instead of the ARM cores, as the Pi Pico includes both. [lft] goes into every detail on the project’s page as well, for those who are still captivated by the era of computer programming where every bit mattered. For more computing demos like this, take a look at this one which is based on [lft]’s retrocomputer of choice, the Amiga.

Continue reading “Kaleidoscopico Shows Off Pi Pico’s Capabilities”

Amazing Oscilloscope Demo Scores The Win At Revision 2025

Classic demos from the demoscene are all about showing off one’s technical prowess, with a common side order of a slick banging soundtrack. That’s precisely what [BUS ERROR Collective] members [DJ_Level_3] and [Marv1994] delivered with their prize-winning Primer demo this week.

This demo is a grand example of so-called “oscilloscope music”—where two channels of audio are used to control an oscilloscope in X-Y mode. The sounds played determine the graphics on the screen, as we’ve explored previously.

The real magic is when you create very cool sounds that also draw very cool graphics on the oscilloscope. The Primer demo achieves this goal perfectly. Indeed, it’s intended as a “primer” on the very artform itself, starting out with some simple waveforms and quickly spiraling into a graphical wonderland of spinning shapes and morphing patterns, all to a sweet electronic soundtrack. It was created with a range of tools, including Osci-Render and apparently Ableton 11, and the recording performed on a gorgeous BK Precision Model 2120 oscilloscope in a nice shade of green.

If you think this demo is fully sick, you’re not alone. It took out first place in the Wild category at the Revision 2025 demo party, as well as the Crowd Favorite award. High praise indeed.

We love a good bit of demoscene magic around these parts.

Continue reading “Amazing Oscilloscope Demo Scores The Win At Revision 2025”

Homebrew CPU Gets A Beautiful Rotating Cube Demo

[James Sharman] designed and built his own 8-bit computer from scratch using TTL logic chips, including a VGA adapter, and you can watch it run a glorious rotating cube demo in the video below.

The rotating cube is the product of roughly 3,500 lines of custom assembly code and looks fantastic, running at 30 frames per second with shading effects from multiple light sources. Great results considering the computing power of his system is roughly on par with vintage 8-bit home computers, and the graphics capabilities are limited. [James]’s computer uses a tile map instead of a frame buffer, so getting 3D content rendered was a challenge.

The video is about 20 seconds of demo followed by a detailed technical discussion on how exactly one implements everything required for a 3D cube, from basic math to optimization. If a deep dive into that sort of thing is up your alley, give it a watch!

We’ve featured [James]’ fascinating work on his homebrew computer before. Here’s more detail on his custom VGA adapter, and his best shot at making it (kinda) run DOOM.

Continue reading “Homebrew CPU Gets A Beautiful Rotating Cube Demo”

Yesterday’s Future Is Brighter Today

The demoscene never ceases to amaze. Back in the mid-80s, people wouldn’t just hack software to remove the copy restrictions, but would go the extra mile and add some fun artwork and greetz. Over the ensuing decade the artform broke away from the cracks entirely, and the elite hackers were making electronic music with amazing accompanying graphics to simply show off.

Looked at from today, some of the demos are amazing given that they were done on such primitive hardware, but those were the cutting edge home computers at the time. I don’t know what today’s equivalent is, with CGI-powered blockbusters running in mainstream cinemas, the state of the art in graphics has moved on quite a bit. But the state of the old art doesn’t rest either. I’ve just seen the most amazing demo on a ZX Spectrum.

Simply put, this demo does things in 2022 on a computer from 1982 that were literally impossible at the time. Not because the hardware was different – this is using retro gear after all – but because the state of our communal knowledge has changed so dramatically over the last 40 years. What makes 2020s demos more amazing than their 1990s equivalents is that we’ve learned, discovered, and shared enough new tricks with each other that we can do what was previously impossible. Not because of silicon tech, but because of the wetware. (And maybe I shouldn’t underestimate the impact of today’s coding environments and other tooling.)

I love the old demoscene, probably for nostalgia reasons, but I love the new demoscene because it shows us how far we’ve come. That, and it’s almost like reverse time-travel, taking today’s knowledge and pushing it back into gear of the past.