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
This commit is contained in:
prosolis
2026-08-25 09:50:03 -07:00
parent f925a1dd9a
commit 6dd3fb3597
15 changed files with 1240 additions and 22 deletions
+28
View File
@@ -357,6 +357,34 @@ ADPCM is recursive and a rounding difference does not stay where it happens. So
which one the chip runs is not a footnote; it is a precondition on shipping any
audio at all, and MAME's x68000 has the chip to ask (FINDINGS 65).
**So the chip was asked, and the encoder was wrong on four things rather than
one.** 68000 code programs the machine's own ADPCM DMA channel exactly as the
IPL ROM programs it — the register bytes are decoded out of the ROM image, not
recalled — and feeds the chip a designed 1,678-nibble stream at the chip's own
pace, 7,811.4 bytes a second against the format's 7,812.5. Sixteen candidate
decoder models are then fitted to what MAME captured, and **exactly one
reproduces it sample-exact over all 1,678 samples**, with a negative control on
every axis: flip one and the match dies. The chip runs the datasheet's
truncation, takes the **low** nibble of a byte first, clamps its accumulator at
**10 bits**, and starts it at **2**. `adpcm.py` defaulted to the opposite of
all four.
And the expensive one is not the one the paragraph above worried about. Getting
the delta formula wrong costs 2.88 dB; getting the **nibble order** wrong costs
**25.74 dB**. The earlier "high nibble first, measured" was a real measurement
of *ffmpeg*, i.e. of the Dialogic VOX **file** convention — a different question
from what a chip does with a byte written to its data register, with a different
answer. The 10-bit clamp costs nothing on this window and only because the
window peaks at **435 of 511**: it is a 13.4 dBFS passage with 1.4 dB of
headroom, 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 (FINDINGS 66).
**Name the layer**: that is MAME's device model, measured end to end through the
machine's real transport. It settles the rig — an emulated audio test encoded
against the wrong model is 25 dB of nothing — and it does not settle the
silicon.
**And audio is what the packed container's best property finally costs
something for.** A packed record is 97 sectors and its address is arithmetic —
no index, and none can be needed. Audio is 651.0417 bytes a frame slot, a rate