problem with the even/odd frames test
Moderator: Moderators
Let me "teach" something cool. I checked the PC address where the test begins, plus the LDA instruction (yes, the exact moment). Once LDA #$03 (for test 3, as example) is triggered, so I start my CPU log (disassembling and a few things, as IRQs, NMIs and PPU timing are logged). You can add log to a few PPU rendering events, plus log its registers (2000,2002,etc). Man... it was wonderful. I could check WHY my emu wasn't OK, in which TIME it fails, what things are being triggered or not, and when. Asking for "theory only" might fail after all, because you WON'T understand the internal thing in deep meaning. ^_^;;
Zepper
RockNES author
RockNES author
If an interrupt (IRQ or NMI) occurs during the last cycle of an instruction, the CPU will execute one more instruction, then process the interrupt. If an interrupt occurs during any other cycle of an instruction (from the first cycle through the second-to-last), the CPU will finish executing that instruction, then process the interrupt.
LDA #1
LDA #2
If an interrupt occurs during the first cycle of LDA #1, the accumulator will contain a 1 when the interrupt code begins executing, and the PC on the stack will point to the start of LDA #2. If, however, an interrupt occurs during the second cycle of LDA #1 (this instruction is 2 cycles long), the accumulator will contain a 2 when the interrupt code begins execution, and the PC on the stack will point to the first instruction after LDA #2. You can think of it as a 1-cycle latency (where one cycle passes after an interrupt occurs before the CPU sees it).
LDA #1
LDA #2
If an interrupt occurs during the first cycle of LDA #1, the accumulator will contain a 1 when the interrupt code begins executing, and the PC on the stack will point to the start of LDA #2. If, however, an interrupt occurs during the second cycle of LDA #1 (this instruction is 2 cycles long), the accumulator will contain a 2 when the interrupt code begins execution, and the PC on the stack will point to the first instruction after LDA #2. You can think of it as a 1-cycle latency (where one cycle passes after an interrupt occurs before the CPU sees it).
Quite interesting. This might fix a few things here, thanks.If an interrupt (IRQ or NMI) occurs during the last cycle of an instruction, the CPU will execute one more instruction, then process the interrupt. If an interrupt occurs during any other cycle of an instruction (from the first cycle through the second-to-last), the CPU will finish executing that instruction, then process the interrupt.
Zepper
RockNES author
RockNES author
Ugh, yes, this issue has been growing in my mind lately. We really need to clarify the conceptual model on this aspect. In reality, execution of INX occurs during three cycles, but only increases total execution time by two cycles. What do we do? Currently it seems we say that INX takes two cycles, but then confusingly refer to the third cycle of the instruction and call the second cycle the last cycle?!?tepples wrote:By "last", you mean e.g. the second cycle of INX or the fifth cycle of LSR $30, not the (pipelined) writeback + next instruction fetch, right?
Could we say last visible cycle of an instruction? The last non-overlapped cycle? Seems we need to upgrade the shared conceptual model and terminology, or these things will remain confusing due to our inability to refer to things without long phrases.