Hi all, sorry if this is not the best place to post this (if it's not please advise where better), im just hoping someone with some know-how here can help.
I have a save game issue I've spent a few hours with Claude trying to understand to restore the save. This is the document it has compiled to help explain the situation and was hoping someone here could help shed some light on why my save appears to be visible in the code, but the emulator is loading a fresh game with only 6 minutes progress and a level 6 starter, instead of my game with a level 31 starter (trained up, full party) and hours of progress including 3 badges...
- - - begin summary;
Pokemon LeafGreen Save State Recovery — Investigation Summary
Setup
- Hardware: TrimUI Brick "Hammer" (metal chassis variant)
- OS: NextUI 20251017-0 (commit cdbe135)
- Stock OS: TrimUI 1.0.6
- Emulator: gpSP v1.1.0-74db5e5 (libretro core via minarch)
- ROM: Pokemon - LeafGreen Version (USA, Europe) (Rev 1).zip — game code BPGE
- Save format setting: Generic (filename: Game.sav)
- Save state format setting: MinUI default (filename: Game.st0 through .st9)
Trainer / Game details (per user)
- Trainer name is correct
- Starter Pokemon: Bulbasaur, nicknamed "Bulba"
- Bulba's level: 31
- Gym badges earned: 3 (Boulder, Cascade, Thunder/Rainbow)
- Several party Pokemon plus PC box Pokemon
- Played primarily via in-game save (Start → Save), not save states
Timeline
- ~Sept 2025: User playing on original plastic-chassis TrimUI Brick
- 23 Sept 2025: Backup taken (no Saves folder included)
- ~17 Oct 2025: Migrated to Hammer, reinstalled NextUI 20251017
- Late Oct 2025: Last play session before issue noticed
- 1 Dec 2025: Backup taken (post-corruption — saves already broken)
- 3 May 2026: Troubleshooting session
File locations on SD card
/Saves/GBA/
Pokemon - LeafGreen Version (USA, Europe) (Rev 1).sav (128KB, all 0xFF)
Pokemon - LeafGreen Version (USA, Europe) (Rev 1).zip.sav (128KB, suspicious binary)
Pokemon - LeafGreen Version (USA, Europe) (Rev 1).srm (RZIP-compressed empty)
/.userdata/shared/GBA-gpsp/
Pokemon - LeafGreen Version (USA, Europe) (Rev 1).zip.st0 (416KB)
Pokemon - LeafGreen Version (USA, Europe) (Rev 1).zip.st1 (416KB)
Pokemon - LeafGreen Version (USA, Europe) (Rev 1).zip.st9 (416KB, overwritten today)
/.userdata/shared/MGBA-mgba/
Pokemon - LeafGreen Version (USA, Europe) (Rev 1).zip.st9 (528KB)
/.userdata/tg5040/GBA-gpsp/
minarch-brick.cfg
Key findings during investigation
Battery save files (.sav)
The .sav file gpSP reads from (per emulator log path) is Saves/GBA/Pokemon...Rev 1).sav — all 0xFF bytes (uninitialised flash). MD5 41d2e2c0c0edfccf76fa1c3e38bc1cf2.
The .zip.sav file has 127,185 non-FF bytes but contains ARM64 machine code patterns (e.g. byte sequences like e21b00f9, fd835ff8 which are valid ARM64 LDR/STR instructions). MD5 e9fc43b883eb47e88cafcad78c5076db. No Pokemon Gen3 magic bytes (0x08012025) found anywhere, no valid sector footers (sector IDs should be 0-13, observed values were 0x9bff, 0xcfff, etc. — invalid). User had renamed files extensively during prior troubleshooting which likely caused this.
Save states (gpSP format)
gpSP save states begin with header info-magic and contain labelled sections including iwram (32KB) and ewram (256KB). Section format: name\0 + size (uint32 LE) + data.
st1 file (MD5 1aad45c2a9540ef94be865bbba1946e3):
The Pokemon Gen3 character "Bulba" pattern BC E9 E0 D6 D5 was found at three EWRAM offsets:
- EWRAM+0x233f9 (Pokemon struct at 0x233f1)
- EWRAM+0x23c15 (Pokemon struct at 0x23c0d) — this is the disputed level 31 finding
- EWRAM+0x2428d (Pokemon struct at 0x24285) — active party slot 1
At EWRAM+0x24285 (active party slot via gPlayerParty at FRLG runtime address 0x02024284):
- Nickname: "Bulba"
- OT name matches and is correct
- OT ID: 26052 (TID), 195 (SID)
- PID: 0xd50d9f49
- Level: 6
- HP: 21/21
- Stats: ATK=11 DEF=12 SPE=11 SPA=12 SPD=14
At EWRAM+0x23c0d (NOT in gPlayerParty range):
- Bytes 8-12 decode as "Bulba" in Gen 3 char encoding
- OT name bytes decode as the correct trainer name
- Reading byte 84 (the level field in a 100-byte party struct) = 31
- Stats fields appeared as ATK=17925 DEF=18 SPE=0 SPA=49853 SPD=52411
- HP = 0/0
- When attempting to decrypt the encrypted block (bytes 32-79) using PID XOR OT_ID per Gen 3 encryption, decoded species came out as 9301 (no valid species — max is 411), EXP came out as 50,537,567 (impossibly high — max ~1.6M)
This is what's in dispute. The user (correctly identifying their own gameplay history) confirms Bulba was level 31, trainer name is correct, 3 badges earned. The data at EWRAM+0x23c0d shows Bulba and correct trainer name characters, level field reading 31, but the decrypted Pokemon substructure produces invalid values.
What the disputed finding could mean
Three possibilities I haven't been able to definitively resolve:
- Stale memory / save buffer: Pokemon FRLG uses a save buffer in EWRAM during Save operations. The data at 0x23c0d may be a partial copy or save-in-progress buffer from the game's last save operation, containing real Pokemon data in an encoding we're not reading correctly.
- PC box memory: PC box Pokemon use 80-byte BoxPokemon structs (no battle stats). The 100-byte read at 0x23c0d misaligns the encrypted block decryption, producing junk. If the underlying data is a valid BoxPokemon, reading it correctly would reveal the real species and EXP.
- The data IS the user's level 31 Bulba — captured during a save operation that wrote partial state to a transient memory region. The user's testimony of Bulba being level 31 with a correct trainer name is corroborated by the bytes present.
The other file (st9 in MGBA-mgba)
mGBA save state, 528KB, header includes ASCII "POKEMON LEAFBPGE". No Bulba pattern found in this file — appears to be a fresh game state captured today during testing.
What was NOT tried
- Loading the st1 file in standalone mGBA on the Mac and converting it
- Using a Pokemon save editor (PKHeX, PokeFinder) to inspect the data with proper game-aware decryption
- Hex-editing st1 to manually patch the level 6 Bulba's level/badges/playtime to match what user remembers
- Examining EWRAM+0x23c0d as a BoxPokemon (80-byte) struct rather than party Pokemon (100-byte) struct with proper decryption
- Comparing all three Bulba locations side-by-side with proper Gen 3 substructure decryption
- Checking FRLG-specific event flags region for badge bits
Current state
Live SD card has the st1 file containing what appears on the device as a 6-minute save with Bulba at level 6 and 0 badges. User maintains real progress was Bulba at level 31 with 3 badges. Three Bulba-named character sequences exist in the file's EWRAM dump at three different memory offsets, but only one decodes cleanly with the assumed party Pokemon offset.