From 2d7de9f13e1f119a831322201fa26fd435a31401 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Mon, 12 Oct 2026 02:22:06 +0200 Subject: [PATCH] Correct the packet tag mapping: the tag does not select the payload 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. --- docs/plan/pcsx2-verification.md | 51 +++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/docs/plan/pcsx2-verification.md b/docs/plan/pcsx2-verification.md index da06e12..df6f5a4 100644 --- a/docs/plan/pcsx2-verification.md +++ b/docs/plan/pcsx2-verification.md @@ -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 EE pointer. The earlier "records at 0x30 spacing" was inferred from a truncated 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.