Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user danyboy@babygang.fr ! (Registered 2022-07-05) You are not logged in - nap
CSDb User Forums

Forums > CSDb Entries > Release id #148664 : C64 Debugger V0.5
2016-06-06 16:54

Registered: Jan 2002
Posts: 2684
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....
2016-06-07 12:20

Registered: May 2015
Posts: 58
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... :)
2016-06-07 13:03
iAN CooG

Registered: May 2002
Posts: 2966
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 .
2016-06-07 13:25
Angel of Death

Registered: Apr 2008
Posts: 201
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.

reset bug? RTFM!
2016-06-09 11:50

Registered: May 2004
Posts: 668
> 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.
2016-06-10 05:47

Registered: Mar 2007
Posts: 71
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.
2016-06-10 10:28

Registered: May 2015
Posts: 58
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 ;-)
2016-06-10 16:28

Registered: Dec 2001
Posts: 10386
endurion: you could start by providing a proper bug report - i dont know of any problems with those features for that matter :)
2016-06-20 04:27

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?
2016-06-20 13:14

Registered: May 2015
Posts: 58
Running directly from D64 is not implemented yet.
2016-06-21 21:02

Registered: May 2015
Posts: 58
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
mutetus/Ald ^ Ons
Guests online: 53
Top Demos
1 E2IRA  (9.7)
2 Edge of Disgrace  (9.6)
3 Coma Light 13  (9.6)
4 Uncensored  (9.6)
5 Bromance  (9.6)
6 Memento Mori  (9.5)
7 Lunatico  (9.5)
8 Unboxed  (9.5)
9 Comaland 100%  (9.5)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Copper Booze  (9.5)
2 Daah, Those Acid Pil..  (9.5)
3 Breadbinked  (9.5)
4 Onef1ler 2  (9.5)
5 Dawnfall V1.1  (9.5)
6 Cityscape 2730  (9.5)
7 Barry Boomer - Trapp..  (9.5)
8 Lovecats  (9.5)
9 Elite Code Mechanics  (9.5)
10 Square Booze  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Crest  (9.3)
4 Censor Design  (9.2)
5 1001 Crew  (9.2)
Top Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Acidchild  (9.7)
4 Starlight  (9.6)
5 Violator  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2022
Page generated in: 0.188 sec.