From bbce492c915e93af47c3e7dc0fd0170871a1cd06 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Mon, 12 Oct 2026 02:37:55 +0200 Subject: [PATCH] Establish that the loader produces the RAM packet forms, not the disc Everything previously reported about five-block sub-lists and fixed-point payloads was read out of the running game. Checking the same packets on disc settles what the disc actually stores. Range measured: level 0, all 29 packets named by the +0x40 tables of the 6 bounded spans, read at their span-relative offsets; 1636 whole 16-byte records after the 16-byte header. Neither RAM form exists on disc: disc RAM 00 00 00 30 per exactly 1 exactly 5 sub-list packet blocks at 0/32/64 0 of 10 11 of 11 fixed-point byte3 0 of 19 100% == 0x80 The 29 packets split 10 sub-list / 19 fixed-point by whether they contain 00 00 00 30 at all, and not one of the ten has the block structure, and not one of the nineteen has the fixed-point marker. The disc body is a compact 16-byte record stream: +000: 04 04 00 01 | 00 00 00 00 | 00 00 00 05 | 00 80 0e 6c +010: 02 00 00 00 | 05 00 00 00 | 32 00 00 00 | 0e 00 00 00 +020: 09 00 00 00 | 00 40 3e 30 | 12 04 00 00 | 05 00 00 00 +030: 09 00 00 00 | 00 40 3e 30 | 12 04 00 00 | 21 00 00 00 Small u32 fields and a repeating 00 40 3e 30 12 04 00 00. Per position over all 1636 records the same two outliers hold: byte 7 takes 4 distinct values and byte 15 takes 2, against 101 to 153 everywhere else. Byte 7 is per-record, not per-packet: the first record of all 29 packets has byte 7 = 0x00. The four-value vocabulary varies within a packet body rather than tagging the packet, which is why grouping packets by it never separated the two kinds. Consequence for Phase 2: the payload is encoded on disc and expanded at load, so a disc parser can bound it and check its signature but cannot read it as either RAM form. Decoding it means reversing the expansion, not re-describing what the loader produced. That is the honest boundary of what is known. --- docs/plan/pcsx2-verification.md | 45 +++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/docs/plan/pcsx2-verification.md b/docs/plan/pcsx2-verification.md index 1724a6e..e10d38a 100644 --- a/docs/plan/pcsx2-verification.md +++ b/docs/plan/pcsx2-verification.md @@ -626,3 +626,48 @@ which is consistent with vertex positions relative to a per-payload origin. decodes to vertices -- the payload entropy is far below random, so it is compressed or permuted rather than stored plainly, and the permutation table seen once in `0x009376f0` remains unexplained. + +## The loader produces the RAM forms: the disc payload is neither of them + +Everything above about five-block sub-lists and fixed-point payloads was read +out of the running game. Checking the same packets on disc settles what the +disc actually stores. + +**Range measured:** level 0, all 29 packets named by the `+0x40` tables of the 6 +bounded spans, read at their span-relative offsets; 1,636 whole 16-byte records +after the 16-byte header. + +**Result: neither RAM form exists on disc.** + +| | disc | RAM | +|---|---|---| +| `00 00 00 30` per sub-list packet | **exactly 1** | exactly 5 | +| sub-list blocks at 0, 32, 64 | **0 of 10** | 11 of 11 | +| fixed-point byte 3 == `0x80` | **0 of 19** | 100% | + +The 29 packets split 10 sub-list / 19 fixed-point by whether they contain +`00 00 00 30` at all, and not one of the ten has the block structure, and not +one of the nineteen has the fixed-point marker. + +**What the disc body actually is.** A compact 16-byte record stream: + + +000: 04 04 00 01 | 00 00 00 00 | 00 00 00 05 | 00 80 0e 6c + +010: 02 00 00 00 | 05 00 00 00 | 32 00 00 00 | 0e 00 00 00 + +020: 09 00 00 00 | 00 40 3e 30 | 12 04 00 00 | 05 00 00 00 + +030: 09 00 00 00 | 00 40 3e 30 | 12 04 00 00 | 21 00 00 00 + +Small `u32` fields and a repeating `00 40 3e 30 12 04 00 00`. Per position over +all 1,636 records the same two outliers hold as on the earlier disc pass: byte 7 +takes 4 distinct values and byte 15 takes 2, against 101 to 153 for every other +position. + +**And byte 7 is per-record, not per-packet.** The first record of all 29 +packets has byte 7 = `0x00`. So the four-value vocabulary is a field that varies +within a packet body, not a tag on the packet -- which is why grouping packets +by it never separated the two kinds. + +**Consequence for Phase 2.** The packet payload is encoded on disc and expanded +at load, so the disc parser can bound it and check its signature but cannot read +it as either RAM form. Decoding it means reversing the expansion, not +re-describing what the loader produced. That is a larger job than the framing +work so far, and it is the honest boundary of what is currently known.