It is currently Thu Oct 19, 2017 6:33 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Mortal Kombat Madness?
PostPosted: Sun Apr 17, 2016 9:35 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
So, I'm doing a bit of bug hunting in my GB emulator, and I figured I should start off with some problems affecting specific DMG games. I thought Mortal Kombat & Mortal Kombat II would be simple enough as a starting point, but it turns out this isn't the case. Allow me to explain.

This game is a compilation of the 1st and 2nd MK games for the DMG, so it uses a menu after the copyright and publisher info screens. Selecting either MK1 or MK2 from the menu, however, always restarts the game back to the copyright and publisher screens. Start, Select, A, B, doesn't matter what's pressed; the result is the same, just an endless loop without the game starting.

Now, at first, I dismissed this (the issue was reported to my project) as a bad dump, but when I checked with another source, the dump they used was clean (as far as the MD5 hash indicates) and it exhibited the same problems in my emulator, in BGB, and in VBA-M. What's even stranger is that they put MK & MKII on a flashcart and played it on a real Game Boy, only to have the same menu-loop problem occur on real hardware. My next thoughts were that maybe no one has been able to get a clean & verified dump of this game before (unlikely, but hey, it could happen).

Unfortunately, I don't think that's the case. I stumbled upon this ebay page as I was looking to buy this game myself. So, looks like actual production carts had bugs in them too. Evidently, this isn't an issue of emulation or getting complete ROM data from the physical cart; it seems like something larger...

So here are my current thoughts:

1) Maybe they goofed when making a number of MK & MKII carts. A number of them might have defects that make the game unplayable.
2) Maybe they aren't really using an MBC1, maybe something different that neither flashcarts nor emulators can handle? But that doesn't explain why commercial carts have the issue, unless something inside the cart breaks down over time. But how would that affect dumping it properly?
3) Maybe something inside the cart is defective (something to do with the MBC itself) but the ROM image is still usable, e.g. the ROM banks need to be rearranged after using a dumping tool?

Any thoughts from others are appreciated. If you know anything about this game, let me know. Thanks everyone :wink:


Top
 Profile  
 
PostPosted: Sun Apr 17, 2016 10:55 pm 
Offline

Joined: Fri Oct 16, 2015 6:18 am
Posts: 39
MK I + II is one of the MBC1-based collection carts, which use the MBC1 chip but with a different wiring. It's impossible to know this from the $0147 header, so an emulator (or a flash cart!) playing this game will fail if the cartridge is emulated with normal MBC1 logic.


Top
 Profile  
 
PostPosted: Mon Apr 18, 2016 12:01 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
Oh, that's hilarious. Here I thought the DMG was the one system where you could realistically get away with pure header heuristics alone (with just a bit of nasty voodoo for MMM01 carts.)

That even BGB can't run it is deliciously ironic given last year's April Fools joke regarding external mapping information that would solve exactly this problem :P

I don't suppose you have any documentation on how the emulated logic needs to change for this alternate wiring? Or have you not emulated it yet either? If not, I may look into it when I get some downtime again.


Top
 Profile  
 
PostPosted: Mon Apr 18, 2016 12:17 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
gekkio wrote:
MK I + II is one of the MBC1-based collection carts, which use the MBC1 chip but with a different wiring. It's impossible to know this from the $0147 header, so an emulator (or a flash cart!) playing this game will fail if the cartridge is emulated with normal MBC1 logic.


Thanks for the response! What about commercial carts failing on real hardware? That ebay link hints to a similar problem. It could be that some component in the MBC is failing, but I'm wondering if it was widespread with this game... If you don't mind me asking, have you emulated this game yet? If so, what does the logic for its MBC look like compared to the standard MBC1?

byuu wrote:
Oh, that's hilarious. Here I thought the DMG was the one system where you could realistically get away with pure header heuristics alone (with just a bit of nasty voodoo for MMM01 carts.)


I was hoping the MMM01 carts would be the only ones I'd have to deal with when it came to this kind of stuff :/


Top
 Profile  
 
PostPosted: Mon Apr 18, 2016 12:31 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
byuu wrote:
Oh, that's hilarious. Here I thought the DMG was the one system where you could realistically get away with pure header heuristics alone (with just a bit of nasty voodoo for MMM01 carts.)

It really looks like any system where mappers were used is pretty much doomed to this problem.

Reminds me of the suggestion of doing the same with the Mega Drive... As far as licensed games go, you can get away with it because headers contain valid data (aside maybe for a few games with invalid SRAM headers, but those get given away the moment they try to access it). As soon as you enter unlicensed territory you can't trust the ROM anymore since a lot of those have their own custom registers unique to them (ugh!). I really hope people doing homebrew don't attempt to do this because there's still a good chunk of free space in the official header yet >=/ (but good luck getting people to not use the default header their devkit comes with!)


Top
 Profile  
 
PostPosted: Mon Apr 18, 2016 1:12 am 
Offline

Joined: Fri Oct 16, 2015 6:18 am
Posts: 39
Quote:
What about commercial carts failing on real hardware? That ebay link hints to a similar problem. It could be that some component in the MBC is failing, but I'm wondering if it was widespread with this game...


My guess is dirty contacts, or some other standard issue with carts. There really is nothing special about this cart except the different wiring.

Quote:
If you don't mind me asking, have you emulated this game yet? If so, what does the logic for its MBC look like compared to the standard MBC1?


I don't emulate it yet, because I haven't checked the wiring and don't have a game hash database or other heuristic to apply the different logic to the right games.
You can check MAME source code for some hints, because they claim to support the MBC1 collection games properly.

If you plan to support these carts, here's some design questions you might want to think about:

  • how do you detect games? hashes, titles, some other heuristic?
  • how do you support ROM hacks and other minor or major changes to the original ROMs? For example, if you change one byte, the hash changes


Top
 Profile  
 
PostPosted: Mon Apr 18, 2016 2:35 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
gekkio wrote:
* how do you detect games? hashes, titles, some other heuristic?
* how do you support ROM hacks and other minor or major changes to the original ROMs? For example, if you change one byte, the hash changes


Personally, I think trying to automatically detect edge cases like this is the wrong approach. For the vast majority of games that work by reading the cart header, auto-detection is great, but for something like MK 1&2, I think it's best to have a one-off option (either command-line or GUI) and label it something like "Emulate MBC1 Collection Cart (MK 1&2)". Then, whenever the user wants to run a game that needs this edge case, they have to manually and explicitly enable it for the current ROM being loaded. If they want to play another MBC1 game, they have to disable it (the GUI can remind them if need be, or they can just deal with it...)

I know it's a hassle for the end user, but if the scope is limited to a few games, I don't see a problem. It becomes one of those situations where the user goes "Oh, I want to emulate XYZ game, but I have to check this special option for it to work." It's not all that uncommon in other emulators (specifically thinking of PCSX2's hacks, and some options buried within Dolphin) and it saves me the pain of trying to find out if the user is running some exotic game.

So, instead of an automatic approach, they'd just do it themselves. They'd have to be smart enough to read the README about known issues, but other than that, I'd take the emulator out of the equation when it comes to choosing whether the game is MK 1&2 or not. As long as there are not hundreds of these kinds of cases, it's manageable.


Top
 Profile  
 
PostPosted: Mon Apr 18, 2016 4:53 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Shonumi wrote:
If they want to play another MBC1 game, they have to disable it (the GUI can remind them if need be, or they can just deal with it...)

You could probably just save the setting for that ROM (going by filename should be more than enough for nearly everybody).


Top
 Profile  
 
PostPosted: Mon Apr 18, 2016 7:10 am 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 192
What are the odds that the commercial cart with problems is a bootleg, and the pirates didn't bother to properly customize the mapper?


Top
 Profile  
 
PostPosted: Mon Apr 18, 2016 9:41 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
adam_smasher wrote:
What are the odds that the commercial cart with problems is a bootleg, and the pirates didn't bother to properly customize the mapper?


Very low, most likely, if we're going by the example I posted. The picture clearly shows the cart and label have aged in the manner one would expect, so it's not a recent pirate. If it's an older pirate cart, it must have had the best labeling and cart molding I've ever seen, since to my eyes they look spot on to a legitimate cart. As far as GB games go, discrepancies with the cart and the label are the biggest warning signs short of popping it open and looking at the innards. So, visually, it looks like other legit carts.

Also, though this game is somewhat obscure, it was never rare or even widely popular, so I don't think people considered making pirate carts for MK 1&2. That won't stop someone determined, but given the history of Game Boy pirate carts, it seems like big-name games and 1000000000-in-1 types games were most common, and the lesser common ones had completely incorrect labels as a dead giveaway more often than not.

Though if there are other visual cues I missed that might indicate a pirate cart in the ebay link, I'd love to know. I'm a game collector, so it's always nice to update my list of "might-be-fake" clues :wink:


Top
 Profile  
 
PostPosted: Tue Apr 19, 2016 10:40 pm 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 93
Quote:
Very low, most likely, if we're going by the example I posted. The picture clearly shows the cart and label have aged in the manner one would expect, so it's not a recent pirate. If it's an older pirate cart, it must have had the best labeling and cart molding I've ever seen, since to my eyes they look spot on to a legitimate cart. As far as GB games go, discrepancies with the cart and the label are the biggest warning signs short of popping it open and looking at the innards. So, visually, it looks like other legit carts.


It does look good, so I'm gonna guess that it's a dirty contact like gekkio. Pirates do love them some multi-game carts, but anything with a label that good would imply that they also tested its functionality. The cart itself looks dirty enough on the outside to indicate that.

Also, if we look at higan's bug list, two other games exhibit this behavior: Bomberman Collection and Genjin Collection.

And it's yet another reason why databases are important for the time being. We're in a constant process of discovery and breakage, and until every single game is dumped and tested, there is nothing but the misery and confusion plaguing rom-side mapping. We've got standard boards and boards that deviate slightly. Who knows if the PCB on this board even has its own code. Plenty of NES games do this rewiring/substitution act with no serial distinguishment.


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 9:39 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 256
FitzRoy wrote:
And it's yet another reason why databases are important for the time being. We're in a constant process of discovery and breakage, and until every single game is dumped and tested, there is nothing but the misery and confusion plaguing rom-side mapping. We've got standard boards and boards that deviate slightly. Who knows if the PCB on this board even has its own code. Plenty of NES games do this rewiring/substitution act with no serial distinguishment.


As I understand it, GB carts are much saner than NES or SNES when it comes to headers in a vast majority of cases. It's just a limited number of edge-cases that pop up. Still, I agree that databases are important. If there was a single place I could have looked up detailed info about MK 1&2, I probably wouldn't have made this thread. Instead, I've had to piece together bits of info from Google searches and advice from others familiar with these kinds of tricky games.

I'll just take this moment (yet again, for the Nth time) to complain about how poor Game Boy documentation is, especially in regards to something like more exotic MBC variants. If you want to know more about the MBC7, for example, good luck. You'll need to pick apart mostly uncommented code (most of it tracing their origins to VBA-M) to figure out what's going on. I can't stress enough how many times I find things about the Game Boy that have only been documented as emulator source code with sparse comments. In my opinion, source code is only ever half of what proper documentation looks like. It's the implementation, which is helpful, but not the actual schematic. Things need to be written in Plain-Old-English so everyone can understand what's going on without having to dissect code.

It's a huge pet-peeve of mine. I hate it when emulators like MAME or Gambatte does something (in this case, support for MBC1 "multicarts") but fail to explicitly write out how it functions. I had to parse Gambatte (MAME's code was not helpful, or at least not as clear as it could have been) to figure out how MK 1&2 works. For the sake of others, I'm going to share the results here so no one has to scratch their heads anymore.

Code:
//MBC1 "multicart" writeable registers
0x2000 - 0x3FFF: Lower 5 bits of the ROM bank (Bits 0-4)
0x4000 - 0x5FFF: Upper 2 bits of the ROM bank (Bits 5-6)
0x6000 - 0x7FFF: "Multicart" mode select bit

As far as I can tell, MBC1 multicarts do not have cart RAM. What normally is the ROM/RAM banking mode bit at 0x6000 - 0x7FFF instead switches the MBC into a "multicart" mode. In this mode, half of the available banks (0x3F) can be accessed. Even though something like Mortal Kombat 1&2 appears to use 1MB of data, it only really has 512KB worth of data on its cart. A lot of those banks are blank data (0xFF). In "multicart" mode, unlike most MBCs, ROM0 can actually be replaced with another bank (0x0, 0x10, 0x20, or 0x30). As a result, unlike MBC1s, the multicart versions can access Bank 0x20 by setting ROM0 to it. ROM1 cannot access 0x20, however (or 0x40 or 0x60 for that matter).

When entering multicart mode, ROM0 gets switched with another bank using the following formula (assume ROM_BANK is the full ROM bank number using all 7 bits from 0x2000 through 0x5FFF)

ROM_BANK = ((ROM_BANK >> 1) & 0x30)

So essentially, in multicart mode, ROM0 banks translate as follows:
Banks 0x0 through 0x1F = 0x0
Banks 0x20 through 0x3F = 0x10
Banks 0x40 through 0x5F = 0x20
Banks 0x60 through 0x7F = 0x30

When entering multicart mode, ROM1 gets switched with another bank using the following forumla:

ROM_BANK =  ((ROM_BANK >> 1) & 0x30)  | (ROM_BANK & 0xF)

So essentially, in multicart mode, ROM1 banks translate as follows:
Banks 0x0 through 0x1F = 0x0 - 0xF, then 0x0 - 0xF again
Banks 0x20 through 0x3F = 0x10 - 0x1F, then 0x10 - 0x1F again
Banks 0x40 through 0x5F = 0x20 - 0x2F, then 0x20 - 0x2F again
Banks 0x60 through 0x7F = 0x30 - 0x3F, then 0x30 - 0x3F again

When multicart mode is disabled, ROM banking works just like a regular MBC1, as far as I can tell.

On a final side-note, when changing the ROM0 by writing a new ROM bank number or flipping the multicart mode bit in 0x6000 through 0x7FFF, most games jump to code in WRAM before doing so. This makes sense because switching out ROM0 means you get new interrupt handling code at 0x40, 0x48, etc... ROM1 also changes its bank, so the only "safe" spot to switch banks is in WRAM to avoid accidentally executed random code.


I haven't looked at the PCB (I can't read electronics or anything like that) but this gets MK 1&2 working. It would be best if someone verified that's how actual hardware works. But I'm sick of documentation not being written out explicitly.


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 10:33 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
Use of MBC1's WRAM bank output for selecting the outer bank on a multicart resembles the use of MMC1's CHR bank output for selecting the outer bank on a large game, such as the English Dragon Warrior III, Dragon Quest/Warrior IV, and the multicart Final Fantasy I & II.


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 10:39 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6283
Location: Seattle
Shonumi wrote:
As I understand it, GB carts are much saner than NES or SNES when it comes to headers in a vast majority of cases. It's just a limited number of edge-cases that pop up. Still, I agree that databases are important.
And yet that's also why the database hadn't been formed. With the NES we knew it was batsh insane and needed to document it; the more consistent the system the more you have to look until you discover...

Quote:
I haven't looked at the PCB (I can't read electronics or anything like that) but this gets MK 1&2 working.
If you want/can, you could post pictures of the PCB (front and back). It would let anyone compare what's there with an "ordinary" MBC1 cart that they have on-hand.

EDIT: Wait, gekkio already did! http://gekkio.fi/blog/2016-03-19-game-b ... hotos.html


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 10:45 am 
Offline

Joined: Fri Oct 16, 2015 6:18 am
Posts: 39
Quote:
If you want/can, you could post pictures of the PCB (front and back). It would let anyone compare what's there with an "ordinary" MBC1 cart that they have on-hand.


I've got photos of cartridge PCBs, including MK I+II, here:

http://gekkio.fi/blog/2016-03-19-game-boy-cartridge-pcb-photos.html

My cartridge has DMG-M-BFAN-10, which is easiest to compare with Super Chinese Fighter GB, which has DMG-BFAN-01.
There is a minor difference in the traces in back, but the vias on the front side are under the chips, so it's impossible to visually see where the traces go. I intend to properly check the traces, but won't have much time to do that before the weekend.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group