| |
Moloch
Registered: Jan 2002
Posts: 2893 |
Release id #148664 : C64 Debugger V0.5
Certainly will give this a test run shortly, looks very handy. Hopefully a version that supports current VICE is released. |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
yup as said in the entry, would be nice to develop a patchset so new VICE versions can be used easily :) |
| |
DKT
Registered: Aug 2004
Posts: 96 |
I'm sure we can expect it very soon from Slajerek. |
| |
Fungus
Registered: Sep 2002
Posts: 616 |
Good good, always needed a good debugging system. |
| |
Angel of Death
Registered: Apr 2008
Posts: 210 |
Have been trying this and ran into a few things (probably related).
These two productions, as far as I have tested, of ours result in a "CPU JAM OCCURRED" message during unpacking while they work fine in VICE 2.4 c64sc itself:
Madheader 2
Swing Crazy
And after that I can't reset the emulator anymore with CTRL-R or SHIFT-CTRL-R. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
Indeed, load from d64 instead of prg and they will run, probably some emulation bugs if tde is inactive. Prolly related to the fact this is based on old Vice build.
I noticed the same cpujam+endless lockup (and random other behaviour) loading another release as prg, but that prg accessed disk via kernal routines: Turbo Outrun (works if loaded from d64)
Editable keyboard settings would be better, for example
I have no ` (~ tilde key), it seems mapped to the key on right of L (for me it's @). Normally on C64 that's the key I press to type ":", now all keys are in different positions.
Placing C64Debugger.exe in the same vice dir loads something from the vice.ini but messes up things, keyboard for example doesn't work properly anymore (no shift working, random other keys not working) |
| |
Slajerek
Registered: May 2015
Posts: 62 |
Thanks for the testing guys.
The Madheader 2 indeed locks with CPU JAM for me during decrunching but only when AR cart is attached. I was able to run D64 without problems on debugger with pure no-cartridge environment.
Regarding automatic PRG startup I've found a small bug with this. In this version I'm loading PRG directly to memory, detecting if it starts from $0801, checking for SYS basic command and parsing the argument address, and finally making JSR automatically to that address (thus, I'm not using Basic procedures for this at all and I keep TDE always active), you can check code here: CViewMainMenu.mm (starting from line 397).
The problem is that I forgot about Basic pointers $2D/$2E-$31/$32. Some decrunchers are using these pointers to find what to decrunch, and thus unexpected behaviour can be seen because these pointers were not set. I've fixed this already and will be in next version, will push code update soon and this should fix problems with loading PRG in most cases.
By the way, do you know what other memory addresses I should care for? I've briefly gone through LOAD/RUN kernel disassembly and they set many values there, but actually what I need to set to "mimic" state after LOAD/RUN apart from $2D-$32 pointers? By the way, I also set $CC now to stop cursor blinking. In overall it is a hack to load PRGs quickly, intended rather for coders to allow quick dev workflow via command line.
Anyway, another thing - when there's a CPU JAM the emulation automatically pauses to let coder check what happened. You need to continue emulation to have it working after reset (by pressing F11). So whenever you hit CPU JAM and send the Reset command then you need to run/continue the emulation (F11). I've also already changed this behaviour, so in next version when CPU is in jam state then CTRL+R will run/continue emulation automatically...
It is not that easy to create a simple patch for VICE to have it nicely integrated as frankly speaking VICE is huge and thus I took only a C64 subset, and I had to mess with VICE internals and core functions. I have some ideas how to automate this, but that's a bit of chunk of careful coding. I run through diffs already and indeed I see some nice changes in emulation engine. It is doable hopefully.
Editing keys mapping and shortcuts is in my top priority list. Simply I wasn't on time with this feature before Stary Piernik party... :) |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
also $ae/af should be updated, copy from $2d/2e after load finishes, actually kernal updates $ae/af during loading because it's the pointer of the current byte to store, and then updates $2d/2e . |
| |
Angel of Death
Registered: Apr 2008
Posts: 210 |
Thanks for the quick reply everyone.
I see your point Slajerek but you should realize that tools like this will not only be used for debugging of our own programs but also for hacking other people's work.
:)
ps.
reset bug? RTFM! |
| |
enthusi
Registered: May 2004
Posts: 675 |
> but also for hacking other people's work.
Indeed. Very much so. These kind of quick (graphical) overview debuggers are very helpful to quickly grasp data-structures, memory-layouts, sprite handling etc. |
| |
Endurion
Registered: Mar 2007
Posts: 72 |
Also, what Groepaz said about VICE: Make the C64s memory states easier available (mem mapped files?), the remote monitor access to all C64k is annoyingly slow and the binary access pretty shaky. |
... 5 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
