CA65 symbols in Altirra debugger

[danwinslow]

Are there any techniques available for getting Altirra to load symbols from CA65, such that they are usable in the Altirra debugger?

[Shawn Jefferson]

I've been meaning to try this for a long time now, and your question gave me the initiative to try it out. It looks like the information from this thread seems to work:

http://atariage.com/forums/topic/223360-altirra-debugger-powerful/?hl=%2Baltirra+%2Bcc65&do=findComment&comment=2953121

 

put -Ln filename.lbl on your linker command line and then load that symbol file into Altirra with .loadsym Don't worry about the leading dot, apparently that is no longer a problem.

 

Bank switching really messes things up though, since the symbol file will have tons of overlapping symbols... I have this problem with my current project.

 

I don't think source file level debugging works in Altirra with the cc65 suite either?

 

@phaeron:

 

If you read this, I think that cc65 suite symbols that end in "__" should be ignored. These are generally speaking all the segment definitions from the linker configuration, which really messes up the disassembly, especially all the *_SIZE__ ones. The _LOAD__ and _RUN__ might be useful for somebody I suppose, but just complicates things for loading the symbols. There are also some internal library symbols *_FILEOFFS__ that also are not useful, and a few others. "*__" should hit them all though.

 

Banked projects are particularly horrible... I wonder if just displaying ALL the symbols for a particular address instead of just one (the first or last read currently?) would be more useful, then the programmer can just determine what bank they are in and pay attention to the appropriate symbol. Might make the disassembly sort of messy, but would make symbols at least useful for bank switched projects.

Edited February 19, 2015 by Shawn Jefferson

[Creature XL]

The symbols get loaded automatically for me. Might be I did something a long time back, but cannot remember if so.
I still use my sed-command, though.

 

http://atariage.com/forums/topic/223360-altirra-debugger-powerful/?do=findComment&comment=2952321

[Shawn Jefferson]

Altirra automatically loads a file with the same filename and extension LBL as the image/file/cart you loaded (mentioned in the help file.)

[danwinslow]

I've been meaning to try this for a long time now, and your question gave me the initiative to try it out. It looks like the information from this thread seems to work:

http://atariage.com/forums/topic/223360-altirra-debugger-powerful/?hl=%2Baltirra+%2Bcc65&do=findComment&comment=2953121

 

put -Ln filename.lbl on your linker command line and then load that symbol file into Altirra with .loadsym Don't worry about the leading dot, apparently that is no longer a problem.

 

Bank switching really messes things up though, since the symbol file will have tons of overlapping symbols... I have this problem with my current project.

 

I don't think source file level debugging works in Altirra with the cc65 suite either?

 

@phaeron:

 

If you read this, I think that cc65 suite symbols that end in "__" should be ignored. These are generally speaking all the segment definitions from the linker configuration, which really messes up the disassembly, especially all the *_SIZE__ ones. The _LOAD__ and _RUN__ might be useful for somebody I suppose, but just complicates things for loading the symbols. There are also some internal library symbols *_FILEOFFS__ that also are not useful, and a few others. "*__" should hit them all though.

 

Banked projects are particularly horrible... I wonder if just displaying ALL the symbols for a particular address instead of just one (the first or last read currently?) would be more useful, then the programmer can just determine what bank they are in and pay attention to the appropriate symbol. Might make the disassembly sort of messy, but would make symbols at least useful for bank switched projects.

 

Hi Shawn - I have bank switching going on but my bank is separately assembled at it's bank address, so there isn't an issue there because I don't have any other banks nor a main that is at the same spot. What I DO have, though, is a chunk of runtime relocated code, which really blows the whole thing up from a symbolic debugging perspective. Just to know, though, I'll give the instructions you reference a try on the non-relocated code. I'll report itt.