The current URL is datacrystal.tcrf.net.
Donkey Kong Land 2/RAM map: Difference between revisions
Blaziken257 (talk | contribs) No edit summary |
Blaziken257 (talk | contribs) (→Checksum: Same bug as in DKL3) |
||
| Line 54: | Line 54: | ||
==== Checksum ==== | ==== Checksum ==== | ||
For each <tt>50</tt>-byte block, a 16-bit, big endian checksum is stored in the first two bytes. This is a sum of each 8-bit value in the rest of the <tt>4E</tt> bytes. If the checksum fails, the checksum in the file's first backup copy is checked. If this also fails, the checksum in the file's second and final backup copy is checked. If they all fail, the file is erased. If any of them pass, the game always uses the data in the first block | For each <tt>50</tt>-byte block, a 16-bit, big endian checksum is stored in the first two bytes. This is a sum of each 8-bit value in the rest of the <tt>4E</tt> bytes. If the checksum fails, the checksum in the file's first backup copy is checked. If this also fails, the checksum in the file's second and final backup copy is checked. If they all fail, the file is erased. If any of them pass, the game always uses the data in the first block. This occurs even if the checksum failed in this block, but passed in either of the two backup blocks. This is a bug; the intended behavior is that the game would copy a valid backup block to the first block in this situation. Since the game always uses the data in the first block, this can cause glitches if the first block is corrupted, but the other two are intact. | ||
Revision as of 04:39, 20 September 2013
The following article is a RAM map for Donkey Kong Land 2.
- 0xDED3 - Bananas
- 0xDED4 - Lives
- 0xDF00 - Current Character
- 00 - Diddy Kong
- 01 - Dixie Kong
- 02 - Rambi
- 03 - Squawks
- 04 - Enguarde
- 05 - Squitter
- 06 - Rattly
- 07 - Roller Coaster
- 0xDF2D - Traction
- 03 - Non-ice levels
- 34 - Ice levels
- 0xDE80-0xDE81 - Horizontal scroll offset in level
- 0xDE82-0xDE83 - Vertical scroll offset in level
- 0xDF10 - Horizontal velocity
- 0xDF11 - Vertical velocity
Saved data
- A000-A04F = File 1
- A050-A0BF = File 2
- A0A0-A0EF = File 3
| File 1 | File 2 | File 3 | Description |
|---|---|---|---|
| A000-A001 | A050-A051 | A0A0-A0A1 | 16-bit big endian checksum of 4E bytes afterwards (e.g. A002-A04F for File 1) |
| A006-A008 | A056-A058 | A0A6-A0A8 | Total time (hours, minutes, seconds) |
| A00A | A05A | A0AA | Kremkoins collected |
| A00B | A05B | A0AB | DK Coins collected |
| A100-A14F A200-A24F |
A150-A19F A250-A29F |
A1A0-A1EF A2A0-A2EF |
Backup copies of given file, used if previous checksum fails |
Checksum
For each 50-byte block, a 16-bit, big endian checksum is stored in the first two bytes. This is a sum of each 8-bit value in the rest of the 4E bytes. If the checksum fails, the checksum in the file's first backup copy is checked. If this also fails, the checksum in the file's second and final backup copy is checked. If they all fail, the file is erased. If any of them pass, the game always uses the data in the first block. This occurs even if the checksum failed in this block, but passed in either of the two backup blocks. This is a bug; the intended behavior is that the game would copy a valid backup block to the first block in this situation. Since the game always uses the data in the first block, this can cause glitches if the first block is corrupted, but the other two are intact.