Files
Dragon-s-Lair-X68k/tools/analysis/20_seek_slack.py
T
prosolis 2f9f5cc995 Pace the ring, then read the DMAC config out of the IPL ROM: audio is cheap and the disk is not
Two sessions that were never separated in the working tree, so they land as one
commit. check.sh ALL GREEN before and after both.

SESSION 19 -- the ring rig gets a frame clock (FINDINGS 51).

src/player/stream.s had no frame clock: it asked for record i the instant it
finished i-1, outran any finite pipe, and never let the ring back up. The 49.1
sweep passing at 48 KB was therefore a wrap-correctness result and nothing else.
PACE/PACEON ($18034/$18038) hold the decoder to 12 fps, so FR_HEAD-FR_TAIL
finally means what it reads as: whole frames the decoder could still draw with
delivery stopped dead. PACEON=0 free-runs and is what the wrap gate still uses,
so every figure in 49 is unmoved.

Paced, on the gate container: 64 KB holds 2 frames, 256 KB holds 7-8, 512 KB
holds 14-15, all pixel-exact. Tolerance is ceiling-1, measured by cutting the
pipe: 256 KB buys 500 ms of dead pipe, not 583.

SLACK IS ACCUMULATED, NOT OWNED. It is built out of pipe-wire and a seek spends
all of it. At 488 KB/s a 256 KB ring needs 4.83 s of play to reach its ceiling
from empty; 512 KB needs 8.42 s to reach 14. A bigger ring raises the ceiling
AND lengthens the climb, so a branch point does not ask "is the buffer big
enough" but "has there been enough play since the last one" -- and Dragon's
Lair's decision points are seconds apart. The rig now also says WHICH resource
is binding: at 460 KB/s every ring from 192 KB to 512 KB is rate-bound at
ceiling 4 and never fills, so larger rings are dead RAM in that scene.
20_seek_slack.py is the same model rewritten in Python from record sizes,
sharing no code with the Lua producer: 35/35 ceilings inside its bracket.

SESSION 20 -- the DMAC configuration was in the IPL ROM the whole time
(FINDINGS 52).

ROADMAP's "do this first" was to put the ADPCM stream on the bus. That needs a
clocks-per-byte figure for the audio channel, and 11_cpu_budget.py was charging
audio the DISK's rate -- 5 clk/B, its own help text calling it "single-address,
bus held". Audio was being charged the favourable end of B3, a 242 KB/s open
question.

It never had to be a guess. The IPL ROM programs all four HD63450 channels
itself and MAME boots the rig with it, so 21_iplrom_dmac.py reads the
configuration out of the image and decodes the MC68450 fields. Eight
(address, expected bytes, meaning) sites; a mismatch or an unknown revision
exits non-zero. In check.sh, no emulator, milliseconds.

ch3 DCR=$80, OCR=$32: dual address, 8-bit port, cycle steal WITHOUT hold,
REQG=10 external request. The DMAC arbitrates once per byte with no burst to
amortise the 5..8 + 2 over, so an audio byte is 16..19 clocks, not 5 -- the old
debit was 3.2x..3.8x small. And on the bus it is still nothing: 651 B/frame is
1.25%..1.48% of a frame, about 4% of what the decoder leaves. P6's bus risk
does not materialise. The unit worry was worth checking and nearly right: 15.6
kHz is 8 MHz/512 = 15,625 samples/s, two 4-bit samples to a byte = 7,812.5 B/s
exactly, and AUDIO_KBPS=7.8 is that in decimal kB while the tool multiplied by
1024.

THE DISK CHANNEL IS PROGRAMMED IDENTICALLY. ch1 (SASI) is DCR=$80 too, and so
is ch0. That is 16..19 clocks per delivered byte, where 42.4 brackets W at 5..12
and 42.5 has W=8 already missing 47/120 frames. The only worked example of a
disk DMA configuration on this machine sits above the entire bracket, and at
that price nothing fits at any container size. It is not scsiexrom.bin so B3
stays open -- what changed is that a cheap configuration is now the thing that
has to be SHOWN. W <= 12 is a requirement on the player's DMAC programming, not
a range the hardware hands us, and it is now the largest open number in the
project, ahead of the rate.

An unforced cross-check fell out: 15_bus_occupancy.py's new W sweep puts W=8 at
105.7% of the frame, agreeing with 42.5's 47/120, from mode histograms and bus
clocks respectively, two models sharing no code.

Also: ADPCM outranks the disk at the arbiter (CPR 1 against 2), so an audio byte
never waits and a video byte does -- relevant to 51's smooth-rate delivery model.

README MEDIA.

stream.lua gains DLX_SNAP_EVERY=1 (needs DLX_PACE, off by default, on no path
check.sh takes) and tools/media/make_readme_media.py turns the PNGs into
docs/img/. The stills and both clips are MAME's own screen pixels.

Building it turned up something worth recording. 116 of 119 captured frames are
pixel-exact against dlx.py; three are TORN -- frame n on top, frame n-1 below
the tear line -- because MAME captured the screen while the block loop was
partway down it. decode.s writes straight to the displayed page (one display
path, 28.1), so a real player tears the same way, and this is the first time
that consequence has been visible rather than argued. The script ASSERTS the
tear and refuses to build otherwise, rather than trimming three frames and
reporting "every frame I kept is exact". Second correction the capture forced:
the snapshot fires before frame n is decoded, so the obvious reading is that it
holds frame n-1 -- it does not, because MAME renders the screen at the end of
the machine frame, by which time the 68000 has finished frame n.

11_cpu_budget.py's "validated to within 1 pt" line is also corrected: the model
reads 2..10 pt HIGH and by more as the frame gets harder, which was already true
before either session.

src/player/decode.s is unchanged; decode.bin is still 1,296 B at the same MD5.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6
2026-08-24 18:14:01 -07:00

147 lines
6.7 KiB
Python

"""Seek slack: how long a branch point can stop delivery (STATUS 4, FINDINGS 51).
19_ring_stream.py asks whether a container ARRIVES in time, and prints one
"seek slack" column derived statically as (usable ring - maxrec)/mean record.
That is a capacity estimate and it quietly assumes the ring is full when the
seek happens. It is not, and the difference is the whole finding:
A ring's slack is ACCUMULATED, not owned. It is built out of the surplus
between the pipe and the wire demand, at (pipe - wire) bytes per second, and
a seek spends all of it. How long a branch point can stall is a property of
the ring; how soon the NEXT branch point can be afforded is a property of the
surplus, and a bigger ring makes that one WORSE.
This is the paced-rig model (tools/bench/stream.lua with DLX_PACE=1) written
independently, and it exists to be compared against it, not to replace it. The
rig drives a real 68000 through a real ring and is the measurement; this is the
cheap sweep that says where to point it. Where they disagree, the rig wins.
python3 tools/analysis/20_seek_slack.py [container ...] --kbps R [R ...]
[--ring KB [KB ...]]
`--kbps` is REQUIRED and takes no default, for the reason FINDINGS 50 gives.
"""
import sys, os, argparse
sys.path.insert(0, "tools/encoder")
import numpy as np
from dlx import DLX
import ratectl as RC
SECTOR = 512
def records(path):
d = DLX(path)
rec = np.array([4 + n + (-(4 + n) % 4) for _, n in d.frames], np.int64)
return d, rec
def paced_sim(rec, ring, fill_per_frame, ticks_per_frame=8):
"""Paced-decoder ring sim. Returns TWO per-tick lookahead series.
THE ANSWER IS BRACKETED TO ONE RECORD AND IS NOT SHARPER THAN THAT. At
these rates the pipe delivers almost exactly one record per frame slot, so
"how many records are resident at slot i" depends on whether you look before
or after that slot's delivery -- and the two answers differ by one, every
time. Sampled after, this agreed with the rig's ceiling in 33 of 35 cells;
sampled before, it was exactly one record lower in 33 of 35. Neither is
wrong. Picking the one that matched would have been fitting the model to
the measurement and then reporting the agreement as a cross-check, so both
are returned and the caller prints the range. The rig sits at the top of it.
The producer is `aligned` (19_ring_stream.py): it will not start a record it
cannot finish before the end of the ring, and it will not place one over
bytes the decoder still owns. The decoder consumes exactly one record per
frame time and releases it whole.
Sub-stepping matters. Delivery and consumption interleave inside a frame
time on the rig -- the producer runs on MAME's machine-frame notifier, ~5x
per 12fps slot -- and a model that delivers a whole frame's bytes at once
can place a record into space the decoder has not released yet, or refuse
one it has. Eight sub-steps is well past the point the answer stops moving.
"""
n = len(rec)
live = [] # [idx, off, len] still owned by the decoder
wcur, nsent, credit = 0, 0, 0.0
lo, hi, ring_ref, rate_ref = [], [], 0, 0
def overlaps(off, ln):
return any(off < r[1] + r[2] and r[1] < off + ln for r in live)
for i in range(n):
if nsent < n:
lo.append(sum(1 for r in live if r[0] >= i))
for _ in range(ticks_per_frame):
credit += fill_per_frame / ticks_per_frame
while nsent < n:
r = int(rec[nsent])
if credit < r:
rate_ref += 1
break
w, hole = wcur, 0
if w + r > ring:
w, hole = 0, ring - wcur
if overlaps(w, r):
ring_ref += 1
break
# sector quantisation: a partial sector is not resident
credit -= r
live.append([nsent, w, r])
wcur, nsent = w + r, nsent + 1
if nsent < n:
hi.append(sum(1 for r in live if r[0] >= i))
# the decoder consumed record i during the slot and releases it whole
live = [r for r in live if r[0] > i]
return np.array(lo), np.array(hi), ring_ref, rate_ref
def main():
ap = argparse.ArgumentParser()
ap.add_argument("containers", nargs="*",
default=["tmp/rc_fr_singe_scsi_span.dlx"])
ap.add_argument("--kbps", type=float, nargs="+", required=True,
help="delivered pipe rates, KB/s. REQUIRED, no default "
"(FINDINGS 50): this project has never measured the "
"delivery pipe and a default is how the last unmeasured "
"one stayed load-bearing for five sessions.")
ap.add_argument("--ring", type=float, nargs="+",
default=[64, 96, 128, 192, 256, 384, 512])
a = ap.parse_args()
FPS = 12
for path in a.containers:
if not os.path.exists(path):
print(f"{path}: MISSING -- skipped\n"); continue
d, rec = records(path)
wire = rec.mean() * FPS / 1024 + RC.AUDIO_KBPS
print(f"=== {path}: {d.nframes} frames @ {d.fps}fps, mean record "
f"{rec.mean()/1024:.1f} KB, wire {wire:.1f} KB/s")
print(f"{'ring KB':>8} {'pipe':>8} {'ceiling':>9} {'build s':>8} "
f"{'mean':>11} bound")
for ring_kb in a.ring:
ring = int(ring_kb * 1024)
if rec.max() > ring:
print(f"{ring_kb:>8.0f} maxrec {rec.max():,} does not fit")
continue
for kbps in a.kbps:
fill = ((kbps - RC.AUDIO_KBPS) * 1024 / FPS) if kbps > 0 else 1e12
lo, hi, ring_ref, rate_ref = paced_sim(rec, ring, fill)
c_lo, c_hi = int(lo.max()), int(hi.max())
build = int(np.argmax(hi >= c_hi)) if len(hi) else -1
print(f"{ring_kb:>8.0f} {kbps:>8.0f} "
f"{f'{c_lo}-{c_hi}':>9} {build/FPS:>8.2f} "
f"{f'{lo.mean():.1f}-{hi.mean():.1f}':>11} "
f"{'ring' if ring_ref else 'rate'}")
# The surplus model, stated so it can be checked against the sweep
# above rather than believed: slack accrues at (pipe - wire) and a
# full ring holds `ceiling` records, so a branch point costs about
# ceiling*mean_record/(pipe - wire) seconds of play to earn back.
print()
print("Slack is accumulated, not owned. A bigger ring raises the ceiling AND")
print("lengthens the climb to it: the surplus (pipe - wire) is what fills it,")
print("and that is set by the encoder and the medium, not by the buffer.")
if __name__ == "__main__":
main()