Drew T
49fc465a51
§178 — SIX LEVERS FROM THE WAVE-P JOURNALS, each byte-proven and source-cited. Four wave-P repair
agents REFUTED the first pass's own diagnosis by dumping cc1 -dS/-da and reading gcc-2.7.2. The
meta-finding leads the section: "REGALLOC-PERM" is this project's most over-diagnosed class -- in
four functions the symptom was a register swap and the cause was in cse.c or sched.c, decided
BEFORE allocation, which is exactly why pins and statement order all failed.
A. The $0-add OPAQUE COPY defeats cse.c:826 make_regs_eqv (a PLUS is not a (set reg reg)), so the
parm pseudo keeps its register. MATCH on first compile; 3 of 5 pins then became dead weight.
B. A `return <const>` is a priority-1 hard-reg set that the BACKWARD list scheduler places FIRST
in the block, making hard $v0 live across a temp's range. Lever: goto a shared return tail.
C. birthing_insn_p (sched.c:2469) boosts only single-set destinations; splitting a 3-set temp
boosts the insn and drags its feeder chain down.
D. NEW IDIOM: a NARROW destination type blocks copy elision (SI->HI cannot be coalesced), so the
copy survives at its source position -- one type change worth ~20 instructions.
E. The ZERO-OFFSET ALIAS HOLE: memrefs_conflict_p's find_symbolic_term path is only reachable for
offset-0 fields, so an offset-0 store silently loses its dependence and floats.
F. MEM_IN_STRUCT_P asymmetry in true_dependence (sched.c:817): struct-varying vs scalar-fixed do
not depend. Struct-vs-scalar externs are a scheduling decision, not cosmetics.
G. Two modelling traps: `sw $a1,SYM($a0)` is ONE cc1 insn (the lui/addu/store triple is gas -G0
macro expansion, not cc1 output); and __asm__ __volatile__ with a memory clobber is a FULL
barrier that also sinks address chains.
Plus the exhaustion result: 2,240- and 5,040-variant statement-order sweeps moved nothing, because
the schedule was DAG-determined. When order does not matter, look for an alias or set-count
property, not a permutation.
§176j-2 — THE REPAIR PASS, MEASURED: 12 of 39 recovered / 579 ins, taking wave Q from 51 matches
(3,631 ins) to 64 (4,245). Closeness must be COUNTED, not read off the first differing index (my
first measurement reported six "closeness 0" drafts that were actually truncated).
§176k — two silent selector bugs: ranking gate groups by MEMBER COUNT collapses a wide band to the
smallest functions when the gate cost is per-slate (60 cards/2,604 ins chosen where 46/4,829 were
available); and a selector that globs its own output counts the previous attempt as spent (pool
106 -> 46). Any derive-from-disk rule must exclude the artifact it is about to produce.
BFM-decomp
A matching decompilation of Brave Fencer Musashi (PlayStation, SLUS-00726, USA 1998) — the first public decompilation effort for this game.
What "matching" means
The goal is C source code that, compiled with the original-era toolchain (PsyQ 4.x / GCC 2.7.2-family + ASPSX via maspsx), produces a byte-for-byte identical SLUS_007.26 and, eventually, byte-identical overlay binaries. SHA1 checksums are the ground truth; "functionally equivalent" does not count.
No ROM content
This repository contains no game assets, no disassembly output, and no ROM-derived data — only source code, build configuration, symbol names/addresses, hashes, and documentation. To build or contribute you must provide your own dump of the game disc (4-track BIN/CUE, redump layout). See .gitignore for the firewall.
Project status
Latest (Phase 19, 2026-06-20): the project builds 136 binaries byte-identical from a clean tree (the EXE + the resident engine + all 134 location overlays);
make check-all→ 136/136. Fleet byte-identical-from-source is 58.0% (function-instance-weighted; see the PhaseEnds for the byte-weighted ~30% figure and what it includes). Shared engine functions are matched once inov_SC01_077and propagated ×134 viatools/dedup_propagate.py. (The narrative below is Phase-11/12-era; a full refresh is part of the public-flip prep.)
Gen1 (foundation) complete — the matching pipeline is proven end-to-end. make extract && make build && make check rebuilds SLUS_007.26 byte-for-byte identical (SHA1 143dbb89…) from C + assembly, reproducibly across many sessions.
- Compiler pinned by evidence:
gcc-2.7.2-psx -O2 -G0 -mips1 -mcpu=3000+maspsx --aspsx-version=2.56 --expand-div. - 52 functions hand-matched to byte-identical machine code — including the LZSS streaming decompressor — with a decomp-permuter + matching-cookbook "flywheel" to accelerate the next.
- 959 PsyQ SDK functions linked byte-identical (libcd, libgs, libgte, libspu/libsnd, libgpu, libc2, libmcrd, libapi/libcard, libetc) straight from the real PsyQ 4.0 libraries instead of re-decompiling them — bringing byte-identical-from-source coverage of the EXE to ~50%.
- File-loader / overlay system reverse-engineered, with the resident engine blob + location overlays' load addresses proven byte-identical against a live PCSX-Redux RAM dump.
About half the EXE is still INCLUDE_ASM stubs (correct bytes, not yet C), and the bulk of the game lives in compressed overlays inside the .CD archives — Gen2 (overlays & engine at scale) is underway:
- The build toolchain is binary-agnostic (one parameterized pipeline builds any binary), and the always-resident engine blob rebuilds byte-for-byte from source (SHA1
8e17e02f…) — the second binary reconstructed exactly, after the EXE — and is now 86% hand-matched C (123 / 146 functions, up from 0): its scripting turned out to be compiled-MIPS state/mode dispatch, not a bytecode VM, and the save-file + sound (SQV) formats are documented. The harvest used a reusable swarm-of-agents + bit-for-bit byte-gate method (a wrong match can't be accepted) —tools/harvest_verify.py+tools/match_one.py, which carry straight into the overlay phase. - A cross-binary deduplication pipeline is live: a Ghidra-free signer fingerprints all 134 location overlays, and the report finds ~9,000 byte-identical function groups shared across binaries (~28 MB of collapsible code) — a single engine function is byte-identical in all 134 overlays. This is "one match unlocks many": each engine match will be auto-credited across the overlay fleet.
Current phase and detailed progress live in phase-ends/ (newest PhaseEnd_*.md = current state); methodology, rules, and the full roadmap are in PROJECT_CONTEXT.md; environment setup in docs/SETUP.md.
This project is developed primarily by Claude Code driving Ghidra through an MCP server; see CLAUDE.md.
License
Private repository for now. AGPL-3.0 is planned at public release, modeled on sotn-decomp. tools/brave-CUE/ is CUE's BRAVE extractor (GPL, source included) and retains its own license.