Unify the register-write effect pipeline: slot-referenced write-effect delays for CPU writes#149
Merged
Merged
Conversation
…slot A register write takes effect a fixed number of colour clocks after the chip-bus slot that carried it, and the delay belongs to the register pipeline, not to the bus master: Denise-boundary registers apply about four colour clocks after the slot (DENISE_WRITE_EFFECT_DELAY_CCK), and Agnus's two-cycle class (DMACON, BPLxPT, BPLxMOD, SPRxPT; vAmiga recordRegisterChange DMA_CYCLES(2)) applies two colour clocks after the slot (AGNUS_WRITE_EFFECT_DELAY_CCK). Copper MOVEs execute at their bus slot, so their render events already recorded slot + 4 since the write-landing fix. CPU writes, however, were recorded at the live beam position - which sits past the granted slot by the bus cycle's tail (two colour clocks on the classic bus, less on the 020+ short cycle), leaving CPU Denise-class events two colour clocks early and making the offset CPU-model dependent. The granted slot is now remembered across the access (Bus::cpu_custom_access_slot, transient) and all CPU render events are referenced from it. Two-sided evidence against vAmiga (VAMIGA_CPU_PROBE poke trace vs the granted-slot positions): on vAmigaTS DMACON/sprenacpu1, all 14 scanlines whose dense CPU COLOR00 landings match vAmiga line-for-line rendered exactly two colour clocks left of vAmiga before this change and at zero offset after it, while the copper-driven CIA/TOD latch2 bars hold 0.000% throughout. The Agnus two-cycle class is pinned by the DMACON bplon bitplane-gating bars, which sit two colour clocks right of vAmiga if those events carry the Denise delay instead. Copper-sourced events keep the Denise delay for the Agnus two-cycle class: the copper-driven DMA-gating replay was calibrated with that offset when the copper landings became bus-exact (documented TODO). The staged collision/render unit tests move their write slots four colour clocks ahead of the intended recorded positions, keeping every asserted boundary identical. No serialized-state shape change.
…CPU_WRITES Log every CPU custom-register write's granted chip-bus slot and the beam position its effect applies at, in the same format as the copper landing trace (COPPERLINE_DIAG_COP_WRITES), for cross-emulator landing comparison against vAmiga's env-gated VAMIGA_CPU_PROBE pokeCustom16 probe (vamigats-reports/vamiga-cpu-probe.patch in the reference checkout). The two-sided histograms this pair produces separate the write-effect pipeline (now modelled) from the remaining CPU write-landing phase divergence: IRQ-handler entries land with a quantized scatter around a +2 colour-clock mode (busy-loop instruction boundaries), and E-clock synced CIA loops land bimodally at 0 / +5 colour clocks (the CIA E-sync table is vAmiga's even-phase projection at colour-clock resolution).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
CPU register writes now record their render/collision events at the chip-bus slot that carried the write plus the register class's write-to-effect delay - the same rule Copper writes have used since #146 - replacing the copper-only compensation twin and its TODO:
DENISE_WRITE_EFFECT_DELAY_CCK).recordRegisterChange(DMA_CYCLES(2))): slot + 2 cck (AGNUS_WRITE_EFFECT_DELAY_CCK).Previously CPU events were recorded at the live beam position, which sits 2 cck past the granted slot on the classic bus once the write's bus cycle has been billed - so CPU Denise-class events carried a hidden -2 cck bias, and the offset silently depended on the CPU model (the 020+ short bus cycle leaves a different tail). The granted slot is remembered across the access (
Bus::cpu_custom_access_slot, transient,#[serde(skip)]- STATE_VERSION stays 26).Evidence (two-sided landing traces)
New probe pair:
COPPERLINE_DIAG_CPU_WRITES=1logs every CPU custom write's granted slot + effect position; an additive env-gated vAmiga patch (VAMIGA_CPU_PROBE=1,vamigats-reports/vamiga-cpu-probe.patch) logs every CPU-sourcedpokeCustom16with its beam position. Traces are aligned per IRQ episode on the copper INTREQ MOVE landings, which are bus-identical since #146.DMA_CYCLES(2).vAmigaTS family numbers (dual-setup sums, baseline = merged main @12fc0b1)
What the fix exposes (characterized, not chased here)
The old -2 bias partially cancelled a REAL remaining divergence: the CPU write LANDING phase. The new probes measure it cleanly; each item is a separate follow-up model, none is a pipeline constant:
E_SYNC_DELAY_CCK[5]is vAmiga'ssyncWithEClockeven-phase projection at cck resolution; the odd phases (and the eClk7 15-clock case) are unreachable.pos + 5inpeekVHPOSR) - 1 cck low, so poll-exit boundaries differ in ~1/13 loop phases.VHPOSR_LOOKAHEAD_CCKwas calibrated (PR agnus: hardware VHPOSR/VHPOSW semantics (first vAmigaTS triage fix) #101) under the old bias; retune only with a two-sided poll-exit trace.Gates