- C 88.9%
- Python 7%
- Assembly 2.2%
- OMNeT++ MSG 1.1%
- Makefile 0.6%
- Other 0.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Zach Bacon
f41d4b424c
Some checks failed
Build / Build repo (cn) (push) Failing after 0s
Build / Build repo (gw) (push) Failing after 0s
Build / Build repo (us) (push) Failing after 0s
Check format / Check format cn (push) Failing after 3s
Check format / Check format gw (push) Failing after 3s
Check format / Check format us (push) Failing after 3s
Implements the synchronous (no real OS threads) design for graphic.c/ nnsched.c under PC_PORT, per the threading-model fork found last commit. nnScCreateScheduler no longer spawns schedulerThread/audioThread/ graphicsThread; gfxCreateGraphicThread calls a new gfxproc_pcPortInit() directly instead. gfxTaskStart() calls func_8002A3F4() (which calls PcPort_DrawGfx synchronously) directly instead of enqueueing to sched_gfxMQ. A new gfxPcPortPumpFrame(sc) is the actual per-frame driver: simulates one VI retrace tick (nnScEventBroadcast) then drains gfx_msgQ non-blocking (gfxproc_pcPortPump, same dispatch gfxproc()'s real thread body uses) -- messages posted mid-dispatch (e.g. gfxTaskStart posting NN_SC_DONE_MSG while handling NN_SC_RETRACE_MSG) are picked up on the same loop's next iteration, so the existing message-passing shape didn't need restructuring, just how it's driven. Added port/milestone4_test.c/.h: a self-contained smoke test that builds a green-fill display list by hand and pushes it through gfxTaskStart, wired into port/main.cpp's loop. Getting this to actually link (not just compile) surfaced several real, previously-hidden gaps, each found by a real LNK2019 rather than guessed at: - gSPDisplayList/gSPSegment don't exist in libultraship (only the double-underscore internal __gSPDisplayList/__gSPSegment do) -- added a two-line alias to libultra.h. - osSetIntMask is declared but never implemented -- added a correct no-op stub (port/os_stubs.c), since everything scheduler-related is synchronous on one thread now, there's nothing real to guard. - osSpTaskYield/osSpTaskYielded/osSpTaskLoad/osSpTaskStartGo don't exist at all -- all four are only used in nnScExecuteAudio, which nothing calls under PC_PORT anymore; wrapped its body in #if !defined(PC_PORT) rather than inventing stubs for N64-RSP-specific, Milestone-7 scope. - gFramebuffers, and the F3*/S2* static RSP/RDP-init display lists (src/buffers/framebuffer.c, src/main_segment/graphics/static.c) were real, portable, already-written code that just hadn't been added to the CMake target yet. - Main_StopThread/MusStop (gfxproc_onPreNMI, the NMI/reset-button handler) are real-OS-thread boot code and real audio-engine code respectively -- wrapped both calls out; unreachable anyway since nothing sends PRE_NMI under PC_PORT. - 8 screen-module graphic functions gfxproc_onRetrace's graphic_no switch references are real dead code at runtime (nothing sets graphic_no away from GRAPHIC_NO_0 yet) but still need to link -- added temporary empty stubs (port/milestone4_screen_stubs.c), explicitly marked for deletion once the real files are ported. Result: the full drmario64pc executable now builds and links with exit 0, wiring scheduler init, synchronous graphics-thread init, a hand-built display list, and the real gfxTaskStart -> func_8002A3F4 -> PcPort_DrawGfx -> Fast3dWindow::DrawAndRunGraphicsCommands chain together for the first time. Runtime verification is blocked by this session's sandboxed shell, not by the code: running the exe crashes with STATUS_STACK_BUFFER_OVERRUN inside Context::CreateDefaultInstance() itself, before any Milestone 4 (or even pre-existing Milestone 3) code runs. Confirmed via an A/B test that this isn't a regression: rebuilding the exact previously-pushed Phase 6 commit in this same environment doesn't crash, it hangs indefinitely at the same point instead -- both broken, just differently, consistent with no real GPU/display access here rather than a logic bug in the new code. See the plan file for the full trace. Needs a real desktop with a GPU to complete the visual confirmation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
| .github/workflows | ||
| .vscode | ||
| config | ||
| include | ||
| lib | ||
| libultraship@a0b6e26257 | ||
| linker_scripts | ||
| port | ||
| src | ||
| tools | ||
| Torch@72960ca16f | ||
| .clang-format | ||
| .clang-tidy | ||
| .gitignore | ||
| .gitmodules | ||
| .python-version | ||
| CMakeLists.txt | ||
| decomp.yaml | ||
| diff.py | ||
| diff_settings.py | ||
| LICENSE | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| uv.lock | ||
| vcpkg.json | ||
Dr. Mario 64
Matching decomp of Dr. Mario 64
Dependencies
All the instructions assume the user is using a Debian/Ubuntu based Linux distro. If you are a Windows user then it is recommended to use WSL2 with Ubuntu.
System packages
The build process has the following package requirements:
- make
- git
- build-essential
- wget
- clang
- binutils-mips-linux-gnu
- gcc-mips-linux-gnu
- uv
Under Debian / Ubuntu (which we recommend using), you can install most of them with the following commands:
sudo apt update
sudo apt install make git build-essential wget clang binutils-mips-linux-gnu gcc-mips-linux-gnu
uv
We use uv to manage Python and its dependencies.
See the official uv docs to install it:
https://docs.astral.sh/uv/getting-started/installation/
Then run uv sync to install and update Python and any dependency needed.
If you need to run any Python script directly you can use either
uv run ./script.py or enable the venv in your shell.
Building
Copy your big-endian Dr Mario 64 ROM into the repository's config/us
directory and rename it to baserom.us.z64. Then run the following commands to
download the appropriate compiler versions, extract ROM data using splat, and
build the files back into a rom.
You can pass -j N, where N is the number of cores your processor has (you
can know this value by using nproc), to speedup the build by parallelizing.
make setup
make extract
make
If successful, the last line of output should say:
build/us/drmario64.us.z64: OK
Other versions
This repository has support for the iQue and the Gateway versions of this game.
To build any of those versions place the corresponding ROM in the config/cn/
or config/gw directories of the repo and rename the rom to either
baserom.cn.z64 or baserom.gw.z64, cn corresponding to the iQue version,
while gw corresponds to the Gateway one.
Run the above make commands but pass either VERSION=cn or VERSION=gw to
build each version respectively.
Contributing
TODO: write some contributing guidelines.
Smaller efforts are appreciated. Just open a PR and try to address any review comments left by other contributors c:
This repository takes some heavy inspiration from the DWARF debug information dumped from the Gamecube release. You can access the DWARF dump in this repository: https://github.com/AngheloAlf/puzzle_collection_dwarf
Important note
This matching decomp effort is being done leak-free. If you have looked/worked with leaked materials (i.e. gigaleak) then it's a shame but you can't contribute to this project.
License
This repository is licensed under the MIT license, except for
- files which declare a different license, and
- folders that have their own
LICENSEfile.
In such cases that license takes precedence.
In particular, the src/ folder is licensed under the CC0 license.
N.B.
The intention of this project is to understand the inner workings of this game better, and to make it easier to modify its behaviour.
As such, over and above the actual licensing of the repo, the decomp team requests that this codebase not be used to build binaries targeting non-MIPS machines ("porting").