GB
File Formats > Electronic File Formats > ROM and memory images > GB
Contents |
GB
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.
Resources
Pan Docs section about the ROM header
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.
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.)
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.)
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.
