Code/Data Logger

Introduction

The Code/Data Logger makes it much easier to reverse-engineer NES ROMs. The basic idea behind it is that a normal NES disassembler cannot distinguish between code (which is executed) and data (which is read). The Code/Data Logger keeps track of what is executed and what is read while the game is played, and then you can save this information into a .cdl file, which is essentially a mask that tells which bytes in the ROM are code and which are data. The file can be used in conjunction with a suitable disassembler to disassemble only the actual game code, resulting in a much cleaner source code where code and data are properly separated.

Using the Code/Data Logger

The Code/Data Logger keeps track of every byte in the ROM and records whether it's code (is executed) or data (is read).

You can combine this logging feature with other tools to make them much more powerful:

combine with Debugger to see which branches of the game code were executed and which weren't yet
combine with Trace Logger to let it log the code selectively
combine with PPU Viewer to let it only display graphics that was drawn on screen at least once
combine with Hex Editor to enable smart coloring of bytes (so you can observe which bytes are used by the game and how/when they are used)
combine with (an external) Tile Viewer to see which graphics was used during certain play session, and which was not
combine with (an external) ROM Corruptor to make it only corrupt data, but not code
combine with (an external) Disassembler to help it separate code from data

See, it is very useful for finding certain types of data or code branches. It also makes debugging work more visual, since you can always see which lines of the disassembled code were executed and which weren't.

Furthermore, while the Code/Data Logger is running, the Hex Editor will color-code ROM bytes depending on whether they were logged as code or data:

For PRG ROM:

Dark-yellow - the byte is code

Blue - the byte is data

Cyan - the byte is PCM audio data

Green - the byte is both code and data

For CHR ROM:

Yellow - the byte was rendered

Light-blue - the byte was read programmatically

Light-green - the byte was both rendered and read programmatically

The Code/Data Logger can also be used to generate a stripped NES ROM.

"Stripped" NES ROM is a ROM in which everything that was not logged by the Code/Data Logger is removed. It can be useful in many ways, for example, you can view the ROM in an external Hex Editor or a Tile Viewer, and you'll see only the parts that were used while playing. Furthermore, you could use it to create a demo ROM by only playing through the parts you would like others to see.

Example of such usage:

1. Open the Code/Data Logger, and press Start to begin logging.

2. Perform a soft and a hard reset while logging, in order to capture the ROM's startup sequence. If you don't do so, you can distribute a save-state file so they will start from within the game.

3. If the game has Save-RAM (e.g. Zelda), you will need to capture the game's Save-RAM initialization routines; you can try to do so by deleting the game's *.sav file and then perform a soft and hard reset again while logging.

4. Play through whatever levels you want present in the demo ROM. Be sure to perform every move, get every item, etc., so that the code and data necessary for those things are logged. If, for example, you fail to perform some special move, and then someone plays the stripped ROM and attempts to perform that move, the game may very well crash or glitch up, because there are zeros in the stripped ROM instead of the code responsible for handling this special move.

5. Save the stripped NES ROM.

Alternatively, you can save Unused Data (a ROM which is the opposite to the Stripped ROM). For example, you can play through the game, then save Unused Data ROM and watch it in a Tile Viewer to find unused graphics (possibly stumble upon secrets and easter eggs).

Note: When you "Load" another .cdl file, it does not clear the current log; instead, it combines ("arithmetical OR") it with the information in the file. This can be useful if you're trying to obtain a complete log of certain game, as multiple people can play through the game and keep own code/data logs, and then the results can be combined into an all-encompassing log. But if you would like to actually clear the code/data log, press the "Reset Log" button.

CDL files are just a mask of the ROM; that is, they are of the same size as the ROM, and each byte represents the corresponding byte of the ROM. The format of each byte is like so (in binary):

For PRG ROM:

C = Whether it was accessed as code.

D = Whether it was accessed as data.

AA = Into which ROM bank it was mapped when last accessed:

00 = $8000-$9FFF 01 = $A000-$BFFF

10 = $C000-$DFFF 11 = $E000-$FFFF

c = Whether indirectly accessed as code.

(e.g. as the destination of a JMP ($nnnn) instruction)

d = Whether indirectly accessed as data.

(e.g. as the destination of an LDA ($nn),Y instruction)

P = If logged as PCM audio data.

x = unused.

For CHR ROM:

D = Whether it was drawn on screen (rendered by PPU at runtime)

R = Whether it was read programmatically using port $2007

(e.g. Argus_(J).nes checks if the bankswitching works by reading the same byte of CHR data before and after switching)

x = unused.

CDL files make possible a number of things never done before. First, a PCM data ripper could be created that scans for data that has the 'P' bit set, in order to find/rip/play every PCM sample in a ROM. Also, it is possible for someone to make a more intelligent ROM corruptor that only corrupts data (by checking the 'D' bit). In any case, the Code/Data Logger opens many new possibilities for discovering useful things in games. Another interesting possibility would be to use the Code/Data Logger on an NSF file to create a stripped NSF. Such an NSF would contain nothing but the relevant subroutines and data required by each tune played; this would be helpful to NSF rippers by removing irrelevant information. Thus, an NSF ripper could create a stripped NSF by listening to each track while the Code/Data Logger operates on it, and then saving the stripped NSF. It should be noted that this capability, though tested and working on private builds, is detrimental to the process of fixing broken NSF files. For this reason, data logging is allowed for NSF files, but stripping NSF files of unused data is disabled.

The Code/Data Logger becomes the most useful when you need to restore a full source code of a game using e.g. IDA or another disassembler. There you can write a custom IDC script that uses a CDL file and calls MakeCode()/MakeData() functions to help the disassembler distinguish code from data. Making full and working/reassemblable disassembly becomes really easy this way.

Created with the Personal Edition of HelpNDoc: Free HTML Help documentation generator