Re: [hatari-devel] Question on new release and features

["J.Young" <jyoung8299@xxxxxxxxxx>]

On 7/27/22 12:50, Eero Tamminen wrote:
> Hi,
>
> On 27.7.2022 17.18, Nicolas Pomarède wrote:
> > Le 27/07/2022 à 16:13, J.Young a écrit :
> > > On 7/27/22 10:02, Nicolas Pomarède wrote:
> > > > Le 27/07/2022 à 15:14, J.Young a écrit :
> > > > > 1) break on any memory access rw?  I know it was discussed 
> > > > > previously. Was it ever added?
> > > >
> > > > not yet, could be in next release 2.5 I think, whenever it will be 
> > > > released :)
> > >
> > > Ok, thank you.  I remember it was discussed that there was a patch 
> > > already done, but was for private use of the author?
> > >
> > > Maybe the patch could be released on this list just for personal use 
> > > outside the mainline release?  It will probably be a long wait for 
> > > 2.5 :).
> > >
> > > It really is an essential feature of a debugger.
> >
> > Maybe it's available in HRDB by Tat, which adds some debugging 
> > features to hatari, you can try to download it.
>
> Nicolas, I remember you mentioning many years ago having that kind of 
> patch yourself. :-)
Oh, ok, that's the author and patch I was talking about.  Sorry, 
Nicolas, I am not on here very often.  Yes, if that patch could just be 
available for private use outside of the main source for those who want 
to use it, that would be great.  I like using 2.4, but really could use 
that break on memory access now and who knows when 2.5 will be ready.

Pretty please? :)

> > > > > 2) search memory range for value?
> > > >
> > > > neither ; should not be too hard to implement, one could even have 
> > > > a feature that allows mixing text and number :
> > > > eg : 'TOS',0x04,'Version',0x0d,0x0a
> > > Yes, that would be great.  For example, I was looking at the game 
> > > Populous 2 and it had a 50/60Hz PAL check on $820A so it wouldn't 
> > > run on my NTSC machine  Turns out there were multiple checks, so a 
> > > search feature would be nice.  Currently, I have to disassemble the 
> > > program with the debugger and save the listing from my terminal 
> > > buffer and then load it in an editor then do a search. Would be much 
> > > more convenient and productive to be able to do the search in the 
> > > debugger.
> >
> > that's different, it's not a search in memory, it's a search in the 
> > disassembly output in that case, which can be a little slower (but 
> > not that much with today's cpu's).
>
> Disassembly search would require user knowing the disassembly syntax 
> that the search internally uses.
>
> IMHO disassembly search is better done offline:
> --------------
> # where to log disassembly
> logfile disasm.txt
> # show current program code address
> info basepage
> # disasm program code (TEXT) segment
> disasm <start>-"<start>+<size>"
> --------------
>
> One can then grep the "disasm.txt" file for whatever content one 
> wants, even using complex regexps.
>
>
>     - Eero
Oh, I agree with that on the disasm side.  I was thinking more like for 
example I wanted to search for 820A in memory or in a program's range 
then I after it found a match I could disassemble around it.  Memory 
searching is a general feature that would be helpful and reduce some 
manual steps that have to be done currently and really could be 
implemented with not much fuss I would think.

Regards,

Jeff