Donkey Kong Land 2/RAM map: Difference between revisions

From Data Crystal
Jump to navigation Jump to search
No edit summary
No edit summary
Line 18: Line 18:
* <tt>0xDF10</tt> - Horizontal velocity
* <tt>0xDF10</tt> - Horizontal velocity
* <tt>0xDF11</tt> - Vertical velocity
* <tt>0xDF11</tt> - Vertical velocity
== Saved data ==
* <tt>A000-A04F</tt> = File 1
* <tt>A050-A0BF</tt> = File 2
* <tt>A0A0-A0EF</tt> = File 3
{| border="1" style="border-collapse:collapse;"
|-
! File 1 !! File 2 !! File 3 !! Description
|-
| <tt>A000-A001</tt>
| <tt>A050-A051</tt>
| <tt>A0A0-A0A1</tt>
| 16-bit big endian checksum of <tt>4E</tt> bytes afterwards (e.g. <tt>A002-A04F</tt> for File 1)
|-
| <tt>A006-A008</tt>
| <tt>A056-A058</tt>
| <tt>A0A6-A0A8</tt>
| Total time (hours, minutes, seconds)
|-
| <tt>A00A</tt>
| <tt>A05A</tt>
| <tt>A0AA</tt>
| Kremkoins collected
|-
| <tt>A00B</tt>
| <tt>A05B</tt>
| <tt>A0AB</tt>
| DK Coins collected
|-
| <tt>A100-A14F</tt><br /><tt>A200-A24F</tt>
| <tt>A150-A19F</tt><br /><tt>A250-A29F</tt>
| <tt>A1A0-A1EF</tt><br /><tt>A2A0-A2EF</tt>
| Backup copies of given file, used if previous checksum fails
|}
==== 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 (even if the checksum failed in this block, but passed in either of the two backup blocks). 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 06:50, 30 January 2013

Chip tiny.png 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 (even if the checksum failed in this block, but passed in either of the two backup blocks). 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.