Revive Old Tech with Coding Agents: drivers, firmware, crash patches and device bridges

[Program] crashes on [OS] with [error or crash log]. Before proposing any fix, explain which behavior changed between the old and new OS for this code path and how you know.
Then propose the smallest patch, where it applies, and how the patcher will check the file hash first. Work on a copy only.

Lane C in the pack. Cause first, then the smallest fix.

We just fixed [bug]. Write the rule we learned in one line, add a check that fails the build if it is broken again, add a row to CHECKS.md, and prove it: show the check failing on the old code and passing on the new.

Run it after every fix so lessons stay learned.

# Revive Old Tech with Coding Agents: drivers, firmware, crash patches and device bridges

A PaperChaseWebb pack, version 1.0. Written for Claude Code and Codex, with a rules block for CLAUDE.md and AGENTS.md. Plain Markdown, so the brief, checklists and prompts also work with any coding agent that can run a terminal.

Coding agents have become very good at a kind of work that used to take a specialist weeks: making old or abandoned hardware and software work again. A scanner whose chipset Linux dropped. A washer the maker cut from its app. A 1990s game that crashes on 64-bit Windows. A smartwatch with no useful firmware. A console that cannot talk to new controllers. The public build reports behind this pack share a pattern. The wins came from giving the agent a way to see the target, a loop it could run alone, a reference to work from and a growing set of checks. The failures came from guessing, from patching originals and from vague goals.

This pack turns that pattern into a method you can run on your own device or program. It is built from public build reports by people who revived hardware and software with Claude Code and other agents, plus our own setups. Sources are credited by link in the Sources section. It is not legal advice; Section 2 sets out the lines we follow and you should check the rules where you live.

## What is inside

| Section | What it is for |
|---|---|
| 1. The revival pattern | The five things every successful report had |
| 2. The line we hold | Your own device, your own copy, nothing redistributed |
| 3. REVIVAL.md | The one-page brief the agent reads first |
| 4. Pick your lane | Six kinds of revival and how each one starts |
| 5. Eyes on the target | Status blocks, log rings, traces, simulators and screenshots |
| 6. Close the loop | Build, load, read, decide, without you clicking |
| 7. Work from a reference | Open drivers, trace diffs, decompilers and checked output |
| 8. The bug-to-check ledger | Every lesson becomes a check that fails the build |
| 9. Ordered goals and proof | Correct first, fast second, polished third |
| 10. Do no damage | Copies, hashes, backups and a tested way back |
| 11. Sessions and budget | One stage per session, decision and blocker logs |
| 12. Rules block | Paste into CLAUDE.md or AGENTS.md |
| 13. Prompts | 14 prompts from first look to release notes |
| 14. Sources | What we used and how we used it |