SD007_T40_6401B*CD_BGA48_TS28 w/ CY62136CV30

[bamartin125]

I have recently (accidentally) purchased a Pokemon Yellow cartridge that I later found to be a counterfeit. I cannot return, so I am trying to put it to use now that I have it.

Image of the inside of the cartridge:

Using my GBxCart RW 1.4c (with the latest R42+L15 firmware installed) & FlashGBX v5.0.1 (beta), I have attempted to extract some information from the cartridge. However, I am new to the scene and I could use a little guidance so that I can help get support added.

Here is a screenshot of my attempt to use FlashGBX to analyze the flash cartridge:

It looks to me like nothing useful came back from the Common Flash Interface Data extraction.

So, we dig...

Looks like a Cypress SRAM chip is being used for the flash storage. Specifically model number CY62136CV30.

Chip image:

Datasheet header:

I'm honestly not sure how much of that is abstracted in the implementation on these things. Although, it looks like many of the profiles included with FlashGBX seem to indicate the model number of the flash storage, so...

I used FlashGBX with the Generic Flash Cartridge (WR/555/A9) profile and pulled 2MiB of data. Of course, I am told that the checksum doesn't match.

Screenshot of a completed dump with an incorrect checksum warning:

The checksum values:

When analyzing the data in ImHex, I find that the ROM doesn't match what I have previously obtained as a ROM for Pokemon Yellow. I'm not sure why the differences, but there are quite a few blocks of those.

Here is a screenshot of many of the diffs. This probably only really matters to someone familiar with Pokemon Yellow? Not sure. On the left is a known-good dump that I have played and on the right is what I obtained from the dump of this cartridge:

(sorry if this is TMI)

At this point, I don't know what is most helpful exactly, but I figured I would try and figure out what remaining offsets I can find and report that make any sense.

So, from what I can tell the beginning of the dump really is the beginning of the game ROM I would have expected. Next, I wanted to look for the save data.

In Pokemon Yellow, you can name your player whatever you want. So, I named my player "EEEEEEE" (7 "E"s) which I know gets mapped to hex 84 84 84 84 84 84 84 (7 x 0x84s). In a normal save data, that name would be first found at address 0x2598. However, in this large dump, I find it at offset 0x116598. So, I think that means that the save state begins at 0x114000 (0x116598 - 0x2598). I don't know what (if anything) this helps us to determine. Again, I'm new to this scene.

Let me know if I can provide any other useful information. Dumps, etc. I don't know what is appropriate to send up front or not.

Anyways, thanks in advance for any pointers and/or support someone may provide. My kids thank you :)

[LucentW]

Hey and welcome to the rabbit hole of the bootleg cartridges!

Consider that the specimen you have at hand is an extremely recent iteration of the SD007* family of MBC5 flashcarts: the flash is actually under that globtop silkscreened "16M", the SRAM chip is there because the game needs it... but as you figured out already, the ROM is patched... because when you save in game, that patched routine flashes back the SRAM contents into the game ROM, which gets loaded back into SRAM on boot by another routine overriding the game's original entry point, the so called batteryless saving routines... made to save literal cents per cart to the bootleggers (no battery cell, less efficient SRAM chips) 😁

You might be interested in this snippet of mine to reimplement the batteryless saving routines on any other game, but considering the flash commands are hardcoded it might be useful to crosscheck with your current full dump if they match or not: https://gist.github.com/LucentW/0aa8e1530f37441a622212689971193e

I'm sorry to say though that this whole patching and so on is out of scope of the FlashGBX project, but you can definitely hook some folks up, me included, in a handful of communities, including the insideGadgets' Discord server where you can ask more about it all.

[bamartin125]

Posting this here until I find a better place --

I was able to demonstrate restoring and backing up save game data for the bootleg game on this cartridge just yesterday. I created a new flash cartridge profile file (initially a copy of fc_DMG_39VF6401B.txt) in the FlashGBX config directory with a modification to the sector size from 0x8000 to 0x4000 and a replacement of the names array to contain an entry of "SD007_T40_6401B*CD_71_TS28 with 39VF6401B". With that I was able to issue the following:

• for backup:

  flashgbx \
    --flashcart-type "SD007_T40_6401B*CD_BGA48_TS28 with CY62136CV30" \
    --mode dmg \
    --action backup-save \
    --dmg-savetype batteryless \
    --bl-layout 0 \
    --bl-offset 0x114000 \
    --bl-size 0x8000 \
    <save-file-path>
  

• for restore:

  flashgbx \
    --flashcart-type "SD007_T40_6401B*CD_BGA48_TS28 with CY62136CV30" \
    --mode dmg \
    --action restore-save \
    --dmg-savetype batteryless \
    --bl-layout 0 \
    --bl-offset 0x114000 \
    --bl-size 0x8000 \
    <save-file-path>
  

I don't know if there is anything useful here to contribute back to FlashGBX or not, but it works for me in the nearterm for save management with the current bootleg cartridge and patched ROM that is loaded on it. I think it's pretty awesome that FlashGBX supports the batteryless save options it does.

Please let me know if there is anything I can contribute to the codebase according to this finding.