What requires? and some suggestions

[St0fF-NPL-ToM]

Hey Slajerek,
since finding back my C64 fun I found even more fun using Retrodebugger.

I managed to write a CMake script that could be run post-build on ACME labels files to generate Retrodebugger .labels and .watches files.

What exactly does RetroDebugger expect to sit next to the .prg file to be autoloaded after the .prg file?

• tested to have the .labels and .watches files keep the same filename stem with the .prg - doesn't seem to be right
  • i.e. Player_4.0.prg is loaded, in the same dir: Player_4.0.labels ... not loaded

I read it expects a .dbg file. The specs are pretty simple atm. inside the repo. So as I already did some changes to ACME, I'm eyeing on adding the minimum debug file output into ACME.

Did anything change about the .dbg specs?

What about making the watches export "NOT" export the addresses? After a reassemble, Adresses might have changed and are provided via labels file.

What about breakpoints? I'm missing a label name in the exports. I'd also rather have a list of Breakpoints on labels (not only on addresses).

[slajerek]

Ugh, you're right. The specs for dbg file are slightly outdated. We changed file format with Mads. I need to update them, however changes are subtle.

The *.labels, *.watches and *.breakpoints should be loaded automatically, but also you can load them via command line (-breakpoints, -symbols, -watches). If they are not loaded there might be some bug, I'll check. They are deprecated anyway, as we have *.dbg file format.

I suggest to export some dbg from KickAss and see what's inside, it's pretty straightforward format. After re-assemble and file reload I match labels to new locations. The dbg file should be in the same folder and with the same name as prg file (e.g. player.prg, player.dbg).

If you would like to write your own exporter, you can also reach to Stein Pedersen, he added dbg export to cc65 recently:
https://github.com/Galfodo/ld65-to-kickasm-debuginfo-converter

Also you also can review this part of code with dbg file loader:

RetroDebugger/src/DebugInterface/Symbols/CDebugAsmSource.cpp

Line 67 in 5b68b96

void CDebugAsmSource::ParseXML(CByteBuffer *byteBuffer, CDebugInterface *debugInterface)

[St0fF-NPL-ToM]

Thank you so much for replying.

About not working autoload of 'SameName(.labels|.breakpoints|.watches)':

Maybe I created a special case with my filenames Player_4.0.<EXT> and spotted a "only matching filename until the first dot" or something - bug? Once checking from the front, in another codepart checking same string from the back?
Still, for the time being, keep that c0de ;). I'd even suggest to change the menu and dialogs around label-, watches-, and breakpoints-export and merge 'em into one. So the user has one "clear", one "import" and one "export" menu option to select f.e."debug setup". In the im/export dialog there's the standard file selection, but at the bottom user can select via checkboxes which data to export/import.

Why? Well, my script indeed looks for "exported.watches" and "exported.breakpoints" within the relative path that both files share (i.e. the script file and the target file). So you subsequently build up your debug view in the RetroDebugger while coding. Save debug setup after changes, the script merges it with the ACME labels. At the end my script could spit out just one file containing all labels, watches and breakpoints together. And as it's a CMake script, it can be run manually or appended to the build toolchain as a post build step ... so except for the code view, I have all data collected to create a.dbg file?

Ty for the reading hint. That's all I needed (get pushed with the nose onto this )

[St0fF-NPL-ToM]

Suggestions:

• document the existing watches types (the strings KickAss .watch $c0de,$c0de,"wants here")
  • maybe make it interpret fixed length Arrays via f.e. "hex8[48]" or .watch 8bitlist, 8bitlist+len, "hex8[]"
  • maybe make it interpret lo/hi arrays via .watch lo_table,hi_table,"hex16le[]" (calculate the length using abs(lo_table-hi_table) )
• add a new type of debug view: TableView
  • declare rows by labels or even combinations (i.e. tb_lo: .fill $20,0 ; tb_hi: .fill $20,0 can be combined into a 16Bit-View)
  • dynamic length via "count"-label, static length via constant, undefined length via shortest distance between given rows
  • maybe horizontal/vertically switchable? (items as rows, items as columns)
  • option to break on any writes/reads, specific table parts write/read

[St0fF-NPL-ToM]

P.S.: I documented in discussions, so you can just copy and paste wherever it fits.

About: TableView

What if you made the Memory Map more configurable - so the TableView would simply be a small restricted Memory Map ... (of which you could open a few, or declare multiple tables in one view ...)