| |
Hypnosis
Registered: Mar 2015
Posts: 36 |
Cycles to get into IRQ routine
How many cycles does it take from an IRQ trigger to the start of the IRQ routine, assuming the CPU finished the instruction when it triggers? It should be around 6-9 cycles but I'm not sure how many. |
|
... 53 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1058 |
Interesting, I don't think my emulator core handles that case! |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting JackAsserDidn't investigate it too deep. With plain NMI I had 7c jitter which I compensated for using indirect jumps into code places on the timer-addresses.
Seems that, to be totally sure to "compensate" all possible jitter ranges (without using illegal opcodes), we need to have a 10 cycles "compensation code".
- 2 cycles for minimum irq jitter;
- 1 cycle or 3 cycles if "branch taken" + next opcode cycles.
So, worst case: 3 + 7 cycles like
LOOP
INC $FFFF,X
DEX
BNE LOOP
if irq is triggered on first cycle of BNE, then BNE + INC are executed before CPU starts irq sequence...
But this isn't related on have an irq that occur very close to one another, and should happen anyway. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Without any unintended opcodes there's a 8c jitter - this was discussed "a decade ago" in Stable Raster via Timer.
It's interesting to see that 7c jitter still seems to be THE standard for max jitter; I hoped this had changed by the discussion once and for all.
However, mixing IRQ with NMI and having them overlapped as mentioned by Jackasser was not focused on back then. Are there really different states resulting in more than 8c jitter? Following the final explanation of the old discussion this could be the case if the first IRQ cycles are also "opcode fetch cycles" that block other interrupts.
Maybe it's a good idea to do a complete writeup of the irq jitter topic, e.g. a chart with all possible IRQ settings and the resulting jitter max values (just like Groepaz did for the unintended opcodes some time ago;)) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
So how can the inc be executed if irq happens on first cycle of bne ?
according to copyfault "Note that IRQs are checked *before* the last cycle of an instruction executes, " |
| |
HCL
Registered: Feb 2003
Posts: 717 |
I think 7 cycles jitter is enough in most cases, as it depends on what kind of op-codes you are using. Legal op-codes use max 7 cycles, only a few illegal ones use 8 cycles. So.. if you are not planning on using them outside your irq, you can of course have less jitter. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
From what I remember right now (it's a little while ago;)):
@Oswald: if the irq happens on the first cycle of a branch, it will be processed after the second cycle of the branch; but if an irq happens during the second cycle of a branch, processing is delayed until the end of the opcode following the branch instruction.
@HCL: 8c jitter is the uncomfortable reality even when sticking to the socalled legal opcodes outside the irq. This was the major conclusion of the thread I started those years ago. This comes from the oddity of the branch logic: if a branch is taken, the additional "branch taken"-cycle adds to the no. of cycles of the following opcode and it can not be interrupted. Thus, if there is an indexed RMW instruction that can be reached by a branch _and_ if the irq happens on the second cycle of the branch (which is going to be taken), the jitter will be 8 cycles.
So it does not depend on wether using illegals or not but rather on what opcode can be reached by a branch. Ok, I have to admit that this specific case is also not very probable ;))
I'll have a look if I can find the test code I did back then; maybe I should release it here for everyone to play around with it. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11135 |
dont forget to submit that kind of code snippets for use in the VICE testprog repo :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting Copyfaultif the irq happens on the first cycle of a branch, it will be processed after the second cycle of the branch; but if an irq happens during the second cycle of a branch, processing is delayed until the end of the opcode following the branch instruction.
So, with this code
LOOP
INC $FFFF,X
DEX
BNE LOOP
if an irq happens durng second cycle of BNE, and branch is taken, 2(BNE)+7(INC)=9 cycles are executed before irq and, as a "borderline case of the corner cases", if BNE cross page boundary, 3+7=10 cycles are executed.
I'm wrong?
(Ok... i know we all need to avoid boundary cross... and probably no one use a INC $FFFF,X... but it's just to see if my thoughts are correct.) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
"if irq is triggered on first cycle of BNE, then BNE + INC are executed before CPU starts irq sequence..."
this still doesnt seem to make sence. last cycle of bne will check forr irq condition, if bne finished then cpu jmps to irq, or why not ? |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
@Flavio: I remember there was a different behaviour when that branch was pagecrossing.
No pagecrossing, branch taken, irq on 2nd branch cycle (marked with <>):
next op.....cycles
BNE (taken) [R=1st branch cycle]<R=2nd branch cycle>[R=add.cycle]
INC abs,X [R=1st INC cycle][2][3][4][5][6][7]
<irq processing starts here>
Same with pagecrossing:
next op.....cycles
BNE (taken) [R=1st branch cycle]<R=2nd branch cycle>[R=add.cycle for branch taken][R=add.cycle for pagecrossing]
<irq processing starts here>
There was this explanation with socalled "opcode fetch cycles" that do not allow irq acknowledging and that an irq is not processed before it was acknowledged. Having a pagecrossing situation, the first additional branch cycle belongs to those opcode fetch cycles whereas the next additional cycle for the page crossing does not; thus, it results in less jitter. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
