Detailed contents of a BRAM file

For reference, here is a breakdown of what makes up a BRAM file. You can view them in a hex editor and make adjustments as you see fit, or use this to fix any unforseen issues with the manager.

BRAM Bank Header (16 bytes)

• Header tag (4 bytes)
  • This will always be "HUBM", I believe. Leave it alone.
• Pointer to first byte after header (2 bytes)
  • This seems to always be 00 88. Leave it alone.
• Pointer to next free byte of memory (2 bytes)
  • Tells the PCE where to write the next save file. This has to point to two bytes of zeroes, or else you may experience errors.
  • An easy way to understand this is to swap the two bytes around and subtract 0x8000 (as it is being offset when loaded into the PCE's memory). For example, "23 81" becomes "0x8123", subtract 0x8000 to make 0x0123, signifying that byte 0x0123 is the start of the next slot.
  • If byte number 123 (291st byte in decimal) is the next slot, you will want these two bytes to read "23 81". If you have errors loading the memory, this being wrong is most likely why.
• Zeroes (8 bytes)
  • Blank space, leave it alone.

BRAM Entry Header (16 bytes)

• Length of entry in bytes (2 bytes)
  • This includes the 16 bytes of the header. You can use this to find where the start of the next slot will be.
  • For the last slot, it will also let you know when the next free byte of memory is if you need to edit the header.
• Checksum (2 bytes)
  • This is a negation of the sum of every byte in the entry, excluding the first four (starting at byte 1 of ID).
  • Typically a negative signed Int16 (NOT UInt16). This + sum of bytes = 0.
  • Example, if sum is 1383 (0x6705), checksum will be -1383 (0x99FA). Initial sum can be a negative Int16, in which case the checksum will be a positive Int16.
• ID (2 bytes)
  • Is usually 00 00 but sometimes it isn't.
• File name (10 bytes)
  • The name of the save file. Editing this will make the save unreadable by the game, but it helps identify the data.

BRAM Entry Data

• This is the save data itself for as long as the length in the header said it would be (minus 16 bytes as it includes the header). Could be fun to mess around with if you're into that. Some games will use one BRAM entry for multiple save slots.

Afterwards, the very next byte will either be the start of the next entry (another entry header followed by the data) or "00 00" to indicate the end. This first byte is the start of the next available slot. Some BRAM entries may have "00 00" at the end of its data, so use the length value in the header to make sure you have the correct "00 00".

This program will of course manage all of this for you, but I'm putting this information out there for anyone who's curious.