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

Correct the packet tag mapping: the tag does not select the payload

Browse Source 
The previous commit mapped the disc tag vocabulary onto the three payload
classes. A wider scan says that is wrong.

Range measured: savestate slot 1, RAM 0x22a000..0x24037f -- 91008 bytes, 20
times the span scanned before.

Result: 19 packet headers, and all 19 carry byte 11 = 0x30. There are no 0x6d
or 0x80 tags anywhere in this range. Reading six payloads:

  rec 0022a6b8 tag 30 -> 8d 8c 80 80 89 87 7c 80 ...   fixed point
  rec 0022a6e8 tag 30 -> 00 00 00 30 cd 00 00 00 ...   sub-list
  rec 0022a6f8 tag 30 -> 92 90 84 80 94 94 86 80 ...   fixed point
  rec 0022a728 tag 30 -> 00 00 00 30 c0 00 00 00 ...   sub-list
  rec 0022a738 tag 30 -> 4c 4c 4b 80 4c 4c 4b 80 ...   fixed point
  rec 0022a768 tag 30 -> 00 00 00 30 78 00 00 00 ...   sub-list

Records of identical tag alternate between two payload kinds. The tag does not
select the payload.

What went wrong: the previous entry took the 0x30 and 0x6d that head the
payloads to be the disc-side tag vocabulary, and matched them to payload classes
by that correspondence. The disc vocabulary at record byte 7 (0x00, 0x30, 0x6d,
0x80) and RAM record byte 11 are different fields that merely overlap in two
values. Three payloads each made the coincidence look like a rule.

What is actually established about the RAM header:

  0-3    04 04 00 01, constant
  4-7    zero, constant
  8      a count, 0x0b to 0x29 across the 19 records
  9-10   zero, constant
  11     0x30, constant on all 19 in this range
  12-15  an EE RAM pointer

Byte 8 is the finding that survives: a small count varying per record, and the
one field here doing arithmetic rather than tagging.

Still open: what 0x30 at byte 11 means, what discriminates payload kinds given
the tag does not, and 0x80, which has no sample in 91 KB of RAM.
This commit is contained in:
ReaperOfVeriod
2026-10-12 02:22:06 +02:00
parent 0b1793d6af
commit 2d7de9f13e
1 changed files with 51 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/pcsx2-verification.md
+51
View File
@@ -316,3 +316,54 @@ fourth value in the vocabulary and there is no sample of it here.
headers, and only 9 of the 5,632 bytes scanned carry both the `0x30` tag and an 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 EE pointer. The earlier "records at 0x30 spacing" was inferred from a truncated
list of hits and does not hold. list of hits and does not hold.
## Correction: the record tag does not select the payload
The previous entry mapped the disc tag vocabulary onto the three payload
classes. A wider scan says that is wrong.
**Range measured:** savestate slot 1, RAM `0x22a000..0x24037f` -- 91,008 bytes,
20 times the span scanned before.
**Result: 19 packet headers, and all 19 carry byte 11 = `0x30`.** There are no
`0x6d` or `0x80` tags anywhere in this range. Reading six of their payloads:
rec 0022a6b8 tag 30 -> 00936a70 8d 8c 80 80 89 87 7c 80 ... (fixed point)
rec 0022a6e8 tag 30 -> 009376f0 00 00 00 30 cd 00 00 00 ... (sub-list)
rec 0022a6f8 tag 30 -> 00937850 92 90 84 80 94 94 86 80 ... (fixed point)
rec 0022a728 tag 30 -> 00939c50 00 00 00 30 c0 00 00 00 ... (sub-list)
rec 0022a738 tag 30 -> 00939e90 4c 4c 4b 80 4c 4c 4b 80 ... (fixed point)
rec 0022a768 tag 30 -> 0093cc70 00 00 00 30 78 00 00 00 ... (sub-list)
Records of identical tag alternate between two payload kinds. **The tag does
not select the payload.**
**What went wrong.** The previous entry took the `0x30` and `0x6d` that *head
the payloads* to be the disc-side tag vocabulary, and matched them to the
payload classes by that correspondence. The disc vocabulary measured at record
byte 7 -- `0x00`, `0x30`, `0x6d`, `0x80` -- and the RAM record byte 11 were
treated as the same field. They are not: the payload magics are a property of
the payload, and record byte 11 is a different thing that happens to be
constantly `0x30` here.
Three payloads each made the coincidence look like a rule. It was a
correspondence between two vocabularies that overlap in two values.
**What is actually established about the RAM header**, per position:
| byte | value |
|---|---|
| 0-3 | `04 04 00 01`, constant |
| 4-7 | zero, constant |
| 8 | a **count**, `0x0b` to `0x29` across the 19 records |
| 9-10 | zero, constant |
| 11 | `0x30`, constant on all 19 in this range |
| 12-15 | an EE RAM pointer |
Byte 8 is the finding that survives. It is a small count that varies per
record, and it is the one field here that is doing arithmetic rather than
tagging.
**Still open:** what `0x30` at byte 11 means, what discriminates the payload
kinds given that the record tag does not, and the meaning of `0x80`, which has
no sample in 91 KB of RAM.