Debugging

[Roth]

I've messed with the debugger in FCEUXD SP, but don't really know how to use a debugger properly. So in effect, I don't get much out of using it. Does anyone know any sites that help with learning how to use a debugger, or have a good tutorial or tips of their own?

[albailey]

I'm certainly no expert but I have found the memory visualization aspect of FCE Ultra very useful. I will often write values to different areas of zero page based on regions of the code I expect to go through.
I found this useful for me in figuring out why my joystick routines were not working.

Another thing I found useful was to write to memory before going into a particular bit of code. Then write to memory again afterwards. Then you can add a "WRITE" breakpoint based on that memory address, run until you hit the "entry" and either step through, or run again until you hit the "exit" and view your registers, etc..

Al

[Celius]

You know, debugging is something I've always wanted to know more about. I use FCEUXD when debugging, but I usually only use the hex viewer and the name table viewer. I also don't know how to use the debugger properly. I usually look at a piece of code to find out if there's something wrong with it. I basically look at what's happening, keep track of values of variables used, and I'll spot the problem after a while. I'd like to learn a little more about how I can use the debugger to my advantage.

[tokumaru]

Tracing code is a very big part of debugging... In FCEUXD, and also in that cool version of Nintendulator, it's possible to set breakpoints. Program execution will stop when an address (or range of addresses) you specify is executed, written or read, and that is useful to track down register writes, or to detect which part of the code might be corrupting a piece of RAM...

There's lots of uses. FCEUXD even has an integrated assembler, you can click anywhere in the disassembly window and start typing instructions, just in case you want to try a few modifications to the code without having to assemble the whole ROM again and start from the beginning.

The modified Nintendulator even tells you in which scanline you are, and which PPU cycle. That's extremely useful when writing timed code.

I agree that when making your own program/game, the memory viewer and the Name Table / PPU viewer are the most useful features, but when reverse engineering someone else's ROM, breakpoints are everything.

[Bregalad]

I usually write use "sta $100" to set a breakpoint, when a piece of code isn't working and see it in FCEUltra to see what is wrong. Since $100 isn't a place you usually use for variables, it doesn't mess with anything.
Seeing the scanline and cycle number when running really rocks, especially if this is accurate (as in this special version of Nintendulator). Else you can log the code, but it often crashes on slow PCs as it writes text too fast.

[Roth]

You know, debugging is something I've always wanted to know more about. I use FCEUXD when debugging, but I usually only use the hex viewer and the name table viewer. I also don't know how to use the debugger properly. I usually look at a piece of code to find out if there's something wrong with it. I basically look at what's happening, keep track of values of variables used, and I'll spot the problem after a while. I'd like to learn a little more about how I can use the debugger to my advantage.

Hey Celius, I happened upon this page which has a few docs written by Parasyte. I haven't ran through them much yet, but seems like it will be a good way to learn how to use the debugger features.

Thanks for the replies : )

[Celius]

Cool! I'll look over them sometime soon. Right now, I'm just learning how to use Maya, the 3D making program. It's really huge, so that'll probably take up most of my time for the next couple of days. But thanks! They look like they could provide some useful information.