prosolis
c5ca56330e
Three things, and the last one reversed itself when the datasheet arrived.
A SECOND EMULATOR. tools/bench/c68k/ links px68k's C68K core into a headless
harness -- no SDL, no ROMs, no emulated machine, because the decoder touches
nothing but RAM, the control block and GVRAM. decode.s is now pixel-exact under
two independent CPU cores, and cycle-table error against MAME is bounded at
3.3%, running against us. MAME 0.277's M68000 turns out to be the MICROCODE
core, not Musashi (m68000.lst + m68000gen.py), so this is two structurally
different timing models agreeing rather than two tables. FINDINGS 28.8's "V4
costs more than RAW" reproduces independently. FINDINGS 37.
THE BUS. Nothing since FINDINGS 24 had counted the 68000's local memory bus --
one 4-clock cycle at a time, carrying instruction prefetch as well as data. The
decoder occupies 86.7% of it and PREFETCH IS 62% OF THAT TRAFFIC, so a data-only
count understates occupancy by 2x. Two sources check each other: c68k_bench
counts every bus callback exactly, and a static walk of decode.lst supplies the
prefetch no emulator here can report. The walk reproduces the measured data half
to 0.04%, which is what licenses its prefetch half, and 15_bus_occupancy.py is a
gate rather than a report because every bus figure depends on that check.
FINDINGS 38.
THE DMAC CHAIN LOSES. FINDINGS 29.6 named it the one uncosted lever. Costed from
bus arithmetic -- a read cycle plus a write cycle, 8 clocks a pixel -- it scored
1/120 frames over budget against the v6 span's 10/120 and looked decisive. Then
the MC68450 manual (Motorola Jul 1989, now at ~/src/mc68450.pdf): Fig 4-25 sheet
4 puts a dual-address word between two 16-bit ports at 9 CLOCKS, because note 2
gives the DMAC 4-clock reads and 5-clock WRITES. The 68000 writes in 4.
DMAC 9.000 clocks/pixel datasheet
v6 9.152 clocks/pixel measured, FINDINGS 30
1.7%. Scored additively, 86% of what remains of the DMAC's advantage is v6's
24-pixel padding quantum -- a property of its unrolled movem chain, fixable in
software with a finer tail chain, worth 55/120 -> 18/120 against the DMAC's
12/120. Recommendation: fix the quantum, drop the DMAC. Six frames does not buy
a reserved channel, a two-region container layout and a timing dependency
neither emulator here can verify. The container is identical either way -- v6's
record and an HD63450 chaining entry are both 6 bytes, so the chain array IS the
span table -- so nothing is foreclosed. FINDINGS 39.
TWO CORRECTIONS TO MY OWN WORK IN THE SAME SESSION:
- I argued FINDINGS 35's flat CPU debit for the disk was too pessimistic and
rescored the window at 53/120 with max(CPU, bus). Wrong. A 68000 has no cache
and a two-word prefetch queue, so it stalls the moment another master takes
the bus, and the MC68450 hands the bus over in SLABS under limited-rate
auto-request rather than interleaving per operand. DMA is additive. 84/120
stands and 14_dmac_chain.py reproduces it exactly. What 86.7% occupancy really
says is that there is almost no room to overlap anything. FINDINGS 38.3.
- The first DMAC costing was derived where a primary source existed. Both wrong
answers were confident and both were caught by reading the manual.
Also landed:
- FINDINGS 5's 8 clocks/word for the SCSI DMA, STATUS's own "most load-bearing
unmeasured number", is now bracketed by the datasheet: 5 clk/word with the bus
held, ~12 if the DMAC arbitrates per word. 8 is a supported midpoint, and
which end applies is a player design decision worth 7 clocks a word on a
480 KB/s stream. FINDINGS 39.7.
- check.sh gains two gates: the C68K pixel-exact decode (seconds, no MAME) and
the bus-model self-check. Both skip cleanly without a px68k checkout.
- spanned blocks are now charged their mode-map dispatch, which FINDINGS 30.7
flagged as uncounted in 12_span_tradeoff.py.
- MAME timed runs must be budgeted by WALL CLOCK, not -seconds_to_run: this box
runs x68000 at ~0.033x realtime and two runs were killed by their own timeout.
That is why the all-RAW cell in 37.3 is empty. The C68K harness does the same
work in seconds because it emulates a CPU and not a machine.
Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6
133 lines
7.5 KiB
Markdown
133 lines
7.5 KiB
Markdown
# Dragon's Lair — Sharp X68000 port
|
|
|
|
Porting Dragon's Lair to a stock X68000 (68000 @ 10MHz, 2MB, 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.
|
|
|
|
**And the binding resource is the 68000's local BUS, not its clock.** The
|
|
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.
|
|
|
|
**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.
|
|
14 prices the HD63450 array-chain against the v6 span
|
|
(FINDINGS 39) and prints the sensitivity that decides it;
|
|
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.
|
|
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/bench/c68k/ headless px68k C68K harness -- a SECOND emulator for every
|
|
68000 cycle figure (FINDINGS 37). Links only px68k's CPU core:
|
|
no SDL, no ROMs, no emulated machine. `make PX68K=~/src/px68k`
|
|
then `run.sh`; `verify_c68k.py` checks the decode is
|
|
pixel-exact, which is what licenses the cycle numbers. It also
|
|
counts BUS cycles, which MAME cannot report.
|
|
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).
|
|
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.
|
|
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 scsi --preview p.png
|
|
```
|
|
|
|
**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).
|
|
The rate point may return under another name once the delivery medium is
|
|
settled, because a 1x CD-ROM sustains ~150 KB/s and CD-ROM is the only period
|
|
medium with the capacity.
|
|
|
|
The profile bitrate is a **ceiling**: 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.62 dB at `scsi` (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.
|