Would using 'history' command help?
Not really. For instance, consider code:
moveq #32-1,d7 ; default init
some_loop:
<some functionality>
some_label: ; d7 initialised elsewhere
dbra d7,some_loop
so if something jumps to "some_label", I always have to scroll up to see what kind of loop it is (one can argue that further stepping will bring me there but that is also not always the case plus I would miss the default initialiser completely). "history" wont help either. I really need to see what's around that instruction to make sense of the whole loop.
One problem is some instructions have different
sizes, so disassembly output is potentially wrong
in the beginning when it's started from fixed
negative PC offset.
I could totally live with that (as I do now when doing "pc-16"). Default history enabled could help here a bit, too (IMHO it is better to have a slightly worse debugger performance when gains are so big).
Another problem is that debugger does not actually
know at which address breakpoints are, because
they are for all kinds of conditions, not just
(or even mostly) for PC addresses.
I suspected that much -- but I think at one point a decision has to be made that the disassembly output can't be just blindly taken from the WinUAE code but it needs to be "smarter". That reminds me, how is this solved in WinUAE itself? It surely doesn't show just raw disassembly from the core in its window.
[Debugger] section in Hatari config file has
variables to control how much output there is
in specific situations:
--------------------------
nBacktraceLines = 0
nDisasmLines = -1
nMemdumpLines = 4
nSymbolLines = -1
--------------------------
So you can limit it to smaller amount
("-1" is unlimited, i.e. until screen end).
This is a good hint, thanks. Still, only a workaround.
Would it be better if:
* "d" would always show disassembly from current
PC unless an address is specified?
* ENTER would still advance the disassembly?
IMHO yes but I'm sure you'll find other people who like it as it is. I'd say make it configurable but yes, yet another config option...
* Disassembly not changing emulation state, while
stepping does, and recovering from stepping
accidentally (too much)[1] is not really viable
for hard to reproduce bugs
SHIFT+ENTER isn't a possibility? (not sure how that parsing works) Or, again, make it configurable. For me the price of an accidental step is much lower than the annoyance of repeating two key presses again and again (one can argue that I can press the up arrow more than once by accident and execute a totally different command so it's not fool-proof either).
Is use of 'n <instruction type>' not of help,
e.g. "n return"?
Not always but thanks for reminding me about this feature! :)