| |
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: 1078 |
Maybe from CLI/SEI/PLP as described in the link above? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Maybe from CLI/SEI/PLP as described in the link above?
Didn'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. Adding raster IRQ gave me an additional 3c jitter. Supporting old and new CIA I treated just like yet another 1c jitter. So in total I had 11 compensation routines at $xx00. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Perhaps you ran into this little corner case. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Interesting, I don't think my emulator core handles that case! |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
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: 478 |
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: 5094 |
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: 728 |
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: 478 |
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: 11386 |
dont forget to submit that kind of code snippets for use in the VICE testprog repo :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
