A Link to the Past Crystal Switches: One Byte, Whole Dungeon

Walk into a room in A Link to the Past you have never opened, and sometimes the orange panels are already down and the blue ones are already up. You did not do that in this room. You did it four rooms ago, at a switch that looks nothing like this one and has no wire, no line of sight, and no obvious connection to it at all.

That is not a bug and it is not your memory playing tricks. It is how the mechanic is built. One byte runs every switch and every panel in the dungeon, and the game is not being clever about hiding that — it is just never asked to be more precise than that.

One byte runs every Switch Fence in the dungeon

The object itself has two names. Zelda Wiki catalogues it series-wide as the Shock Switch, with Crystal Switch as the name used in A Link to the Past specifically. The blocks it moves go by their own name too, the one used across ALttP strategy content: Switch Fences — Zelda Wiki's own term for the object is Elevator Block.

Here is what ties every one of them together, in every room of a dungeon, at once. The zelda3 decompilation names the flag plainly: $7EC172, declared orange_blue_barrier_state and documented in the disassembly's own RAM notes as "Orange/blue barrier state." The switch sprite's own code reads that byte to pick its palette, LDA \$7EC172 : AND.b #\$01, and on a hit flips it with a single instruction, EOR.b #\$01 : STA \$7EC172 — an exclusive-or against 1, which is just a bit flip: on becomes off, off becomes on, every time.

That is the entire state of every crystal switch and every Switch Fence in the current dungeon: one bit, in one RAM address, read by every instance of the sprite. There is no per-room copy and no per-switch copy. When you hit one, you are not telling that switch to change — you are flipping a flag the whole dungeon shares.

The panels honor it just as bluntly. Every time a room loads, Dungeon_LoadAttributeTable checks that same byte and, if it is set, calls Dungeon_FlipCrystalPegAttribute, which walks the room's entire collision table and toggles every tile carrying the Switch Fence attribute. That call does not care whether you personally hit a switch in this specific room. It cares what the shared byte currently says, full stop. Walk into any room with Switch Fence panels and they will already match whatever you last left the byte set to — even if this is the first time you have ever set foot in that room.

What flips it, and what does not

Getting the flip to register takes a real swing, not contact with the object.

The poke exclusion is deliberate and it is named in the disassembly's own label. The switch's per-frame update reads $3C — the same counter the game uses everywhere else to track how many frames you have been holding the sword button on this swing — and if that counter is anywhere past 8, the routine branches straight to a label the disassembler called .ignore_player_poke_attack and returns without ever testing for a hit. The hitbox test it would otherwise run, Player_SetupActionHitBox, is annotated in the same disassembly as being specifically for "the pokey player hit box with the swordy" — it is the sword's hitbox, keyed off that same frame counter, and $3C only sits in that 1-to-8 window during an actual completed swing. Hold the blade out instead of swinging it, and the counter climbs past 8 into the range the game uses to start charging a spin attack — which is exactly the state the switch's own gate exists to reject.

Walking or dashing straight into the switch does something else entirely, and it is worth knowing so you do not mistake it for a broken interaction. That contact runs through Sprite_CheckDamageToPlayer_same_layer, not the hit-detection branch, and it calls Sprite_RepelDashAttackLong — the switch just bounces you off it, like a wall. No damage, no flip, nothing to fix. If you want the panels to move, you have to actually hit it.

One byte is also why the same rule about full-health sword beams tracks the crystal switch's rule about pokes so closely — both gate on that same $3C swing counter, just in different routines for different purposes. The damage guide covers what a beam is worth once it fires; this is the counter that decides whether either one fires at all.

The flip runs on a delay, not on contact

A connecting swing does not flip the byte on the spot. It schedules a countdown at a separate per-sprite timer, $0EA0, and the switch decrements that timer every frame until it lands on exactly $0B — 11 — at which point it finally runs the EOR #\$01 that actually changes the shared byte, and plays the switch's sound effect. Until that countdown lands, hitting the same switch again does nothing at all: the routine's very first check on the frame is LDA \$0EA0, X : BNE .switching_already_scheduled, which skips straight past the hit test while a flip is already in flight.

The switch is not idle while you wait on it, either. Whenever its sparkle timer ($0DF0) reaches zero, it spawns a particle and resets that timer to $1F — 31 frames — so the object visibly sparkles on a fixed cycle the whole time it sits there, pending flip or not. If you swing and nothing seems to happen immediately, that is normal. The game is running the countdown out before it commits.

The state is never saved

$7EC172 lives in WRAM, not SRAM, and nothing in the switch's own code ever writes it to your save file. The only place it gets forced back to a known value is Dungeon_LoadEntrance — the routine that runs when you walk into a dungeon through its own door — which zeroes it out along with the room's torch and pot-reveal state on the way in. Leave through that same entrance and come back, and every Switch Fence panel in the dungeon is back to its default position, regardless of what you flipped on your last trip through.

That single reset point is also why the "already flipped" moment described at the top of this guide only ever happens mid-visit. Within one continuous run through a dungeon, the byte only moves when you hit a switch. Between visits, it is wiped clean at the door.

Do not confuse it with a Cane of Somaria block

A Link to the Past has a second thing people call "the orange and blue blocks," and it runs on completely different code. The Cane of Somaria conjures a single temporary block wherever you are standing, and its existence is tracked by its own flag, dung_flag_somaria_block_switch, entirely separate from the Switch Fence byte covered above. A Somaria block is yours to place, one at a time, and it disappears on its own or when you summon another. A Switch Fence panel is fixed dungeon furniture that was there before you walked in, and the only thing that moves it is the shared crystal-switch byte. If a guide tells you to "stand on the block" for a puzzle, check which one it means — the two systems share a color scheme and nothing else. The magic guide has what casting Somaria actually costs; it is not on this page because it is not the same mechanic.

Pushable statues are a third, equally unrelated system, worth naming for the same reason as the Somaria block: it is easy to see a stone object in a dungeon and assume it answers to the crystal-switch byte when it does not. Statues answer to push and pull speeds instead, which the movement speed guide already covers in full — that same guide is also where the throwaway line about "touching a crystal switch restores your walking speed while carrying an object" comes from, which is a real side effect of the byte covered here, just not one this guide is centered on.

Where you will actually meet it

Zelda Wiki's own catalogue of the object is blunt about how often this comes up: in A Link to the Past, Shock Switches are used, in the wiki's words, "mainly for Elevator Block puzzles throughout Dungeons" — not one signature room you can point to and be done, but a mechanic the game leans on repeatedly across its dungeon list. Read this guide as the rule for whichever room you are standing in, not as a locator for one specific puzzle.

The practical upshot in any dungeon that leans on this: track the color, not the room. If you last hit a switch and left it orange, every panel you meet from here until you leave through the entrance will be orange too, on the first frame you see it. That is not the game tracking your progress through the dungeon. It is the game tracking one bit.