[hatari-devel] Execution history debugger command

[Eero Tamminen]

Hi,

On torstai 02 kesäkuu 2011, Nicolas Pomarède wrote:
> > Before running it, does your version have same checksums as the version
> > I just downloaded:
> > $ md5sum Steem.exe steemupdate.exe unzipd32.dll
> > 7d89731bd2bade75cf973ccd308ed50f  Steem.exe
> > 259d0340504a80fdcb2371367c3e704f  steemupdate.exe
> > aaddb5561976f09c2d002d8ebc78d54d  unzipd32.dll
> 
> Yes, I have the same md5sum for those files.

Thanks.

When I ran Steem with Wine the first time, the icons for the Atari window
were always black (but happily they have working mouseover explanations)
and it crashed after use.  After disabling DirectDraw, it started to work
OK.  It's still a bit crashy though.


Steem debugger's features which are missing from the current
Hatari CLI debugger:

* Things that would seem to be straightforward to add:
  - History.  I would need to add tracking also instruction cycles
    to the code I posted earlier
    (= Steem History view & Trace info)
  - Showing values both in different lengts and numeric bases.
    In Hatari one gets latter with "evaluate" command, e.g. "e a0",
    but that doesn't show the value if it were long/word/byte
  - All register values being shown with above info
    (= Steem Register monitor)
  - info commands for PSG, MFP, FDC and IKBD register values
    (= Steem monitors for these)
  - Info command for "timings" i.e. cycles since HBL/VBL, timer values,
    video address & scanline
    (= Steem Timings view)
  - memory dump in text format
    (= Steem Text monitor)
  - Text string and binary values (hex) search
    (= widgets in Steem monitor windows)
  - Disasm format options being changable at run-time
    (= Steem options)
  - Run for N cycles
    (Hatari continue command accepts only instructions, not cycles)

* These would be harder, either because I'm not sure where/how these
  would be best integrated or because they're more work:
  - Monitoring reads & writes to specific address.  Hatari supports only
    monitoring changes to values, not having breakpoints of reading values
    or writing the same value
  - Break on exceptions 2-8 vs. bombs vs. don't break.
    Hatari has only an option to break on address & bus errors
    & uninitialized exception handler.
  - Showing breakpoints in instruction dumps.  Hatari breakpoints
    are more advanced than the trivial address breakpoints...
  - Adding new symbol names for arbitrary addresses one at the time.
    Hatari debugger currently requires new symbols to be added to
    a file containing all the symbols + reloading that file
  - Memory dump that shows also disassembly and values in different bases
    (= Steem Memory monitor)
  - Stack content display
  - Shift Atari screen contents by 0/2/4/6 bytes

(I think rest of the Steem features can be supported by the Hatari
breakpoints.)


Do any of the above listed items (especially the easy ones) sound
interesting to be had in the CLI debugger?

(As I'm already listing missing Monst features as potential TODOs
 for Hatari debugger, I'll add these also to the todo.txt file.)


As to the Steem UI on top of these features, Steem's UI really has a *huge*
amount of functionality integrated to it.  With Hatari it would also need
to work for CPU & DSP as Hatari supports both.

So... I think you need to specify quite in detail what you would like to
have in the debugger GUI and in which priority order before it makes much
sense to start coding it.

--

> > [...]
> Well, if I recall correctly Vice and/or Openmsx are having different UI,
> I don't know if it's possible to mix qt/cocoa, but in that case it could
> be possible to make a QT only UI and use it also on OSX (if the user
> prefers it to the native osx look).

Hm.  Switching Hatari itself from SDL-only to Qt+SDL would be quite large
change.  Before considering that, I'd like to see for a bit longer how well
Nokia manages Qt...


> > While the SDL debugger UI would be bound by the Hatari screen size, it
> > doesn't mean that the output would have to be scaled like the Atari
> > screen is.  Adding --desktop option support for ST mode too and
> > running in fullscreen would guarantee largest possible resolution.
> 
> In my case running --desktop on a 1280x1024 monitor then pressing F11
> doesn't give that much more space (visually it looks the same as if I
> didn't use "--desktop 1")

If you're using ST mode, you need my earlier patch to have --desktop option
effect that too.

Even if the Atari screen content fills only part of the screen
the SDL resolution used by Hatari window is what's important.
Hatari can use all of that area.


> > If Hatari would be running at e.g. 1280x1024, you could fit several
> > hex/asm dumps on same screen...  How many of them you typically and at
> > maximum would want to compare at the same time ?
> 
> Do you mean emulating a 1280x1024 resolution in GEM ? But in that case
> it won't work with demos and games, and those are certainly the only
> candidates for a debugger.

I mean that however the Atari screen is put to the Hatari's window,
that doesn't affect how e.g. debugger could use that area.  If debugger UI
would use 8x16 font, 1280x1024 pixel Hatari window could accommodate 180x60
amount of textual information.


> The problem with single window (everything in Hatari's current window)
> is that once in the debugger, you can't see the ST screen anymore. And
> when you want to debug colors/blitter or other gfx problems, it's very
> important to have the full Atari video screen visible, not overlapped by
> some other informations.
> 
> I know lot of things can be made with ncurses, including using the
> mouse, but what if you want to resize some of those internal windows to
> make an hexa dump bigger/smaller for example ? You need to handle some
> kind of window resizing in ncurse. Same if you want to reorder/move
> those windows inside Hatari.
> Quite a nightmare in the end, reinventing the wheel in some ways, I
> don't think ncurse is the proper solution when you want to handle a
> variable number of windows, with different size and position.
> 
> Having external windows seems really much more useful to me : you keep
> the Atari's video screen untouched and you have a bunch of windows
> locked on registers/asm/hex dump. You're not limited to Hatari's
> resolution, but you can benefit of all the space your OS is giving you
> (if you have dual monitor for example).

Ok, then it really needs a real, modern widget toolkit.

In that case I think it's better to do the UI separately from Hatari
and utilize the remote API.  Only if the remote UI turns out infeasible,
I would go for integrating everything to Hatari binary itself.


	- Eero