| |
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. |
|
... 5 posts hidden. Click here to view all posts....
|
| |
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. |
| |
Slajerek
Registered: May 2015
Posts: 62 |
Thanks Endurion, good idea about these mem map files.
I've added C64 RAM memory mapping via mmap to a file already. It works although it's slowing down emulation a bit. Mapping RAM was quite easy to do, but having this for chips states, colour RAM etc is going to be a bit pain as there is no "memory" for chips per se, but rather register read/write functions.
I will add this as an option in Settings.
I'm planning also to add suggestion from Conjuror "write the memory to file for a specific set of frames".
Ahh, and yes I do know that this tool is going to be used to hack other's stuff. I literally spent hours playing with Glasnost's zoomer from The Un-named Demo ;-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
endurion: you could start by providing a proper bug report - i dont know of any problems with those features for that matter :) |
| |
Keys
Registered: Jan 2012
Posts: 1 |
I'm trying to autorun from a D64, but I can't find an option to do so. Is this not implemented or am I just missing something? |
| |
Slajerek
Registered: May 2015
Posts: 62 |
Running directly from D64 is not implemented yet. |
| |
Slajerek
Registered: May 2015
Posts: 62 |
I added mapping of C64 memory into a file via mmap. It works like a charm on Linux and MacOS, in a way that I can view "live" C64 memory and apply edits just by writing to the file (f.e. using external hex editor), and that changes are immediately reflected in C64 memory.
I tried to have the same feature on Windows using Memory Mapped Files (mmap is not existing on Windows), for example using this: http://www.beyondlinux.com/windows-file-api-samples/windows-fil..
Also I tried a mmap implementation via this wrapper: https://github.com/witwall/mman-win32
Although I can see memory in a file and browse it correctly, the file is locked for write, and does not matter what file attributes I set (FILE_SHARE_READ | FILE_SHARE_WRITE), it is not possible to write to that file and see it reflected in C64 memory using external software...
Any Windows hackers here that can help me with this...? Is such read/write mapping to file actually doable on Windows...? Maybe some clue what I'm doing wrong?
Thanks in advance. |
| Previous - 1 | 2 - Next |
