Definition of unlock
transitive verb
3 : to free from restraints or restrictions
// the shock unlocked a flood of tears

Former Dawn aims to be the most extreme example yet of what could be called Neo Vintage — a new game for an old system. This is literally the opposite of the excellent forum site VOGONS (Very Old Games On New Systems). When forming Something Nerdy Studios in early 2019 and launching our first game project, we all felt as though creating an advanced modern RPG that targets the NES would be a really fun and cool thing to do, but that the available memory mappers from the system’s heyday seemed too limiting. We knew quite well that the easiest thing to do would be to give up and make a retro game on the PC instead, but that rubbed us the wrong way. Not only was that already a very crowded market by 2019, it wasn’t good enough merely to create an NES-like game that could never actually work on a real NES. We wanted to find out how far we could go on the real thing!

At first, it seemed like either MMC3 or MMC5 would be our best bet, despite the nagging feeling that something much better could be crafted if we just had the know-how and manufacturing connections. It seemed to us that there was vast untapped potential in the NES, and that providing it with gobs of ROM is the primary way to tap it. Although SNK pioneered very large ROM sizes in the early 90s via the Neo·Geo, both that system and the games for it were exceedingly expensive because of mask ROM prices at the time. What if there had been a more economical solution back then? Specifically, what if the NES had enjoyed CD-ROM games that would’ve continued its lifespan and taken a bite out of the TurboGrafx-CD, Sega CD, and 3DO? Try to imagine what modern PC gaming would be like if you only had 1 meg to play with; would anyone even take it seriously? Sure, a lot could still be done in 1 meg but it would be nowhere near enough space for the features that modern gamers expect in new games — even indie games. Similarly, there’s no good reason to think that the same is not true of the NES.

In addition to space requirements, there are many pieces of low hanging fruit that almost no classical NES games plucked. For instance, did you know that glitchless diagonal scrolling (using 4 “nametables”) was baked into the hardware design of the NES from the very beginning? Despite Super Mario Bros. 3 using the MMC3 memory mapper, Nintendo opted not to include the tiny amount of extra RAM on the cartridge necessary to unlock MMC3’s scrolling enhancement, which is why the obnoxious graphical glitches appear at the right side of the screen during gameplay. That sort of thing felt inexcusable to us, so to get our feet wet, we implemented glitchless and perfectly smooth 8-way scrolling in an MMC3 “walking simulator” game demo. As far as we know, this had only been accomplished on the NES (read: not Famicom) in 1 title — Tengen’s Gauntlet (which is technically a simpler predecessor to MMC3) . And even in that game there were only 4 screens per level, which is the easy way to do it. Our proof of concept sported a 16-screen level with lots of complex graphics, with the ability to add even more screens. This was a much harder feat, but more importantly, much more conducive to something like a sprawling RPG.

Thus emboldened but still lacking the ability to create our own mapper, we pushed forward with inventing as many new tricks as we possibly could — what were called “novelties” around the office. We ended up creating quite a few of these…so many that it really did seem like the ROM space constraints of MMC3 would’ve prevented us from fully exploiting them. MMC5 allowed for a little more space than MMC3 (about double), but lacked MMC3’s quad nametable feature. MMC5 also sported 8×8 attributes (I.e., denser coloration of the screen than the NES’s stock 16×16 attributes allow), but the feature is hardwired to only use a single nametable. Thus 8×8 is so broken in MMC5 that it doesn’t work correctly with hardware scrolling. This whole classical mapper situation was a mess, and in any case, no existing memory mapper for the NES allowed anywhere near enough space to facilitate expansive games full of advanced level design, rich soundtracks and sound effects, high frame rate sprite animations, intricate background animations, or SNES/PlayStation JRPG quantities of dialogue…let alone something as crazy as FMV.

It was at that time that we had the good fortune of meeting Paul Molloy from Infinite NES Lives. We told him of our ambitions and he in turn told us that he had designed a new type of FPGA-based NES cartridge that would probably serve our needs. At the time, he needed to work out some issues with it and partially redesign the PCB, but there was enough functionality there to tell us that we had our path forward. The main problem was, the hardware wasn’t enough; at least one of us had to learn Verilog in order to implement our mapper on that hardware. But in turn, before specifying the mapper in Verilog we had to know what to specify!

Up until that point, I had cheekily called my fantasy mapper “The Gigamapper”, because it would, at a minimum, supply the NES’s CPU and PPU access to a gigabyte of ROM. (We also toyed with only giving it a gigabit of ROM, to be in line with NES and SNES ROM size nomenclature.) This base requirement now seemed almost trivial, and it was quickly apparent that we could do many, many things with a cartridge like this that had heretofore been impossible. But we definitely did not want to “cheat” in the way that Doom-on-the-Raspberry-Pi-on-the-NES does. Something undeniably anachronistic like that lay very far from our interests. In other words, the NES needed something new that could have been something old, but never was. What then, to do?

= Guiding Principles =

We decided that since 1994 marked the end of the NES’s original lifespan, we had to create an expansion system that would’ve been plausible in 1994 — technologically and economically. This is the base principle from which the rest of our mapper design philosophy flows. At the same time, we chose not to do absolutely everything that was possible in 1994. This is in part because we wanted to know what the NES was capable of “on its own” in the very specific sense that it still does all the computations that are ends unto themselves. Essentially, this means that something akin to a CD-ROM expansion is perfectly fine, but that a 3D accelerator or math co-processor is not.

In addition, video compression algorithms like MPEG were suspicious at best, and we’d prefer to avoid them. Although MPEG-2 was out by 1994, it was intended for display resolutions, palette freedoms, and color depths that are not possible on the NES. Because of this, in order to use it at all we’d have to implement additional conversion logic in hardware, which would probably violate the economics requirement mentioned above(even more than adding an MPEG decoder to the BOM would do already). It would probably also result in terrible image quality compared to whatever bespoke algorithms we came up with.

We interrogated these principles and after much debate around the office and with other people in the broader NES development community, we arrived at these conclusions. For ease of reading and contrast, they are split between dos and don’ts.

= Conclusions =

Technical jargon is pretty much unavoidable when discussing a topic like this, so here it is. Anyone who doesn’t care about these details is welcomed to skip below to where I will graphically demonstrate what these features unlock in NES game development.

Allowed:

1. Direct access to as much data as could be stored on just over 1 CD-ROM. (768MiB)
2. Indirect access to as much data as could be stored on 4 CD-ROMs. (2.8GiB)
3. Direct access to up to 1 MiB of RAM.
4. Interposing the PPU’s data fetches in order to alleviate onerous limitations:
   1. 256 unique tiles per screen -> 960 unique tiles per screen.
   2. 2 nametables -> 4 nametables.
   3. 16×16 attributes -> 8×8 and/or 8×1 attributes.
5. Automatic bank switching that facilitates items 4.1 and 4.3.
6. Nametable bankswitching, allowing high performance background animations composed with other mapper features.
7. Attribute bankswitching that facilitates item 4.3.
8. Multiple fine-grained CHR banks. (16 banks of 512 bytes apiece)
9. Multiple medium-grained PRG banks. (4 banks of 8KiB apiece)
10. Error correction or “de-glitching” features, merely to correct behavior that amounts to bugs in the NES’s hardware design.
11. Scanline counter. (Better than MMC3’s, in that it works correctly with all other features of the mapper.)
12. DPCM sample size expansion. (4081 bytes -> 16MiB)
13. Audio synthesis chip [emulation] (YM2608, YM2610, YM2612, etc) for expansion audio purposes.
14. Dual-port ROM and RAM.

Disallowed:

1. Offloading general purpose calculations. (I.e., no CPU, FPU, or any other kind of co-processor on the cartridge.)
2. Offloading graphical processing. (So nothing like Super FX, SA-1, etc.)
3. PCM audio streaming via expansion audio.
4. Exceeding the computational power or complexity of the NES itself.
5. Exceeding the circuit complexity of MMC5, which was the most complicated classical memory mapper for the NES.
6. Re-implementing the PPU for any reason whatsoever.
7. Physical form factor any larger than a traditional Game Pak. (I.e., the game cartridge has to fit properly in a frontloader NES.)
8. Transferring data from SD card into cartridge RAM at data rate that exceeds that of a quad speed CD-ROM drive. (600KiB/s)

Our memory mapper began life as C++ code inserted into our local fork of Mesen, and only implemented feature 1. All of the other features except for 2, 13 and 14 eventually became implemented together in a single package which we call the Memory eXpansion Module 0, or MXM-0. Taking MXM-0 and combining it with stubs for 2 and 13 is what we call MXM-1. You’ll notice that feature 14 is left out of both; that is because INL is supplying that feature on the cartridge for us. It is therefore not actually part of our mapper(s). Feature 13 is also merely stubbed, because we are creating three different types of cartridges for Former Dawn — one with a genuine Yamaha YM2610 ASIC inside, one with simulated YM2610 audio synthesis coinhabiting the FPGA that implements MXM-1, and one without expansion audio entirely.

MXM-0 and MXM-1 are both now implemented in Verilog as well, with almost all features fully usable and complete. Like all of the classical memory mappers for the NES, ours run beautifully on the EverDrive N8 Pro. Very soon we will adapt MXM-1 to our prototype cartridges from INL. In other words, this mapper is real. It is not a theoretical construct! Any one of you with a genuine hardware NES (frontloader or toploader) could insert one of our N8 Pro dev cartridges and run the current build of Former Dawn right now. Compatibility with NES clones varies, but is quite good; more on that later.

= Explanation (Allowed) =

In order to understand our motivations for implementing each of the Allowed features, each one needs to be described in some detail along with visual examples if possible. In such cases, the image on the left will be an NES game suffering classical restrictions, and the image on the right will be something that is made possible by MXM — preferably from Former Dawn.

1. Direct access to as much data as could be stored on just over 1 CD-ROM. (768MiB)

When we began implementing what became known as MXM-0, we thought that Former Dawn was going to be stored entirely in NOR flash on the new INL board. (Since mask ROM production incurs prohibitive fixed costs, this is what everyone else in the modern NES “homebrew” scene is doing.) Because of various uncertainties in chip supplies and technical difficulties, we opted to take INL’s offer to include an SD card on the cartridge as well. As it turns out, we think that the fast-access part of the game can quite comfortably be stored in 16MiB of (NOR flash) ROM. If we had known at the very beginning that we were going to go the SD card route, we might not have facilitated direct access to 768MiB of ROM in MXM-0. But we did, and now we see no reason to remove it — especially because anyone who uses MXM-0 in the future might want to create a Neo·Geo style cartridge for the NES with a massive amount of ROM in chip form instead of SD card form. Why not? In either case, the basic point is that having so much ROM means that one can now spend that ROM liberally in order to upgrade the quantity and the quality of pretty much any aspect of an NES game you can think of of.

2. Indirect access to as much data as could be stored on 4 CD-ROMs. (2.8GiB)

Because of the fact that we’re basing Former Dawn‘s cartridge specs and memory footprint off of a classical CD-ROM console or console add-on, it made sense to base our ROM limits on actual examples of CD-ROM games from the early 90s. Most CD-ROM games used only 1 disc, but a few of them used more, even early on. Night Trap, released in 1992 for the 3DO and Sega CD came on 2 discs. In late 1994, Slam City with Scottie Pippen was released for the Sega CD and contained 4 discs — and this may be the record by 1994. So we’re setting our max ROM size to 4 CD-ROMs, or 2.8GiB. Whether or not we will come anywhere close to that depends on how much FMV we end up including in the game. No other assets would push the ROM footprint past 1 disc’s worth. Even if the OST were 2 hours long and we stored it as raw 7-bit 33.1KHz mono PCM, we would only need 239MiB. Before MXM-0, ROM sizes and more primitive memory mappers meant FMV on the NES was never achieved with full frame rate at full screen.

3. Direct access to up to 1 MiB of RAM.

In order to justify the decision to include 1MiB of RAM in this expansion system, there are 3 relevant questions: A) Can this amount of RAM reasonably be used by a 6502-based CPU? B) Would it have been economical in late 1994 to do so? C) WHY?

A) Yes. The Apple //e supported up to 1MiB of RAM. All it takes is carefully managed bankswitching and/or serial loading.
B) Technically, we are using 1MiB of static RAM, which would not have been economical in 1994. But this is because it’s more economical for us to use SRAM than DRAM in 2021. Using dynamic RAM would imply having to have some sort of memory controller on the cartridge, which would cost significant money and engineering time, not to mention possibly exceeding our available electrical power. However, consider that the original PlayStation was released in late 1994 and it had over 3MiB of RAM onboard.
C) Why? Because we need it. Classical cartridge games on the NES often had 8KiB of RAM onboard, and some had up to 32KiB. The reas