Well, there's a number of possibilities.
1) game has 1 sdk string, and saves. This is what we hope. but the sdk string won't always reveal the size. emulators generally can just read the protocol during initialization and pick the right size when more than one are possible. We probably don't need to check a database, BUT....
2) same, but the game actually has a smaller save type, and it's doing an antipiracy check. for this case we need an exception list to catch those games that lie.
3) game has one sdk string, but it's just AP and the cart doesn't have any save. it expects the save to fail. this also needs an exception. Any save type can cause this.
4) game has multiple sdk strings, and doesn't actually save. it's all antipiracy. Because there are multiple strings, we KNOW we need to check the database.
5) game has multiple sdk strings, but only one of them is real, and the rest are antipiracy. We know we need to check the database.
There's also the wrinkle of flash manufacturer. I dunno if any games actually check the flash manufacturer for antipiracy, but you need to emulate a manufacturer supported in that SDK version or the game cannot save.
If we can reliably determine the SDK version from inspecting the .gba file, we can pick a supported manufacturer code. Hopefully the manufacturer is never actually used as antipiracy...
i suspect this list of exceptions by 4 character game code will be of use. these are games that vba-m can't autodetect properly.
vba seems to have some heuristics for how to handle multi strings. It processes them in the order it finds them.
Flash overrides no other strings. If ANY other strings are first, it's ignored.
SRAM overrides all others EXCEPT flash with a number, which is not overrode.
EEPROM overrides flash WITHOUT a number, but not flash WITH a number or SRAM.
Default flash size is 0x10000, unless it's FLASH1m, then it gets set to 0x20000.
But there are also overrides for the autodetection, based on 4 character game code from the rom header area. They are all listed in vba-over.ini in the source.
Classic nes/fc series games need special support, because they mirror the program rom 4 times (nothing else actually does this). as noted the are all eeprom4 EXCEPT for Zelda2, which is eeprom64.
This particular heuristic seems to give the smallest number of false positives. you can then check vb_over.ini to work out the overrides. there are only 103 of them.
VBA (and most other emulators) actually decides what the size of the eeprom is at first read. This seems to work. could OPEN_AGB_FIRM do the same thing, or is there some reason it won't work?
if (cpuDmaCount == 0x11 || cpuDmaCount == 0x51) {
if (eepromBits == 0x11) {
eepromInUse = true;
eepromSize = SIZE_EEPROM_8K;
as for flash manufacturers, i'm guessing this is already solved, since vba just uses one for small flash and one for large flash, so its' probably doing the same thing.
vba does sometimes autodetect the RTC. it never autodetects a sensor.
The pokemon games all lie about their flash size as a form of antipiracy, and actually use the bigger one.
Other games lie about their flash size and actually use the smaller one.
Top gun is the only multi string game that doesn't actually save.
the 103 figure includes undetected RTCs. 32 of them are pokemon games.