View source for Structure of the Game Boy Camera Save Data

The Game Boy Camera stores photos a battery backed SRAM chip. If power to the SRAM chip is lost, the data stored would be lost. If your camera no longer holds photos after powering off your Game Boy, you'll need to replace the battery.

=== Composition of the RAM ===
The Camera's RAM, unlike a regular file system, uses specific addresses or locations to store specific data. Data which is found at a certain location on one camera can be found at the same location on a different camera as well. The complete size of the camera's RAM is 128KB (Length: 0x20000). Some data are protected by checksums (scores, partitions, player's informations, image data structure), they can be read in clear but not written. Any attempt to modify these protected data activates a "suicide code" that erase all of them in the camera save. The protective checksum is calculated  as follows:  left byte (low address) is a 8-bit sum, right byte (high address) is a 8-bit XOR (discovered the 7 June 2021). Knowing the rule is enough to perform a byte attack on all data of the savestate starting by a legit one. You just have to know for each byte if it is covered by a checksum, and which among four differents. The rule to modify any byte in an area protected by checksum is the following:

- modify the old byte value by a new byte value;

- modify the left byte of its checksum like this: old checksum byte+(new byte value-old byte value);

- modify the rigth byte of its checksum like this : old checksum byte XOR old byte value XOR new byte value;

And that's all ! 

The checksum is calculated from scratch from always the same seed: "Magic" followed by 0x2F, 0x15 (starting checksum when all data are 0x00). Each new data entering a protected area modifies the values of its corresponding checksum according to the rules.

Any extended 0xAA range is a remnant of the initial factory sram tests, never erased since camera release. Other value means that backup battery has been replaced one time in the camera life. By extension, these ranges are never included into any checksums as they are never used by the camera code in writing mode. 
{| class="wikitable"
|+
!Start address
!End address
!Description
|-
|0x00000
|0x00FFF
|Live preview image / Last "seen" image, 128x128 pixels, 256 tiles, size of the sensor. The effective resolution is in fact only 128x123 as indicated in the datasheet of the M64282FP sensor so the last 5 lines of pixels are blank.
The camera's main chip seems to store the Imagedata received from the Camera's sensor directly in the fist 4096 bytes for the GameBoy to access and display directly when in shooting mode. Picture displayed and saved is this 128x128 pixels image without the first and the last row of tiles. Last row of tiles is glitchy.
|-
|0x01000
|0x010D8
|Game save area, Trippy H and image counter, see details below :
:0x01000-0x0102E: animation slots 1-47 (index 0-29. MSB=1 for album B). 
:0x0102F: animation loop flag. 
:0x01030-0x0105E: animation loops (loop start 0x80 + loop time), between (loop time 0x02-0x32), (loop end 0x40 + loop time).
:0x0105F: animation speed.
:0x01060: animation border.
:0x01061: SOUND I - from MSB to LSB-> unknown (2 bits), duty length (2 bits), gate (4 bits).
:0x01062: SOUND I - env. from MSB to LSB-> U/D (1 bit), time (3 bits), gain (4 bits).
:0x01063: SOUND I - mod. from MSB to LSB-> square or sine (1 bit), dep. (7 bits).
:0x01064: SOUND I - mod. from MSB to LSB-> ? (1 bit), freq.  (7 bits).
:0x01065-0x01074: SOUND I - notes (range 0x01-0x25).
:0x01075-0x01078: SOUND I - stereo option for the 16 notes (2 bits per note, default 0x55, center).
:0x01079-0x01088: SOUND II - 32 values for wave enveloppe (16 bytes, 16 levels by group of 4 bits).
:0x01089: SOUND II - from MSB to LSB-> unknown (2 bits), wave pattern (2 bits), env. g. (4 bits).
:0x0108A: SOUND II - mod. from MSB to LSB-> square or sine (1 bit), dep. (7 bits).
:0x0108B: SOUND II - mod. from MSB to LSB-> ? (1 bit), frq. (7 bits).
:0x0108C-0x0109B: SOUND II - notes (range 0x01-0x025).
:0x0109C-0x0109F: SOUND II - stereo option for the 16 notes (2 bits per note, default 0x55, center).
:0x010A0: loop count - from MSB to LSB-> SOUND I (4 bits), SOUND II (4 bits).
:0x010A1: NOISE - env. from MSB to LSB-> U/D (1 bit), unknown (3 bits), gain (4 bits).
:0x010A2: NOISE - from MSB to LSB-> gate (4 bits), loop count (4 bits).
:0x010A3-0x010B2: NOISE - notes (range 0x01-0x025).
:0x010B3-0x010B6: NOISE - stereo option for the 16 notes (2 bits per note, default 0x55, center).
:0x010B7-0x010B8: unknown area (seems unused).
:0x010B9: Tempo.
:0x010BA: 0x01 if any partition is saved, 0x00 either.
:0x010BB-0x010BC: counter for image taken (on 2x2 digits reversed).
:0x010BD-0x010BE: counter for image erased (on 2x2 digits reversed).
:0x010BF-0x010C0: counter for image transfered (on 2x2 digits reversed).
:0x010C1-0x010C2: counter for image printed (on 2x2 digits reversed).
:0x010C3-0x010C4: counter for pictures received by males an females (2x2 digits).
:0x010C5-0x010C6: Score at Space Fever II (on 4x2 digits reversed).
:0x010C9-0x010CA: score at balls (on 2x2 digits reversed).
:0x010CB-0x010CC: score at Run! Run! Run! (on 2x2 digits reversed, 99 minus value on screen).
:0x010CD-0x010CF: unknown data.
:0x010D0: printing intensity (0x00 min, 0x040 typical, 0x7F maximum);  0x010D1: unknown data;
:0x010D2-0x010D6: "Magic" word in ascii.
:0x010D7-0x010D8: checksum (2 bytes, left is a 8-bit sum, rigth is a 8-bit XOR, range of data included 0x01000-0x01D6, starting seed: "Magic" followed by 0x2F, 0x15).
|-
|0x010D9
|0x011B1
|game save area, echo of 0x01000-0x010D8.
|-
|0x011B2
|0x011D6
|vector state, see details:

:0x11B2-0x011CF: image number associated to memory slots (minus one), 0xFF means erased or blank;
:0x11D0-0x011D4: "Magic" word in ascii;
:0x11D5-0x011D6: checksum (2 bytes, left is a 8-bit sum, rigth is a 8-bit XOR, range of data included 0x11B2-0x011D4, starting seed: "Magic" followed by 0x2F, 0x15);
|-
|0x011D7
|0x011FB
|vector state, echo of 0x011B2-0x011D6.
|-
|0x011FC
|0x01FFB
|Game Face, 128x112 image, 224 tiles. This area is not erased when booting with START+SELECT (factory reset).
|-
|0x01FFC
|0x01FFF
|Possible camera tag (0x00, 0x56, 0x56, 0x53 to unlock Corocoro features). This area is not erased when booting with START+SELECT (factory reset).
|-
|0x02000
|0x02FFF
|Memory slot #1, see details :

0x02000-0x02DFF: image data tiles in memory slot 1 (128x112, 224 tiles).

0x02E00-0x02EFF: image thumbnail (32x32, 16 tiles, black borders and 4 white lines on the bottom to not hide the hand). Image exchanged displays a small distinctive badge.

0x02F00-0x02FFF: image tag or metadata (contains informations on the owner of camera and image).

:0x02F00-0x02F5B: User ID, data, comments and some other information from image owner.

::0x02F00-0x02F03: user ID, 4 bytes sequence (equal to 11 + series of two digits among 8 in reading order).
::0x02F04-0x02F0C: username (0x56 = A to 0xC8 = @, same tileset as first character stamps).
::0x02F0D: User gender (0x00 no gender, 0x01 male, 0x02 female) and blood type (japanese only, +0x04 A, +0x08 B, +0x0C O, +0x10 AB).
::0x02F0E-0x02F11: Birthdate (year, 2x2 bytes, day, 2 bytes, month, 2 bytes, each 2 bytes + 11).
::0x02F12-0x02F14: 3 unknown bytes.
::0x02F15-0x02F2F: Contains comments [[Character Mapping|Character mapping of INT and JP ROMS]]
::0x02F30-0x02F32:  0x00.
::0x02F33 : 0x00 if image is original, 0x01 if image is a copy.
::0x02F34-0x02F35:  Probably a checksum from image data. Erasing these bytes do nothing particular, but camera rewrites them automatically. Two identical image copies have the same value.
::0x02F36-0x02F3A: 0x01 if hotspot is activated among 5 possible (0x00 otherwise). 
::0x02F3B-0x02F3F: xpos of the 5 hotspots, range 0x00-0x0E.  
::0x02F40-0x02F44: ypos of the 5 hotspots, range 0x00-0x0C.  
::0x02F45-0x02F49: sound effects and music associated to the 5 hotspots, range 0x00-0x3F, 0xFF for Off.  
::0x02F4A-0x02F4E: visual effects associated to the 5 hotspots, range 0x00-0x06, 0xFF for Off.  
::0x02F4F-0x02F53: jump to image XX, range 0x00-0x1D, 0xFF for Off.
::0x02F54: border number associated to the image.
::0x02F55-0x02F59: "Magic" word in ascii.
::0x02F5A-0x02F5B: checksum (2 bytes, left is a 8-bit sum, rigth is a 8-bit XOR, range of data included 0x02F00-0x02F59, starting seed: "Magic" followed by 0x2F, 0x15).

:0x02F5C-0x02FB7: User ID, data, comments and some other information from image owner, echo.

:0x02FB8-0x02FD0: User ID and data from camera owner (below the first image only, slot 1, just replaced by 0xAA on other slots).

::0x02FB8-0x02FBB: User ID.
::0x02FBC-0x02FC4: Username (0x56 = A to 0xC8 = @, same tileset as first character stamps).
::0x02FC5: User gender (0x00 no gender, 0x01 male, 0x02 female) and blood type (japanese only, +0x04 A, +0x08 B, +0x0C O, +0x10 AB).
::0x02FC6-0x02FC9: Birthdate (year, 2x2 bytes, day, 2 bytes, month, 2 bytes, each 2 bytes + 11).
::0x02FCA-0x02FCE: "Magic" word in ascii.
::0x02FCF-0x02FD0: checksum (2 bytes, left is a 8-bit sum, rigth is a 8-bit XOR, range of data included 0x02FB8-0x02FCE, starting seed: "Magic" followed by 0x2F, 0x15).
::0x02FD1-0x02FE9: User ID data echo (below the first image only, slot 1, just replaced by 0xAA on other slots).

:0x02FEA-0x02FFF: end of memory slot.

::0x02FEA-0x02FEF: 0xAA repeated; 
::0x02FF0-0x02FF1: 0xAA repeated, but not always;  
::0x02FF2-0x02FFF: 0xAA repeated or sensor calibration vector under image slot 3 (0x04FF2-0x04FFF) and image slot 16 (0x11FF2-0x011FFF, echo).  
::0X02FFF: changes with hotspots and events in the camera;
|-
|0x03000
|0x03FFF
|Memory slot #2
|-
|0x04000
|0x04FFF
|Memory slot #3 - sensor calibration at 0x04FF2-0x04FFF
|-
|0x05000
|0x05FFF
|Memory slot #4
|-
|0x06000
|0x06FFF
|Memory slot #5
|-
|0x07000
|0x07FFF
|Memory slot #6
|-
|0x08000
|0x08FFF
|Memory slot #7
|-
|0x09000
|0x09FFF
|Memory slot #8
|-
|0x0A000
|0x0AFFF
|Memory slot #9
|-
|0x0B000
|0x0BFFF
|Memory slot #10
|-
|0x0C000
|0x0CFFF
|Memory slot #11
|-
|0x0D000
|0x0DFFF
|Memory slot #12
|-
|0x0E000
|0x0EFFF
|Memory slot #13
|-
|0x0F000
|0x0FFFF
|Memory slot #14
|-
|0x10000
|0x10FFF
|Memory slot #15
|-
|0x11000
|0x11FFF
|Memory slot #16 - echo of sensor calibration at 0x11FF2-0x11FFF
|-
|0x12000
|0x12FFF
|Memory slot #17
|-
|0x13000
|0x13FFF
|Memory slot #18
|-
|0x14000
|0x14FFF
|Memory slot #19
|-
|0x15000
|0x15FFF
|Memory slot #20
|-
|0x16000
|0x16FFF
|Memory slot #21
|-
|0x17000
|0x17FFF
|Memory slot #22
|-
|0x18000
|0x18FFF
|Memory slot #23
|-
|0x19000
|0x19FFF
|Memory slot #24
|-
|0x1A000
|0x1AFFF
|Memory slot #25
|-
|0x1B000
|0x1BFFF
|Memory slot #26
|-
|0x1C000
|0x1CFFF
|Memory slot #27
|-
|0x1D000
|0x1DFFF
|Memory slot #28
|-
|0x1E000
|0x1EFFF
|Memory slot #29
|-
|0x1F000
|0x1FFFF
|Memory slot #30
|}

=== Composition of an image data block ===
The length of an image data block is always 3584 byte (Length: 0x00E00). It can be split into 224 blocks of 16 bytes each. Which each represent an 8x8 pixel tile in standard Game Boy graphic tile encoding. The 224 blocks represent the actual image data of 16x14 tiles or 128x112 pixels. These data are not protected by any checksum and can be freely modified.

=== Composition of an image metadata block ===
A metadata block always has a length of 512 bytes (0x200). It contains informations about the image owner (ID, birth date, gender, etc.), the comments associated to the image, the border type and some other informations non elucidated. If the metadata is situated into the first memory slot of the camera, it contains also informations about the camera owner. These informations are stored here even if the first memory slot is not in use. Of course, the camera owner and picture owner differs in case of picture exchange. These data are protected by a checksum.

=== Hello Kitty Pocket Camera Differences ===
The save format of the unreleased Hello Kitty variant of the Pocket Camera is mostly the same as the normal camera with some exceptions:

{| class="wikitable"
|+
!Start address
!Length
!Description
|-
|0x00000
|0x00FFF
|Same as Game Boy Camera
|-
|0x01000
|0x011B1
|Game save data (NOT PROTECTED BY CHECKSUM), see details:
::0x01000-0x01001: counter for image taken (on 2x2 digits reversed);
::0x01002-0x01003: counter for image erased (on 2x2 digits reversed);
::0x01004-0x01005: counter for image transfered (on 2x2 digits reversed);
::0x01006-0x01007: counter for image printed (on 2x2 digits reversed);
::0x01008-0x01009: counter for pictures received by males an females (2x2 digits);
::0x0100A-0x0100C: counter for Kitts (on 3x2 digits reversed);
::0x0100D-0x01011: Unknown data;
::0x01012-0x01016: "Magic" word in ascii with NO CHECKSUM after (just 0x00, 0x00, data are not protected;
::0x01017-0x011B1: Filling with 0x00;
|-
|0x011B2
|0x011D6
|Vector state, same as Game Boy Camera, protected with checksum;
|-
|0x011D7
|0x011FB
|Vector state, echo of 0x011B2-0x011D6;
|-
|0x011FC
|0x0187B
|User profile 3 photos animated, 40x56 pixels (5x7 tiles), written consecutively;
|-
|0x0187C
|0x01FFF
|Filling with 0x00;
|-
|0x02000
|0x1FFFF
|Same as Game Boy Camera
|}

The counter for images is followed by a nice flower meter just below. I think that the game save data are not protected just because the game is not finished. Indeed, the "Magic" word exists but without checksum after and the game save data are not echoed contrary to the state vector that may originate from the old Game Boy Camera code the Hello Kitty is based on. Means that SRAM functionality is enough for running and testing the game but not "polished" for antipiracy.