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

Map shrub packet tags onto three payload kinds

Browse Source 
Dereferenced all nine pointers in the level 0 table that carry the 0x30 tag at
byte 11 and an EE pointer at 12..15, reading 32 bytes each. They fall into
exactly three classes, three payloads each, with no overlap.

A, Q16.15 fixed-point vertex data (3 of 9): every high byte 0x80 or 0x7c,
repeating on an 8-byte boundary, values differing per payload while the
4e 4e 4c 80 tail is shared by two.

  00936a70  8d 8c 80 80 89 87 7c 80 ... 4e 4e 4c 80
  0093cde0  8a 8a 7f 80 92 90 84 80 ... 4e 4e 4c 80
  009cf4f0  6e 6f 68 80 6e 6f 68 80 ... 54 54 51 80

B, a 0x30 sub-list with a repeated word (3 of 9), structurally identical
apart from that word (0xcd, 0xc0, 0xc8), all carrying 01 00 00 05 at offset 16
and a ".. c1 01 6e" at 20.

  009376f0  00 00 00 30 cd 00 00 00 cd 00 00 00 ...
  00998880  00 00 00 30 c0 00 00 00 c0 00 00 00 ...
  009d2da0  00 00 00 30 c8 00 00 00 c8 00 00 00 ...

C, an index/attribute list (3 of 9), both opening 00 c0 05 6d, then a count,
then a run of small ascending u16.

  00939700  00 c0 05 6d 3e 00 00 00 01 00 00 00 ...
  009c1540  00 c0 05 6d 36 00 00 00 01 00 00 00 ...

So the tag vocabulary measured on disc at record byte 7 -- 0x00, 0x30, 0x6d,
0x80 -- selects the payload:

  0x30  class B, the 00 00 00 30 sub-list
  0x6d  class C, the 00 c0 05 6d attribute list
  0x00  class A, the fixed-point vertex data

0x30 heads the class B payloads and 0x6d heads the class C payloads. That was
flagged as a single coincidence two commits back; three payloads each makes it
a rule.

0x80 has no sample among these nine and its meaning stays open.

Correction: the record spacing in this table is not uniformly 0x30. The find
output shows 0x30, 0x10, 0x30 between consecutive packet headers, and only 9
of the 5632 bytes scanned carry both the 0x30 tag and an EE pointer. The
earlier "0x30 spacing" was inferred from a truncated hit list.
This commit is contained in:
ReaperOfVeriod
2026-10-12 02:20:04 +02:00
parent ad70e4c4be
commit 0b1793d6af
1 changed files with 63 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/pcsx2-verification.md
+63
View File
@@ -253,3 +253,66 @@ all fields of it. Two adjacent records with unrelated payloads is not that.
appears in record bytes 8-11 in RAM also appears at the head of the second
payload, which is suggestive but is one coincidence so far and should not be
written up as a link until it is seen in more than one record.
## The tag values map onto three payload kinds
Following the pointers out of the level 0 table, all nine that carry the `0x30`
tag at byte 11 and an EE pointer at 12..15 were dereferenced and read 32 bytes
each. They fall into exactly three classes, three payloads each, with no
overlap.
**A -- Q16.15 fixed-point vertex data** (3 of 9)
00936a70 8d 8c 80 80 89 87 7c 80 8d 8c 80 80 89 87 7c 80
4e 4e 4c 80 4e 4e 4c 80 4e 4e 4c 80 4e 4e 4c 80
0093cde0 8a 8a 7f 80 92 90 84 80 8a 8a 7f 80 92 90 84 80
4e 4e 4c 80 4e 4e 4c 80 4e 4e 4c 80 4e 4e 4c 80
009cf4f0 6e 6f 68 80 6e 6f 68 80 6e 6f 68 80 6e 6f 68 80
54 54 51 80 54 54 51 80 54 54 51 80 54 54 51 80
Every high byte is `0x80` or `0x7c`, each payload repeats on an 8-byte
boundary, and the values differ between payloads while the `4e 4e 4c 80` tail
is shared by two of them.
**B -- a `0x30` sub-list with a repeated count** (3 of 9)
009376f0 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
00998880 00 00 00 30 c0 00 00 00 c0 00 00 00 c0 00 00 00
c0 00 00 00 01 00 00 05 11 c1 01 6e 00 00 00 00
009d2da0 00 00 00 30 c8 00 00 00 c8 00 00 00 c8 00 00 00
c8 00 00 00 01 00 00 05 1d c1 01 6e 00 00 00 00
Structurally identical apart from the repeated word: `0xcd`, `0xc0`, `0xc8`.
All three carry `01 00 00 05` at offset 16 and a `.. c1 01 6e` at 20.
**C -- an index/attribute list** (3 of 9)
00939700 00 c0 05 6d 3e 00 00 00 01 00 00 00 12 00 00 00
18 00 c0 00 fe 00 fe 00 ff 00 ff 00 11 01 17 01
009c1540 00 c0 05 6d 36 00 00 00 01 00 00 00 08 00 00 00
13 00 93 00 c9 00 c9 00 ca 00 ca 00 d2 00 d5 00
Both open `00 c0 05 6d`, then a count, then a run of small ascending `u16`.
**The mapping.** The tag vocabulary measured on disc -- `0x00`, `0x30`,
`0x6d`, `0x80` at record byte 7 -- is not decorative:
| tag | payload |
|---|---|
| `0x30` | class B, the `00 00 00 30` sub-list |
| `0x6d` | class C, the `00 c0 05 6d` attribute list |
| `0x00` | class A, the fixed-point vertex data |
`0x30` heads the class B payloads and `0x6d` heads the class C payloads, which
is the link flagged as a single coincidence two entries back. It is now seen in
three payloads each, so it is a rule rather than an accident.
`0x80` did not appear among these nine. Its meaning is still open -- it is the
fourth value in the vocabulary and there is no sample of it here.
**A correction.** The record spacing in this table is not uniformly `0x30`. The
`find` output shows `0x30`, `0x10`, `0x30`, `0x30` between consecutive packet
headers, and only 9 of the 5,632 bytes scanned carry both the `0x30` tag and an
EE pointer. The earlier "records at 0x30 spacing" was inferred from a truncated
list of hits and does not hold.