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.
| 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 :
|
| 0x010D9 | 0x011B1 | game save area, echo of 0x01000-0x010D8. |
| 0x011B2 | 0x011D6 | vector state, see details:
|
| 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).
|
| 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:
| Start address | Length | Description |
|---|---|---|
| 0x00000 | 0x00FFF | Same as Game Boy Camera |
| 0x01000 | 0x011B1 | Game save data (NOT PROTECTED BY CHECKSUM), see details:
|
| 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.