| |
muh
Account closed
Registered: Feb 2013
Posts: 6 |
Stable IRQ Jitter
I have a more or less technical question considering the cycles used after an IRQ triggers.
From what i gather this happens after an IRQ triggers:
- finish -already started- instruction (variable cycles)
- 7 cycles for IRQ
I think I understand the way double IRQ works:
IRQ1 ends in NOPs; IRQ2 now has 1 cycle jitter; last cycle of cmp $d012 either at cycle 63 of the current rasterline or cycle 0 of the next, so the beq by actually branching or not fixes the 1 cycle jitter. All fine.
However the examples on codebase I've seen seem to be 2 cycles short. Now I read in these forums the finish-instruction-delay is 2-9 cycles after IRQ trigger.
With a NOP taking 2 or 3 cycles to complete after IRQ trigger the examples make sense.
How can a 2 cycle NOP instruction take 3 cycles to finish? Can anyone explain the logic?
I hope this makes sense ;) |
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
If D012 change just after fourth CMP cycle or, in other words, on the first cicle of BNE, your code takes 3 cycles for branch, 4 cycles for CMP again, and if D012 match the CMP, BNE takes 2 cycles to exit.
9 in total.
Is this cycle what you are looking for? |
| |
muh
Account closed
Registered: Feb 2013
Posts: 6 |
Below a snippet taken from codebase to hopefully explain my confusion:
irq2:
// 7 IRQ cycles
// I would say 0 or 1 cycles for finishing a NOP (the jitter)
txs //2
ldx #9 //2
!: dex //2
bne !- //3 (or 2 when done)
// subtotal: 55/56
//final cycle wobble check
lda #irqLine+1 //2
cmp $d012 //4
//at best the cmp $d012 ends up at 61/62
beq *+2 //3 or 2
//the raster is now stable! \o/
I added cycle counts. It seems to me the cmp $d012 should end at cycle 61 or 62, but as the routine works apparently it is at 63/0? Where do the extra 2 cycles come from?
Hoping this makes my question clearer..
Thanks Flavioweb, however I think your answer is to the reason the jitter is there when you do a lda #$30; cmp $d012; bne *-3. Not the answer to the 2 cycles I'm looking for in this case. |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
For being served after an instruction an IRQ needs to be triggered 2 cycles before the instruction ends.
Some examples may clarify:
...
NOP
-->IRQ Triggered
NOP
-->IRQ Served
NOP
...
...
NOP -->IRQ Triggered at cycle 1
NOP
-->IRQ Served
NOP
...
...
INC abs16 --> IRQ triggered at cycle 5
(ANY instruction)
-->IRQ served
...
...
INC abs16 --> IRQ triggered at cycle 4
-->IRQ served
(ANY instruction)
...
This clearly expains the two missing cycles, so jittering is 2+(0-7) => 2-9.
Font: http://www.antimon.org/dl/c64/code/stable.txt |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
cool, thats something I didnt know so far. |
| |
muh
Account closed
Registered: Feb 2013
Posts: 6 |
Ah thank you.
Little follow-up, I know I could test it but you might know the answer.
Is it the VIC triggering the IRQ that causes the delay or is it the CPU taking 2 cycles to recognize the IRQ signal before the default handling kicks in.
In other words do the same 2 cycles apply for timer generated IRQs? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
VIC has no idea of the CPU state, so it must be wired cpu behaviour. |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
As Oswald's already told you, it's cpu default behavior. |
| |
lft
Registered: Jul 2007
Posts: 369 |
For completeness:
I learned recently that if the IRQ arrives while the CPU is stalled e.g. due to sprite fetches, the first cycle of the interrupt sequence (probably just latching the signal) appears to be handled anyway. This means that the total latency will be one cycle less. |
