James DansereauandClaude Sonnet 5 1d4e912e83 D69.4: verification fixes (D83/D84) + crash safety net (D85) + docs
Verification of the D69 sidecars against a live run surfaced two more
narrow ABI layout bugs, both the same MIPS-BE/x86-LE class as D78/D79:

- D83: StandTileHeaderMid/StandTileHeaderTail bitfield packing. N64/MIPS
  packs the first-declared bitfield into the high bits; x86 GCC packs it
  into the low bits. tile->tail.hdrTail.pointCount (read pervasively for
  tile-size navigation) silently read the wrong nibble on PC, producing
  an out-of-range list_of_tilesizes index and an infinite loop in
  stanBuildRoomData. Fixed under #ifdef PORT by declaring both structs'
  fields in reverse order (verified via probe: byte-identical numeric
  result to N64).

- D84: bgLoadRoomVtxData/bgLoadRoomPrimaryGdl/bgLoadRoomSecondaryGdl each
  hand-roll the BG_SEG_TO_PTR segment fold instead of calling the macro,
  and did it as real 64-bit pointer arithmetic -- the "+0xf1000000"
  doesn't wrap at 32 bits the way the macro's (u32) cast does, so the
  computed file offset came out ~4 GiB too large. Fixed under #ifdef PORT
  by doing the fold as plain u32 math at all three sites, matching
  BG_SEG_TO_PTR exactly.

With D83+D84, load_bg_file and stanBuildRoomData complete without fault
and the game proceeds into room streaming, where it hit a further crash
in bgBuildRoomVtxBounds: the room primary/secondary DL binaries decompress
correctly but texLoadFromGdl (the already-working model-GDL runtime
converter) doesn't produce valid GBI opcodes from their content (D85,
not yet root-caused -- likely a BG-specific GDL marker convention).
Added a PORT-only bounds check before every vtx[] dereference so a
garbage command stream can't segfault the process (produces an empty
bounding box for that batch instead) -- a crash-safety net, not a
geometry fix.

The original D69 bug (load_bg_file faulting instantly on stage load) is
now fully resolved and verified byte-for-byte against BUNKER1's stan
tiles. Two new, separate issues surfaced during verification remain open:
D85 (room geometry decodes wrong) and D86 (a new crash in modelInitRwData
during room-triggered model instantiation, likely unrelated to bg/stan --
see docs/HANDOFF.md). Debug probes GE_D69STAN/GE_D69BB added (stan.c/
bg.c, env-gated, zero cost when unset) and kept for the next session.

Docs: PCPortResearch.md D83-D86, HANDOFF.md and AGENTS.md status rewritten
to reflect current state.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C3xib6jjMV8o2iE4JfixAo
2026-08-27 21:02:31 -04:00
2026-08-16 17:30:25 -04:00
2026-08-17 13:48:42 -04:00
2026-08-17 13:48:42 -04:00
2026-08-17 13:48:42 -04:00
2026-08-16 17:30:25 -04:00
2021-03-08 12:58:16 -06:00
2021-03-08 12:58:16 -06:00
2021-03-08 12:58:16 -06:00
2026-08-17 13:48:42 -04:00

Goldeneye 007

NTSC-Status JP-Status PAL-Status

About this repository

This is a WIP decompilation of Goldeneye 007!

It builds the following ROMs:

  • ge007.u.z64 sha1: abe01e4aeb033b6c0836819f549c791b26cfde83
  • ge007.j.z64 sha1: 2a5dade32f7fad6c73c659d2026994632c1b3174
  • ge007.e.z64 sha1: 167c3c433dec1f1eb921736f7d53fac8cb45ee31

Note: This repository does not include all assets necessary for compiling the ROMs. A prior copy of the game is required to extract the assets.

Documentation

  • Setup Guide: useful information about installing the necessary dependencies and how to use it
  • Structure Guide: learn more about the project structure of this repository
  • Style Guide: code style conventions if you want to contribute code
Languages
C 92.9%
C++ 2.8%
Python 1.8%
Assembly 1.2%
HTML 0.4%
Other 0.7%