The bytecode-VM decompiler that outgrew annotation and became the series’ crucible.
na1-decompilerwas extracted from this vault on 2026-06-05 with full git history preserved (236 commits); active work continues there, not here.
Links: system → NES · toolchain → KOEI tools · series hub → Game Annotation · sibling tooling → Lowering Atlas · project SDK → projects/CLAUDE.md
| Field | Value |
|---|---|
| Logical name | na1-decompiler |
| GitHub | github.com/chrisaacson69/na1-decompiler (public) |
| Sibling path | ../na1-decompiler (resolved per-machine via .claude/local-paths.md) |
| Entry point | na1-decompiler/nobunaga/CONTEXT.md → ROADMAP.md |
| Also carries | na1-decompiler/lowering-atlas/ — the forward-catalog tooling |
| Title | Nobunaga no Yabō: Zenkokuban · design clock 1986 · Famicom port 1988-03-18 |
| Cart | MMC1/SOROM, 256 KB |
| Depends on | koei-nes (family engine) → nes-render (generic render core) |
⚠️ Not cloned on this machine (2026-07-21) — see .claude/local-paths.md. The four RE skills
(/label-walk, /data-walk, /var-walk, /nobunaga) cannot run until it is.
Reachability: clone as a sibling of the vault so ../na1-decompiler/ resolves — portable
across machines and readable by an agent. If a machine doesn’t follow the sibling layout, its
absolute path belongs in that machine’s local resolver — never committed here, since this page is
published.
NA1 is where the meta-question got its sharp answer: when the source is a weakly-grounded formal
language (a bespoke bytecode VM), don’t read it cold — build a deterministic transpiler to a grounded
language and let the model read that. vm_decompile.py (bytecode → C) is the existence proof.
It also radiated theses well outside game annotation — agent design, LLM grounding, transpilation — which is why it gets a crucible hub rather than a single home.
nes · 6502 · mmc1 · nobunagas-ambition · reverse-engineering · assembly