<p>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 stores this information in a .cdl file, which is essentially a mask that tells which bytes in the ROM are code and which are data. The file can then be used in conjunction with a suitable disassembler to disassemble only the actual game code, resulting in a much cleaner source code, with code and data properly separated.</p>
<p>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:</p>
<p>See, it is very useful for finding specific code and data by using it with the <aclass="rvts18"href="TraceLogger.html">Trace Logger</a>. Furthermore, while it is running, the Hex Editor will color-code bytes depending on whether they were logged as code or data. And it can also be used to create a stripped NES ROM.</p>
<p>A "stripped" NES ROM is one in which everything that was not logged by the code/data logger is removed. This may be just a novelty feature, however it can be useful because you can view the ROM in a 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.</p>
<p>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.</p>
<p>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 (F10, F11) again while logging.</p>
<p>4. Play through whatever levels you want present in the demo. 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 the special move.</p>
<p>5. Save the stripped NES ROM. If you're using the Old PPU, the CHR (graphics) data will be saved in full, but if you're using New PPU, only the graphics that was used while playing gets saved.</p>
<p>6. Alternatively, you can save Unused Data (a ROM which complements the Stripped ROM). For example, you can play throught the game with the New PPU enabled, then save Unused Data and watch it in a Tile Viewer to find unused graphics (possibly stumble upon secrets and easter eggs).</p>
<p>7. Rejoice, for it is done.</p>
<p><br/></p>
<p>Some notes:</p>
<p>When you open another .cdl file, it does not clear the current log; instead, it combines it with the information in the file. This can be useful if you're trying to obtain a complete log, as multiple people can play through the game and keep code/data logs, and then the results can be combined. But if you would like to actually clear the code/data log, press the "Reset Log" button.</p>
<p>CDL log files are just a mask of the ROM; that is, they are 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):</p>
<p> D = Whether it was drawn on screen (rendered by PPU at runtime)</p>
<p> R = Whether it was read programmatically using port $2007</p>
<p> (e.g. Argus_(J).nes checks if the bankswitching works by reading the same byte of CHR data before and after switching)</p>
<p>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 (which is now partially supported) 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.</p>
<p><br/></p>
<p>The Code/Data Logger becomes the most useful when you need to restore a full source code of a game using IDA (Interactive DisAssembler). There you can write custom IDC script that uses a CDL file and calls MakeCode()/MakeData() to help the disassembler distinguish code from data. Making full and working disassembly becomes really easy this way.</p>
<pclass="rvps2"><spanclass="rvts13">Created with the Personal Edition of HelpNDoc: </span><aclass="rvts14"href="http://www.helpndoc.com">Free HTML Help documentation generator</a></p>
