2 Commits

Include renames

Author	SHA1	Message	Date
prosolis	b49bbdc939	Build v7 into the player, and find the cost model 18% wrong on the block it made commonest ... 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	2026-08-23 20:02:03 -07:00
prosolis	c5ca56330e	A second emulator agrees, the bus was never counted, and the DMAC loses by one clock ... 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	2026-08-23 18:30:23 -07:00