Breaking at start address doesn't seem to be working as expected

[georgrottensteiner]

Breaking at start address doesn't seem to be working as expected

[GeorgRottensteiner]

Nice catch! This looks like a racing condition. VICE is running cart code before C64Studio manages to connect to the remote monitor. Once you're in VICE and connected, you can break with C64Studio (the pause symbol) and go from there. Obviously that's just a work around, I'll try to find a way to get into it from the start.

[GeorgRottensteiner]

I've checked in an attempt, that seems to work now for both carts and normal programs.

Please let me know if it works fully as intended.

The "solution" works by breaking into the debugger once the socket is connected, adding the required breakpoints and hard resetting VICE. So a part of the cart may actually start running before the reset kicks in!

[fade0ff]

I tried that solution and it doesn't break automatically anymore (i.e. no initbreak parameter and DebugStartAddress is ignored). Is this intended? If so, it's a bit strange that the DebugStartAddress can still be set and the initbreak parameter is displayed under tools but then ignored when debugging.

So I need to break, set a breakpoint manually at 0xf000, stop/restart debugging and then (the 2nd time), the debugger starts at the first instruction. I tried this with the previous version and there it wouldn't work. So this is definitely an improvement. Personally, I could live with this but if DebugStartAddress and initbreak are deliberately ignored, wouldn't it make sense to remove them?

[GeorgRottensteiner]

initbreak is not used for cartridges, I kept it for non carts though. The DebugStartAddress should be used, not via initbreak, but indirectly with the -moncommands file.
If it isn't, then that's a plain bug in my "solution".

Regarding setting a breakpoint at $f000, is that address used as jump vector in $fffc?
It could be that I need to attempt your exact constellation. Could you provide an as short as possible sample that exhibits the wonky behaviour?

[fade0ff]

Yes, 0xf000 is used for the jump vector. The binary also works in a real cartridge.
Just as an example, not for anything else, a version of kinzi's Dead Test modification 004 with a very few changes to improve the LED blinking on the tape port:
Dead Test.zip

[GeorgRottensteiner]

Ah, I think I finally understand and found the cause. I've checked in a potential fix. The address configured as debug start address is now actually used as first intermediate break point, similar to "Run to cursor".

[fade0ff]

Yep, this works for me. Great support as always. Thanks!

[GeorgRottensteiner]

Goodie :)
Closing this then.