As I have been using the debugger quite intensively the past few weeks, I have noticed some patterns where I have been doing things quite inefficiently (that came to my mind esp. after seeing Tat's debugger).
The most important thing -- I never know where I am in the code. For example, I set up a breakpoint somewhere, it's hit. I press "d' which shows me the current PC (i.e. where the breakpoint is). But that rarely suffices, I need to look up a few instructions, so I type something as "d 'pc-16'" to see some context. Then I of course forget which address was the actual BP (esp. when looking back as far as 32, 64, 128 bytes). It would be much, much better if there was a way to show the disassembly output in the way that the BP is in the middle, in bold/with an indicator/whatever and I could see instructions around it in both directions automatically.
Another thing is that "d" command. It works quite confusingly - when I hit a BP, "d" is equal to "d pc". But when I type "d" again, it moves to the next N instructions, depending on screen height. And even more confusingly, if I just press ENTER, it repeats "d", i.e. moves down further. It's a useful feature but then I'm totally lost whether I'm still looking at PC or PC+screen size, there's basically no indication (see the previous paragraph) so what I do is that I always type "d pc", which seems like a waste.
This is related to stepping -- so "d" works with ENTER (which is sometimes nice) but "n" and "s" do not? Why? This would be much more helpful than n, enter, arrow up, n, enter, arrow up, ....
Address / truth prediction - this is really, really misleading when looking at disassembled code. I press "d" and I see all sorts of addresses and T/Fs -- but only one kind is actually true and that is (d)bcc destination address. All the others -- like (an,d) calculation and [content of such address], condition code results -- is mostly a lie because it calculates *current* content of registers and not the values when it will actually reach the point in code (understandably). I would be much happier if there was nothing rather than this misleading information. I bit myself numerous times, especially if that's true for RECORDED history, here I absolutely don't get it -- it's useful only for stored PC addresses/(d)bcc codes dump, all the other information is garbage because it doesn't reflect reality! If we have a limit of 64 instructions here, couldn't Hatari store also the whole context (registers, content of the memory when reading/writeing something etc) so one can actually see what *really* happened?
I can't remember anything else for now, just some food for thought, maybe others have similar problems?
Also, having all said that, Hatari & its debugger has been invaluable help, these are just suggestions to make it even better! :)