Most of the writing on this blog is code walkthroughs of small programs. Some of them are extremely basic proof-of-concept programs that don’t do anything other than demonstrate some technique or investigate some behavior. Others are larger programs that one might consider running for their own sake.

This page collects the larger projects and releases discussed on the blog.

Lights Out

When I want to put an unfamiliar system through its paces, I’ve often implemented the Lights Out puzzle on it. It’s a very good-sized problem for such things, including some simple graphics and UI (with reasonable options for both keyboard and mouse input, even!) but not needing a tremendous amount of logic to implement directly. I’ve used it over the years as a Rosetta Stone for comparing the capabilities of different hardware platforms, and as a springboard for going deeply into what it really takes to make a program of any kind tick.

• ZX81/Timex Sinclair 1000: This version sparked my first article on the puzzle, and while it doesn’t include a full code walkthrough, there’s some discussion on the general challenges faced in making a software release. The random number generator I used gets a deep dive in an article of its own.
• MS-DOS, Win32 Console: Text mode DOS and Windows programs were released with the ZX81 version but never seriously discussed.
• ZX Spectrum: My first real Spectrum program, and its article discusses how to make the same binary run properly on the various Spectrum variants, including the ill-fated Timex Sinclair 2068. I enhanced it later inspired by the later NES version.
• Commodore 64: A version was released with the ZX81 version, and a graphically enhanced version inspired by the ZX versions came later. The NES version inspired three further enhancements, to the overall screen, to the board itself, and finally a fully-animated version where even the labels on the buttons move properly.
• TRS-80 Model III: Once I properly split the game up into an engine and a shell, this quick port tested out the shell. It didn’t rate an article on its own.
• Exidy Sorcerer: This also didn’t get much discussion, but it was used as a testbed for how inconvenient its graphics work was or wasn’t in my tour of the Sorcerer.
• Atari 2600: I built this one from scratch in a long series (I, II, III, IV, V, VI, VII, VIII, IX, X, XI, XII, XIII). This doesn’t cover absolutely everything you need to know to become an Atari 2600 developer (it is, at the very least, missing both asymmetric playfields and arbitrary sprite positioning), but it’s got a good fraction of it.
• Microsoft Windows: This is a full-fledged Windows GUI application built with all the traditional components (menus, dialog boxes, GDI rendering, properly resizable windows, etc), but it weighs in at 6KB, 1.5KB of which is the icon. And that’s without any particular sizecoding tricks, either, so feel free to look sideways at anyone telling you that Windows software is intrinsically hugely bloated! Like the Atari case, this one was written over a long series (I, II, III, IV, V, VI, VII, VIII) that talked through every instruction, to demonstrate how a Windows-2k-or-later application is constructed at the lowest level. Note that because it’s restricting itself to the old UI calls, it does not exploit the significant improvements offered by the Vista’s Common Controls expansions, much less WinForms or WPF. This should not be taken as a guide to modern software development on Windows!
• Nintendo Entertainment System: I built this one from scratch in a long series (I, II, III, IV, V, VI, VII, VIII, IX, X, XI, XII). It goes through a lot of contortions to explore program architecture approaches that were not used by the previous versions, nor by my other NES programs to date. It suffers a bit for that, but it is also probably the nicest looking edition so far. Unusually for these sorts of series, it also goes into some detail on toolchains for creating assets that are not code.
• PICO-8: This is a quick but cheerful clone of the NES version that I wrote in a single session. Getting this working introduced me to several parts of that fantasy console that I never really had gotten a handle on before.

All of these editions are available as a single compilation.

Shooting Gallery

In late 2024 I ended up implementing the same little shooting-gallery program multiple times as a way of comparing the sprite technologies of three related platforms. As time went on I reimplemented it a few more times to explore yet other approaches to sprite graphics, and it’s become another “Rosetta Stone” project alongside Lights-Out.

• Atari 2600: The original set of articles was tracking the evolution of “Player-Missile Graphics” from the Atari 2600 through to the Amiga’s sprite system. The 2600 was the earliest system, so it came first. This is an extremely primitive platform, with sprite control requiring software intervention in nearly every scanline on the display. As a result, getting everything working just right ended up becoming an eight-part series (I, II, III, IV, V, VI, VII, VIII) that also needed to cover a lot of the principles behind the system that the Lights-Out project did not get to.
• Atari 800: The 800’s sprite system is explicitly descended from the 2600’s, but the CPU has less work to do because most of the components recognizable from the Atari 2600 are now hooked to DMA transfer systems. There’s still a role for the CPU to play, but it’s much smaller and more comparable to what we’d see on more traditional systems like the C64. As a result, this series (I, II, III, IV) was much shorter.
• Amiga 500: Like the Atari 800, this also fell into a neat 4-part series (I, II, III, IV). Amiga “Sprite DMA channels” end up looking a great deal like the Atari 800’s DMA-backed player-missile graphics, but the size, color depth, and complexity of the graphics are more advanced. Multiplexing—using a single sprite element to represent multiple game objects—no longer requires CPU intervention. Note that the technique here was executed to hew as closely as possible to the Atari technique, and to show off the incremental improvements in the DMA system the Amiga provided, but it was rare in practice to actually do this, even during the system’s heyday. The Amiga’s “Copper” coprocessor could transparently fill the role that CPU intervention did on the Ataris, and doing so resulted in a significantly simpler programming model.
• PICO-8: After that lineage of three systems was covered, I wanted to create a “modern” implementation with no particular hardware support. Instead of creating a fully modern desktop application, I wrote it for the PICO-8 fantasy console to keep the graphical capabilities in line with the others. This remained simple enough that it could be entirely implemented in a single post—the game logic overall here is simple enough that when writing in Lua instead of assembly language there’s just less work to be done.
• TI-99/4A: Unlike the Ataris and the Amiga, the TI-99’s graphics chip was the inspiration for the sprite systems that were the most popular and common throughout the 1980s and early 1990s. Implementing the shooting gallery for the TI-99 ended up also fitting in a single post. The TI-99’s system design is extremely constrained, with an unusual architecture that means that the main CPU usually cannot see much of the system’s RAM. This project also served as an opportunity to put the program organization discipline I’d previously devised to the test.
• Sega SG-1000: This was a very simple Z80-based system with the same graphics and sound chips as the TI-99/4A. It was not the only such system, but it was the simplest one. I ported the TI’s shooting gallery over to this system in two parts: a hardware abstraction layer and then a port of the game itself.
• Colecovision: Much like the SG-1000, this was a Z80-based system that used the TI’s graphics and sound chips, but also included a more sophisticated on-board BIOS. I wrote the SG-1000 port to be relatively portable within the Z80 space, and this port proved that out. The system-specific aspects of the port were covered in a dedicated article.
• MSX: The MSX line of home computers were z80-based and the earliest iterations of the hardware had the same graphics chip as the TI-99/4A. It also received a port based on the SG-1000 edition, with its own porting quirks and considerations.

All of these editions are available as a single compilation.

Simulated Evolution

This started out as a one-shot project—taking a project specification from Scientific American‘s old “Computer Recreations” column and putting it through its paces with the full power that the 21st century had to offer—but it ended up inspiring a bit of extra work as well.

• Simulated Evolution was the original article. I port the program from a BASIC-like pseudocode into idiomatic modern C and work through what has changed in program design over the decades. I also explore the behavior of the program itself.
• Simulated Evolution on Two 8-Bit Machines was a followup. I was interested in looking into writing assembly language code in a way that most of it would be reasonably portable between two systems that were not at all compatible, but which did share the same CPU architecture: the Commodore 64 and the Atari 800. This worked better than it had any right to. The ports themselves were not small projects, and I don’t do detailed walkthroughs of them. The techniques I needed to develop to get good performance and user experience out of them are linked within the articles themselves; they don’t form a “dev diary” like the Lights-Out projects did.
• Simulated Evolution on Two 16-Bit Machines was a second followup. This adapted the modern C implementation into something that would run acceptably on the Atari ST and the PC DOS.
• The Commodore Amiga received a more sophisticated port with the same toolkit the Atari ST port used. This port made full use of the Amiga’s “Intuition” GUI and runs on both the Amiga 500 and the Amiga 1200.
• The Macintosh received the most sophisticated port yet, and runs on every version of the Mac from the 512Ke through the final PowerPC Macs, and on any version from System 4 through System 9.
• PICO-8 required a fresh implementation due to its Lua-based execution runtime, but ends up adapting several techniques from the 8-bit versions along the way.
• There isn’t an article for it, but the modern C program was one of the programs I adapted to make use of the Direct3D 9 pixmap library outlined below.

The various editions of the program are available as a single compilation.

The Cyclic Cellular Automaton

This is one of the simplest order-from-chaos simulations. The rules are simple; there is a toroidal 2D grid of cells, each seeded with a random value between 1 and N. On each tick, a cell increases its value by 1 if any of its 4 cardinal-direction neighbors have a value one more than it does. (The value 1 is understood to be one more than N here, so there is a cycle.) Despite the random starting state and the very simple simulation rule, the overall map evolves through several levels of order, often ending in a collection of pulsating spirals.

Before Lights-Out became my go-to “Rosetta Stone” program, the CCA was the simple program I’d write to get up to speed with a new system or graphics library. It turns out that it’s a poor fit for most of the 8-bit systems I look at—I really want pixel-level control with at least 16 colors—but with a little bit of cleverness I was able to get acceptable displays out of the tile-graphics systems of the 16-bit consoles as well.

• MacOS. When I wanted to use Cocoa and CoreGraphics as directly as I possibly could, the CCA was a natural fit for my original use case. This ended up being a five-part series (I, II, III, IV, V). Apple’s official application framework, Cocoa, keeps the developer at considerable remove from the OS and the hardware. Even building the most basic application usually requires asking Xcode to do a lot of configuration and setup work for you under the hood, and most of this s is declarative data with no easy counterparts in other systems. Using the Cyclic Cellular Automaton as a base example, I work through a graphical Cocoa application that produces a full user experience, without ever touching the Interface Builder or an an Info.plist file, and which runs acceptably on versions of macOS going all the way back to 10.7.
• Microsoft Windows. The actual simulation code for Mac was portable C, which meant that later on when I was experimenting with pixel-level displays in Direct3D 9, I could port it over directly.
• RISC OS. This didn’t make it into the article, but I used the same C core again as a use case for legacy VDU graphics on RISC OS 5. The graphics mode was, I think, designed for a mid-range Acorn Archimedes, but the Raspberry Pi 3 can runs it a very respectable speed indeed.
• PICO-8. This was one of my two initial programs I wrote when I first seriously looked at the PICO-8 fantasy console. I was bending the simulated hardware quite hard with this one, treating what was supposed to be sprite RAM as a secondary bitmap display, but it worked out very well.
• Sega Genesis/Mega Drive. This was my first actual CCA implementation here, and it was quite the journey to get it working. I needed to develop a pseudo-bitmap mode general enough to cover the space I was simulating, fit updates to it into the frame loop, and manage scrolling and interrupts just to get the project off the ground at all. That groundwork in place, I could then create the program in a three-part series (I, II, III). I ended up leaning much more heavily on high-level languages for prototyping, general design constructs, and reasoning about optimization for this project. The Genesis is a lovely demonstration of how the 16-bit era bridges the gap between the 8-bit era where every kind of computer is a unique artifact to a world where most of the time you want to abstract away the underlying hardware. Once I saw what I could make the SNES do (below), I revisited the project on the Genesis side, making it faster, prettier, and with fancier graphical effects.
• The Super Nintendo Entertainment System. The same pseudo-bitmap techniques I used on the Genesis also worked on the SNES. The overall hardware is more powerful but more finicky, so replicating the technique was a bit of a journey (I, II, III) compared to the actual implementation of the simulation itself (I, II). My whole first four months with the SNES were ultimately all aimed at getting this program working as best it could, so one could frankly do worse than starting with my first post about the platform and just reading forward for the rest of 2023’s posts.

The various editions of the program are available as a single compilation.

Type-In Rescues

Throughout the 1980s, a surprisingly large amount of surprisingly powerful software was distributed as printed listings that end users were expected to type in themselves. I occasionally dig into such programs to determine how they worked, fix bugs in them, or recreate them using techniques less suited for publication as source code in magazines.

Unlike my other projects, these usually end up just being one-shot articles unless the type-in program is less of a subject for analysis and more of a springboard for some project or investigation of my own.

• Color Chart Madness. My first real series on this blog tore apart a sample program in Sheldon Leemon’s Mapping the Commodore 64 and determined both how it worked and how to correct some graphical anomalies I found within it. This was a three-part series (I, II, III) and some strange, glitchy behavior I found along the way ended up sending me on a year-long quest to master some of the most advanced techniques on the platform, pushing the VIC-II well beyond what it was designed to do. I ultimately published a retrospective of that journey, which covers the topics needed to understand why the original code glitched out, rather than merely how to avoid the glitch, which is what the original series did.
• Exploring the HAT function. This program was short enough that I am assuming it is from a magazine, but I do not know where it was from. I use a math-heavy old BASIC program to experiment with mixing assembly language with Pascal or C on DOS, and do some performance measurements on modern-day hardware and software.
• Hamurabi is one of the oldest city-builder games. I take the published source code from the late 1970s and create a strategy guide out of the formulas therein.
• Portrait of Liberty. This is really an article about type-in programs generally, using John Jainschigg’s Portrait of LIberty program as a springboard. I lament the generally poor quality of the C64 port and bring it up to par with the vastly superior version for the PCjr in the same issue. This program also became the bones around which I built my first serious Atari ST program (I, II, III, IV, V, VI), which let me explore a lot of dusty corners of the system.
• SWAT and the Automatic Proofreader. Many publishers included special secondary programs whose job was to make sure that you did in fact type in their programs correctly. Some of them even coordinated so that proofreader programs could be shared across magazines and books. I select three proofreader programs from SoftSide and Compute! and discuss the algorithms they use and their methods of operation. These run the gamut from simple standalone programs through sophisticated mutation of the BASIC interpreter’s own operation and memory layouts.
• Compute!‘s C64 Auto-loader. This was a program that would allow programs to start running automatically after being loaded without requiring the user to type RUN. That program was, itself, generated by a BASIC program that used a helper machine-language program to do its work. This turns out to be that rare case where I found the program to be much improved by removing responsibilities from the machine code, and in the end, the final version is 100% BASIC except for the pure-machine-code programs being generated by it. The programs it generates are analyzed and improved in a separate article.
• Wallpaper. This is the article where I start referring to what I’m doing as “rescuing” type-in programs. I take a small BASIC program (though not small enough that it can run unaided on an unexpanded ZX81!) and convert enough of it to machine language that it runs at an actually acceptable speed. This mostly ends up being a proof of concept for cross-developing hybrid BASIC/Machine-Language programs on the ZX81, but I do like Wallpaper for the tiny demo program that it is.
• Mandala Checkers. Wallpaper was a warmup for this: the conversion of a rather more sophisticated game from the same book into something that was actually playable. This is a four-part series (I, II, III, IV) that walks through the design and implementation decisions I made along the way, as well as an analysis of the virtues and flaws of the original design.
• Front Attack. This is an arcade action game for the Atari 800 that is written entirely in BASIC but which exploits various parts of its environment to get machine language speeds out of a great many operations. This also rendered it extremely fragile, in ways where most readers who attempted to type it in would fail to produce a functioning program. I identify the techniques it uses, the problems it encounters when actually typing it in, and working around those problems without changing the program in any meaningful way.
• Mini-Invaders. This is a small action game for the TRS-80. It was presented as a type-in BASIC program, but the game itself is pure machine code and the BASIC listing cannot actually be typed in directly. I fully reverse-engineer what the BASIC program does and then use that knowledge to render the program runnable in two different ways.
• Quadrun. This was a small action game for the 16K ZX Spectrum—but, unusually, not for the 48K ZX Spectrum. I do some digging to discover why an upgrade would break an otherwise straightforward program, and implement a compatibility fix.
• Gift Drop. This is a hybrid BASIC/machine-code program published in 2025, and while I mostly leave the program itself alone, I use it as a springboard for discussing how these hybrid programs could be most efficiently packed and distributed. Our end result changes no actual program logic outside of initialization, but initialization is sped up by over a full minute and the program loads more quickly, too.

One-Shot Projects

Most programs I make aren’t part of some series or meta-project. These are the miscellaneous programs I’ve put together over the years here, with various levels of explanation.

• Color Test. This was my first Atari 2600 program of any significance. It was designed to explore the Atari’s (very large for an 8-bit system) palette, and it manages a couple of tricks on its own, too.
• Apple IIe Experiments. This program doesn’t do a whole lot, but it takes me through creating programs and putting them on disk images, playing music, and drawing low-resolution graphics. The Apple IIe is noticably harder to get off the ground with compared to the other platforms I’ve used here.
• The Atrocitron. A text adventure, sort of. This started as a prank and turned into an experiment of sorts. It did better than I expected it to.
• Galaxy Patrol. To date my only NES release of significance.
• Smoking Clover. An old graphics demo that I’d never really gotten to work right as a child. This was written in two parts to demonstrate direct hardware and OS access on DOS without dropping out of C into assembly language.
• Coast to Coast. My only demo release of note, for the C64. A collaboration with the musician Nick Vivid, and an invite for the SynchroNY 2018 demoparty.
• C64 Directory Editor. This is a full-scale program written as part of a five-part series (I, II, III, IV, V) on producing and organizing useful programs in BASIC.
• Game Boy Hello World. In 2018 I realized that I had now written significant programs for every computer or game system I’d used as a child, with two exceptions. The Game Boy was one of them. I start with a simple standalone Hello World program, as is traditional.
• Conway’s Game of Life. This was my real program for the Game Boy. Starting with my Hello world program, I proceed through five posts (I, II, III, IV, V) to refine the program into its final form. on the Original Game Boy.
• Diffusion Chamber. A much simpler program from the same columnist that inspired the Simulated Evolution projects. This uses modern computers to investigate a randomized simulation and struggles with the limits of default pseudo-random number generators.

Libraries

Sometimes instead of building complete programs I’ll create implementations of particular functions so that I can use them in multiple projects.

• Pseudo-Random Number Generators. The default random numbers in most high-level languages aren’t very good, and usually rely on operations like multiplication and modulo that the old chips I program here on this blog aren’t good at. A family of PRNGs called “xorshift” has very strong statistical guarantees and also may be very efficiently implemented on old chips. I have worked through implementations of a 16-bit version for the 6502, Z80, Atmel AVR, and ARM chips (with ARM specifically in its 16-bit “THUMB 1” mode), and a 64-bit version for the 32-bit x86, ARM, 68000, and MIPS I architectures.
• SHA-256. The most powerful cryptographic function that it is remotely reasonable to ask a 6502 chip to perform.
• Simplified LZ4 decompression. Many of my projects targeting 16-bit systems needed large amounts of graphics or sound data, and it is convenient to store them compressed. The 2012 LZ4 algorithm is a good fit for these older CPUs, and I modified its frame format a bit to make decompression even simpler. To date I’ve written dedicated decompressors for the SNES’s 65816 chip, the CoCo’s 6809, and the Genesis’s Motorola 68000.
• Sound and Music on the C64. I wrote these graphics and music drivers for the C64 about twenty years ago, and while I’m not proud of either of them, they’ve both regularly proven themselves too useful to discard. The music driver was later ported to the Atari ST.
• Digital Sound on the PC Speaker. The old PC speaker was capable of far more than angry bleeps. This library provides a 16-bit DOS interrupt routine capable of high quality audio playback.
• Direct3D 9 pixmap library. I built this over the course of several articles (I, II, III, IV, V, VI, VII) as a way to both explore Direct3D 9 as a technology and also to give me a cheap alternative to SDL2 when rendering simple displays on Windows. Some of my earlier attempts turn out to not pan out, but a good chunk of its bones survive into the final module as well.
• Direct3D 9 tilemap library. After getting the pixmap library working, I extended it (I, II, III, IV) so that it would work as a more traditional sprite engine. That gave me an excuse to dig more deeply into the workings of Direct3D 9’s non-shader pipeline and compare them with OpenGL’s.