All the action replay cartridges cause excessive crashing in the deebugger as well as you can't type quottes, spaces, return key and more

[bytraper]

The bug happens when you try and use ANY of the action replay cartridges. Sometimes, once it loads you load the file you want, you make some mods to the code, save it from the monitor, restart it and the more you edit, the more chances of crashes as well as the keyboard stops working, firstly maybe quotes, space bar or the return key or any oof the number keys. Using the onscreen keyboard works oce itt starts failing on rettro debugger, but even then you start to lose those too.
Even the return key causes a soft reset for no reason, but it gets worse the longer you use the debugger.

I've only tested all the action replays both bin and crt from retro rom recourses.

The problem happens every time, you can't start the debugger without admin or it just crashes straight to desktop and you have to run it again.
Removing the cart fixes all the issues.

But its obviously crept in between releases. It wasn't in early versions.

[slajerek]

Could you please post video(s) of this issue, how to reproduce?

[bytraper]

Hey Slajerek, really good job with the debugger man, its a fantastic tool (I'm really sorry for all the edits, i'm changing it as i get closer to working out the root of the issue).

The first one is a real bug within the debugger. It seems to have something to do with the way the external auto start load command which overrides the cartridge control (while there is a cartridge image attached) and you double click a d64 disk image that you want to attach to the debugger drive from the FILE BROWSER directory (with the cart image attached and you've just clicked the disk you want mounted). BUT now, unknowingly for you (as the bug doesn't initially show), you've introduced some kind of bug in the debugger that YOU CANT GET OUT OF without a restart.

It then overrides the cartridge's start when it auto starts the first file. So the cartridge image is still active and seems to be all there and working just fine, BUT now, you can start to see the issue isn't with the cart, its somehow caused the debugger to be in a, uh less than stable state now, though for all appearances, it seems to be working just fine (initially).... BUT as you try and use the debugger further and do a few cart freezes, resets, go into the monitor etc, so basically the longer you keep using it and the further from that initial load you get, the more you start seeing bugs (more and more as you keep working). You can load as many .crt or .bin cart images you want at this point and they'll all bug out (the FC3 is the one most likely to show up issues faster than other carts for whatever reason), so we know the issue is with the debugger.

At first, everything seems to be good, but gets worse, as you keep using it) , until even simple things, will just reset the machine or pressing return will suddenly load the disk image again and again, or it keeps crashing back to the AR soft/hard reset screen (same with other carts) or you get freezes of the debugger where no buttons respond. But as you're studying code using the carts own built in monitor (and its the same with ALL carts like AR, SSV, RR, FC3 etc) there starts to be corruption in the debugger itself. Freezes, crashes, non working keys etc (it seems to introduce a whole range of different bugs)

SO the longer you try to use it the worse it gets, like i have to load the on screen keyboard to be able to write just to save changes i made because some of the keys stop registering, almost like you don't have the focus on the c64 screen until it does that FINAL crash which then won't allow you to restart the program. You might now have to attempt to reload it a dozen times before it suddenly boots just fine as if nothing has happened. Some carts like the FC3 will crash a lot faster and even though you're reloading new cart images to test, it just keeps the bug in the debugger and WON'T go away until you close and restart the debugger. Even trying to reset (not restart) it once you've started this bug will cause you ALL types of problems including losing your workspace. So from the moment you've autoloaded a file with the AR attached, you've just introduced a bug in the debugger that stays there until you restart the program (provided you CAN) once its started because i've had to shut down the non responsive program several times.

You should be able to recreate it now, yourself (but sorry its so long winded)

I'm sorry it took me so long to kind of pinpoint. Its because it doesn't show any issues straight away, so it was harder to pinpoint the exact moment when the bugs started happening and why they happened.

It might pay to have the auto load turn OFF when you have ANY cart image loaded? I mean unless you can find why the debugger crashes with the autoload first file option. Turning it off helps retro debugger not crash all the time and become WAY more stable.

But you can see the second bug(?) when the disk file in the directory wipes the cartridge from memory. So, by using the "1541 Disk Directory" to load a .prg file from the disk WILL overwrite EVERYTHING including cartridge images, just by loading a .prg file!?
Not really sure this is the way its intended to work because mounting a d64 disk image with the first load doesn't wipe the cart from memory, but loading a .prg file from the disk directory does.

Three - There is also another bug with the auto program loader when you change disks too fast fast in the file browser (you can see the dirs already in the 1541 disk directory, so you know whats on them before you've moved to the next one) but it crashes retrodebugger completely and you cant restart it when it crashes out and its because the auto program loader is freaking out, and the next time you load the debugger, its still got those files saved in its list i guess.... and wont work or something?? i don't know.