drwily/Dragon-s-Lair-X68k
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Build v7 into the player, and find the cost model 18% wrong on the block it made commonest

Browse Source 
src/player/decode.s now paints v7 literal spans, pixel-exact under MAME and
px68k's C68K core over a container where every frame carries 128-216 spans
covering up to 38% of the picture. The span pass is blit.s v7 verbatim: the
66.0/9.143/9.978 fit was measured on that instruction sequence.

The container is DLX3 -- a span section between the mode header and the block
payload, since that is the only place the 68000 can reach without first parsing
something of variable length. 16_span_roundtrip.py gates it in check.sh, and
asserts it emitted enough spans to have tested anything.

Two synthetic all-SPAN anchors price v7 inside decode.s at 151.2 and 225.6
clocks per 4x4 block, against FINDINGS 40's table of 151 and 226 -- 0.2% on
both emulators. The measured mode costs what it was said to cost.

Two things that were not on the list:

TWO BYTE BUDGETS. FINDINGS 40's 18/120 was scored against the 488 KB/s PIPE,
not the 280 KB/s profile, and at the profile rate the lam search has already
spent the allowance -- spans fired on 5 frames of 120 and looked like a
regression. The profile is a chosen quality rate point; the pipe is hardware.
--kbps and --span-kbps are now separate and spans run before mu, because a span
pays in bytes and mu pays in picture. Delivered: 86/120 over budget without
spans, 77/120 at the profile budget, 34/120 on the pipe for +0.36 dB.

C_SKIP_MIXED WAS NEVER MEASURED, and it was 18% low -- 45.0, now 55.0. It is
the one constant in the table that came from a derivation, because the
synthetic frame that would measure it cannot exist: a byte needs a coded block
for its SKIP to be mixed. Four bracketing anchors measure it on both emulators
with the header byte rotated through all four positions, and the partner mode
solves back to its own anchored value to 0.2%. With it corrected the model
predicts a real spanned decode to -0.06% mean / 0.09% worst, against -2.99% /
4.30%. It matters because a span marks its run SKIP, so mixed SKIPs dominate
exactly the frames spans are judged on.

Also: the rig had been writing its synthetic timing frames 26 KB past the top
of a 2 MB machine, and got away with it because the modes it overran are
data-independent. A span's jump displacements come out of the stream, so it is
not. And frames-over-budget is no longer a safe headline -- the controller aims
at the deadline, so 55 of 120 frames sit within 5% of it and a 1% cost shift
moves 22 frames.

FINDINGS 41. check.sh ALL GREEN, now gating on a span-heavy DLX3 container.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6
This commit is contained in:
prosolis
2026-08-23 20:02:03 -07:00
parent c520a89e14
commit b49bbdc939
16 changed files with 1342 additions and 203 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+35 -8
View File
@@ -11,9 +11,15 @@ decoder occupies 86.7% of it once instruction prefetch is counted, and 52 of the
53 frames that miss the 12fps budget miss it on the bus, not the CPU
(FINDINGS 38). Read that before optimising anything for cycles.
The largest measured win on the table is the **literal span with a fine tail**
(`blit.s` v7): it takes the worst `scsi` window from 84/120 frames over budget
to 18/120, and `src/player/decode.s` does not implement it yet (FINDINGS 40).
The **literal span with a fine tail** (v7) is now IN the player: `decode.s`
paints it, pixel-exact under both CPU cores, and it costs inside the decoder
what `blit.s` said it would to 0.2% (FINDINGS 41).
**It only pays if the stream is allowed to run near the pipe.** Spans buy the
68000's deadline with bytes, and at the 280 KB/s profile the mode decision has
already spent them: 77/120 frames over budget against 86 without spans. Given
the full 488 KB/s pipe it is **34/120, and 0.36 dB better** — so the next
decision is a rate point, not an optimisation (FINDINGS 41.2, docs/STATUS.md).
**Green-light check:** `./tools/bench/check.sh` (~3 min, needs the Blu-ray
mounted) re-runs both display regression tests, the rate-control drift test, the
@@ -58,7 +64,15 @@ tools/analysis/ measurement scripts, numbered in the order they were written
15 measures how much of the 68000's LOCAL bus the decoder
occupies (FINDINGS 38) and exits non-zero if its derived
model stops matching the harness's measurement.
buscost.py is the shared bus-cycle table both import.
16 is the DLX3 span container ROUND-TRIP gate (part of
check.sh): it encodes, writes the container, reads it back with
the reference decoder and fails if a pixel differs -- or if it
emitted too few spans to have tested anything. 17 prices the
spans the encoder ACTUALLY emitted, with no selection model,
which is what 12 and 14 could only simulate.
buscost.py is the shared bus-cycle table both import; the
per-BLOCK constants live in tools/encoder/vq_hybrid.py and are
imported, never copied (session 12 corrected one of them).
tools/bench/ MAME Lua injection harness + 68000 benchmark sources.
`check.sh` re-runs both display regression tests (~40 s).
`blit.s`/`blit.lua` time the full-frame GVRAM blit on the
@@ -85,13 +99,19 @@ tools/bench/c68k/ headless px68k C68K harness -- a SECOND emulator for every
The Makefile's -no-pie and the harness's MAP_32BIT arena are
load-bearing: C68K truncates host pointers to 32 bits.
tools/vasm/ vasm m68k assembler (built from source)
tools/encoder/ hybrid VQ encoder + DLX2 container writer (working).
tools/encoder/ hybrid VQ encoder + DLX3 container writer (working).
spans.py is the v7 span geometry, selection and serialiser, and
the single place the chain layout is stated on the encoder side
-- it must match blit.s/decode.s (11 coarse units of 24 px, 11
fine of 2).
DLX2 4-byte-aligns every frame record: an odd `move.l` is an
ADDRESS ERROR on a 68000, not a slow read (FINDINGS 28.3).
dlx.py is the reference DECODER -- ground truth for the 68000.
src/player/ decode.s: the 68000 DLX decoder. Pixel-exact; 1 frame of 120
over the 12fps CPU budget once the mode decision prices
cycles. See FINDINGS 28 and 31.
src/player/ decode.s: the 68000 DLX3 decoder. Pixel-exact under MAME and
px68k's C68K core, blocks and v7 literal spans both. The span
pass is blit.s v7 verbatim -- the same instruction sequence the
66.0/9.143/9.978 fit was measured on, so do not tidy it.
See FINDINGS 28, 31, 40 and 41.
assets/ extracted frames/audio (gitignored)
```
@@ -102,6 +122,13 @@ python3 tools/encoder/extract.py 00020 /tmp/fr 12 crop
python3 tools/encoder/encode.py /tmp/fr out.dlx --profile scsi --preview p.png
```
**Two budgets, not one.** `--kbps` is the quality rate point and `--span-kbps`
is the ceiling the span pass may draw on. They are different things: the profile
is chosen, the pipe is hardware, and bytes between them buy a better picture if
spent on `lam`, the 68000's deadline if spent on spans, and nothing if left
unspent. Spans run before `mu` because a span pays in bytes and `mu` pays in
picture (FINDINGS 41.2).
**One profile: `scsi`, 280 KB/s.** The 110 KB/s `sasi` profile was dropped in
session 9 on capacity, not bandwidth — a SASI volume is limited to 40 MB, and
the game's 22.8 minutes of footage is 146 MiB even at that rate (FINDINGS 32).