Here's a (contrived) scenario:

My (6502) emulator is executing code and an NMI occurs. It was in the middle of an instruction so the instruction finishes. Once the instruction finishes, the current PC is pushed the the stack (along with status, etc.), and the ISR routine is ran.

In the ISR routine, the address at which the NMI occured gets modified to hold a different instruction of a different size.

When RTI is called from the ISR routine we return back to the instruction that was preempted, but now there is a different instruction there.

What is the behavior next? Do we advance PC by the new instruction length? Do we advance PC by the old instruction length? Do we execute the new instruction?

Thanks in advance.

When you do the RTI, the new PC value is popped off the stack and the next instruction is read from that address - there's no record or residue of what might previously have been at that address.

Okay, so if i'm understanding it correctly, it still needs to re-read what is currently at that address so it knows how much to advance PC by, without executing the instruction there.

Umm, not sure what you're saying there. At the time of the interrupt being taken, the present PC is pushed - the instruction at that place is read, but nothing happens with the opcode that's read. At the time of the RTI, the new PC is popped, and then the instruction is read. That then proceeds exactly like any other instruction: in the following cycle, the next byte will be read and in parallel with that the instruction just read is decoded. In the third cycle, the CPU's behaviour depends on the decoded instruction - possibly a third byte will need to be read.

You can experiment with interrupts using the visual6502 simulator. A possible starting point:
http://visual6502.org/JSSim/expert.html ... =8080&d=40

> Once the instruction finishes, the current PC is pushed
Perhaps this is where we need to dive in - you're thinking of the previous instruction being interrupted. It's more accurate to say that the previous instruction finishes, and the next instruction is replaced by the actions of a BRK instruction. It's the replaced instruction which will eventually be refetched and executed after the RTI. The PC is incremented one by one during the execution of any instruction - it doesn't stay static and then jump by 1, 2 or 3. (In any given cycle, it either increments, stays the same, or is replaced.)

Ah okay. I was for some reason getting hung up on it not advancing PC -- Now it makes sense to me, thank you.

Glad I could help! I've been musing about posting something to explain the reason behind the difference between RTS and RTI, as to whether the PC or PC-1 is found on the stack. That is, assuming I could come to understand the reason while writing it up!

So, just to clarify, when an interrupt happens in the middle of an instruction, is that instruction allowed to complete, and then the interrupt processing begins, or is the instruction stalled.

So, simplest case.

PC = 1000
Instruction is a NOP.

While the NOP is being executed, the interrupt occurs. So, which PC is pushed on the stack: 1000, or 1001?

The instruction is allowed to finish. The exception is the ABORT\ interrupt on the 65816. That one makes that instruction appear to finish but it has no effect, and then the RTI takes you back to the same instruction to try again.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yes the instruction is allowed to finish. For anyone who's curious about the exact details of interrupt handling...

Step 1: when the SYNC signal is high (or when the 816's VPA and VDA are both high) it means a new instruction is beginning. Via PC, the CPU fetches an opcode. Typically the opcode is accepted; but this cycle is the timeslot when an interrupt can commence (assuming one has been requested). If an interrupt commences then the just-fetched opcode is discarded. It gets preempted by an internal instruction that resembles BRK. The next step will be 2b, not 2a.

Step 2a (normal): if there's no interrupt then PC is incremented, and in cyle 2 (the cycle following SYNC) the byte at opcode_address + 1 is fetched. The byte at opcode_address + 2 may also be fetched, and other memory accesses may occur, such as to zero-page, stack or general data memory. In other words the instruction is allowed to complete -- after which PC will point to the opcode of the subsequent instruction, and it's time to go to step 1 again.

Step 2b (interrupt): if, during step 1, an interrupt commences, PC is not incremented, which is important. And in cycle 2 the opcode is fetched again and discarded again, which is generally meaningless. Then the thing resembling BRK causes PC -- still pointing at the preempted opcode -- to be pushed. Finally the interrupt vector is fetched, and the thing resembling BRK is complete. PC will point to the first opcode of the ISR, and it's time to go to step 1 again.

At the conclusion of an ISR, RTI pops the return address into PC. When the RTI has completed PC will point to the preempted instruction and it's time to go to step 1 again.

Did I hear somebody ask what's the difference between "the thing resembling BRK" and an actual BRK? Actual BRK sets the BRK bit in the P byte pushed to stack. Also, actual BRK is a two-byte instruction that causes PC to increment by two before it gets pushed to stack.

(ABORT, as Garth noted, causes the currently executing instruction to have no effect. In that regard it does not wait for an instruction boundary. Then when the boundary does arrive -- when the instruction has "completed" -- the address of the aborted instruction's opcode is pushed, which means when an RTI occurs later it will take you back.)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

If the instruction didn't finish, the CPU would have no way to properly finish it, after other instructions in the ISR were executing. The only valid way would be to refetch and execute it again, which is not what happens (except in the case of ABORT).