MBC controller history
parent
c40d02c230
commit
75a8a3a90f
|
@ -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:
|
||||
|
||||

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

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

|
||||
|
||||

|
||||
|
||||
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 |
Loading…
Reference in New Issue