File Formats

!!!OUTDATED!!!

See: Core.Utility.Import and Core.Utility.Export on dev branch for currently implemented file formats

Mole, aswell as other SMW romhacking tools use a bunch of often undocumented file formats, this page will serve to describe in detail all the file formats Mole uses internally, aswell as all the formats it supports to import or export

Table of contents

1. Import-/Export-able formats
   1. ROMs (*.sfc, *.smc)
   2. Graphics (*.bin)
   3. Palettes (*.pal)
   4. Map16 (*.map16)
   5. Levels (*.mwl)
   6. Patches (*.asm)
2. Internal project formats
   1. Compressed projects (*.moleproj)
   2. Hashes (*.sha1)
   3. Stacks (*.stk)
   4. Cached data (*_dat.bin)
      1. Global header
      2. Graphics
      3. Pointer Tables (*_ptr.bin)
   5. Backups

---

Import-/Export-able formats

WIP

Internal project formats

Compressed Projects (*.moleproj)

• Size:

  Variable

• Contents:

  Tarred and compressed Mole project folder

• Description:

  These files are shareable versions of the similarly named *_moleproj folders generated when a ROM is imported into Mole, All the files in the project folder (with a couple exceptions listed bellow) will simply be tarred together into a single file, and compressed with gzip. The custom file extension is purely cosmetic.

  (For more information on the tar format see this, and similarly for more info on the gzip format see this)

  To allow for legal sharing of *.moleproj files:

  When exporting Mole will seemlessly exclude the clean ROM file usually present, and replace the users modified ROM with a *.bps patch instead.

  When importing Mole will ask the user for a clean ROM and seemlessly create the modified copy using the patch.

---

Hashes (*.sha1)

• Size:

  40 bytes

• Contents:

  SHA1 Digest

• Description:

  These files are simply binary representations of SHA1 digests of various other files, these files are used to verify the integrity of the files within a Mole project to assure they are still up to date and haven't been tampered with, if for example the ROM is edited externally, any cached data or pointers files need to be regenerated, an extra backup entry will be written for these external changes, etc...

---

Stacks

WIP

---

Cached data

• Size:

  Variable, atleast 16 bytes

• Contents:

  Variable, data generated by computationally expensive operations that shouldn't need to be repeated if possible

• Description:

  These files hold various kinds of cached data for computationally expensive operations such as graphics decompression, due to the large variety of data these files can contain the file always begins with a global header which contains information on what kind of data follows, immediately followed by the cached data itself, some of these variations need further specification due to their complexity.

• Specs:

  Offset	Name	Size	Description	Optional?	Repeateable?
  0x00	Global Header	16 bytes	Holds information used to assist Mole in importing the cached data Further info bellow	No	No
  0x10	Data	Variable	Holds the actual data Mole will import Further info bellow	No	No

  • Global Header:

    A 16 byte header present accross all types of cached data files. Holds the information necesarry to discern which type of cached data file this is, Aswell as 14 bytes to act as a type specific global header, if these 14 bytes are unused they must be filled with 0s.

    Offset	Name	Size	Description	Optional?	Repeateable?
    0x00	Type	2 bytes	Helps Mole identify what kind of file this is	No	No
    0x02	Info	14 bytes	Other important information about the file that may or may not be needed	Yes, fill 0	No

  Based on the Type byte in the global header, see the explanations bellow for how each type of cached data is encoded. This includes anything that may be found in the Info bytes of the global header, aswell as further documentation on the Data section of the file. Offsets are global to the file, not the section, so compare them acordingly.

  • Type 0x00, Graphics:

    Repeateable headered chunks of compressed graphics data. Each chunk starts with a Format byte, 2 Size bytes, and then the data itself. We know when the next chunk starts because of the Size bytes of the previous one. First chunk starts at offset 0x10, the beggining of the Data section of the file. The Info section of the Global Header is ignored and should be all 0s

    Offset	Name	Size	Description	Optional?	Repeateable?
    0x10	Format	1 byte	Which of the 5 graphics formats available the following Data chunk is encoded in. Expandable up to 16 formats	No	Yes, after a Data chunk
    0x11	Size	2 bytes	Size of the following Data chunk	No	Yes, after a Format byte
    0x13	Data	Variable, based on Size bytes	Decompressed graphics data	No	Yes, after Size bytes

  • Type 0x01, Pointer Table:

    Stores a bunch of 4-byte (unsigned integer) pointers one after another

    Offset	Name	Size	Description	Optional?	Repeateable?
    0x10	Pointer	4 byte	Unsigned Integer representing a pointer	No	Yes, infinitely

---

Backups

WIP