[hatari-devel] Debugger breakpoints for Hatari variables too?

[npomarede at corp.free.fr]

On Sun, 9 Aug 2009, Eero Tamminen wrote:

> Support for LineCycles and FrameCycles is now commited, I hope it helps in
> debugging the video.c interrupt issues. :-)
>
> Please test, it needed touching many places in breakcond.c so there could
> be some regressions.  But after this it will be easy to add more accessors
> or Hatari variables there.
>
> 	http://hg.berlios.de/repos/hatari/
>
> I also commited the number base change support code and large update
> to the manual.  I put a box around all the <pre> command line output
> excerpts in the Manual, I hope you like them, see:
> http://hg.berlios.de/repos/hatari/raw-file/tip/doc/manual.html#The debugger
>


I tested it, and this seems OK.

I see a little possible improvement, but perhaps it's too specialized to 
be added : when using LineCycles as a beakpoint var, we should warn the 
user if the value is not a multiple of 4, as LineCycles so far can only be 
this way. There could be a ValidMask, and we would warn
 	if ( value != value & ValidMask )

Some variables could also have a mix/max limit, but this is harder to 
determine as it can change dynamically (nHBLs depending on freq 50/60). I 
think it's easier for the user to pay attention to the range, than to 
check if a value is multiple of 4 for example.


Nice cleaning of the debugger anyway, good job.

One remark, from my use, I think it's better to avoid scrolling and to 
display as little lines as possible in the terminal, so I think it could 
be more efficient when using 'v' to replace :

> v 127
Value '127' is in the supported number bases:
- bin: %1111111
- dec: #127
- hex: $7f

with :

Value '127' is : %1111111 (bin)  #127 (dec)  $7f (hex)

That is, everything on one single line.


> Do you have a proposal patch for debugui.c?  I'm not sure what it should
> look like...

Sthg like :

PC=xx  VBL=xx FrameCycles=xx HBL=xx LineCycles=xx

Rather simple, but I think in the end people that use the debugger will 
care for immediate visibility of the values, so avoiding "words" seems 
more efficient.


Just my preferences anyway, perhaps others have different ideas ?


Nicolas