It is currently Mon Jul 16, 2018 8:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Jun 24, 2018 2:14 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 662
I have attached a list of games, currently numbering 70, that are likely to fail in your flash cart or emulator. Some may boot, some may be partially playable but all are likely to fail sooner or later. These >32KB games do use one of the common MBCs (1, 2, 3, & 5) or do not use them in a typical manner.

There are three issues with games like these. First, some of them have hardware that is difficult (camera, accelerometer, flash memory, eeprom) or impractical (infrared, noise making when powered down) to emulate or simulate. Second, there is scant documentation for the hardware in these cartridges because the games are in Japanese or extremely obscure. Third, testing real hardware can be difficult because the cartridges are either rare or in Japanese or Chinese.

Essentially this list shows that emulation of not just unlicensed but licensed games cannot likely be completely done without a mapper assignment system. The internal header can't always be trusted, I believe it fails with MMM01 games for example. Maybe only 16 assignments should be required this time :lol:


Attachments:
Unusual & Unlicensed GB & GBC.txt [2.46 KiB]
Downloaded 47 times

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog
Top
 Profile  
 
PostPosted: Sun Jun 24, 2018 7:19 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 289
The way I handle unique mappers that can't be ID'd via the header is to have the user manually specify which one they want to use before my emulator runs via a simple drop-down list. For example, MBC1M (the multicart variants of the MBC1) and MMM01 carts are done like this in GBE+. Most recently, I've added the MBC1S (sonar variant of the MBC1) to that list.

A lot of people scratch their heads when it comes to handling exotic carts that aren't well detected via the header or other metadata. To me, the solution is simple: don't automate the process. Just tell the user to decide things manually. The mappers outside the current "read the header" method are so small in number, they're edge cases where I'd expect a user to do some prior research (especially since GBE+ comes with a manual detailing such edge cases and how to deal with them) :wink:

On a separate note, it's actually not that hard to automatically detect MMM01 carts, it's just not as straightforward the other MBCs. An emulator need only verify that a valid cart header is in the last 32KB of the ROM when reading in that file (e.g. check for Nintendo logo just to be sure, maybe even do the checksums to be safe). If so, odds are it's an MMM01 cart (or some really tricky homebrew designed to fool the emulator). But this is not as simple as reading a single byte from a fixed location, so emudevs tend to make a fuss about MMM01 :lol:

Anyway, great list! It's perfect for those looking to expand past the basic MBCs. It's useful too to have a list of all of the unofficial carts. Naturally, I have a couple of suggestions to add:

Gyogun Tanchiki: Pocket Sonar - I've informally called this the "MBC1S". It's mostly MBC1; if you treat it as a normal MBC1 cart, you can browse the menus and play the mini game. But sonar functionality will not work. You'll either get a black screen or a white screen depending on what values an emulator returns for unaddressable cart RAM. It's still possible to emulate the sonar via a static image (or other external input, like your own sonar device). Still working on finishing the documentation.

Battle Space and Monster Maker: Barcode Saga - Normal MBC1 carts, but they absolutely require a working Barcode Boy to communicate with. At the start, before being able to enter any play mode, the game pings the Barcode Boy. This isn't a problem with a flash cart as long as you hook it up to a real Barcode Boy, but most emulators will get stuck on a screen asking the user to power on the Barcode Boy. The other 3 Barcode Boy games play just fine without a Barcode Boy, you just can't scan cards for extra stuff.

Zok Zok Heroes - Normal MBC5 cart, but needs the Full Changer accessory for battles. Without the special IR input, the game will get stuck during the first battle/tutorial waiting forever. Even getting past that, every other fight is almost impossible without using the Full Changer to change into different heroes. Not a problem for flashcarts, but definitely an issue for emulators.

GB Mobile Trainer - Not exactly a "game" but it requires the GB Mobile Adapter. Once again, no issue for flashcarts since it's a normal MBC5 cart, but it's tricky for emulation.

Chee Chai Alien - Normal MBC5 cart, but it's the one GBC game that extensively uses the IR receiver. Not tricky from an emulation standpoint (it's enough to return 0 every time the game reads the IR register to get the game to "work" as a hack) but on a real GBC, you better have that plastic clip-on. I tried playing with and without the clip-on, and it seemed to make a world of difference. At least, it took the frustration levels down a couple notches. It's hard to properly "capture" light input without the clip-on, and still finicky when you have it attached. Maybe not the best candidate for the list, but it's one to be aware of at least.

I don't mean to toot my own horn, but I spent a lot of time getting the above examples working in GBE+ :mrgreen: Hopefully I'll be diving into the HuC-1 and HuC-3 stuff next year since I have everything necessary to emulate IR communications.


Top
 Profile  
 
PostPosted: Mon Jun 25, 2018 6:37 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20250
Location: NE Indiana, USA (NTSC)
At least one user in the GBDev Discord server discourages homebrewers from creating new mappers because they will not work in the big 3 accuracy-focused emulators (BGB, Gambatte, and SameBoy), and therefore developing games for them will be prohibitively difficult even if you have wire-wrapped your own prototype board.

A couple weeks ago, I explained the process through which I led the design of the Action 53 mapper for NES:

  1. Spec, reference implementation of banking function in two different languages, and manual test ROM designed to also work on no mapper
  2. One emulator adds preliminary support
  3. Automated test ROM
  4. Multiple emulators add full support
  5. Someone writes Verilog for a CPLD

In the case of a coding competition for Game Boy that receives 14 entries, this user recommended without detectable sarcasm that shipping a 14-pack of individual cartridges would be preferable to shipping a multicart with a custom mapper loaded onto a CPLD.


Top
 Profile  
 
PostPosted: Mon Jun 25, 2018 7:18 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 662
I had not considered the "needs peripheral to work" category of games outside the Camera, I didn't know the ROMs for those had been dumped. To your list I could add Mario Family, a normal MCB5 cart that works with the Singer Izek sewing machines and doesn't do much without one.

I could also mention other odd peripherals like the GameShark MX, which included a modem in the large cart and had software you could use to read your email, if you had a subscription for the service.

Beware mentioned that the MMM01 games work in his emulator, bgb, just fine if you transpose the first 32KB of data in the No-Intro ROMs to the last 32KB.

If transposing data banks or adding headers doesn't get your blood pumping with enthusiasm, might I suggest automating the process by use of different file name extensions for the obscurer carts. You could do something like this :

.ws - Wisdom Tree Mapper (Uses a 74'377)
.rg - Rocket Games Mapper
.rgc - Rocket Games Color Mapper
.rgm - Rocket Games Multi-cart Mapper
.mmm - MMM01
.m1m - MBC1 Multi-cart
.m1s - MBC1 Sonar
.m30 - MCB30
.man - Mani Discrete (Uses a 74'161)
.sxx - Sachen Mapper xx (unsure how many are needed)

The Analogue Nt Mini does something like this for its Atari 2600 Core because it does not have the capabilities to detect some of the more unusual 2600 mappers and there is no header standard for 2600.

If someone wants to develop a game they wish to put on a cartridge and sell to the public, then a new mapper might be a good idea to prevent casual piracy. But for non-commercial development, just use an MCB5.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Mon Jun 25, 2018 1:32 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20250
Location: NE Indiana, USA (NTSC)
Would "Wisdom Tree" collide with WonderSwan?

Is there a better way to include multiple independent executables in one ROM than a custom mapper?


Top
 Profile  
 
PostPosted: Thu Jun 28, 2018 12:23 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 662
I have added a few more ROMs and made a few corrections. I used an ancient emulator called DreamGBC to assist me. This emulator has a loader program which will show the header information in a convenient format. It helped me catch a few HuC-1 games.

The No-Intro MMM01 dumps may match the physical configuration of the ROM, but not the logical configuration as the cartridge hardware presents it to the Game Boy. On bgb, these games must be fixed by cutting the final 32KB bank and pasting it before the first 32KB bank. Additionally, the Mani games must have their header fixed to indicate the MMM01 instead of the MBC3.

I think .wst could be used for Wisdom Tree games :)

It seemed there were two hardware approaches to doing the official multi-carts without rewriting the program during the GB's lifetime. One approach was to use the MMM01, the other was to use the MCB1M method, which rewires the MCB lines on the PCB so that the RAM Bank acts as game select register. It works so long as no single game is larger than 256KB in size, at least in the way Nintendo implemented it. The MMM01 is a complex extension of the MBC1 which never appeared to be used outside of multicarts.


Attachments:
Unusual & Unlicensed GB & GBC.ods [17.48 KiB]
Downloaded 4 times

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog
Top
 Profile  
 
PostPosted: Thu Jun 28, 2018 12:53 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20250
Location: NE Indiana, USA (NTSC)
Great Hierophant wrote:
It seemed there were two hardware approaches to doing the official multi-carts without rewriting the program during the GB's lifetime. One approach was to use the MMM01, the other was to use the MCB1M method, which rewires the MCB lines on the PCB so that the RAM Bank acts as game select register. It works so long as no single game is larger than 256KB in size, at least in the way Nintendo implemented it.

MBC1M technique becomes wasteful when you want to include compo entries of varying size, such as 16K, 32K, or 64K. Is "ROM Bank #WE/Mask" in MMM01 supposed to control the size of the game?


Top
 Profile  
 
PostPosted: Thu Jun 28, 2018 1:32 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 662
I'm honestly unclear how exactly the mapper works to wall in a game to its own space within the ROM, but masking bits seems to have something to do with it. That MMM01 page is the only page with hard information about the chip, but while the information on that page seems technically more precise than say on gbdev, it is also a lot more obtuse.

In other interesting things, the Mani 4 in 1 (China) (DMG-601 CHN) has no more data in it after the 160KB mark, although I'm quite sure that there is a 256KB ROM inside the cart with padding. It is structured as 32KB for the menu + 4 x 32GB games.

All the Mani games were distributed in China using MBC chips from Nintendo. The boards seem to be manufactured by Mani and are designed to accept bonded ROMs coated with epoxy. Here are some samples :

http://datomatic.no-intro.org/index.php ... =46&n=1545

http://datomatic.no-intro.org/?page=sho ... =46&n=1160

Ironically, the Chinese version of Tetris does not use epoxy ROMs whereas it frequently did elsewhere in the world.

The Mani multicarts do a form of poor man's colorization and some of the Collection multicarts support SGB functions.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Fri Jun 29, 2018 7:02 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 662
Now I think I am clear on how the MMM01 works.

It is clear that the Mask Bits in the MMM01's Mode Register remap the physical location of a game on the cartridge's logic chip to the logical location the game expects itself to be in the GB's memory map. It does this by controlling which address lines will be active. You can individually set whether bits A15-A18 will be enabled or disabled. That allows you to have 15 x 64KB games, 7 x 128KB games, 3 x 256KB games or any combination thereof so long as each game has its exclusive space within the ROM and starts on a 64KB boundary. Then you set the MMM01 to MBC1 mode and turn control over to the game. The MMM01 zero-adjusts the bankswitch writes as well so the game thinks it is the only game on the cartridge and it starts at $0000 within the ROM.

Why 15, 7, & 3 games and not 16, 8, and 4 games? Well, the multicart menu needs to reside somewhere do fiddle with these mask bits and set the appropriate mode for each game. It is physically placed at the end of the cartridge ROM in its last 32KB bank. I believe one of the first things that all known MMM01 carts do when they are booted up is to write to the multiplexer bit in the Mode Register. This switches control from the first 32KB bank to the last 32KB bank by outputting ROM A19-20 to CPU A13-A14. I think this is why an emulator like bgb needs the multicart menu at the beginning of the ROM, it relies on the header value to determine what memory control scheme to emulate and it "sees" the memory controller specified by the first header, namely the header for the first game on the multicart.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Fri Jun 29, 2018 9:59 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7303
Location: Seattle
Great Hierophant wrote:
You can individually set whether bits A15-A18 will be enabled or disabled. That allows you to have 15 x 64KB games, 7 x 128KB games, 3 x 256KB games or any combination thereof so long as each game has its exclusive space within the ROM and starts on a 64KB boundary.
It should allow 32KiB games also...


Top
 Profile  
 
PostPosted: Fri Jun 29, 2018 10:08 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20250
Location: NE Indiana, USA (NTSC)
I think it does: set all four game size bits to 0.

Here's how I understand the MMM01 docs:
Code:
7654 3210  $0000: RAM enable
 ||| ++++- SRAM enable ($A: on; others: off)
 ||+------ 1: Ignore writes to $4000 bit 0 (SRAM A13) (supervisor)
 |+------- 1: Ignore writes to $4000 bit 1 (SRAM A14) (supervisor)
 +-------- 0: Supervisor mode; 1: Ignore supervisor writes and
           "disable the forced ROM Address line masking" (supervisor)

7654 3210  $2000: ROM bank
 ||| ||||
 ||+-++++- Select 16 KiB ROM bank at $4000 (PRG A18-A14)
 ++------- Select 512 KiB outer bank (PRG A20-A19) (supervisor)

7654 3210  $4000: RAM bank
 ||| ||++- Select 8 KiB bank at $A000 (SRAM A14-A13)
 ||| ++--- Select 32 KiB outer bank (SRAM A16-A15) (supervisor)
 |++------ Select 2048 KiB outer bank (PRG A22-A21) (supervisor)
 +-------- 1: Ignore writes to $6000 bit 0 (MBC1 mode) (supervisor)

7654 3210  $6000: Mode
 ||| || +- 0: MBC1 mode 0; 1: MBC1 mode 1
 |++-++--- Game size (0: 32K; 1: 64K; 3: 128K; 7: 256K; 15: 512K)
 |         (supervisor)
 +-------- 0: Normal operation; 1: Swap SRAM A14-A13 and PRG A20-A19

Regs normally written in order $2000, $6000, $4000, $0000.

The big problem is that leaving supervisor mode appears to be one-way, preventing anything like "exit to multicart menu on A+B+Select+Start" or "exit to multicart menu from game's main menu".


Top
 Profile  
 
PostPosted: Fri Jun 29, 2018 10:36 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 759
Reset. It's not a big deal to watch the Nintendo logo.


Top
 Profile  
 
PostPosted: Fri Jun 29, 2018 12:27 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20250
Location: NE Indiana, USA (NTSC)
That's what EverDrive X series does when starting a game or when the player presses the microswitch under the front of the cartridge's chassis: it asserts the reset line in the cartridge to cause the Game Boy CPU to reset. It does this in part to allow switching between Game Boy and Game Boy Color modes. But MMM01 doesn't expose a port to let a program send such a signal.


Top
 Profile  
 
PostPosted: Sat Jun 30, 2018 2:02 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 759
By the user turning the console off and on.


Top
 Profile  
 
PostPosted: Fri Jul 06, 2018 6:47 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 662
Rocket Games single game GBC releases use an MCB1 clone, but it's header needs to be fixed to work with most emulators and flash carts. Designate them as MCB1 (Cartridge Type 01), make sure the ROM and RAM size is correct (never any RAM), restore the Nintendo logo and fix the header checksum.

One curious thing however is that Rocket Games would display "ROCKET®", not "Nintendo®" on the bootup screen. The GBC checks some of these bytes to ensure that your ROM was displaying the correct name. Rocket Games presumably found a way to bypass the check, but when you replace the logo, the games work but now display Nintendo®.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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