The Secret Chips Inside Nintendo Cartridges

0:14Super Mario Bros. 3 runs on the same NES as the original, with nearly ten times as much game data. So what was the extra chip inside its cartridge actually doing? Look just above Mario 3's scoreboard. That single blue line is a clue to something happening inside the cartridge while the picture is being drawn.

0:42And in the Japanese version of Castlevania Three, part of what you're hearing isn't being made by the console at all.

0:53By the end, you'll understand what these chips added to the NES and Famicom, and how each console shared the work with its cartridge.

1:05There are two different conversations going through that slot. The CPU, the main processor, reads the game's instructions and data. The PPU, the picture processing unit, fetches the information it needs to draw the screen. An address is how a chip asks for a particular byte. The CPU and PPU have separate memory connections, so a graphics address isn't an address in the CPU's memory. Put the address on a set of wires, and the memory sends the byte back on another set. Those groups of wires are buses. The important question is what memory answers when a particular address appears.

1:51With the original Super Mario Bros., that answer stays put. ROM is read-only memory, where the cartridge stores the program and graphics. The CPU's cartridge window is the range of addresses through which it can see 32K of program ROM. The PPU has its own window onto 8K of graphics ROM. Both fit exactly. This cartridge arrangement is called NROM, and it has no controls for bringing another section into view.

2:26Mario 3's mapper chip, the MMC3, changes that answer. The CPU can ask for the same address twice and receive bytes from different parts of a much larger ROM. Each 8K section is called a bank. Nothing has widened the CPU's memory window. The cartridge has changed what's behind it. Choosing a different bank is bank switching.

2:59Nintendo explained this to its readers in Nintendo Power, in January nineteen ninety-one: "Because the NES was designed so that the latest technology could be used in each new generation of Game Paks. It's like an RC car. When a faster motor comes out, you buy one and slap it in your old racer. That's how games can get bigger and better while your Control Deck stays the same." It's a lovely way to explain why you didn't need another console. The part worth checking is what, exactly, got a faster motor.

3:39The connector gave a cartridge rather more access than a box of stored instructions might suggest. It carries the CPU's address and data signals, and the PPU's separate memory signals. There's also an interrupt request connection, which lets cartridge hardware call for the CPU's attention. We'll come back to that wire. First, keep these two maps separate. The CPU's map includes working memory and the controls for other hardware. Its usual cartridge-ROM window occupies the top 32K. The PPU has its own 16K address space, with 8K devoted to graphics patterns. Those patterns are the little drawings used to build backgrounds and sprites, the separately positioned objects in the picture. Mario 3 holds 256K of program ROM behind the CPU's window, and 128K of graphics ROM behind the PPU's. They don't all have to be visible together. The game chooses the program sections it needs, and the patterns the picture chip needs, then changes those choices as it runs.

4:57The MMC3 divides that program window into four 8K banks. The lower address bits choose a byte within a bank. The mapper supplies six higher address bits to the ROM, choosing which bank answers. So what looks like a different page of memory is, electrically, a different choice on the ROM's address wires. Some banks stay fixed. The very last bank always stays available at the top of the CPU's memory. That gives the game a dependable place for code that must remain reachable. The graphics side has its own choices, in smaller sections. Switching program memory doesn't automatically switch the PPU's patterns.

5:46The game controls this by writing to addresses that also belong to the program ROM. That sounds unhelpful. ROM is read-only memory. But the cartridge can distinguish a read from a write. A read gets a byte from the ROM. A write reaches the mapper's controls instead. It doesn't rewrite the game. Those controls are registers, small pieces of storage inside the chip. On the MMC3 they're write-only. For this bank change, one CPU write chooses R6, the register that holds the bank number for this 8K program window. A second write supplies the bank number. The chip now connects that ROM bank to the window. The next read from the window comes from the newly selected bank.

6:41Other mappers used different controls. This is the MMC1 on a Tetris cartridge. To save chip pins, it receives a register value one bit at a time. Five CPU writes to deliver five bits. The programmer had to do a little more talking so the chip could have fewer legs.

7:09We've written a small NES program that makes the change visible. Six banks contain six different messages, all at the same CPU address. Every two seconds, it selects the next bank and reads the message it finds there. These instructions choose the bank. The read that follows still asks for the same address. Watch the address stay put while the text changes.

7:45That message is quite literal. The CPU doesn't receive a note saying that a different bank has arrived. It reads the address and gets the byte the cartridge supplies. The software has to know which bank it selected.

8:04Mario 3 does this far more often than once when a level loads. In World One, level one, it switches program banks about twenty times per frame. In six seconds of play, it selects eight different program banks out of its thirty-two. The cartridge is being rearranged throughout the action. Nintendo Power compared bank switching to adding pages to a storybook, then opening the page you need. That's a good starting point. But these pages can change many times before the next television picture has finished. The cartridge can even change what the PPU sees partway down that picture.

8:53The original Super Mario Bros. already changes its picture partway down. The PPU draws it one line at a time, and one scroll setting applies to the lines being drawn. To keep the score still at the top while the level scrolls underneath, the game has to change that setting where the bar ends. Its cartridge has no mapper controls or interrupt timer. In the title screen and World One, level one, it doesn't write to cartridge space at all. The first sprite in the PPU's sprite memory is sprite zero. Super Mario Bros. places it at the edge where the bar ends, so an opaque part of the sprite overlaps an opaque background pixel. When that overlap happens, the PPU sets the sprite-zero hit flag in its status register. Every frame, Super Mario Bros. waits for that flag before changing the scrolling. The CPU reads the status, tests the flag bit and, while it remains clear, reads it again. Those three instructions are the wait. Watch how much of the frame they occupy.

10:09We're following the North American NES, with NTSC television timing. The wait uses about six per cent of every frame. That's roughly two hundred checks and eighteen hundred CPU cycles. Once the marker appears, the game waits until that line's visible pixels have finished. In that gap, it sets the scrolling for the playfield below. That's a split screen without a cartridge timer. The cost is that the CPU has to keep asking. It can't carry on with another part of the game while it's executing that loop.

10:50Mario 3 lets the cartridge do the watching. Its bar stays still at the bottom while the level moves above it. Nintendo Power described the scoreboard as "a second screen", made possible by a timer built into the MMC3. It's still one picture from the same PPU. The settings change before the bar is drawn.

11:17But the cartridge needs a signal that tells it how far the picture has got. There's no wire from the television saying that the beam has reached the scoreboard.

11:32That's the blue line from the opening, just above the bar. There's a sliver of the sky's light blue between the ground and the black panel. It's only one line high. That little gap is part of what the game does when the cartridge calls for its attention.

11:54The MMC3 doesn't watch the television. It watches the PPU asking for memory. Those requests have a rhythm, and the cartridge can turn that rhythm into a count. The PPU builds the picture one line at a time. On an NTSC machine, each line lasts three hundred and forty-one PPU clock ticks. When those ticks are counted across a line, they're called dots. After one idle dot, the next two hundred and fifty-six produce the visible pixels. The remaining dots include the fetches that prepare sprites for the next line.

12:38On this line of Mario 3, the background patterns come from the lower half of the PPU's pattern memory. After the visible section, the PPU fetches sprite patterns for the next line. Those reads come from the upper half. That difference gives the mapper something electrical to recognise.

13:03One address wire, called A twelve, is low for patterns in the lower half and high for patterns in the upper half. The MMC3 watches that wire. After the long run of background fetches, the move to sprite-pattern reads produces the rise it can count. Mario 3 uses eight-by-sixteen-pixel sprites. Here, on line a hundred and ninety, there aren't any visible sprites at all. The PPU fetches sprite patterns anyway. For each empty slot, it fetches tile F F from the upper pattern table. The mapper gets its timing signal from drawings that won't appear.

13:52During the sprite fetches, raw A twelve rises eight times, first at dot two hundred and sixty-one and then every eight dots. The filter accepts another rise only after A twelve has stayed low across three falling edges of M2. M2 is the CPU clock signal carried to the cartridge, and one CPU cycle lasts three dots. Three falling edges therefore take longer than the four-dot low gaps before the later rises, so the MMC3 rejects them. Only the first rise follows the long low stretch of the background fetches. So the counter gets one qualifying rise per line, at dot two hundred and sixty-one, just after the line's two hundred and fifty-six visible dots.

14:49The name scanline counter describes what it's useful for. Electrically, it counts qualified rises on an address wire. Put the pattern reads in the wrong places and you don't get the same timing. Even a CPU write that changes the PPU's address can clock it. The chip knows the memory traffic, not the position of the television beam. Before drawing each frame, Mario 3 writes a reload value of a hundred and ninety-two, asks for a reload and enables the interrupt. The pre-render line, just before visible line zero, makes the same kind of qualifying rise as an ordinary line. That rise loads the counter with a hundred and ninety-two. Each following line's rise subtracts one. When the count reaches zero, the MMC3 pulls the interrupt request wire low. An interrupt is a request for the CPU to leave its usual work and run a particular routine after it finishes its current instruction.

15:56The CPU can't read this counter to find out how many lines are left. It can't set the running count directly either. It supplies the reload value and asks for a reload. The cartridge handles the countdown.

16:17The rise on line a hundred and ninety-one reaches zero. In this frame, the CPU finishes its current instruction at about dot two hundred and sixty-four, takes the interrupt, and is running the handler by dot two hundred and eighty-five. The reload value is a count, not a line number. Bank switching and this timer are separate jobs. What Mario 3 needs now is the signal that says it's time for the CPU to change the picture.

16:52Once the CPU finishes its current instruction, it answers the request. The CPU responds by running a routine in the game called an interrupt handler. The MMC3 hasn't drawn a scoreboard. It's brought the game to the code that will arrange one. The handler takes time. It saves the CPU's registers, then prepares the change. Early on line a hundred and ninety-three, it switches background and sprite rendering off. It then moves the PPU's reading position to the start of the status bar. It changes six graphics windows. Two receive the bar's background patterns, while four sprite windows all point to the same 1K bank of zero bytes. That keeps sprites out of the bar. It switches rendering back on near the end of the line, then finishes the scrolling setup early on the next line. Finally, a write acknowledges the pending request and disables further MMC3 interrupts until the game enables them again.

18:04While rendering is off, the PPU outputs the backdrop colour. In World One, level one, that's the sky's light blue. So the little line above the scoreboard is the visible trace of the game changing its display.

18:23The PPU still makes the pixels. The CPU still runs the handler. The cartridge supplies the timing and the choice of graphics. From the accepted interrupt to its acknowledgement, the handler's work spans about two and a half scanlines. Rendering itself is off for almost all of one line, and that is the line that appears as the thin blue seam.

18:52Our little program uses the same division of labour. The stripes scroll above, and the text stays still below. Its cartridge interrupts the CPU on line a hundred and fifty-nine. The handler selects the font's graphics and resets the horizontal scroll for the lower section. Holding A disables that interrupt. Watch the text when the CPU stops getting its cue.

19:27The text hasn't been erased. The PPU is still scrolling, and it's reading its tile numbers against the stripes' graphics bank. Without the handler's changes, it makes exactly the wrong picture from the information it's been given.

19:45The MMC3 has no sound generator. Konami's VRC six does. As well as mapping memory, it contains three extra sound channels. These aren't recordings of instruments stored in the cartridge. They're circuits making waveforms alongside the console's own sound hardware. We've written a tune for those two sets of hardware to play together. A channel is one circuit's musical voice. The names match the traces on screen: a pulse has flat high and low sections, the triangle is pointed, the noise trace is irregular, and the sawtooth climbs before it drops. The upper lamps belong to the console and the lower lamps to the cartridge. The tune begins with the console's triangle and noise, then adds its two pulses. Watch the cartridge group as the last three voices arrive.

21:15Those last three voices all belong to the VRC six: two pulses and a sawtooth. The console's sound generator is inside the same chip as its CPU. It has five channels of its own: two pulses, a triangle, noise, and a channel for samples. Our tune leaves the sample channel unused.

21:45The narrow pulse you heard spends only a short part of each cycle high. The wider one stays high for longer. That proportion is the duty cycle, and changing it changes the tone. The VRC six offers eight duty settings, compared with four on the console's own pulse channels. The VRC six's pulses divide each cycle into sixteen steps. At the narrowest setting, the output is high for one step. At the widest normal setting, it's high for eight. The pitch sets how quickly the cycle repeats. The duty setting changes the shape within that cycle.

22:33The sawtooth begins with the shape you saw and heard: a rising staircase, then a drop. Inside the chip, an accumulator is a small register that keeps a running total. The chip adds the same rate value six times. A larger value makes each step taller, so the staircase climbs higher before the reset, changing its level rather than its pitch. On the seventh step it resets the total to zero. The circuit takes the channel's output level from that running total. Those repeated additions and the reset make the staircase. The chip combines that output with its two pulses and turns the result into an electrical audio signal. Now the cartridge has something quite different to send back: sound, not memory data.

23:36For the Japanese Famicom, there was a route for that signal. Its sixty-pin cartridge connection carries the console's own audio into the cartridge on pin forty-five. Pin forty-six takes audio back towards the console's output. A cartridge with extra sound hardware mixes its voices with the incoming console sound and sends the combination back. The CPU tells the VRC six what to play by writing its sound controls. But the resulting waveform takes an audio connection, not the data bus. Telling a chip to play a note and hearing that note are two different electrical jobs.

24:24The NES has a larger, seventy-two-pin cartridge connector. But it doesn't have that Famicom audio loop. More contacts didn't mean every old connection survived. On an NES as sold, there isn't an equivalent cartridge audio return carrying those extra voices into the sound output. The front-loading NES does have expansion connections running between its cartridge slot and a port underneath the console. That port sits behind a plastic tab you have to cut or break away. No officially released consumer device used those cartridge expansion pins. A rather well-protected opportunity.

25:11Those connections matter because a modified NES can be arranged to hear cartridge audio. Modern devices often use an expansion contact called E X P six. That doesn't give an unmodified NES the Famicom's built-in route, and it doesn't make a game start playing channels its software never uses.

25:41This is Akumajou Densetsu, the Japanese version of Castlevania Three. Its cartridge uses the VRC six. For the comparison, follow the bass, the low line underneath the rest of the music. Hear it once in the Japanese version, then in the American release on the NES.

26:17Both cartridges hold 384K. The American one uses Nintendo's MMC five instead of Konami's VRC six. Why the chip changed isn't documented. And the Japanese soundtrack isn't the American arrangement with three extra channels placed on top. Even the job of playing the bass moves from one chip to another. In the Japanese Stage One music, the bass comes from the cartridge's sawtooth. Listen to that part on its own.

26:57The VRC six's two pulse channels play in the middle and upper range, mostly above the console's two pulses. The console's triangle stays silent throughout this stage's music. Eight available channels didn't mean the arrangement had to use all eight. In the American version, the console's triangle takes the bass instead.

27:28That's the difference between a hardware limit and an arrangement. The stock NES can't hear those cartridge voices. But the Japanese version's decision to leave its triangle silent is a musical choice, not something the VRC six forces it to do. Both versions also use the console's sample channel to play the same drum part about as often. The American version uses shorter samples, so its drum sounds occupy less time even though the hits still arrive at much the same points. That's another change in the arrangement, not a missing cartridge channel.

28:09The American cartridge carries sound hardware too. The MMC five has two pulse channels and a sample channel of its own. Across the title, the prologue and the opening of Stage One, Castlevania Three writes to those sound controls once. At start-up it sets the MMC5's sample control to zero. No write programs either of the MMC5's pulse channels, and no later write asks the MMC5's sample channel to play. All three stay silent.

28:46An MMC five board can send audio on an expansion contact if the required components are fitted. But in this sequence, there's nothing to send.

29:02The MMC five was more than sound hardware. It also offered an eight-bit by eight-bit multiplier. Its extended-colour mode let each eight-by-eight-pixel background tile choose one of the small sets of colours held in the PPU's palette table. Nintendo Power credited those finer colour areas to games like Castlevania Three. In the title, the prologue and the opening of Stage One, the game neither enables that mode nor writes to the multiplier. The hardware reference identifies Just Breed, Yakuman Tengoku and the Koei games as continuous users of the colour feature. A cartridge's list of features tells you what a programmer could use. The game tells you which of them actually mattered on the screen, or at the speaker.

29:55Nintendo Power's faster motor is a useful image, up to a point. The system really could do more when you fitted a different cartridge. But the CPU and PPU stayed inside the console, doing the same jobs. The cartridge didn't replace them or make them run faster. That palette table stays inside the PPU. A mapper can't bank in a replacement for it. The ingenuity was in working through the connections that were there, and knowing where their limits were. The nearest thing here to a faster motor is taking a job off the CPU. Super Mario Bros. keeps asking whether the picture has reached its marker. Mario 3's cartridge does the watching and calls the CPU when it's needed. That isn't a faster processor, and its handler still takes time. Nintendo Power also said a customised module in the MMC five freed the Control Deck's CPU from some repetitive functions, such as running an internal clock. It didn't identify which circuit did that. The separate multiplier we met earlier is another job cartridge hardware could do beside the CPU, not evidence that the processor itself became faster. Adding a helper could make the whole system more capable without changing the processor.

31:24If you'd like to look inside our two demonstration programs, their source is linked in the description. Both depend on the console keeping its side of the bargain. Mario 3 needs those memory connections and that interrupt wire. The VRC six needs an audio route. The unchanged Control Deck is both the trick and the limit. So I'd keep Nintendo Power's last sentence, "while your Control Deck stays the same", and retire its motor. The machine grew through the cartridge slot. The CPU and PPU stayed put.

32:03For more stories from inside the machines, subscribe to Retro Computer TV.