Skip to content
LuigiBlood edited this page Aug 9, 2019 · 4 revisions

The Legend of Zelda - Ocarina of Time is not a rebooter game unlike most games with 64DD support. Instead it implements 64DD hooks into the game's code for specific uses.

Technical Details

  • The game checks for the following 64DD units:
    • Japanese Retail Unit (Japan)
    • American Retail Unit (USA)
    • Development Unit (All)
  • The game checks for the following Game Codes, regardless of region:
    • EZLJ
    • EZLE
  • The European PAL version of the game does contain 64DD code, but it has been completely disabled.
    • If it was enabled, the game would check for Game Code EZLP.
    • There is no European 64DD initialization function, only the Japanese & American ones. It is unknown what initialization the game would have used.
  • The game performs the following when an Expansion Disk is detected:
    • "Disk" is mentioned on the Title Screen.
    • You cannot play or create a regular save file, only Disk save files.
    • When you start up a Disk save file...
      • The way the game handles disk loading is different from other games, as it uses a byte address, and calculates the address starting from LBA 1.
      • Load 0x118 bytes from disk address 0x1060.
        The format is the following:
        SSSSSSSS EEEEEEEE DDDDDDDD FFFFFFFF RRRRRRRR
        
        SSSSSSSS = Disk Source Address Start
        EEEEEEEE = Disk Source Address End
        DDDDDDDD = RAM Destination Address Start
        FFFFFFFF = RAM Destination Address End
        RRRRRRRR = RAM Pointer to Disk Hook Function Callbacks
        
      • The game loads from Disk Source Address Start to End, to the RAM Destination.
      • Execute the initial Disk Hook Callback (ID 0), with access to required basic functions passed as argument.
      • From there, depending on the implementation on the disk side, it can replace specific files.
        It can replace the scene list, scenes, rooms, dungeon minimaps, entrance cutscenes, text.
        • There is a way to replace almost every file, but because of differences between revisions of the game, it is not reliable from a development standpoint.
        • By the exception of scene disk loading, handled by the game itself, everything else has to be reimplemented by the loaded code from disk.