Find a second packet record magic interleaved with the first

Range measured: savestate slot 1, RAM 0x22a000..0x24037f. Result: a second four-byte record magic appears at comparable density beside 04 04 00 01 -- 02 01 00 01, ten occurrences against nineteen. The two interleave: every 02 01 00 01 sits between two 04 04 00 01 records. 0x22a6b8 04 04 00 01 13 00 00 30 70 6a 93 00 0x22a6c8 02 01 00 01 19 c0 4c 6e 00 00 10 00 00 00 00 00 0x22a6e8 04 04 00 01 16 00 00 30 f0 76 93 00 0x22a6f8 04 04 00 01 16 00 00 30 50 78 93 00 0x22a708 02 01 00 01 1e c0 58 6e 00 00 10 00 00 00 00 00 0x22a728 04 04 00 01 24 00 00 30 50 9c 93 00 The 02 01 00 01 records are 16 bytes like the others but carry no pointer -- bytes 12-15 are zero in all ten. Their fields are a count at 4-5 (0x14, 0x19, 0x1e), a constant 0xc0 at 6, a varying byte at 7 (0x30, 0x4c, 0x54, 0x58), 0x6e at 8-9, and 10 00 at 10-11. The 0x6e at bytes 8-9 matches the ".. c1 01 6e" the sub-list payloads carry at offset 20-23. That is a second correspondence, and unlike the one retracted in the previous commit it is a shared value rather than a shared position. Not settled: this still does not say what discriminates the two payload kinds among the 04 04 00 01 records, since those share the same magic and the same 0x30 at byte 11 and differ only in the count at byte 8. The 02 01 00 01 records sit between them rather than replacing them, so they are a companion structure rather than the missing discriminator. Next: compare the count at byte 8 against the payload's own length.
2026-10-12 02:24:22 +02:00
parent 2d7de9f13e
commit db76319600
1 changed files with 41 additions and 0 deletions
@@ -367,3 +367,44 @@ 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.
+
+## The table interleaves two record magics
+
+Scanning the same 91 KB for other four-byte record magics beside `04 04 00 01`
+turns up a second one at the same density: **`02 01 00 01`, 10 occurrences**
+against `04 04 00 01`'s 19.
+
+**Range measured:** savestate slot 1, RAM `0x22a000..0x24037f`.
+
+**Result: the two magics interleave.** Every `02 01 00 01` sits between two
+`04 04 00 01` records:
+
+    0x22a6b8  04 04 00 01   13 00 00 30  70 6a 93 00
+    0x22a6c8  02 01 00 01   19 c0 4c 6e  00 00 10 00  00 00 00 00
+    0x22a6e8  04 04 00 01   16 00 00 30  f0 76 93 00
+    0x22a6f8  04 04 00 01   16 00 00 30  50 78 93 00
+    0x22a708  02 01 00 01   1e c0 58 6e  00 00 10 00  00 00 00 00
+    0x22a728  04 04 00 01   24 00 00 30  50 9c 93 00
+    0x22a738  04 04 00 01   16 00 00 30  50 9e 93 00
+    0x22a748  02 01 00 01   19 c0 54 6e  00 00 10 00  00 00 00 00
+
+The `02 01 00 01` records are 16 bytes like the others but carry **no pointer
+** -- bytes 12-15 are zero in all ten. Their fields are a count at 4-5
+(`0x14`, `0x19`, `0x1e`), a constant `0xc0` at 6, a varying byte at 7
+(`0x30`, `0x4c`, `0x54`, `0x58`), `0x6e` at 8-9, and `10 00` at 10-11.
+
+**The `0x6e` link.** These records carry `0x6e` at bytes 8-9, and the sub-list
+payloads found earlier carry `.. c1 01 6e` at offset 20-23. That is a second
+correspondence between this record type and the sub-list payloads, independent
+of the one retracted in the previous entry -- and this one is a shared *value*
+rather than a shared *position*.
+
+**What this does not settle.** It still does not say what discriminates the two
+payload kinds among the `04 04 00 01` records, because those all carry the same
+magic, the same `0x30` at byte 11 and differ only in the count at byte 8. The
+`02 01 00 01` records sit between them rather than replacing them, so they are
+probably a companion structure, not the missing discriminator.
+
+Still open: what distinguishes a fixed-point payload from a sub-list payload
+when the records carrying them look identical in bytes 0-3 and 11. The most
+likely place to look is the count at byte 8 against the payload's own length.