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

Show the byte-8 count sizes sub-list payloads at exactly 16 bytes each

Browse Source 
The previous entry left one test: compare the count at byte 8 against the
payload extent. Pointer spacing gives the extent, since the packets lie in
ascending order in EE RAM.

Range measured: savestate slot 1, the 17 packets in RAM 0x22a000..0x24037f,
each with its record address, byte-8 count and pointer, sorted by pointer.

Result: eight packets sit exactly count*16 bytes after their predecessor -- a
ratio of 16.00 in every one, no rounding.

  0x22a6e8  count 22  ptr 009376f0  gap 352   16.00
  0x22a728  count 36  ptr 00939c50  gap 576   16.00
  0x22a768  count 23  ptr 0093cc70  gap 368   16.00
  0x22a7a8  count 36  ptr 00998880  gap 576   16.00
  0x22a7e8  count 25  ptr 009c19c0  gap 400   16.00
  0x22a828  count 24  ptr 009cf370  gap 384   16.00
  0x22a868  count 41  ptr 009d2da0  gap 656   16.00
  0x22a8a8  count 21  ptr 009f5aa0  gap 336   16.00

Eight exact hits at a ratio that must be an integer is not luck. The count at
byte 8 is the record count, and these payloads are 16 bytes per record.

These are exactly the sub-list payloads -- 009376f0, 00939c50, 0093cc70,
00998880 and 009d2da0 were read directly in earlier passes and all open
00 00 00 30 followed by a repeated word.

The other nine have ratios of 168, 419, 559, 31288, 7985, 3458, 764 and 6452
-- no shared factor, far too large to be a record count times anything. Either
their payload is not followed immediately by the next packet in pointer order,
or they are not 16 bytes per record. Ruled out either way: they do not follow
the same rule.

This resolves byte 8, measured two entries ago as "a count, 0x0b to 0x29" and
now shown to size a payload exactly in eight independent cases within one
level. Whether it also sizes the fixed-point payloads is the open half.

Still open: why the fixed-point packets differ, and what the 16 bytes per
sub-list record are -- the repeated word (0xcd, 0xc0, 0xc8, 0x78) differs per
packet, so the records are not identical to each other.
This commit is contained in:
ReaperOfVeriod
2026-10-12 02:27:28 +02:00
parent db76319600
commit f1cf6cd164
1 changed files with 47 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/pcsx2-verification.md
+47
View File
@@ -408,3 +408,50 @@ 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.
## The count at byte 8 sizes the sub-list payload: exactly 16 bytes per record
The previous entry left one test: compare the count at byte 8 against the
payload's own extent. Pointer spacing gives the extent, since the packets are
laid out in ascending order in EE RAM.
**Range measured:** savestate slot 1, the 17 packets in RAM
`0x22a000..0x24037f`, each with its record address, byte-8 count and pointer,
sorted by pointer so the next packet is the next object in memory.
**Result: eight packets sit exactly `count * 16` bytes after their predecessor
-- an integer ratio of 16.00 in every one, with no rounding.**
record count ptr gap gap/count
0x22a6e8 22 009376f0 352 16.00
0x22a728 36 00939c50 576 16.00
0x22a768 23 0093cc70 368 16.00
0x22a7a8 36 00998880 576 16.00
0x22a7e8 25 009c19c0 400 16.00
0x22a828 24 009cf370 384 16.00
0x22a868 41 009d2da0 656 16.00
0x22a8a8 21 009f5aa0 336 16.00
Eight exact hits at a ratio that has to be an integer is not sampling luck. The
count at byte 8 is the **record count**, and these payloads are 16 bytes per
record.
**And these are exactly the sub-list payloads** -- `0x009376f0`, `0x00939c50`,
`0x0093cc70`, `0x00998880`, `0x009d2da0` were all read directly in earlier
passes and all open `00 00 00 30` followed by a repeated word.
**What the other nine are.** Their ratios are 168, 419, 559, 31288, 7985,
3458, 764, 6452 -- no shared factor, and far too large to be a record count
times anything. So either their payload is not followed immediately by the next
packet in the pointer order (other data intervenes), or they are not 16 bytes
per record. Both readings are open; what is ruled out is that they follow the
same rule.
**This resolves byte 8.** It was measured as "a count, 0x0b to 0x29" two entries
ago and is now shown to size a payload exactly, in eight independent cases,
within a single level. Whether it also sizes the fixed-point payloads is the
open half.
Still open: why the fixed-point packets do not follow the same rule, and what
the 16 bytes per sub-list record are -- the repeated word (`0xcd`, `0xc0`,
`0xc8`, `0x78`) differs per packet, so the records are not identical.