107 Commits

Include renames

Author	SHA1	Message	Date
ReaperOfVeriod	e389d6d082	UpdateCamera_6 verified at 0x4284a8 -- three independent checks ... The anchor 20655c7 said had to be verified before following. It is. docs/AUG6-RETAIL-ANCHORS.md recovers UpdateCamera_6 and InitCamera_24 as class/role identifiers in the two dispatch tables, so role 6 of lvl.camvtbl is the camera update function. The decomp's addresses are in the same space as ours -- its func_L00_002A3B80 is this overlay's .text dest exactly -- so the claim is checkable rather than taken on faith. Three checks, because PROVENANCE.md records that the decomp's function addresses have failed once here: 1. Role 6 of level 0's lvl.camvtbl names handler 0x004284a8. 2. overlay_bytes_at reads real code there: 0x3c014094, a lui. 3. tools/overlay-anchors decodes the first six words with zero failures: lui $at, 0x4094 ori $at, $at, 0x7ae1 ; $at = 0x40947ae1 mtc1 $at, $f1 ; a float into an FP register lw $v0, 0x2290($s4) lui $at, 0x3f00 mtc1 $at, $f3 ; 0x3f000000 = 0.5f Two mtc1 into FP registers and a struct field at +0x2290: a function doing floating-point work on a camera struct. Three agreeing checks are a different kind of evidence from any one of them, which is the lesson of the moby_anim chase. Caveat recorded: level 0's lvl.camvtbl is 0xb4 bytes, 13 records and 13 distinct ids, but several ids read as implausible large values (4,350,904 and similar). The record layout is not uniformly id/handler, so role 6 being clean may be luck. Worth remembering when the other roles are read. Next, unblocked: read all of 0x4284a8 and find the store that writes 0x18aa70. That confirms m4 by locating the write site rather than inferring it from input response, and the frustum should be whatever the same function writes nearby. 295 passing, clippy clean.	2026-10-15 03:36:08 +02:00
ReaperOfVeriod	20655c7744	Stop pattern-matching RAM: follow UpdateCamera_6 from lvl.camvtbl ... Two more frustum searches, both unproductive, then the lookup that should have come first. Non-orthonormal 4x4 matrices within 4 KB of the camera, reasoning that the projection must live nearby: 79 candidates, every one a sliding window over data rather than a matrix. The filter does not discriminate and the region has no obvious projection. Then: the decomp names the camera. include/engine.h and docs/AUG6-RETAIL-ANCHORS.md reference UpdateCamera_6, InitCamera_24 and Camera_CollPrimTest, and docs/COMMUNITY-ENGINE-REFERENCE.md places lvl.camvtbl at 0x0026E900. The camera dispatch table is already characterised -- 217 records, 14 distinct ids on level 0, handlers in the overlay .text. That is the right way in. The camera writes its matrices at 0x18aa70; the function that does so is reachable from camvtbl, and the frustum is whatever that same function writes nearby. Reading it would confirm m4 by finding the write site, and pick up the frustum constants beside it, without guessing at float patterns. The caveat that applies first, and why this was not done first: the decomp's function addresses have already failed once here. PROVENANCE.md records that they do not resolve for the moby class loader, while struct layouts transcribed from the decomp were usable. So UpdateCamera_6's address must be verified against the overlay before following it, not trusted from the name. Resuming here is a different kind of task from the three searches above: follow a known call site instead of pattern-matching a 32 MiB heap. 294 passing, clippy clean.	2026-10-15 03:32:18 +02:00
ReaperOfVeriod	ca42793e48	Frustum search: bounded with a proper filter, not found ... e7eec01 located R and the camera; the remaining operand is the frustum. Searched with the same shape of filter that found the camera -- structural invariant first, differential second. First attempt discarded: scanning for a perspective-matrix signature returned 11,846 hits, which is noise and means the filter was worthless. Recorded because the number looks like a result. Second attempt, the right filter: unit-length 3-vectors at 16-byte alignment, the invariant that identified the camera matrices. 9,514 found, 188 forming clusters of four or more. The six-vector cluster at 0x189e20 is a frustum's exact shape -- six planes, 96 bytes -- and it is not one. It reads as three orthonormal basis vectors plus a zero affine row at 0x30 stride, with a translation at 0x189ea0 near the camera: a table of positioned things. So the frustum is not located, and I am not picking the six-vector cluster because six is the number a frustum has. That is rule 4's failure with an exact number attached to make it feel earned, which is what I have already committed twice in this investigation. What the search did establish: the structured regions near the camera are the nine matrices at 0x18aa70, orientation records at 0x189e20, and larger clusters at 0x1793f0 and 0x18b260. The frustum is not among them as planes. Which points at the next search, and it is a different one: guard_band's signature is Frustum { near, far, tan }, not six planes. If the frustum is stored as near/far/tan scalars, the search should be for a stable float pair with a plausible ratio, not for normals at all. 294 passing, clippy clean.	2026-10-15 03:31:19 +02:00
ReaperOfVeriod	e7eec01b50	m4 is the live camera: a 20x outlier against eight controls ... d4e81ba left one question: the camera's rotation is one of the nine, but which. Answered by turning the camera in the live emulator and watching which matrix responds. Ten captures at ~0.6s intervals; angle through which each matrix's first row rotated, from capture 1: idx 1->4 1->7 1->10 m0 0.37 0.27 0.53 m1 1.31 1.07 1.34 m2 3.89 1.38 1.43 m3 2.25 1.18 1.40 m4 30.60 18.49 37.21 <-- the camera m5 1.70 1.45 1.82 m6 1.24 0.98 1.29 m7 1.88 1.34 1.73 m8 1.70 1.45 1.82 The eight others are the control and they sit under 4 degrees across the whole sweep while m4 goes to 30-37. Its motion is non-monotonic, tracking the input being turned one way then back. The translations gave the complementary half: all nine move together by the same few thousandths. So the nine share one camera position and carry nine different orientations, one of which is live. guard_band step 1 now has both operands: R rows 0-2 of the matrix at 0x18ab70 camera its fourth row, (247.1, 193.4, 50.4) on Aranos NOT established: why there are nine. They are not nine cached frames of one camera -- if they were, all nine would have swung by 30 degrees together. They are nine distinct orientations about a shared point with one selected, and a table selected by an index fits. The nine-legal-orientations-on-a-spherical-planet reading stays plausible and unproven; what is proven is which entry is live. No reindexing was observed, so if the index moves it does not on camera rotation alone. 294 passing with the disc and savestate present, clippy clean.	2026-10-15 03:29:14 +02:00
ReaperOfVeriod	d4e81ba977	Correction: the camera region is nine matrices, not three ... dcd4dd6 said three 4x4 matrices at 64-byte stride and read them as a view/modelview/lighting family. There are nine. Contiguous from 0x18aa70, breaking at 0x18acb0 where row norms are 0, 0, 0.97 and w = 0. All nine are orthonormal to 1e-6, all affine, all translating inside a 0.4-unit box, all moving smoothly between live frames. Nine different rotations about one position is not a view/projection/lighting family -- it is a table indexed by orientation, and the index is what is unknown. So dcd4dd6 was right that the region holds the camera position and wrong that three was the extent. It stopped at three because three read as a sensible story. That is rule 4's failure and I have now committed it twice in this investigation. What survives unchanged: the translation is the camera position, (247.3, 193.1, 50.5), verified by orthonormality plus the smooth-motion control. The rotation changes far faster than the translation between frames, which is what identifies which part is which. What is now open and larger than it looked: which of the nine is the R that guard_band step 1 wants. Not "pick m0". Nine orientations about one point is a table with an index. A plausible reading -- that these are the nine legal camera orientations on a spherical planet -- would be a real find and is NOT established by anything measured here. Two cheap checks, both needing only the live emulator: move the camera and see whether all nine translations move together or only one; and change pitch to see whether the nine rotations reindex. The test now checks all nine rather than three, so a tenth would be noticed. 294 passing with the disc and savestate present, clippy clean.	2026-10-15 03:27:01 +02:00
ReaperOfVeriod	dcd4dd6246	Camera transform found at 0x18aa70: three orthonormal matrices, one position ... With PCSX2 on Aranos the savestate problem went away. PINE reads EE RAM live, so two dumps seconds apart are consecutive frames by construction -- exactly what the offline savestates could not provide (1aa94ee). Of 1,654 changed 16-byte float triples between two live dumps, most singletons are mob positions moving 4-5 units. One region is three 4x4 matrices at 64-byte stride, each with an affine fourth row: 0x18aa70 0.0338 -0.1983 0.9796 0.0000 -0.0275 -0.9799 -0.1974 0.0000 0.9990 -0.0203 -0.0386 0.0000 247.2990 193.1330 50.4526 1.0000 0x18aab0 t = 247.239, 193.102, 50.497 0x18aaf0 t = 246.940, 193.155, 50.151 The control that makes this an identification rather than a coincidence: all three upper 3x3 blocks are orthonormal to within 1e-6 -- row norms 0.999995..0.999998, pairwise dots at or below 1e-6. Three consecutive float triples in a random 32 MiB region being unit length AND mutually perpendicular does not happen twice. The residual is f32 rounding, expected on an FPU that is not IEEE-754. Camera position on Aranos: (247.3, 193.1, 50.5). camera_transform_is_orthonormal_with_a_moving_translation asserts orthonormality, w == 1, and that the translation moves smoothly but not wildly. That last half is the check 1aa94ee needed and the savestates could not supply: consecutive frames give 0.002-0.005 of movement, against ~230 between unrelated savestates. What this unblocks: guard_band step 1 is R * (bsphere - camera * 1024). Both operands now exist. R is rows 0-2 of 0x18aa70 and the camera is its fourth row, so the clip test can run against a real frame for the first time. Not assumed, and recorded as open: which of the three matrices step 1 wants; whether the float translation needs converting to the disc's 12.4 fixed point first (the algorithm multiplies by 1024, which implies it does); and the frustum planes, which the guard band needs and which are not in this structure.	2026-10-15 03:23:02 +02:00
ReaperOfVeriod	3dbd384b59	The guard-band clip test: implemented and unit-tested ahead of the camera ... 1aa94ee moved the camera hunt behind a PCSX2 session, because no two savestates on hand are consecutive frames. But the camera is only part of this item -- the test itself is a pure function over a camera and a frustum, so it can be written and tested now, and then drop straight in when the camera is found rather than being written under time pressure later. New gc_formats::guard_band implements docs/plan/tfrag_rac1.md 3b.2 steps 1-7, returning Cull, Normal or ClipAtLod0. Seven unit tests: directly ahead, behind camera, beyond far, straddling the side planes, all-corners-outside-one-plane, the integer sqrt, and a rotation. This is not speculative plumbing. The inputs are already parsed and verified: TfragGeometry::bsphere, clip_corners (8 corners, median 1.000x the bounding radius from their centroid) and draw_mode (matching the reference table). WHAT THE FIRST VERSION GOT WRONG The reference culls when ONE plane has every corner outside it. I first wrote "every corner is outside some plane", which culls patches that merely straddle *different* planes. The test caught it at once: a patch whose corners were beyond far in one axis and the side plane in another returned Cull where it should be ClipAtLod0. Fixed by carrying a per-corner 4-bit mask of which planes it is outside and testing each plane across all corners. That is what the guard band is for. A patch outside the frustum but inside the guard band must still draw, via the clipping program, so objects partly off-screen do not pop. Collapsing the two turns "4x guard band" into "immediate cull", and the symptom is objects vanishing at the screen edge rather than any error. NOT VERIFIED AGAINST THE GAME Steps 1-4 are implemented from the reference and have not been compared to a real frame, for the reason above. The unit tests check the algorithm implements the documented rule, not that the rule is what the game does. Two scales are my reading of the fixed-point convention and are NOT established: tan = 1024 for 1.0, and the clip-cube scale of 64. Both are flagged in the module doc so they are not mistaken for measured facts. 293 passing with the disc and savestate present, clippy clean.	2026-10-15 03:09:57 +02:00
ReaperOfVeriod	1aa94ee288	0x152c70 rejected as the camera; the savestates are not consecutive frames ... Ran the cheapest confirmation from a991088 on the candidate: [247.000, 194.000, 49.890] step 0.000 [293.960, 411.810, 115.000] step 232.133 [506.306, 311.614, 116.656] step 234.804 [300.170, 227.480, 128.000] step 222.933 Rejected. A camera between consecutive frames moves a little; this moves ~230 units per step and is not monotone on any axis. It is per-frame state but not a camera position. a991088 wrote the prediction down before the measurement, so the candidate is out rather than reinterpreted. The more useful consequence: these four savestates are not consecutive frames, so smoothness cannot filter the 2,005 candidates until consecutive frames exist. Both cheap confirmations need something the savestates do not provide -- consecutive frames, or an actual camera perturbation. That moves the camera hunt from offline to needing a PCSX2 PINE session, the same category as the tfrag morph. Worth noting the shape of it: the differential produced 2,005 candidates and the confirmation reduced them to zero in one step, because the confirmation was written before the measurement was interpreted rather than after. 286 passing with the disc and savestate present, clippy clean.	2026-10-15 03:04:33 +02:00
ReaperOfVeriod	a991088103	Camera state: 2,005 per-frame float triples, one singleton candidate ... The guard-band clip test's blocker is named in core-data-regions.md: the algorithm needs the camera and the frustum, both per-frame, so it needs a savestate. Two savestates give that as a differential -- anything that moved is per-frame state -- without needing to know where the camera lives. Frames .01 and .04, 33,554,432 bytes each. Of every 16-byte-aligned triple of finite floats with magnitude 0.001..100,000, 2,005 differ. Two shapes, clearly different things: the 0x1886xx block repeats one triple four times at 16-byte stride, which is a per-object array, and 0x18aa70 holds a near-unit vector that reads as a direction. 0x152c70 is a singleton, [247.000, 194.000, 49.890] -> [300.170, 227.480, 128.000], in the range Aranos occupies. Not claimed as the camera. 2,005 candidates is not a shortlist and a plausible shape is not evidence -- this stretch has produced enough of those. Three confirmation steps recorded, cheapest first: smooth motion across .01-.04, a singleton rather than an array element, and perturbing the camera in an emulator to watch that one address change. The first two need only the savestates already on disk; the third is what the lighting verification used. 286 passing with the disc present and GC_SSTATE set, clippy clean.	2026-10-15 02:15:05 +02:00
ReaperOfVeriod	e3e0a30030	The GS TEX0 register set, and why TBP0 is region-relative ... Picking up "the GS register set the level load builds from the texture entry" from level-assets.md, for a renderer that emulates the GS rather than resolving texture addresses on the host. gc_formats::gs gains tex0_of (TBP0, TBW, TW, TH, PSM), texture_slot_bytes and clut_base. Three measurements back them, over all 27 levels and 1,595 textures. Every dimension is a power of two: 1,595 textures, zero exceptions, in four classes -- 128x128 (1,249), 64x64 (303), 256x256 (22), 32x32 (21). The GS addresses textures by exponent, so TW and TH are log2 of the dimensions, and a texture that was not a power of two could not be addressed at all. That the whole population is one is the measurand for the decode. TBP0 is region-relative. 19 of 27 levels have a textures_base only 64-byte aligned -- mod 256 reads 0, 64, 128 or 192 -- while every entry's own data_offset is 256-aligned on all 1,595. A base pointer computed from core_data would therefore not be a whole number of 256-byte blocks on those levels. The first version of tex0_of took textures_base + data_offset and rejected 1,168 of 1,595 textures for exactly this reason, which is how the finding surfaced. The slot is level 0 plus one mip level: the stride between consecutive entries is w*h + (w/2)*(h/2) on 1,560 of the 1,564 ascending gaps -- 32x32 gives 1,280, 64x64 gives 5,120, 128x128 gives 20,480, 256x256 gives 81,920. One byte per texel. `ty` reads 3 on all 1,595, so it is not the stored level count. Four gaps break the rule and four more run backwards. Both are reported as bounded exceptions rather than folded into an average: the four ascending outliers are 712,960 to 1,064,960 bytes, two orders of magnitude past any slot the game allocates, so they are boundaries the slot rule does not describe rather than slots that came out different. The four reverse gaps mean the table is not sorted by data_offset, which a consumer walking the region in table order would trip over. The CLUT address is the established palette * 0x100, restated as clut_base because a GS emulator asks for it as TEXCLUT's CBP. Still open after this: TEXCLUT's own fields, MIPTBP1/2 wiring, and how the ad-gifs' A+D values relate to this base. Suite with the disc: 70 disc tests, 160 gc-formats, 22 gc-trace, 23 gc-engine, 19 gc-game. Clippy clean.	2026-10-14 13:36:16 +02:00
ReaperOfVeriod	66e83f1665	The tfrag clip cube is at +0x38, and +0x2e is the mini-sphere array ... TfragHeader carried a field named `cube_ofs` at +0x2e. R&C1 documents that slot as `msphere_ofs` and puts the 8-corner clip cube at +0x38. The disc is on R&C1's side for both. Reading +0x2e as an array of `msphere_count` (+0x2c) Vec4f entries gives 833 of 833 well-formed arrays: four finite floats per entry, every radius non-negative. +0x2c takes 4, 3, 5, 6, 16 and others. Reading that same slot as eight s16 clip corners gives data that is not corner-shaped, which is how the error was visible at all. The real cube at +0x38 is non-zero on 833 of 833 headers and its eight points sit inside the patch's own block on every one. So: `cube_ofs` at +0x2e is renamed to `msphere_ofs`, the count it pairs with is parsed and the array is read into TfragGeometry as `mini_spheres`, and `clip_cube_ofs` at +0x38 is new, read into `clip_corners`. What the corners are, measured over all 833: corners, all with 8 distinct x values 833 of 833 |centroid - bsphere centre| / r median 0.147, max 0.595 corner distance from centroid / r median 1.000 The median is exactly the bounding radius, so the eight points lie on the bounding sphere. They are not an axis-aligned box: every tfrag has eight distinct x values, so if it is a box it is oriented. Whether they form a cube needs the corner ordering, which is not recoverable from the data -- assuming opposite pairs are (0,7)(1,6)(2,5)(3,4) matches body-diagonal == 2r on only 99 of 833, so either that pairing is wrong or the array is not a cube. Recorded as unknown. This was picked to unblock the guard-band clip test from the roadmap. The algorithm is from the vendored R&C1 reference and is recorded with its attribution: camera-space sphere, near/far truncation, side-plane cull, then the 8-corner re-test against the frustum unscaled and against a volume with xy x (0.25, 0.25) -- the 4x guard band -- with any corner outside the guard volume sending the tfrag to the clipping path at LOD 0 with no morphing. draw_mode already matches that table. What the test still needs is the camera matrix and the frustum as a clip volume, both per-frame state, so the camera has to be pinned at a savestate. The geometry side is now parsed and asserted, which leaves only the camera side outstanding. The s16 x 64 corner scale is R&C1's documented one and is not verified against the game; the assertion covers that the parsed corners sit inside the patch's own block and lie on the bounding sphere, not that the scale is right. Suite with the disc: 69 disc tests, 156 gc-formats, 22 gc-trace, 23 gc-engine, 19 gc-game. Clippy clean.	2026-10-14 13:09:54 +02:00
ReaperOfVeriod	3a1156d8e1	The tfrag morph is not in the data block: positions are verbatim in RAM ... The morph was recorded as unverifiable because "reading a weight back out of RAM does not work -- the positions live inside regenerated VU packets". That is right about the correspondence and wrong about the cause. The cause is measurable, and it comes back clean: patches 833 positions 40,600 disc == ram positions identical 40,600 block bytes differing 166,465 inside a position unpack 0 inside another unpack 49,484 in a VIF command word 116,981 Range: level 0, all 833 tfrag patches, live PINE RAM against the disc. Two independent measurements agree. Walking the VIF lists on both copies and comparing parsed positions gives 40,600 identical and zero changed; a raw per-byte diff of each patch's own extent classifies every differing byte, and none of them is in a position unpack. The position ranges total 490,224 bytes. So the blend is not precomputed into the geometry. The rewrites are packet framing -- 70% command words -- plus other unpack payloads, which is the loader rebuilding the VIF packet for the tier it selected while leaving the vertices alone. The morph happens at draw time in the VU stream. The standing note becomes a sharper one: there was never a correspondence problem. The values were identical, so there was nothing to read. gc-trace gains verify-morph, which does both measurements. TfragGeometry gains position_ranges and other_ranges so the walk needed to classify a diff is already paid for, and the ranges come from the same walk the rest of the parse uses rather than a second one that could drift. Per-patch extents are the gap to the next patch's data pointer. That is exact and needs no guess about which header field marks a patch's end; the first attempt at this compared each patch against the whole rest of the region and reported 65 million differing bytes, which is what an unbounded comparison looks like. tfrag_positions_are_verbatim_and_the_rewrites_are_elsewhere is gated on GC_SSTATE and asserts the four bounds, plus two guards: the rewrites must be non-trivial (over 100,000 bytes) and mostly command words, so a RAM image that was a verbatim copy of the disc -- which would make the zero look good for the wrong reason -- fails instead. Suite with the disc and GC_SSTATE: 68 disc tests, 156 gc-formats, 22 gc-trace, 23 gc-engine, 19 gc-game. Clippy clean.	2026-10-14 12:27:38 +02:00
ReaperOfVeriod	d4aeb94616	Extent check inconclusive; the opcode field itself is not understood ... Tried to answer whether the decomp extents land on CPU code by checking for a prologue. Only 29 of 3,835 matched 'addiu $sp,$-N' or 'lui $gp' -- but the other bucket is full of textbook prologues my two patterns miss, because PS2 leaf functions save registers with no frame adjustment: 0x2a4ef0 ffb00000 ffb10008 sw $s0,0($sp); sw $s1,8($sp) 0x2a48f0 3c013f80 44816000 lui $1,0x3f80; bc1t Not reading a result into that. Separately, ffb00000 has major opcode 0x3f, unused in MIPS32, yet is unmistakably a register-save prologue and ffbf0020 for 'sw $ra,0x20($sp)' appears throughout this code. Either the EE encodes sw outside MIPS32 or I am reading the opcode field wrong somewhere. Not resolved -- and it undercuts every opcode-based check in this investigation, the 391 and the neighbour ratios included. Position after twenty-one commits: the mapping is verified, two targets are VU microcode, and the candidate windows are not established to be CPU code. What this needs is one authoritative disassembly of one extent compared against tools/overlay-anchors, to establish what the opcode field means. That is the same mistake one level down from the section-indexing bug: using a decoding never checked to produce results, then measuring those results with the same unverified decoding. 286 passing with the disc present, clippy clean.	2026-10-14 06:28:26 +02:00
ReaperOfVeriod	91b09955c8	The shortlist points at VU microcode; the decomp extents are unverified ... 391 candidates on correct bytes, 73 under 16 immediates. The densest, 0x2dca20, 164 bytes with three distinct immediates, disassembles through tools/overlay-anchors as: xori.b $w0, $w0, 0xa2 ext $v0, $s0, 0, 1 addu $a2, $v0, $a2 xori.b and ext are VU1 mnemonics and three-operand addu is not MIPS32. Capstone is decoding COP2: 0x2dca20 is VU microcode. Same answer 0x2ee138 gave. That calls the frequency result into question more seriously than the displacement did. The measurement filtered on opcodes excluding COP2, so VU cannot explain the 391 counts directly -- but the function extents come from the decomp's CPU analysis, and if an extent spans a VU region the window scanned is mixed and the immediate set attributed to that function is not a function's. Status: the enrichment is real as a measurement of those windows; what the windows are is now doubtful. Next: verify decomp extents land on CPU code before trusting any of them -- decode a sample and require a plausible prologue. Same shape as the cd16485 check, and the fourth time a 'real shortlist' has needed one more verification first. 286 passing with the disc present, clippy clean.	2026-10-14 06:27:05 +02:00
ReaperOfVeriod	36d8d2b00c	The frequency enrichment survives the redo; the disassembly does not ... Redone through overlay_bytes_at, the verified flat mapping: functions kept 2,313 moby_classes 0x00c0 391 (displaced: 394) best neighbour (0x00c8) 15 (displaced: 4) bucket n 0xc0 best neighbour ratio (displaced) 0-15 1,033 73 2 36.5x 72.0x 16-31 759 118 4 29.5x 29.8x 32-47 283 89 2 44.5x 34.7x 48-63 118 41 3 13.7x 19.5x 64-79 55 32 2 16.0x 15.5x 80-95 37 22 2 11.0x 13.0x The reason it survives is worth stating, because it separates the two results. The displacement was uniform -- every window shifted by the same amount -- so a function's contents barely changed, and a frequency count over a window is robust to that. A disassembly is not: it depends on the exact byte alignment, which is what was wrong. Hence 394 becoming 391 with the same shape, while the 0x3a8060 walk and the 16-byte stride evaporated entirely. So the investigation was not "all wrong". Precisely: - the frequency enrichment is real, now on verified bytes, with a test that fails if it goes; - the disassembly was never real, and the whole jal chain built on it is retracted; - no loader has been located, and 0x2ee138 is VU microcode. THE LESSON IS ABOUT WHICH MEASUREMENTS SURVIVE A MISTAKE A count over a window tolerates a constant displacement. A decode does not. Sixteen probes leaned on the kind that does not tolerate it, and reported each with the same confidence as the kind that does. Nothing about the numbers distinguished them at the time -- that is the whole difficulty, and why the verification in cd16485 was the missing step rather than a formality. Next: the ~391 functions are a legitimate shortlist, but consuming them means disassembly through tools/overlay-anchors, whose output is now checked against a word the build pins. 286 passing with the disc present (23 + 19 + 66 + 156 + 22; disc binary 34.89s), clippy clean.	2026-10-14 06:23:49 +02:00
ReaperOfVeriod	4a826997f6	Redone on correct bytes: the disassembly chain is gone, 0x2ee138 is VU microcode ... Re-read through overlay_bytes_at, the verified flat mapping from cd16485. 0x2ee138 is VU1 microcode: five COP2 instructions and a jr $ra stub. Nothing you jal into, so the jal read from 0x3a3d70 cannot be right either -- and that instruction was itself read from displaced bytes and must be re-read. 0x3a8060 is not what cee17c9 said. On correct bytes there is no addiu r17, r18, 0xc0, no 16-byte-stride walk and no function prologue; the first word is opcode 0x1f, which is not a MIPS user opcode. cee17c9's central finding does not exist. State: overlay_bytes_at verified; 0x2ee138 is VU microcode, verified; the 0x3a8060 walk retracted; the frequency and neighbour-enrichment numbers not re-measured and not quotable as exact; the e1482ab jal chain unverified, built from displaced bytes and pointing at now-known VU code. What is left of moby_anim is nothing. No loader located, one frequency result to redo from scratch on correct bytes, and no reason to expect it to survive. 285 passing with the disc present, clippy clean.	2026-10-14 06:20:27 +02:00
ReaperOfVeriod	e6b3e0b091	Root cause: the per-section indexing used throughout this investigation was wrong ... The verification f2d7e7e asked for. Reference case: the tool disassembles 0x2ee138 as 0x4bc00083; reading the flat overlay at 0x2ee138 - LIT_BASE gives 83 00 c0 4b, little-endian 0x4bc00083. Match. Correct mapping is off = ram - LIT_BASE indexed into the whole overlay.bin. What I used in every probe: off = addr - secs[6].dest indexed into secs[6].data, and OverlaySection::data includes the 16-byte section header. Every read was displaced. Invalidated: - cee17c9's addiu r17, r18, 0xc0 disassembly, the 16-byte-stride walk, and the 'address not float' conclusion. Built on wrong bytes. - the immediate-frequency and neighbour-enrichment numbers in 3ea5ab7 and a2f8c92. Scanned per-function windows, so uniformly displaced: ratios are probably robust, exact counts are not measured on the bytes they claim. - e1482ab, d97e7df, f2d7e7e: the jal decoding was verified correct, so branch targets stand; what lives at them was read wrongly. Survives intact: every chunk-offset measurement in the tie and overlay work, which read core_data and the overlay flat and never went through the section index. Fix: never index secs[n].data by addr - secs[n].dest. Either use overlay[addr - LIT_BASE], or add a helper that accounts for the 16-byte header so call sites cannot forget it -- and verify it against a word the decomp pins, as above. This was available from the first probe and skipped sixteen times. 284 passing with the disc present, clippy clean.	2026-10-14 06:14:14 +02:00
ReaperOfVeriod	f2d7e7ecd4	d97e7df was wrong: my section offset was wrong, not the decoder ... Ran gc-overlay-anchors on 0x2ee138 as d97e7df directed. It reports 6 of 12 words did not decode -- but the words disagree: tool: 0x2ee138 0x4bc00083 my read: 0x2ee138 0xd8a10000 Different bytes at the same address. My offset into the section is wrong, so the 'opcode 0x36 is invalid' finding was about bytes never at that address. That invalidates d97e7df's conclusion and its 'second decode error' framing: the decoder was never the problem. The tool's words are COP2 (0x12), VU1 vector-unit instructions, which capstone will not render under plain MIPS32. So its 'did not decode' is expected for VU code and says nothing either. Four bugs in this investigation, all mine: un-masked branch target, transposed address, invalid opcode read from wrong bytes, and the offset mapping itself. Every one was a self-consistent probe reporting a clean number. The check that catches all four is verifying the tool against a known-correct case before using it to generate a finding -- which d97e7df recommended and I then skipped. Nothing about 0x2ee138 is now known: not VU code, not data, not a function. The address is the correctly decoded jal target; what is there is unestablished. Next step is to fix and verify the address-to-overlay mapping before re-reading anything. Until then no address computed by hand in this investigation is trustworthy, including the 0x3a8060 walk that happened to decode. 284 passing with the disc present, clippy clean.	2026-10-14 06:01:54 +02:00
ReaperOfVeriod	d97e7df41f	Second decode error in the same investigation; stopping rather than trusting this decoder ... Following e1482ab I disassembled the function supplying r2 and made two errors, both mine. First I read the jal target as 0x2ee178 when it is 0x2ee138 -- 0x0bb84e << 2 is 3,072,312. Second, at the correct address the bytes do not decode: d8a10000 is opcode 0x36, which is not a valid MIPS major opcode for user-space code. The coherent readings are that this is data, that the decomp's extent is mis-bounded, or that the jal target is still wrong. Stopping here deliberately. An un-masked branch target that reported a false negative, and a transposed address that produced plausible-looking garbage, are enough to make anything else from this decoder untrustworthy. The next step is not another immediate scan or another hand-decoded disassembly -- it is tools/overlay-anchors, which links capstone, verified against a known-good function first. The established chain, with nothing inferred beyond it: 0x3a3d70 jal 0x2ee138 target decoded, callee unidentified 0x3a3d84 jal 0x3a7c30 r2 = return value of the above 0x3a7c30 580 bytes, never writes r2 0x3a7d88 jal 0x3a8060 passes r2 through 0x3a8060 addiu r17, r18, 0xc0 with 0xd0 and 0xe0; 16-byte-stride walk What 0x2ee138 returns is unknown, and it is the single remaining link between the program and moby_classes.offset. 284 passing with the disc present, clippy clean.	2026-10-14 05:56:00 +02:00
ReaperOfVeriod	e1482abd75	Correct my own decode bug: there is a caller, and r2 is a return value ... 349b498 reported that 0x3a7c30 has no jal callers. That was wrong and the bug was mine: the scan built J-type targets as ((instr & 0x03ffffff) << 2) | 0x0c000000 without masking to the upper nibble, adding 0x0c000000 to every target so nothing matched. Corrected: exactly one jal caller, at 0x3a3d84. Still no j tail-calls, still not a vtbl handler, still not a pointer in any level-0 data file. Tracing back, r2 is never written between the call and the use: 0x3a3ce4 lw r3, 0x1500(r2) 0x3a3d70 jal 0x2ee178 0x3a3d84 jal 0x3a7c30 so r2 is the return value of 0x2ee178, passed through as the first argument. The chain is now 0x2ee178 returns a pointer -> 0x3a7c30 -> 0x3a8060 -> addiu r17, r18, 0xc0. Next question is one function: does 0x2ee178 return core_data + moby_classes.offset? If so the reading is confirmed and the loader is located; if not, the 0xc0 in 0x3a8060 is an unrelated struct member. Also recorded in docs: a negative from a hand-rolled decoder is worth nothing until checked against a known case. jal 0x3a8060 decoded correctly under a different constant in the same probe and I did not notice. 284 passing with the disc present, clippy clean.	2026-10-14 05:47:29 +02:00
ReaperOfVeriod	349b498ddd	r2 is never written in the enclosing function, and it has no callers ... The trace eca1a16 asked for. The call site 0x3a7d88 sits in the function at 0x3a7c30, 580 bytes. r2 is never written there: scanning all 580 bytes for any instruction storing into r2 finds none. So it arrives from outside the function. And 0x3a7c30 has no jal callers anywhere in level-0 .text, and is not a lvl.vtbl handler -- level 0's vtbl has 233 records and 185 distinct handlers, and neither 0x3a7c30 nor 0x3a8060 is among them. That rules out the tidy story, which was the obvious guess given r2 arrives unexplained: the vtbl dispatcher calling it with a class pointer in v0. What remains is an indirect jalr call, a dispatch table in data, or code that is never called. Not distinguished; the question for anyone continuing is whether 0x3a7c30 is a jalr target and from where. The chain is now ? -> 0x3a7c30 (no static caller) -> 0x3a8060 -> addiu r17, r18, 0xc0. Every remaining question is about control flow and register provenance, not counts, which is where this stretch's method stops working. 284 passing with the disc present, clippy clean.	2026-10-14 05:44:46 +02:00
ReaperOfVeriod	eca1a16b17	Call sites: one caller, and it does not compute base + 0xc0 ... 0x3a8060 has exactly one call site, at 0x3a7d88: 0x3a7d84 addiu r18, r2, 0x202d r18 = r2 + 0x202d 0x3a7d88 jal 0x3a8060 No 0xc0 in the eight instructions before the call, and r18 is built from a different offset. So the 0xc0 inside the callee is a field offset applied to a pointer the caller already built, not a chunk offset the caller resolved. Two readings remain: r18 is core_data, making r18+0xc0 equal &moby_classes, which fits since level 0's moby_classes.offset really is 0xc0; or 0xc0 is a member offset in an unrelated structure and the match is coincidence. Settling it needs the provenance of r2 at the call site -- real dataflow, not counting. That is where this stops. Recorded in docs/plan/level-assets.md. The previous commit's doc edit failed silently on a line-break mismatch, so this appends rather than replaces. 284 passing with the disc present, clippy clean.	2026-10-14 05:41:48 +02:00
ReaperOfVeriod	cee17c95b1	Disassembled: 0xc0 is an address offset, and the walk is 16-byte strided ... Closes the ambiguity 05d9bf6 raised. At 0x3a8060: 263200c0 addiu r17, r18, 0x00c0 r17 = r18 + 0xc0 263000d0 addiu r17, r16, 0x00d0 r17 = r16 + 0xd0 262400e0 addiu r17, r4, 0x00e0 r17 = r4 + 0xe0 3c013f80 lui r0, r1, 0x3f80 the actual float constant: 1.0f 0xc0 is an address offset, not a float constant. The float constant is in the same function and is 0x3f80, where it belongs -- so the ambiguity does not arise here, and the reading of 0xc0 as moby_classes.offset survives. The three offsets are 0xc0, 0xd0, 0xe0: sixteen bytes apart. The function walks a table of fixed-stride structures and indexes the field at offset 0xc0, which is what a class-table lookup looks like. WHAT THIS DOES NOT SETTLE That 0x3a8060 is the moby class loader. It indexes a 16-byte-stride table at offset 0xc0, which is consistent with a moby class walk, with a different structure that also lives at 0xc0, and with ordinary field access on an object handed in by the caller. The entry code sets a 64-byte frame and saves r16 through r20, and the three indexes come off three different registers -- r18, r16 and r4. So the walk is over arguments, not over a global. That is informative in itself: a loader would more plausibly be handed the chunk by its caller than re-derive core_data + 0xc0 on every call. Which also means the chunk reference is in the *caller*, and that is where the next step is. NEXT STEP, narrow and concrete: trace where r18 and r4 come from, and find the call sites of this function. If a caller does `addiu r, base, 0xc0` and passes it in, that caller is doing the chunk lookup and this function is the per-class work inside it. Worth recording how long the ambiguity took to close. It was raised one commit ago and resolved by reading twelve instructions. Five commits before that the same constant was reported as a "real shortlist", and two before that as a size artifact. Every one of those states was arithmetically correct; only this one was the right question, and it took looking at the operands rather than counting them to arrive at it. 284 passing with the disc present (23 + 19 + 64 + 156 + 22; disc binary 35.00s), clippy clean.	2026-10-14 05:40:08 +02:00
ReaperOfVeriod	05d9bf6cd7	The 72 concentrated candidates, and a float-constant ambiguity ... Looking at the 72 candidates with fewer than 16 distinct immediates, the sets are full of values that look like lui high halves: 0x3f80 is the high half of 1.0f, and 0xff40/0xff70/0xff80/0xffc0 are negative high halves. 0xc0 << 16 is 0x00c00000, a small float. So 0xc0 in these functions may be a float constant rather than a chunk offset. The neighbour control cannot tell the difference, because 0xb8 and 0xc8 are equally plausible float high halves and are rare for their own reasons. Also recorded, and explicitly not as a finding: exactly 1 of 394 candidates contains another chunk offset, and none of the 72 does. That sounds like evidence of moby-specificity and is not -- the other chunk offsets are 0x1e80 and above and are globally rare (0 to 2 functions each, measured in 3ea5ab7), so their absence here is exactly what rarity predicts. What survives is the enrichment fact from a2f8c92. What does not survive is reading 0xc0 as a chunk offset. There are now two live explanations, a moby chunk reference and a float constant, and only disassembly separates them. Cheapest test: 0x3a8060, 148 bytes, six immediates. If the lui carrying 0xc0 is paired with an ori it is a float; if it feeds an addiu computing base + 0xc0 it is the chunk. 284 passing with the disc present, clippy clean.	2026-10-14 05:36:13 +02:00
ReaperOfVeriod	a2f8c924b4	moby_classes.offset enrichment is size-independent: 13x to 72x at matched size ... Runs the control 06531fb named. It settles the question that commit left open, and the answer is that the enrichment is real. Matching on immediate-set size, against the best of the sixteen adjacent values: bucket n 0xc0 best neighbour ratio 0-15 1,082 72 0xb8:1 72.0x 16-31 713 119 0xc8:4 29.8x 32-47 291 104 0xb8:3 34.7x 48-63 119 39 0xb8:2 19.5x 64-79 59 31 0xc8:2 15.5x 80-95 25 13 0xb8:1 13.0x Enriched in every bucket, and the ratio does not decay as sets grow. That is the opposite of a pigeonhole artifact -- a volume effect would shrink the ratio in the big buckets, and it rises instead. The load-bearing row is the smallest: 72 of 1,082 functions carrying fewer than 16 distinct immediates contain 0xc0, where the best neighbour appears once. A set that small cannot produce that by count alone. What this revives. The 300 candidates with 48 or fewer distinct immediates are not noise: at matched size, neighbours hit 0.4% to 1.4% in those buckets where 0xc0 hits 35%. A function using fewer than 16 constants, one of which is 0xc0, uses that offset deliberately. Those are the shortlist. Why this took four commits to establish. 3ea5ab7 measured 394 against neighbours 1-14 and called it a shortlist. 06531fb showed the rate rises with set size and said the 394 was a list of large functions. Both were right about their own measurement and neither had the bucket-matched comparison, which is the only form that separates "the constant is special" from "big functions contain more constants". Twenty-two probes this stretch, and the thing that finally settled it was not a better measurement but adding the right comparison to a measurement taken three commits earlier. Caveat unchanged: presence of an immediate is not proof the chunk is read there. It is proof the constant is used, which is all either test asserts. 284 passing with the disc present (23 + 19 + 64 + 156 + 22; disc binary ~35s), clippy clean.	2026-10-14 05:34:42 +02:00
ReaperOfVeriod	06531fb66c	The 394 does not survive: 0xc0's rate rises with immediate-set size ... Ran the size-independent statistic db1e69c asked for, and it confirms the confound. Bucketing level-0 functions by distinct-immediate count, the rate containing 0xc0 is: 0-15 72/1082 6.7% 64-79 31/59 52.5% 16-31 119/713 16.7% 80-95 13/25 52.0% 32-47 104/291 35.7% 112-127 3/7 42.9% 48-63 39/119 32.8% 624+ 1/1 100% Monotone from 6.7% to over 50%. Pigeonhole: a function with hundreds of distinct immediates has more chances to contain any particular value. So the 394 is largely a list of large functions and '394 of 2,323' was never a shortlist. db1e69c was right; 3ea5ab7's framing was wrong and is corrected here. This does not retract the neighbour result. 0xc0 being enriched over 0xb8-0xc8, and 0xc0 being enriched in bigger functions, are separate claims and both hold. What it retracts is the inference that the 394 are candidates for anything. The control that would settle it: 0xc0's rate against a specific neighbour's rate within the same set-size bucket. Not measured, and named so the next attempt starts there rather than re-ranking by size. No test -- the bucket rates are the finding, and an assertion on any single threshold would be arbitrary.	2026-10-14 05:32:34 +02:00
ReaperOfVeriod	db1e69c0ab	Ranking the 394 by size is backwards; record the confound ... Ranking the moby_classes candidates largest-first is the wrong first cut. The top entries are 34,316 and 26,432 bytes with 631 and 421 distinct immediates, median candidate 852. A function with 631 distinct immediates is far more likely to contain any given value, 0xc0 included, than one with 80, purely by pigeonhole. Sorting by size therefore selects for the functions most likely to be false positives, and the 34,316-byte outlier is probably a mis-bounded extent -- the decomp corrects three level-00 entries -- rather than a 34 KB loader. The 394 needs a size-independent statistic: whether a function contains 0xc0 more often than its immediate count predicts, not whether it contains it at all. Not measured. Recorded as a negative about the method rather than committed as progress. No test -- there is no assertion here to make. 283 passing with the disc present, clippy clean.	2026-10-14 05:30:07 +02:00
ReaperOfVeriod	3ea5ab799f	moby_classes.offset is referenced by 394 functions; its neighbours by 1 to 14 ... First positive result of the loader hunt, and it exists only because of the control that two commits ago I said was missing. Across 2,323 level-0 functions of at least 128 bytes -- extents from the decomp's functions.tsv -- the immediate 0x00c0, which is moby_classes.offset, appears in 394 functions. Every value adjacent to it appears in 1 to 14. 0xb8:8 0xb9:2 0xba:2 0xbb:2 0xbc:3 0xbd:5 0xbe:5 0xbf:3 0xc1:3 0xc2:3 0xc3:2 0xc4:1 0xc5:2 0xc6:3 0xc7:1 0xc8:14 This is what 27891ce was asking for. 0xc0 is small and small immediates are common -- 17,699 occurrences across the program, against 200,784 for 0x0001 -- so the raw frequency was worthless. The neighbours have the same magnitude and none of the frequency, which is the only reason 394 means anything rather than being an artifact of the value being short. A second control points the other way, so the two bracket it: the other five level-0 chunk offsets are larger values and are referenced 0 to 2 times each. Shrub_classes 1, tfrag_textures 2, moby_textures 2, tie_textures 0, shrub_textures 2. The chunk offsets a loader would use are referenced about once. moby_classes is referenced 394 times. The program leans on this constant heavily. The previous commit's 410 candidates were not a shortlist. These 394 are, because the number is now separated from magnitude rather than merely stated. WHAT THIS DOES NOT SAY An immediate appearing in a function is not proof the chunk is READ there. It is proof the constant is used, which is the claim the test asserts and the only claim it makes. It does not say which of the 394 is the loader, or that the loader is among them. Stated plainly because the 394 is the kind of number that gets quoted without its caveat and then built on. Also measured, negative: zero functions contain both the moby_classes and tie_classes offsets, so nothing indexes both chunk tables by immediate. The moby loader does not reach the tie table the same way, if it reaches it at all. Boundaries: level 0 only, "level 0" meaning the function's first listed place is level 00, and a 128-byte size floor -- 59957a0 recorded 20-byte "functions" that are mis-bound extents. 283 passing with the disc present (23 + 19 + 63 + 156 + 22; disc binary 35.23s), clippy clean.	2026-10-14 05:28:34 +02:00
ReaperOfVeriod	59957a02a2	Attribute the 0xc0 immediate sites to functions: 410 candidates ... The decomp's functions.tsv makes this cheap -- 3,835 level-0 functions with start and size, so each immediate-bearing instruction is attributable to its container. 410 of 3,835 functions (10.7%) contain one; sizes 20 to 34,316, median 808. Ten per cent is what a common small immediate buys, so this confirms 56b00fb rather than narrowing anything. 410 is not a shortlist. What it does establish is that the attribution works and the decomp's extents are usable for it. The loader hunt now has a concrete next step: of those 410, the ones that also touch a class span. That is dataflow, not counting, and it is where this resumes. Caveat recorded: a 20-byte 'function' holding the immediate is a mis-bound extent whose tail happens to include another function's instruction. Sizes need a floor before the set is used. No test -- an attribution count with no assertion behind it would only make the 410 look like a finding.	2026-10-14 05:23:14 +02:00
ReaperOfVeriod	56b00fb305	Fix the immediate scan by filtering on opcode; still no signal ... Saying the previous method 'cannot tell' was right but the reason deserved a step rather than a hand-wave: it is fixable by counting immediates only where they are immediates, which needs an opcode filter and no disassembler. All 27 levels: 11,911,320 instructions, 2,985,897 carrying an immediate (addiu/lui/ori/xori/andi/sltiu), 13,813 distinct immediate values. moby_classes 0x00c0 17,699 tie_classes 0x1e80 17 And now there is a control the raw version never had -- the program's most frequent immediates are 0x0001 (200,784), 0x001b (149,259), 0x0010 (137,523), 0xffff (98,312). 0xc0 at 17,699 sits below the top of that small-value cluster rather than standing out, so it is not a distinctive reference. Result unchanged from the raw scan and now defensible: no signal. The loader is not findable by frequency, and the remaining route is structural dataflow -- functions touching both the chunk offset and a class span. No test: asserting that an offset is unremarkable is not an invariant worth locking, and the two numbers are already recorded with their denominator.	2026-10-14 05:17:47 +02:00
ReaperOfVeriod	27891ce5b4	Cross-reference scan by raw immediate: the method cannot tell ... Sought the moby class loader by counting raw u16 occurrences of each chunk offset in .text. moby_classes 0xc0 hits 49,230 times, tie_classes 0x1e80 hits 111 -- and that contrast means nothing. Small u16 values are simply common: the most frequent value in .text occurs 1,834,535 times. A two-byte value that is frequent by construction beats a rarer one regardless of what either references, so the comparison has no shared denominator. Rule 3a again, one level below where it has bitten before -- not the measurement being wrong but the comparison being uninterpretable. Recorded as a methodological negative rather than a finding. Doing it properly means counting immediates only where the instruction decoder says they are immediates, which is what tools/overlay-anchors exists for. No test added: a test asserting a meaningless comparison would make the next reader trust it.	2026-10-14 05:15:07 +02:00
ReaperOfVeriod	743107e864	moby_anim: the class table is not the loader ... Ruled out the cheap approach: moby_classes (offset 0xc0, count 238 in level 0) holds float-shaped values, and only 120 of the first 4,096 u32s land inside the overlay .text against ~259 expected by chance. Fewer than chance, so the loader is not dispatched from a pointer here. Not concluded what the 238 entries are -- the float reading is suggestive but was taken at one stride on one level.	2026-10-14 05:13:02 +02:00
ReaperOfVeriod	6d26da3630	The control fails my own claim: 0x1c/0x34 select nothing distinctive ... 2ff2abb ended by implying that the class-header offsets point at identifiable content. I said the next step would be a control. Here it is, and it fails the claim. Adjacent-equal-byte rate over 64 bytes, 1,864 classes: 0x1c 0.12688 0x34 0.12106 control 0.14109 (the same offset + 0x2000) random 0.00391 All three are ~30x above the random baseline, so the region is structured data and not noise. That part stands. But 0x1c and 0x34 are no more structured than an arbitrary offset in the same blob, and 0x34 is slightly *less*. So the hex fragments in 2ff2abb were three hand-picked examples from a structured region. "They look like compiled shader programs with small-integer parameters" said something about this part of core_data, not about what those fields address. That is exactly the rule 4 failure -- a pattern that reads as meaningful with no control to test it against -- and I wrote it anyway while explicitly declining to name a format two paragraphs earlier. RETRACTED: the suggestion that the offset targets are identifiable content. Unaffected, because it was measured differently: the offsets are base-relative, non-zero, in range on 1,864 of 1,864 classes, and always land past the class's own tie packet blocks. What they address is still unknown. The earlier finding that the packet's control region is not a tag stream also stands -- that was measured by uniformity within the packet, not by comparison to elsewhere in core_data. A TEST THAT CAUGHT ITS OWN AUTHOR The first version asserted |0x1c - control| < 0.02 symmetrically, and failed on 0x34 at a gap of 0.0200. The correct response was not to loosen the number until it went green. The claim being guarded is "these offsets select distinctive content", and a gap in the *other* direction does not support it -- both offsets came out below control. So the assertion is one-sided, and the comment says why, including that the symmetric form was the wrong shape. That is the AGENTS 3b discipline working in the direction it is meant to: a failing assertion is information about the assertion. 282 passing with the disc present (23 + 19 + 62 + 156 + 22; disc binary 35.16s), clippy clean.	2026-10-14 05:06:57 +02:00
ReaperOfVeriod	2ff2abbd32	Two class-header words are base-relative offsets pointing past the tie packets ... Chasing where the AD-GIF is, since f43a1c2 established it is not in the packet. Two of the undecoded class-header words are offsets. base + 0x1c and base + 0x34 land inside core_data on 1,864 of 1,864 classes, so both are relative to the class base rather than absolute, and both are non-zero on every class. Both also land **past** that class's own tie packet blocks on every class, so they address per-class data held elsewhere in core_data rather than the tie geometry. That is consistent with f43a1c2: if the packet's own control region is not a tag stream, the per-class draw state is referenced from somewhere else. WHAT IS THERE, AND WHAT IS NOT CLAIMED The bytes are structured, not random -- class 3 shows a fixed-stride table with `80 01 00` recurring, class 2's field is a monotone byte table, class 5's has `38 38 38` and `ff 00 ff ff`. They read like compiled shader programs with small-integer parameters, or lookup tables. **Not identified, and deliberately not named.** None of those three fragments has been run against a control, and all three were picked because they looked like something. That is precisely the finding rule 4 refuses, and having spent this session on four retractions I would rather record an honest "structured, unidentified" than a plausible format that has not earned it. If any of these turns out to be a shader program the next step is a control, not a better-looking hex dump. ALSO SETTLED 0x24 is demonstrably not an offset: only 17 of 1,864 of its values land in range for core_data. Recorded as packed data. 0x28, 0x2c, 0x38 remain high-entropy and unexplained. 281 passing with the disc present (23 + 19 + 61 + 156 + 22), clippy clean.	2026-10-14 05:03:34 +02:00
ReaperOfVeriod	f43a1c2e6e	bfc_distance is not the control region's length; the AD-GIF is not in the packet ... Follows 9bb04cc. The control region is now characterised, and the second half of the answer is a correction to a field doc that has been wrong since the record was first parsed. WHAT THE CONTROL REGION IS Per-record, not shared state. 12,294 distinct blobs across 13,042 records, mixed within 2,410 of 3,549 classes, and different between LOD 0 and LOD 1 on all 500 classes that have both. It varies per primitive. Partitioned by its own length, it is not uniform in character, and the pooled count hid that: vert_ofs 48 bytes (3 qw) 5 distinct blobs vert_ofs 64 bytes (4 qw) 3,175 vert_ofs 80 bytes (5 qw) 4,309 vert_ofs 96 bytes (6 qw) 3,281 vert_ofs 112 bytes (7 qw) 1,523 vert_ofs 128 bytes (8 qw) 1 The shortest and longest are effectively constant -- five blobs, and one -- while everything between is per-record unique. That is a shape, not a noise floor, and it is invisible unless the measurement is partitioned by length. THE CORRECTION bfc_distance == 5 * shader_count holds on every record, and the field doc has always read "quadwords of ad-gif data" -- which read as a packet-relative length would make it the control region's size. It cannot be that. bfc_distance is 5..20 quadwords; vert_ofs, the control region, is 3..8. Pooled, they overlap on 9,315 of 15,219 records -- 61%, a number describing nothing. Partitioned by shader_count, as AGENTS 3a requires, it is exact: shader_count 1: 2,772 of 8,676 exceed (32%) shader_count 2: 4,649 of 4,649 exceed (100%) shader_count 3: 1,729 of 1,729 exceed (100%) shader_count 4: 165 of 165 exceed (100%) Without exception for two or more shaders. For one shader it exceeds exactly when vert_ofs is below 5, which is that 32%. **The AD-GIF is not stored in the tie packet.** The packet is control, vertices and scissor, in that order. bfc_distance is a per-record quantity tied to the shader count whose meaning is still not established, and the "quadwords of ad-gif data" reading of it is wrong. The doc now says so and says why, rather than carrying a plausible description of a field whose meaning nobody has established. This is the fourth retraction today and the second today found by partitioning rather than by a test failing. The pooled number was not merely less precise than the partitioned ones -- it pointed the other way, because 61% looks like noise and 100% looks like a boundary. Had I accepted the pooled figure I would have written "sometimes" and moved on. 59 disc tests, 278 total across 23 + 19 + 59 + 156 + 22 with the disc present (disc binary 35.31s), clippy clean.	2026-10-14 04:57:41 +02:00
ReaperOfVeriod	9bb04cca7b	The tie control region is not a VIF or GIF tag stream; and vert_ofs is mis-named ... Went after the GS's GIF packets in the tie AD-GIF region. Got a negative result, a new universal invariant, and a retraction of my own first probe, which reached the right answer for the wrong reason twice. THE NEGATIVE RESULT Tried the leading `5 * shader_count` quadwords of each packet (the `bfc_distance` field's stated meaning) as VIF tags -- command in bits 0-6, size in 7-14, mark in 15 -- and as GIF tags -- type in the top byte of word 1, length in bits 0-2 of word 0. Both uniform. Over 13,042 records: 10,443 distinct values of word 0, no GIF tag type above a count of 2. That is the control result rule 4 asks for, and it says stop. THE RETRACTION The first probe scanned `bfc_distance` quadwords, which for most records overruns `vert_ofs` and runs into the vertex data. Pooling a control region with vertex positions -- two populations with different structure -- gives a uniform answer, so "not a tag stream" came out right from a measurement that was measuring the wrong bytes. That is exactly the rule 3a failure, and I only caught it because the hex dump I took next looked structured while the histogram said random. Re-measuring quadword 0 alone, on its own population, gives the same uniformity. The conclusion survives; the reasoning did not, and both are recorded. THE PARTITION, AND A NEW INVARIANT The hex dump showed the packet layout directly: q[0 .. vert_ofs) control 3..8 quadwords, peak at 5 q[vert_ofs .. +vert_size) vertices q[vert_ofs+vert_size ..] scissor and `scissor_ofs == vert_ofs + vert_size` holds on **15,219 of 15,219** records across all 27 levels, including every one whose strip_count is non-zero. That is a derived quantity stored explicitly, and it holds everywhere -- which is the check that confirms the three regions really are laid out the way the existing packet length formula assumed. It is now a hard check in invariants_hold(), which is something the previous four could not be. The fixture in tie.rs failed the moment I added it: it had vert_ofs 4 and vert_size 0x20 with scissor_ofs 0x30, which is 4 + 0x24. The synthetic data was never constrained by a relation that did not exist yet. Fixed to 0x24. vert_ofs IS MIS-NAMED It is not a vertex offset. It is the *length* of the leading control region, and the vertex data begins at that many quadwords into the packet. The field name stays because the on-disc order is fixed and everything already written about this record says vert_ofs, but the doc now states what the value is and gives the distribution. STILL UNKNOWN What the control region contains. Not standard DMA tags; possibly pre-merged GS register writes in another framing, or per-class state rather than per-primitive draw data. Recorded as an open question rather than guessed at. 23 + 19 + 58 + 156 + 22 = 278 passing with the disc present (disc binary 35.67s), clippy clean.	2026-10-14 04:51:43 +02:00
ReaperOfVeriod	bbd8cdccab	Phase 5 is Aranos, not Veldin -- Veldin is not on this disc ... Caught by the user, and it was wrong in four places: the Phase 5 heading, its gate, its go/no-go line, and the PCSX2 verification plan's "Level 0 (Veldin)". Veldin is Ratchet & Clank's home planet in the 2002 game. Going Commando opens on Aranos, and there is no Veldin anywhere in this disc. The error looks like it carried over from the first game when the roadmap was drafted, which is an easy slip to make and an unhelpful one to leave standing: a vertical slice defined as "completable and matching PCSX2 frame-for-frame" is not something anyone could have attempted or judged while pointing at the wrong planet. Confirmed against the vendored decomp rather than taken on faith. Its docs/LEVELS.md refers to level 00 as Aranos directly -- "corrects three measured Aranos entries before fingerprinting ... These corrections apply to level 00 only" -- so level 0 is Aranos in the reference material this project has been using all along, and the roadmap disagreed with the decomp. There is a real R&C1 reference nearby and it is worth keeping, because the reasoning under the gate is sound and only the noun was wrong. Phase 5 argues that spherical gravity is the thing most likely to break, because it invalidates the movement and camera assumptions the engine inherits from Ratchet & Clank (2002). That is about inherited code from the previous game, not about the level being built, and the text now says so explicitly so the next reader does not have to work out which game is meant. No code change. Documentation only.	2026-10-14 04:29:57 +02:00
ReaperOfVeriod	1fa1913e38	Reconcile the docs after the last three corrections ... The last three commits changed things the documentation still asserted in the old direction. Fixed: roadmap * 227 tests -> 238. * The level_overlay bullet contradicted itself: it said "the header words are not named" in the same breath as "+0x00 load base is 0x1A7C80". Now says +0x00 IS the load base and is named, +0x0c is excluded as the .lit size by sign (below file length on 16/27, by up to 8.9%) and remains unnamed, and the unnamed remainder is stated as such. * Section names aligned with the Phase 3 list (lvl.vtbl, lvl.camvtbl, lvl.sndvtbl). core-data-regions.md * The claim-assertion audit still said the two PCSX2 claims were "NOT assertable here -- needs a savestate". They are asserted now, gated on GC_SSTATE, in the same file. Updated, with the two corrections that fell out of writing them recorded right there. * "that string is inside the collision routine" was never established. It is in the string pool, yes; the reference to it is not found. Reworded to say so, including the zero-hit result. research log * field_00 now carries its name and the .lit/$gp/program context. * The field_0c falsification and the byte-order retraction are both recorded here as well, so the log and the format file agree. Nothing left asserting the withdrawn anchor, and no stale test counts.	2026-10-13 07:13:45 +02:00
ReaperOfVeriod	26a0918178	Gate the PCSX2 claims as tests; two corrections fall out of writing them ... The audit two commits ago listed three claims as "not assertable here -- needs a savestate". With PCSX2 running they are assertable, so they now are. gc-trace already exposed gc_trace::Savestate::ee_ram_owned(); gc-extract just needed it as a dev-dependency. Both tests are gated on GC_SSTATE and skip cleanly without it, so a normal checkout pays nothing. Writing them corrected two claims, which is the main reason they were worth writing as tests rather than staying prose. 1. The collision payload is NOT "byte-for-byte identical". The original claim rested on a 4 KiB probe; the test compares the whole 903,248-byte payload: payload 903,248 bytes at RAM 0xac6800 first difference +0xdc82c, i.e. 903,212 bytes in bytes that differ 6 (0.00%) 903,212 of 903,248 bytes are verbatim and 6 are not, all in the final 36. "Verbatim" was an overclaim on a probe that never looked at the tail. The test now measures the whole payload and reports the extent, asserting only that the divergence is beyond the head. 2. The tfrag relocation base is the TABLE address, not the block base. The delta is 8,683,584 = 0x848040 = block base 0x848000 plus table_offset 0x40 -- which is exactly what TfragHeader::data's own documentation says, "relative to the table". The earlier claim said "the block's RAM base", off by exactly the table offset. Also: +0x10 and +0x38 do NOT share one constant. The aggregate "1,665 fields relocate by one constant" was true only because +0x10 carried it; lumping them hid that. The test asserts +0x10 and REPORTS +0x38's delta rather than assuming. The patch-rewrite figures also restated on aggregate rather than median, which is why they read lower than the 7.80%/8.12% medians recorded earlier: patch bytes rewritten -- cannot morph 1.9% of 334, can morph 2.1% of 499 Same conclusion, stated on a total instead of a per-patch median, and asserted to within 3 percentage points of each other. Net: the audit table in docs/formats/core-data-regions.md now has no "prose only" rows for disc-or-savestate-readable claims.	2026-10-13 06:59:22 +02:00
ReaperOfVeriod	3ee0b3d0dc	Disprove that morphing causes the tfrag byte changes: LOD selection does ... Read the whole tfrags block from RAM -- 4,379,200 bytes at 0x848000 -- and compared every one of the 833 patches against its disc copy, grouped by whether it CAN morph: patches with NO morphing entries 334 differing: max 10.59%, median 7.80% patches WITH morphing entries 499 differing: max 10.49%, median 8.12% patches 100% identical to disc 0/334 and 0/499 The two groups are indistinguishable. Morphing is NOT what changes the bytes, and this disproofs the claim two commits ago that the 8.6% was "morphed positions with topology and UVs left verbatim". If it were, the 334 patches with no morphing entries would be untouched -- and none of them is. Nor is it a pointer relocation: the differing bytes fall in short structured runs (257-263, 272-277, 305 on patch 0) whose u32 deltas share no common value. The explanation consistent with everything measured is that the loader REGENERATES each patch's VU packet stream for the LOD tier it selected. That happens to every patch, morphing or not -- and it is why morphing shows no signal. This also settles the verification route, which the previous commit left as "needs the camera distance at the savestate". It does not, and no camera distance would help: this memory image shows the LOD-selected form rather than the morph state, so there is nothing in it to solve a weight against. Verifying the derivation needs a captured frame at a known view distance instead. What is established now, all measured on the full population rather than inferred from one patch: - data and cube_ofs are relocated pointers, delta 0x848000, on all 833 records - every patch's bytes are rewritten, ~8%, by LOD-driven packet regeneration - morphing is not observable in this memory image - 833 of 833 patches parse; 499 of 833 have morphing entries; 43,613 vertex-info entries across the level	2026-10-13 05:14:40 +02:00
ReaperOfVeriod	aff977e8c5	Correct the tfrag pointer-field claim, and show morphing regenerates VU packets ... Two corrections to the previous commit, both from continuing the RAM comparison. 1. The previous commit said the RAM comparison "names two fields the disc-side work had left as data and an unnamed word". It does not. +0x10 is TfragHeader::data and +0x38 is TfragHeader::cube_ofs, both already named in the struct. What RAM adds is that both are POINTERS -- relocated by adding the block's RAM base -- rather than plain offsets. That is still worth knowing, but it is not a naming. 2. The previous commit attributed the 8.6% of rewritten bytes to "morphed positions with topology and UVs left verbatim". That is wrong, and patch 1 shows why. Comparing 4 KiB, disc 0xdf60 against RAM 0x855f60: bytes differing 354 of 4,096 = 8.6% contiguous runs 120 longest run 8 bytes extent +0xc1 through the end of the window Patch 1 has 83 positions and 83 vertex-info entries, of which 13 morph. If morphing rewrote position fields alone, the differing bytes would be a 13/83 slice of a 498-byte position array -- a couple of dozen bytes in one contiguous region. Instead 354 bytes differ, spread over 120 short runs across the whole window. So the loader is not patching positions in place: it REGENERATES the VU packet stream for the current morph state. That is what morphing is on this hardware -- VU1 GIF packets, not a CPU-side vertex array. Consequence for verification, and the reason this is worth committing rather than just noting: the plan of "map RAM vertices to disc indices and solve for the weight" does not work against this memory image. The positions are inside regenerated packets, so there is no stable per-vertex correspondence to read a weight out of. Verifying the morph weight against the original needs the CAMERA DISTANCE at the savestate, so the weight can be computed from the derivation and compared with the rendered result, rather than read back out of RAM. Population figures gathered on the way: 833 of 833 patches parse, carrying 43,613 vertex-info entries; 499 of 833 patches have at least one morphing entry, and patch 0 -- the first record -- is base-only with none. Also fixed a measurement error mid-run: I compared patch 1 at disc 0xdf60 against RAM 0x855f00, off by 0x60, and got "every byte differs". The corrected base is 0x855f60.	2026-10-13 05:08:08 +02:00
ReaperOfVeriod	93591a79de	Verify the tfrag record framing against RAM: two pointer fields, morphed vertices ... The tfrags block header -- table_offset 0x40, tfrag_count 833, lod_distance 32.0 -- hits once in the level-0 savestate at RAM 0x848000, so disc offset 0 maps to RAM 0x848000 and the block can be compared position for position. Result 1: exactly two fields per record are rewritten. Comparing all 833 64-byte table records field by field: records compared 833 u32 fields differing 1,665 = 833 x 2, and no others their offsets +0x10 and +0x38, on every record relocation delta 8,683,584 = 0x848000, on 833 of them So +0x10 and +0x38 are block-relative pointers and the loader adds the block's RAM base to each. Every other byte of all 833 records is verbatim. Six fields differ by 0xF80000 and 0x1F00000 instead -- three records pointing into a different buffer, recorded rather than averaged. This names two fields the disc-side work had left as `data` and an unnamed word. Result 2: behind the pointers, about 8.6% of bytes are rewritten. Following record 0's +0x10 to disc 0xd040 / RAM 0x855040 and comparing 16 KiB: 14,977 bytes identical, 1,407 differ = 8.6%. The differences spread across many field positions rather than concentrating, which is what morphed POSITIONS look like -- topology, UVs, counts and command lists stay verbatim while a fraction of the position bytes move. 8.6% is about half of a 16-byte vertex's six position bytes, consistent with roughly half the vertices in this patch mid-morph at the saved camera distance. Not established: that the morphed bytes match resolve_vertex's formula. That needs mapping RAM vertices to disc vertex indices and solving for the weight, which is the next step -- but the framing is now known well enough to attempt it, and the two pointer fields are confirmed rather than inferred. This also answers the "is morphing real?" question that made the earlier tfrags probe fail to match RAM: the tfrags block is not verbatim in RAM, because both its table pointers are relocated and its vertex positions are morphed.	2026-10-13 05:04:25 +02:00
ReaperOfVeriod	d5e637930b	Show the collision payload is verbatim in RAM, and retract the "not in RAM" claim ... This overturns the premise collision work was blocked on. Searching the level-0 savestate for a probe from collision payload +1024 hits at 0xac6c00; a probe from +64 hits at 0xac6840. The difference is 0x3C0 = 960, which is exactly 1024 - 64, so the payload sits at a fixed relative address -- RAM 0xac6800 for the disc address 0x27e800 -- and reading it back is byte-for-byte the disc's own bytes: RAM 0xac6800 0b 00 21 00 b6 08 ad 08 a4 08 6b 08 38 08 63 07 disc 0x27e800 0b 00 21 00 b6 08 ad 08 a4 08 6b 08 38 08 63 07 Nothing is reshaped. That is the opposite of the tie block, where the loader relocates a pointer inside each record. The retraction. The previous note reads: "level 1's 24 x 16 grid dimensions appear in memory, level 0's 11 x 33 appear nowhere, so disc-side decoding has to work against the reshaped form." Level 0's dimensions ARE in RAM, at 0xac6800 -- 0b 00 and 21 00 are the first two bytes of the block, 11 and 33. The search that missed them looked for 0b 00 00 00 21 00 00 00, the dimensions as a pair of u32s. They are stored as two u16s, so that pattern never occurs. So the negative result was an artifact of the search pattern, not evidence about the data -- and it was then used as a premise for several rounds of disc-side work. Both lessons were already written down in AGENTS.md and both were re-learned: a negative from a byte search bounds the search, not the format; and the control here is one command -- read the predicted RAM address and compare it to the disc -- which would have shown the verbatim copy immediately. Also recorded while mapping it: the payload contains ascending u32 offset tables from +1024 onward, and its first two bytes are the grid dimensions, so level 0's grid is 11 x 33. The cell layout itself is still undecoded, but the blocker is gone: disc-side decoding no longer has to work against a reshaped form.	2026-10-13 04:40:01 +02:00
ReaperOfVeriod	4e90c282ad	Make the tie record relocation a command, and verify it on two levels ... The relocation rule from the previous commit was established by a script that lived in a shell history, which means the next person would have had to rediscover it. It is now `gc-trace verify-tie-records <unpacked-dir> <level> <class> <lod> <src>`: resolve the class, parse the block, search the RAM image for the loaded record table, report what it found, and exit 0 only when every record's pointer has become table + word and every field byte is verbatim. Swept over every (class, lod) slot of two levels, from PCSX2 savestates: level 0: 87 slots with a block, 87 verified, 0 mismatched, 61 absent level 1: 104 slots with a block, 104 verified, 0 mismatched, 78 absent So the rule holds on every LOD block of two levels the game had loaded, which is what makes the record layout a finding rather than a reading of one block. Writing the command also caught an off-by-one in the parser it exercises: TieBlockHeader::records started its slice after the 16-byte header, but the header IS the first record -- the table runs from the block start to data_offset, and a block with data_offset 0x50 holds five records, the first being the header itself and its pointer naming where the payload begins. Found because the tool's first run relocated nothing while the same check in a script had passed; the unit test fixture was wrong in the same way and is fixed. Two operational notes now in the format doc: the live emulator is not a stable input (verifying level 1 over PINE matched 104 of 104 while the user was on that planet, and the same command minutes later found no matching copy because they had returned to level 0 -- a miss there is not a counterexample, so the report says "no copy matched" rather than "failed"), and a class index past the table count is an error rather than a mismatch, so a sweep should stop at the level's class count rather than a round number.	2026-10-12 15:24:48 +02:00
ReaperOfVeriod	2c4bbdc600	Use PCSX2 RAM to recover the chunk loader's transformation ... This is what RAM was needed for: nothing about the loader's transformation is recoverable from the disc. Anchor: a 32-byte probe from inside a chunk record in level 0's core_data, searched in the level-0 savestate. It hits at 0x18538a8 and the record's first bytes at 0x185387e -- exactly chunk_base + record_offset, no rescaling. So the chunk payload is copied VERBATIM; unlike collision and the shrub packet tables it is not expanded or repacked. Result 1: the offset table is rewritten to absolute EE addresses. disc: f000057c f00006b0 f00007e4 f0000914 RAM: 0xf185387c 0xf18539b0 0xf1853ae4 0xf1853c14 The 0xf0000000|low24 tag becomes 0xf1850000|low24 -- tag replaced by the chunk's load base, low 24 bits untouched. Consecutive deltas agree exactly (0x134, 0x134, 0x130), which is why the disc-side stride is approximate rather than constant. Result 2: every record gains a constant 2-byte prefix 02 00, and the rewritten table points at THAT rather than at the record data. Walking all 90 records from the RAM dump: prefix 02 00 on 90 of 90; the disc's index bytes preserved unchanged at +2/+3 on 90 of 90. Result 3, the useful one: the byte at +2 takes exactly 0, 16, 32, ... 240 -- the 16 values index_rule predicts for step = 16, phase = 0. The mixed-radix record index derived from the disc is corroborated on the running game's own copy of the chunk. That is a disc-derived claim validated against the game, which is the strongest form of check available here. On disc a chunk is [16-byte header][10 zero bytes][tagged offset table][records]. In RAM it is [16-byte header][10 zero bytes][absolute-pointer table][records each prefixed with 02 00]. The 02 00 is unexplained -- possibly a record type or an alignment the loader needs -- but it is constant, so like the two index bytes it carries no per-record information.	2026-10-12 04:32:07 +02:00
ReaperOfVeriod	d8b8ccc6d4	Follow the gameplay.bin pointers: they address position and direction arrays ... Where the pointers go. Following them shows what gameplay.bin indexes. The leading table is 39 words, all of which land inside the file, and three clusters dominate: near 150000, near 800000 and near 1050000. The region near 797808 is position data -- 31 consecutive plausible floats that group cleanly into xyz triples: 246.948 201.015 73.867 | 88.240 186.000 302.598 | 107.712 12.723 183.125 353.591 126.365 19.962 | 182.068 374.001 122.567 | 116.961 265.001 437.866 and the region near 797456 is direction data -- unit-length vectors: 0.969 0.945 0.733 | -0.120 0.433 0.250 | -0.866 0.000 0.267 So the file's leading words are a table of pointers into float arrays, not a flat list of small integers. The earlier reading of it as "u32 pointers holding nothing" was too quick: it is a pointer table into data that is present. Volumes remain unlocated. The position arrays are the right shape to bound a volume and nothing yet shows the volume records themselves.	2026-10-12 03:36:55 +02:00
ReaperOfVeriod	b17ec17127	Rule out the moby_anim instance-table reading of the chunk types ... moby_anim was the one post-shrub chunk type with a concrete reason to exist: an instance table would have to scale with the level's moby class count, so comparing per-type record counts against that count was the obvious test. It fails, and the way it fails is itself the result: per-type record counts are level-independent. The same types report the same counts on every level tried: type_id level0 level1 level2 level3 0x007d7ec438 90 90 90 90 0x00d3d8c4a9 90 90 90 90 0x00429ec43d 77 77 77 77 0x0053c8c4aa 77 77 77 77 0x007626c4a4 50 50 50 50 0x00fb88c462 47 47 47 47 Across all 27 levels there are 77 distinct chunk types, the largest at 2430 records total -- exactly 90 x 27. What that rules out: nothing in this chunk set is a per-moby-class instance table, because those counts would vary by level the way the moby class counts do. So whatever holds moby animation data is either keyed by something other than the class count, or it is not among these chunk types. Also visible: the types pair up. 0x007d7ec438 and 0x00d3d8c4a9 both report 90 on every level; 0x00429ec43d and 0x0053c8c4aa both report 77. Two chunk types carrying identical, constant record counts on every level is a signature of two views of the same fixed table rather than two independent tables that happen to agree. Still open: the pairings are described but not explained, and no type has been named. The Moby class-ID enrichment from earlier stands separately -- 9493 hits against 246.1 expected is real, and the class arrays are contiguous per type, but that identifies where classes are referenced, not which chunk is moby_anim.	2026-10-12 03:33:52 +02:00
ReaperOfVeriod	02ced5ee83	Parse the per-level overlay: header, constant block, level data ... level_overlay was the least-characterised file in the level set -- no parser, no located structure. It now has gc_formats::overlay and a real-disc test over all 27 levels: overlay: 27 levels; field_00 1735808, field_08 1; field_04 37540..=45308, field_0c 2763912..=3027336 (17 below the file length, 10 above); +0x10..0x1220 identical on all The header is four words. +0x0c is not the file length: it was recorded as one on the strength of the first levels measured, where it sat near the file end, but across all 27 it falls on both sides -- below on 17, above on 10 -- so it is an ordinary level-specific word. The test asserts this, being the claim most worth pinning. The common prefix is 4 bytes, not the whole header: +0x00 is constant at 1735808 while +0x04 and +0x0c vary. Everything from +0x10 to +0x1220 -- 4624 bytes -- is byte-identical on all 27 levels. Still not named: what any of the four header words means, and how the level-specific tail is structured. The module reports them as fields. Also records in docs/plan/pcsx2-verification.md that the 64-byte RAM stride from the previous commit is disproved. A 415 KB dump of level 1 finds the longest such run at 27 records, not 384, and those are identity matrices -- 27 of them, one per level. It is a per-level transform table, not the collision grid, and the 20.0 reported there was a coincidence.	2026-10-12 03:32:02 +02:00
ReaperOfVeriod	bd012efe71	Find a 64-byte collision record stride in RAM, and record a savestate search pitfall ... Searching the savestates for the collision grid dimensions as a u32 pair -- level 0's 11 x 33 and level 1's 24 x 16 -- puts level 1's at several RAM addresses and level 0's nowhere. So the grid dimensions are not held in RAM as adjacent u32s, and the collision payload is reshaped on load, as the shrub packet tables are. A nearby region of level 1's RAM does show structure. At 0x12e048c and 0x12e04cc, 64 bytes apart: 28 01 00 00 | 92 ff 00 00 | 04 00 a0 41 | ... 296 -110 20.0f Searching for that shared 12-byte tag finds a consecutive run at a 64-byte stride in slot 2: 0x12df390 0x12df3d0 +0x40 0x12df410 +0x40 plus scattered singles elsewhere. Slot 1 has the tag at four addresses not on a 64-byte stride, so the two levels lay it out differently. What this is: a 64-byte record carrying two small signed values and a float reading exactly 20.0 -- the shape of a per-cell entry with coordinates and a radius or half-extent, which is what the collision grid would hold. What this is not: it is not decoded. Three consecutive records is not enough to establish a stride, the tag matches only a few records rather than a whole grid, and 20.0 may be coincidence. Level 1's grid is 384 cells; nothing here has been shown to count to 384. Method note: savestates are compressed on disk, so a byte scan of the file finds nothing. All RAM search must go through gc-trace find --state, which decompresses first -- scanning the file directly reports zero hits for a sequence that demonstrably exists in memory.	2026-10-12 03:27:14 +02:00
ReaperOfVeriod	d3e1475f64	Characterise gameplay.bin as a flat pointer table, and record volumes as unlocated ... Range measured: the first 40 u32 and the whole file, on levels 0 and 1 -- 1872256 and 2006400 bytes. Result: the file is a flat array of u32, opening with a small count then a run of ascending offsets, terminating on a zero: level 0 336 797472 798832 799136 464 150672 150688 314800 479920 ... ... 1847600 1845456 797808 1829056 160 1849088 1249808 1847616 0 level 1 496 799904 800128 800432 624 151152 151168 315680 481456 ... ... 1984496 1982400 800112 1966000 160 1988160 1303456 1984512 0 Both levels carry the same shape. The sentinel 160 appears at u32 index 34 on both and the zero terminator at index 38 on both, with counts 336 against 496 and 464 against 624 at the head. The leading ~38 words are a structured header whose layout is level-independent apart from its sizes. The offsets cluster into groups -- near 800000, 150000, 1050000, 1800000 -- which is what a table of pointers into several buffers looks like. Not decoded: what the pointers point into, what 160 is, and why the zero terminator sits at the same index on both levels. No gc_formats module exists for this yet; it is characterised, not parsed. On volumes: nothing resembling volumes was found here. gameplay.bin is u32 pointers throughout and holds no float data in its first 64 words read as f32 -- 59 of 64 are denormals, i.e. small integers reinterpreted. Volumes remain unlocated on the disc; nothing in the regions examined so far presents itself as one.	2026-10-12 03:19:03 +02:00