Possible gameboy bug

[Cephiros]

So, i have dumped around 300 games in total between most supported systems, and i can get almost every rom to dump correctly, minus a few overdumps than when trimmed come out correctly, and a couple games with 1-2 bytes different, I blame my carts for such small errors. That said, I have one gameboy MBC2 game, Final fantasy Legends, the ROM dumps correctly, however the save will not. It is the only save that will not load in an emulator. Before I report this as a bug, is there anyone that can either confirm or disprove my bug using fw5 and fw 10.2? Test any mbc2 game with a valid save by dumping the save and loading it in an emulator?

Thank you.

[PsyK0p4T]

Sorry, I don't have the right stuff to test your save problem...
But can you share the list of games/systems that gave you an overdump ? Maybe you found some real size problems in OSCR files

[PsyK0p4T]

Nothing's hurry ;)
Ok for Metroid zero mission. I'll submit the fix to the txt file.

For Brain Lord (and snes in general) the rom size isn't working same as gba. Moving the line position in the txt shouldn't change anything. The thing I wanted to test was to change the bank amount at the end of line "AC443D87,85C3,F93A1045,12,048". Have you changed the last chars "048" by "024" ? if result is still an oversized dump, then maybe @sanni can find the issue :(

Ok for SMS. Still not good then. Size detection is a pain on SMS/GG really. Maybe the solution at the end will be to have rom sizes stored in the txt file.

8 minutes, wow. Papier Mario is one of the biggest roms but that's still a lot... Yeah for switches they must be "left right left left", 3v is correct.

[Cephiros]

Yes, I have made that change from 48 to 24, and resulted in no change to the file, which i find strange, I will have to try dumping it again,if there are less banks I would expect a smaller file size. That said, I probably dont have a real grasp on hot its working.

[Cephiros]

I meant to make mention that hardware5 only has an on/off switch, and a 3 3/5v switch, no eep, or clk switches to set.

[sanni]

The script I used to create the database mistook Brain Lord (USA) for a LoROM game and thus looked at the wrong place for the header and wrote wrong checksums into the database file. Fixed now.

OSCR HW5 V10.3
[+] Super Nintendo/SFC
[+] SNES/SFC cartridge

Searching database...
Checksum: A16A
Header CRC32: 113FC077
Found
Correcting size
Size: 16 -> 12Mbit
Banks: 32 -> 24

Title: BRAIN LORD
Revision: 0
Type: HiROM FastROM
ICs: ROM SAVE
Rom Size: 1 MB (24 banks)
Save Size: 8 KB
Checksum: A16A

[+] Read ROM
Saving to SNES/ROM/BRAIN LORD/538/...
Dumping HiRom...
[*******************]
Checksum... A16A -> OK
CRC32... AC443D87 -> Brain Lord (USA).sfc

[Cephiros]

Confirm this works, Thank you! I forgot the game had sram to dump, oops.

[Cephiros]

I have a theory on this initial problem, reading the documentation on this mapper it looks like it uses 512x4 bits in a 512x8bit array. Reading 1111xxxx 1111yyyy 1111zzzz 1111wwww. I suspect the emulator is expecting only the lower bits (xxxxyyyy zzzzwwww). This theory originates from looking at the dump, which every byte starts with F, and is 512bytes, and the sram dump from mgba is 256 bytes. If this is the case the ram might be reading correctly and i should, in theory be able to write it back to the cart. I havent attempted that because i dont prefer to loose the save on a hunch. I would like to figure out a way to strip every other 4 bits from the file and try that in an emulator.

[Cephiros]

I was very close. They were also swapped. So yyyyxxxx wwwwzzzz. This problem is solved, I may write an application for others for this use case. With the verification that my dump works, i had enough courage to try and write to the cartridge. That works as expected. This is an emulator quirk, not a gameboy dump bug.

[nmrugg]

Hey, thanks for the solution! I wanted to add that this fixed my issue with Final Fantasy Adventure as well. (It would be nice if cartreader would do this automatically.) For anyone else who needs it, here's the Node.js script I used to convert the dump to the expected format for the emulator:

// Usage: node convertSave.js filename.sav
var fs = require("fs");
var p = require("path");
var filePath = process.argv[2];
var newFile = p.join(p.dirname(filePath), p.basename(filePath, p.extname(filePath)) + ".srm");
var data = fs.readFileSync(filePath);
var fixedData = [];
var len = data.length;

for (var i = 0; i < len; i += 2) {
    fixedData.push(((data[i + 1] & 0x0f) << 4) | (data[i] & 0x0f));
}

fs.writeFileSync(newFile, Buffer.from(fixedData));

[mariomadproductions]

and a couple games with 1-2 bytes different, I blame my carts for such small errors.

this is a bit of an aside, but it'd be interesting to know which ones had error. its possibly that there may be errors in the rom database, if those carts haven't been re-dumped much (or there was a dump tool error).