Page 1 of 1

NES: Technique for debugging CC65 code?

Posted: Tue Sep 05, 2017 11:05 pm
by tschak909
Hey guys,

Does anyone have a technique for debugging CC65 code, specifically mapping variables to RAM so that I can e.g. watch and trap in FCEUX's debugger? Usually with 6502 assembler, the memory map is simple enough, I know where my variables are, at the very least, I can derive them from an output listing. Not so much for CC65... Can someone point me in the general direction, as I have a _really_ weird edge case in my maze traversal code for wizard of wor that I need to catch.

-Thom

Re: NES: Technique for debugging CC65 code?

Posted: Tue Sep 05, 2017 11:27 pm
by rainwarrior
Compile and/or assemble with debug information (-g), and tell the linker to output a label file (-Ln) or a debugging file (--dbgfile), whichever format seems more convenient; dbgfile has more info, slightly trickier to parse.

Convert those labels to an FCEUX debug file and you can see those symbols directly in its debugger.

A while ago I wrote a simple python -Ln to .NL parser for an example: thread

If all you're looking for is the address things end up at, though, you could just keep the label/debug files open in a text editor and search for them by name as you need their addresses.

Re: NES: Technique for debugging CC65 code?

Posted: Wed Sep 06, 2017 2:27 am
by calima
You get the map files as usual, "-m mapfile" and "-vm" for verbose maps to ld65/cl65. Note that only static/global vars can be tracked, stack vars change locations.

Re: NES: Technique for debugging CC65 code?

Posted: Wed Sep 06, 2017 4:38 am
by dougeff
Also, in FCEUX, there is a way to record button presses, so set record...get the bug to happen...pause, rewind a few frames, turn on the trace logger, and run a trace on the exact frame (or 2) where the bug happens.

I don't usually do this.

Usually I have a dummy function I call "debug()". All debug does is increment a known address. Then I place a call to debug() right before the code I'm checking. I can set a breakpoint for the address, and step through the code, while looking at the .s output file from the .c code.

Re: NES: Technique for debugging CC65 code?

Posted: Wed Sep 06, 2017 9:03 am
by dustmop
I use this to get source-level debugging (original C source code visible in FCEUX's debugger):

https://github.com/dustmop/annotatecc65

Re: NES: Technique for debugging CC65 code?

Posted: Wed Sep 06, 2017 9:29 am
by thefox
NDX (https://kkfos.aspekt.fi/) also supports source level debugging for C. It does kind of work, but I haven't tested it much. The main issue is that since there's a corresponding ".s" assembly source file for each compiled ".c" file, it will sometimes try to display the ".s" file even though it doesn't exist. I guess I should fix that some day...

Watch window also works for statically allocated variables as long as you add a "_" before the variable names (variable "foo" becomes "_foo"). Stack variables don't work. If variable addresses is all that you care about, you can get the same information from a map file, though.

(NOTE: You have to generate debug information for this to work, e.g., pass -g -Wl --dbgfile,test.nes.dbg to cl65.)