Debugger Enhancements v2

[kktos]

Changes

• change the repo arch to have sub dirs for SRC, OBJ
• add INI file for setup; works in // with CLI parms - "x16emu.ini"
• place the debugger in its own window
• add a true console to debugger
• add some fonts for setup
• add symbols in disasm
• add many bps, up to 10
• add a bunch of commands to the console - shamelessly inspired by AppleWin console

Commands

• m [[bank]address]
  display CPU memory [at the given address]. If not specified the current bank will be used.
• v [address]
  display VIDEO memory [at the given address].
• e address values....
  set memory at address with values
• f address value length [increment:1]
  fill CPU/VIDEO memory
• sh address,length|start:end value0 value1 ...
  search CPU/VIDEO memory in range (addr,len or start:end) for bytes
• d address
  disasm from address
• b rom|ram bankNumber
  set RAM or ROM bank
• r A|X|Y|PC|SP|P|BKA|BKO|VA|VD0|VD1|VCT value
  set register value
• sec
  set carry
• clc
  clear carry
• sec
  set zero
• clz
  clear zero
• sei
  set interrupts disabled
• cli
  clear interrupts disabled
• sed
  set Decimal mode
• cld
  clear Decimal mode
• seb
  set break
• clb
  clear break
• ser
  set reserved/not used
• clr
  clear reserved/not used
• sev
  set overflow
• clv
  clear overflow
• sen
  set negative
• cln
  clear negative
• bpl
  list breakpoints
• bp address
  add a breakpoint at the specified address
• bpc bp_number|*
  clear a specific breakpoint or all
• ?|help
  display help
• sym [address|symbol]
  look-up for the address or symbol and display it
• symclear bank [symbol|*]
  clear the "symbol" or "*" all from the symbol table for specified bank
• symload [bank] symbolFilename
  load the symbol table [for the specified bank]
• symdump symbolFilename
  dump in a file the symbol dictionary
• code
  Toggle the display in full page of code/disasm
• data
  Toggle the display in full page of data
• font [Name|ID [Path]]
  Display loaded fonts or Set the debugger font or Load and Set the debugger font
• romdebug
  toggle ROM debug mode to allow editing
• info
  display X16 emulator & debugger info

[kktos]

Here is an example of the x16emu.ini file

[main]

; scale: 1 | 2 | 3 | 4
scale = 2

; warp: yes | no
warp = yes

; keymap: one of
;          en-us
;          en-gb
;          de
;          nordic
;          it
;          pl
;          hu
;          es
;          fr
;          de-ch
;          fr-be
;          pt-br
; keymap = en-us

; geos: yes | no
geos = no

; test: test ID to run
;test = 0

; echo: raw | iso
;echo = raw

; quality: nearest | linear | best
quality = best

; joy[1-2]: NES | SNES
joy1 = 
joy2 = 

; abufs: integer
abufs = 8

; dump_[cpu | bank | ram | vram]: yes | no
dump_cpu = no
dump_ram = no
dump_bank = no
dump_vram = no

; log_[keyboard | speed | video]: yes | no
log_keyboard = no
log_speed = no
log_video = no

[dbg]
enabled = yes

; font filepath used by the debugger
; font = oldschool.bmp

; window background colour
; bg_color = 0x2020FF

; colour of transparent rect drawed when the mouse is over a debugger zone (data/code/stack....)
; focus_color = 0xF0F0F0

; debugger debug feature to display where the mouse is
; showMouseCoord = yes

; colours used on VRAM display
; vram_tilemap_color = 0xFF0000
; vram_tiledata_color = 0x00FF00
; vram_special_color = 0x0000FF
; vram_other_color = 0xFFFFFF

; breakpoints list, up t0 10
; BP0 = 00:enter_basic
; BP1 =
; BP2 =
; BP3 =
; BP4 =
; BP5 =
; BP6 =
; BP7 =
; BP8 =
; BP9 =

;
; [dbg_ini_script]
; list of commands to execute on launch
;
[dbg_ini_script]
0 = symload 0 kernal.sym
1 = symload 1 keymap.sym
2 = symload 2 dos.sym
3 = symload 3 geos.sym
4 = symload 4 basic.sym

[dbg_console]

; font filepath used by the debugger console
; font = consolas10.bmp

; console background colour
; bg_color = 0x202020

[indigodarkwolf]

Ooh, I think I like this. I'm hoping it's accepted.

[gaekwad]

Are you looking for feedback on this? I decided to play around with it a bit (it's really cool), and I'm seeing some strange behavior that I'm not sure if it's just because I'm configuring something wrong.

For one, there is no "x16emu.ini" supplied by default and the emulator seems to freeze if you try to open the debugger without it. So I had to copy your example one from above to even get to try it. I'm sure the plan is to add a default one to the repo at some point, but I just thought I'd point it out.

Another strange behavior, the background color of the main debug window seems to always be black no matter what I set the bg_color under [dbg] to. The console background color seems to work though (set under [dbg_console]). From a little bit of poking and experimenting, it looks like if I disable drawing the console in DEBUGRenderDisplay, it uses the right color.

Lastly, the highlighted row in the code area seems to stay statically in the middle when I use the mouse wheel to scroll in it, causing it to not highlight the actual PC row anymore.

[kktos]

@gaekwad
Thx for testing. Much appreciated 👍
-1- no-ini-bug fixed
-2- colours use C hexa number format, that is

; window background colour
bg_color = 0xFF0000

for a red background (RGB)
For instance, I'm using a dark grey in my conf:

[dbg]
enabled = yes

; font filepath used by the debugger
font = consolas10.bmp

; window background colour
bg_color = 0x404040

-3- highlight pc fixed.

[gaekwad]

Yup, that's how I'm doing it in mine. This is what mine looks like (I actually grabbed this from one of your screenshots because I liked the way it looked)

 ; window background colour
 bg_color = 0x383838
 
 ; colour of transparent rect drawed when the mouse is over a debugger zone (data/code/stack....)
 focus_color = 0xF0F0F0
 
 label_color = 0x8080FF
 data_color = 0xFFFFFF

And this is what it looks like.

If I try commenting out "CON_DrawConsole(console);" in "DEBUGRenderDisplay" this is what it looks like:

The background color is what I expect, but obviously the console isn't being drawn.

[indigodarkwolf]

I hope my PR to main.c doesn't conflict with this. @mist64, if you're inclined to accept the debugger improvements, then please be sure to merge this in before #317.

[indigodarkwolf]

Oh man, I just realized, because you moved literally every source file, you've made reconciling this PR with any other changelist completely impossible.

[kktos]

@indigodarkwolf Not exactly ;) Upon closer look, you may see that nothing was moved but the debugger source.
I've added the console sources in a dedicated folder and I moved the related debugger sources in a folder.
Tried to have everything set in an orderly fashion.
Anyway, if you wanna merge, you can do that PR last. And I'll rebase. No worries ;)

[indigodarkwolf]

You misunderstand. Yes, the files were technically "moved". Git sees it as "the files were deleted", plus "a bunch of new files were added."

Any attempt to reconcile changes from any other pull request will fail, and they must be re-done by hand.

[kktos]

That’s why I told you the other PRs can be merged before. Then I’ll do a rebase and then the PR could be merge.
No worries;)

[lmihalkovic]

hmmm .. don't take this the wrong way (I work on large scale projects with 10s of developers): PRs that mix functional with structural changes are effectively a maintainer's nightmare ... it is always easier on everyone when the 2 happen separately... same for the 'ini setup' ... a super great idea.. but should it not be its own separate PR? or even the enabling multi letter commands on the debugger? ... I know it is a pain ... (I am dealing with the same thing via all my memory management changes .. painful to keep them all as separate layered branched)

I you allow me a small thought?! ... I would eliminate ini and replace it with JSON. this would allow hierarchical definitions.... for eg:

debugger: {
   color: {
      "vram_sdfsd" :  "col1", 
      "vram_sdkfjsdkfj" :  "col2", 
   },
  'some_other_stuff': {
  },
  'bindings': [           // THIS IS AN OPTION... TO CLEAN THE KEYS PROCESSING CODE
     'key':  'SDL key def',
     'command': 'the thing to bind to'  //  => yes .. it means having the code structured as 
                                        //     independent functions .. and not a giant switch case... or you can just 
                                        //     have a switch case on a 
                                        //          cmd_token_t command_token = get_command_name_from_key(SDL_KEY_RECEIVED);
                                        //          switch(command_token) {
                                        //             case DBG_CMD_1:
                                        //                 current code
                                        //          }
  ]
}

the point being that someone can grab an entire section with having to wonder if they have it all or not

[kktos]

hmmm .. don't take this the wrong way

I don't as you're absolutely right.
Same here, working with a team. I broke a lot of rules I'm following usually...
I should have probably make the PR with some initial commits then do a branch in my repo and kept working on it.
As a matter of fact, that is what I'll do as there are so much things I want to do on this code.

I you allow me a small thought?! ... I would eliminate ini and replace it with JSON

I went for INI files as there are pretty easy to deal with, with not to much code to add to deal with them.
But that's not very modern :)
Now, about JSON, okay, but for such a file which needs to be humanly edited, I'd rather go for YAML. Better readability with roughly the same amount of code as for to process a JSON file.
I'll check if I can find a decent lib/code for that.

[lmihalkovic]

yes .. yaml is ok too ... but then TOML is also another alternative (if you want to stick with .ini style syntax). the point for me is the hierarchical nature of the info

.. and the keymap crap .. I basically took inspiration in the VSCode way of doing it ... I think they have it really done well

[kktos]

no, I don't wanna stick to INI. And TOML is too hybrid I think. YAML is a better solution. Wide spread so big chances to find libs dealing with it

keymap. ok.
Have you done something too ? I can replace my code with yours. I like the VSCode way.
I've based my code on SDL abilities. that's the lazy way, not necessarily the best way.

[mist64]

This is HUGE.

And I love it.

Sorry,

• I'm late
• I merged Proto #2 support, which broke this merge. Can you update?

Config file comments:

• INI or TOML yay, JSON nay
• I would suggest #404040 syntax instead of 0x404040 syntax for colors, but no biggie

[kktos]

@mist64 Doh... I'm useless..... I wasn't able to manage the update of this PR therefore I created a new one based on the last changes you made.
#338

• config file: I'll check for a yaml lib
• colours: ok, I'll see what I can do about it

[mist64]

Superceded by #338.