I just wonder why listing them in name order instead of address order is more expected.

Because it's easier to find a symbol in an alphabetical-sorted list Most of the time, you know you're looking for a particular symbol (variable name, function name) and you want to show memory/disasm, so looking for the name in a sorted name-list is the natural way to go.

I just wonder why listing them in name order instead of address order is more expected.

Because it's easier to find a symbol in an alphabetical-sorted list Most of the time, you know you're looking for a particular symbol (variable name, function name) and you want to show memory/disasm, so looking for the name in a sorted name-list is the natural way to go.

+1 for alphabetical sort

Tab completion is certainly not taste for a debugger. I still hope for a graphical ui to the Hatari debugger anyway.

The reason why Hatari Python UI debugger part is so rudimentary is that I soon found out that making out-of-process GUI debugger which gets ASCII output through FIFO and parses that, isn't performant enough, and keeping changes on Hatari side in sync with Python GUI is too error prone. Supporting even simplest breakpoints through that would have been way too painful.

I.e. proper debugger GUI needs need to be in-process. And it needs real GUI toolkit, SDL isn't enough for that. There were some mails about writing Qt GUI for Hatari on hatari-devel, but one of the problems with that would be how to integrate e.g. Qt & SDL input handling together. And in general, breakpoint functionality would have needed to be simplified quite a lot to support GUI (doc/todo.txt in Hatari sources has some notes about that).

All of that would be a really large rewrite, I think at least half a year of full time work if one wants to support most of current debugger functionality.

Of course a real GUI would be nicer, but you can do also a lot by using SDL. Look at Steems debugger, which does exactly that. And it has the benefit that you don't have to care about two systems fighting your input events.

Eero Tamminen wrote:All of that would be a really large rewrite, I think at least half a year of full time work

Maybe. But you could start with some basic functionality, then implementing other features that are currently supported.

Of course a real GUI would be nicer, but you can do also a lot by using SDL. Look at Steems debugger, which does exactly that. And it has the benefit that you don't have to care about two systems fighting your input events.

Hi, I agree GUI would need a revamp, but there's a difference between Hatari's UI and Steem's X UI : Hatari's UI is mainly character based (ie you can only put char or put line on a fixed character position), while Steem's dev used their own toolkit, which is X11 based, and can really do gfx/txt on a pixel level.In the end, it makes it rather more complicated to improve Hatari's UI at the moment, better rewrite a new one from scratch using QT (have a look at FS-UAE to see that QT + SDL can get great results), but as already said, it takes a lot of time.Nicolas

ThorstenOtto wrote:The problem with Qt and/or Gtk is that is it mostly unix based. You will have a hard time to deliver a working Qt stack for Win32 and/or MacOS, not to speak about a development environment.

Not sure about that, as far as I know FS-UAE users on Windows/OSX are quite happy with the result GTK might not be WIN32/OSX "compliant" but QT certainly works quite nicely under all 3 OSes, there're several applications that work on all 3 OSes using QT and result is certainly good enough for what Hatari would need.I think there's no point in developping further our own toolkit and to add new functions to it (but of course, anyone is welcome to spend time on it if he wants )

Eero Tamminen wrote: I'm not really sure whether something that primitive would be any kind of improvement over current console debugger.

I'm not sure how others think about this, i myself don't use the hatari debugger too often, but for me it already looks much better than the current console output. You have all important information constantly at hand, without having to type any command. Most commands like step over/step into etc are single keystrokes. Whats also nice is that it already does address decoding, the third column shows the memory that is accessed by the instruction.Ok, it does not have all those nice looking icons, and looks more like an ascii terminal, but do we really need that in a debugger? And it adds a bit to the retro feeling

Dang, the forum SW is acting again, it's revealing the "secret" tags. I'm pretty sure I've been targeted by them too, based on few programming itches I had earlier.

Anyway... If you really happen to take a look at the visual debugger, one of the problems of using the same window is that Hatari's SDL frame buffer size can be anything between 320x200 (unzoomed ST-low) and 2048x1280 (max VDI res), and the size can change at any moment, e.g. because user toggled ST/STE borders or emulated Falcon code changed Videl registers. Separate window would be nicer because then window size can be based on debugger content, instead of content needing to adapt to changing framebuffer size.