MBC controller history

This commit is contained in:
Wouter Groeneveld 2023-04-18 20:23:54 +02:00
parent c40d02c230
commit 75a8a3a90f
5 changed files with 59 additions and 0 deletions

View File

@ -0,0 +1,59 @@
---
title: "Historical Usage of Memory Bank Controllers in Game Boy Carts"
date: 2023-04-18T20:20:00+02:00
categories:
- retro
tags:
- gameboy
---
Brendan Byers wrote an in-depth piece on the [exploration of the Game Boy Memory Bank Controller](https://b13rg.github.io/Gameboy-MBC-Analysis/) (MBC), where he used the data from gekkio's [Game Boy hardware database](https://gbhwdb.gekkio.fi/) to plot MBC usage statistics over the GB's lifespan, resulting in the following interesting graph:
![](../MBC_Types_Year.png "Historical usage of MBC chips in GB carts. Source: Brendan Byers, Gekkio.")
Based on the graph, we can establish the following:
- The first three years of the GB's lifespan (1989--1991), some games were released without any MBC chip (e.g. _Tetris_, _Dr. Mario_).
- Subtypes of `MBC1` (red hues) are the most widely used chips, until 1998, which also happens to be the year the Game Boy Color was released.
- After the GBC release, `MBC3` and `MBC5` are the most commonly used chips, which supported more maximum storage (up to `2 MB` ROM/`64 KB` RAM and `8 MB`/`1 MB` respectively) and additional sensors such as the real time clock, light sensor, and rumble motor.
- Quite a few GB(C) games were published during the release year of the Game Boy Advance in 2001!
- Some cartridges come with custom MBC chips such as `TAMA5` for Bandai's Tamagochi 3[^tama3].
[^tama3]: This cart is really cool: [see for yourself](https://gbhwdb.gekkio.fi/cartridges/DMG-AOMJ-0/gekkio-1.html). It does stick out quite a bit and contains an additional microcontroller. I have yet to get my hands on one of these!
But hold on a minute...
## What's a Memory Bank?
Bear in mind that the original 1989 Game Boy was a _very_ simple 8-bit micro computer. Its designers emphasized affordability and usability over sheer power---otherwise there would have been a color display included instead of the four shades of green (and unlit) drab.
As a consequence, the circuit board and CPU are simple as well: each game cart has 32 pins that slides into the GB which directly connects to the GB CPU architecture. This sounds obvious, but nowadays, a hundred tiny hardware layers are stacked in-between board and CPU, hopelessly increasing complexity. In the early nineties, things were still (relatively) simple. Also, since everything is 8 bits, `32 KB` off the game ROM can be loaded directly into memory, which is mapped in the GB memory model as chunks of `16 KB`. This is called a "bank": the first chunk, bank `0` of `16 KB` game instructions data, is hardwired to addresses `0x0000`--`0x3FFF`. Two chunks or banks are available for games, up to address `$8000`. Very simple games that are less than `32 KB`, such as _Tetris_ or _Dr. Mario_, simply map everything from ROM into the GB CPU.
But what if you want bigger games, more sprawling fantasy worlds, more enemy sprites, and more levels? Then two banks or `32 KB` won't likely cut it. Even though the Game Boy CPU can't handle anything more, there's a trick to fool the Game Boy into thinking we're still working with merely two banks, but the second bank can be dynamically pointed to other chunks of `16 KB`. This is literally what a Memory Bank Controller does: it controls which bank the second one points to:
![](../gbmemmapbank.jpg "The MBC can swap in and out portions of 16 KB at $4000.")
That means suddenly, our game ROM isn't limited to `32 KB` but can have _any_ arbitrary size, even a gigabyte if the MBC can handle it! `MBC1` supports `2 MB`, `MBC5` up to `8 MB`, which in practice is the largest a GB(C) game usually can be. This memory chunking/swapping trick can also be applied to the RAM chip. Games that have a lot to save, such as _Pokémon_ or _Zelda_, can extend the GB working memory (WRAM) by chunks of `4 KB`, also depending on the MBC model.
Imagine you're playing _Super Mario Land 2: Six Golden Coins_. One minute you're jumping from branch to branch on your way to defeat a giant bird, the next you're evading pumpkins and broomsticks. Each of those six worlds is vast compared to its predecessor, with beautiful sprite work and quite long levels: certainly bigger than `16 KB` in total. If developers cleverly compact and group assets, they can fit them in banks which get loaded into bank 1 accordingly, as seen in the above schema.
Bank 0, before address `$4000`---the first leftmost light purple block---could for example contain handy routines that are reused throughout each world: jump mechanics, physics logic, scoring systems. These don't need to be swapped in and out by the MBC. Because of the whole memory mapping model from `$0000` to `$FFFF`, programming for the Game Boy in Assembly does mean working with addresses and cramming everything you can in very specific locations.
## Why care about historical usage?
Because this perfectly illustrates the gradual progression and mastery the developers showcased when creating games throughout the Game Boy's lifespan. Again, take the _Mario Land_ franchise as an example. _Super Mario Land_, a 1989 launch title, nowadays is nothing more but a curious relic: it's barely got any levels, challenge, power-ups or even interesting sprite work. When you dump the ROM of _Super Mario Land_ with a tool like GBxCart, you learn that its file size is exactly `64 KB`. It also lacks a RAM chip, meaning no save feature. And yet it used one of the first `MBC1B` chips. Even more interesting, later reprints even changed MBC manufacturer, as can be seen in the GB hardware database entry on [DMG-MLA-1](https://gbhwdb.gekkio.fi/cartridges/DMG-MLA-1/).
_Super Mario Land 2: Six Golden Coins_ and _Super Mario Land 3: Wario Land_ (`512 KB`---eight times as big as the first installment!) increased the complexity of the cartridge PCB. _Wario Land_ used a `MBC1B1` revision and the black _Wario Land II_ cartridge from 1998 used the `MBC5` chip, although some releases use a `MBC3` one. _Wario Land 3_, a Game Boy Color exclusive, is `2 MB`.
Even if we limit ourselves to the monochrome compatible releases, this evolution is clearly visible when either placing screenshots of each game or photos of their PCBs side by side:
![](../warios.png "The evolution of the Mario Land series in screenshots.")
![](../pcbs.jpg "The evolution of the Mario Land series in PCBs and MBCs. Source: gekkio DB.")
The status bar on top of the first installment gradually made room for bigger sprites and more depth in the background. Even coin sprites are interesting to look at: they're actually split in two to fake four color shades as one of the four colors is used as an indicator for transparency---yet another clever way to circumvent the limitations of the hardware, true [constraint based creativity](/post/2021/11/constraint-based-creativity) at work here.
I obviously love the Game Boy system: it's complicated enough to explain the basic concepts of computing architectures, from the instruction set down to the wiring on the PCB, yet as a cart is nothing but a PCB with chips soldered on, it also allowed for a crazy amount of variation, like a gyro sensor (_Kirby's Tilt 'n' Tumble_), real time clock (_Pokémon_), or even in later games a light sensor (_Boktai_).
In that sense, the RAM addition, usage of gradually bigger ROMs, and evolution of MBC chips in the above _Mario Land_ games is just playing it safe.

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 82 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 363 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB