Filesystem

From CloudModding MM Wiki
Jump to: navigation, search
See also: Mod:Filesystem
dmadata
VersionVRomVRam
Debug00012F70?80016DA0?
J 1.00001C110?800A14B0?
J 1.10001C050?800A13F0?
U 1.00001A500?8009F8B0?
PAL 1.00001A650?8009FA00?
PAL 1.10001A8D0?8009FC80?
JP GC0001AE90?800A0270?
USA GC0001AE9000020E80800A0270?
PAL GC0001AE90?800A0270?

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).

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.

One entry for a file is 0x10 bytes, and of the following form:

Virtual Address (VRom) Physical Address (Rom)
Start End Start End
00000000 00000000 00000000 00000000

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.
  • If a file is not compressed, the start physical address will point to rom, but the end address will be 0.
  • If a file does not exist, both start and end physical addresses will be FFFFFFFF.

Consider these examples:

<= COMPRESSED DATA =>

Offset 0x0001C1C0 in the debug ROM
 Virtual Mapping     Physical Mapping
00A3A000 00A3EB80   009BA6B0 009BBA50
00A3F000 00A42300   009BBA50 009BD150
00A43000 00A4A780   009BD150 009C0310

<= DECOMPRESSED DATA =>

Offset 0x0001C1F0 in MM J
 Virtual Mapping     Physical Mapping
00A4B000 00A4C310   009C0310 00000000
00A4C310 00A55660   009C1620 00000000
00A55660 00A68270   009CA970 00000000

As you can see in the decompressed data example, these three files are decompressed and mapped to a certain location, with their last pointer being set to 00000000. Since the file size of the file in the ROM is identical to the mapped one, the last pointer can be set to 00000000 without losing information. In short: the game calculates the size of the block via the virtual mapping (when dealing with decompressed data). In the compressed data example, however, the physical mapping points to a Yaz0 block in the ROM, which is then decompressed and mapped to the location in the first offset pair.

Filename Table

Majora's Mask Debug Rom has a filename table similar to Ocarina of Time's Debug Rom, but it only lists the names of the scene files, and some of the scenes it refers to are removed. In order to build a more complete filename list, Majora's Mask 3d was used to identify files.