I'm still lacking a good reference for which clock IRQ and NMI are checked on. I've been studying the timing diagrams in the Rockwell manual again. This is what I've gotten from them:
* Each instruction is structured into the following cycles: opcode fetch, decode, optional extra cycles, and a final calculation cycle that overlaps with opcode fetch for the next instruction
* The interrupt sequence consists of the normal opcode fetch, another dummy opcode fetch, then interrupt vectoring cycles
This instruction overlap upsets the simpler model we commonly use when talking of the nth cycle of an instruction, since in reality every instruction has one more cycle than listed in the timing charts (the charts list how many cycles longer a code sequence will take when adding that instruction, not how many cycles that instruction consists of).
I used to think that the processor checked for IRQ/NMI at the beginning of the next-to-last cycle of an instruction, but now I'm not so sure. Part of this is in realizing that the next-to-last cycle is the last memory cycle of an instruction, which had previously caused me to think of it as the last cycle of the instruction. This is clearly wrong since something like LDA must set the status flags in a cycle after the final memory read. With this new understanding, it doesn't make sense to me to check one clock before the next opcode fetch, so I'm thinking I must have been wrong.
I do know that a CLI that clears the I flag while an IRQ is pending results in the next instruction executing before the interrupt sequence begins. CLI is a three-cycle instruction (opcode fetch, decode, clear I flag while fetching opcode of next instruction). From this I conclude that IRQ must be checked during the opcode fetch cycle or before that, since checking it after that wouldn't result in the extra instruction being executed. So maybe the interrupt lines are checked during the opcode fetch cycle?
* Each instruction is structured into the following cycles: opcode fetch, decode, optional extra cycles, and a final calculation cycle that overlaps with opcode fetch for the next instruction
Code:
1 Opcode
2 Decode
3 Final Opcode
4 Decode
5 Final Opcode
6 Decode ...
7 Final
2 Decode
3 Final Opcode
4 Decode
5 Final Opcode
6 Decode ...
7 Final
* The interrupt sequence consists of the normal opcode fetch, another dummy opcode fetch, then interrupt vectoring cycles
This instruction overlap upsets the simpler model we commonly use when talking of the nth cycle of an instruction, since in reality every instruction has one more cycle than listed in the timing charts (the charts list how many cycles longer a code sequence will take when adding that instruction, not how many cycles that instruction consists of).
I used to think that the processor checked for IRQ/NMI at the beginning of the next-to-last cycle of an instruction, but now I'm not so sure. Part of this is in realizing that the next-to-last cycle is the last memory cycle of an instruction, which had previously caused me to think of it as the last cycle of the instruction. This is clearly wrong since something like LDA must set the status flags in a cycle after the final memory read. With this new understanding, it doesn't make sense to me to check one clock before the next opcode fetch, so I'm thinking I must have been wrong.
I do know that a CLI that clears the I flag while an IRQ is pending results in the next instruction executing before the interrupt sequence begins. CLI is a three-cycle instruction (opcode fetch, decode, clear I flag while fetching opcode of next instruction). From this I conclude that IRQ must be checked during the opcode fetch cycle or before that, since checking it after that wouldn't result in the extra instruction being executed. So maybe the interrupt lines are checked during the opcode fetch cycle?