Legend of Zelda/Technical Information - Revision history

Neil at 23:34, 24 December 2025

2025-12-24T23:34:13Z

← Older revision		Revision as of 23:34, 24 December 2025
Line 163:		Line 163:
	== Additional references ==		== Additional references ==

	[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.		[https://web.archive.org/web/20200817053838/http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

	[~~http~~://www.~~obelisk~~.~~me.uk~~/~~6502~~/~~reference.html~~ 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.		[https://www.nesdev.org/wiki/Instruction_reference 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

	[http://wiki.nesdev.~~com~~/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.		[http://wiki.nesdev.org/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
	__FORCETOC__		__FORCETOC__

Fiskbit: Dungeon graphics corruption - Adds a screenshot and improves the description of the glitch.

2019-03-06T14:22:26Z

Dungeon graphics corruption - Adds a screenshot and improves the description of the glitch.

← Older revision		Revision as of 14:22, 6 March 2019
Line 150:		Line 150:

	=== Dungeon graphics corruption ===		=== Dungeon graphics corruption ===

			[[File:Glitch_dungeon_graphics_corruption.png]]

	When entering a dungeon on the same frame that a background block is changed, such as an armos statue or bombable wall, there's a 50% chance that the dungeon graphics won't load properly, resulting in the overworld graphics being used but with some minor corruption. While some of the corruption will persist until reset, the issue is mostly corrected upon leaving the dungeon.		When entering a dungeon on the same frame that a background block is changed, such as an armos statue or bombable wall, there's a 50% chance that the dungeon graphics won't load properly, resulting in the overworld graphics being used but with some minor corruption. While some of the corruption will persist until reset, the issue is mostly corrected upon leaving the dungeon.
Line 155:		Line 157:
	When you change areas, the game has to copy over all of the area's graphics from ROM to VRAM. This can't be done directly; instead, the game has to tell the PPU where in VRAM it wants to put the graphics, and then hands the bytes to the PPU one-by-one to put at the specified location. After each byte is written, the target address is automatically incremented by the PPU, and there's a PPU setting that controls whether the increment is by 1 or 32. This is to make it easy to change adjacent 8x8 tiles on the screen; if incrementing by 1, it'll target the next tile in the row, and if by 32, the next tile in the column (because rows are 32 tiles wide).		When you change areas, the game has to copy over all of the area's graphics from ROM to VRAM. This can't be done directly; instead, the game has to tell the PPU where in VRAM it wants to put the graphics, and then hands the bytes to the PPU one-by-one to put at the specified location. After each byte is written, the target address is automatically incremented by the PPU, and there's a PPU setting that controls whether the increment is by 1 or 32. This is to make it easy to change adjacent 8x8 tiles on the screen; if incrementing by 1, it'll target the next tile in the row, and if by 32, the next tile in the column (because rows are 32 tiles wide).

	The graphics copying function assumes that the PPU is set to increment by 1 per write, but doesn't actually guarantee this by setting it this way. Background block updates in Zelda go vertically (increment by 32), so if that was the last thing to configure the PPU before you enter a new area, the setting will be wrong and the graphics copy will erroneously splatter the graphics data throughout VRAM (modifying only 1 out of every 32 bytes) instead of copying the contiguous chunks as it should. ~~Normally, things work correctly~~ because updates to the HUD leave the PPU in the correct increment-by-1 configuration. ~~The~~ HUD ~~is updated~~ every other frame, ~~regardless of whether~~ there is ~~new information to display, so even if~~ you enter on the ~~same frame as~~ the ~~background update~~, ~~the HUD update has~~ a 50% chance of ~~properly configuring~~ the ~~PPU before~~ the ~~copy occurs~~.		The graphics copying function assumes that the PPU is set to increment by 1 per write, but doesn't actually guarantee this by setting it this way. Background block updates in Zelda go vertically (increment by 32), so if that was the last thing to configure the PPU before you enter a new area, the setting will be wrong and the graphics copy will erroneously splatter the graphics data throughout VRAM (modifying only 1 out of every 32 bytes) instead of copying the contiguous chunks as it should. This normally doesn't happen because updates to the HUD leave the PPU in the correct increment-by-1 configuration. HUD updates occur every other frame, so there is only a 1-frame window during which you can enter with the incorrect PPU settings. Because of the difficulty of timing these events to fall between HUD updates, you effectively have a 50% chance of triggering the glitch by entering a dungeon on the same frame as a background update.

	Because area graphics are loaded on every area transition, most of the issue is corrected by leaving the dungeon. However, some graphics are only copied to VRAM on power on or reset and will remain partially corrupted until then.		Because area graphics are loaded on every area transition, most of the issue is corrected by leaving the dungeon. However, some graphics are only copied to VRAM on power on or reset and will remain partially corrupted until then.

Fiskbit: Dungeon graphics corruption: Corrects statement about how long corruption lasts.

2018-10-19T18:08:15Z

Dungeon graphics corruption: Corrects statement about how long corruption lasts.

← Older revision		Revision as of 18:08, 19 October 2018
Line 151:		Line 151:
	=== Dungeon graphics corruption ===		=== Dungeon graphics corruption ===

	When entering a dungeon on the same frame that a background block is changed, such as an armos statue or bombable wall, there's a 50% chance that the dungeon graphics won't load properly, resulting in the overworld graphics being used but with some minor corruption. While ~~most~~ of the corruption will persist until reset, the issue is ~~otherwise~~ corrected upon leaving the dungeon.		When entering a dungeon on the same frame that a background block is changed, such as an armos statue or bombable wall, there's a 50% chance that the dungeon graphics won't load properly, resulting in the overworld graphics being used but with some minor corruption. While some of the corruption will persist until reset, the issue is mostly corrected upon leaving the dungeon.

	When you change areas, the game has to copy over all of the area's graphics from ROM to VRAM. This can't be done directly; instead, the game has to tell the PPU where in VRAM it wants to put the graphics, and then hands the bytes to the PPU one-by-one to put at the specified location. After each byte is written, the target address is automatically incremented by the PPU, and there's a PPU setting that controls whether the increment is by 1 or 32. This is to make it easy to change adjacent 8x8 tiles on the screen; if incrementing by 1, it'll target the next tile in the row, and if by 32, the next tile in the column (because rows are 32 tiles wide).		When you change areas, the game has to copy over all of the area's graphics from ROM to VRAM. This can't be done directly; instead, the game has to tell the PPU where in VRAM it wants to put the graphics, and then hands the bytes to the PPU one-by-one to put at the specified location. After each byte is written, the target address is automatically incremented by the PPU, and there's a PPU setting that controls whether the increment is by 1 or 32. This is to make it easy to change adjacent 8x8 tiles on the screen; if incrementing by 1, it'll target the next tile in the row, and if by 32, the next tile in the column (because rows are 32 tiles wide).

Fiskbit: Technical Info: Adds a section on the dungeon graphics corruption bug.

2018-09-13T07:04:49Z

Technical Info: Adds a section on the dungeon graphics corruption bug.

← Older revision		Revision as of 07:04, 13 September 2018
Line 146:		Line 146:

	'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.		'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

			== Glitches ==

			=== Dungeon graphics corruption ===

			When entering a dungeon on the same frame that a background block is changed, such as an armos statue or bombable wall, there's a 50% chance that the dungeon graphics won't load properly, resulting in the overworld graphics being used but with some minor corruption. While most of the corruption will persist until reset, the issue is otherwise corrected upon leaving the dungeon.

			When you change areas, the game has to copy over all of the area's graphics from ROM to VRAM. This can't be done directly; instead, the game has to tell the PPU where in VRAM it wants to put the graphics, and then hands the bytes to the PPU one-by-one to put at the specified location. After each byte is written, the target address is automatically incremented by the PPU, and there's a PPU setting that controls whether the increment is by 1 or 32. This is to make it easy to change adjacent 8x8 tiles on the screen; if incrementing by 1, it'll target the next tile in the row, and if by 32, the next tile in the column (because rows are 32 tiles wide).

			The graphics copying function assumes that the PPU is set to increment by 1 per write, but doesn't actually guarantee this by setting it this way. Background block updates in Zelda go vertically (increment by 32), so if that was the last thing to configure the PPU before you enter a new area, the setting will be wrong and the graphics copy will erroneously splatter the graphics data throughout VRAM (modifying only 1 out of every 32 bytes) instead of copying the contiguous chunks as it should. Normally, things work correctly because updates to the HUD leave the PPU in the correct increment-by-1 configuration. The HUD is updated every other frame, regardless of whether there is new information to display, so even if you enter on the same frame as the background update, the HUD update has a 50% chance of properly configuring the PPU before the copy occurs.

			Because area graphics are loaded on every area transition, most of the issue is corrected by leaving the dungeon. However, some graphics are only copied to VRAM on power on or reset and will remain partially corrupted until then.

	== Additional references ==		== Additional references ==

Fiskbit: Forced Drops - Fixed misinformation in the Overkill section on how health is handled.

2018-02-28T10:42:51Z

Forced Drops - Fixed misinformation in the Overkill section on how health is handled.

← Older revision		Revision as of 10:42, 28 February 2018
Line 141:		Line 141:
	Vires are more robustly written and don't suffer from this bug.		Vires are more robustly written and don't suffer from this bug.

	'''Overkill''': When an enemy is killed by a weapon, it still finishes checking the remaining weapons that frame, as normal. This means it can be hit by those additional weapons~~. Because the enemy is dead~~, ~~it has 0 health, so any other weapons hitting it that frame will~~ also kill it. The consecutive kill counters are incremented at kill time, so these additional kills will each increment the counters like with any normal kill. As a result, killing a single enemy by hitting it with multiple weapons on one frame can add more than one to the ~~count~~. This can be done most practically by timing multiple attacks to hit when an enemy's iframes expire. Note that the order in which weapons are checked can impact how many kills the enemy gives because each weapon hit ~~reduces~~ the health for the ~~next weapon~~. Weapon check order is boomerang, beam (sword/rod), flame/bomb slot A, flame/bomb slot B, sword, ~~and~~ arrow/rod.		'''Overkill''': When an enemy is killed by a weapon, it still finishes checking the remaining weapons that frame, as normal. This means it can be hit by those additional weapons, which may also kill it. The consecutive kill counters are incremented at kill time, so these additional kills will each increment the counters like with any normal kill. As a result, killing a single enemy by hitting it with multiple weapons on one frame can add more than one to the counts. This can be done most practically by timing multiple attacks to hit when an enemy's iframes expire.

			Note that the health the enemy has after a killing blow can vary. If the weapon damage was equal to the enemy's current health, the resulting health is 0, so any following hits will count as kills. However, if the damage was more than the current health, the health is unchanged. Furthermore, the order in which weapons are checked can impact how many kills the enemy gives because each weapon hit may reduce the health for the following weapons. Weapon check order is boomerang, beam (sword/rod), flame/bomb slot A, flame/bomb slot B, sword, arrow/rod.

	'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.		'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

Fiskbit: Forced Drops - Adds a section on overkill causing multiple counts on one enemy.

2018-02-28T07:45:36Z

Forced Drops - Adds a section on overkill causing multiple counts on one enemy.

← Older revision		Revision as of 07:45, 28 February 2018
Line 140:		Line 140:

	Vires are more robustly written and don't suffer from this bug.		Vires are more robustly written and don't suffer from this bug.

			'''Overkill''': When an enemy is killed by a weapon, it still finishes checking the remaining weapons that frame, as normal. This means it can be hit by those additional weapons. Because the enemy is dead, it has 0 health, so any other weapons hitting it that frame will also kill it. The consecutive kill counters are incremented at kill time, so these additional kills will each increment the counters like with any normal kill. As a result, killing a single enemy by hitting it with multiple weapons on one frame can add more than one to the count. This can be done most practically by timing multiple attacks to hit when an enemy's iframes expire. Note that the order in which weapons are checked can impact how many kills the enemy gives because each weapon hit reduces the health for the next weapon. Weapon check order is boomerang, beam (sword/rod), flame/bomb slot A, flame/bomb slot B, sword, and arrow/rod.

	'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.		'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

Fiskbit: Forced drops - Clarifies when stabbing multiple dodongos will and will not drop forced bombs.

2018-02-09T11:52:44Z

Forced drops - Clarifies when stabbing multiple dodongos will and will not drop forced bombs.

← Older revision		Revision as of 11:52, 9 February 2018
Line 129:		Line 129:
	There are some notable special cases and edge cases with counters. These include:		There are some notable special cases and edge cases with counters. These include:

	'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link ~~rapidly~~ kills ~~multiple dodongos~~ with a sword~~, only~~ one bomb will drop because the forced drop system has no way of queuing up multiple forced bombs.		'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link kills a second dodongo with a sword before the first one has dropped its bomb, the second will not drop a bomb because the forced drop system has no way of queuing up multiple forced bombs.

	'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.		'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

Fiskbit: Screen scroll glitch - Minor wording improvement.

2017-12-28T14:24:26Z

Screen scroll glitch - Minor wording improvement.

← Older revision		Revision as of 14:24, 28 December 2017
Line 103:		Line 103:
	A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.		A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

	To fix this issue, the game includes a hack to ensure that the ~~subgrid offset~~ Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.		To fix this issue, the game includes a hack to ensure that the vertex Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

	Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.		Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

Fiskbit: Adds technical sections on object movement and the screen scroll glitch.

2017-12-27T23:59:49Z

Adds technical sections on object movement and the screen scroll glitch.

@@ Line 1: / Line 1: @@
 ''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''
-== Object system ==
+== Objects ==
 The game allocates memory for up to 19 objects of varying types. These types and their indices are:
@@ Line 82: / Line 84: @@
 '''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.
 == Forced drops ==

Fiskbit: Technical Information - Forces table of contents.

2017-11-17T10:37:12Z

Technical Information - Forces table of contents.

← Older revision		Revision as of 10:37, 17 November 2017
Line 122:		Line 122:

	[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.		[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
			__FORCETOC__