From 3fa64b70035a505770064ab184e50fbf68c84a33 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Mon, 12 Oct 2026 02:28:07 +0200 Subject: [PATCH] Read a full sub-list payload: tagged blocks and a byte permutation table With the extent known from the previous entry (count * 16), a whole sub-list payload can be read. This is the packet at 0x009376f0, count 22, 352 bytes. Range measured: savestate slot 1, 0x009376f0..0x0093784f. The payload is a sequence of blocks, each opening 00 00 00 30, carrying a repeating word and a short trailer: 00 00 00 30 | cd 00 00 00 cd 00 00 00 cd 00 00 00 cd 00 00 00 01 00 00 05 | 22 c1 01 6e | 00 00 00 00 00 00 00 30 | 00 00 00 45 00 00 00 45 1d 00 00 00 1d 00 00 00 1f 81 01 6d 00 | 00 00 00 00 | 00 00 a4 00 00 00 00 30 | bc c0 03 00 23 17 03 00 e5 dd 00 00 00 00 00 00 02 01 00 01 | c1 80 01 69 | 00 00 00 00 The repeating word differs per block (0xcd, 0x45, 0x03) and the trailer's second word varies in its high bytes (22 c1 01 6e, 81 01 6d 00, c1 80 01 69). Every block ends 6e, 69 or 6d at byte 23 -- the same 6e the 02 01 00 01 records carried at bytes 8-9. The payload contains a byte permutation table at 0x009377c4: 00 01 02 03 3e 3f 53 54 40 41 42 43 4e 4f 50 51 04 05 06 07 08 ... Ascending byte values with a handful (3e 3f, 53 54, 40 41 42 43, 4e 4f 50 51) lifted out of order ahead of the sequential run. Read as a table it maps each of 0x00..0x39 to a slot -- the shape of a code-length or symbol-ordering table, and the first thing in this format that is self-evidently a table rather than data to be interpreted. Not said: whether it is a Huffman-style code, an index reorder for the vertex data that follows, or a palette permutation. The sequence continues to 39 then 23 c1 01 6e, after which the next block opens. Corroboration: the fixed-point payload 0x00937850 begins exactly where this one ends. The 22-record identity made the boundary exact and the next packet starts on a payload boundary with nothing in between, so the two payload kinds sit adjacent in RAM -- consistent with them being two records of the same blob. --- 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 71d9608..d5a6945 100644 --- a/docs/plan/pcsx2-verification.md +++ b/docs/plan/pcsx2-verification.md @@ -455,3 +455,48 @@ open half. Still open: why the fixed-point packets do not follow the same rule, and what the 16 bytes per sub-list record are -- the repeated word (`0xcd`, `0xc0`, `0xc8`, `0x78`) differs per packet, so the records are not identical. + +## Inside a sub-list payload: tagged blocks and a byte permutation table + +With the extent known (`count * 16`), a whole sub-list payload can be read. +This is the packet at `0x009376f0`, count 22, 352 bytes, in full. + +**Range measured:** savestate slot 1, `0x009376f0`..`0x0093784f`, 352 bytes. + +**Result: the payload is a sequence of blocks, each opening `00 00 00 30`,** +carrying a repeating word and then a short trailer: + + 00 00 00 30 | cd 00 00 00 cd 00 00 00 cd 00 00 00 cd 00 00 00 + 01 00 00 05 | 22 c1 01 6e | 00 00 00 00 + 00 00 00 30 | 00 00 00 45 00 00 00 45 1d 00 00 00 1d 00 00 00 1f + 81 01 6d 00 | 00 00 00 00 | 00 00 a4 00 + 00 00 00 30 | bc c0 03 00 23 17 03 00 e5 dd 00 00 00 00 00 00 + 02 01 00 01 | c1 80 01 69 | 00 00 00 00 + +The repeating word differs per block -- `0xcd`, `0x45`, `0x03` -- and the +trailer's second word varies in its high bytes: `22 c1 01 6e`, `81 01 6d 00`, +`c1 80 01 69`. Every block seen ends `... 6e` or `69` or `6d` at byte 23, which +is the same `6e` the `02 01 00 01` records carried at bytes 8-9. + +**The payload contains a byte permutation table.** At `0x009377c4`: + + 00 01 02 03 3e 3f 53 54 40 41 42 43 4e 4f 50 51 04 05 06 07 08 ... + +This is not a position or vertex list -- it is a run of ascending byte values +with a handful (`3e 3f`, `53 54`, `40 41 42 43`, `4e 4f 50 51`) lifted out of +order ahead of the sequential run. Read as a table, it maps each of the 0..0x39 +symbols to a slot. That is the shape of a **code-length or symbol-ordering +table**, and it is the first thing in this format that is self-evidently a table +rather than data to be interpreted. + +**What this does not say.** Whether the table is a Huffman-style code, an index +reorder for the vertex data that follows, or a palette permutation. The +following bytes continue the sequence to `39` and then `23 c1 01 6e`, after +which the next block opens. + +**Corroboration worth noting.** The fixed-point payload `0x00937850` begins +immediately after this one ends at `0x00937850` exactly -- the 22-record +identity from the previous entry made the boundary exact, and the next packet +starts on a payload boundary with nothing in between. The two payload kinds sit +adjacent in RAM, which is consistent with them being two records of the same +blob rather than two unrelated objects.