Feed on

After making the GBA 32MB cart without any save capability, I decided to revisit the option of adding either SRAM or Flash saves to it.

Initially I thought that it may not be possible on 2 layers because the save flash chip is addressed with A0-A16 however there isn’t enough room on the PCB to route these to the connector pads but then it hit me – the CPLD has just enough pins for it to act as a simple buffer so if I moved things around a little, I could run 16 traces from the CPLD to the save flash chip.


So that’s what I did! The idea was just to use a regular 1Mbit flash chip (which I will tie the highest address pin to ground so it acts like a 512Kbit chip) that was small enough to fit in the area but also have the same flash commands (e.g 0x5555) as the genuine 512Kbit chips (39VF512).

Around the same time, I saw that there was a user who wanted to patch a Pokemon GBA hack to work with a clone cart so that saves would be written back into the main flash chip; just like clone carts do, they can get away with having SRAM with no battery but once you save, it saves back into the main flash chip. They had been looking for a solution for a few months, so I thought I could easily just change the 512Kbit flash chip for a genuine 1Mbit flash chip and make a prototype board, no patching required.

So, once again, that’s what I did. After buzzing out the 1Mbit flash chip (MX29L010), it turned out it was pretty similar to the 1Mbit flash chip I had already.

A week or so later the prototype boards showed up and I started off with the 512Kbit one. The only change in the CPLD schematic was to add outputs and link them to the existing inputs, easy. After flashing the full 32MB without an issue, I tried writing and reading back the 512Kbit flash save which was successful!

Now I needed to try it out, I went with Mario Kart because why not, it was a small game to flash. When loading this game to a cartridge without a flash save chip, the characters appeared to be corrupted however loading it on to this new board made it run normal so I thought everything worked.

That wasn’t the case, after finishing the first 4 races in the cup, it went to save and it failed. I needed to test another game which would save much earlier and found Golden Sun but that too also failed. We need to find out why so we’ll try loading it up an emulator to see what it’s doing.

I was looking for access breakpoints options for NO$GBA kind of like how BGB has where you can break once it reads or writes to a certain address but couldn’t find any. After searching for a bit, I came across mGBA which allows us to set a watchpoint at a certain address, perfect!

The address for SRAM/Flash saves is 0x0E000000 so this means that we would need to watch 0x0E005555 or 0x0E002AAA for the flash chip commands. After setting these, we have some hits, you just hit enter to continue (or type ‘c’ like I did).

One of the data bytes sent to the flash chip was 0xFFFFFF90 (0x90) which is the flash identification, I wonder why they need that? It turns out that games don’t get to choose which flash save chips they use, so they have to be able to handle multiple chips which is why they do this product identification routine.

Armed with information plus the some of the addresses that called these flash functions (e.g 0x8006896), I went back to NO$GBA, set a break point around those addresses and started tracing it.

I saw the data being returned from the flash ID was D9BF (Edit: this may be incorrect as the correct response should be D4BF) and comparing that to an older SST39VF040 datasheet, the BF is the manufacturer ID and the D9 would have to be the device ID. I changed the data returned to say D5BF for example and checked what would happen, it seemed to go back into a loop a few times and try repeating the same process.

After a little while, I figured the exact point we needed to change the result, 594E. I changed that bne statement to a NOP, flashed it to flash cart and lo and behold, it worked!

So what does this mean? It means we would have find a similar sort of flash detection routine for all games and patch it. I’d rather not do that, so I ended up finding 39VF512 flash chips on Ebay – 10 for $12 and will have to wait until they arrive to make sure they work.

For games that use 1Mbit flash such as Pokemon (Mario Kart can also use them), it looks like they send the switch bank command when saving and this command isn’t in a regular flash chip. It’s kind of like the 16 bit counter that Nintendo integrated into their GBA ROM chips. This bank switching command allows the GBA to have access to 1Mbit of flash instead of the maximum of 512Kbit (A0-A16) because it switches to the next 512Kbit bank internally.

Seeing as games detect the flash product ID, I shouldn’t have that issue with the 1Mbit flash save cart because the chip would be coming off a genuine Nintendo cartridge, my Pokemon Ruby cart.

I flashed a Pokemon Gaia hack which uses Fire Red as the starting game, then wrote and read back the 1Mbit flash chip successfully. Powered it up an a GBA and as per the video, it saves, what a relief! This means you could play all the Pokemon GBA games and hacks if you didn’t want to use an EZ-Flash for example.

Now the only issue is actually sourcing the 1Mbit chips, doesn’t look like you can buy them from Ebay, Aliexpress, etc so this means we’ll have to resort to pulling these chips from genuine Pokemon carts. Luckily the Japanese versions aren’t too expensive at around $10-15, but there aren’t that many of them plus we’ll also have to factor this into the cost of our flash cart – stay tuned!

But what if we wanted to use a regular 1Mbit flash chip? What would need to happen for that? I’ve thought about it a little and firstly we definitely need to go for a 4 layer board.

We need to have the CPLD control the data lines of the flash chip, be able to set those pins as inputs and also output a result back to A16-A23. This would allow us to spoof the flash ID result once received but also to spoof the bank switching too, we would set a the highest address pin high on the flash chip however we also need to consider how the sector erasing addresses as that would need a different address pin to be set high. Quite a bit isn’t it?

How about adding RTC? Well, once again we need a 4 layer board so we can fit it. I also traced the RTC chip and guess what… it goes back to the ROM chip pin 1 & 2. We’d have to add whatever logic is in the ROM chip to the CPLD, strangely enough I couldn’t really find much on it after a quick search.

That concludes my GBA cart building for the moment. The production GBA boards should be arriving any day now as well as the Pokemon carts to salvage the flash chip from, we have a listing on our shop ready – GBA 32MB, 1Mbit Flash Save, Flash Cart

Leave a Reply