From 338af9b7bd84bca2debcc4ea99892aa53b8c6e0a Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Tue, 13 Oct 2026 04:44:09 +0200 Subject: [PATCH] Fix the collision grid dims, and disprove two sample artifacts in the payload With the payload confirmed verbatim in RAM, the disc bytes can be read directly. The grid dimensions are the first two u16 of the payload: level 0 is 11 x 33 = 363 cells, level 1 24 x 16 = 384, level 2 1 x 53 = 53. Level 2 being one cell wide is worth noting -- the grids are not all similar in shape. Two readings disproved, both by measuring the whole payload instead of a sample. An ascending u32 offset table. A probe from payload +1024 reads f4ae0000 40af0000 c4b2000020b20000, which is three ascending values before the fourth goes down (0xb2c4 to 0xb220). Read as a table, that was a three-value impression. Scanning all three levels for maximal ascending u32 runs of 8 or more entries finds zero, on every level. A global alternating-zero stride. The head of level 0 shows an obvious (value, 0) pattern from about i16[37]: [32..] [1808, 1872, 2198, 0, 34, 86, 25848, 1, 25824, 1, -13028, 0, -12284, 0, -12228, 0, -12716, 0, ...] Measured over the whole payload, both alignments score far below what that sample suggests: even-slot aligned 18% second-half zero, odd-slot aligned 13%. The sample again. What the global numbers do say is that the payload is heavily zero-bearing -- 18% against a chance rate of about 0.0015% -- which is what a sparse or variable-length encoding looks like, and consistent with the variable-length reading established earlier. The 18-against-13 split is a real alignment preference but a weak one. The cell layout is still undecoded. The useful position now is that the bytes can be read as they are and that they are sparse and variable-length rather than fixed-stride, so the next attempt should look for a terminator-delimited walk through the sparse region rather than for a record size. --- docs/formats/core-data-regions.md | 37 +++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index 209fe91..e115181 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -1642,3 +1642,40 @@ commit concluded from the disc alone. Reading the header word at `+0x00` as an element count gave 0 of 922 blocks dividing; it is the byte offset to the payload, so the table it bounds has 16-byte records. The number was right and the reading was wrong, which is the error the packet-header identification corrected. + +## Collision payload: what the verbatim mapping settles, and what it does not + +With the payload confirmed verbatim in RAM, the disc bytes can be read directly. +The grid dimensions are the **first two `u16`** of the payload -- level 0 reads +**11 x 33 = 363 cells**, level 1 **24 x 16 = 384**, level 2 **1 x 53 = 53**. +Level 2 being one cell wide is worth noting; the grids are not all similar in +shape. + +**Disproved this round -- an ascending `u32` offset table.** A probe from payload +`+1024` reads `f4ae0000 40af0000 c4b2000020b20000 ...`, which is three ascending +values before the fourth goes *down* (`0xb2c4` to `0xb220`). Read as a table that +was a three-value impression. Scanning all three levels for maximal ascending +`u32` runs of 8 or more entries finds **zero**, on every level. + +**Disproved this round -- a global alternating-zero stride.** The head of level 0 +shows an obvious `(value, 0)` pattern from about `i16[37]` onward: + + [32..] [1808, 1872, 2198, 0, 34, 86, 25848, 1, 25824, 1, + -13028, 0, -12284, 0, -12228, 0, -12716, 0, ...] + +Measured over the whole payload rather than the first 96 values, both alignments +score far below what that sample suggests: + + even-slot aligned: second half zero on 18% of pairs + odd-slot aligned : second half zero on 13% of pairs + +The sample again. What the global numbers *do* say is that the payload is heavily +zero-bearing -- 18% against a chance rate of about 0.0015% -- which is what a +sparse or variable-length encoding looks like, and is consistent with the +variable-length reading established earlier. The 18-against-13 split is a real +alignment preference but a weak one. + +**Still not decoded.** The cell layout. The useful position now is that the bytes +can be read as they are, and that they are sparse and variable-length rather than +fixed-stride -- so the next attempt should look for a terminator-delimited walk +through the sparse region, not for a record size.