[hatari-devel] Bugs and GUI (Was: Little AceTracker question)

Eero Tamminen eerot at users.berlios.de
Tue Jul 20 21:57:07 CEST 2010


On Tuesday 20 July 2010, Anders Eriksson wrote:
> > Aren't there any terminal programs for OSX which you could ask to run
> > Hatari so that you see the debugger in the console?  OSX is unix so
> > missing fully functioning terminal seems strange...
> >
> > One can run any of the Linux terminals like this:
> > 	xterm -T "Hatari debug window" -e hatari
> of course there are is a terminal in OS X, and several more to download
> if you don't like the default one (personally I prefer iTerm).

The question wasn't about whether there are terminals, but whether they have
an option with which you can tell them to launch Hatari in the terminal when
the terminal starts.

Otherwise the comand-line cripped OSX users cannot have a button / icon /
whatever on their desktop that would open both the Hatari and a debugger
window for it.

(Which is trivial on Linux and doesn't require using command line, on
Windows it may need a bit more effort from the Hatari packager.)

> However, I totally agree with Jerome that the debugger should be an
> Hatari window,

If the OSX terminal(s) support something like XTerm's "-e" option, adding
his own terminal implementation into Hatari OSX GUI code would be just
a large pointless effort from Jerome.

> and not used thru third party apps which will most likely be quite
> different on different OS'es. 

All normal unixes (including OSX, Maemo etc) have terminal pre-installed
as does Windows.  So whether users want to use it with a 3rd party app is
up to them.

As to what Hatari does... The API that the Hatari debugger uses is supported
everywhere. Text output functions have been in C since K&R (80's).

It can optionally use a readline library for the debugger command and their
argument completion + history.  Readline is available on all popular unixes
(including MiNT & OSX) and Windows.  Here are some OSX versions:

I would definitely recommend using the debugger with readline, without
command & argument completion the usage is awkward and you don't
immediately see all the alternatives.

Btw. Both building Hatari with readline, having something that invokes
Hatari with a debugger window etc are something that Hatari packagers for
given OS are supposed to do.  It's not really something that Hatari devs
themselves or less skillfull Hatari users should need to do.

> nobody have ever seen or tested the Hatari debugger.

Except for supporting both CPU & DSP debugging at the same time, before
Hatari v1.4 I think the debugger was in general more useful for Hatari
developers than Atari developers.  But I think the v1.4 should've changed

The TAB completion is the main thing, but there are also other usability
improvements (like disassembly address reseting to PC each time you enter
debugger) and some new features that were missing in Hatari debugger
compared e.g. to Monst.

Although Atari's own debuggers have some features than Hatari one doesn't,
there are several situations where emulator debugger is much more
convenient.  Quoting Mickael Pointier:

"Problem of MonST/Adebog/TurboAss, etc... is that they interact with what 
you are currently debugging. Typically an Atari ST demo uses a gazillion 
of timers, replaces the VBl, cut the mfp, etc... and is totally 
impossible to debug with MonST (monst dies as soon as the VBL is 
disabled). You can do it with Adebog in IPL/7, but then you have 
restrictions about what you can do."

And these are the features that Hatari debugger is still missing compared to
        - Shortcut command for telling to run until given
          (temporary) conditional breakpoint is hit
        - Running until code returns from ROM (exiting from super mode?)
        - Single stepping that skips Traps, Line-A, Line-F. And one that
          skips also BSRs and JSRs
        - Command to run slowly
        - Saving machine status to history buffer each time debugger is
          entered (exception or breakpoint is hit) and being able to view
          this history
        - SP & SSP as CPU register names (active & supervisor stack)
        - Fill and copy memory command
        - Search for bytes or strings

As to the last feature, Monst supports also searching instruction (subsets)
but that's too much work & code for Hatari, especially both for CPU & DSP.

Main issue with implementing them is that the list of currently supported
commands is already long and adding more (especially ones that wouldn't
be used) would just make the debugger UI harder to use (read).

	- Eero

More information about the hatari-devel mailing list