All eight sub-list payloads from level 0 were read to their exact extent
(count * 16) and compared block by block.
Range measured: savestate slot 1, the packets at 0x009376f0, 0x00939c50,
0x0093cc70, 0x00998880, 0x009c19c0, 0x009cf370, 0x009d2da0 and 0x009f5aa0,
counts 21 to 41, each truncated to exactly count*16 bytes.
Every payload contains exactly five blocks tagged 00 00 00 30, and the first
three are always at offsets 0, 32 and 64:
009376f0 22 0, 32, 64, 184, 304
00939c50 36 0, 32, 64, 268, 400
0093cc70 23 0, 32, 64, 200, 288
00998880 36 0, 32, 64, 272, 404
009c19c0 25 0, 32, 64, 196, 300
009cf370 24 0, 32, 64, 204, 316
009d2da0 41 0, 32, 64, 308, 448
009f5aa0 21 0, 32, 64, 176, 280
Blocks 4 and 5 move with the payload; the first three do not. Eight payloads,
eight different block-4/5 positions, and 0/32/64 in every case.
Per-block fields constant across all eight:
block 0 byte 4 varies 0x78..0xcd
block 1 byte 4 = 0 in 8/8, trailer 00000000 in 8/8
block 2 byte 4 varies independently, bytes 16-20 zero in 8/8
block 3 byte 4 EQUALS BLOCK 0 in 8/8
block 4 byte 4 = 0 in 8/8
Block 2's word is unrelated to block 0's in every case, so the equality is not
every block reading one shared field.
Correction: the "byte permutation table" reported in the previous commit does
not generalise. It appears in 0x009376f0 at offset 212, but a scan across all
eight payloads finds no such run outside that one. It was one payload's block
content, not a format feature. The five-block shape, the fixed 0/32/64 offsets
and the block-0/block-3 equality are what survive eight-way comparison.
Not established: what the five blocks are, why blocks 0 and 3 share a word, and
what moves blocks 4 and 5 -- their offsets are not monotone in count (21 gives
280, 36 gives 400 and 404), so something inside the earlier blocks sets them.
ReaperOfVeriod
186a700f32