Nagano Winter Olympics '98 (USA) decompilation

A complete, byte-matching decompilation of the USA Nintendo 64 release. You must provide your own legally obtained retail ROM.

For a concise record of the compiler behavior, successful matching techniques, failed approaches, final-function breakthrough, asset methodology, and release checks, read Lessons learned.

Verified baseline

• ROM SHA-1: eaf543e195731031a84f4136b506449209e3a8f5
• Big-endian .z64, 12,582,912 bytes, CIC 6102, game code NH5E
• Initial program: ROM 0x1000..0x829E0, VRAM 0x80000400..0x80081DE0
• BSS: 0x80081DE0..0x801954A0
• CPU text catalogue: 1,470 functions / 391,940 function-body bytes
• Linked CPU text also contains 232 bytes of alignment/linker padding outside function bodies; the physical ROM inventory covers it separately from code
• Program initialized data: 129,824 bytes, plus 40 bytes of verified linker padding
• RSP code identified inside the linked text section: 7,296 bytes
• SDK functions named: 241 (220 high-confidence)
• Audio: four libaudio bank files and 327 indexed VADPCM sample payloads
• Music: 23 loader-indexed Konami LZ sequences, 297 tracks, and 33,236 Nagano/Konami events decode and rebuild exactly
• Matching source: 1,470 / 1,470 functions and 391,940 / 391,940 function-body bytes (100%) in 1,328 verified units
• Byte-matched initialized data: 129,824 / 129,824 bytes (100%)
• Classified post-program bytes: 12,047,904 / 12,047,904 bytes (100%)
• Classified decoded-container bytes: 14,762,912 / 14,762,912 bytes (100%)
• Reproducibly extracted asset-region bytes: 12,047,904 / 12,047,904 (generated locally; none are committed)
• Physical ROM inventory: 12,582,912 / 12,582,912 bytes (100%)

Physical coverage does not mean that every field has a final human-readable name. The exact physical ledger classifies every ROM byte and reconstructs every non-code range; the reproducible nested map now assigns every decoded container byte to a proven structural family. Transform records, model-graph records and some texture fields retain provisional descriptive names. See analysis/data_map/README.md and the gap-free analysis/data_map/rom_map.tsv; the earlier conservative inventory remains as historical evidence rather than the authoritative data map. Every original container decodes and re-encodes exactly. Consequently, no non-function byte-matching or structural-coverage work remains. Further field names improve semantic documentation but do not change byte-match progress unless new evidence changes a structural boundary. The generated full-ROM audit records structural metrics and prioritized function queues without promoting heuristic findings.

Verification

Place the ROM at baseroms/us/baserom.z64 (a symlink is fine), then run:

make check

The default build reuses ../n64-decomp-kit and ../BattleTanx/.toolchain. Override N64DK_ROOT or N64DK_TOOLCHAIN for another installation. make verify-matching recompiles every manifest row and compares relocated bytes directly with the retail ROM. make report produces the objdiff v2 report published as NH5E_report for ByteMatch (with the original us_report artifact retained during migration).

The report keeps separate categories for byte-matched program code, byte-matched initialized data, identified bytes in the post-program asset region, reproducibly extracted asset bytes, and gap-free physical inventory. Only code and initialized data contribute to aggregate decompilation progress. Identified audio is not reported as extracted, and loader-referenced ranges do not count as identified assets until their formats are decoded.

Progress trackers

• ByteMatch consumes the NH5E_report artifact published by every successful push to main. The legacy us_report artifact carries the same report so its retained history stays accurate.
• recomp.fyi and compatible project directories consume the root .recomp.json manifest. It records the exact USA revision, ROM identity, project status, method, maintainership, and live ByteMatch report without conflating decompilation with asset inventory.

The machine-readable report is also available directly from ByteMatch as JSON.

make families compares mnemonic-level instruction fingerprints across the function catalogue and reports unmatched functions that share a shape with verified C. Its output is candidate evidence only; every promoted result must still pass make verify-matching.

make unmatched prints the remaining function queue in stable size/address order across every matching manifest. This prevents already verified units from being re-investigated when selecting batch candidates.