[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-92597":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":15,"stars30d":16,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":17,"rankGlobal":9,"rankLanguage":9,"license":18,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":21,"hasPages":21,"topics":22,"createdAt":9,"pushedAt":9,"updatedAt":23,"readmeContent":24,"aiSummary":25,"trendingCount":15,"starSnapshotCount":15,"syncStatus":13,"lastSyncTime":26,"discoverSource":27},92597,"sm64ds-decomp","tangosdev\u002Fsm64ds-decomp","tangosdev","From-scratch matching decompilation of Super Mario 64 DS into C.",null,"C",65,7,2,1,0,5,43.21,"MIT License",false,"main",true,[],"2026-07-22 04:02:06","# sm64ds-decomp\n\n[![Discord Server][discord-badge]][discord]\n\n[discord]: https:\u002F\u002Fdiscord.gg\u002FJXckvdARc\n[discord-badge]: https:\u002F\u002Fimg.shields.io\u002Fdiscord\u002F1520811338568569112?color=7289DA&logo=discord&logoColor=ffffff\n\nA from-scratch effort to decompile **Super Mario 64 DS** into matching C.\n\nNew here? Start with **[CONTRIBUTING.md](CONTRIBUTING.md)**, coordinate work in\n**[CLAIMS.md](CLAIMS.md)**, and if you review or merge PRs read **[MERGE.md](MERGE.md)**.\n\n## Progress\n\n\u003C!-- progress:start -->\n```\nFunctions  ████████████████████████░░░░░░  79.1%   8,978 \u002F 11,349\nCode size  ████████████████░░░░░░░░░░░░░░  53.6%   1,185,092 \u002F 2,211,124 bytes\n```\n\u003C!-- progress:end -->\n\nEvery arm-mode function in the game, drawn as a treemap. Each rectangle is one\nfunction sized by its byte count, green for matched and gray for unmatched, grouped\nby module.\n\n![Decompilation progress treemap](docs\u002Fprogress-treemap.svg)\n\nFor an interactive version where you can hover any function for its name, address,\nsize, and status, see the [progress treemap on GitHub Pages](https:\u002F\u002Ftangosdev.github.io\u002Fsm64ds-decomp\u002F).\n\n## What \"matching\" means\n\nThe goal is source code that, when compiled with the original toolchain, produces a\nbinary byte-for-byte identical to the retail ROM. This is the same standard the N64\n`sm64` project holds to. Every matched function is checked against the ROM, so the\nsource is known to be correct.\n\n## Legal and scope\n\nThis repo contains only original work: the tooling, the hand-written C, and the notes.\nIt contains no ROM and no extracted Nintendo assets. Those are read locally from a\ncartridge dump you own, and they are git-ignored. Do not commit anything derived from\nthe ROM's data or assets, with one deliberate, documented exception: the coordination\ndata on the `chaos-data` branch includes annotated disassembly text of still-unmatched\nfunctions, so contributors can pick up work without a full local setup. This is the\nsame practice as decomp projects committing `.s` files for unmatched code. It is text,\nnot bytes or assets, and each function's disassembly leaves the published data as soon\nas it is matched.\n\n## Notes on the numbers\n\nFunction count climbs faster than code size because the small, regular functions are\nmatched first, while most of the remaining bytes live in the large, call-heavy\nfunctions. The original compiler has been pinned to **mwccarm 1.2\u002Fsp2p3** with these\nflags:\n\n```\n-O4,p -enum int -lang c99 -char signed -interworking -proc arm946e -gccext,on -msgstyle gcc\n```\n\n## How matching works\n\nEvery candidate is verified the same way: compile it with mwccarm, then compare the\nresult to the ROM byte-for-byte, relocation-aware (call and data references are slots\nthe linker fills in, so they are compared structurally). Nothing counts as matched\nuntil that check passes. The work is organized in tiers so the automatic methods clear\nas much as possible before any manual effort:\n\n1. **Automatic templates.** A set of rules recognizes common function shapes (constant\n   returns, field getters and setters, bitfield reads, struct copies, simple wrappers,\n   constructors, and destructors), generates the C, and confirms it against the ROM.\n   This clears the bulk of small, regular functions with no hand work.\n2. **Hand-written.** For functions with real logic, you write the C yourself and verify\n   each attempt until it is byte-identical. A decompiler such as Ghidra is useful for\n   reading the function, though its output never matches on its own.\n\nFor already-banked matches, `tools\u002Flinkcheck.py` performs the stronger relocation\ndestination check: it reconstructs each function's linked bytes and compares them to\nthe ROM, catching wrong callees or globals that the normal unlinked byte diff would\nwildcard. See [notes\u002Flink-verification.md](notes\u002Flink-verification.md).\n\n## Setup\n\nYou supply your own cartridge dump. Full setup (Python dependencies, the proprietary\nmwccarm compiler from the DS-decomp Discord, the dsd toolkit, and unpacking your ROM)\nis in [CONTRIBUTING.md](CONTRIBUTING.md) and\n[notes\u002Fsetup-mwccarm.md](notes\u002Fsetup-mwccarm.md).\n\nShort version:\n\n```\npip install ndspy capstone pyelftools\n# get mwccarm per notes\u002Fsetup-mwccarm.md, then:\npython tools\u002Funpack.py \"path\u002Fto\u002Fyour-own-sm64ds.nds\"\n```\n\n## How you can help\n\nEvery matched function moves the project forward, and the automatic tier means even a\nsmall amount of time goes a long way. See [CONTRIBUTING.md](CONTRIBUTING.md) for the\nfull workflow.\n\n**Contributing code.** Pick a function, write C for it, verify it compiles to the same\nbytes as the ROM, then open a pull request. One function or a small related group per PR\nis ideal. Use only your own legally dumped ROM, and never commit it.\n\n**Coordination.** Discord `beansntoast` for questions and claiming work, or open a GitHub\nissue so two people do not grind the same function.\n\n**Funding.** Sponsoring helps cover both the development time and the AI compute that the\nmatching runs on. Most functions are matched for free by the automatic templates, and the\nharder ones are matched with AI assistance at roughly 5 to 10 cents of usage each. Spread\nacross everything matched so far, that works out to about 5 cents per function on average,\nand reaching the current progress has cost on the order of $200 in AI usage. You can\nsponsor at https:\u002F\u002Fgithub.com\u002Fsponsors\u002Ftangosdev or back the project on Patreon at\nhttps:\u002F\u002Fwww.patreon.com\u002Fc\u002Fthe_tango. This goes toward development and compute only; it\nhas nothing to do with Nintendo's ROM or assets.\n\n**Fastest way to start with an AI assistant.** Paste this into a Claude Code session and\nit will pull the repo and set you up:\n\n```\nClone https:\u002F\u002Fgithub.com\u002Ftangosdev\u002Fsm64ds-decomp and set up the Super Mario 64 DS\nmatching-decompilation toolchain on my machine. Do these in order:\n1. Read CONTRIBUTING.md and notes\u002Fsetup-mwccarm.md in the repo.\n2. Install the Python dependencies: ndspy, capstone, pyelftools.\n3. mwccarm cannot be downloaded automatically: it is in the DS-decomp\n   Discord (https:\u002F\u002Fdiscord.com\u002Finvite\u002FgwN6M3HQrA, resources channel, mwccarm.zip) and I\n   have to fetch it by hand. Wait for me to do that, then help me place it under\n   tools\u002Fmwccarm\u002F.\n4. Unpack my own SM64DS cartridge dump with tools\u002Funpack.py. This writes the ARM9, ARM7,\n   and overlay binaries into extracted\u002F (gitignored), including both the compressed\n   arm9.bin and the decompressed arm9_dec.bin. Use the decompressed image for disassembly.\n5. Confirm the toolchain runs: re-match a function we have already landed (any file in\n   src\u002F) with tools\u002Fmatch.py and check that it still reports identical bytes.\n6. Before matching, read CLAIMS.md and pick a module or address range that nobody has\n   claimed. Add a row claiming it (range, my handle, date), commit it on its own, and\n   push, so no one else grinds the same functions. Work only inside that claimed range.\n7. Pick an unmatched function from the claimed range, help me write matching C for it,\n   and verify with tools\u002Fmatch.py that it compiles to the same bytes as the ROM.\nUse only my own legally dumped ROM. Never commit the ROM or anything extracted from it.\n```\n\n**Claude effort and hit rate.** If you run batches of functions through a Claude agent\nfan-out, watch the **hit rate** (functions that verify divided by functions attempted).\nEarly\u002Ffresh subsystems land 50% or more; as the easy functions in a region get matched,\nthe rate falls. The Claude Code reasoning-effort setting matters here: higher effort\nconverts more of the hard residue but costs more tokens per attempt. A rule of thumb once\na batch's hit rate drops **below 25%**:\n\n- **Keep cracking as-is** if you don't mind the cost. It still lands real functions, but\n  most of the tokens go to attempts that fail, so it is inefficient.\n- **Raise the reasoning effort** (e.g. medium to high). On the hard residue this converts\n  noticeably more functions and is usually cheaper *per function actually landed*, even\n  though each attempt costs more.\n- **Hand-crack with the main Claude session.** When even high effort floors out, the\n  remaining functions are genuine one-off logic. Drop the fan-out and have the main\n  session match them one at a time (disassemble, write C, verify with `tools\u002Fmatch.py`),\n  or build a new template rule if you spot a recurring shape.\n\n## Credits\n\nSymbol names and struct knowledge build on community reverse-engineering work. See\n[CREDITS.md](CREDITS.md). The rule is import knowledge, write code: you may use known\nsymbol names and field offsets, but all C must be written from scratch against your own\nROM.\n\nFunction contributions: [RyanCopley](https:\u002F\u002Fgithub.com\u002FRyanCopley) hand-matched a set of\nfunctions across ov002, ov006, arm9, and ov034 (PR #1), including the first functions in\nov034 and several that had resisted the automated passes.\n[andrewboudreau](https:\u002F\u002Fgithub.com\u002Fandrewboudreau) has hand-matched a large and growing set of\nfunctions across arm9 and many overlays (PRs #2, #45, #48, and the #50 through #60 constructor and\nstatic-initializer batches), contributed codegen notes on boolean materialization and\npredicated-select shapes (PR #49), and reported the scheduler bug fixed in #61.\n[Moundistz](https:\u002F\u002Fgithub.com\u002FMoundistz) contributed 3 matched functions and 8 nonmatching\nfloor entries, plus a pass of placeholder-to-resolved callee renames across the arm9 corpus.\n\nTooling contributions: [webheadvr](https:\u002F\u002Fgithub.com\u002Fwebheadvr) made the relocation\nsymbol resolver module-aware, fixing wrong-overlay symbol picks where overlay address\nranges overlap. [andrewboudreau](https:\u002F\u002Fgithub.com\u002Fandrewboudreau) added a relocation\ndestination audit and an opt-in strict-relocs check to the verify path (PR #47).\n\nThe `tools\u002Fcoddog.py` fuzzy opcode-similarity scheduler was inspired by\n[Chris Lewis's writeup](https:\u002F\u002Fblog.chrislewis.au\u002Fthe-long-tail-of-llm-assisted-decompilation\u002F)\non LLM-assisted decompilation and the Coddog similarity tool it describes.\n\n## License\n\nThe original work in this repo (the C, the tooling, the notes) is released under the MIT\nLicense, see [LICENSE](LICENSE). This applies only to that original work and grants no\nrights to any Nintendo material, which is not present here.\n","这是一个对任天堂DS平台游戏《超级马力欧64 DS》进行从零开始、逐函数匹配的C语言反编译项目。核心目标是生成能通过原厂工具链（mwccarm 1.2\u002Fsp2p3）编译出与零售ROM字节完全一致二进制文件的C源码，所有已匹配函数均经结构化字节比对验证。项目采用分层策略：优先应用自动模板识别常见汇编模式，辅以人工逆向与协作标注。适用于游戏逆向工程研究、经典游戏代码复现、嵌入式ARM汇编分析及开源游戏开发教学等场景。","2026-07-09 02:30:27","CREATED_QUERY"]