tepples wrote:
So in other words, RTI is handled just like a PLP then RTS, except a couple cycles faster, right?
RTI does not change the return address once pulled from the stack.
RTS increments the return address by 1 (since JSR pushes an address 1 less than what you'd expect)
So if you try to PLP + RTS instead of doing an RTI (or vice versa), you'll end up returning to the wrong spot and possibly crashing.
But aside from that detail... yeah.
darklink wrote:
ah, I forgot the PLP.
Is it same as RTI ?
You might want to look at the instruction layouts in this doc to see what each instruction does during each of its cycles:
http://nesdev.com/6502_cpu.txt
The reason the IRQ might be delayed by one instruction is because the I flag has to be cleared BEFORE the last cycle of the instruction in order for an IRQ to trip immediately after that instruction. (Likewise, the I flag must be set before the last cycle of the instruction for the IRQ to be prevented -- so it's possible for an IRQ to trip immediately after a SEI instruction and have the I flag set when pushed to the stack!)
If you look at PLP and CLI -- they both change processor status on the last cycle of the instruction -- hence their delay. RTI, however, changes it before the last cycle, so there's no delay.
EDIT -- actually it doesn't look like CLI/SEI are listed on that doc because they're basic implied addressing. But logically, since the first cycle of CLI/SEI is fetching the opcode, the flag couldn't be changed until the second (last) cycle.
PLP and RTI are in that doc though.