Hi, Just for fun I though I would have a prod about on the sonic 3 save game ram. I had never peeked into a megadrive cart before, so this is all new to me. My plan was as follows: Use an emulator (I'm using dgen/sdl) to take periodic save game ram (thats the battery backed SRAM) dumps and bindiff them using radare2's radiff2. And this does appear to work. I have identified what I believe to be the character (as in sonic/tails/both) field in save game slot 1. However, changing this field willy-nilly does not work, I think there is a CRC/checksum which has to be calculated. What I did here was: 1) Start the game as sonic and tails, dump the sram to file. 2) Start the game as sonic only, dump the sram. 3) Start the game as tails only, dump the sram. To dump the ram you have to exit the emulator. When I say "start the game", I mean start the first act of zone 1 from a fresh sram (just remove the sram dump file from ~/.dgen/ram). I did two sram bindiffs: Sonic -> Tails Sonic -> Sonic + tails The table below shows the diff results: 0x0000016c 01 => 02 => 00 0x000001cc 70 => c7 => ed 0x000001ce 4f => fd => 3e 0x000001f8 01 => 02 => 00 0x00000258 70 => c7 => ed 0x0000025a 4f => fd => 3e (The columns are byte offset, value for sonic only, value for tails only, value for both characters) The first thing to note is that everything was written twice at different offsets. Perhaps for backup purposes? Anyway this is nice, because we now know the length of the save game slot 0x0000016c and 0x000001f8 appear to be where the character is selected: 0x00 = Sonic and Tails 0x01 = Sonic 0x02 = Tails But the other bytes? Checksums? If this is a checksum, what algorithm is likely to be used? Does anyone tinker with this stuff here atall?