GB

From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
(Added extension "gb" to the format info box, as mentioned in the text)
m (Edited the dead Pan Docs link to the new Pan Docs host.)
 
Line 15: Line 15:
 
=== Resources ===
 
=== Resources ===
  
[http://nocash.emubase.de/pandocs.htm#thecartridgeheader Pan Docs section about the ROM header]
+
[https://gbdev.io/pandocs/#the-cartridge-header Pan Docs section about the ROM header]
  
 
== SAV ==
 
== SAV ==

Latest revision as of 03:36, 12 July 2020

File Format
Name GB
Ontology
Extension(s) .gb, .sav

Contents

[edit] GB

[edit] Description

A Nintendo Game Boy cartridge contains a ROM chip, for the most times a memory bank controller (MBC) and optionally a battery backed SRAM chip which may contain save game data. Files are typically using the GB file extension, or occasionally GBC if it's a Game Boy Color compatible game or program.

The file contains a header in the area $0100-$014F. This header contains information about the the program and the cartridge, such as title, ROM size, RAM size, type of MBC, which hardware it supports and checksums.

[edit] Resources

Pan Docs section about the ROM header

[edit] SAV

A file containing the information from the SRAM of a Game Boy cartridge is typically given the file extension SAV. The standard sizes for the cartridge SRAM are 512 x 4 bits (for MBC2, see below for details), 2 KiB, 8 KiB, 32 KiB and 128 KiB. The MBC3 chip offers an RTC (real time clock) using a 32768 Hz crystal oscillator. See below for conventions on how to store this data in a sav file.

[edit] MBC2 battery save format

MBC2 ram consists of 256 bytes which are accessible as the low 4 bits of a 512 bytes address range, $a000-$a1ff. The upper 4 bits always read high ($f0).

BGB saves this as a 512 bytes file, which directly maps to this address area. the upper 4 bits in the file are undefined. other emulators may save 256 bytes, packing the bits. I chose to not do this, because this allows for ambiguity between emulators: which bits go in the low bits/high bits? a 512 bytes file can only be interpreted in one way. I also choose to save in this 512 byte format for compatibility with generic SRAM emulation (not emulating MBC2 correctly)

I've seen sav files circulating that were saved by an old BGB, possibly version 1.02 (the files are from 2005), here: final fantasy legend save files. They are 8192 bytes in size, because the BGB from that time did not accurately implement MBC2 ram. They work in current BGB because it ignores save data past the size it expects.

(Specification described by beware, author of BGB. Originally published here and reproduced with permission.)

[edit] MBC3 RTC save format

The RTC data is appended after the sav file, 44 or 48 bytes. You can detect its presence by the save data being 44 or 48 bytes bigger than the cart's ram size, or 44 or 48 bytes bigger than a multiple of 8192.

Old VBA (from 2005) saves the 44 bytes version, and can load both the 44 and 48 bytes version.

VBA-M saves the 48 bytes version, and can *only* load the 48 bytes version.

One should load both types, and always save the 48 bytes version.

The data consists entirely of little endian (Intel order) DWORDs. as the registers are bytes, it's in the first byte of the field, the other bytes should always be 0.

Time is the internal "hidden" version. Latched time is what you're reading from the registers.

The unix timestamp is UTC seconds since 1970-01-01 00:00, a very common standard on internet. Again, the lowest byte goes first.

offset  size    desc
0       4       time seconds
4       4       time minutes
8       4       time hours
12      4       time days
16      4       time days high
20      4       latched time seconds
24      4       latched time minutes
28      4       latched time hours
32      4       latched time days
36      4       latched time days high
40      4       unix timestamp when saving
44      4       0   (probably the high dword of 64 bits time), absent in the 44 bytes version 

(Specification described by beware, author of BGB. Originally published here and reproduced with permission.)

[edit] Little Sound Dj sav format

The Game Boy music creation software Little Sound Dj (LSDj) is using SRAM to store song data. It can use cartridges with between 32 KiB and 128 KiB of SRAM. The lower 32 KiB will always hold the currently active song. If more than 32 KiB of SRAM is present, LSDj can optionally store up to 32 compressed song files in a simple file system in the upper portion of the memory.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox