Barnacle's thread on Single stepping by inserting BRKs into RAM got me thinking. Rather than trying to insert the BRK opcode into the correct location following the current instruction why not insert the BRK op-code into databus when the op-code is being fetched*. It's solves the stepping into ROM problem quite neatly. And I suspect a bit of fiddling with the PC on the stack could make RTI return to exactly where the BRK was inserted.

But then I realised it seemed like I was describing the '816's abort feature. Does it seem feasible to single step the '816 by ABORTing it during the op-code fetch? It would be kinda satisfying to finally find a use for ABORTB.

Still very much a thought experiment and using abort might require more hardware to make it work compared to inserting a BRK. And if hardware modifications can't be made then I guess neither are workable and it's back to inserting BRKs into memory.

Just wondering if anyone has tried this or thought about it before?

* i.e. when VPA and VDA are high or when SYNC is high on the 6502

Certainly an interesting concept.

Inserting a BRK on to the bus would require a buffer or multiplexor of some kind, and you'd need an address comparator, and you'd probably want to snoop VDA and VPA as well so that you only act on the opcode byte of an instruction.

Using ABORTB you could run run the output of the comparator & VDA/VPA snooper directly into the processor, removing the need for the buffer entirely, I reckon.
In a sense, this sort of thing is exactly what ABORTB was originally intended for - perhaps not breakpoints per se, but if you wanted to interrupt on a specific instruction or memory access without having to deal with collateral damage...

The main gotcha would be that ABORTB has non-trivial timing requirements in order for the instruction to actually not have any effects, also you need to make very sure you don't trigger it again because its not maskable and, somewhat ironically, you can ABORT an ABORT.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Still a thought experiment but I think the ABORTB timing would be fine. I visualise loading a latch somewhere that says: "The next VPA & VDA after an RTI instruction must issue an ABORTB pulse". In my case I already have the last op-code knocking around in another latch so that is simple enough to test. And I think bringing ABORTB low while PHI2 is high & VDA & VPA & single-step-latch will satisfy the abort conditions before the '816 runs past its second cycle - which is where the caveats start coming in. I could also work to ensure I never abort an abort and if I do then, well, that's a bug.

What I'm seeing as tricky now is: what happens if a NMI occurs, particularly if during the RTI of abort? I'm using NMIs as an OS watchdog type thing and I'd guess most systems have them for something. Do I save the NMI into another latch somewhere and the abort vector must know to check it before it does it single step shenanigans? Do I instead have the NMI clear the single-step-latch and set it again when it is done? How do I know NMI must set the single-step-latch again? Store it in memory somewhere? Store it in yet another latch?

Gah!

Single stepping with abort still, after all of the above, feels like it is less effort than trying to calculate the next program address to insert a BRK but that's mostly by pushing the problem out to the hardware guy. In this case: also me.

Anyway, I'm very far from single-step debugging so I have plenty of time to think about things.