Hardware IRQ-delivery model (IPL pipe + sampling) and blitter startup cycles#125
Merged
Merged
Conversation
Replace the blanket 65-cck interrupt-recognition latency with the hardware mechanisms it approximated: - Paula pipelines the encoded interrupt level to the CPU's IPL pins over a few chip clocks; DEFAULT_IRQ_LATENCY_CCK becomes that pipe (5 cck: the ~4-cycle pin pipe plus the poked-INTREQ register-commit cycle). INTREQR reads are never delayed. - The 68000 latches its IPL pins during bus cycles: the take-interrupt decision at an instruction boundary uses the level sampled at the previous instruction's last bus access (CpuBus::sample_ipl), so a level rising in an instruction's trailing internal cycles is taken one instruction later. A STOPped CPU samples live. - Normal blits get three internal startup slots: the BLTSIZE register commit plus the two bus-arbitration startup cycles Agnus spends before the micro-program begins. The 65-cck constant had been calibrated against timing-test row 19 with a mis-decoded VHPOSR: the low byte is the beam position in colour clocks (H8..H1 of the 9-bit counter), not cck/2, so the real raise-to-entry latency is ~52-61 cck, not ~114-122, and the blanket made every interrupt ~50 cck late. Verified against vAmiga with a beam-position probe across seven IRQ-source/CPU-loop geometries plus a BLTSIZE-to-blitter-IRQ chain measurement, and against the vAmigaTS real-A500 photos. vAmigaTS: cputim1 79.3->2.8%, irqtim1 24.1->7.9%, dmaoff1 47.6->6.9%, dmacon9 37.4->0.0%, bltint1 95.5(emulated program crashed)->7.2%; Agnus/Blitter family summed 3373->1750%. Demo screenshot set is byte-identical. Known trade: eon's scene player returns to ~37% frame skips (the removed constant was masking a real ~50 cck/frame CPU budget deficit tracked separately). Save states: STATE_VERSION 18 (blit state gains the startup counter).
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.
Replaces the blanket 65-cck interrupt-recognition latency with the hardware mechanisms it approximated, and adds the blitter's missing startup cycles.
What
COPPERLINE_IRQ_LATENCY_CCKnow configures this pipe (0 disables it and the sampling delay below). INTREQR reads are never delayed.CpuBus::sample_ipl). A level that rises during trailing internal cycles is recognised one instruction later, as on silicon. STOP samples live.Why
The 65-cck constant was calibrated against timing-test row 19 with a mis-decoded VHPOSR: the low byte is the beam position in colour clocks (H8..H1 of the 9-bit counter), not cck/2. Real raise-to-entry latency is ~52-61 cck, not ~114-122, so the blanket delivered every interrupt ~50 cck late - the dominant cause of the vAmigaTS cputim/irqtim divergence.
Verified against vAmiga (v4.4 headless) with a beam-position probe across seven IRQ-source x CPU-loop geometries plus a BLTSIZE-to-blitter-IRQ chain measurement, and against the vAmigaTS real-A500 photos.
Results
bltint1 deliberately holds a garbage level-3 vector for a few cycles after starting a blit; correct blit-IRQ latency is what keeps real hardware out of that window.
Gates
irq_recognition_uses_previous_instruction_ipl_sample); clippy + fmt clean.Known trade
eon's scene player returns to ~37% frame skips (was ~1% with the blanket): the removed constant was masking a real ~50 cck/frame CPU-budget deficit. Sensitivity is flat for honest pipe values (8/12 cck change nothing), so this needs its own investigation rather than a compensating constant; tracked in the vAmigaTS work list.