Posted: Wed Nov 17, 2010 6:03 am
I'm afraid in my previous post above I did a poor job of explaining the KIM-1 single-step facility. The key point I ought to have stressed is that the Debugger and the Code Being Debugged reside in separate memory chips. The technique requires no timer and doesn't need to overwrite anything with BRK opcodes.
The CPU starts off looping within the Debugger program -- displaying registers, perhaps, and waiting for a command from the user. If the single-step command is invoked it causes the CPU to exit the loop and branch to the code being debugged.
Naturally the branch has an effect on the chip-select lines, because the Debugger and the code being debugged reside in separate memory chips. Only the latter's chip-select is gated to NMI. Ie; chip-select active AND SYNC active results in NMI active. Therefore the very first opcode fetch within the code-to-be-debugged generates an NMI interrupt. 6502 NMI timing is such that the op is able to execute anyway; then the NMI takes effect. The NMI vectors the CPU back to the Debugger to resume displaying info and waiting for commands. No additional NMIs are generated (until the next command) because the Debugger code resides in a device whose chip-select isn't gated to NMI.
With that matter clarified, I hope my previous post will make a little more sense! The approach is similar to the Timer idea, and the interrupt still occurs after a single op has executed. But it's not reacting to the passage of time per se; it's reacting to the chip-select lines (which react to what's on the address bus). ROMness and RAMness have no bearing on the situation.
The technique could be adapted to use IRQ instead of NMI, although the exact gates and wiring would be a little different since IRQ doesn't exhibit a delay as with NMI. To use IRQ you'd drop the interrupt pin low at the end of the SYNC (ie; opcode fetch) cycle, not the beginning as with the KIM-1/NMI scheme. Another possible variation is to enable interrupts when the Debugger chip-select is inactive, rather than when the debug-ee chip-select is active. This is actually how the KIM-1 is wired; it's essentially the same thing.
(Furthermore, it's not strictly necessary to use separate chips. The alternative is to tie directly to the address bus. For example, if you were using a 64KB chip, wire A15 to the gate and put one code section above $8000 and the other section below $8000. Oops, am I confusing matters again?? Forget that last bit, then!!)
-- Jeff
The CPU starts off looping within the Debugger program -- displaying registers, perhaps, and waiting for a command from the user. If the single-step command is invoked it causes the CPU to exit the loop and branch to the code being debugged.
Naturally the branch has an effect on the chip-select lines, because the Debugger and the code being debugged reside in separate memory chips. Only the latter's chip-select is gated to NMI. Ie; chip-select active AND SYNC active results in NMI active. Therefore the very first opcode fetch within the code-to-be-debugged generates an NMI interrupt. 6502 NMI timing is such that the op is able to execute anyway; then the NMI takes effect. The NMI vectors the CPU back to the Debugger to resume displaying info and waiting for commands. No additional NMIs are generated (until the next command) because the Debugger code resides in a device whose chip-select isn't gated to NMI.
With that matter clarified, I hope my previous post will make a little more sense! The approach is similar to the Timer idea, and the interrupt still occurs after a single op has executed. But it's not reacting to the passage of time per se; it's reacting to the chip-select lines (which react to what's on the address bus). ROMness and RAMness have no bearing on the situation.
The technique could be adapted to use IRQ instead of NMI, although the exact gates and wiring would be a little different since IRQ doesn't exhibit a delay as with NMI. To use IRQ you'd drop the interrupt pin low at the end of the SYNC (ie; opcode fetch) cycle, not the beginning as with the KIM-1/NMI scheme. Another possible variation is to enable interrupts when the Debugger chip-select is inactive, rather than when the debug-ee chip-select is active. This is actually how the KIM-1 is wired; it's essentially the same thing.
(Furthermore, it's not strictly necessary to use separate chips. The alternative is to tie directly to the address bus. For example, if you were using a 64KB chip, wire A15 to the gate and put one code section above $8000 and the other section below $8000. Oops, am I confusing matters again?? Forget that last bit, then!!)
-- Jeff