[hatari-devel] register locking in debugger

npomarede at corp.free.fr npomarede at corp.free.fr
Thu Feb 11 23:14:50 CET 2010


On Thu, 11 Feb 2010, Eero Tamminen wrote:

> Hi,
>
> On Thursday 24 December 2009, npomarede at corp.free.fr wrote:
>> But in that case, I think that adebog or monst are way more powerful than
>> Hatari debugger, with a built in window system, register locking, search
>> in disasm mode, ...
>
> Nicolas, the infrastructure is now ready for doing register locking
> (I added "lock" as separate command which shares code with the "info"
> command and for conditional breakpoints there was already code for
> handling registers).
>
> I was thinking of this kind of an "UI" for the register locking:
> 	lock regaddr <register name>
>
> But what it should show when entering the debugger?  Disassembly from
> the address pointed by the "locked" register, memory dump, or both?
> For both data and address registers?

Regarding monst, it's possible to lock a register and choose hex dump or 
disasm dump ; this is possible for any register, the fact that it's a data 
or address reg shouldn't limit what kind of dump (as in highly optimized 
code, where all registers are used, it's often possible to store address 
in data reg for example).

I don't know what should be shown ; problem is that if you lock several 
registers it will become quite a mess on screen. My opinion is that some 
extra windows could be used to display locked registers or locked i/o 
spaces (like showing video regs, blitter regs, ...), with only a single 
text terminal as output, I'm afraid more advanced debugging functions 
(those that can display a lot of data) will prove to be hard to use in an 
efficient way.
Perhaps something that should be taken care of in the python ui for 
instance.

> And should this kind of setting be saved to memory state file or
> configuration file?

Maybe this should be saved to a specific hatari_debug.cfg file instead of 
using the memory state ; I think it's better if the memory state file 
changes only (or mostly) when the emulated machine changes, not when the 
ui/debugging interface change.

Nicolas



More information about the hatari-devel mailing list