| |
Paulko64
Registered: Jul 2010
Posts: 24 |
Reverse debugging in emulator?
Hi all,
I'm currently working on a game-project that has high irregular CPU load during each frame. I've coded everything in such a way that all this irregular code is ran during a mainloop and starting of the routines is regulated during raster-irqs (besides the multiplexor and music calls).
Now this all works perfectly except for once in a few minutes my game crashes (CPU-jam), because it apparently jumped to a strange adres (ZP in my case). I'm not sure what happened but maybe I didn't end the irqs well enough, or perhaps I used the same ZP-adres for indirect adressing in both main and irq-code, which then screws up code if an irq fires at exactly the right (wrong!) moment...
Anyhow, this proves to be very hard to troubleshoot. So I thought, isn't there an emulater that supports some kind of "reverse debugging"? I.e. when I get a CPU-jam can I trace back what instructions were used just before? Or maybe an emulator that supports writing all instructions executed to a textfile which I can then trace back? Although this last option will probably generate a HUGE trace-file.
Does anybody know how to accomplish something like this?
Thanks,
PaulKo64 |
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
I'm not aware of any C64 emulator that can do that. I know an Apple II emulator that has a feature like that, and it's definitely useful.
But you should be able to trace back to what call caused the problem by carefully looking at the stack. Look at $0100 + SP + 1 and check if that's pointing to after a JSR. Sometimes it's easy to see how you got there.
But you could also end up there through some other way. Was it an IRQ? Check the IRQ flag. Maybe a BRK? It can easily happen that you overwrite some code with $00 and thereby put a BRK in your code. Do you go through $fffe or $0314? In the first case, try putting some BRK detection in the code (the kernal IRQ handler at $ff48 has the relevant stack snooping code to check the status register for the BRK flag). In the second case, make sure you install a BRK handler in $0316.
Maybe you're fiddling with the stack and RTS or RTI causes a wrong return address to be popped off the stack?
Or, one common mistake that happened to me often: When using the typical double-IRQ raster stabilization technique, where the second IRQ triggers during a chain of NOPs, try putting a JMP * at the end, to protect against the second IRQ not triggering. Usually there's a TXS after the NOPs where the second IRQ jumps to and if the IRQ doesn't trigger for some reason, you'll run into that and mess up your stack. Usually these problems happen when not acknowledging pending IRQs during a SEI/CLI block, causing the IRQ to trigger immediately after the CLI, and not at the $d012 line.
One last hint: If you end up crashing in ZP, it's possible that the CPU somehow jumped to $ffxx and actually managed to execute and wrap around the end of memory, before it crashed, so consider that possibility. |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
The VICE monitor have a backtrace command which might be helpful. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
configure/compile VICE with --memmap ... this enables the cpu-history feature in the monitor (chist) which does exactly what you want (prints the last 1000 or so executed instructions) |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Why isn't that compiled in by default? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
because it slows down the emulator quite a bit, and most people dont need it :) |
| |
Paulko64
Registered: Jul 2010
Posts: 24 |
Thanks for the suggestions!
The memmap option in VICE sounds like the best option.
Before going through all the trouble of trying to compile VICE, I don't suppose anyone already has a win32 compiled version of VICE with this option included? |
| |
Angel of Death
Registered: Apr 2008
Posts: 211 |
Micro64 1.00.2012.05.28 Build 669 has an in-build real-time monitor. (needs a powerful PC, though) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Yeah I had a bug exactly like this a while back, where the stack was corrupted and the code died with a CPU JAM in a completely bizarre location. I ended up installing a Ubuntu VM just to compile vice with --enable-memmap, since compiling the Mac sources was pretty much impossible... |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
This version of VICE contains some of my extra tweaks for debugging.
http://www.wellytop.com/VICEMyTweaks.zip
The source for the tweaks can be downloaded from: http://www.wellytop.com/C64.html
The monitor command "chis" will display the state of the registers for each instruction.
If you have labels loaded then the disassembly and memory dump windows will also include those.
Let me know when you've got it so I can nuke it from the server.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Yeah I had a bug exactly like this a while back, where the stack was corrupted and the code died with a CPU JAM in a completely bizarre location. I ended up installing a Ubuntu VM just to compile vice with --enable-memmap, since compiling the Mac sources was pretty much impossible...
Hmms.. configure && make worked quite nicely for me on Mac OS Mountain Lion. Although I have all the dev tools installed from xcode etc... perhaps that was your issue? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
afaik only outdated OSX are affected...
martin: where are the sources to these tweaks exactly?
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Hmms.. configure && make worked quite nicely for me on Mac OS Mountain Lion. Although I have all the dev tools installed from xcode etc... perhaps that was your issue?
This was on 10.7.3 with Xcode 4.2 (with command line tools installed). Specifically it failed compiling the library dependencies but I don't remember which one.
I should try in a fresh VM with 10.8.1 and Xcode 4.4 and see what happens... |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: This was on 10.7.3 with Xcode 4.2 (with command line tools installed). Specifically it failed compiling the library dependencies but I don't remember which one.
I should try in a fresh VM with 10.8.1 and Xcode 4.4 and see what happens...
OSX v10.8.1 with xcode 4.4.1 here. |
| |
Paulko64
Registered: Jul 2010
Posts: 24 |
Martin: Thanks for your "Tweaked" VICE! The "chis" command works beautifully! However, my next question is how to scroll upwards in the VICE-monitor, or how to save the history to a file? At the moment I can't see the point where it exactly went wrong :-( |
| |
Endurion
Registered: Mar 2007
Posts: 73 |
You could try with the remote monitor, this way you can get all the output. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
you can't scroll backwards in the windows gui? wow =) |
| |
Norrland
Registered: Aug 2011
Posts: 14 |
Quote: you can't scroll backwards in the windows gui? wow =)
No :P I had the same kind of problem while debugging some stuff just earlier today..
Therefore, this remote monitor sounds interesting. I've searched the vice manual and the web but haven't managed to get it up and running. I've tried "-remotemonitor" on the commandline but is obviously missing something.. I would appreciate if someone could point me in the right direction. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting H MacaroniI've tried "-remotemonitor" on the commandline but is obviously missing something.. I would appreciate if someone could point me in the right direction.
To connect to the remote monitor from a separate terminal on the same machine, use "telnet localhost 6510". You can of course also connect from a different computer, provided there's no firewall blocking the port.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
The version of VICE you have (from me) doesn't have the telnet feature enabled, the source is too old. But the CPU history of instructions is limited to the last 64 instructions.
If you can I would recommend trying to spot a pattern where the crash comes from in the CPU history and setting a breakpoint earlier until you start tyo discover where the wrong code is coming from.
Or if you suspect wrong memory is being accessed then use watch with a memory range.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
OK, because I'm a nice chap I expanded the CPU history to be 256 instructions and also added the "telnet localhost 6510" debug log stuff.
You can get it from:
http://www.wellytop.com/VICEtweaked2.zip
You won't be able to type commands into the telnet window so you still need to use the monitor window.
Also you'll need to open the monitor window before trying to connect ot localhost port 6510.
Sources: https://github.com/martinpiper/VICE/
|
| |
Paulko64
Registered: Jul 2010
Posts: 24 |
Yeah, finally solved the bug! I couldn't have done it without the "chis" command.
What happened was that due to a negative offset an unrelated routine corrupted the hi-byte in one of my jump-tables. Now minutes later when actually using this particular jump-adres I ended up in zero-page where after some random instructions it encounterd a BRK instruction and crashed soon thereafter!
So luckily I can now continue with the rest of the game.
Thanks all!
|
