Debugging multifile C64 assembly

[mokdevel]

I have a C64 project which is split in to multiple .asm files. In my firstfile.asm, I include my seconfile.asm with !source "secondfile.asm" All is fine and everything works. If I add a break point to the firstfile.asm, it works. Having a breakpoint in secondfile.asm, does not work.

The capability to debug the secondfile.asm is requested.

Second option: As the above may be complex, please add a functionality to combine sources in to one .asm file. This would be similar to Build->Preprocessed file, but has only added the !source "file" in their respective places. All others, like !bin is left as-is. I can then build and debug this single file when needed.

[GeorgRottensteiner]

That's all implemented and ought to work fine. I just tested with a simple file pair and it worked nicely. Could be something about the setup of the project though. On the very first assembly C64Studio doesn't know that the second file is part of the final build.

If that doesn't help can you provide a bit more details, maybe even a really stripped down sample; plus, which VICE version you're using, and the full display of the "output" window.

[mokdevel]

Could be something about the setup of the project though. On the very first assembly C64Studio doesn't know that the second file is part of the final build.

Could be. I have all the files in the solution explorer as a flat structure and included from the firstfile.asm (!source). Did I miss something? The project works perfectly when compiling from firstfile.

[GeorgRottensteiner]

Difficult to say, everything, that is done differently than I'm doing, is bound to be problematic :) How do you set the breakpoint? By clicking into the border, or is it a data breakpoint or one with special settings (only load/store etc.)?

I think it would really help if you could do a small sample where it doesn't work for you. I know it's annoying, but could you also do a short write up how you, step by step, set the breakpoints and start debugging? Plus, please mention if you're using a solution/project, or stand alone files.

[mokdevel]

Sure, I'll provide an example later.

[mokdevel]

Using GTK3VICE-3.7-win64. I've set the debug start address in the project to where my code starts. I set a break point by clicking the border. run+debug.

• Code execution stops at a 'random place'. I hit Debug GO. The previously set breakpoint never triggers.
• I pause the execution. Remove the breakpoint and reset to the same line by clicking the border.
• run+debug and now the breakpoint is triggered. I can now step through code, set new breakpoints etc.

Not sure if this a Vice thing or smth else, but from my point of view the case can be closed. I now know how to use breakpoints even if it's a little tricky.

Thank you for the support and amazing tool. You have re-lit my passion for c64 coding!

[GeorgRottensteiner]

Just out of curiousity, what do you change the debug start address to? If it's the value for -initbreak, this could be the cause of the issue. I let VICE run through the kernal upstart, until it's starting the BASIC loader. The initbreak breakpoint triggers, and now adds all other breakpoints. This avoids triggering breakpoints during the kernal RAM check, which usually nobody is interested in.

Have you tried simply Run-to-cursor? (Ctrl-F10 per default)

I will double check with VICE 3.7. There was a similar issue with 3.5, which would always break into the monitor at a seemingly random location (usually at the time, C64Studio connects to VICE, which has already ran quite a bit of code at that point)

[mokdevel]

Just out of curiousity, what do you change the debug start address to?

I changed it to the address where my program starts. No reason, I was just desperate. :-)

[GeorgRottensteiner]

Closing this, as it's sort of resolved

[mokdevel]

It could've been an issue on my end. A clean installation of tools on a separate machine and I have no issue. Keep it closed. Thanks for the support.

[GeorgRottensteiner]

Thanks for double checking! Feel free to reopen, if you find it happens again.