A Link to the Past I-Frames: 58 Frames After a Hit

Action games hand you a mercy window after a hit. A Link to the Past's is unusually easy to pin down, because it is not a system — it is a single byte that gets loaded with one number and decremented once a frame, and damage routine after damage routine asks the same question about it before doing anything.

The number is 58. Here is what it buys.

The timer is one byte, and it holds 58

The byte lives at RAM address $031F. The disassembly's own RAM notes describe it as a "countdown timer that, when it's set, causes Link's sprite to blink, i.e. flash on and off" — which undersells it, because the blinking is the cosmetic half. The damage routines care about the same byte.

When an enemy lands contact damage, the player's control handler runs this:

• if $031F is already non-zero, leave it alone
• otherwise load it with #$3A — 58 in decimal
• play the hurt sound, then subtract the damage from Link's health at $7EF36D

That is the whole setup. The disassembly and the zelda3 decompilation agree byte for byte here: the C rewrite's control handler reads if (countdown_for_blink == 0) countdown_for_blink = 58;, in the same order, in the same routine.

The decrement happens once per frame inside the routine that builds Link's sprite, and it is gated on submodule_index being zero — normal play. The counter does not tick while the game is running a transition or a menu submodule, so a mercy window does not quietly burn off while you are reading a text box.

At the SNES's roughly 60 frames a second, 58 frames is about 0.97 seconds. Call it a second and you will not be far wrong.

What 58 frames of flashing switches off

This is the part worth internalising, because the window is wider than "enemies can't touch you". It also covers several hazards that look environmental, and are handled by routines that consult the same byte.

Two of those are worth saying out loud. Your own bombs obey your i-frames — the bomb routine loads the same 58 and tests it the same way, so a second blast that goes off inside the first one's window does nothing to you. And the spike tiles are not a special environmental damage type with rules of their own; they query the same byte as a Moblin's spear.

That last row is the odd one. Being hit does not only protect you, it also suspends a dungeon room tag: while the flash timer is running, the "trigger activated chest" tag routine returns without doing its work. Getting clipped on the way into a room can stall the thing you came in to trigger.

Nineteen frames stunned, fifty-eight frames safe

There are two timers doing two different jobs here, and they are easy to conflate.

When a sprite damages you, the routine sets $46 to #$13 — 19 and applies recoil at strength #$18 (24). The RAM notes call $46 "a countdown timer that incapacitates Link when damaged or in recoil state. If nonzero, no movement input is recorded for Link." That is the knockback: you are launched, and for 19 frames the game ignores your d-pad.

The invulnerability byte was set to 58 in the same exchange. So the arithmetic is:

Thirty-nine frames of free invulnerable movement is the real prize — about two-thirds of a second in which no contact damage routine will touch you and your inputs are being read again. That is enough to walk straight through the thing that just hit you instead of backing away from it.

Note the damage amount itself is a separate lookup — the routine builds an index from the sprite's bump-damage class and your mail level and reads a table. The damage guide has those numbers; this post is about the clock, not the size of the hit.

The flashing stops before the protection does

The blink is drawn in Link's sprite routine, and the logic is specific: after decrementing, the game hides Link only when the counter is 4 or higher and even. Below 4, he is drawn normally.

So the visible flicker is 30 Hz — on one frame, off the next — and it runs from the top of the window down to 4. Frames 3, 2 and 1 are still invulnerable and no longer flashing. It is not much, and it only runs in your favour, but it means the obvious reading is wrong: the animation stopping is not the signal that your protection stopped. If you want the precise end of the window, count frames, not flickers.

The Magic Cape is a separate flag ($55) and behaves differently — it is checked first, and when it is active the control handler throws the incoming damage away and clears the stun timer instead of starting a countdown. Its magic drain is covered in the magic guide.

Spike floors and spiked tiles read the same byte

This is the practical payoff, and it is why the walk to the Cane of Byrna's chest is survivable on hearts alone.

The spike floor handler runs four checks in order before it hurts you:

1. Is the Magic Cape flag set? If so, no damage.
2. Is there a Cane of Byrna spark active? If so, no damage.
3. Is $031F non-zero? If so, no damage.
4. Otherwise, look up the damage by mail level and apply it.

The spiked and cactus tiles you bump into while walking — zelda3 calls the bitfield bitfield_spike_cactus_tiles — run the same idea with an extra term: the check is $46 or $031F or $55, stun timer or flash timer or cape, and any of the three makes the game ignore the tile. There is a grid quirk in there too; the disassembly's own annotation on the 4-pixel alignment test is "this is a tad strange, seems like more of a tweak than anything else", which is as good a description as any.

To be clear about which hazards this is: these are the two tile routines. Spiked enemies and traps that exist as sprites — the rolling spike trap, Big Spikes, Beamos, Sparks — take the ordinary sprite path instead, and their damage comes out of the bump-damage class table the damage guide lays out. They are still gated by $031F, because everything on the sprite path is. They just do not use these two routines.

The consequence is that a spike corridor does not drain you continuously. It charges you once, gives you 58 frames, charges you again. Walking spikes is a pacing problem, not an attrition problem, and the ALttP Speedrunning Wiki puts a number on one of them: to cross the spike floor guarding the Cane of Byrna chest on Dark World Death Mountain, it says you want 14 full hearts, or mail upgrades, or the Cape, or a refill in a bottle.

Both tile routines index their damage by your armour value at $7EF35B, so mail upgrades do reduce what they take. There are no per-mail numbers in this post, because the two sources do not settle them: the disassembly reads the values out of a ROM table the repository does not decode, and the zelda3 rewrite hardcodes the green-mail figure in both places. The mechanism is not in doubt — the lookup is armour-indexed in both routines, and the speedrunning wiki independently lists mail upgrades as a mitigation for that same spike floor. The size of the reduction is not something I can source, so I am not claiming one.

The 144-frame windows

58 is the combat number. There is a second, much longer value — #$90, 144 frames, about 2.4 seconds — that the game hands you when it puts you somewhere you did not walk to. In the decompilation it is written into the same byte by:

One routine covers two of those rows. The indoor and outdoor pit-recovery submodules both hand off to the same recovery routine the game uses after you go into deep water without the Flippers, and that routine is where the 144 is written — which is why a hole in a dungeon and a hole on the overworld pay out the same number.

The pattern across the table is that none of these are arrivals you walked into: the screen resolves around you, and you get roughly two and a half times the normal grace period to read it. Note which way the Magic Mirror row runs, though — the Mirror carries you out of the Dark World and back to the Light World, so those 144 frames land on the Light World screen you arrive on, not the one you left.

What it will not save you from

The window governs damage routines. It does not govern the things that are not damage routines, and the list of exclusions is short but sharp:

• Falling in a hole. The pit branch runs before the spike-tile check in the same handler and never looks at $031F. Flashing does not let you skate over a hole.
• The heart the hole costs you. Pit damage does not go through the damage routine at all. TakeDamageFromPit subtracts 8 — one heart — straight out of Link's health, with no mail lookup and no invulnerability check in front of it. A pit costs the same heart in Red Mail as in Green.
• The death check itself. If the subtraction takes you to zero, the game switches to the death module and zeroes $031F on the way out. There is no i-frame window that saves you from the hit that kills you. Where you wake up afterwards is the subject of the death guide.
• Getting shocked again. The electrocution routine sets its own 64-frame timer on contact — six frames longer than the invulnerability it triggers. On paper, the shock outlasts the mercy.

And one genuinely funny exclusion in the other direction: the bomb routine checks whether the room's boss is already dead before it damages you, and skips the damage if it is. The disassembly's comment is "If the boss is beaten Link is invincible!" Your own bombs cannot hurt you in a cleared boss room.

Useful mental model for all of it: the game is not really tracking your invulnerability. It is tracking whether Link's sprite should be blinking, and a whole set of separate routines have quietly agreed to treat "is he blinking" as "leave him alone".