Ask the chip which decoder it is, and find four wrong axes where one was expected

ROADMAP P6a, on the machine. 68000 code programs HD63450 channel 3 with the
IPL ROM's own ADPCM bytes -- dual address, 8-bit port, cycle steal, external
request -- and feeds the MSM6258 a designed 1,678-nibble stream at the chip's
own pace: 839 B in 0.1074 s = 7,811.4 B/s against the format's 7,812.5, CER=$00.
That transport is P6b's, not scaffolding.

Sixteen candidate decoder models, three capture decimations and a searched
prologue are fitted to MAME's capture. Exactly one reproduces it sample-exact
over all 1,678 samples, and every axis carries a negative control: flip it
alone and the closest survivor disagrees on 826, 1,504, 156 and 1,522 samples.

The chip runs 'terms', takes the LOW nibble of a byte first, clamps the
accumulator at 10 bits and starts it at -2. tools/encoder/adpcm.py defaulted to
the opposite of all four, and 65.2 named the wrong axis as the risk: the delta
formula is worth -2.88 dB and the NIBBLE ORDER is worth -25.74 dB. 65.1's "high
first, measured" was a measurement of ffmpeg, i.e. of the VOX file convention,
which is a different question from what a chip does with a byte in its data
register.

The 10-bit clamp is free on the Singe window and only because that window peaks
at 435 of 511 -- 1.4 dB of headroom on a -13.4 dBFS passage, 12.1 dB below where
the encoder was clamping, and inside the recursion. So the audio level is an
open choice again, downward, and the loudest passage on the disc is unmeasured.

Session 33's silence had two ordinary causes: the PPI's port C is an input until
control word $92 says otherwise, and $01 is COMMAND_STOP. And a rig fact worth
the space: the 8 MHz ADPCM clock is CT1 in the YM2151's $1B, delivered on the
sound system's schedule rather than at the store, so a transfer started in the
same breath as the setup plays its first ~17 ms at the old clock and no model
fits a stream that changed rate part way through.

Name the layer: this is MAME 0.277's okim6258 device model measured end to end
through the machine's real transport. It settles the rig and not the silicon.
Also struck: 64.4's "no MAME source tree is on this machine" -- there is none on
disk, but the machine has network and the upstream tag fetches.

check.sh ALL GREEN before (tmp/check_s34_start.log) and after
(tmp/check_s34_end.log), with one new stage.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6

docs/ROADMAP.md

@@ -96,6 +96,25 @@ The codec container, which already has an index and variable records, pays
 branch's simplification, and 64's risk list predicted there would be one without
 knowing what.
 
+Amended end of session 34: **P6a IS DONE, AND THE ENCODER WAS WRONG ON FOUR AXES
+RATHER THAN ONE (FINDINGS 66).** 68000 code programs HD63450 channel 3 with the
+IPL ROM's own ADPCM bytes — dual address, 8-bit port, cycle steal, EXTERNAL
+request — feeds the MSM6258 at the chip's own pace (**7,811.4 B/s against
+7,812.5**), and one of **sixteen** candidate decoder models reproduces MAME's
+capture **sample-exact over 1,678 consecutive samples**, with a negative control
+on every axis. The chip runs **`terms`, LOW nibble first, a 10-bit accumulator,
+starting at −2**, and `tools/encoder/adpcm.py` defaulted to the opposite of all
+four. **65.2 named the wrong axis as the risk**: the delta formula is worth
+−2.88 dB and the NIBBLE ORDER is worth **−25.74 dB**, and 65.1's "high first,
+measured" was a measurement of ffmpeg's VOX file convention rather than of a
+chip's data register. Two things came with it. **(1) The 10-bit clamp is free on
+the Singe window and only because that window peaks at 435 of 511** — 1.4 dB of
+headroom on a −13.4 dBFS passage, where the encoder had been clamping 12.1 dB
+higher — so **the audio LEVEL is an open choice again**, downward, and the
+loudest passage on the disc is unmeasured. **(2) The transport is P6b's, not
+scaffolding**, and it worked first time. **P6b is next and its bytes are
+decided: DLXP2 encodes with `adpcm.CHIP`.**
+
 **THE COMPLETION TARGET IS M3, THE VERTICAL SLICE** (USER DECISION): one scene
 tree — a decision point, two outcomes, a death clip — with audio, streaming from
 a real SCSI volume on a stock 2 MB machine, playable. That is the point at which
@@ -657,7 +676,13 @@ Buildable, and empty until P4: there is nothing to boot from yet.
 **Exit criterion: one decision point, two outcomes, a death clip, with audio,
 playing from disc on stock hardware.**
 
-**P6. Audio — and it is the largest unpriced risk left in the project.**
+**P6. Audio. P6a DONE, session 34 — FINDINGS 66.** ~~and it is the largest
+unpriced risk left in the project.~~ Three quarters of P6 closed in session 33
+and the fourth precondition — which decoder the chip runs — closed in 34, on the
+machine, through the real DMA channel. **What is left of P6 is P6b (DLXP2, a
+container with sound in it) and the refill climb with a second consumer.**
+
+*(original framing, kept because every figure below is still the live one:)*
 MSM6258 ADPCM, 15.6 kHz mono, **7.8 KB/s**. That figure is in `ratectl.py`'s
 budget and nowhere else: not extracted, not encoded, not interleaved into the
 container, and **never priced on the bus**. Two reasons to treat it as a risk