prosolis
06b98d4b47
The decoder has been CPU-bound since FINDINGS 28 while the mode decision
minimised D + lam*R -- distortion against BYTES. decide() now minimises
D + lam*bytes + mu*cycles, and ratectl bisects mu per frame against the
833,333-cycle budget with the lam bisection nested inside it. On the worst
sustained window:
sasi 27.22 -> 26.95 dB, 109.5 -> 109.4 KB/s, 37/120 misses -> 1
scsi 29.90 -> 29.27 dB, 280.0 -> 278.6 KB/s, 51/120 misses -> 1
Bitrate does not move: the byte controller still binds, and mu changes WHICH
modes are bought. V4 is what it stops buying -- 25.2 -> 20.3% of blocks at sasi
and 15.0 -> 5.3% at scsi, where RAW takes it. That is 28.8's inversion in
practice: RAW is dearer in bytes and cheaper in cycles, so only the byte-rich
profile can buy its way out of V4.
Three things worth knowing beyond the headline:
- The one frame that still misses, at both profiles, is FRAME 0 -- no previous
reconstruction, so 100% changed by definition, which is also what a scene
cut is. It comes out at the all-V1 floor of 110.6% and is emitted late on
purpose. Freezing a cut to make a deadline is the worse failure.
- 28.7's "11 frames are impossible" was too pessimistic. That floor held the
SKIP set fixed and asked how cheaply the drawn blocks could be drawn; the
real decision can also MOVE a block to SKIP, which above ~90% non-SKIP is
the only lever left.
- SKIP's price depends on its neighbours (13.25 cycles clustered, 45 mixed),
which a per-block lagrangian cannot see. The way out is that the two uses
need not share a cost function: a ranking constant inside decide(), the
exact clustered rule for the frame-level bisection. vq_hybrid.cycles() is
now the one definition of that rule and 11_cpu_budget.py imports it.
Gated: 09_ratectl_drift.py runs both controllers, both 0/120 drifting frames.
The cost-aware container decodes pixel-exact on the 68000 (120 frames). ON by
default in encode.py; --no-cpu-fit restores session 7. check.sh ALL GREEN.
Still a model, not a measurement, for THIS container: FINDINGS 31's cycle
figures come from vq_hybrid.cycles (within 1 point of the 68000 on four frames
of the session-7 container). Timing this one on the machine is step 1 of the
next session -- it was started and killed for time, and it is slow.
FINDINGS 31. tools/analysis/13_cpu_ratectl.py.
Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6
105 lines
5.7 KiB
Markdown
105 lines
5.7 KiB
Markdown
# Dragon's Lair — Sharp X68000 port
|
|
|
|
Porting Dragon's Lair to a stock X68000 (68000 @ 10MHz, 2MB, SASI/SCSI).
|
|
|
|
This is fundamentally a **video codec problem**, not a game-logic problem: the
|
|
game logic is a scene table with branching input windows; the difficulty is
|
|
pushing ~22 minutes of Don Bluth animation through a 10MHz 68000.
|
|
|
|
**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
|
|
display-path coherency counterexample and a 120-frame 68000 decode, then prints
|
|
`ALL GREEN`.
|
|
|
|
## Read first
|
|
- **`docs/FINDINGS.md`** — measured hardware facts, content statistics, codec
|
|
decision, and a section on measurement traps that produced three separate
|
|
false results. Read §4 before trusting any pipeline number.
|
|
- **`docs/STATUS.md`** — current state, working setup, blockers, next steps.
|
|
**Start here.** It also lists what has been explicitly abandoned, so old ideas
|
|
do not get re-proposed.
|
|
- **`docs/BENCHMARK.md`** — how to measure the storage subsystem, and why a
|
|
bandwidth figure out of MAME would be meaningless.
|
|
- **`docs/HARDWARE.md`** — X68000 GVRAM/CRTC reference.
|
|
|
|
## Layout
|
|
```
|
|
docs/ findings, status, hardware reference
|
|
tools/analysis/ measurement scripts, numbered in the order they were written
|
|
(01/02 marked BROKEN deliberately, kept as regression refs).
|
|
Run from the repo root — they import from tools/encoder/.
|
|
07 finds the hottest sustained window in a stream; 08 renders
|
|
source | decoded | block-mode map as .webm; 09 is the
|
|
rate-control drift gate (FINDINGS 26/27) and is part of
|
|
check.sh -- it exits non-zero if the encoder ever again
|
|
reports a reconstruction no decoder would produce.
|
|
10 is a COUNTEREXAMPLE, and exits non-zero by design: it
|
|
demonstrates that the two-display-path plan of FINDINGS
|
|
24.5/25.6 corrupts 70 of 120 frames (FINDINGS 28.1).
|
|
11 scores a container against the MEASURED per-mode block
|
|
costs without needing MAME; 12 prices the literal-span mode of
|
|
FINDINGS 30 against those same mode maps, and prints whether a
|
|
scene cut still fits at 12fps; 13 measures what fitting the
|
|
CPU budget costs in dB (FINDINGS 31) and caches H.build so the
|
|
search loop is seconds, not minutes.
|
|
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
|
|
68000 itself (FINDINGS 24) — not part of check.sh, because
|
|
wall timings would make the green-light check host-sensitive.
|
|
`span.sh` (prep_spans.py + span.lua + blit.s v5/v6) measures
|
|
the literal-span mode the same way (FINDINGS 30, ~25 s); it
|
|
also asserts all 23 timing configs drew a pixel-exact frame.
|
|
`crtc_mode.lua` is the single source of truth for CRTC R00-R08
|
|
and R20 — do not write CRTC values anywhere else.
|
|
`prep_dlx.py`/`decode.lua`/`verify_decode.py` load, time and
|
|
verify `src/player/decode.s`; the verify pass is in check.sh.
|
|
tools/vasm/ vasm m68k assembler (built from source)
|
|
tools/encoder/ hybrid VQ encoder + DLX1 container writer (working).
|
|
dlx.py is the reference DECODER -- ground truth for the 68000.
|
|
src/player/ decode.s: the 68000 DLX1 decoder. Pixel-exact, and 31% of
|
|
frames over the 12fps CPU budget. See FINDINGS 28.
|
|
assets/ extracted frames/audio (gitignored)
|
|
```
|
|
|
|
## Encoder
|
|
|
|
```
|
|
python3 tools/encoder/extract.py 00020 /tmp/fr 12 crop
|
|
python3 tools/encoder/encode.py /tmp/fr out.dlx --profile sasi --preview p.png
|
|
```
|
|
|
|
Two quality profiles ship from one codec and one decoder — `sasi` (110 KB/s) and
|
|
`scsi` (280 KB/s) are two points on the same rate-distortion curve. Both are
|
|
**ceilings**: lam is bisected per frame under a leaky bucket, so the profile's
|
|
`lam` is a quality floor rather than a setting (`--fixed-lam` opts out).
|
|
|
|
There are **two** ceilings, on two different axes. The second is the 68000's
|
|
decode budget: `mu` is bisected per frame against 833,333 cycles so the frame
|
|
also *decodes* in time, which takes the worst sustained window from 37 frames
|
|
over budget to 1 for 0.26 dB (FINDINGS 31). It is on by default; `--no-cpu-fit`
|
|
restores session 7 behaviour. Unlike bytes, cycles have no bucket — there is no
|
|
double buffer to decode ahead into, so it is a hard per-frame ceiling. The codec is
|
|
a Cinepak-style hybrid: each 4x4 block is coded as SKIP, one 4x4 codeword, four
|
|
2x2 codewords, or RAW literal pixels, chosen per block by rate-distortion.
|
|
|
|
The RAW escape means `lam=0` is pixel-exact against the palettised frame, so the
|
|
quality knob spans lossless to heavily-compressed without changing the bitstream.
|
|
|
|
Profiles are derived from a bandwidth figure, not chosen by eye:
|
|
|
|
```
|
|
python3 tools/encoder/profile_gen.py --bw-mbps 4 --name scsi
|
|
```
|
|
|
|
> **On reading `docs/FINDINGS.md`:** it is append-only and several later sections
|
|
> overturn earlier ones. Superseded sections carry a blockquote at the top
|
|
> pointing to the correction — heed those, especially 18 (reversed by 21).
|
|
|
|
Source media (`DRAGONS_LAIR.iso`) and ROMs are gitignored — supply your own.
|
|
|
|
**Not every large stream is game footage.** `00216` is the feature with a
|
|
burned-in commentary picture-in-picture and `00215` is the commentary itself —
|
|
the two largest files on the disc. The clean 9.4-minute animation is **`00223`**.
|
|
See FINDINGS 25.1 before running any size-ranked survey.
|