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

Establish the sub-list payload as a fixed five-block shape

Browse Source 
All eight sub-list payloads from level 0 were read to their exact extent
(count * 16) and compared block by block.

Range measured: savestate slot 1, the packets at 0x009376f0, 0x00939c50,
0x0093cc70, 0x00998880, 0x009c19c0, 0x009cf370, 0x009d2da0 and 0x009f5aa0,
counts 21 to 41, each truncated to exactly count*16 bytes.

Every payload contains exactly five blocks tagged 00 00 00 30, and the first
three are always at offsets 0, 32 and 64:

  009376f0  22  0, 32, 64, 184, 304
  00939c50  36  0, 32, 64, 268, 400
  0093cc70  23  0, 32, 64, 200, 288
  00998880  36  0, 32, 64, 272, 404
  009c19c0  25  0, 32, 64, 196, 300
  009cf370  24  0, 32, 64, 204, 316
  009d2da0  41  0, 32, 64, 308, 448
  009f5aa0  21  0, 32, 64, 176, 280

Blocks 4 and 5 move with the payload; the first three do not. Eight payloads,
eight different block-4/5 positions, and 0/32/64 in every case.

Per-block fields constant across all eight:

  block 0  byte 4 varies 0x78..0xcd
  block 1  byte 4 = 0 in 8/8, trailer 00000000 in 8/8
  block 2  byte 4 varies independently, bytes 16-20 zero in 8/8
  block 3  byte 4 EQUALS BLOCK 0 in 8/8
  block 4  byte 4 = 0 in 8/8

Block 2's word is unrelated to block 0's in every case, so the equality is not
every block reading one shared field.

Correction: the "byte permutation table" reported in the previous commit does
not generalise. It appears in 0x009376f0 at offset 212, but a scan across all
eight payloads finds no such run outside that one. It was one payload's block
content, not a format feature. The five-block shape, the fixed 0/32/64 offsets
and the block-0/block-3 equality are what survive eight-way comparison.

Not established: what the five blocks are, why blocks 0 and 3 share a word, and
what moves blocks 4 and 5 -- their offsets are not monotone in count (21 gives
280, 36 gives 400 and 404), so something inside the earlier blocks sets them.
This commit is contained in:
ReaperOfVeriod
2026-10-12 02:30:06 +02:00
parent 3fa64b7003
commit 186a700f32
1 changed files with 65 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/pcsx2-verification.md
+65
View File
@@ -500,3 +500,68 @@ 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.
## The sub-list payload has a fixed five-block shape
All eight sub-list payloads from level 0 were read to their exact extent
(`count * 16`) and compared block by block. The structure is the same in every
one.
**Range measured:** savestate slot 1, the eight packets at `0x009376f0`,
`0x00939c50`, `0x0093cc70`, `0x00998880`, `0x009c19c0`, `0x009cf370`,
`0x009d2da0` and `0x009f5aa0`, counts 21 to 41, each truncated to exactly
`count * 16` bytes.
**Result: every payload contains exactly five blocks tagged `00 00 00 30`, and
the first three are always at offsets 0, 32 and 64.**
| payload | count | blocks at |
|---|---|---|
| `009376f0` | 22 | 0, 32, 64, 184, 304 |
| `00939c50` | 36 | 0, 32, 64, 268, 400 |
| `0093cc70` | 23 | 0, 32, 64, 200, 288 |
| `00998880` | 36 | 0, 32, 64, 272, 404 |
| `009c19c0` | 25 | 0, 32, 64, 196, 300 |
| `009cf370` | 24 | 0, 32, 64, 204, 316 |
| `009d2da0` | 41 | 0, 32, 64, 308, 448 |
| `009f5aa0` | 21 | 0, 32, 64, 176, 280 |
Blocks 4 and 5 move with the payload; the first three do not. Eight payloads,
eight different block-4/5 positions, and 0, 32, 64 in every case.
**Per-block fields, constant across all eight:**
| block | byte 4 | other |
|---|---|---|
| 0 | varies | `0x78`-`0xcd` |
| 1 | **0** in 8/8 | trailer `00 00 00 00` in 8/8 |
| 2 | varies independently | bytes 16-20 `00000000` in 8/8 |
| 3 | **equals block 0 in 8/8** | |
| 4 | **0** in 8/8 | |
The block-0/block-3 equality is exact in all eight:
009376f0 0xcd 0x00 0xbc 0xcd 0x00
00939c50 0xc0 0x00 0xbf 0xc0 0x00
0093cc70 0x78 0x00 0x30 0x78 0x00
00998880 0xc0 0x00 0xc9 0xc0 0x00
009c19c0 0x93 0x00 0x1f 0x93 0x00
009cf370 0xb5 0x00 0x0d 0xb5 0x00
009d2da0 0xc8 0x00 0x65 0xc8 0x00
009f5aa0 0x9b 0x00 0x25 0x9b 0x00
Block 2's word is unrelated to block 0's in every case, so the equality is not
every block reading a shared field.
**Correction to the previous entry.** The "byte permutation table" reported
there does not generalise. It appears in `0x009376f0` at offset 212, but a
scan for it across all eight payloads finds no run of more than a few bytes
outside that one. What looked like a table is better described as one payload's
block content. The `00 00 00 30` block structure, the fixed 0/32/64 offsets and
the block-0/block-3 equality are the findings that survive eight-way
comparison; the permutation table was not among them.
**Not established.** What the five blocks are, why blocks 0 and 3 carry the
same word, and what moves blocks 4 and 5 -- their offsets are not monotone in
the count (`count` 21 gives 280 and `count` 36 gives 400 and 404), so something
inside the earlier blocks sets them.