| |
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? |
... 11 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
