Homebrew, ports and preservation research for obscure and failed vintage platforms — the machines that flopped, got cancelled, or were never documented, and so have almost no public technical record — and native PC ports of console games that never left their console.

The goal is concrete: take technical knowledge that exists nowhere else — compiler bugs, hardware register maps, undocumented file formats, emulator internals — and make it publicly verifiable for the people who come after. For several of these platforms, these repositories are the only public documentation of their kind.

Everything below is either original code or documentation. No repository here contains game assets, ROM data or copyrighted content — the tools read media you already own.

Everything here is published as is. This is reverse-engineering work, not a specification: findings are revisited and corrected over time, but nothing in these repositories is guaranteed to be complete or correct, whether or not a given page says so. Where a claim can be checked mechanically, the repository ships the command that checks it — run that rather than trusting the prose.

Original software, written from scratch for the target hardware.

The Channel F is the constraint that best explains the appeal: a 1976 console with 64 bytes of system RAM, and two complete games written into it.

Console games brought to PC by translating their own machine code to C++ ahead of time and running it natively, with a runtime that stands in for the console's hardware. No emulator underneath and no source code needed: the game's code is the game's code, compiled for a different machine.

The work that every game on a console shares — its discs, its CPU, its graphics and sound hardware, its SDK — lives in a game-agnostic toolkit per console. Each toolkit grows inside the ports: a piece is written because a game needed it, then kept free of that game's knowledge.

Where each one stands is at the top of its README, and in a .recomp.json at its root that recomp.board reads.

Games built from their released source for hardware they were never meant to run on.

Engines rebuilt for PC from their file formats and their behaviour.

All ports, recompiled or rebuilt, are BYOA — bring your own assets. They need a copy of the game you already own.

Three platforms with essentially no prior public reverse-engineering record.

Format archaeology: containers, sprite codecs, map formats, text systems, and the strata a shipped build accidentally preserves. Each repository carries machine-checkable verification commands, not just prose — the claims can be re-run against the files years from now.

The larger families are indexed rather than listed: each index repository links one write-up per title, and the shared platform notes hold each finding once. Counts are kept in the indices, never here. Everything below is reachable from this page in at most two hops.

Some indices were created before their first title, so that the first disc had a structure to be filed into and a set of questions to be measured against. Their checklists mark every claim by where it came from — a disc that was opened, code that runs on the machine, or public documentation only — and never promote a mark because nothing contradicted it.

<platform>-<subject>, where the platform is the target, not the origin. So psx-lba is Little Big Adventure running on PlayStation, and pc-victorious is a Wii game brought to PC.

Two suffixes narrow it further: -doc is documentation only, and -re is a reverse-engineering devlog. Anything without a suffix ships runnable code. A -kit is a game-agnostic toolkit, named after the console it stands in for.

These repositories are part of a larger, ongoing body of cross-console work — an analog-horror ARG series and the homebrew and reverse-engineering that underpins it, spanning many years and many forgotten machines. Which platforms, and in what order, is something the series leaves for players to discover.

This is where that technical work surfaces publicly first.

This is a human + LLM collaboration, stated openly because the honesty is the point. Claude acts as a technical bridge: I bring decades of domain knowledge and direction — knowing these platforms, recognising when a result is a genuine first, and deciding where it's worth digging — and Claude provides implementation across architectures I could not otherwise approach: the drivers, the emulator patches, the disassembly and log forensics, the documentation. Neither side reaches these results alone.

I'm a professional technical translator, a field heavily affected by AI, and I hold a deliberate position about it: AI used for net-new work that displaces no one — reverse-engineering an abandoned console that nobody else was working on — is the case worth defending. Visibility of the collaboration is part of that argument, not a disclaimer.

— @vs-sr-dev