Seems SMB3 has 8 KB of non-battery-backed WRAM though (so essentially just a RAM extension - guess that might be where "work" comes from), which will make things much trickier. You can't just dump data there without potentially stomping on the game's data.

I'm working on an NES emulator and can fill in some more details.

The $6000-$7FFF area is where battery-backed RAM tends to show up for games that have a save feature. Just to confuse you, this area is variably called PRG RAM, SRAM (probably for Save RAM), and WRAM (which apparently stands for Work ...

That ADC imm example makes it look like some four-cycle instructions can be reduced to two cycles too if they don't need access to the data bus during the final two cycles, which is pretty cool. It probably uses some more internal state in addition to the State to make that work out right.

Like ...

Yeah, not sure about the numbering on those steps either.

All reads/writes output the address during φ1+φ2 and perform the transfer during φ2 btw, and every cycle is either a read or a write cycle.
Another doubt though - if this is the case, then during a read cycle, why does the data bus already have the fetched value during φ1?

I think it's because ...

Someone correct me if I'm wrong, but I think the two-step pipeline (if it can be called that) in the 6502 works as follows:


All instructions need at least three cycles to execute (fetch + decode + carry out).
During the decode cycle the data bus is free, and the byte after the opcode is fetched ...

Perhaps BigEd can shed some light on this. My best guess is that the opcode fetch is still happening during T0 (presumably during φ2), but the results are only 'visible' by the start of T1, or something like that?

Some instructions read/write results during the final T0 cycle though, which speaks ...

Ah, thank you, I hadn't spotted that.

While we're here, perhaps you could clarify something which still leaves me rather puzzled, looking at the Visual 6502 output (this is going a little off-topic). It is usually stated that T0 represents the opcode fetch state, but looking at Visual 6502, this ...

Another way to phrase the explanation would be to say that there's a level detector on the IRQ input and an edge detector on the NMI input, both reacting to a change during φ2 and asserting their outputs during the following φ1. It's those outputs that are then sampled.

More analog-inclined people ...

OK, here's what I was thinking of - in this post , I posted a simulation URL and noted that "as long as nIRQ is low during the first half of T0, the interrupt sequence will begin, and this is the only place the CPU checks whether an interrupt should be taken or not". Going to this URL now shows ...

IRQ is usually polled during the second-to-last cycle of an instruction (two cycles before the opcode fetch).
This surprises me, as I was sure I once set up some simulations in Visual 6502 which showed that the second half of T0 was where IRQs were polled to determine whether to start the ...

You're welcome.

In case anyone's interested, I've put together a page with detailed (or at least more detailed and less vague than I could find elsewhere) information on 6502 interrupt behavior and timing at http://wiki.nesdev.com/w/index.php/CPU_interrupts . It checks out in Visual 6502 and makes blargg's cpu ...

The log seems consistent with the logic around the pin now at least, so it's probably correct.

I remember reading in some places that IRQ is (usually) polled during the last cycle of the instruction, but it seems more accurate to say that it is polled at the end of the second-to-last cycle then ...

Hmm, that still doesn't match what I'd expect, but maybe I'm missing something.

My understanding what that the IRQ line would get sampled during the final cycle of the LDA, before the CLC fetch, but now it looks like it's being sampled during the LDA fetch cycle. Was the display shifted in the ...