6502.org

Just to confirm -- What is the behavior of the 6502 when an interrupt occurs in the middle of instruction? Does it handle the interrupt when it occurred, or does it finish the instruction and then perform the interrupt?

For example, if I'm executing an instruction and have 2 cycles left until that instruction completes, what happens when an interrupt occurs? Does the interrupt logic (i.e. saving flags, changing PC) happen after the instruction completes (2 cycles later) or does it occur instantly?

Thanks in advance.

As Garth noted, the current instruction is always finished before interrupt processing begins. Also, as he noted, the 65C816's ABORT interrupt causes the MPU to discard the computational result of the current instruction.

Thanks for the information. One more question:

On the 6502, According to https://en.wikipedia.org/wiki/Interrupt ... processors, the following happens:
I've been able getting my cycle counts for various instructions on http://www.6502.org/tutorials/6502opcodes.html. This lists the cycle counts per instruction, as well as whether a modifier needs to be added because it passes a page boundary.

For the case of an NMI as described above... Is there a discrete number of cycles it takes to perform the NMI before executing the ISR? I couldn't find it anywhere (and an NMI isn't an actual instruction)

I'm basically going to push PC and SR to the stack, set the interrupt disable flag, and then set PC to the address of the ISR. I'm not sure how many cycles that would take for my emulator.

EDIT:
According to http://wilsonminesco.com/6502interrupts/, am I interpreting it correctly to be 7 cycles?

It's a matter of definition, I suppose. I'd say NMI is an instruction -- and, like its cousin, BRK, it takes 7 cycles to execute. But NMI is unusual in that it's an instruction not stored in memory -- it occupies zero bytes!

By the same measure, an IRQ would not be an instruction in the literal sense.

With the 65C816 in native mode, eight cycles are consumed in responding to any interrupt, the extra cycle accounting for the pushing of PB to the stack.

I'm not sure I fully understood a specific mechanism in the interrupt behaviour. Can anyone help me.

Page 131 of the MCS 6500 programming manual dated January 1976 indicates that during cycle 1 of an IRQ, the processor finishes the previous operation.

I also read this here https://www.pagetable.com/?p=410 "If there is an IRQ pending and the current instruction has just finished, the interrupt logic in the 6502 forces the instruction register (“IR”) to “0”, so instead of executing the next instruction, the PLA will decode the instruction with the opcode 0x00 – which is BRK!".

Let's imagine an interrupt occurs while the processor is executing a series of NOP's, which take 2 cycles each.

Does this mean that in this case, finishing the previous operation can take either 1 or 2 cycles?

I think there's a tension in every description of interrupt handling, between being simple enough to explain and being detailed enough to be precisely correct. It's rare indeed to see a description which is absolutely correct, because the cycle-by-cycle behaviour is, as it turns out, rather subtle.

That programming manual - link here to the exact page - has a table which counts off the cycles of the interrupt sequence, starting from the SYNC cycle which is the fetch of the instruction following the last one to complete.

Garth is right in saying that even during that SYNC cycle there are (potentially) internal operations which finish off the actions of that last instruction. But there's no way to see that from the outside, either in hardware or in software. We only see that by looking at the insides of the chip, for example with visual6502. It's interesting because without understanding this, the cycle counts of the instructions don't quite make complete sense.

Michael (aka the pagetable author) is of course also right. The SYNC cycle of the first instruction not to be executed proceeds as normal, as far as the chip's external signals tell us, but on the inside the instruction fetched is replaced with 00. There's no way to see this from the outside.

The program manual is right, in that the cycle after the SYNC is another read, but uniquely it is a read from the same address as the SYNC. This only happens in the case of an interrupt. However, I don't think I would have labelled this as Fetch, because it's not a SYNC cycle. I might have labelled it as Internal Operation.

If you count the IRQ from the cycle in which it is asserted - which is not what the manual is doing - then you will see a variable number of cycles before the next SYNC, which will happen on schedule.

And, to answer your question, yes, if executing a steam of NOPs and getting an asynchronous IRQ, the 6502 will take N or N+1 cycles from the SYNC of the final NOP to the fetch of the interrupt vector. Because the deterministic count starts from the next SYNC, which belongs to the first NOP which won't be executed.

One of the most remarkable threads here is
A taken branch delays interrupt handling by one instruction
which starts from an observation on a real system, and is interrupted(!) by the arrival of visual6502, which allows us to make full explorations of internal behaviour.

Hope this helps.