This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NES: Technique for debugging CC65 code?

NES: Technique for debugging CC65 code?
by on (#203998)
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.

Re: NES: Technique for debugging CC65 code?
by on (#204001)
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?
by on (#204010)
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?
by on (#204021)
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?
by on (#204036)
I use this to get source-level debugging (original C source code visible in FCEUX's debugger):
Re: NES: Technique for debugging CC65 code?
by on (#204042)
NDX ( 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.)