Using a timer interrupt is interesting as it allows for much simpler logic as you don't need to follow execution flow. You do still need to be able to hook the interrupt vector, of course, and it's much harder to make cross-platform. The Commodores used a VIA, the BBC Micro and Oric have 6522s, the Atari has the bespoke POKEY... and the BBC Micro Second Processor doesn't have a timer at all. Which is nice.

Belatedly: one issue with semi-emulation (i.e. patching the instruction into the debugger code so that it can be executed in situ) is that the debugger has to make sure the stack is unmodified when this happens or else debugging code like 'tsx; lda 0x101, x' will fail. So there'll be some exciting code there.

Another option is to use a plug-in hardware emulator such as the MCL65+, and then use that to log an instruction trace/set breakpoints.

Or, what I do, printf FTW ...

If you can blink an LED you can send a character down a UART, if you can do that then you can print strings, then numbers, then the world is your bi-valve...

I seriously haven't done anything more than that on the 6502 to bring a new system up since the late 70s...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

using prints for debugging is pretty underrated. i have a macro that prints a single character to serial without changing any flags or registers.
so when i have a program that crashes somewhere i can start by just putting a few prints along the main program flow like "a", "b", "c". when i then run it i can see which is the last character it prints before crashing, which gives me a rough idea of where the issue might be.

of course prints are not as useful when you try to debug existing code sitting in ROM somewhere that you cannot reprogram at will

I have done that --- I've brought boards up, in fact, where the only feedback was whether a light comes on or not. And my general opinion of it is that having a real debugger is so, so much easier!