[hatari-devel] Execution history debugger command

[Eero Tamminen]

Hi,

On maanantai 30 toukokuu 2011, Nicolas Pomarède wrote:
> Le 29/05/2011 22:46, Miro Kropáček a écrit :
>>     And Hatari debugger not being "marketed".
>>     
>>     (I've commented about it on EmuTOS & MiNT mailing lists sometimes
>>     when there
>>     have been issues with which Hatari debugger might help, but I'm not
>>     on any
>>     of the Hatari forums where demo coders visit...)
>> 
>> So true. I think I've got some of your emails starred in the inbox ("to
>> check later") because I was always impressed what is possible with the
>> debugger but then... I always see that strange syntax and fall back.
>> Maybe some tutorials for us dummies would be cool, some popular use
>> cases.

Could you suggest some use-cases that are not (yet :)) documented in
the Manual:
http://hg.berlios.de/repos/hatari/raw-file/tip/doc/manual.html#The debugger

?

> Well, I know it's a lot of work, but I really think something similar to
> the "Steem debug version" UI would be just great and would make all the
> available possibilities shine more than ever.
> 
> Steem really has a great UI when it comes to the debuger : multiple
> windows, click-and-set breakpoints, hexa/ascii dumps, ... All these
> functions are of course available in Hatari, but the UI really makes it
> so much powerful (something similar to the UI provided by MonST, with
> several sub windows in the same window, but really powerful to use in
> the end)

I've thought of expanding the debugger in the Python UI, but there are
some issues:

1. When Hatari enters debugger, note of that and what triggered it needs
   to be sent to the remote UI and remote UI needs still able to be
   command Hatari.  Currently it cannot.

-> I have some thoughts on how to fix this.


2. For some reason after the debugger sends the data to the remote UI
   and the socket is ready on the UI side, UI needs to wait 0.1s until it
   can read the data, otherwise the data is stale.

   I've wondered could it be because the current remote UI is done in
   Python (but that would seem strange as Python has been used to do e.g.
   high performance / high traffic websites).

-> I've thought at some point write a simple native Hatari remote client
   to check whether that helps.


3. People seem to have issues on OSX & Windows on getting everything
   required for Python & Gtk, Qt probably isn't any better in this
   respect...?

-> So, should the remote debugger UI be done in SDL or ncurses?  Both will
   restrict the debugger UI to a single window.  It can of course have
   different areas dedicated for different things, but the available
   space will be fixed & limited.

-> I need UI design on what of the current debugger functionality should
   be in such a screen, how it should be layed out, should there be multiple
   screen through which one can switch (e.g. help), should there be buttons
   one can click with mouse, keyboard shortcuts etc.

Also, if I write a separate debugger UI in C (or C++), this will probably
need Hatari to support sockets for multiple remote clients (one being
debugger, another an UI, third a scripting console...), but I don't think
that's too much of a problem compared to writing the UI itself.


> PS : for those who haven't tried it, just download Steem debug from
> Steem website and simply run it with Wine if you use Linux or OSX.

I don't like binary blobs, could you mail a screenshot of it and tell what
exactly in it is nice?


	- Eero