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.
ReaperOfVeriod
2d7de9f13e