Hi,
On 5/10/20 11:13 PM, Steven Tattersall wrote:
On Sun, 10 May 2020 at 10:08, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
I'm slowly getting there with an initial patch. To make it manageable it
will probably only contain the core bit where the hooks have to go into
the
main loop and route DebugUI via the control socket, not the
implementation
of test debugging commands or the python UI code. Should I send it to you
direct, or to the mailing list?
Just send it to the mailing list. It affects
Hatari main loop so others may have comments on
it too.
What do you think of the idea of doing the disasm
etc output on the Hatari side in SDL2 window, and
just doing the control in the remote GUI process?
It would allow you some quite responsive update/refresh I think.
Using intermediate files for Hatari internal views
could be awkward. So, all the related functions
would need to be changed to support writing to a
string buffer in addition to just to a given FILE.
That can be quite a lot of changes.
However,
even views like disassembly would need to be interactive (for instance,
setting breakpoints) so I wonder if it would get quite messy trying to
arbitrate between external and internal GUI control?
Possibly. I think we need to flesh out a bit more
how it could or should work, both to make the
interaction most sensible to the user and for
code managing them.
How does following sound?
Register & HW info views (updated on every
debugger invocation) don't need any interaction,
assuming they're large enough to show all relevant
content. So they can be controlled completely from the remote GUI.
In the debugger CLI, commands for controlling
them could be something like:
------------------------------------------
view registers -> opens new view
view videl -> opens new view
view list -> lists supported views
registers (shown)
blitter
videl (shown)
...
view rm registers -> removes view
view rm all -> removes all views
------------------------------------------
As to interactive SDL2 views...
User will want to scroll disasm & memdump views,
and I think that's best done with direct view
interaction (using arrows keys and page up /
down).
Setting what memory area should be shown whenever
debugger is invoked, should IMHO be done when
view is configured, but I think it should be
possible to re-configure interactive views without
needing to recreate them.
If view is already open, it will just jump to
a different address:
view memdump <start address> [lines]
view disasm <start address> [lines]
view dspdisasm <start address> [lines]
(If number of lines changes, I guess view SDL2
texture needs to be recreated.)
List of debugger views and their options could
be one configuration dialog in the remote
debugger.
As to breakpoints, I think all the direct user
interaction can also be done on the Hatari side
and remote debugger is just informed of what was
done on its behalf (breakpoint set/unset at
pc=xxxx).
Remote debugger would then just have a window
with a list of current address breakpoints and
their options:
- checkbox: remove after triggering
- counter: trigger every Nth hit
And highlighting for last triggered and/or set
breakpoint.
It should be possible to delete breakpoints from
the remote debugger too, and remote GUI needs to
be informed of breakpoint removals done through
other means than the interactive disasm view.
Some users will want multiple (CPU & DSP) memdump
and disasm views, but I'm not sure whether they
should be supported. If yes, view command needs
indexes for them:
view disasm <idx> <address> [lines]
view rm disasm <idx>
- Eero