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

Pace the ring, then read the DMAC config out of the IPL ROM: audio is cheap and the disk is not

Browse Source 
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
This commit is contained in:
prosolis
2026-08-24 18:14:01 -07:00
parent b49bbdc939
commit 2f9f5cc995
49 changed files with 6276 additions and 375 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tools/analysis/21_iplrom_dmac.py
+255
View File
@@ -0,0 +1,255 @@
#!/usr/bin/env python3
"""What the X68000's own ROM programs into the DMAC -- read out of the bytes.
python3 tools/analysis/21_iplrom_dmac.py [iplrom.dat]
FINDINGS 48.4 / ROADMAP B3 left the single-address vs dual-address question
open for the disk, priced it at 242 KB/s and 0.69 dB, and blocked it on
sourcing `scsiexrom.bin` so its DMAC init could be disassembled. The same
question was open for AUDIO and nobody had asked it: ROADMAP P6 budgets ADPCM
at 7.8 KB/s and `11_cpu_budget.py` charges those bytes the DISK's per-byte
rate, which is a guess about a channel whose configuration was never read.
It does not have to be a guess. **The IPL ROM is on this machine** -- MAME runs
the player rig with `-bios ipl10` -- and it programs all four HD63450 channels
itself. This script reads the configuration straight out of the ROM image and
decodes the MC68450 register fields, so every claim below is a byte at a named
address rather than a recollection about a chip.
It is a GATE, not a report: each piece of evidence is (address, expected bytes,
what it means), and a mismatch exits non-zero. If a different ROM revision is
pointed at it, it says so instead of quietly decoding something else.
SOURCED for the field layouts: MC68450 Direct Memory Access Controller,
Motorola, Jul 1989 (bitsavers) -- the same document FINDINGS 39 already cites
for the transfer timings in tools/analysis/buscost.py.
NOTE THE LAYER: this is the ROM's own choice of configuration, read from the
shipping image. It is not a measurement of a running machine, and it is not
proof that a different configuration is impossible -- our player programs these
registers itself. It is evidence about what Sharp's engineers could get the
board to do, from the vendor, for these exact devices.
"""
import sys, os, argparse, hashlib
BASE = 0xFE0000 # where the IPL ROM is mapped (and its 0xFF0000 alias)
# The image this was decoded against. A different revision is a different
# machine's answer, so it is named rather than assumed.
KNOWN = {
"7fd4caabac1d9169e289f0f7bbf71d8e":
"IPL 1.0 (MAME x68000 -bios ipl10), 131,072 B",
}
# --- MC68450 register map, by offset inside a channel's 0x40 block ----------
REG = {0x00: "CSR", 0x01: "CER", 0x04: "DCR", 0x05: "OCR", 0x06: "SCR",
0x07: "CCR", 0x0A: "MTC", 0x0C: "MAR", 0x14: "DAR", 0x1A: "BTC",
0x1C: "BAR", 0x25: "NIV", 0x27: "EIV", 0x29: "MFC", 0x2D: "CPR",
0x31: "DFC", 0x39: "BFC"}
XRM = {0: "burst",
1: "UNDEFINED",
2: "cycle steal WITHOUT hold (bus released between operands)",
3: "cycle steal with hold"}
DTYP = {0: "68000-compatible, EXPLICITLY addressed -> DUAL ADDRESS",
1: "6800-compatible, EXPLICITLY addressed -> DUAL ADDRESS",
2: "device with ACK, implicitly addressed -> SINGLE ADDRESS",
3: "device with ACK and RDY, implicit -> SINGLE ADDRESS"}
DPS = {0: "8-bit port", 1: "16-bit port"}
PCL = {0: "status input", 1: "status input with interrupt",
2: "start pulse", 3: "abort input"}
SIZE = {0: "byte", 1: "word", 2: "long word", 3: "byte, unpacked"}
CHAIN= {0: "none", 1: "UNDEFINED", 2: "array", 3: "linked array"}
REQG = {0: "auto-request at limited rate", 1: "auto-request at max rate",
2: "EXTERNAL request (one operand per device request)",
3: "auto-request first operand, external thereafter"}
def dcr(v):
return [f"XRM = {v>>6&3:02b} {XRM[v>>6&3]}",
f"DTYP = {v>>4&3:02b} {DTYP[v>>4&3]}",
f"DPS = {v>>3&1:b} {DPS[v>>3&1]}",
f"PCL = {v&3:02b} {PCL[v&3]}"]
def ocr(v):
return [f"DIR = {v>>7&1:b} " +
("device -> memory (read)" if v & 0x80 else "memory -> device (write)"),
f"SIZE = {v>>4&3:02b} {SIZE[v>>4&3]}",
f"CHAIN= {v>>2&3:02b} {CHAIN[v>>2&3]}",
f"REQG = {v&3:02b} {REQG[v&3]}"]
def scr(v):
m = {0: "no count", 1: "increment", 2: "decrement", 3: "UNDEFINED"}
return [f"MAC = {v>>2&3:02b} memory address {m[v>>2&3]}",
f"DAC = {v&3:02b} device address {m[v&3]}"]
# --- the evidence ----------------------------------------------------------
# (address, expected bytes, one-line description). Every register value quoted
# anywhere below comes out of one of these; nothing is typed in twice.
EV = [
(0xFF0BEA, "49f900e84080197c00080004197c0005",
"boot: lea $E84080,a4 (ch2) ; DCR=$08 ; SCR=$05..."),
(0xFF0C2E, "49f900e840c0197c00800004197c00040006197c00050029197c0001002d"
"197c00050031197c00050039297c00e92003",
"boot: lea $E840C0,a4 (ch3, ADPCM) ; DCR=$80 SCR=$04 MFC=$05 CPR=$01 "
"DFC=$05 BFC=$05 DAR=$E92003"),
(0xFF0D8E, "0480060429052d0031054480460469056d027105",
"boot: the ch0/ch1 init TABLE, ten (offset,value) pairs, written by the "
"loop at $FF0CD8"),
(0xFF0CE4, "217c00e940030014217c00e960010054",
"boot: DAR ch0 = $E94003 (FDC data) ; DAR ch1 = $E96001 (SASI data)"),
(0xFF9A82, "13fc003200e840c5610a13fc000200e920014e75",
"IOCS ADPCM PLAY: OCR(ch3) = $32 ; then command $02 to $E92001"),
(0xFF9A5E, "13fc00b200e840c5612e13fc000400e920014e75",
"IOCS ADPCM RECORD: OCR(ch3) = $B2 ; then command $04 to $E92001"),
(0xFF9A96, "13fc00ff00e840c023c900e840cc33c200e840ca",
"IOCS ADPCM arm: CSR=$FF ; MAR = a1 ; MTC = d2 (DCR/SCR untouched)"),
(0xFF9944, "13fc00ff00e8404013fc00b200e84045601013fc00ff00e8404013fc003200"
"e8404523c900e8404c33c300e8404a13fc008000e840474e75",
"IOCS SASI: OCR(ch1) = $B2 read / $32 write ; MAR ; MTC ; CCR = $80"),
]
ap = argparse.ArgumentParser()
ap.add_argument("rom", nargs="?",
default=os.path.expanduser("~/mame/roms/iplrom.dat"))
a = ap.parse_args()
if not os.path.exists(a.rom):
sys.exit(f"missing {a.rom} -- point this at the IPL ROM MAME boots the rig "
f"with (-bios ipl10).")
d = open(a.rom, "rb").read()
md5 = hashlib.md5(d).hexdigest()
print(f"{a.rom}: {len(d):,} B, md5 {md5}")
if md5 in KNOWN:
print(f" {KNOWN[md5]}\n")
else:
sys.exit(f"\nUNKNOWN ROM. Every field decoded below was read out of\n"
f" {list(KNOWN.values())[0]}\n"
f"and a different revision is a different machine's answer, not a "
f"detail. Add its\nmd5 to KNOWN only after re-reading the sites -- "
f"the addresses are revision-specific.")
print("EVIDENCE -- each line is bytes at an address, not a recollection")
bad = 0
for addr, hx, what in EV:
want = bytes.fromhex(hx)
got = d[addr - BASE: addr - BASE + len(want)]
ok = got == want
bad += not ok
print(f" {'OK ' if ok else 'FAIL'} ${addr:06X} {what}")
if not ok:
print(f" expected {want.hex()}\n got {got.hex()}")
if bad:
sys.exit(f"\nFAIL: {bad} evidence site(s) do not hold. The decode below "
"would be about\nsome other code, so it is not printed.")
# The ch0/ch1 table, decoded from the bytes rather than restated.
tbl = d[0xFF0D8E - BASE: 0xFF0D8E - BASE + 20]
init = {}
for i in range(0, len(tbl), 2):
off, val = tbl[i], tbl[i + 1]
init[(off >> 6, off & 0x3F)] = val
init[(2, 0x04)] = 0x08 # from the inline moves at $FF0BEA
init[(2, 0x06)] = 0x05
init[(2, 0x2D)] = 0x03
init[(3, 0x04)] = 0x80 # ...and at $FF0C2E
init[(3, 0x06)] = 0x04
init[(3, 0x2D)] = 0x01
DEV = {0: ("FDC", "$E94003"), 1: ("SASI", "$E96001"),
2: ("IOCS _DMAMOVE (general purpose)", "set per call"),
3: ("ADPCM MSM6258V", "$E92003")}
print("\nWHAT THE ROM PROGRAMS, per channel")
for ch in range(4):
name, dar = DEV[ch]
print(f"\n ch{ch} base $E840{ch*0x40:02X} {name} DAR = {dar}")
v = init[(ch, 0x04)]
print(f" DCR = ${v:02X}")
for line in dcr(v):
print(f" {line}")
v = init[(ch, 0x06)]
print(f" SCR = ${v:02X} " + " ; ".join(scr(v)))
print(f" CPR = ${init[(ch,0x2D)]:02X} channel priority "
f"({init[(ch,0x2D)]}, 0 = highest)")
print("\nAND THE PER-TRANSFER OCR, written every time a transfer is armed")
for label, ch, v in (("ADPCM playback", 3, 0x32), ("ADPCM record", 3, 0xB2),
("SASI write", 1, 0x32), ("SASI read", 1, 0xB2)):
print(f"\n {label:<15} ch{ch} OCR = ${v:02X}")
for line in ocr(v):
print(f" {line}")
print(f"""
WHAT THIS SETTLES
1. AUDIO IS DUAL ADDRESS, AND IT CANNOT HOLD THE BUS. ch3 DCR = $80: DTYP =
00, explicitly addressed, so every ADPCM byte is a MEMORY READ FOLLOWED BY A
DEVICE WRITE -- not the single-address 5 clocks the disk debit is written in.
XRM = 10 is cycle steal WITHOUT hold and OCR REQG = 10 is external request,
so the DMAC arbitrates for the bus ONCE PER BYTE and gives it straight back.
There is no burst to amortise the arbitration over.
2. THE PORT IS 8 BITS AND THE OPERAND IS A BYTE. DCR DPS = 0, OCR SIZE = 11.
One MSM6258V byte is two 4-bit samples, so 15.6 kHz is 7,812.5 BYTES/s and
7,812.5 DMA REQUESTS/s -- the request count does not halve the way a 16-bit
port's would. That is the FINDINGS 43 unit trap, in the other stream.
3. THE DISK CHANNEL IS PROGRAMMED IDENTICALLY, AND THAT IS THE BIGGER NEWS.
ch1 (SASI, DAR = $E96001) gets DCR = $80 and OCR = $B2 -- dual address,
8-bit port, cycle steal WITHOUT hold, external request. Byte by byte, with a
full arbitration each time, exactly like the audio. ch0 (FDC) too. Sharp
programs every explicitly-addressed 8-bit device on this board the same way.
This is not scsiexrom.bin and it does not close ROADMAP B3 -- a different
ROM drives a different SPC. But it is the same vendor, the same DMAC and the
same class of device, and it lands on the EXPENSIVE side of B3's 242 KB/s.
4. AND IT IS OUTSIDE THE BRACKET THE PROJECT HAS BEEN COSTING P4 IN.
FINDINGS 42.4-42.6 brackets W, the clocks stolen per delivered byte, at
5..12, and reports that W <= 6 fits 0/120 frames while W = 8 misses 47/120.
The ROM's own disk configuration costs 16..19. It is still true that the
player programs these registers itself and the choice is ours (42.6) -- but
the only worked example on the machine sits ABOVE the whole bracket, and
nothing in this tree has yet shown that a cheaper configuration is reachable
for an explicitly-addressed port. Treat W <= 12 as a REQUIREMENT ON THE
PLAYER'S DMAC PROGRAMMING, not as a range the hardware hands us.
5. AUDIO OUTRANKS THE DISK AT THE ARBITER. CPR: FDC 0, ADPCM 1, SASI 2,
_DMAMOVE 3, lower being higher priority. When both channels want the bus in
the same slot, the ROM's arrangement serves ADPCM first. An audio byte is
never the thing that waits; a video byte is.
""")
# --- what it costs ---------------------------------------------------------
sys.path.insert(0, os.path.dirname(os.path.abspath(__file__)))
import buscost as B
ADPCM_HZ = 15625.0 # 8 MHz MSM6258V clock / 512
ADPCM_BPS = ADPCM_HZ / 2 # 4-bit samples, two to a byte
FPS, CPUHZ = 12.0, 10e6
lo = B.DMA_DUAL_BYTE_CLK + B.DMA_FRONT_CLK + B.DMA_BACK_CLK
hi = B.DMA_DUAL_BYTE_CLK + B.DMA_FRONT_CLK_WORST + B.DMA_BACK_CLK
bpf = ADPCM_BPS / FPS
print(f"WHAT IT COSTS, at the configuration above\n"
f" 15.6 kHz mono = {ADPCM_HZ:,.0f} samples/s = {ADPCM_BPS:,.1f} B/s "
f"= {ADPCM_BPS/1024:.2f} KiB/s\n"
f" (ratectl.AUDIO_KBPS is 7.8, which is this figure in DECIMAL kB; "
f"as KiB it is {ADPCM_BPS/1024:.2f})\n"
f" dual-address byte transfer {B.DMA_DUAL_BYTE_CLK} clk "
f"(read {B.DMA_READ_CLK} + write {B.DMA_WRITE_CLK}, Fig 4-25 sheet 4 note 2)\n"
f" + arbitration, EVERY byte {B.DMA_FRONT_CLK}..{B.DMA_FRONT_CLK_WORST}"
f" front + {B.DMA_BACK_CLK} back (sect 4.5.2.1/4.5.2.2)\n"
f" = {lo}..{hi} clocks per audio byte\n\n"
f" per frame at {FPS:g} fps: {bpf:,.1f} B costs {bpf*lo:,.0f}..{bpf*hi:,.0f} "
f"clocks of {CPUHZ/FPS:,.0f}\n"
f" = {100*bpf*lo/(CPUHZ/FPS):.2f}%..{100*bpf*hi/(CPUHZ/FPS):.2f}% of the "
f"frame, stolen from the 68000\n\n"
f" 11_cpu_budget.py charges audio --dma-clocks-per-byte, default 5, "
f"described\n as 'single-address, bus held, no drive wait'. The ROM says "
f"audio is neither\n single-address nor able to hold the bus, so that "
f"debit is {lo/5:.1f}x..{hi/5:.1f}x too small.\n"
f" In absolute terms it is small -- but it is small IN THE RESOURCE THE "
f"PROJECT IS\n SHORT OF, and it was being taken from the wrong side of "
f"an open question.")