GUIDES & MAPS

• Red Candle, speed tech and info for all stages of learning http://redcandle.us/The_Legend_of_Zelda
• Walkthroughs for various routes: https://sites.google.com/view/orderoftheate/the-legend-of-zelda
• Room Tutorial Series (advancing players, incomplete): http://redcandle.us/The_Legend_of_Zelda/Room_Tutorial_Series
• All Z1 Game maps: http://nesmaps.com/maps/Zelda/Zelda.html

TEACHING VIDS

• Screen Scroll tutorial. How to wrap Link around the screen:
• Added screen scroll tech. Instant turnaround -- https://www.youtube.com/watch?v=UBI-0vvfNDU

ROM PATCHES

• REMOVE FLASHING PATCH -- Approved for speedrun attempt use: https://drive.google.com/file/d/1aSn3oQ4mnRJuqaNJS6UzZfdwpk7aZ9LC/view
• PRACTICE ROM PATCH - not for use in speedrun attempts - (READ the README.txt) -- https://www.speedrun.com/the_legend_of_zelda/resources/2qzpq

SAVE STATE PACKS

• Everdrive N8 Pro, level-2 starting routes: https://www.speedrun.com/the_legend_of_zelda/resources/zie90
• Everdrive N8 Pro, 3-first routes: https://www.speedrun.com/the_legend_of_zelda/resources/jl5vt
• Everdrive N8 OS v1.23 (may work above 1.23), Level-3 manipulations, help videos included: https://drive.google.com/file/d/1Qt4RvVZCKd7IQ8zGKdy15qKjUShmDrao/view?usp=sharing

MISC.

• Global Count Tracker: https://doctorblue.github.io/Zelda-Global-Tracker/
• OBS -- Record and/or livestream your runs: https://obsproject.com/download
• avidemux -- Examine, time, cut, and re-encode your recordings: http://avidemux.sourceforge.net/
• Livesplit -- Display a run timer: http://livesplit.org/introduction/
• somewes.com -- Get exact run times from VODs or local recordings: https://somewes.com/frame-count/

In accordance with this old sticky post -> https://www.speedrun.com/zelda1ce/thread/6up72

The game rules and relevant category rules have been updated. All Japanese runs submitted during the lapse have been re-timed, with time added as if they were run with English text.

Follows this thread from main board: https://www.speedrun.com/the_legend_of_zelda/thread/14xq4

Noting the exception that Extensions did already have some Game Rules listed, where the main board previously listed no Game Rules listed.

We've updated our "Game Rules" today, answering some frequently asked questions where every potential runner can easily read them.

The rules seem rather lengthy, but the only changes to our previous verification standards are as follows (and I'll expand on each): --We are explicitly allowing P2 Up+A to be bound to a single input. --We are now provisionally accepting runs on ARM/Mobile devices (e.g. smartphones). --We have a recommended emulator core list. --We are asking users to indicate what emulator, FPGA, or hardware mods were used.

P2 Up + A single binding. First of all, speedrunners had already been taping, clamping or rubber banding buttons on original hardware. The net effect for the runner is that one less button needs pushed. We accepted runs that did this. So, we're expanding the rules to allow all our potential runners that convenience. When previously asked about it we didn't think it was unfair if anyone had used a trick to make P2 Up + A a single input, but we discouraged runners from doing it in the future. Our ableist rationale was that it's trivial either way. But the fact is that while for most of us there is no difference between pressing one button or the two, for someone out there it could make a difference. We'd rather even the field for such a runner. But this allowance is intended to be limited to P2 Up+A. We don't intend for runners to further expand this rule for any other purpose. If you want to duplicate P1 input to P2, which due to a quirk in the game's program can cut a lot of lag frames, you have to do it manually.

About Smartphone emulation I've done preliminary testing and found no inaccuracy. We've researched the programs and what we learned has given us some confidence in their quality. The recommended smartphone apps use well-known x86/PC cores like Nestopia and FCEU. So, we don't have any specific reason to think they are advantageous, or less accurate than x86/PC emulators which themselves are not perfect. Should we find a significant inaccuracy in any gaming device we will of course examine it and per our standards for comparison to original hardware, remove runs that gained an advantage due to CPU/PPU inaccuracy.

We are recommending emulator cores now, as this is one of our most frequently asked questions. There are multiple resources on the internet, but this contains tables http://emulation.gametechwiki.com/index.php/Nintendo_Entertainment_System_emulators#cite_note-libretro-1

Indicating emulator, FPGA, modification use. As we're allowing a new platform provisionally, we'd like to keep a better public record of what programs are being used in case we do need to go back and check videos. We're expanding that to all platforms. No comment would imply unmodified original hardware. We will message you to get that information if you do not add it.

There's been a whirlwind of ideas and WRs over the past few days. One idea was what is done in this video by Neerrm which is not a PB for him, but it is a unique route that runners should be aware of.

Using only Flybot's charged up slam move he does the run in six fights, same as my 1:45 and his 1:47 runs, but with Two At-Bats instead of one.

The obvious benefit of using a Flybot is being able to completely avoid being hit while charging up a massive attack as soon as the fight gets underway. The downside to Flybot is that hovering and charging drains its power so quickly that you need almost a full bar to deal over 200 damage with a charged attack. For a 6F/1AB route (used in the WR runs) to go fast, you must get into fights with the 3B at a distance no less than 76M from home plate, and then with the SS at 85M. At the start of every fight, the distance between your runner and the next base is counted up, and during that time your maximum power bar for the fight is drained. Flybot won't have enough juice to deal a massive hit during those fights. So our solution was just to do 2 at-bats, so every fight would start with a low distance value and a high power bar.

However, Neerrm theorized that a Flybot 6F/1AB route could be feasible if done similarly to the 1:45 and 1:47 Tank runs. Do 255 damage to SS, 3B and C in the first fights. In the second fight with SS and 3B, still using your first batter/runner, whittle down the opponent to about 46 with your gun, then do a small charged slam to finish them. We don't have any working math to determine if that would be faster or slower than the current prevailing route. Nor am I aware of what might be causing fully-charged attacks to sometimes have their damage reduced from 255.

Open RBO was previously called True RBO. It was renamed to dispel any notion that the other reverse categories were 'false' or 'less true'.

The run time end frame is now defined as when Aquamentus' heart container reward appears.

Thanks to a Randomizer update, Second Quest Open RBO can now be made to start the player with the Raft, allowing the bosses to be beaten in reverse order. As of this post, there had been no submissions for Open RBO 2Q.

Short version: Do not speedrun this game on RetroArch, it has settings which can cause inaccurate emulation. We recommend using current versions of Nestopia, FCEUX, Mesen, and higan/bsnes; or, OpenEmu with one of the those cores.

Full version: For the time being, we will not accept runs on RetroArch due to the potential for large scale inaccuracy which was recently discovered in runs of another game. It was detected when the run didn't experience what some call 'NES slowdown' during a well-known circumstance that should produce slowdown. The runner claimed to be using RetroArch.

In TLOZ, the most obvious manifestation of NES slowdown is on overworld screens with Octoroks and Moblins, and in the Blue Darknut and Turret rooms in Level-8. Slowdown also happens, less obviously, during screen transitions and while loading caves and dungeons.

The exact cause of inaccuracy is yet unknown, but the affected runner claimed to be using RetroArch with some of the latency reduction features turned on. RetroArch is actually a front end program that basically runs other emulators' cores (the program that emulates hardware). There has been limited investigation running the circumstance above on NES hardware, FCEUX, mesen, bizhawk, bsnes, and in RetroArch running each of those cores on default latency settings. Tests all produced more slowdown than the inaccurate run in question.

So, while RetroArch is at least capable of being accurate, there's still a question of whether and which of its front end settings employed by that runner created the inaccuracy. Not knowing the causes means we don't have a way to recommend correct settings in RetroArch.

I would prefer to not ban RetroArch under mere suspicion, but the burden on moderators to examine lag in runs is too high and we'd rather our runners not risk their runs using potentially inaccurate emulation. Given the number of other accurate and user-friendly emulators available the simplest solution right now is to warn runners off RetroArch and continue recommending current versions of Nestopia, Fceux, Mesen, Higan, and OpenEmu (with one of the those cores).

I'm looking into games that could be raced in a tournament I do with ~20 friends. We'd all at most have played the game casually. The game would be announced a month in advance of the tournament. I'm asking these questions rather than watching or playing because I'd like to limit my exposure to the speedrun so I don't have an advantage if it is chosen. (It's been 20+ years since I've played this)

My questions: Which versions of would be fair to race against each other? Does "PC" include the MS-DOS version (is it any good?)

The leaderboard makes it obvious that Tyris has the fastest potential. Are the slower characters easier in some way that in a race scenario they would be a viable choice, especially for the very casual participants? Basically, is Tyris a riskier choice?

How much time does it take to learn the speedrun and improve it? For example, what are the differences between a sub-10 run, a sub-9 run and a sub-8 run?

Since we'd be racing, the runs would presumably be no reset. This may be answered by the previous question, but how volatile is the run?

Thanks in advance for your guidance.

The categories TDO Glitchless† and Any% Twin Galaxies Rules are so-called glitchless categories. This post details exactly what is banned in these categories and why. It also gives examples of speed tech, including "glitches" and manipulations that are not banned and why. My hope is that this will give a foundation for the spirit of these categories both for present understanding and deciding on future discoveries.

NOT ALLOWED IN GLITCHLESS: Block Clips/Screen Scrolls Key Door Glitches Bait Storage Wrong Warps Arbitrary Code Execution, Save Corruption, Memory Corruption, Hardware Manipulation, etc.

Descriptions of tricks and glitches, and reasons for (dis)allowing.

Block clips/Screen scrolls The technique which allows the player to break through 1-pixel thick boundaries and do sequence breaks both small and large. It's easy to mindlessly clip when used to doing them in runs. If you clip through a boundary, immediately turn around and exit through the same boundary, or the run must be rejected. Being hit by enemies can also cause you to clip through boundaries. Your run won't automatically be rejected for something out of your control. If one happens in a submitted run, please bring it to the moderators' attention. Clips are disallowed because the game's obstacles have boundaries to prevent the player from passing through them and trivializing encounters.

Key Door Glitches The first practical example is re-entering Level-1 in first quest to pop the top lock. Another is known as "Khananakey" -- it is possible to walk through key doors without a key while a shutter door or bomb wall is opening.  This is not allowed because doors are meant to stop players who don't have keys.

Bait Storage Using Up&A when giving a hungry goriya gatekeeper the Bait/Food to clear the gatekeeper and keep the Bait. In gameplay, the Bait is a useful item that can be repeatedly used to corral enemy Goriyas (and other monsters!) without being consumed. Giving up your Bait to the hungry Goriya is a sacrifice of a useful item in order to progress. From a role play perspective, the Goriya cannot have its hunger satisfied if you still have the meat. Be the hero, let the hungry Goriya have its meal.

Wrong Warps, such as Roocorder The only known wrong warp that does not have a boundary clip as a prerequisite is Roocorder, which is riding a warp wind across a dock to launch the raft creating new warp destinations. Other known overworld wrong warps simply take the player back to the starting screen.

All other known glitches and manipulations are currently allowed in Glitchless. New discoveries will be considered after exploration of the costs and benefits and how they fit with the design of a category.† If you're wondering why a trick or glitch is allowed or think that it should be banned, please consider the following. Some glitches are unavoidable. Some have negligible benefits which may come at a price, or have no benefit at all. Sometimes a glitch or a manipulation may improve the reliability of an outcome, but not change what is possible. On the other hand, the effort of avoiding glitches can force the player into taking slower paths or higher risks simply for the sake of avoiding a bug.

Take the Master Goriya room in Level-2 for example. If you defeat the master while boomerangs are flying, when the boomerang returns to a dropped item it will change into a bomb. Banning this would force the player to one of these solutions: risk nothing, kill the master last; be cautious, kill the master when no boomerangs are flying; be careless, reset when glitches happen; avoid fighting them completely.

Let's weigh the quantifiable the benefits of the glitch. Without the glitch, the player already has a blind 52.7% chance of getting at least one bomb (barring bad PRNG distributions or unknown glitches affecting the drops). Global count manipulation increases the drop chance to 64.8%. In the unlikely scenario that five boomerangs return to dead Goriyas, another item will change into a bomb 83% of the time.

The boomerang glitch doesn't create a previously unavailable routing opportunity or break a sequence, it merely improves the efficacy of an action that would be taken regardless of the glitch existing. So we allow it, and other glitches based on similar reasoning.

Green gleeok head's 3/8 heart damage is another allowed beneficial glitch.

Object timer manipulations, e.g.: Tooting after waking an Armos; placing a bomb before tooting vs. Digdogger; tooting after touching a bubble; tooting during the Gannon fight.

PRNG manipulations are allowed. Gannon "stun lock" is a manipulation of Gannon's Left vs. Right respawn RNG and the fixed duration of his invincibility. Standing in the middle of a room to attract enemies toward you is in fact a PRNG manip. During pauses and game-initiated freezes (recorder toots, medicine chugs, item hoists) some timers with fixed or randomly assigned values controlling enemy actions continue to run. Money Making Game runs on PRNG -- results can be predicted and manipulated.

The way enemies are counted is limited to number and not type. Partially clearing enemies in a room and re-entering will change the enemy type. You can also despawn a boss by half-clearing it and re-entering.

† A more accurate category name given the rules would be "Numerical Level Order, Limited Sequence Breaks". The category was called Traditional Dungeon Order because some of its progenitors saw the it as a way to play the game similarly to how they did as a child. As a point of fact, the game is open world and different people had different ways to beat the game, including going to Level-2 first. Having 'Traditional' in the name was not meant to imply that playing the game differently was wrong in some way. If every individual in the community were to ban anything they didn't know as a kid, the category likely would allow practically nothing.

FIRST / SECOND QUESTS First Quest and Second Quest are shown as subcategories in order to reduce clutter. Unless the category specifically states to complete both quests, the rules imply completing the goals for the respective quest only. For categories that play both Quests, please submit the run under First Quest.

TDO Glitchless For explanations, see the forum thread: GLITCHES GUIDE https://www.speedrun.com/zelda1ce/thread/b32yk

CO-OP (online) The emu-coop is currently still in development and new sync options may become available. Most likely, all current and future 2-player sync types will be allowed for this category. If there's any separation it would likely be to add a variable that defines the sync mode used. Submission videos should include both players' complete gameplay. Either add a comment to the second video link, or produce a single video with both players' gameplay. One easier way to do this is to capture your partner's stream on yours. They won't be perfectly synced but that's fine.

2P1C 2 players, 1 controller. One person on the D-pad, the other on B+A. I don't know that we care to specify how Select and Start should be divided. Your video may be more interesting with both players on camera showing hands, but it's not required.

One-handed Use only one hand on the controller. Stabilizing your controller somehow is perfectly reasonable. A run cannot be verified without a hand cam.

Reverse Dungeon Order (RDO) You're allowed to enter any dungeon in any order you want, but you should defeat the bosses who guard the heart container and collect the Triforce of Wisdom pieces only in descending order. That means Gleeok (4-heads) in Level-8 and collect the triforce, then Aquamentus in Level-7, Gohma in Level-6 and so on. In Second Quest, refer to how the dungeons are listed in the game's display. Level-8 is the green level with Goriyas and three Dodongos as the boss. The boss of second quest Level-3 are the Dodongos that guard the heart.

FDS Prototype This is the only FDS specific run on the board. Moderators will remove loading times in excess of the Famicom cartridge version in order to level the field between devices. Sheet: https://goo.gl/dRxwEk

Open 9/RBO (hacked ROM) Open RBO and Open 9 Any% are played on a ROM generated by Fred's Zelda Randomizer using a specific Flag String in which Level-9 is open without having the Triforce of Wisdom completed. Select Swap does not change the flag string and is allowed, along with any flag that keeps the flag string. See: https://imgur.com/tf3wDzk In order to make Second Quest compatible with Open RBO, the Rando flag string starts the player with the Raft, so that the player can get the Bow without first beating boss Digdogger in Level-4. Link to Randomizer is in Resources.

Minimum B Presses and Max Keys are two new 'puzzle categories'. The rules are only going to state what is required for completion, leaving players the opportunity to figure out how it's done and route it for speed. Familiarize yourself with the maps and available glitches. Arbitrary Code Execution is not presumed to be used.

Max Keys just means finishing a quest with the highest number of keys possible without buying keys from a shop.

Minimum B presses means using your B button items the fewest number of times possible to complete a quest. Don't miss your Gohma shot!

In particular, Minimum B Second Quest is unreasonably difficult to achieve due to requiring hitting 3 Dodongos with one bomb. We'd like to have it sorted by Time subordinate to lowest B score, but speedrun.com doesn't directly support that so we'll have to rig something up to make that work. In the meantime, feel free to submit runs that didn't one-shot all Dodongos.

Also make sure to post here if you're almost certain the min/max is inaccurate.

Click the Level Leaderboard and view all to see all the itemGet categories that we've added.

These appetizer categories include the often asked for Magical Sword category, low% teaser Magical Key, and the cold calculating manipulation that is getting the Blue Ring.

K?

"Fairy Feet" is now allowed in the following categories in which it previously was not: Any% No OoB; New Game+ No OoB; Any% No Door Fairying (PAL B No OoB); and, the newer 100% No OoB category. The categories previously named "No OoB" are now called "NMG" for No Major Glitches. ZebGedney made us a very simple table for what tech is allowed in categories. https://docs.google.com/spreadsheets/d/1AGsrkwvp_CygiT75sUDcwwPClr9O3PDjT2boi-oxlSM/edit#gid=0

Fairy Feet was previous caught in a net of rules banning glitches related to Fairying near the edge of the screen.

What is Fairy Feet? Fairy Feet is the name for a specific setup that allows the player to effectively skip walking across the side-scroll encounter for two-sided overworld tiles. (Why is it called Fairy Feet? Because Saver found it while playing the game with his feet.)

The two-sided tiles are a specific type of spiked tile where the player was intended to pass through to get to the other side in the overworld. The list of these encounters: Darunia Pass, Wilson fences, Maze encounters, Valley of death lava encounters, Bubble skip and Bridges. A common workaround that has long been accepted in all categories is to set up random monster encounters and run into them on the spiked tile in order to skip doing the full length side scrolls. However, it was discovered that there's another way to skip side scrolls that doesn't involve random encounters.

When Link enters one of these specific types of side-scroll encounters, the game sets a flag. When that flag is on the game never actually checks which side of the encounter Link exits, instead checking his last known direction of movement upon exiting. It is possible, for example, to exit the left side of an encounter while moving right by stopping Link's leftward velocity completely just as he hits the exit plane then press right before exiting. This is difficult because Link's velocity rises and falls gradually every frame. Yet, Link never goes out of bounds doing this.

However, as a fairy Link's velocity can go from 0 to maximum and back to 0 on consecutive frames just by tapping a direction for one frame. So it's far easier for a human to do the encounter skips as a Fairy, despite the additional magic cost. Another way to instantly reverse Link's velocity is to be damage boosted in the exit plane. I watched Jamevil do it playing Z2Randomizer.

Hence, the glitch is not specific to being a fairy near the edge of the screen. Instead, it is merely an unexpected outcome of the working code just the same as skipping the same type of encounter by running into a random encounter on the spiked tile. Nevertheless, changing the category names away from "No Out of Bounds" dispels any need to debate the fact that Fairy Feet is not out of bounds.

The pitch is simple: We have filters; one filter can have numerous variables. But the filters allow the site users only to filter all but one variable per filter at a time. This works exactly the same when using a filter as a subcategory, but the filter displays as a single-click filtering choice at the top of a category. What I like about using subcategories as filters is that the subcategory button is directly between the category tabs and the time tables and that they are single-click to apply. The limitations are the same as filtering in the drop-down menu -- we can only select one. Is it possible to allow subcategory filters to have multiple defaults (ON) and multiple selections (ON)? This would the site user to more easily and view and select the runs they want to view.

This picture simplifies what I'm asking. https://imgur.com/gallery/BAegp

Background for the request I moderate Zelda 1, and we would like to improve our category layout but we can't serve our speedrunning community as well as we could with the suggested feature.

One issue is that the NES cart version of the game has slightly more slowdown than the Famicom (JP) cart version, but our community has a predisposition to running on the NES version. So we set the software version as a subcategory with the most popular one as the default because we didn't want to force everyone to buy Famicom versions just to compete.

Another issue is that it became more popular to run the game without using death warps. For example, we have Any% and Any% No up+A. We didn't want to invalidate deathless runs by merging the categories, nor ignore the fastest completion category. The game also has two quests that are run individually.

Zelda1 basically has six speedrun categories: Any%, 100%, Low%, Swordless, ACE (2nd quest, FDS only) and Extreme rules (which is semi-pacifist, swordless, low%, 100% map completion). For five of those basic categories we have two quests: First Quest and Second Quest. Then we have three deathless versions of categories on top of that. Altogether, we have 14 categories and each category still has 3 subcategories for software version.

What I'd like to be doing is bringing that down to 6 categories. 5 of those categories would have a "Quest" subcategory, a software version category, and a single subcategory filter for deathless that could be turned on of off.

I know that someone will give the opinion that using the drop-down menu to sort filters is good enough. I agree that for certain defaults like Showing Obsoleted runs it is great, and for sorting to view specific Hardware platforms as well. However, the issue we're trying to solve has to do with evenly conveying what the community deems important in terms of gameplay and guiding new viewers of the board in a way that is not off-putting or bloated looking while also helping the veteran users sort through runs quickly.

First and foremost, the reason for extra categories is to expand the community's enjoyment for speedrunning TLOZ with new types of challenges. I encourage you to participate in the community by joining the Discord, and following the game and its players on Twitch, and also to invite others to join you in this activity.

**Discord: https://discord.gg/n3SQKFs ** **Twitch: https://www.twitch.tv/directory/game/The%20Legend%20of%20Zelda **

GAME PLATFORMS The allowed official releases are listed in the left side panel. To date, all the official releases are allowed.

Play the NA English version if you can† The Japanese cart is the fastest version, but almost entirely due to text length which adds up to as little as 12 seconds in some full game categories. Otherwise the gameplay is nearly identical. Nevertheless, it is the fastest version. However, most of the leaderboard's users are using NTSC-U hardware, not NTSC-J.

There are a number of ways to play another region's version. Flash carts, pin adapters, imported game and console, etc, but those are more prone to failure than using native hardware. We don't want to negatively impact our runners by requiring them to spend more money and take additional risks for the sake of text differences.

Yet, fair competition is essential, and we'd also be as inclusive as possible. So, a little compromise required to make that work. Additionally, moderators don't want to re-time a lot of runs to keep it fair, so please use the English version if you can.

If a player is in the NTSC-J market, they may submit runs on Japanese language versions. Submissions in Japanese text may have their times adjusted based solely on the time difference between English and Japanese text.† So, for the sake of the moderators, please use the English NA version if it doesn't negatively impact your attempts.

†Japanese is used for Co-Op. Since it is emulation-based everyone has equal access to the fastest version.

EMULATION Unofficial NES emulation is allowed. No emulation of Gamecube, GBA, Wii, etc. Your NES emulator should be accurate. Here is a list of reasonably accurate emulators: Mesen, Bizhawk (Neshawk), Nintendulator, puNes, FCEUX, Nestopia. Get the latest versions. Don't use overclocking features, don't use lag helpers (e.g. RunAhead), don't remove sprite flicker by allowing more than 8 sprites per scanline. Don't use any features that don't exist on the original game

CATEGORY DESIGN / GAME OVER WARPING Speedrunning is measuring how fast you can get from the beginning to the end of a game. The whole idea of this board is still to do that, but add an unusual restriction or requirement that provides an interesting speed challenge. Adding "No Up+A or Deaths" restriction to beating the game has already been done. We'll be focusing on other ideas here.

Between attempts, you should always reset or power cycle the console. Failing to do so will change enemy drops, spawn positions, etc., and your run will be rejected because your game environment was not even with other players in the field. For Online Co-op, you should be disconnecting from your partner between runs so that item sync info is reset.

Take care to get a proper reset when using virtual platforms (e.g. Switch) or emulation-in-a-box (e.g. NES Classic Mini). If enemy formations on the same screen are different from run to run, that's a sign that their formation value is not resetting between attempts as it should.

VIDEO SUBMISSION GUIDELINES Complete video of the gameplay is required, including the last reset or power on. Please submit a Permanent Video -- Twitch Past Broadcasts are not permanent.

We have created subcategories for this game's leaderboards to differentiate between certain program versions of the game. They are labeled as "FDS", "NES" and "FC" (Family Computer or Famicom), analogous to the system on which the versions were originally released. Note that this is different than the hardware or emulation software on which the run was performed. For example, one could run the FDS version on NES or Famicom using a flash cart but the appropriate subcategory is still FDS. All times will be sorted into their appropriate subcategory.

FDS will include all versions based on the Famicom Disk System ROM, notable for Japanese language and thinner font. The most relevant re-release version is for Wii VC which has the fastest loading times. ACE runs work only on this version. when viewing the ACE category, click the FDS subcategory to view the runs.

NES will include all versions based on the English language NTSC release, including PRG0 and PRG1 NES versions. This is the most run version because it is the most ubiquitous among NA speedrunners. As such, it is the default version in the listings.

FC will include all versions based on the Japanese cartridge-based release from 1992 on Famicom. This version is noted for having Japanese language but maintaining the thicker font face for numbers and Roman alphabet. Where applicable, this is the fastest version. For reference purposes, exact text time differences are tabled: https://goo.gl/t89Txm

I intend to improve this list to detail where all versions belong, barring discovery of any further changes. For now there are other resources on the subject including: http://redcandle.us/The_Legend_of_Zelda/Version_Differences https://tcrf.net/The_Legend_of_Zelda/Console_Differences www.google.com _

Background:

While it's long been known that the original Famicom Disk System release has longer load times entering dungeons and doesn't have as much general lag due to FDS hardware differences, the NES and Famicom versions were thought to be the same in all but language text differences and the reverted Pol's Voice vulnerability to arrows (irrelevant to most speedruns). Thanks to some disassembly done separately by Fiskbit and Zzewt, more knowledge has come to light about the differences between the NES release and the later Famicom cart release. The first difference relevant to speedrunning was a very small bug fix to shopkeepers, who prior to the Famicom re-release would hold on to timer values generated by enemies on the previous screen which could cause the shopkeeper to spawn up to 4 seconds late, though just under 2 seconds was normal in speedruns. Subsequently, strategies were developed to reduce the time loss from this bug in the NES versions, but the Famicom version is simply faster and easier.

Fiskbit's disassembly has been a tremendous source of technical information, providing us with the cause of many unintended behaviors and general knowledge about certain routines that are particularly burdensome on the CPU, such as HUD updates and pushing on certain objects like Armos (and also why the routine that should prevent Armos duplication fails). He also discovered that the Famicom version has engine improvements to fix minor graphical glitches that happen when entering caves and when changing rooms during an "adjacent boss roar." In the case of cave and dungeon loads, the fix adds one frame to load times.

In the process of discovering this info, Fiskbit hypothesized the cause of graphical glitches long present with my EverDrive running certain MMC1 games were related to NMI handler which is the subject of an engine change from NES to Famicom ROMs. This was evidenced by the Famicom version not presenting the same graphical glitch as the NES versions on my EverDrive. While testing that, I noticed that under conditions that in my near 30 years of playing this game would be likely to cause lag, that in the Famicom version the weapon sprites in the HUD would flicker.

Given what Fiskbit told us about burdensome HUD updates and engine improvements, I began to suspect that the engine changes may be reducing the gameplay lag present in screens with a high number of sprites. Subsequent speedruns on the Famicom version resulted in some unexpectedly fast split times where text differences were not involved (gold split from Silver Arrow to Gannon by 2 seconds). Obviously, that alone is wholly unscientific.

So I resolved to put this theory to the test in FCEUX running side-by-side the NES and Famicom versions in a room known for heavy lag, the 5 Blue Darknuts and 4 turrets room in Level-8, dubbed the Blue Lagoon by LackAttack. Over approximately 60,000 frames mostly spent holding Up+Left while running an invincibility cheat, the NES produced 1890 frames of lag to the Famicom's 864. This test was only meant to be a precursor to an RNG perfect test that would spawn the room with exactly the same RNG for posterity. However, this test alone was enough to convince the lead moderator that there is a significant difference between the versions that we could never accurately calculate.

While running the fastest and best version of the game certainly has its appeal, the general feeling in the community is that an arms race for the fastest version is not fun and/or that most people would prefer to play the version they grew up with (you know, if they grew up in an NTSC region). This change will also provide the opportunity and space to list FDS videos of non-ACE runs and perhaps even put some Japanese videos on the board.

I'm wondering if we're going to adjust times accordingly for Japanese (cart) version submissions, noting in the rules that adjustments will be made for text differences.

Offering to chart the differences for every cave's text if that data isn't already available somewhere, and handle those submissions as a mod if no one else wants to.

edit: This proposal may seem like it's taking the subject too seriously, but my interest is in keeping speedrunning this game simple and inclusive for newer players. By informing them that it doesn't matter on leaderboards which NTSC version they play because text times will be adjusted, there will be no need for newer players to have a hardware arms race.

2nd edit (May 9 2017): Famicom version probably has significantly less lag. We made subcategories. See new thread.