A Link to the Past
Cave State
Cave state refers to sneaking the dungeon ID for caves into areas of the underworld that are parts of dungeons. There is also a second cave state that can be achieved by using shelf shift while in the standard cave state.
Basic explanation
While in the underworld, the game stores the current dungeon ID at $040C. When Link is in a cave or house, this address will be set to 0xFF, which can be thought of as -1—a value the game understands as "Link is not in a dungeon." When dungeon specific actions are taken, such as pressing to open the map or using the mirror, the game checks that $040C is not 0xFF before letting that action happen.
Through using major glitches, players can enter the underworld in a cave and travel to other areas in the game, including dungeons. Having the cave state dungeon ID while in a regular dungeon will have a few interesting effects.
XOR cave
If the player uses the shelf shift while in cave state, the 0xFF dungeon ID will be exclusive OR'd by 2. This leads to the dungeon ID becoming 0xFD, a value that was never intended to occur. Being in this state is known as xor cave state or fd state.
Effects
Limited actions
With the cave state dungeon ID set, Link will be unable to use the mirror or open the map, even if he's physically in a room that belongs to a dungeon. The map is typically unimportant in speedrunning, but use of the mirror to warp to the last used entrance can be a valuable routing option. This is one of the main downsides to being in cave state.
If the player is in xor cave state, then the mirror and the map will work. Using the mirror will return Link to the original entrance he used to the underworld, the same as if he were in a dungeon. The map will have buggy and unpredictable behavior.
Small keys
Every time Link enters a cave, the address that holds his current key count $7EF36F is set to 0xFF. This is a value that prevents the game from drawing the small key counter on the HUD. However, this special value has no other consequences. 0xFF in an unsigned integer context is 255, so Link effectively has 255 small keys every time he enters a cave.
Obtaining a small key while he has 255 will overflow the count to 0 small keys. Since the game doesn't track cave small keys and the value is set to 0xFF every time, small keys obtained in cave state are effectively lost.
Big keys
Big keys interact strangely with cave state. There are a set of big keys that, if Link has collected them, will work in cave state and allow Link to open any big key doors or big chests. And there are a separate set of big keys that Link will acquire when he receives a big key while in a cave state.
A couple of the dungeons listed below don't have big keys in the game normally: the Sewers and Castle Tower. Link is still able to collect a big key for either of them though, either through these cave state mechanics or through entering one of them normally and glitching to another dungeon and stealing its big key.
Big keys that work in cave states
When attempting to open a big chest or big key door or lock, the game's check will allow for one of several dungeon's big keys to pass.
| Dungeon ID | Dungeon big key | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HC | Sewers | EP | DP | ToH | CT | PoD | SP | SW | TT | IP | MM | TR | GT | |
0xFF | ✔️ | ✔️ | ❌ | ❌ | ❌ | ✔️ | ✔️ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ✔️ |
0xFD | ✔️ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ |
Big keys that are set in cave states
When grabbing a key in a cave state, multiple dungeons' big keys will be marked as obtained.
| Dungeon ID | Dungeon big key | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| HC | Sewers | EP | DP | ToH | CT | PoD | SP | SW | TT | IP | MM | TR | GT | |
0xFF | ✔️ | ✔️ | ❌ | ✔️ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
0xFD | ✔️ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Big key technical explanation
This section goes into very technical detail. The information is presented with the assumption that the reader has at least basic knowledge of hexadecimal, bitwise operations, SNES memory, and/or SNES assembly.
What big keys Link has are held in a 2-byte bitfield at $7EF366 in save RAM. Dungeons are assigned bits in that bitfield via bitmasks. If the bit for a dungeon is 0, then Link doesn't have the big key, and it'll be set to 1 if he does.
For checking if Link has a big key when he interacts with a big key lock, the game will look up the bitmask corresponding to the current dungeon by indexing a table of bitmasks by the current dungeon ID. So looking at Hyrule Castle as an example, the dungeon ID will be 2. If Link interacts with a big key lock while in Hyrule Castle, the game will index the bitmask table using the number 2 and pull the mask 0x4000. This number is 0100 0000 0000 0000 in binary, meaning the game should check the 14th bit (or the 2nd most significant bit) at $7EF366 for determining if Link has the Hyrule Castle big key or not. But in cave state, Link's dungeon ID is 0xFF, so the game will look at the 255th "index" of the bitmask table. Unsurprisingly, there aren't that many entries in the bitmask table, and the game ends up pulling an arbitrary 2 bytes from elsewhere in the ROM to use as a mask. Because these bytes aren't intended for masking, they'll have multiple bits "on", creating the observed effect where the game checks for multiple different big keys.
Setting the big keys is similar, except the game indexes a separately defined table of bitmasks. This other table of bitmasks has the same definitions, but it's located at a different address in the game's ROM. This means when its 255th index is read, a different 2 byte value will be pulled and used for setting the big key vs the one used for checking a big key. The overall effect is similar (multiple big keys are set due to the 2 bytes used in an unintended masking context), but the exact values are different.