sanni / cartreader

A shield for the Arduino Mega that can back up video game cartridges.
GNU General Public License v3.0
2.18k stars 221 forks source link

Batman Forever (Sega Genesis) not dumping padding correctly #1007

Closed PsychoFox11 closed 2 months ago

PsychoFox11 commented 2 months ago

OSCR firmware version

14

OSCR hardware version

HW5

Attach OSCR_LOG.txt file here

OSCR HW5 V14.0

[+] Mega Drive/Genesis

[+] Game Cartridge

Cart Info

Name: BATMANFOREVER bramCheck: 0100 Size: 32 MBit ChkS: BC5F Sram: None

Press Button...

[+] Read ROM

Saving to MD/ROM/BATMANFOREVER/1123/... [***] Internal checksum...Error 533C

CRC32... 795F8C5E -> Not found

System used

Select a system

Describe the issue.

Creating a new issue for this specifically, as I can reproduce it and gathered more info about the behavior. The other issue also mentions Turrican, but I can dump that fine consistently, and may be an issue with a bad cart. Batman Forever seems to be an actual OSCR issue though.

I am not able to get a good dump of Batman Forever (World) using the OSCR, and another user is experiencing the same which led to me looking into this.

It is a 4MB chip with a 3MB game on it (older ROMs were trimmed). However, starting at the beginning of the 4th MB, according to No-Intro's dump, which includes one from a Retrode, it should be all FF for the last 1MB. The first 3MB dump fine, but then the 4th MB seems random - always a different checksum/CRC32. The game plays fine.

Typically this would lead me to believe that the last MB isn't mapped to the edge connector, and desoldering would be the only way to dump the full chip - however, a Retrode was able to do it, so it appears to be possible. It is a single chip, and any time Sega used chip sizes that were not a power of 2, multiple chips were used. It also doesn't overdump and return to the beginning.

Here's a comparison of one of my dumps (top) compared to what's known (bottom).

image

Every value I get in the padding is either 3C, 3E, 7C, or 7E - and 1C a few times at the beginning then not again - but never in the same order.

Here's the PCB (thanks to @fakkuyuu for reporting that this game didn't dump properly in general and providing this pic - my PCB is the same).

image

Anyone know what might be going on here?

sanni commented 2 months ago

Try enabling the internal pull-up resistors on the data pins, then open bus should become 0xFF.

In MD.ino line 696

Change:

// Switch data pins to read
void dataIn_MD() {
  DDRC = 0x00;
  DDRA = 0x00;
}

to:

// Switch data pins to read
void dataIn_MD() {
  DDRC = 0x00;
  DDRA = 0x00;
  // Enable Internal Pullups
  PORTC = 0xFF;
  PORTA = 0xFF;
}
PsychoFox11 commented 2 months ago

That works, should I keep it there permanently or would it cause issues with others, and we need to make it only do it for this cart? @fakkuyuu making sure you see this

sanni commented 2 months ago

I'll add it to the github code and make a remark about what it does for future reference.

PsychoFox11 commented 2 months ago

Ok thanks so much! I'm great at ROM analyzation but I don't understand the hardware side too well yet!

fakkuyuu commented 2 months ago

I've rewritten the code and was able to dump it. Thank you. IMG_20240802_172822 IMG_20240802_173259

PsychoFox11 commented 2 months ago

While it does give us a dump that matches No-Intro now, if I understand correctly, the last 1MB isn't properly mapped, and this is more of a "write FF instead of random noise when you can't read it" type code. So while it results in a cleaner, properly sized file, I don't think it confirms that FF is really on the chip - which is fine, I don't think that can be confirmed from the edge connector, and this matches what No-Intro has recorded. I'm guessing the Retrode does something similar as it only creates a match if you force the size to 4MB instead of the default trimmed 3MB. If I get a chance, I'm going to desolder this chip and see if I can find out what's on it - something I'm still new to. My guess is that it probably DOES continue the FF that the 3MB ends with, but I have encountered a few where the ROM written to the cart ended in FF but the blank padding after the end of the ROM was 00. I've also seen one with whatever factory noise originated on the chip where they don't write to the last part. When that's the case, there's an argument for calling it a 3MB ROM (or whatever size). It only matters for full-chip preservationists. The game is being recorded just fine even in the noisy dump, but I like to be sure what's in there. If I find anything other than FF, I might revisit this (via a new issue) as I'd update No-Intro as welll. I think it is good to mark this closed now.