Almost everyone has an old console in a drawer. Many of them aren't dead: they can be unlocked and turned into open platforms that run programs written by anyone. It's called homebrew, it has been around for many years, and it has always been the domain of people who could really program. With today's AI models the bar is much lower: an idea, some patience and a method are enough to bring a new game to an old console.

Why it used to be so hard

Programming a console from the past means dealing with peculiar hardware, scattered documentation, toolchains to set up, and different conventions on every platform. Many remake ideas died before showing a single pixel. An AI assistant can read existing source code, explain an SDK, write code, compile it, fix the errors and repeat until it works. So the question changes: it's no longer "do I know how to program this machine?" but "do I know what I want to build?".

The work you can't hand off is still there: choosing the game, deciding how it should look and behave, playing it, and noticing what's wrong.

What you can do now

Port a classic that never came out for that console. There are much-loved games, often open source, that never had a version for a given platform. Now they can be adapted.

Make your own game. A Tetris-like with the look, rules, scoring and music you decide on no longer takes months of study: it's a few days of trial and error.

The BlockOut 3DS case

The project behind this post is an unofficial port for the Nintendo 3DS, derived from BlockOut II. Let's be clear right away: it's an adaptation loosely inspired by the game, not a one-to-one conversion.

▶️ See it in action: BlockOut 3DS on a New 3DS, the demo video on YouTube.

BlockOut 3DS in play: the three-dimensional pit on the top screen, statistics and controls on the bottom one

Where it comes from. BlockOut is a classic from 1989 (California Dreams, on DOS): a Tetris seen from above in a three-dimensional pit, with solid pieces to rotate on three axes. The port doesn't start from the 1989 game but from BlockOut II 2.5, an open source remake by Jean-Luc Pons under the GPL, whose code anyone can read and reuse. That's what makes the port legitimate: it keeps the same license and credits the author. "BlockOut" is a registered trademark of Kadon Enterprises, used here only to identify the game.

What I did. Rules, piece shapes, scoring formulas, game timings and the automatic player that runs the demo come from BlockOut II. It's not a 1:1 conversion, though: the "MS-DOS" look is a style choice of mine, and I redesigned the menus, setup screens and hall of fame. The rest was adapting what the 3DS hardware requires:

  • controls: D-pad, buttons and touchscreen instead of the keyboard, with rotations spread across the keys;
  • graphics: the 3D pit is computed by the program itself, with a black background, green grid, EGA palette and block characters, plus the 3DS stereoscopic 3D with adjustable depth;
  • audio: effects and soundtrack are synthesized by the console, without a single audio file;
  • saving: options and high scores on the SD card.

How I did it. Working in tandem with the AI, step by step: I started from the original sources, adapted them one piece at a time, compiled, tested in the emulator, noticed what was wrong and had it fixed. I also added an "autotest" build that plays the game by itself, so I can check the graphics without touching anything. When something broke, and it does, the lesson went into a project notes file so the mistake wouldn't be repeated.

The BlockOut 3DS game over screen, with final score and statistics

In the same lab I built two other experiments: Neon Rush, a 3D runner with synthwave scenery and music generated in real time, and Blockfall, a falling-blocks puzzle made my way. The latter changed its name from the original "Tetris" to avoid trademark problems: even when working with AI, rights and trademarks still apply.

The code is open

All three games are published under the GNU GPL v2 or later in the 3ds-homebrew-lab repository on GitHub: sources, build tools and working notes. Anyone with a homebrew-enabled 3DS can compile and try them, and anyone who wants to can use them as a base for a game of their own.

Not just the 3DS: homebrew tools for other consoles

The 3DS has a mature community and development kit. Here are the tools for other consoles:

ConsoleToolNotes
Nintendo 3DS, DS, GBA, GameCube, WiidevkitPro (with libctru, libnds, libogc)The historical reference for Nintendo consoles
Nintendo 64libdragonModern open source SDK; developed with emulators such as Ares and tested on flashcarts like EverDrive64 and SummerCart64
PlayStationPSn00bSDKOpen source SDK with compiler, libraries and tools for building the disc image; the project itself advises against it for beginners
PSPPSPDEVFor custom and official firmware
DreamcastKallistiOSSystem and libraries developed independently from Sega
Sega SaturnJo EngineMeant to simplify a notoriously difficult machine
Sega Mega Drive / GenesisSGDKThe most widely used kit for the console: you write in C instead of 68000 assembly
PlayStation 2ps2dev / PS2SDKOpen source toolchain and libraries, with ports of well-known libraries
PlayStation VitaVitaSDKOpen source toolchain for consoles with the HENkaku/taiHEN jailbreak; SDL2 support also exists
Nintendo SwitchlibnxLibrary for the console's operating system, with the devkitA64 toolchain from devkitPro; programs are NRO files
Game Boy, NES, Master System, Game GearGBDK-2020C compiler and libraries for these 8-bit consoles

They are open source tools with documentation and public examples: the kind of material an AI model works well with.

The limits

  • The result must be verified. AI can write code that compiles and looks right but does something else on screen: audio you can't hear, graphics that break after a few minutes. You need human eyes and ears, or well-designed tests.
  • The hardware has the last word. The emulator helps enormously, but the real test happens on the console.
  • Legality is your responsibility. Port code with a suitable license, avoid other people's trademarks and assets, and use homebrew on your own console. Unlocking a console can void the warranty and violate the manufacturer's terms of use (with the risk of being banned from online services), and the rules on circumventing technical protections vary from country to country: do your research first and never use unlocking to run pirated copies.

Why it's worth it

Rescuing a console keeps it out of the landfill, porting a classic makes it playable again, and a tailor-made game no longer takes years of study. If you have an old console in a drawer, ask yourself which game never came out for it. Today you can try building it.