SuperFW: a (very much WIP) supercard firmware

[Apache Thunder]

One notable difference I've noticed with my SuperCard Lite MicroSD is that the fw flash requires a different unlock command then the others and the sckill app from that other custom fw project isn't able to update the fw section. (despite updating mode switch for fw rom read/write, nothing is changed).

The interesting bit though is if i send the unlock mode switch to it via a modified build of GBA-Exploader in NorFlash mode I can flash small GBA files to it and it actually changes the flash. I haven't gotten anything to boot though. As a I recall most of FW rom is not accesible until you poke a register as I was told so you'll have to account for that if you want to make your project usable on fw flash.

 

[Gamemaster2022]

Thanks for the report!
I also noticed that the Lite has some quirks (I found some funny comments in SCFW and devkitpro sources) so I was wondering whether my FW was at all compatible with this particular model.
It seems it's not easy to find any more (only the regular microsd version is still available in aliexpress and similar sites, the other versions seem gone).
That means having an in-game menu will be even more important for these carts.

I just tried your menu on my GBA and I noticed, save files for some games are being saved in full size - 128kb instead of the 64kb regular firmware saves. Does that mean that pokémon games will no longer have problems with corrupted saves when you polish your firmware a bit in the future?

 

[davidgf]

I was just lazy and dumped the entire 128KB SRAM (instead of trying to detect the save size). I might improve this in the future (detecting save size is not complicated).

 

[Gamemaster2022]

I was just lazy and dumped the entire 128KB SRAM (instead of trying to detect the save size). I might improve this in the future (detecting save size is not complicated).

I mean that's a good thing. As far as I know the supercard has 256kb SRAM chip but it only saves 64kb on the stock firmware as well as on metroid maniac's scfw. Some games like pokémon have larger saves than 64kb which causes the save to get corrupted each time I load it because it's not completely saved though the game fixes it and all the pokémon and locations works. If you could go around this limitation saves would no longer get corrupted

 

[davidgf]

Oh didn't know that
BTW my supercards are definitely 128KB (one ships a KM68V1000B and the other a BS62LV1024 chip). Which models ship the 256KB chip?

 

[metroid maniac]

Oh didn't know that
BTW my supercards are definitely 128KB (one ships a KM68V1000B and the other a BS62LV1024 chip). Which models ship the 256KB chip?

The size of the chip doesn't matter. SRAM addressing is restricted 16 bits (64KB) as a hardware limitation. You need banking to have more SRAM capacity, but as far as I can tell there's no registers mapped for this purpose.

 

[davidgf]

Oh right! Totally forgot about this.
Checking gbatek it seems that no SRAM game uses more than 64KB, so I'm wondering how the 128KB SRAM is actually mapped.
Given that 128KB flash is indeed banked, what you mention about the 64KB hardware restriction seems to make perfect sense. Now the question is: how is the SRAM banked? I assumed that the banking commands used for flash ([E005555h]=AAh, [E002AAAh]=55h, [E005555h]=B0h) are specific to the flash chip, but I have no idea.
Did you do any investigation on this? I also understand from the comments that the original supercard firmware doesn't do any bank swtiching? (So 128KB games don't work?). Feels odd given they installed a 128KB chip.

 

[metroid maniac]

Oh right! Totally forgot about this.
Checking gbatek it seems that no SRAM game uses more than 64KB, so I'm wondering how the 128KB SRAM is actually mapped.
Given that 128KB flash is indeed banked, what you mention about the 64KB hardware restriction seems to make perfect sense. Now the question is: how is the SRAM banked? I assumed that the banking commands used for flash ([E005555h]=AAh, [E002AAAh]=55h, [E005555h]=B0h) are specific to the flash chip, but I have no idea.
Did you do any investigation on this? I also understand from the comments that the original supercard firmware doesn't do any bank swtiching? (So 128KB games don't work?). Feels odd given they installed a 128KB chip.

Official GBA games use up to 32KB SRAM.
As far as I'm aware, the Supercard doesn't have any mechanism to switch SRAM banks. Some flashcarts like EZ Flash IV do, by poking a particular MMIO register. Other cars like Everdrive emulate EEPROM & Flash commands for games which use those chips, so you don't have do do anything in software to handle saving..
Modern Supercards are just using whatever SRAM chips the manufacturer can salvage. I don't imagine there's a very big price difference any more between a 64KB and a 128KB chip, so they just ground the address pins when using a bigger chip. You see this kind of thing in bootleg GBA games too.
There are only a handful of 128KB saving games in the GBA library. Pokemon Gen 3 is the important one, and the Supercard's official client patcher seems to have a customized patch for this game which trims the save down to 64KB by taking advantage of redundancies in those games' save file layout.

 

[JORGETECH]

Will the card still support passme to run DS homebrew?
> For now I'm focusing on GBA mode (also my NDS died and I don't have a SuperKey with me for testing)

You don't need an original SuperKey for testing PassMe, those cheap R4 clones on Aliexpress that support YSMenu (RetroGameFan's version) have PassMe functionality if you use YSMenu, it's an option in the START menu.

 

[davidgf]

Oh thanks for the passme advice, I found some information that pointed to that but couldn't test it due to my DS being dead. I will try it once it comes back to life.

Post automatically merged: Sunday at 6:56 PM

Ok so about the SRAM and its 128KB capacity.
I chatted with Maniac and we reached the conclusion that yeah, only 64KB are addressable via the SRAM bus (that's why flash uses bank switching instead of mapping the 128KB directly), and that there might be a way to use it all.
I checked the SRAM chip, and it has 17 address lines, as expected. Pin A16 (the MSB) is not connected to GND nor VCC from my testing, but rather to a pin in the CPLD, which could mean there's a way to control it somehow. We just haven't figured out yet how to do that.

I'm attaching some pictures. The first one shows how the pins are connected. A16 is not wired to any other GND/Vcc pin. In fact, the Vcc and the neighbouring NC pin are connected to VCC (actually connected to the backup battery, there's some diode so that the battery is not used whenever the cart is powered up, but it kicks in when the cart is not). The other pin is the CE2 which is always tied high, that one is connected to VCC (not battery).
I find it interesting that the NC is wired up, I assume they could use BS62LV2001 chips (256KB) if they ever cheaper or easy to get, since those have an A17 signal in that NC. Interestingly enough this is not the case for A16, which hints that they did not intend to limit the SRAM to 64KB.
The next picture is my probing of the A16 pin, which seems connected to the shown pin on the CPLD. This pin is the 9th from the corner, which could be 67th pin if I'm counting it correctly. If Im not wrong it could be pin E9 in the manual.

So here we are, haven't yet figured out how this pin switching works. My obvious next steps would be:

- Figure out the JTAG/ICP header and attempt to dump the CPLD configuration.
- Find the right software (back from 2007) to make sense of it and perhaps view the config?
- Understand how the pin is flipped and test it out on a real cart.

Sounds like complicated If anyone can assist, please lemme know

 

[Hunter]

my OG phat Supercard SD does not use a battery

 

[Klikks]

Sounds like complicated If anyone can assist, please lemme know

I can hook up my logic analyzer later today. Do you have any clues on which pads are which? (the 6 pads on the back side)

I'm not too confident but pad 1 seems to be GND and pad 6 seems to be VCC. I measured in quite the hurry, I will measure with more patience this afternoon (in a few hours from now).

My plan was to supply pad 6 with 3.3V, connect pad 1 to GND common ground with the analyzer and then put the analyzer data pins on the 4 remaining pads and see if I get any data.

For some context;
I ordered 4 carts, just before SCFW came out. My initial plan was to learn more about this cart. Then came the SCFW and a bit later SuperFW. It seems there is still room for me to contribute!

I'll let you guys know how it goes.