It is currently Wed Apr 26, 2017 4:57 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Apr 20, 2016 11:37 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5571
Location: Seattle
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 ?


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 12:11 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 295
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?


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 12:33 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 295
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?)


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 12:45 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5571
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 2:27 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 295
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.


Top
 Profile  
 
PostPosted: Wed Apr 20, 2016 6:51 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 237
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 :D


Top
 Profile  
 
PostPosted: Thu Apr 21, 2016 9:14 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1274
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.


Top
 Profile  
 
PostPosted: Thu Apr 21, 2016 12:16 pm 
Offline

Joined: Fri Oct 16, 2015 6:18 am
Posts: 32
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.


Top
 Profile  
 
PostPosted: Thu Apr 21, 2016 1:02 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 295
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...


Top
 Profile  
 
PostPosted: Thu Apr 21, 2016 1:11 pm 
Offline

Joined: Fri Oct 16, 2015 6:18 am
Posts: 32
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)


Top
 Profile  
 
PostPosted: Thu Apr 21, 2016 1:37 pm 
Offline

Joined: Fri Oct 16, 2015 6:18 am
Posts: 32
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


Top
 Profile  
 
PostPosted: Thu Apr 21, 2016 8:24 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 237
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 :P)

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?


Top
 Profile  
 
PostPosted: Fri Apr 22, 2016 12:10 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5571
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Fri Apr 22, 2016 4:14 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 295
According to the MAME software list Momotarou Collection has only 8KB (64Kbit) of RAM, which doesn't need to be bankswitched.


Top
 Profile  
 
PostPosted: Fri Apr 22, 2016 7:21 am 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 237
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.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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