2 Commits

Include renames

Author	SHA1	Message	Date
prosolis	7179339bd2	Move the loader onto the 68000, and find 5,920 bytes nobody counted ... src/player/load.i expands both codebooks to word-per-pixel form and packs the palette to GGGGGRRRRRBBBBBI out of the RAW container header, byte-exact against tools/bench/dlxload.py on both CPU cores. The palette half is gated on words read back out of the palette registers at $E82000, so "the words reached the hardware" is part of what passes. ROADMAP P1 is done; P2's encoder half (a reserved black entry, 23.4) is not, and is a re-encode rather than an edit. A scene change costs 18.96 ms of 68000 time, 22.8% of one 12 fps frame; boot costs 24.70 ms. The scratch tables describe the CRTC, not the scene, so pal_tables is a separate entry point built once at boot -- 5.29 ms off every scene change. The one that moves something: the scene header is 5,920 B that no rate table in this tree included, because it belongs to no frame record. In FINDINGS 51.3's currency it is divided by the surplus pipe - wire, so it is hypersensitive: 138 ms of extra refill climb at 488 KB/s and 1.099 s at 451.4 KB/s, for the same bytes. tools/analysis/22_scene_load.py prices it across explicit rates. Recorded as open: the two CPU cores agree to <3% on every stage but the table build, where they differ by 16.4%. px68k's C68K charges a flat 50 clocks for MULU/MULS (c68kmacro.h:1869) where the 68000 charges 38+2n, which explains 4,608 of the 8,703 clock gap. 4,095 clocks are unexplained. Nothing else in src/player/ multiplies, so no figure in FINDINGS 24-52 is affected. decode.s and stream.s are untouched; decode.bin is still 1,296 B at the same MD5. check.sh gains a stage that gates byte-exactness on both cores and deliberately does not gate the cycle counts -- MAME's clock is 1/55.46 s and a wall timing would make the green light host-sensitive. Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6	2026-08-24 20:20:40 -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