Bug: RAM corruption after checking Hitmonchan and Hitmonlee’s Pokédex entries

[fsegouin]

Review the Compatibility Notes In particular, not all emulators or non-official hardware solutions are supported due to bugs induced from lack of accuracy. Proper bugs should be able to be replicated on official hardware or, to a lesser extent, the latest version of the BGB emulator.

What emulator and/or hardware are you are using? I am playing on a DMG, original hardware, I managed to reproduce this bug on both a custom cartridge and a pi-based cartridge.

Which patch are you using? Pokemon Shin Green

What ROM base are you using? Pokémon Blue USA CRC32 D6DA8A1A

How are you utilizing the patch? I patched using marcrobledo’s rom patcher. I have clocked in 13h in this save file, no cheats have been used, both trainer and Pokemon randomisers have been turned on. I initially lost the save file when this happened to me for the first time and managed to reach Saffron again, then trigger the same glitch again. This time I did not save.

What version of this project are you using? 1.24.5M regular version

What is the problem you encountered? I suspect possible RAM corruption with save file corruption as well. After checking out both Hitmonchan and Hitmonlee’s Pokédex entries multiple times before choosing one of them, all Pokemon sprites become corrupted. All PC boxes show ghost data as well, as if Pokemon were stored but the list contains ghost data, with only the cursor moving up and down through an empty list. Eventually reaching this point if I try to save I get the message “the older save file will be deleted…” which is a sign of save corruption. If I do save, upon restating, it says the save data is corrupted and will be deleted.

Expected behavior I should be able to watch both Pokémon’s Pokédex entries without encountering the glitch.

Is it possible to reproduce the problem?

1. Go to Saffron City and beat the Dojo boss.
2. Press A in front of both Hitmonchan and Hitmonlee’s poke balls to see their Pokédex entries. Do so several times (maybe 4 times for each Pokemon).
3. Open the Pokédex and see any Pokemon entry. Their sprites should now be glitched.
4. Go to the Pokémon center and check out Bill’s PC. All boxes will show as filled with ghost data.
5. Upon saving, the game will act as if the previous file save is from a different trainer / will overwrite. Something that clearly indicates an issue with the data in RAM somehow. Saving will overwrite the save file with garbage and the save file will be lost.

Screenshots/Video I am joining a few screen grabs. Apologies for the poor quality, I am posting this from the beach ha.

SAV file or Save States Unfortunately I am not behind a computer at the moment but will update with my save file prior to the event soon. I can also attach a save state from when the corruption has started.

Additional context I initially thought my custom cartridge went bad and suspected a bad RAM chip. Then I went on doing this on a croco cart, based on a raspberry pi pico, which has never been an issue for me, and managed to reproduce the issue doing the exact same steps, with a backup save file from a few hours earlier.

[jojobear13]

So far, I am unable to replicate this issue. But I do know what is probably happening.

The corruption looks like it's caused by memory bank switching problems. Pokemon front sprites are decompressed in the last bank of save ram as an improvised buffer (which is why vanilla missingno would corrupt your hall of fame). The glitched sprites mean that it's loading garbage data from someplace it's not supposed to be. The save corruption means that it's trying to buffer and process that garbage data in the wrong save ram bank.

Zip up the rom file you're using and post it here when you get a chance. I can compare the file hash and see if there is something wrong with it.

What are the details of the other custom cartridge you are using? I looked up this Croco Cart for one, and I found some interesting information: https://github.com/shilga/rp2040-gameboy-cartridge-firmware?tab=readme-ov-file#known-limitations. Whatever flash carts you are using need to operate to MBC3 standards (or emulate them very well) for pokemon games.

[fsegouin]

Thanks for your reply @jojobear13. I will upload the Rom tomorrow for you to have a look at. Thanks again for looking into this. It’s probably a user error more than anything looking at what you have just said, especially as I encountered this at the exact same spot twice, on different hardware.

One more thing, I have started my save file under a previous version and did not teleport back to Pallet Town as suggested when upgrading. Could this have caused this issue?

I am attaching a photo of my Chinese cart I have used for reference.

[fsegouin]

@jojobear13 Here's the link to my patched rom. I have double checked the CRC32 hash: 9FE3DCE6 which matches what I have when I patch the game from the bps file (I did it twice). https://www.dropbox.com/scl/fi/i82h3skhr0oqvs3jubn2a/Shin_Green_1-24-5.zip?rlkey=e2oy5ez60s65glfronpoxohhp&st=o2iedx0m&dl=0

Shin_Green_1-24-5.zip

[jojobear13]

Thanks. FYI, you can drag and drop zip files directly into github issue comments.

I checked the hash. Everything is okay on that front.

I ran the rom on a test save using the DMG gameboy but could not replicate the issue.

I have no idea what that chinese repro cart pcb is. This whole thing looks odd. The lack of the battery implies that it's using FRAM to save. DMG-A07-01 is a type of PCB used in GBC games, but every one that had that designation number had an MBC5 chip whereas this one implies MBC3. But I cannot know for certain because the topside symbol of the MBC chip has been acid-washed off. Furthermore, it looks like this PCB was originally something else but then had its components manually swapped out like some kind of custom job. Granted, whoever did it knew what they were doing because the workmanship is good. Where did you buy this thing?

Going from an old save should not cause this kind of catastrophic data integrity failure. The more I go through the theory of how to cause this, the more it points away from a software problem and more towards the memory bank controller chip not doing its job properly.

Since this issue is on two different cartridge platforms, process of elimination directs me to your gameboy. I noticed that your DMG has an aftermarket screen. Do you know if it also has an upgraded power supply? Backlit screens need much more wattage to run compared to the original screen, and even flash carts require more power to operate than official nintendo carts. The original DMG gameboy is very constrained in supplying power, so swapping to a fancy screen can make it so there isn't enough free power to run the flash cart's memory bank controller properly. The result is that memory banks won't get switched which causes data to load and save from the wrong locations.

I suspect that this is what's happening to you. But without taking apart all your stuff and checking it all out on an electronics bench, I cannot say for sure. You can try to rule things out by testing with a GBC or maybe even a GBA since those models are more tolerant of increased power demands.

[fsegouin]

I did suspect my DMG too as this issue happened as I said on two different cartridges but using the same Game Boy and same save file. Yes it is an IPS display and yes I have upgraded the power board myself. I did not have any power related issue with other games but this could be a valid explanation indeed.

That being said, I did notice the issue earlier in my save where PC boxes from 7 to 12 started showing signs of corruption before it got bad enough to mess up the save file. And this happened on my GBC, using the Chinese cart. I bought it on AliExpress a while ago. The same cart on which I encountered the bug for the first time and lost my save. I then proceeded to continue playing on the croco cartridge from a backup of the same save file, that did not happen to have any sign of memory corruption yet at that stage.

To add to the mystery, I had the 60 fps option enabled on this save while playing on both my GBC and DMG. While this isn’t supposed to work on the DMG (iirc it’s relying on the GBC’s dual speed mode right?) it is definitely faster than without the option enabled on my DMG somehow, hence why I kept it on. It’s probably unrelated but who knows.

I feel like there’s too many variables here and we might never find out what the real issue is. I since tried to reproduce the bug and could not trigger it, even if I initially managed to see it twice at the same spot. This makes me think it’s a hardware issue as well, but having seen this bug twice in two different carts... I don’t know for sure.

Thanks so much for looking into this anyway. I love your work and enjoyed playing the game so far, I don’t want to give up that easily :)

[jojobear13]

Thanks for the report regardless.

I had the 60 fps option enabled on this save while playing on both my GBC and DMG. While this isn’t supposed to work on the DMG (iirc it’s relying on the GBC’s dual speed mode right?) it is definitely faster than without the option enabled on my DMG somehow, hence why I kept it on.

For the record. 60 fps will work on the DMG, it just won't use any double-speed features so it can be a little choppy.