Each with the measurement that failed to settle it. A question with a number next to it is worth more than an answer without one.
root dir record, in the PVD 1994-08-17 16:41:45 +0
root '.' entry, in its own extent 1994-08-17 16:41:45 +0
root '..' entry 1994-08-17 16:41:45 +0
earliest file or subdirectory 1994-08-22 12:13:39 +0
PVD creation date 1994-08-24 12:17:15 +0
Stored consistently in three places, so not a read error. The root is 7 d 19 h 31 m 54 s older than the earliest thing inside it. All 21 subdirectories are 08-22 or 08-24; only the root is old, and it is the only record on the disc from 1994-08-17.
What would settle it: the same field on the other fifteen discs. Nothing in the checklist has asked for the root directory record's own date before — only for the PVD date against the file dates — so there is no baseline. This is one line of code on each disc and it is now step 37.
magic leeway unpacked packed 14+packed filesize
MAPMONITOR CrM! 0 61,440 18,020 18,034 18,034 ✓
MAPMONITORSCREENS CrM! 0 102,400 16,480 16,494 16,494 ✓
Header validated exactly on both. The stream is not read, so Super Stardust's resident figure is a lower bound (≥3,358,430 rather than 3,221,772).
The inherited decoder from cd32-gloom-doc implements CrM2 only; its CrM!
branch is the literal line raise NotImplementedError("CrM! stream: no file on the disc uses it") — true of Gloom, false here. Gloom's own binary contains a
CrM! decoder at code-hunk offset 0x24DAA, which is where a transcription would
come from, but that binary is not in this repository (documentation only).
What would settle it: transcribe the CrM! routine from Gloom's executable
the way crm.py transcribed CrM2. Cost: one routine.
Nine files, header proven on 9 of 9 (14 + packed == filesize), declared
unpacked size confirmed against a RAW/ sibling on 4 of 4 where one exists.
16,620 bytes on disc declaring 23,966, 1.44×.
The codec is not decoded. Until it is, the honest claim is "a ninth container format", not "a ninth cruncher" — the eight known crunchers are known because someone ran their decompressor.
What would settle it: the decoder is in MAINDEMO1/MAINDEMO2/TUNNELDEMO,
which are the only programs that read CRM/. Finding it is a matter of locating
the reader of the 14-byte header.
Second-order question: the RAW/ and AGARAW/ copies exist alongside the
CRM/ and AGACRM/ ones, so the decoder can be verified without being
understood — decode a CRM/ file and compare against its RAW/ twin. Four
files give four independent checks. That is a stronger validation setup than any
cruncher in the set has had.
52 occurrences across 26 shipped files, 8 distinct targets, 0 of them on the
disc, and the assign name spelled three ways: SDIFF × 32, sdiff × 10,
Sdiff × 10, with the same target taking different cases in different files.
The disc says the level maps were built from IFF artwork called L1BM-IFF
through L6BM-IFF, LBBM-IFF and LWBM-IFF, on a volume or assign called
SDIFF:. It does not say what SDIFF: was — a hard-disk partition, a network
volume, a directory assign. SDDISK1: on the same disc is plainly "SuperFrog
Data DISK 1", which suggests SDIFF: is "SuperFrog IFF", but that is a reading
of a name and not a measurement, and it is recorded here as such.
The 08-22 copy pass wrote 231 records in eleven seconds (12:13:39–12:13:50). One file, the game engine, is dated 12:30:26 — 16 minutes 36 seconds later, and alone.
Everything it loads was already in place. Something replaced only the executable. A late build, a late bug fix, a substitution of a different build — the disc does not distinguish them.
Related and also open: SFData/PARTF embeds a variant build of the same
engine (same seven dispatch sites at a constant 0x728 offset, byte-identical
at the dispatch site, 92.8 % identical over 4 KB). If the 12:30 rebuild changed
SuperFrogCD and not PARTF, the difference between the two embedded builds
might be exactly what was fixed. Measuring it needs the relocation-masked diff
from 06-executables.md applied to two unpacked pieces, which
this session did not do.
Five 64-entry tables, 320 slots, 24 distinct branch targets, one default taking 265 slots (82.8 %). The vocabulary is 23 real handlers out of a 64-wide opcode space.
Naming them means following 23 branches, which this session did not do. The structural facts are settled (06-executables.md); the semantics are not.
The volume is named SuperFrog_AGA. Superfrog's own display is five
bitplanes, 32 colours, lores 320×256, with BPLCON3 written only to safe
defaults and FMODE never written in any validated copper list — an ECS-capable
display. Arcade Pool has an eight-plane, 256-colour AGA copper list
(BPLCON0 $0210). Super Stardust ships parallel AGARAW/AGACRM and
RAW/CRM asset trees, so it has two asset sets by design.
So the disc's AGA content is demonstrably in the two demos. Whether _AGA names
a build variant of the compilation, distinguishes this master from an ECS one,
or is simply the directory name the master was cut from, the disc does not say.
What would settle it: an ECS-named sibling master, if one exists. This is step 15 / 28 territory and there is no second master to diff against here.
Not answerable from one disc, and worth stating as unanswered rather than
assumed. The evidence for looking: the volume name carries a variant suffix
(_AGA); T17Man ships in two builds differing by one DisplayID byte, so this
pipeline demonstrably shipped parallel variants of at least one program.
Nothing on the disc references another master.
The image is 4,194 sectors, the volume declares 4,164, and the difference is 30 sectors of zero — separate from and additional to the 32 unclaimed sectors inside the volume at LBA 4132–4163.
30 is a new value for this column. The image being an exact multiple of 2048 — unlike all fifteen predecessors, whose images are not — points at the dumper rounding rather than the mastering tool, but that is a reading of one number.
What would settle it: a second dump of this disc.
libs/nonvolatile.library ships. No binary on the disc names it except
c/SetPatch and libs/lowlevel.library, which are both Commodore's. No binary
loads $00B80030. So nothing on this disc saves anything — and yet the library
was deliberately placed in libs/.
Either the compilation shell was built from a template that included it, or a
save feature was planned and cut. The disc has no other trace of one: no save
file, no ENV:/ENVARC: write beyond the boot assigns, no high-score file.
Written in _work/predictions.md at the start of the
session, before any tool was run against the image beyond ls and reading the
.cue. Scored here honestly, including the wrong ones — which are the useful
ones.
| # | Prediction | Outcome | |
|---|---|---|---|
| P1 | Preparer name empty | WRONG — Kenny Grant, a third pattern, neither Pocock nor empty |
✗ |
| P2 | Trailing run 32 sectors | RIGHT, but for the wrong reason: right number, dead premise | ½ |
| P3 | Cruncher is the Imploder | RIGHT — 96 files, ATN!, Speris's own decruncher decodes all of them |
✓ |
| P4 | Disc compresses and floppy ancestry is readable | RIGHT, and further than expected — the three-floppy layout comes out exactly | ✓ |
| P5 | Band holds, via "barely compresses" (a) or "low factor" (c) | WRONG on both routes. It expands 3.25×, second-highest in the set. The on-disc band survives only via route (b), which the prediction ranked last; the resident band's ceiling breaks by 0.64 % | ✗ |
| P6 | Planar in planar, zero C2P immediates | RIGHT on the conclusion, and the zero is sharper than predicted: four of the six constants have zero immediates, $55555555 and $AAAAAAAA have 37 and they are a 2-bit interleave |
✓ |
| P7 | Akiko 0, 0, 0, 0 | RIGHT, all four zero | ✓ |
| P8 | Music is ProTracker; OpenDevice zero or near zero |
WRONG on both halves. Zero ProTracker, zero OctaMED; 37 The Player modules, a format the checklist did not list. OpenDevice is 4, not 0 — in the two demos |
✗ |
| P9 | No script VM; structure lives in a data format | HALF RIGHT. No VM of the Universe form — no program counter, a1 is a compile-time delta table — but there is a 64-way type dispatch, five tables, 320 slots, 24 handlers |
½ |
| P10 | .TM matches the twelve, not Speris |
RIGHT | ✓ |
| P11 | Prose under 1 % of on-disc bytes; 7-bit ASCII; a $VER: present |
MIXED. 1.054 % on disc — over, by a hair, on the denominator named — 0.496 % resident. Not 7-bit: correct ISO 8859-1 across four languages. $VER: present, but on none of the six game programs |
½ |
| P12 | Every FORM big-endian |
RIGHT — 20 of 20, zero little-endian | ✓ |
| P13 | Nesting depth 0 | WRONG — depth 2, with 21 streams inside the output of other streams | ✗ |
| P14 | Fewer than three findings that would change a checklist line | WRONG, and this is the one worth the most. At least seven: the band ceiling, a fifth home for music, a third preparer pattern, a ninth container, the tool-versus-label split with a named mechanism, step 36's second instance, and the root-directory date | ✗ |
Score: six right, five wrong, three half.
The five wrong ones carry the session. P5 produced the band result. P8 produced The Player. P13 produced the nesting. P1 produced the third preparer pattern. And P14 — the prediction that the disc would be boring — is the most wrong of the fourteen, which was worth writing down precisely because the expectation was reasonable: a 1993 2D platformer on 1.26 % of a CD.
What actually made it interesting was not the game. It was that the disc is a compilation — three programs by two studios plus a bespoke front end — so almost every question got asked three times on one master, and the disagreements between the three answers are where the results are. A single-game disc of the same size would have produced far less.