Has there ever been any discussion on the behaviour of the RESET interrupt on the 6502? I had always expected it to behave exactly like the IRQ and NMI interrupts (albeit with stack reads instead of writes), but Visual6502 shows some strange things.

Here we see A getting corrupted:
http://visual6502.org/JSSim/expert.html ... es,irq,nmi

Here we lower /RES half a cycle later; this time A isn't corrupted, but PC goes through some crazy values on the way:
http://visual6502.org/JSSim/expert.html ... es,irq,nmi

Don't remember reading anything about this on here in the past, but I assume by now it's been reverse engineered and we know exactly what's going on. Took me by surprise though.

mmm, mildly interesting! I think what's going on here is that reset must always get the whole machine into a known state, and for that reason it affects the timing machine as well as injecting a BRK into the IR. And so any in-progress instruction could go through various deterministic but unplanned states, which might then have side-effects in the datapath.

In the first case, the IR isn't getting a BRK instruction inserted into it at first, but it is going through the timing of an interrupt sequence. So the LDA# logic is firing for all those cycles, hence moving whatever's on the data bus into A.

Hard to understand exactly what's going on in the second case, but the T0+T1 state is new to me, and seems to be responsible for the wacky PC behaviour.

(This all came about after watching the recent Ben Eater video on building a 6502 based computer, where he showed the 6502 reset sequence briefly setting the address bus to FFFF. Why's that? I thought. Well...)

Mmm, what seems to be happening is that Reset low pretty quickly gets the timing state machine to T0+T1, and that becomes the stable state until Reset is taken high again. The BRK has already been jammed into the IR - which might well therefore have changed the PLA inputs, the PLA outputs, and the datapath control lines.