Skip to content

Toad Houses Disassembled

To waste some time today I played some Super Mario Bros 3 on my Wii. I only made it trough three levels before I reached the first Toad House. Upon receiving the item from Toad I decided to investigate something I've wanted to know for, I don't know, maybe 15 years. How exactly does the game decide what item you receive? I remember as a child that people playing Super Mario Bros 3 did the weirdest stuff in Toad Houses to improve their item karma. Running around, doing weird jumps, whatever.

Anyway, I really wanted to know when the game decides what item you receive and how it decides that. Does the game already know what item you receive as soon as you enter the Toad House? Are the items placed in the boxes when you enter the Toad House? Does it do any other weird stuff?

Continue reading "Toad Houses Disassembled"

Release of FCEUXD SP 1.07

Two days ago I was sure that I would never release another version of FCEUXD SP (everybody's favourite NES emulator for hacking NES games). Today there's a new version because I was unhappy with the Cheat Console. Weird things happen sometimes.

Version 1.07 is another small update. It adds the so called RAM Filter. With this tool you set up rules to specify how you expect RAM values to change. After you set up the rules, RAM Filter eliminates all bytes in memory that changed differently. This makes finding data in NES games very easy. How is that different from the Cheat Console? The RAM Filter offers more options, it's easier to use, you get more information about value changes, and you can easily go back to earlier rules without having to restart everything.

Let me give you two examples.

In the first example we want to find out where the game Faxanadu stores the player's health points in RAM. Check this screenshot to see how I used the RAM Filter tool.

At first I started a game and used the "Any" rule. This rule tells the RAM Filter that I don't have any information about the value I want to find. Right after that I walked to another screen. There I set up two "Equal to last value" rules because the health points didn't change since the first rule. These two rules eliminated lots of potential memory locations that had nothing to do with the health points. Then I went to the next room and walked into a monster. This obviously changed the number of health points and I set up a "Not equal to last value" rule accordingly. Then I went to a store and set up two more "Equal to last value" rules to eliminate more potential memory locations. Afterwards I bought some health points from the vendor. Once again this changes the number of health points so I set up another "Not equal to last value" rule.

After all this, the RAM Filter tool found that only 2 memory locations changed according to the rules I set up: 0x399 and 0x431. A quick test reveals that the health points are stored in 0x431.

Here's another example. Suppose we want to find out where the number of player lives left are stored in Super Mario Bros. Check this screenshot to see the results

I started the game and once again I set up an "Any" rule at first because I didn't know what to look for. Immediately after I set up the first rule I added two "Equal to last value" rules because the number of lifes left didn't change. This helped to eliminate lots of memory locations already. Then I walked into the first Goomba to lose a life. I expected the number of lifes to decrease therefore I set up a "Less than last value" rule. After the game was restarted I set up another "Equal to last value" rule.

RAM Filter worked even better this time. Only one memory location was left. Now we know that the number of lives left is stored in 0x75A.

Both of these examples took less than one minute to figure out. That's pretty neat in my opinion.

Download FCEUXD SP 1.07
Download the FCEUXD SP 1.07 source code

Release of FCEUXD SP 1.06

Here's a mini update of everybody's favourite NES emulator FCEUXD SP. Version 1.06 fixes two problems people reported on IRC today.

The first problem (reported by Gavin) was a bug in the conditional breakpoint code that occured when using numbers with leading zeros.
The second problem was reported by olaf who suggested that the automatically generated .deb debug files should only be created if the user actually used the debugger. From this release on the .deb files won't be created anymore if the user merely plays a game without debugging it.

Here are the files:
Download the FCEUXD SP 1.06 binaries
Download the FCEUXD SP 1.06 source code

FCEUXD SP 1.05

The motto of this update of FCEUXD SP is definitely "This happens when you don't have unit tests for your code". I think each and every bug fixed in this version could have been picked up by even the most basic test framework.
Thankfully I found Kapow who worked as a human unit test on my website (see the comments for the last release) and on IRC. You can thank him for most of the new stuff and bugfixes in version 1.05.

Enough text, here's what you guys actually care about:

- New: Added range options for freezing / unfreezing addresses
- New: Added dump RAM to file option
- New: Added dump PPU memory to file option
- New: Readme file fceuxd.txt from FCE Ultra Extended Debugger is now included (read this if you want to learn about the debugger)
- Change: Increased the maximum number of frozen addresses
- Bugfix: NL files for banks at 0x8000 work again
- Bugfix: Empty comments work properly again
- Bugfix: Fixed a breakpoint persistence problem

Click here to download the FCEUXD SP 1.05 binary
Click here to download the FCEUXD SP 1.05 source

cmpf

cmpf (C++ source included) is a cute little tool for finding the differences between a number files. It's a command line tool that takes three parameters, the names of two files to compare and the name of the so called mask file.

When you run the tool the first time it compares the two files and dumps the offsets of the bytes where the files differ to stdout. At the same time it creates the mask file which is used for consecutive comparisons. The mask file is just a file filled with 'C' and 'U' bytes that indicate whether the bytes at the same offset during the comparison were the same or not.
If you want to add another file to the comparison you re-run the tool with the parameters 1st file, 3rd file and mask file. Now the mask file exists and is considered in the comparison. Only bytes that were unchanged during the first comparison and have now changed are printed to stdout.

To make it simple: After n consecutive runs of the tool the bytes that were unchanged n-1 times but changed during the last comparison are printed to stdout.

What's the use of this tool? It makes it very easy to find RAM addresses during NES ROM hacking. Here's an example: I want to find the RAM byte where your health points are stored in Super Mario Bros II.
Continue reading "cmpf"

Release of FCEUXD SP 1.04

First the important stuff:

- New: Better error handling
- New: Invalid lines in NL files are now shown to the user instead of being silently ignored. This gives the user the opportunity to fix erroneous lines.
- New: Good news for other developers, all C files added by me are now fully documented.
- Change: Array indices in disassembly windows are now hexadecimal values.
- Bugfix: Fixed a bug that occured when loading the bookmark description of hex bookmarks from disk
- Bugfix: Fixed a bug that occured when using arrays and long comments in symbolic debugging
- Bugfix: Fixed a bug that occured when reading NL files

Now my comment about this release:
This release was mainly a release that's supposed to be the basis for future bugfixing releases. Most of the new stuff I added is of no concern to actual users of the emu. In this release the code was cleaned up and error handling was significantly improved. That means I should be able to find bugs way quicker from now on. At least in theory. Let's hope I'm right here.

I also have a real build script now! Well, OK, it's just a BAT file but that means I probably won't forget to include the readme.txt file in future releases.

Anyway, I'd also appreciate if people would send me their NL files. I only have my own ones from Faxanadu and they might not be sufficient for testing. My mail address is webmaster@ät@the-interweb.com. Thanks.

OK, here are the files:
FCEUXD SP 1.04 Executable file
FCEUXD SP 1.04 Source files

Release of FCEUXD SP 1.03

Here's FCEUXD SP 1.03 which adds some new features and fixes some others. Special thanks goes to TFG who significantly improved and sped up this release with his feedback (which you can see in the FCEUXD SP 1.02 thread).

Here are the changes which are while few quite significant I think:

- New: Added register P (Program Counter) to the conditional breakpoint expressions.
- New: There's a new name list file for symbolic debugging. Put all debugging information
for addresses < $8000 into the name list file romname.nes.ram.nl.
- New: Added a feature to NL files to support arrays.
- Bugfix: Names for offsets can now be properly distinguished from byte values. All
offsets have the four-byte format $XXXX now (including zero-page offsets)
while all byte values have the two-byte format ($XX). This fixes some bugs
and issues with NL files.

Enjoy! Just like every release of mine this one's barely tested. I hope you don't find too many bugs. And if you do, report them please.

Click here to download the FCEUXD executable.
Click here to download the FCEUXD source code.

How to compile FCEUXD SP yourself

Here's a quick description of how to compile FCEUXD SP yourself just in case you want to add things to FCE Ultra that nobody else wants to add. There's also another guide which helped me a lot to get started.

I use the following tools and libraries to compile FCEUXD SP.
- MinGW 3.1.0.1 (MinGW-3.1.0-1.exe)
- MSYS 1.0.10 (MSYS-1.0.10.exe)
- zlib 1.2.2 (zlib122.zip)
- The DirectX 7 libraries for MinGW (dx70_mgw.zip)
Continue reading "How to compile FCEUXD SP yourself"

Release of FCEUXD SP 1.02

Here's version 1.02 of FCEUXD SP:

- New: Added hotkey F6 to open hex window.
- New: Added bookmarks to the hex window.
- New: Debugging data like breakpoints or bookmarks are automatically saved and restored when games are closed / opened.
- New: Increased the size of the mouse-over information area below the diassembly window
- New: Added name list file information for addresses to the mouse-over information area
- New: It's now possible to give breakpoints a brief description/name.
- Bugfix: Inline Assembler works for all lines again.
- Bugfix: Deleting breakpoints correctly updates breakpoint conditions now.


For a more detailed description of what's new check the readme file.
Click here to get the FCEUXD SP Windows binary file.
Click here to get the FCEUXD SP source code.

Faxanadu collision detection - Part III (Sprite behaviour III)



After going through 6 of the 7 main rules from the sprite description table last time it's now time to turn to the last and most complex rule, the main rule with ID $02. What makes this rule more complicated than most others is that it has it's own set of sub-rules. Depending on a value from the sprite description table one of eight sub-rules is chosen once main rule $02 is executed.

Continue reading "Faxanadu collision detection - Part III (Sprite behaviour III)"

Release of FCEUXD SP 1.01

Here's version 1.01 of FCEUXD SP:

Improvements over v1.00 (June 30, 2005)

- New: Significantly better conditional breakpoints
- New: Multi-line comments are now allowed in symbolic debugging mode
- New: Added the possibility to reload the *.nl files
- New: Added the possibility to enable / disable symbolic debugging
- New: Increased the number of visible lines in the disassembly window to 34.
- New: Added disassembly bookmarks
- Bugfix: Conditional breakpoints can now be removed again.

For a more detailed description of what's new check the readme file.
Click here to see a picture of the debugging window of this version.
Click here to get the FCEUXD SP Windows binary file.
Click here to get the FCEUXD SP source code.

Faxanadu Disassembly

I probably won't have a lot of time in the next weeks or even months to continue my Faxanadu disassembly. Therefore I've decided to upload all disassembly files in the hopes that someone else can continue my work.

Click here to get the archive including all files

Files in the archive:
*.html - HTML disassembly of important ROM banks
*.bin - IDA Pro databases
*.nl - Name list files for FCEUXD SP
idc*.idc - Various IDC scripts used while disassembling the Faxanadu ROM file
memmap.txt - Notes about the RAM section of Faxanadu; Use only in combination with the newer initram.idc

Initial release of FCEUXD SP 1.0


I've decided to fork FCE Ultra eXtended-Debug 1.0a under the name FCEUXD SP with the hope to make significant contributions and improvements to the NES debugging experience. My main reason for this was the sorry state of NES debugging today. Even with the best NES emulator debuggers today barely anything is possible. If I had to guess where NES debugging today is I'd estimate it's somewhere between debug.com and Borland's Turbo Debugger. That's an unacceptable situation in my opinion.
Here's where I come into play. As the original FCE Ultra was thankfully released under GPL I was able to get the source code of one of it's former forks FCE Ultra eXtended-Debug 1.0a from Zophar's Domain. The code is very well written so I had absolutely no problems with adding new functionality. It was not even necessary to change the interface of one, single pre-existing function.

In this first release of FCEUXD SP 1.0 I've added two features which were at the very top of my list: A simple form of symbolic debugging and conditional breakpoints.

Continue reading "Initial release of FCEUXD SP 1.0"

Faxanadu collision detection - Part III (Sprite behaviour I)



After last time's slow start into the collision detection code things are going to be more interesting this time. The second function call from the main collision detection code contains quite a lot of code (at least indirectly because it calls lots of other functions). So much in fact that a decently sized chunk of ROM bank 15 contains nothing but code and data that's used from that function. Thankfully it's not necessary to explain all, or even most of it because a lot of code is very similar and I can skip over it without explaining it any further. You'll see later why exactly that's the case.

Continue reading "Faxanadu collision detection - Part III (Sprite behaviour I)"