ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Reconcile the docs after the last three corrections

Browse Source 
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.
This commit is contained in:
ReaperOfVeriod
2026-10-13 07:13:45 +02:00
parent 282e633a7c
commit 1fa1913e38
3 changed files with 54 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/formats/core-data-regions.md
+25 -14
View File
@@ -1707,11 +1707,14 @@ than on a sample.
### What would actually unblock this
`overlay.bin` **is the game's own code**, and the collision parser is in it --
`Camera_CollPrimTest WARNING! - grid out of bounds! (RAR)` was located in the
debug string pool earlier, and that string is inside the collision routine. The
format is therefore recoverable, but not by measuring bytes: it needs either
disassembly of that routine or a reference for R&C2's collision cell record.
`overlay.bin` **is the game's own code** -- it is the level's `.lit` section,
loaded at `0x1A7C80` -- and the collision debug string
`Camera_CollPrimTest WARNING! - grid out of bounds! (RAR)` is in its string pool.
So the parser is reachable. What is *not* established is the reference to it: a
`$gp`-relative search for the string returns **zero** instruction-aligned hits,
so the code addresses that string by some other means. The format is therefore
recoverable, but not by measuring bytes: it needs disassembly of that routine or
a reference for R&C2's collision cell record.
Stating this plainly is worth more than another scan. The disc-side measurement
space for collision is now genuinely exhausted -- the bytes are available, they
@@ -1824,17 +1827,25 @@ likely to be lost. Audit against `crates/gc-extract/tests/disc.rs`:
start_16_byte_aligned
moby class IDs in one body slot per type moby_class_ids_sit_in_one_slot_
per_chunk_type
collision payload verbatim in RAM NOT assertable here -- needs a
savestate, so it lives in
plan/pcsx2-verification.md
tfrag patch bytes all rewritten by LOD same -- savestate-dependent
morphing is unobservable in that image same -- savestate-dependent
collision payload essentially verbatim collision_payload_is_verbatim_
in_ram (GC_SSTATE-gated)
tfrag pointers relocate, patches rewrite tfrag_table_pointers_relocate_
and_every_patch_is_rewritten
(GC_SSTATE-gated)
The last two used to be marked "not assertable here -- needs a savestate". They
are asserted now, in the same file, gated on `GC_SSTATE` so a checkout without
PCSX2 skips them. Writing them as tests is what corrected two claims: the
collision payload is 903,212 of 903,248 bytes identical rather than wholly
verbatim, and the tfrag relocation base is the *table* address `0x848040`, not
the block base.
The split is deliberate: anything readable from the disc is asserted against the
disc, and anything that needs a running PCSX2 is documented in the plan file with
its method. What is *not* acceptable is a disc-readable claim living only in
prose, which is how the tie `i16[3]` finding spent two commits before it had a
test.
disc; anything that needs a running PCSX2 is asserted against a savestate when
one is available, and documented in the plan file with its method when it is not.
What is *not* acceptable is a claim living only in prose -- which is how the tie
`i16[3]` finding spent two commits before it had a test, and how the collision
"verbatim" claim survived long enough to be wrong.
## An external decompilation project is the same disc, and names the overlay
docs/plan/level-assets.md
+20 -1
View File
@@ -1693,11 +1693,30 @@ as one.
splits out the constant block and the level-specific tail, and a real-disc test
covers all 27 levels:
overlay: 27 levels; field_00 1735808, field_08 1;
overlay: 27 levels; field_00 1735808 = 0x1A7C80, field_08 1;
field_04 37540..=45308, field_0c 2763912..=3027336
(17 below the file length, 10 above);
+0x10..0x1220 identical on all
Later, from OpenRAC/rac2-gc-decomp (same disc, SHA-256 verified identical):
field_00 IS the .lit load base -- 0x1A7C80, constant on all 27 levels
because every level's literal section loads at the same address.
overlay.bin IS that section: it holds code and the string pool.
$gp 0x1A7C80 + section offset is computed against $gp = 0x1AEFF0.
program seven sections: .lit .bss .data lvl.vtbl lvl.camvtbl
lvl.sndvtbl .text
field_0c tested as the .lit size and FAILED: it is smaller than the file on 16 of
27 levels, by up to 8.9% (level11 file 3,151,128 vs field_0c 2,870,792). Excluded
by sign, not by a near miss. Still unnamed.
The collision assert string was then used as an anchor and the first attempt was
WRONG -- a byte-order bug, recorded in core-data-regions.md. The PS2's MIPS is
little-endian, so an I-type immediate is word bytes 0 and 1; searching bytes 1..3
matches opcode/$rs instead and manufactured a single convincing "hit". Corrected,
the count is zero. The anchor is NOT established.
**`+0x0c` is not the file length.** It was recorded as one on the strength of the
first levels measured, where it sat close to the file end. Across all 27 it falls
on **both sides** -- below on 17, above on 10 -- so it is an ordinary
docs/roadmap.md
+9 -6
View File
@@ -25,7 +25,7 @@ early, while they are still cheap to retire.
`core_index` class tables, `tfrag` (format, topology, textures, LOD,
normals, colour), `occlusion`, `sky`, `moby`, `collision` framing and
header, `shrub` (blob, packets, palette, billboard), the post-shrub
`chunks` container, `sound_bank` framing and `level_overlay`. 227 tests
`chunks` container, `sound_bank` framing and `level_overlay`. 238 tests
green against the real disc. **What is open is naming, not locating** --
see the Phase 2 list for the four types that still have no decoded
fields: `tie` vertices, collision cells, `SBlk` records, `volumes` and
@@ -399,11 +399,14 @@ Phase 1 hands over the extents; this phase works out what each one contains.
length, falling below it on 17 levels and above on 10. The debug string
pool it opens with carries `Camera_CollPrimTest WARNING! - grid out of
bounds! (RAR)`, independent support for reading the collision payload's
two leading `u16`s as grid dimensions. **The header words are not named
and the level-specific tail is not structured yet**; the Phase 3
seven-section parser and relocation are untouched. The seven sections are
now named (`.lit .bss .data vtbl camvtbl sndvtbl .text`) and `overlay.bin`
is the `.lit` section, whose `+0x00` load base is `0x1A7C80`.
two leading `u16`s as grid dimensions. `+0x00` **is** the load base of
the section this file is, `0x1A7C80`, constant on all 27 levels because
every level's `.lit` loads there. `+0x0c` is **not** the `.lit` size -- it
falls *below* the file length on 16 of 27 levels, by up to 8.9%, so it is
excluded by sign -- and it is still unnamed. **The remaining header words
are unnamed and the level-specific tail is not structured yet**; the
Phase 3 seven-section parser and relocation are untouched, though the
seven sections are now named (`lvl.vtbl`, `lvl.camvtbl`, `lvl.sndvtbl`).
- [x] **The post-shrub chunk container.** A 16-byte header, a 10-byte zero gap,
then offsets tagged `0xF0000000 | low24` resolving to `chunk_start + low`;
header byte 14 is the record count, equal to `offsets.len()` on 1,123 of