From NES Hacker Wiki
Revision as of 12:29, 28 December 2018 by TheAlmightyGuru (talk | contribs) (Multiple-Byte, Hex Value)
Jump to: navigation, search

This guide is to make you better acquainted with the way various games store variables in the NES.

Remember that most games store all of their memory in the basic RAM of the NES, which is located from 0x0000 to 0x07FF.

Single-Byte, Hex Value

Variables of this type are stored as a hex value in a single byte of memory. This is the native way the CPU handles values, so it is the easiest way, and by far the most commonly used in games. No special code is needed to perform math on variable stored in this way. Each byte can hold 256 discrete values, and they are displayed in a hex editor as 0x00-0xFF.

In The Legend of Zelda, Link's horizontal position on the screen is stored as a single byte hex value in memory address 0x0070. If you load up the game and move Link horizontally across the screen, you'll see this number grow and shrink as he moves.

As long as the value never needs to be displayed to the player, this is the best way to handle such values. However, if the player needs to see the value in number form, it must first be converted to decimal, which takes extra CPU time. A good example of this in action is Link's rupees in The Legend of Zelda. They are stored in memory as a hex value, but they are displayed to the player in decimal form. If you load The Legend of Zelda and start a new game, you can adjust the number of rupees (memory address 0x066D) using a hex editor and see the value update immediately on the screen. For example, type "01" into the address, and you'll suddenly have 1 rupee. Type "0A" (the hex value for 10), and you'll have 10 rupees. Type "FF" (the hex value for 255) and you'll have a full compliment of 255 rupees. The game does this by running a conversion from hex to decimal every time the value updates.

Single-Byte, Decimal Value

Variables of this type are stored as a decimal value in a single byte of memory. Because the NES CPU doesn't have native decimal mode, programmers must write a special routine to perform decimal math on these values every time they add or subtract on them. Because of this extra overhead, programmers usually only type of variable for values that will be seen by the player.

For example, the player's scores in Tecmo Super Bowl are stored as decimal values in memory. P1 is at address 0x0399 and P2 is at address 0x039E. When a player scores 14 points, the value won't read 0x0E (the hex value for 14), but rather 14 in decimal. This way, the value won't need to be converted when it's displayed on the screen.

The programmers handled this by writing special addition routines when a player scores. Instead of simply using the native ADC opcode, which adds in hex, the game has to convert the decimal value into hex, then add the points, and then convert it back to decimal every time a score changes.

The CPU used by the NES originally had decimal mode, but Nintendo engineers removed it so it wouldn't have to pay royalties on the patent. If decimal mode remained, programmers wouldn't have had to write all the extra code to convert between hex and decimal and add and subtract decimal values.

Multiple-Byte, Hex Value

A single byte can only hold 256 values, and that's usually enough for most uses, but what about when you want to store more than that?

Multiple-Byte, Decimal Values

Bit Flags