|[hatari-users] Re: Hatari UI bios-intercept option
[ Thread Index |
| More lists.tuxfamily.org/hatari-users Archives
Please post either to hatari mailing lists (hatari-devel or
hatari-users), or to Atari Forum Hatari section (mailing list is
preferred), so that others benefit also for questions & answers.
I've CC'd this mail to hatari-users.
On 13.11.2022 23.08, Cédric Bourse wrote:
I recently moved to Linux as my main OS and I'm trying to convert my Atari Falcon compiler toolchain/debugger from windows to this linux.
I discovered your really great UI tool for hatari, and the graphic debugger included, which is very nice because debugging the Falcon is not as easy as using the awesome Steem gui debugger for the ST/e.
Anyway, I think it lack a major dev feature that I'm trying to setup, it's the "--bios-intercept" option, which would allow me to stop my program at a precise point using "Dbmsg()" and debug it step by step from there.
Maybe there is another way, but I'm trying to start hatari with the option "--bios-intercept" and I don't know where to do that you the python script (I'm not familiar with python language)
Could you tell me where to modify the python script to include that command ?
Or if there is another way to interrupt a program at a precise point in the code so that I can debug it using the GUI debugger ?
1. "--bios-intercept" has been deprecated for a long time. Use NatFeats
- Example code:
- Docs: https://github.com/aranym/aranym/wiki/natfeats-proposal
2. When using external GUI, that is in control, not the emulator, or a
program running in the emulator. I.e. you cannot invoke things in GUI
from the emulator. That would need something completely new to be added
both to Hatari and Python UI
3. Debugger part of Python UI is just minimal thing, it's not intended
for serious use, and never going to have many of the useful features in
the Hatari's CLI based debugger (more of these below)
4. If you really want GUI debugger with Hatari, I've understood that
TAT's Hatari fork is quite nice: http://clarets.org/steve/projects/hrdb.html
Some of the nice things provided by the CLI debugger:
* Symbols and control for them
* Profiling, both for CPU & DSP code (cycle-accurate for 68000)
* Program backtrace when entering debugger, if symbols were loaded and
profiling enabled earlier
* Execution history (for addresses)
* Conditional breakpoints
* Tracepoints (breakpoints that output tell when specific OS call is
done, or specific memory address contents change)
* Scripting by chaining breakpoints
CLI debugger is nicer if you automate profiling and debugging actions +
post-processing of the data it provides.
If your program can automatically invoke things that you want to profile
or debug, all the better.
While it's no so nice for "live" debugging as GUI debuggers, at least it
has help, TAB-completion and automatic repeats for some commands.
Debugger manual "Usage examples" sections is good starting point: