I'm curious, Bubble bobble on Master system reporting wrong size maybe?

[Fishaphrodite]

Hello,

I use a Sannicart v5 to dump my games, and didn't have any real issue so far, however when I dumped my cartridge of Bubble bobble for the master system, at first it didn't give me a valid checksum for it, I also compared to the No Intro dat file, and the size didn't match (the dat says it should be "262144", which I believe is 256kB, while the sannicart reported 512 kB). after forcing the ROM Size to 256 kB and dumping again, it could validate the checksum (I even checked once more as well as the md5 to make sure it wasn't a fluke).

I'm a bit curious, could it be the cartridge reports the wrong size, the sannicart wrongly thinks of this game being bigger, or be that no meaningful information exists beyond a certain point beyond that size so it somehow ends up being trimmed on no-intro's side?

Have a good day

Log for good measure:

OSCR HW5 V14.3

[+] SMS/GG/MIII/SG-1000

[+] SMS/MarkIII raphnet

[+] Read ROM

SMS Header:
 
Name: TMR SEGA
512KB
 
Press Button...

Saving to SMS/ROM/TMR SEGA/201/...
ROM Size: 512KB
[*******************]
CRC32... D268DC70 -> Not found
Press Button...

[+] Set ROM Size

[+] 256 KB

Selected Size: 256KB
Press Button...

[+] Read ROM

Saving to SMS/ROM/UNKNOWN/202/...
ROM Size: 256KB
[*******************]
CRC32... E843BA7E -> Bubble Bobble (Europe, Brazil) (En).sms

EDIT: I came across issue #527 which seems to talk about such cases.

[andy-miles]

SMS cart size detection algorithm isn't fool proof as not all SMS roms define the same header format (or at all). This issue applies to Cloud Master and Penguin Land US SMS carts as well. In other words, the current implementation makes incorrect assumptions to calculate the rom size; though, it works for a large majority of the carts. This is the reason why a manual cart size selection override was added as a work-around solution (see Commit 644e1dc).

My 2 cents for a better long term solution is to update the SMS/GG code to include a checksum + database lookup approach to determine (or at least validate/confirm) the cart size. This is like how NES and SNES cart reading approaches work. Unless someone else wants to take on the work, I'll add it to my to-do list. But it hasn't been a top priority due to limited time constraints as I just help to contribute on the side.

[Fishaphrodite]

I can confirm it works for a lot of carts (Bubble Bobble is the only one that gave me this issue, 1 game out of 76 is quite low).

I also don't mean to say it's a big problem or anything like that, I was just curious as to why it happened, since the cart size can be set it's easy to work around as long as the size is actually known.

[andy-miles]

Agreed that it isn't a big problem, but it's annoying. I occasionally dump Japanese Mark III carts and have to manually select the cart size each time. So I would be helping myself out in the long run :)