Good strategies for software single stepping

Programming the 6502 microprocessor and its relatives in assembly and other languages.
User avatar
hjalfi
Posts: 107
Joined: 12 Oct 2017

Re: Good strategies for software single stepping

Post by hjalfi »

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.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Good strategies for software single stepping

Post by Arlet »

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.
User avatar
drogon
Posts: 1671
Joined: 14 Feb 2018
Location: Scotland
Contact:

Re: Good strategies for software single stepping

Post by drogon »

Arlet wrote:
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/
User avatar
Proxy
Posts: 746
Joined: 03 Aug 2018
Location: Germany

Re: Good strategies for software single stepping

Post by Proxy »

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
User avatar
hjalfi
Posts: 107
Joined: 12 Oct 2017

Re: Good strategies for software single stepping

Post by hjalfi »

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!
Post Reply