| |
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....
|
| |
Hypnosis
Registered: Mar 2015
Posts: 36 |
Ooh, that was really handy, showing the memory accesses per cycle and instruction in nice tables! |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Things get a bit more tricky men using NMI together with IRQ. If an NMI triggers while the IRQ is being setup, the NMI will get stalled the addional cycles it takes for the CPU to complete the IRQ-setup. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
You're not talking about an NMI "stealing" an IRQ in progress are you? Please explain what you mean by "setup" and "stalled". |
| |
Hypnosis
Registered: Mar 2015
Posts: 36 |
I would assume setup would mean push PC and status on stack and stalled would mean waiting for additional cycles to push on the stack, perhaps another 7 cycles? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quoting HypnosisI would assume setup would mean push PC and status on stack and stalled would mean waiting for additional cycles to push on the stack, perhaps another 7 cycles?
This seems to be a "borderline case", where we can have an "Interrupt hijacking".
The MOS 6502 and by extension the 2A03/2A07 has a quirk that can cause one type of interrupt to partially hijack another type if they occur very close to one another.
For example, if NMI is asserted during the first four ticks of a BRK instruction, the BRK instruction will execute normally at first (PC increments will occur and the status word will be pushed with the B flag set), but execution will branch to the NMI vector instead of the IRQ/BRK vector:
Each [] is a CPU tick. [...] is whatever tick precedes the BRK opcode fetch.
Asserting NMI during the interval marked with * causes a branch to the NMI routine instead of the IRQ/BRK routine:
********************
[...][BRK][BRK][BRK][BRK][BRK][BRK][BRK]
http://wiki.nesdev.com/w/index.php/CPU_interrupts |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Yes, this is the NMI stealing or hijacking a BRK or IRQ, however you want to call it. There are no stalls here though, it's the same 7 cycles as always, just jumping to the NMI vector at the end. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Yes, this is the NMI stealing or hijacking a BRK or IRQ, however you want to call it. There are no stalls here though, it's the same 7 cycles as always, just jumping to the NMI vector at the end.
Well. I had to conpensate for an additional 3c jitter i clearly remember. |
| |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
