NES: Technique for debugging CC65 code?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
Posts: 139
Joined: Mon Jul 03, 2017 4:37 pm

NES: Technique for debugging CC65 code?

Post by tschak909 » Tue Sep 05, 2017 11:05 pm

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.


User avatar
Posts: 7897
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada

Re: NES: Technique for debugging CC65 code?

Post by rainwarrior » Tue Sep 05, 2017 11:27 pm

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.

Posts: 1246
Joined: Tue Oct 06, 2015 10:16 am

Re: NES: Technique for debugging CC65 code?

Post by calima » Wed Sep 06, 2017 2:27 am

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.

User avatar
Posts: 2775
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG

Re: NES: Technique for debugging CC65 code?

Post by dougeff » Wed Sep 06, 2017 4:38 am

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. -- blog/tutorial on programming for the NES

User avatar
Posts: 136
Joined: Wed Oct 16, 2013 7:55 am

Re: NES: Technique for debugging CC65 code?

Post by dustmop » Wed Sep 06, 2017 9:03 am

I use this to get source-level debugging (original C source code visible in FCEUX's debugger):

User avatar
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland

Re: NES: Technique for debugging CC65 code?

Post by thefox » Wed Sep 06, 2017 9:29 am

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.)
Download STREEMERZ for NES from! — Some other stuff I've done:

Post Reply