Turn a 1993 Amiga Port into a Paid Legacy-Code Niche with an LLM

The proof is the product

Most side projects stay side projects, and that is fine. The ones that become businesses usually do it by turning a small, hard artifact into evidence. In legacy code, the rarest thing is not another port. It is a proof you can show a stranger: the old thing still works, the new thing is faithful, and the process was controlled.

Rabah Shihab built the Amiga game Babylonian Twins in 1993 in Baghdad on an Amiga 500, writing it in pure 68000 assembly. That kind of artifact is a perfect test case for a builder with limited hours: it is old, small, emotionally loaded, and impossible to fake.

The game was the first commercial title from Iraq, but it stayed unpublished after Commodore, the Amiga maker, collapsed and sanctions frightened publishers. The story gives the work a reason to exist beyond a demo. It also shows why preservation is a service: old software does not age gracefully, and the people who need it often do not have time to become investigators.

The original disks can be obtained without cost from itch.io, while the rebuilt Definitive Edition is available on iOS and Android, with a Steam release said for the fall. Distribution matters, but the deeper lesson is that a finished artifact can carry a niche. If you can restore one obscure thing and prove it, you can sell the same confidence to studios, hobbyists, and embedded-systems owners who are afraid of their own old code.

An earlier hand port for iPhone in 2010 used a from-scratch engine of about 34,000 lines of C++ and reached over two million downloads. Chasing that number misses the point: legacy work can have a long tail when the proof is concrete enough to be trusted by a stranger.

He did not do the port himself; the AI handled the file-format and assembly work, while he requested, tested, and made decisions. That division of labor is the actual business model for a builder with limited hours. The LLM does the tedious reading and the first drafts. You keep the judgment, the testing, and the final call on what counts as faithful.

The LLM got the 1993 sources to assemble again with an assembler on an Apple Silicon Mac, continuing until the output matched the shipped binaries byte for byte. That is the kind of target that makes a side project feel like a service: not 'it looks close,' but 'here is the check, and it passes.'

The Legacy-Code Product Ladder

Use the same shape for your own weekend project. The aim is one repeatable proof that you can take old, fragile code and make it trustworthy again, not a retro-game restoration company. The scope can stay small.

1. Pick one artifact. Choose something small enough to finish in a few weekends: a homebrew game, an old utility, controller firmware, a demo, a level format, a save file, or a single module from a larger codebase. The artifact should have a clear owner, a clear failure mode, and a reason someone would pay to understand it.
2. Define a verifiable target. Decide what 'done' means before you start. Playable is good. Byte-identical is stronger. A passing test suite, a checksum, a before-and-after recording, or a diff that explains every change can all work. The target should be something a skeptical reader can check without trusting your word.
3. Let the LLM do the reading. Ask it to read file formats, explain assembly, compare binaries, propose translations, and generate test cases. Keep the prompts narrow. Do not ask for a whole port in one message. Ask for one hypothesis, one patch, one explanation, one test. Your job is to keep the work bounded and the evidence clean.
4. Document the proof. Write the notes you would want if you were the client. Include the starting state, the target, the commands you ran, the failures you saw, the decisions you made, and the final result. A short public write-up is enough. The document is the product. It is also the sales page.
5. Sell preservation, porting, or migration. Once the proof exists, package the same skill. Offer a fixed-scope audit for old code, a preservation pass for a homebrew game, a migration plan for embedded firmware, or a compatibility report for a legacy tool. You sell the confidence that the old thing can be understood, tested, and moved forward, not hours.

What makes it a niche, not a demo

A demo is a thing you made. A niche is a thing you can do again for someone else. The difference is usually the proof. If your write-up says 'I ported it,' it is a demo. If it says 'here is the old binary, here is the new build, here is the test, and here is why the difference is acceptable,' it is a service.

Keep the scope small enough that a weekend can actually finish it. That is the quiet advantage of the legacy-code niche: you do not need a team, a server, or a marketing budget. You need one artifact, one target, one LLM-assisted investigation, and one document that makes the result checkable.

Start with one artifact and one checkable result. If it works, you have a niche. If it does not, you have a useful lesson and a cleaner codebase.