Moderators: simonsunnyboy, thothy, Moderator Team
Code: Select all
> symbols conio.sym
Reading 'nm' style ASCII symbols from 'conio.sym'...
WARNING: syntax error on line 106, skipping.
WARNING: symbols '_basepage' & '__bss_start' have the same 0x115c address.
WARNING: symbols '_assert_init.part.0' & 'CMakeFiles' have the same 0x4d0 address.
WARNING: symbols '_basepage' & '_edata' have the same 0x115c address.
WARNING: symbols '__bss_start' & '_edata' have the same 0x115c address.
WARNING: symbols '_end' & '__end' have the same 0x11cc address.
WARNING: symbols '_etext' & '__etext' have the same 0x115c address.
WARNING: symbols '__edata' & '_etext' have the same 0x115c address.
WARNING: symbols '_basepage' & '__edata' have the same 0x115c address.
WARNING: symbols '__bss_start' & '__edata' have the same 0x115c address.
WARNING: symbols '_edata' & '__edata' have the same 0x115c address.
WARNING: symbols 'CMakeFiles' & '.LC0' have the same 0x124 address.
WARNING: addresses 0x4d0 & 0x124 have the same 'CMakeFiles' name.
WARNING: addresses 0x17c & 0x570 have the same '.L2' name.
WARNING: addresses 0x124 & 0x1038 have the same '.LC0' name.
Loaded 108 symbols from 'conio.sym'.
> v
Hatari debugger builtin symbols and their values are:
- AesOpcode: $FFFF / #65535 -- $FFFF when not on AES trap
- Basepage: $14964 / #84324 -- invalid before Desktop is up
- BiosOpcode: $FFFF / #65535 -- $FFFF when not on BIOS trap
- BSS: $15BC0 / #89024 -- invalid before Desktop is up
- CpuInstr: $0 / #0 -- CPU instructions count
- CpuOpcodeType: $1 / #1 -- internal CPU instruction type
- CycleCounter: $9516BEC / #156330988 -- global cycles counter (lower 32-bits)
- DATA: $15BC0 / #89024 -- invalid before Desktop is up
- DspInstr: $0 / #0 -- DSP instructions count
- DspOpcodeType: $1 / #1 -- internal DSP instruction type
- FrameCycles: $27244 / #160324
- GemdosOpcode: $FFFF / #65535 -- $FFFF when not on GEMDOS trap
- HBL: $139 / #313
- LineAOpcode: $FFFF / #65535 -- $FFFF when not on Line-A opcode
- LineCycles: $44 / #68 -- is always divisable by 4
- LineFOpcode: $FFFF / #65535 -- $FFFF when not on Line-F opcode
- NextPC: $E0FB28 / #14744360
- TEXT: $14A64 / #84580 -- invalid before Desktop is up
- TEXTEnd: $15BBF / #89023 -- invalid before Desktop is up
- VBL: $3CF / #975
- VdiOpcode: $FFFF / #65535 -- $FFFF when not on VDI trap
- XbiosOpcode: $FFFF / #65535 -- $FFFF when not on XBIOS trap
>
Eero Tamminen wrote:Done: https://hg.tuxfamily.org/mercurialroot/ ... d0dfa775f2
I just wonder why listing them in name order instead of address order is more expected.
Code: Select all
> address _<TAB>
Display all 451 possibilities? (y or n)
_Getcookie ___mpn_mul_n _atof _mt_appl_find
___PRETTY_FUNCTION__.3476 ___mpn_rshift _atoi _mt_appl_init
___PRETTY_FUNCTION__.3649 ___mpn_sub_n _base_table _mt_appl_write
___access ___mpn_submul_1 _bcopy _mt_evnt_button
___adddf3 ___muldf3 _binops _mt_evnt_multi
___addxf3 ___muldi3 _blanks _mt_evnt_timer
___assert_fail ___mulsi3 _bzero _mt_form_alert
...
--More--
npomarede wrote:Eero Tamminen wrote:Done: https://hg.tuxfamily.org/mercurialroot/ ... d0dfa775f2
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.
simonsunnyboy wrote: I still hope for a graphical ui to the Hatari debugger anyway.
Eero Tamminen wrote:And it needs real GUI toolkit, SDL isn't enough for that.
Eero Tamminen wrote:All of that would be a really large rewrite, I think at least half a year of full time work
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.ThorstenOtto wrote:Eero Tamminen wrote:And it needs real GUI toolkit, SDL isn't enough for that.
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.
npomarede wrote:while Steem's dev used their own toolkit, which is X11 based, and can really do gfx/txt on a pixel level.
npomarede wrote:better rewrite a new one from scratch using QT (have a look at FS-UAE to see that QT + SDL can get great results)
npomarede wrote: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.
ThorstenOtto wrote:Shouldn't be too hard to get a simple frame working, that just displays some assembly lines, cpu registers etc. From there you can start adding features from the current debugger.
Eero Tamminen wrote:Would you implement it with a window separate from Hatari window, or draw it to the already existing Hatari window?
Eero Tamminen wrote: Anyway, I'm interest to see your prototype code.
Eero Tamminen wrote: I'm not really sure whether something that primitive would be any kind of improvement over current console debugger.
ThorstenOtto wrote:Hm, did i say i'm going to implement that?
Eero Tamminen wrote:No, but you're having an irresistible itch about it that you cannot help scratching, aren't you?
Users browsing this forum: No registered users and 1 guest