Mortal Kombat Madness?

Mortal Kombat Madness?
by Shonumi on 2016-04-17 (#168726)

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:

Re: Mortal Kombat Madness?
by gekkio on 2016-04-17 (#168728)

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.

Re: Mortal Kombat Madness?
by byuu on 2016-04-18 (#168734)

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.

Re: Mortal Kombat Madness?
by Shonumi on 2016-04-18 (#168737)

gekkio wrote:

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 :/

Re: Mortal Kombat Madness?
by Sik on 2016-04-18 (#168739)

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!)

Re: Mortal Kombat Madness?
by gekkio on 2016-04-18 (#168744)

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

Re: Mortal Kombat Madness?
by Shonumi on 2016-04-18 (#168746)

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.

Re: Mortal Kombat Madness?
by Sik on 2016-04-18 (#168750)

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).

Re: Mortal Kombat Madness?
by adam_smasher on 2016-04-18 (#168755)

What are the odds that the commercial cart with problems is a bootleg, and the pirates didn't bother to properly customize the mapper?

Re: Mortal Kombat Madness?
by Shonumi on 2016-04-18 (#168768)

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:

Re: Mortal Kombat Madness?
by FitzRoy on 2016-04-19 (#168905)

Quote:

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.

Re: Mortal Kombat Madness?
by Shonumi on 2016-04-20 (#168925)

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 N^th 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.

Re: Mortal Kombat Madness?
by tepples on 2016-04-20 (#168927)

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.

Re: Mortal Kombat Madness?
by lidnariq on 2016-04-20 (#168928)

Shonumi wrote:

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

Re: Mortal Kombat Madness?
by gekkio on 2016-04-20 (#168929)

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.

Re: Mortal Kombat Madness?
by lidnariq on 2016-04-20 (#168931)

The difference on the back appears to be what ROM pin 31 (A18?) is connected to... perhaps connecting ROM A18,A19 to AA13,A14 instead of to RA18,AA13 ?

Re: Mortal Kombat Madness?
by AWJ on 2016-04-20 (#168934)

Quote:

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

A alternate/simpler way to describe the logic: Bit 4 of $2000 is completely unused. Bits 0-3 of $2000 form a 4-bit "inner" bank number which only affects the ROM1 address range ($4000-7FFF). Bits 0-1 of $4000 form a 2-bit "outer" bank number which affects both ROM0 ($0000-3FFF) and ROM1.

INNER &= 0xF

ROM0 bank = OUTER << 4
ROM1 bank = OUTER << 4 | INNER

Quote:

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

I don't see how that's possible. My suspicion is that when 0 is written to $6000, OUTER only affects bank 1, but the bank number is still 6-bit (4 bits from $2000 and 2 bits from $4000)

I looked at the MK1&2 ROM, and it looks like the first "outer" bank contains the menu program and a whole bunch of empty space, the second "outer" bank contains MK1, the third "outer" bank contains MK2 and the fourth "outer" bank is empty. The copies of MK1 and MK2 are complete with GB headers (they might actually be identical to the original single-game versions)

Here's a possible heuristic for detecting MBC1 multicarts: A 1 megabyte MBC1 ROM with no cartridge RAM (all the multicarts are this size) with valid data in bank $20 (not empty and not a duplicate of bank 0) is probably a multicart, since bank $20 is never accessible in a standard MBC1 configuration. The tricky part is defining "valid data". MK1&2 has a valid GB header there (the original MK2's header); do the other multicarts as well?

Re: Mortal Kombat Madness?
by AWJ on 2016-04-20 (#168935)

gekkio wrote:

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.

gekkio, when you get a chance to check the traces, please check whether there's a difference between those two carts in how CPU A15 is connected (it'll be connected to a pin on the MBC on a non-multicart; is it connected to the same MBC pin on a multicart?)

Re: Mortal Kombat Madness?
by lidnariq on 2016-04-20 (#168936)

Looking at the PCB pictures (BFAN-01 vs BFAN-10), A15 looks unchanged. The only visible change is the additional trace that ends vaguely near AA13/AA14, and a change of the trace (that ends vaguely near ROM A18).

The changes that I do see are consistent with what you said in the previous post.

Re: Mortal Kombat Madness?
by AWJ on 2016-04-20 (#168940)

Based on the chip pinout, I'm pretty sure the usual explanation of MBC1 register $6000, that it determines whether $4000 affects RAM or ROM, is incorrect.

Register $4000 directly corresponds to pins AA13 and AA14 on the chip, which can be connected to the upper address lines of either the RAM or the ROM (or both, in theory, but I don't think there are any MBC1 games with both >512KB ROM and >8KB RAM) There's only the one pair of pins, not one set for RAM and a different set for ROM (which would be required to make the chip work like the usual docs say) So what does $6000 actually do?

When 0 is written to $6000, AA13 and AA14 are AND gated with CPU A14, meaning they're forced to 0 when accessing $0000-3FFF and $8000-$BFFF (practically meaning $A000-BFFF, since VRAM isn't on the same bus as the cartridge slot) The upshot is that only the $4000-7FFF ROM range is banked; $0000-3FFF always accesses the first 16KB of the entire ROM, and $A000-BFFF always accesses the first 8KB of RAM.

When 1 is written to $6000, it looks like AA13 and AA14 are ungated, meaning all ROM and cartridge RAM accesses use the upper bank bits. If I'm right, you can take a standard 1MB or 2MB MBC1 cart, write 1 to $6000 and it'll behave like a "multicart", but with 512KB "outer banks". I'm not sure if there are any games that actually do this; if they do, they won't work on emulators that emulate MBC1 according to the description in the usual docs.

Re: Mortal Kombat Madness?
by Shonumi on 2016-04-20 (#168967)

AWJ wrote:

I don't see how that's possible. My suspicion is that when 0 is written to $6000, OUTER only affects bank 1, but the bank number is still 6-bit (4 bits from $2000 and 2 bits from $4000)

All I'm doing is translating what emulators do in C++ into plain English. Any inaccuracies are what I gathered between MAME and Gambatte. Gambatte treats ROM reads with all 7-bits present, MAME does as you say using 6-bits. I went with Gambatte's version because it's much easier to read and understand. Anything I wrote is just a preliminary guess since I'm trying to figure out what other people's code was meant to achieve (for the relevant parts, there are practically no useful comments anywhere in either emulator...)

I suppose this only highlights how important it is to have public discussions like we are doing now, out in the open, with multiple people verifying things and offering theories. Otherwise, we just get "rough ideas" on how things work, and no one really bothers to investigate, let alone share their thoughts or results. This is also why I'm very happy to see this topic generating some great info. This is exactly what has been missing from the Game Boy emu-dev scene. Trust me, it only gets worse for other things. Folks tend to write code, but don't do squat to explain it, and that leaves curious types in the dark unless they're programmers too.

So by all means, keep posting more stuff guys. I'll be very glad to have an accurate understanding of MBC1 multicarts

Re: Mortal Kombat Madness?
by byuu on 2016-04-21 (#169014)

Thanks for the info on this mapper, Shonumi and AWJ.

Given the PCB says DMG-M-BFAN-10, and the M- is the unique part, I'm going to nickname this mapper MBC1M. Hopefully you guys don't mind me calling it that.

I understand that it's technically a literal MBC1 and just wired differently. But "MBC1M" is a lot easier to describe a mapper than "MBC1 with pins 16-19 connects to ROM pins 13-16 instead of RAM pins 8-11" (or whatever.)

Anyway, since Shonumi is going with sinamas' version, I've implemented AWJ's theory for now, that way if any bugs arise we can compare between our two implementations to see which one is correct. AWJ's runs Mortal Kombat I & II just fine, at least.

This is what I have for the mapper so far:

Code:

auto Cartridge::MBC1M::read(uint16 addr) -> uint8 {
  if((addr & 0xc000) == 0x0000) {  //$0000-3fff
    return cartridge.romRead((romHi << 4) * 0x4000 + (addr & 0x3fff));
  }

  if((addr & 0xc000) == 0x4000) {  //$4000-7fff
    return cartridge.romRead((romHi << 4 | romLo) * 0x4000 + (addr & 0x3fff));
  }

  return 0xff;
}

auto Cartridge::MBC1M::write(uint16 addr, uint8 data) -> void {
  if((addr & 0xe000) == 0x2000) {  //$2000-3fff
    romLo = data & 15;
  }

  if((addr & 0xe000) == 0x4000) {  //$4000-5fff
    romHi = data & 3;
  }
}

auto Cartridge::MBC1M::power() -> void {
  romHi = 0;
  romLo = 1;
}

struct MBC1M : MMIO {
  auto read(uint16 addr) -> uint8;
  auto write(uint16 addr, uint8 data) -> void;
  auto power() -> void;

  uint4 romLo;
  uint2 romHi;
} mbc1m;

I didn't bother with the register at $6000. I'll do so if we find a game that uses it, otherwise I don't like guessing.

Unless we find a 2MiB multi-cart, it's speculation where $2000.d4 is usable or not. Although I don't see why it wouldn't be, I'll disallow it for now.

Re: Mortal Kombat Madness?
by gekkio on 2016-04-21 (#169032)

I did some testing, and here are the connections:

BFAN:

Code:

ROM A0-A13  = Gameboy A0-A13
ROM A14-A18 = MBC1 RA14-RA18
ROM A19     = MBC1 AA13

MBC1 AA14 is unconnected

M-BFAN:

Code:

ROM A0-A13  = Gameboy A0-A13
ROM A14-A17 = MBC1 RA14-RA17
ROM A18-A19 = MBC1 AA13-AA14

MBC1 RA18 is unconnected

Now, let's treat the MBC1 as something that has two registers: 5-bit zero-adjusted ($2000), 2-bit ($4000).
The collection carts use just a normal MBC1, so the behaviour of $6000 should be exactly the same as with normal MBC1 carts.
The difference is in how we combine the two main registers to get the upper ROM address bits.
BFAN uses 5 + 1 bits (RA14-RA18 + AA13: ARRRRR), while M-BFAN uses 4 + 2 bits (RA14-RA17 + AA13-AA14: AARRRR).
Based on the No-Intro and MAME databases, almost all MBC1 collections include just the MBC1 chip and a 8Mbit ROM.
There's just one exception: Momotarou Collection also has 64Kbits of RAM.

In my opinion $6000 should still be emulated since it affects the behaviour and the effects are predictable.
$2000.d4 doesn't need to be emulated, because it's not obvious where that pin would go in the final physical ROM address and no game seems to use it.
We only have real 8Mbit ROM cases, so wirings of MBC1M with smaller and bigger ROMs can only be speculated.
For example, can we really assume in all cases that both AA13 and AA14 are used? If they are interpreted as "game number", AA13 would be enough if we have only two games.
Because of this uncertainty, I intend to hard-code a 8Mbit ROM requirement for MBC1M in my emulator.

All this has reminded me of the need to do logic analysis on the MBC1 :shock:

Tauwasser has already done good in-depth research, but I think independent testing is still valuable and I might uncover some surprising things.

Re: Mortal Kombat Madness?
by AWJ on 2016-04-21 (#169036)

So the only difference between a "multicart" and a standard MBC1 cart is that the connection of the MBC1 bank-select lines to the ROM address lines skips over RA18? That's pretty much what I expected.

I think there's exactly one cartridge that connects all seven MBC1 bank-select lines to ROM: the 16-megabit Dragon Quest Monsters. All other GB/GBC games that are bigger than 8 megabits use a different MBC.

I was gonna ask "who's Tauwasser" but then I remembered he contributed a bunch of GB stuff to MAME a couple years back, and I managed to google up his blog and wiki. The description and VHDL code on his wiki agree with my hypothesis that register $6000 simply controls whether the upper bank-select lines are ANDed with CPU A14 or not.

I wonder why both MBC1 and MBC2 were designed to do the "zero-adjustment" thing. It obviously requires additional logic in the chip, it creates unusable "holes" in large ROMs and it doesn't seem to serve any useful purpose...

Re: Mortal Kombat Madness?
by gekkio on 2016-04-21 (#169039)

Quote:

The description and VHDL code on his wiki agree with my hypothesis that register $6000 simply controls whether the upper bank-select lines are ANDed with CPU A14 or not.

Indeed! This leads to an interesting fact about MBC1 behaviour that I just verified with real carts: on big cartridges where AA13-AA14 are used, ROM0 area ($0000-$3FFF) is switchable (even on normal wiring!)

1. Write $01 to $6000. This makes AA13 and AA14 independent of A14
2. Write $03 to $4000. AA13 and AA14 are now both 1
3. ROM reads from $0000-$3FFF will have AA13 and AA14 bits 1 -> if even one of them is connected to the ROM, it will not read bank 0!!

I just verified this on both Dragon Quest Monsters (all 7 address bits from MBC1) and Super Chinese Fighter GB (6 address bits from MBC1, including AA13)

Re: Mortal Kombat Madness?
by gekkio on 2016-04-21 (#169042)

I need to collect proper evidence with logic analysis about this, but here's an execution trace from my GB peek&poke program I use to fiddle with real cartridges.

Code:

Connecting...
Connected
> rb 0x0100
$0100: 00 C3 50 01 CE ED 66 66  CC 0D 00 0B 03 73 00 83  ..P...ff.....s..
$0110: 00 0C 00 0D 00 08 11 1F  88 89 00 0E DC CC 6E E6  ..............n.
$0120: DD DD D9 99 BB BB 67 63  6E 0E EC CC DD DC 99 9F  ......gcn.......
$0130: BB B9 33 3E 44 51 2F 4D  4F 4E 53 54 45 52 53 00  ..3>DQ/MONSTERS.
$0140: 00 00 00 80 42 34 03 03  06 02 00 33 00 71 25 B4  ....B4.....3.q%.
$0150: FE 11 3E 00 20 01 3C EA  1D C8 31 FF DF CD B1 15  ..>. .<...1.....
$0160: CD 5B 16 CD 80 00 21 00  80 01 00 1C AF CD 9A 16  .[....!.........
$0170: 21 8A C8 AF 22 22 22 77  3E 04 EA EE C8 3E 00 EA  !..."""w>....>..
$0180: 8A C8 3E 01 EA 00 61 3E  00 EA 00 41 3E 00 EA 00  ..>...a>...A>...
$0190: 61 3E 00 EA 00 41 3E 0A  EA 00 01 3E 01 EA 00 21  a>...A>....>...!
$01A0: 3E 00 EA 00 41 3E 01 EA  1C C8 3E FF EA B7 C8 EA  >...A>....>.....
$01B0: B8 C8 CD 00 37 AF EA C7  C8 FA 1D C8 B7 28 07 AF  ....7........(..
$01C0: E0 4F E0 70 E0 56 CD F7  13 38 07 AF EA 1C C8 C3  .O.p.V...8......
$01D0: 8B 02 01 0C 00 CD A2 14  3E 14 EA 74 C7 21 00 08  ........>..t.!..
$01E0: D7 CD E6 13 3E 02 EA 74  C7 21 00 08 D7 CD E6 13  ....>..t.!......
$01F0: 3E 03 EA 74 C7 21 00 08  D7 CD E6 13 3E 04 EA 74  >..t.!......>..t
> w 0x6000 1
> rb 0x0100
$0100: 00 C3 50 01 CE ED 66 66  CC 0D 00 0B 03 73 00 83  ..P...ff.....s..
$0110: 00 0C 00 0D 00 08 11 1F  88 89 00 0E DC CC 6E E6  ..............n.
$0120: DD DD D9 99 BB BB 67 63  6E 0E EC CC DD DC 99 9F  ......gcn.......
$0130: BB B9 33 3E 44 51 2F 4D  4F 4E 53 54 45 52 53 00  ..3>DQ/MONSTERS.
$0140: 00 00 00 80 42 34 03 03  06 02 00 33 00 71 25 B4  ....B4.....3.q%.
$0150: FE 11 3E 00 20 01 3C EA  1D C8 31 FF DF CD B1 15  ..>. .<...1.....
$0160: CD 5B 16 CD 80 00 21 00  80 01 00 1C AF CD 9A 16  .[....!.........
$0170: 21 8A C8 AF 22 22 22 77  3E 04 EA EE C8 3E 00 EA  !..."""w>....>..
$0180: 8A C8 3E 01 EA 00 61 3E  00 EA 00 41 3E 00 EA 00  ..>...a>...A>...
$0190: 61 3E 00 EA 00 41 3E 0A  EA 00 01 3E 01 EA 00 21  a>...A>....>...!
$01A0: 3E 00 EA 00 41 3E 01 EA  1C C8 3E FF EA B7 C8 EA  >...A>....>.....
$01B0: B8 C8 CD 00 37 AF EA C7  C8 FA 1D C8 B7 28 07 AF  ....7........(..
$01C0: E0 4F E0 70 E0 56 CD F7  13 38 07 AF EA 1C C8 C3  .O.p.V...8......
$01D0: 8B 02 01 0C 00 CD A2 14  3E 14 EA 74 C7 21 00 08  ........>..t.!..
$01E0: D7 CD E6 13 3E 02 EA 74  C7 21 00 08 D7 CD E6 13  ....>..t.!......
$01F0: 3E 03 EA 74 C7 21 00 08  D7 CD E6 13 3E 04 EA 74  >..t.!......>..t
> w 0x4000 1
> rb 0x0100
$0100: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0110: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0120: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0130: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0140: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0150: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0160: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0170: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0180: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$0190: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$01A0: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$01B0: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$01C0: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$01D0: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$01E0: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
$01F0: FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF  ................
> w 0x4000 2
> rb 0x0100
$0100: DA 4E E2 4E EA 4E EF 4E  F4 4E F9 4E 02 4F 0B 4F  .N.N.N.N.N.N.O.O
$0110: 14 4F 1C 4F 21 4F 22 4F  25 4F 36 4F 44 4F 57 4F  .O.O!O"O%O6ODOWO
$0120: 66 4F 79 4F 8B 4F 9F 4F  AE 4F C0 4F D4 4F E3 4F  fOyO.O.O.O.O.O.O
$0130: F0 4F FA 4F FF 4F 15 50  1E 50 3B 50 47 50 52 50  .O.O.O.P.P;PGPRP
$0140: 66 50 76 50 94 50 AB 50  BD 50 E1 50 F0 50 2E 51  fPvP.P.P.P.P.P.Q
$0150: 4A 51 6E 51 91 51 9F 51  AB 51 BB 51 CB 51 E9 51  JQnQ.Q.Q.Q.Q.Q.Q
$0160: F7 51 15 52 1F 52 3E 52  4E 52 74 52 88 52 97 52  .Q.R.R>RNRtR.R.R
$0170: A5 52 B5 52 C5 52 D4 52  15 53 20 53 34 53 3B 53  .R.R.R.R.S S4S;S
$0180: 42 53 45 53 48 53 51 53  59 53 5F 53 64 53 66 53  BSESHSQSYS_SdSfS
$0190: 68 53 6A 53 6C 53 6E 53  70 53 72 53 74 53 8B 53  hSjSlSnSpSrStS.S
$01A0: 91 53 C3 53 D1 53 DF 53  F2 53 05 54 1C 54 52 54  .S.S.S.S.S.T.TRT
$01B0: 72 54 80 54 91 54 A0 54  C4 54 D3 54 E3 54 F6 54  rT.T.T.T.T.T.T.T
$01C0: 06 55 0C 55 24 55 49 55  67 55 80 55 80 55 80 55  .U.U$UIUgU.U.U.U
$01D0: 9F 55 C3 55 EA 55 F7 55  03 56 0E 56 1A 56 26 56  .U.U.U.U.V.V.V&V
$01E0: 32 56 3D 56 48 56 53 56  5F 56 6A 56 75 56 80 56  2V=VHVSV_VjVuV.V
$01F0: 8B 56 97 56 A3 56 A4 56  A9 56 AE 56 B3 56 B8 56  .V.V.V.V.V.V.V.V

Re: Mortal Kombat Madness?
by Shonumi on 2016-04-21 (#169059)

byuu wrote:

Thanks for the info on this mapper, Shonumi and AWJ.

Thank AWJ and gekkio. They're doing all the poking and prodding and verifying the MBC1M electronic stuff. My efforts here (condensing already available info) have been minimal, in my opinion :wink:

Anyway, looks like there's been a lot of progress since this thread started. I'm going to try to recap key points about what we know about the MBC1M (I like this name btw, byuu, I'm gonna steal it

)

1) The main difference between the standard MBC1 and MBC1M is wiring, which affects bank selection.
2) Calculating ROM0 Bank selection -> (ROM_HI << 4) where ROM_HI is the 2 bits written to 0x4000-0x5FFF
3) Calculating ROM1 Bank selection -> (ROM_HI << 4) | (ROM_LO) where ROM_HI is the 2 bits written to 0x4000-0x5FFF, and ROM_LO is 4 bits written to 0x2000-0x3FFF.
4) Writing 1 to 0x6000-0x7FFF enables ROM0 to switch to banks 0x10, 0x20, or 0x30. Otherwise, it will read from 0x0 always.

#4 makes sense to me. It explains why MK 1&2 writes to 0x6000-0x7FFF at all. Does the above look correct to everyone else? Please make sure it lines up with everything that's been said so far. My ultimate goal (besides emulating MBC1M games) is break all this down into the simplest understandable terms, something I could add to the GBDev wiki for example.

I'm rather curious about cart RAM for MBC1M for Momotarou Collection. How does it handle RAM banking? If it's an MBC1M game, how does it use the bit at 0x6000 - 0x7FFF? Or maybe I missed something during this discussion?

Re: Mortal Kombat Madness?
by lidnariq on 2016-04-22 (#169066)

Shonumi wrote:

I'm rather curious about cart RAM for MBC1M for Momotarou Collection. How does it handle RAM banking? If it's an MBC1M game, how does it use the bit at 0x6000 - 0x7FFF? Or maybe I missed something during this discussion?

The NES and SNES multicarts I have seen sometimes connect the same control line to both ROM and RAM, and so each outer bank corresponds not only to program N, but also to program N's save memory.

So, in that world, you could think of MBC1 and MBC1-M as:
When 0x6000.0 is 0
* cart RAM is always bank 0
* ROM bank at 0x0000-0x3FFF is always 0
When 0x6000.0 is 1
* cart RAM is bank written to 0x4000
* ROM bank at 0x0000-0x3FFF is also controlled by the register at 0x4000 (depending on PCB variant, either selecting banks 0/0x20/0x40/0x60 or 0/0x10/0x20/0x30)
Regardless of what 0x6000.0 is:
* ROM bank at 0x4000-0x7FFF is the concatenated results of the two bits in 0x4000 and the five or four bits in 0x2000

Hopefully that helps clear things up, and isn't just repeating things.

Re: Mortal Kombat Madness?
by AWJ on 2016-04-22 (#169071)

According to the MAME software list Momotarou Collection has only 8KB (64Kbit) of RAM, which doesn't need to be bankswitched.

Re: Mortal Kombat Madness?
by Shonumi on 2016-04-22 (#169079)

My bad. I guess I misread it as 32KB somewhere. In that case, I don't think it's anything special in regards to RAM, just the usual enable/disable when writing to 0x0 - 0x1FFF.