SNES - Mortal Kombat (Europe) (Rev 1) never came out

[Pr3tty F1y]

So, I don't think that Mortal Kombat (Europe) (Rev 1) needs to be removed from the dat. However, I think the argument can be made that it never reached store shelves. What should be added to the dat is Mortal Kombat (Europe) (Rev 2).

If you look at the PCB image, you can see two ROM chips (the smaller SPAL-KX-EXT and the larger SPAL-KX-1):



If you reference MAME's Software List for SNES, you'll see that this revision of MK is a 2mb ROM and a 32kb ROM for SPAL-KX-1 and SPAL-KX-EXT, respectively.

Now the -EXT is a bit telling (as is the small 32kb size), but I'm arguing that this is a patch done in ROM. My guess is that there was a bug found late in production of Mortal Kombat (Europe) (Rev 1) and rather than scrap the ROM chips they devised a plan to just patch the game with a the 32kb ROM to create Mortal Kombat (Europe) (Rev 2).

If you run the SPAL-KX-1 ROM thru NSRT, you get this which matches the current dat entry for Rev 1:

Code: Select all

---------------------Internal ROM Info----------------------
       File: datmk1.sfc
       Name: MORTAL KOMBAT            Company: Acclaim
     Header: None                        Bank: LoROM
Interleaved: None                        SRAM: 0 Kb
       Type: Normal                       ROM: 16 Mb
    Country: Euro/Asia/Oceania          Video: PAL
  ROM Speed: 120ns (FastROM)         Revision: 1.1
   Checksum: Good 0xA2EC            Game Code: 
---------------------------Hashes---------------------------
      CRC32: 047B3D88
        MD5: 1D348D1AF28DB657195F926CC0207796
--------------------------Database--------------------------
       Name: Mortal Kombat
    Country: Europe                  Revision: 1.1
     Port 1: Gamepad                   Port 2: Gamepad
    Genre 1: Fighting                 Genre 2: Hand To Hand

However, if you patch/replace the first32kb of the SPAL-KX-1 ROM with the SPAL-KX-EXT ROM, you get:

Code: Select all

---------------------Internal ROM Info----------------------
       File: Mortal Kombat (Europe) (Rev 2).sfc
       Name: ____~________\___        Company: Acclaim
     Header: None                        Bank: LoROM
Interleaved: None                        SRAM: 0 Kb
       Type: Normal                       ROM: 16 Mb
    Country: Euro/Asia/Oceania          Video: PAL
  ROM Speed: 120ns (FastROM)         Revision: 1.2
   Checksum: Good 0xA78F            Game Code: 
---------------------------Hashes---------------------------
      CRC32: 1ED2D8D6
        MD5: E86C05726A2731E9845314D5808F2946
--------------------------Database--------------------------
    ROM wasn't found in the database (possible bad dump).
    You can try using -fix or -findover to see if the
    file has been slightly altered in a rectifiable way.

So, the header does get jacked up a bit with the internal name, but the checksum remains good and the revision is boosted to 1.2.

I believe that this is the only way to account for both the SPAL-KX-EXT and SPAL-KX-1 ROMs being on that single PCB and, therefore, is truly what you would get in your European SNES if you plugged the supposed "Rev 1" cart into your system.

Unless someone can uncover a PCB with only the data contained in the SPAL-KX-1, the combination of the SPAL-KX-EXT and SPAL-KX-1 ROMs is likely the correct way to document this ROM in the dat as you can see the traces on the PCB wire these two ROMs together, hence integrating them into a Rev 2 ROM.

Figured I'd post this as I've been sitting on it a while and when I saw the Genesis Triple Play 96/Gold PCB and ROMs which just got redumped and seems to similarly have traces connecting the SRAM to the ROM chip (messing up the mapping and making the true dump of that game not playable with current emulators), I got all fired up about PCB wiring oddities

[badinsults]

I can't remember exactly the details on how bsnes/Higan handles this game, but the patch was necessary to fix a bug when the game was reset. If the patch sets the revision to 1.2, then I would assume that it was by mistake.

[Pr3tty F1y]

I can't remember exactly the details on how bsnes/Higan handles this game, but the patch was necessary to fix a bug when the game was reset. If the patch sets the revision to 1.2, then I would assume that it was by mistake.

Well, I don't have access to the spreadsheet/data from Nintendo regarding documented releases so I can't confirm what would be on there (i.e., what's Nintendo's official documentation on the release), but to me it makes sense if 1.1 had a bug that the patch would boost the revision to 1.2.

The only thing that puzzles me is the internal name. The only thing I can possibly think of would be to fudge the bytes in the combined image to get a good checksum but even that seems to be stretch to me.

Either way, I think the combined rom should be added to the dat as the 32kb EXT rom replacing the 1st 32kb of the Rev 1.1 rom because the dat is currently ignoring the 32kb EXT rom.

I want to say someone with a retrode did dump their cart and what it exported was the data you'd get by patching the existing 1.1 rom with the 32kb rom. I just can't remember where that discussion was documented.

[Hiccup]

I googled the spreadsheet name and found this Saves me from uploading it.

[Pr3tty F1y]

Thanks Hiccup. If I'm reading the table right, I'm seeing a Rev 1.2 PAL Mortal Kombat from 4/9/1996. Interesting that it's so long after 1.1. Which means, is there a 1.1 PCB out there in the wild with no patch rom?

[badinsults]

Thanks Hiccup. If I'm reading the table right, I'm seeing a Rev 1.2 PAL Mortal Kombat from 4/9/1996. Interesting that it's so long after 1.1. Which means, is there a 1.1 PCB out there in the wild with no patch rom?

There was a Majesco re-release of Mortal Kombat in 1996, but it uses the 1.0 version of the game. Maybe they originally intended to issue a 1.2 release, but for some reason they didn't bother.

[Hiccup]

I think we should try and get a back-of-pcb picture for one of the rev1+ext chip PCBs, to see what the manufacturing date is and compare that to the info on the Nintendo sheet. Then we can get more of an idea if this PCB is really meant to be Rev 1 or Rev 2.

It'd also be good if we could get trusted dumps of each ROM chip. But I guess for now we can make do with the (unattributed?) MAME dumps.

[Pr3tty F1y]

I think we should try and get a back-of-pcb picture for one of the rev1+ext chip PCBs, to see what the manufacturing date is and compare that to the info on the Nintendo sheet. Then we can get more of an idea if this PCB is really meant to be Rev 1 or Rev 2.

It'd also be good if we could get trusted dumps of each ROM chip. But I guess for now we can make do with the (unattributed?) MAME dumps.

Question about that Nintendo spreadsheet (if you or anyone else knows). Are those 4 character values followed by a lowercase h's in the far right comments column hashes? I thought that they may be, but I cannot identify the algorithm. I've tried hashing the files with every 16-bit hash algorithm I can find and I can't replicate those values, but I thought that if they were ROM hashes, that they could prove quite useful.

[Hiccup]

Hmm... they could be. Have you tried CRC-16 and just hashing the data for a single ROM chip?

[Pr3tty F1y]

Hmm... they could be. Have you tried CRC-16 and just hashing the data for a single ROM chip?

I did some ROM splitting to split the various Euro MK1 roms into 1mb chunks and the hashes are 16-bit checksums (and it's the same 16bit checksum used to internally calculate the cartridge's total checksum in the header info).

However, my frankenstein'd "1.2" rom does not match the checksum hashes in the sheet, but it also doesn't match Rev 1 either so but we're definitely not accounting for that 32kb rom in the dat currently and that 32kb rom is not an additional 32kb onto of the 2mb of ROM for MK. It's definitely replacement data for the 1st 32kb of the 2mb total.

[Hiccup]

The sheet checksums don't always match. But it might be worth trying some other games in case you've got the method wrong or something.

[Pr3tty F1y]

The sheet checksums don't always match. But it might be worth trying some other games in case you've got the method wrong or something.

It is definitely just a 16-bit checksum. You can check it with JackSum: https://jacksum.loefflmann.net/en/index.html

Code: Select all

java -jar jacksum.jar -a sum16 -E hex <your file here>

That's the algorithm on a per-rom chip basis (or, sometimes, like with MK Euro 1.1, splitting the single 2mb rom into 1mb chunks even though the chip on the PCB is a 2mb chip) for the spreadsheet. Jacksum will also give the same checksum that the internal header shows if the rom is good.

[Hiccup]

So if the EXT ROM chip supposedly overwrites the first 32KB, then how come the dumps in DoM (which were apparently done from the "cart end" rather than directly from each chip, like the MAME dumps) match the direct-from-main-chip MAME dump?

Does the game program in the Rev 1 ROM access the EXT data through some special command?

[Pr3tty F1y]

So if the EXT ROM chip supposedly overwrites the first 32KB, then how come the dumps in DoM (which were apparently done from the "cart end" rather than directly from each chip, like the MAME dumps) match the direct-from-main-chip MAME dump?

Does the game program in the Rev 1 ROM access the EXT data through some special command?

I believe it may depend on the equipment used to create the dump.

I'll have to track down where I had read that someone dumped their MK1 cart and got a single image that was the EXT rom patched over top of the baserom.

EDIT: Found it. It was right here from 2018 - http://forum.no-intro.org/viewtopic.php?f=7&t=3279 - It looks like the SuperNT was used to dump it.

And that is matching the hashes on the ROM I manually patched together with EXT and the base rom which I've been calling Rev 2 based on the header, but it could be the "real" Rev 1 based on badinsults thought that it was a mistake (as it also doesn't match the spreadsheet):

[relax]

Mortal Kombat (Europe) (Rev 1) in the dat matches rev 1 in the sheet. Use checksum-16 (not CRC-16) on the two halves for instance in HxD.