I wanted my Game-Maker sandbox to boot on real hardware without Linux underneath. Not a Linux box that happens to run my games, but a small machine whose whole job is Game-Maker. This week that machine woke up.
Why bare metal
If I put Linux under it, this would still be a Linux port. The Pi Zero W is a $10 board with one ARM core and 512 MB of memory, which is more computer than the DOS machines Game-Maker was written for. A tiny kernel of my own can start in a moment, show what it’s doing, and do nothing else.
The kernel is open source under the MIT license, in its own repository, sandbox-kernel.
The prototype
The first thing to run was a prototype built on an existing bare-metal library. It came up and drew on the e-ink screen right away, a Waveshare 2.13-inch e-paper hat. A few seconds later it started flashing, because it redrew the whole screen every time something changed. I asked for it to update only the part that changed, and the flashing stopped. Then it ran for hours:
That proved the board, the screen and the USB cable could all work. I also asked for a little boot logo, and for the Pi to keep showing it until it has other screens to show. The new kernel, which I call M0, starts from scratch: a small boot selector, the kernel itself, the e-ink screen, a USB serial link back to my Mac, and a safe way to update itself.
Two slots and a 30-second trial
The card holds two copies of the kernel, slot A and slot B. When I send an update over the USB cable, it goes into the slot that isn’t running. The Pi restarts into the new copy on trial. If the new copy keeps the timer, the card and USB healthy for 30 seconds, it confirms itself. If it doesn’t, the next restart falls back to the copy that worked.
First boot
M0’s first boot drew its status on the e-ink upside down, in a thick, blocky little font where an A and an 8 both looked like a B. “SD ACMD41 BUSY” read to me as “SD.BCHD41.BUSY”, and the spaces looked like dots.
That screen turned out to be the most useful thing on the board. The boot selector had read the card just fine, but the kernel couldn’t open it a moment later, and USB never came up. Both problems traced back to how the kernel talked to the Pi’s firmware once memory caching was switched on, and to the kernel trying to start a card the boot selector had already started. Instead of starting the card over, the kernel now picks it up where the selector left it, and the screen names the exact step that failed when something goes wrong.
The fixes went in, the text turned right side up, and the font got bigger and clearer. Then the screen said what I wanted to see:
Updates over one cable
From there, nothing needed the card reader. I sent three updates over the USB cable, and each one installed into the spare slot, ran its 30-second trial, and confirmed itself: generation 2, then 3, then 4.
The last two brought the logo I’d asked for. I wanted it on the screen for a picture, so the Sandbox castle from the games’ opening animation became a round 1-bit badge, drawn to stay crisp on e-ink. It went to the Pi the same way, over the cable, while the Pi sat on my desk.
What’s next
- Test the safety net on purpose: send a broken update and watch the Pi fall back to the last good one.
- Load and run a Game-Maker game, which is the whole point.
- Keep the Pocket Player boards (the little touchscreen CYDs) and the Pi moving toward Game-Maker 3.0 before any 4.0 ideas.
Two booklets
The same days finished two printable booklets for the site.
The Technical Reference and Limits booklet now covers every Game-Maker file, one format to a page: what each byte means, with a worked example from a real file. It runs 48 pages, from the palette files to the files that move a game between programs.
The new Player Patching Manual is for anyone who wants to change a finished game’s player program without the source: the menu words, colors, frames, waits and function keys. It catalogs 139 documented player settings, starting with how to tell exactly which program you have before you touch a byte.
Running like my first computer
I also wanted to see how Game-Maker ran on my computer when I first got it. So I set up 86Box, an emulator of old PCs, on my Mac as an IBM PS/1 Model 2011: a 286 at 10 MHz with 1 MB of memory.
Getting there took some back and forth with Claude. The PS/1’s drivers, utilities, disk images and ROMs are shared by fans, but every file I tried to download came wrapped in advertisements, so Claude grabbed the whole set for me. Then we troubleshot the setup together: the 30 MB hard drive only formatted with its real geometry, 921 cylinders instead of the 920 I’d been reading; the floppy drive worked once I took the speed setting off; and the game played without a sound until I noticed I’d set “Sound and music” to None. With the Sound Blaster on IRQ 7, the FM music came through.
Then I played, and I felt it. Level 2 of Slow Computers, with its crowd of monsters, crawled in a way our emulation never had. Every digital sound paused the game for a moment while it loaded. And on the slow machine, I had to press Esc four times, then eight, before a game would let me leave instead of reloading the level.
That testing turned into a few more levels in Slow Computers, a game about what makes an old PC slow down: short and long music pads, a crowd of monsters on one screen, and a sky where every block animates.
The web player can now run a game “like a” slower machine, down to that PS/1, so the slowdown shows up in the browser too. It even holds the music still while the game reads a sound from disk, the way the PS/1 did.
The browser’s 286 mode didn’t match the slowdown 86Box showed. That was useful, not a failure: it pointed at what the estimate gets wrong and gave the research something real to check against.
More came out of that afternoon, and most of it landed the same day: troubleshooting tips for music with no sound effects (a wrong IRQ) and for the Esc key on slow machines (hold it down), and a Guide page on writing an install script for an exported DOS game. Still to come: an A:INSTALL script on the exported disks themselves, with a short install note on every disk label. Even the strange “³ JET DRIVER ³” game name got fixed: those were old DOS box-drawing characters being read as the wrong alphabet.
Running light
Most of the day, Claude was down to its last 2% of the week’s usage before the weekly reset on Friday evening. So it ran light: instead of writing everything itself, it set up Codex agents on my Mac, pushed Kaylee (my Linux machine) to run Codex agents of her own where there were plenty of tokens to spare, and kept itself to directing and reviewing. You can see the shift on November 6, when the Mac’s orange Claude bars shrink and the blue Codex bars on Kaylee and the Mac carry the work:
That’s how the kernel got made. OpenAI’s Codex (GPT-6.1 Sol) researched the license options and wrote the first design, and Codex (GPT-6) wrote the original M0 code, its tools and its host checks. Claude Opus directed the work and added the profiles, gates and latches. Once the weekly limit reset, Claude Sonnet workers made tonight’s fixes from what the e-ink screen told us: the firmware calls, the card handoff, the rotation, the font and the logo. I held the board, swapped cards and read the screen out loud.
This follow-up covers about 2 AM on Friday, November 6, 2026 through about 2 AM on Saturday, November 7, 2026, in Eastern time. The code is on GitHub: where the last post left off and where this one ends. The Pi kernel is in its own repository, sandbox-kernel.
