diff --git a/content/post/2023/04/historical-usage-of-memory-bank-controllers-in-game-boy-carts.md b/content/post/2023/04/historical-usage-of-memory-bank-controllers-in-game-boy-carts.md
new file mode 100644
index 00000000..c6de8caf
--- /dev/null
+++ b/content/post/2023/04/historical-usage-of-memory-bank-controllers-in-game-boy-carts.md
@@ -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.
+
diff --git a/static/post/2023/04/MBC_Types_Year.png b/static/post/2023/04/MBC_Types_Year.png
new file mode 100644
index 00000000..ea7a321d
Binary files /dev/null and b/static/post/2023/04/MBC_Types_Year.png differ
diff --git a/static/post/2023/04/gbmemmapbank.jpg b/static/post/2023/04/gbmemmapbank.jpg
new file mode 100644
index 00000000..884a5114
Binary files /dev/null and b/static/post/2023/04/gbmemmapbank.jpg differ
diff --git a/static/post/2023/04/pcbs.jpg b/static/post/2023/04/pcbs.jpg
new file mode 100644
index 00000000..0e732857
Binary files /dev/null and b/static/post/2023/04/pcbs.jpg differ
diff --git a/static/post/2023/04/warios.png b/static/post/2023/04/warios.png
new file mode 100644
index 00000000..966c7518
Binary files /dev/null and b/static/post/2023/04/warios.png differ