Welcome to Data Crystal's new home! Data Crystal is now part of the TCRF family (sort of).
The wiki has recently moved; please report any issues in Discord. Pardon the dust.

Castlevania II: Belmont's Revenge/RAM map

From Data Crystal
Jump to navigation Jump to search

Chip tiny.png The following article is a RAM map for Castlevania II: Belmont's Revenge.

Please add more.

Legend: [u] is unsigned, [s] is signed, [d] is binary-coded decimal. [2] is a 2 byte word, [3] and so on likewise. [p] is a 2-byte pointer. [b] is big-endian; otherwise, values are assumed to be little-endian.

During entity update routines, register d stores the high byte of the entity data. Belmont's data begins at c000, so d is always c0 during belmont's update routine. Most of Belmont's entity data, such as the velocity data, repeats every 0x100 bytes for subsequent entities.

0x7FFF [u] index of currently-loaded swappable bank.
0xC001 Belmont state (0: standing. 1: walking. 2: crouching. 3: jumping.)
0xC002 Belmont's substate (0: none. 1: attacking, including both whip and subweapon. 2: knockback.)
0xC008 flags set when Belmont is hurt? Reset bits 0 and 1 to induce iframes; set bit 7 to cause knockback.
0xC009 Belmont's facing (CHR code). Bit 5 is Belmont's facing (20: left. 0: right.); bit 6 is Belmont's vertical flip, etc.
0xC00A Belmont's image. (see "Images" in ROM map.)
0xC00B Belmont's animation frame minus animation base (?)
0xC00C Belmont's animation timer (when walking, repeatedly counts down from C to 0)
0xC00F [s2] Belmont's Y velocity. Negative is upward
0xC011 [u] Belmont's Y subpixel
0xC012 [u] Belmont's Y pixel
0xC014 [s2] Belmont's X velocity. Negative is leftward.
0xC016 [u] Belmont's X subpixel
0xC017 [u] Belmont's X pixel
0xC018 [u] hitstun
0xC300 [u] subweapon projectile id. (0 if no subweapon being thrown currently; 1 if cross/axe; 2 if holy water.)
0xC301 [u] subweapon mode. (0: belmont is still winding up to toss. 1: in the air. 2: become flame/return [cross])
0xC880 game mode (0: konami logo. 1: title screen. 2: title fade-in. 3: stage select and title screen selected. 4: stage entry. 5: normal gameplay. 6: death. 7: game over. 9: Credits. D: password entry. E: intro reel.)
0xC882 global 1-byte game timer
0xC886 current input (1: right. 2: left. 4: up. 8: down. 10: A. 20: B. 40: select. 80: start)
0xC887 input pressed (like 0xC886, but only what was just pressed this frame.)
0xC8C0 current stage (0: plant (glitched). 1: plant. 2: crystal. 3: cloud. 4: rock. 5: Drac 1. 6: Drac 2. 7: Drac 3.)
0xC8C1 current substage (initially 0, increments every time belmont passes through a door.)
0xC8C2 [d3] points/score
0xC8C5 [d] lives ("rest")
0xC980... array of values to copy to vram during the next vblank. Format is:
  - [2 bytes] address to update
  - [1 byte] bits 0-6: stride (e.g. 1 to edit consecutive values). bit 7: unknown.
  - [...] any data other than $FF
  - [1 byte] $FF terminator. Can be followed by more such packets.
0xCA86 [u] Screen x. Every screen that Belmont moves right, this increments, and vice versa.
0xCA8D [u] Screen y. Every screen that Belmont moves downward, this increments, and vice versa.
0xCA90 [p] pointer to base of 4x4 tile-chunk map. Each tile-chunk is 16 bytes, each byte representing 1 tile in the chunk. This generally depends on the level.
0xCA92 [p] pointer to bank 6 base of 4x4 tile chunk data for this sublevel. Every 20 bytes is a screen of 4x4 tile chunks.
0xCA97 [u] low-byte is current screen in tile chunk data. This is set by looking up the screen (x,y) coords in the $DD00 screen array.
0xCBE0... array of what lanterns have been smashed. (e.g. if Belmont returns to this area, then the lantern will remain gone.)
0xC8D0 subweapon (0: none. 1: axe (us) / cross (jp). 2: holy water)
0xC8D1 whip upgrade (0: leather. 1: chain. 2: fireball)
0xCC80 [d2] time remaining
0xCC86 [d] hearts
0xCC89 [u] Belmont's hitpoints
0xC88C [u] next free index of $c980 array plus $80.
0xD000 - 0xD800: copy of vram background tiles? Presumably for access outside of vblank/hblank.
0xDD00 - 0xDDFF: Sublevel area layout. A grossly inefficient use of space. A 16x16 array of screens. The low byte in the array indicates which screen of 4x4 tile chunk data to use (i.e. added to the pointer at $CA92). High byte as follows: (9-begin. 8-middle. A-end. B-single screen.). This array is indexed by the x and y screen coordinates at $CA86 and $CA8D.
0xDEA0 [u] scratch? entity loading: x position. Also commonly used as an iterator.
0xDEA1 [u] scratch? entity loading: y position. Also commonly used as an iterator.
0xDEA4 [u] scratch? entity loading: index
0xFF80-0xFFFE stack (127 bytes)

Entities

Each entity has 20 bytes of data, located at **00 (where ** ranges from C0-D7).

    • 00: entity ID (see the ROM map for a listing)
    • 01: state?
    • 05: entity load index (see $DEA4)
    • 09: sprite flags (flip, palette, etc.)
    • 0A: image (see "Images" in ROM map)
    • 0B-0D: animation data (TODO)
    • 0F: [s2] Y velocity (subpixel, pixel)
    • 11: [bu2] Y position (pixel, subpixel)
    • 14: [s2] X velocity (subpixel, pixel)
    • 16: [bu2] X position (pixel, subpixel)
    • 18: timer