Filesystem - Revision history

Jrra: Add newly-released NTSC Gateway version (fix syntax oopsie)

2023-04-26T05:41:47Z

Add newly-released NTSC Gateway version (fix syntax oopsie)

Jrra: Add newly-released NTSC Gateway version

2023-04-26T05:19:19Z

Add newly-released NTSC Gateway version

Jrra: Add version NTSC 0.9 to dmadata table, despite the Address3 template not yet supporting it

2023-03-01T08:47:42Z

Add version NTSC 0.9 to dmadata table, despite the Address3 template not yet supporting it

Jrra: Add more versions to dmadata table

2023-03-01T01:01:31Z

Add more versions to dmadata table

CloudMax: File List redirects back to same page, link is no longer necessary

2019-01-14T08:39:28Z

File List redirects back to same page, link is no longer necessary

Mzxrules: /* Compression Formats */

2018-11-26T06:43:53Z

‎Compression Formats

Mzxrules: rewrite to add in iQue file compression information

2018-04-30T07:28:35Z

rewrite to add in iQue file compression information

Mzxrules: added iQue info

2018-04-27T22:31:56Z

added iQue info

Mzxrules: Added dmadata addresses

2018-03-07T09:02:25Z

Added dmadata addresses

Mzxrules at 14:27, 5 December 2017

2017-12-05T14:27:21Z

@@ Line 12: / Line 12: @@
 |ver9=PAL 1.1|ref9=manual|rom-start9=7950
 |ver10=NTSC 0.9|ref10=manual|rom-start10=7430
-|ver11=NTSC Gateway|ref10=manual|rom-start10=7a40
+|ver11=NTSC Gateway|ref11=manual|rom-start11=7a40
 }}

@@ Line 12: / Line 12: @@
 |ver9=PAL 1.1|ref9=manual|rom-start9=7950
 |ver10=NTSC 0.9|ref10=manual|rom-start10=7430
 }}

@@ Line 11: / Line 11: @@
 |ver8=PAL 1.0|ref8=manual|rom-start8=7950
 |ver9=PAL 1.1|ref9=manual|rom-start9=7950
 }}

@@ Line 8: / Line 8: @@
 |ver5=chi ique|ref5=manual|rom-start5=B7A0|rom-end5=116F0|ram-start5=13040
 |ver6=tai ique|ref6=manual|rom-start6=B240|rom-end6=11190|ram-start6=12AF0
 }}

@@ Line 13: / Line 13: @@
 {{clear}}
 == dmadata Format ==
 The first entry of the file table is always the "[[makerom]]" file, located at 0x00000000 to either 0x00001060 for most versions, or 0x00001050 for the iQue.

@@ Line 57: / Line 57: @@
 <syntaxhighlight lang="python">
 def decode(data):
      decomp = zlib.decompressobj(-zlib.MAX_WBITS)
      output = bytearray()

@@ Line 10: / Line 10: @@
 }}
-Ocarina of Time, Majora's Mask, and all of their seperate versions & ports use an identical filesystem. The filesystem helps the game differentiate between compressed and decompressed data, and keep the files in order. It also allows for quick editing should something be misplaced. The filesystem (rather the file offset table part) begins right after the ROM creator and build date. If you would like to see for yourself, you can find the filesystem at the following offsets:
+Ocarina of Time, Majora's Mask, and all of their separate versions & ports use an identical filesystem. It's primary purpose is to provide an easy mechanism to locate files when the rom is compressed. The '''dmadata''' file consists of a table of records for every file in the game (including itself).
+{{clear}}
-{|class="wikitable"
+== dmadata Format ==
 {{For|a listing of files within a specific build|File List}}
-The file offset table begins exactly 0x30 bytes from the creator/build date. The first entry of the file table is always  the location 0x00000000 - 0x00001060, which is referred to as "[[makerom]]" in the filename table. This is not related to this article, but that file it the header for the N64 ROM.
+The first entry of the file table is always the "[[makerom]]" file, located at 0x00000000 to either 0x00001060 for most versions, or 0x00001050 for the iQue.
-One entry for a file is 16 bytes (or 0x10 bytes; one line in a hex editor). You can split this up into 2 parts to find out the two offset pairs, and then you can split those two pairs in half to find the start/end offset for said pair. Here is a tiny diagram:
+One entry for a file is 0x10 bytes, and of the following form:
 {|class="wikitable"
@@ Line 34: / Line 27: @@
 |}
-The virtual (rom) address assigns a file a virtual location, and sets the file's size. This address is used to identify and fetch a file within the rom, regardless of whether or not the file is compressed. In a fully decompressed rom, a file's virtual address will be the same as it's physical address.  The physical (rom) address points to where the file is actually stored in rom. A physical address either points to an uncompressed file, a file compressed with the [[Yaz]] compression algorithm, or no file at all (Majora's Mask).
+The virtual rom address assigns a file a virtual location, and sets the file's size. This virtual location represents the location at which the file will exist if all of the files in the rom were decompressed, and thus acts as an identifier for a file or a portion of it's data. In a fully decompressed rom, a file's virtual address will be the same as it's physical address.  The physical rom address points to where the file is actually stored in rom. A physical address either points to an uncompressed file, a compressed file, or no file at all (Majora's Mask).
 * If a file is compressed, the start and end physical addresses will be set to the start/end of the compressed file in the rom.
@@ Line 54: / Line 47: @@
 |}
-File 00A65000 is decompressed, as it's physical end address pointer is set to 00000000. Since the size of the virtual file is the same as the one mapped in ROM, the last pointer can be set to 00000000 without losing information. In short: the game calculates the size of the block via the virtual address (when dealing with decompressed data).  However, the physical end address address for files 00A87000 and 00B8AD30 is non-zero, meaning that these files are compressed, and that their physical start addresses points to a Yaz block in the ROM, which is then decompressed and mapped to the location in the first offset pair.
+File 00A65000 is decompressed, as it's physical end address pointer is set to 00000000. Since the size of the virtual file is the same as the one mapped in ROM, the last pointer can be set to 00000000 without losing information. Finally, note that the virtual start address ''does not'' match the physical start address. This is due to the existence of compressed files earlier on in the rom.
-Furthermore, note that the physical start address is not the same as the virtual start in either case.
+<syntaxhighlight lang="python">
 ==Filename Table==

@@ Line 6: / Line 6: @@
 |ver3=PAL MQ|ref3=manual|rom-start3=7170|ram-start3=8000AF90
 |ver4=NTSC 1.1|ref4=manual|rom-start4=7430|ram-start4=8000B140
 }}

@@ Line 1: / Line 1: @@
 {{Article link|Filesystem}}
 {{See also|Mod:Filesystem}}
 Ocarina of Time, Majora's Mask, and all of their seperate versions & ports use an identical filesystem. The filesystem helps the game differentiate between compressed and decompressed data, and keep the files in order. It also allows for quick editing should something be misplaced. The filesystem (rather the file offset table part) begins right after the ROM creator and build date. If you would like to see for yourself, you can find the filesystem at the following offsets:

@@ Line 51: / Line 51: @@
 ==Filename Table==
 Since the Debug ROM is meant for debugging the game, the developers were nice enough to leave all of the filenames for OoT's resources intact. They can be found in the main code block or at offset 0xBE80. The filenames are separated by 1-4 null (0x00) bytes (for four-byte alignment), and they match up perfectly with the data referenced by the file offset table. The Debug ROM is the only Zelda 64 game to have a complete file listing. Majora's Mask has one too (following a similar format), but it only lists the names of the scene files, and some of the scenes it refers to are removed.
 [[Category:Documentation]]