Super Nintendo / Famicom Architecture

A practical analysis by Rodrigo Copetti

Classic edition - Last updated: May 19, 2025

Languages available: 🇬🇧 - English, 🇪🇸 - Español, 🇧🇷 - Português (Brasil), 🇨🇳 - 简体字, 👋 - Add translation


About this edition

The ‘classic’ edition is an alternative version to the ‘modern’ counterpart. It doesn’t require Javascript, state-of-the-art CSS or convoluted HTML to work, which makes it ideal for readers who use accessibility tools or legacy internet browsers. On the other hand, paper/eBook users can now check the book editions.

This edition is identical content-wise. However, interactive widgets have been simplified to work with pure HTML, though these will offer an link to the original article in case the reader wants to try the ‘full version’.

As always, this article is available on Github to enable readers to report mistakes or propose changes. There’s also a supporting reading list available to help understand the series. The author also accepts donations and translations to help improve the quality of current articles and upcoming ones.


Table of Contents

  1. Supporting imagery
  2. A quick introduction
    1. Models and revisions
  3. CPU
    1. Modernising the 6502
    2. The new CPU
    3. Ricoh’s additions
      1. Speedy memory access
      2. The 16-bit Segmentation Fault
    4. (Lots of) more memory
  4. Graphics
    1. Design
      1. The chipset
      2. Display modalities
    2. Organising the content
    3. Constructing the frame
      1. Tiles
      2. Background
      3. Modes
      4. Sprites
      5. Result
    4. That feature
      1. Generous circuits
    5. More colour magic
    6. Cause of frame drops
    7. A convenient video out
  5. Audio
    1. Architecture
    2. Pitch control
    3. Evolution from the NES
    4. Advanced usage
    5. Stereo confusion
  6. Games
    1. Cartridge configuration
      1. Beyond convention
  7. Anti-piracy / Region Lock
  8. That’s all folks
  9. Copyright and permissions
  10. Sources / Keep Reading
  11. Contributing
  12. Changelog

Supporting imagery

Model

International
The Super Nintendo (in Europe) or Super Famicom (in Japan).
Released on 21/11/1990 in Japan and 11/04/1992 in Europe.
American
The Super Nintendo.
Released on 13/08/1991 in America.

Motherboard

Motherboard
Motherboard
Showing revision 'SNS-RGB-CPU-01'.
Earlier revisions had the Sound Subsystem connected as a daughterboard, later ones unified both PPUs.
Motherboard
Motherboard with important parts labelled

Diagram

Diagram
Main architecture diagram
Bus 'A' and 'B' are address buses, the data bus follows the trail of bus 'B' and it's 8 bits wide.

A quick introduction

It seems Nintendo managed to deliver the next generation of graphics and sound without using expensive off-the-shelf components. But there’s a catch: the new console was also designed with expandability in mind. In a world where CPUs are evolving faster than the speed of light, Nintendo ultimately relied on game cartridges to make its console shine.

Models and revisions

Kids across the globe saw this console in various shapes, colours, and names. Nevertheless, the internal differences were less noticeable. As you may already know, due to the spread of analogue standards, models from different regions exhibit variations in their analogue signals (e.g., video output) to accommodate these differing standards. Compared to its predecessor, however, the architectural differences are less pronounced. For instance, on this occasion, Nintendo did not include exclusive circuitry for audio expansion, which significantly impacted the quality of games across regions.

The company did ship hardware revisions during its lifespan, but their main purpose was to reduce the number of dedicated components on the motherboard, thereby lowering manufacturing cost.


CPU

The Super Nintendo’s choice of processor is a peculiar one. Unlike its competition bundling a fully-fledged 68000, the SNES’ chip is not a radical departure from its predecessor. To recap, the NES employed a modified 6502 CPU, an admired ingredient of late-70s and early-80s computers. Now, to pave the way for the new decade (the 90s), Nintendo opted for a more conservative (and cheaper) solution: the WDC 65C816, a 16-bit extension of the 6502.

Modernising the 6502

The 65C816 CPU originates from Western Design Center (WDC), particularly from Bill Mensch, a former member of the 6502 team (at MOS) and the 6800 team (at Motorola). In 1978, one year after leaving MOS, Mensch founded Western Design Center, a semiconductor company that produces clones of the MOS 6502 with attractive enhancements (e.g., CMOS design, extra opcodes, circuitry fixes, new addressing modes, etc.).

Image
The WDC 65C816 chip found on the Apple IIGS.

One day, Apple approached WDC to design a backwards-compatible variant of the 6502 that could process larger amounts of data. This resulted in the WDC 65C816 CPU, released in 1983. Curiously enough, Apple encountered many setbacks during the development of a computer that would use the new CPU, until three years later, with the release of the Apple IIGS.

Image
In the end, the Apple IIGS and the Super Nintendo became the only major adopters of the 65C816 CPU.

Meanwhile, Nintendo was enjoying a good relationship with Ricoh and their set of bespoke chips for the NES. I haven’t found the exact document outlining what connected Ricoh to WDC, but what I can confirm is that at some point in time, WDC agreed to license their 65C816 designs to Ricoh [1]. Consequently, the latter tailored it to meet the new requirements of the Super Nintendo, it became the Ricoh 5A22 and was exclusively supplied to Nintendo.

The new CPU

As you’ve seen before, the main processor of this console is the Ricoh 5A22, a superset of the 65C816.

Image
The Ricoh 5A22 chip, labelled ‘S-CPU’ by Nintendo.

Unlike the Apple IIGS, which enjoyed backward compatibility with Apple II software, the Super Nintendo is not compatible with NES games. To be fair, based on the choice of processor, there’s a slight possibility that the SNES was originally planned to be compatible with NES games, who knows.

Moving on, the CPU employs a variable clock speed, reaching up to 3.58 MHz for register operations and dropping to 1.79 MHz when accessing the slowest buses (i.e. the serial/controller port).

Now, to properly understand the functionality of the 5A22, we must first look at what the 65C816 provides:

Looking at this, I have to confess that the 65C816 feels excessively cumbersome for little gain. Compared to other offerings such as the Motorola 68000, it is not difficult to conclude why the Apple IIGS remained the only personal computer to adopt the 65C816. Nonetheless, throughout this article, you will see how Nintendo and Ricoh managed to turn the limitations of this CPU into opportunities to revamp its game library.

Ricoh’s additions

In 1983, the 65C816 CPU was conceived as a general-purpose successor of its 1975 ancestor, with all the associated requirements and constraints. Yet, Nintendo planned its console to last throughout the 90s, meaning Ricoh had to step up its game (if you’ll pardon the pun).

First on the list was tackling its arithmetic limitations - the 65C816 lacks dedicated instructions for multiplication or division. As a result, Ricoh incorporated multiplication and division units, enabling the CPU to perform these types of operations via hardware (rather of software). Instead of conventional instructions, they are operated through registers.

The multiplier receives 8-bit numbers and outputs 16-bit ones [6]. Conversely, the divider takes a 16-bit dividend and an 8-bit divisor; and returns a 16-bit quotient along with a 16-bit remainder [7]. Both units only support positive numbers (called ‘unsigned’).

Now, you may be wondering ‘why is this relevant?’. The significance of these additions will become clear when we explore the novelties of the Super Nintendo’s graphics chips (in the ‘Graphics’ section).

Speedy memory access

The second challenge was to increase its data bandwidth. Hence, two exclusive DMAs (Direct Memory Access) were added to move data around without the intervention of the CPU, resulting in faster speeds. For this design to work, regions of memory are referenced using two distinct address buses [8]:

When setting up a DMA transfer, the origin bus must differ from the destination bus.

Furthermore, the two DMAs are not identical and serve very distinct functions [9]:

Finally, the system provides eight channels for DMA transfers, enabling to dispatch up to eight independent transfers at once.

The 16-bit Segmentation Fault

The primitive Open Bus behaviour is also present in this console. Furthermore, there has been speculation about the existence of an internal register called Memory Data Register (MDR), which is believed to store such values [10].

For comparison, the 68000 employs a vector table to handle exceptions, ensuring execution is redirected whenever a fault is detected.

(Lots of) more memory

It’s fascinating to realise how much content the NES managed to display with only 2 KB of RAM. Well, the Super Nintendo now features 128 KB of SRAM (still referred to as ‘Work RAM’ or WRAM) - a staggering 6400% increase in general-purpose memory compared to its predecessor.

So, what can developers do with this? Anything they desire, really. WRAM is used to store variable data for the game. The more space available, the greater the amount of information that can be stored and processed (thus, reducing reliance on cartridge hardware).

However, as the following sections will demonstrate, the Super Nintendo is a fairly complex machine (albeit its ‘simplistic’ CPU). I tend to call this console a ‘collection of mini-computers/subsystems’. Each subsystem may need data from the CPU, meaning programmers may reserve portions of WRAM to process that information - thus justifying the need for 128 KB of memory.


Graphics

After everything discussed so far, let me tell you that the graphical subsystem of this console is a true feat of engineering. Given its constrained CPU, one might assume the SNES could never cast a shadow on its competitor, which boasts a ‘32-bit’ Motorola 68000. Yet, Nintendo and Ricoh engineers devised clever tricks that exploit the behaviour of CRT displays, effectively expanding the console’s capabilities without the need for expensive, state-of-the-art components.

Before diving deeper into this topic, I strongly recommend reading the NES article first, as it introduces key concepts that will be revisited here.

Design

As with any other console of its generation, the Super Nintendo draws graphics using 2D tiles (8 x 8 pixels). The NES initially achieved this through it signature Picture Processing Unit (PPU), which beams the image in sync with a CRT screen. The Super Nintendo follows suit but incorporates more sophisticated techniques to obtain richer results.

The chipset

The Super Nintendo houses two different PPU chips that constitute the graphics subsystem, collectively known as the Super PPU or ‘S-PPU’.

Image
The two PPU chips.

Each PPU package serves specific functionality [11]:

This separation, from a programming perspective, is redundant, as both chips are effectively treated as a single unit.

Display modalities

The NTSC system outputs a standard resolution of 256 x 224 pixels at ~60 Hz [12]. The European variant, adhering to the PAL specification, outputs 256 × 240 pixels at ~50 Hz. Be as it may, most games do not utilise the additional pixels and instead display a letterbox (black lines).

Now, here’s the tricky part: traditional TVs have an aspect ratio of 4:3. Yet, if you do the math, the Super Nintendo’s output resolution has an aspect ratio of 8:7. Consequently, once the image is beamed on the TV, it looks horizontally stretched, resembling a 292 x 224 pixels frame instead (in the case of the NTSC variant) [13]. Put simply, pixels on the Super Nintendo have an aspect ratio of 8:7, rather than being ‘perfectly square’.

Image
Rendered frame with a resolution of 256 x 224 pixels. This is what the console sends to the TV.
Image
Stretched frame as seen from the TV (with an apparent resolution of 292 x 224 pixels).
Kirby’s Dream Land 3 (1997).

The reasoning behind Nintendo’s deviation from the standard aspect ratio boils down to cost. You will soon see that the S-PPU is very rich in functionality, but not fast enough to render everything at the pace of the CRT beam [14]. Rather than adding more circuitry to the board, Nintendo opted to short the width of the visible image, allocating extra space for the horizontal blanking period instead.

Nevertheless, some games like ‘Chrono Trigger’ account for this factor by intentionally using squashed shapes, which then look correct after being stretched by the TV. This, however, remains an exception, since the majority of games take no extra measures to compensate for this effect.

Organising the content

Image
Memory architecture of the S-PPU.

Due to cost and performance reasons, graphics data is distributed across three memory regions:

VRAM is implemented using two 32 KB chips, each accessed simultaneously via a separate 8-bit bus. This allows the PPU 1 to fetch 16-bit values per cycle, making it particularly efficient for retrieving multiple consecutive pixels in real time [15]. Additionally, each VRAM chip is connected to a dedicated 16-bit address bus, rather than a shared one. This will prove useful when the PPU 1 needs to switch to alternative memory arrangements - something we’ll explore in more detail when we talk about ‘Mode 7’.

Constructing the frame

Let’s now see how a frame is rendered on the console and subsequently displayed on TV. For demonstration purposes, Super Mario World will serve as example.

Tiles

Image
Some 16x16 Tiles found in VRAM.

Just like its predecessor, the S-PPU uses tiles to build sophisticated graphics. Although, there are significant improvements compared to the original PPU:

Background

Image
Background Layer 1 (BG1).
Image
Background Layer 2 (BG2).
Image
Background Layer 3 (BG3).
Background maps in VRAM.
Image
Rendered Background Layer 1 (BG1).
Image
Rendered Background Layer 2 (BG2).
Image
Rendered Background Layer 3 (BG3).
Image
Rendered Background Layers combined.
Rendered Background layers after selection and transparency are applied.

The Super Nintendo can generate up to four different background planes. Using either 8x8 or 16x16 tiles, blocks are made of 32x32 pixels (2x2 tiles). That being said, each background layer can extend up to 1024x1024 pixels in size (32x32 tiles). The region in VRAM where these layers are configured is called Tilemap, and is structured as a table (continuous values in memory).

Each Tilemap entry contains the following attributes:

As always, these planes are scrollable. However, the number of features available - such as colour depth, number of layers, independent scrolling regions, and size of selection - depends on the Background Mode activated on the S-PPU, which brings us to the next section…

Modes

The S-PPU provides many operations for backgrounds, but these cannot be chosen arbitrarily. Instead, programmers must choose from eight background modes, each offering a distinct set of features [16]:

As you can see, programmers can now decide whether to prioritise colour depth, number of layers, special effects, or resolution.

Sprites

Image
Rendered Sprite layer.

A dedicated memory region called Object Attribute Memory (OAM) stores a table with references of up to 128 sprites, each with the following properties [17]:

The S-PPU can render up to 32 sprites per scanline; overflowing this will only make the S-PPU discard the ones with the lowest priority.

Result

Image
Tada!

The S-PPU renders each scanline on-the-fly, first processing the relevant portion of each layer and then mixing them.

One of the key constraints of NES games was that graphical updates could only occur during V-Blank - the brief interval when the CRT beam was returning to the starting point provided a reasonable time frame to reshuffle some tiles without breaking the image.

Well, now thanks to the enhanced capabilities of the SNES, this limitation now takes on a different meaning.

You see, because the new DMA/HDMA units enable programmers to perform memory transfers without waiting for V-Blank [18], games can now update tiles, colours, and registers without waiting for the entire frame to be drawn. In fact, the possibilities extend even further: since games can now modify S-PPU settings mid-frame, it becomes possible to activate different background modes at different stages within the same frame, unlocking new and original game designs!

That feature

Truth to be told, I still haven’t mentioned the most important characteristic of this console…

Image
Rendered Background layer.
Image
Allocated Background map.
Image
Rendered frame on the screen.
The first quarter of scan-lines uses another mode to simulate distance, Mode 7 starts at the second quarter (this is possible thanks to HDMA).
Deconstruction of F-Zero (1990).

Introducing Mode 7, yet another background mode - but this time, with a completely different way of working. While it can only render a single 8 bpp background layer, it provides the exclusive ability to apply the following affine transformations on that plane [19]:

Mode 7 is controlled via a rotation matrix, which alters its parameters. Without delving into linear algebra, depending on the desired effect, the CPU must perform some trigonometric functions (sine and cosine) to populate the entries of this table accordingly. This is computationally expensive for the 65C816, even when using fixed-point precision. For this reason, with the 5A22, Ricoh integrated multiplication and division registers to offload some cycles.

By the way, you may notice that the list of transformations does not mention perspective, despite its presence in the example game, F-Zero. This effect is achieved by adjusting the rotation matrix at each HDMA call, creating a pseudo-3D effect in the process. This should give you an idea of just how versatile the S-PPU truly is!

Finally, due to the use of affine transformations, it is no longer useful to fetch adjacent pixels from VRAM. So, to maintain acceptable bandwidth, the memory map is restructured in a way that benefits the new pipeline. Thus, the first VRAM chip stores the Tilemap (where tiles are referenced), while the second stores the Tileset (where tiles are stored). Considering entries in both tables are 8 bits long, this setup allows the PPU 1 to retrieve references and tiles in a single cycle.

Generous circuits

Since Mode 7 requires additional computations, the PPU 1 incorporates dedicated circuitry to process the rotation matrix. Now, here is the interesting part: it also exposes the registers for developers to access when idle (in other words, when using Mode 0 to 6, or during V-Blank) [20].

The PPU 1’s multiplier is both faster and more capable than the CPU’s, as it accepts 16-bit numbers, both positive and negative (signed).

Reflecting on this 30 years later, I must say this concept is an earlier precursor to computer shaders.

More colour magic

Behind every rich frame is a flexible rendering pipeline. Well, if all the previous advancements weren’t impressive enough, the S-PPU features a versatile colour blender that enables to customise how layers are merged. Unlike other sprite engines with fixed rendering steps, Nintendo’s engineers exposed multiple parameters within the S-PPU’s pipeline, enabling developers to alter how certain pixels of different layers interact to form the final frame.

This functionality is collectively known as Color Math [21], but it is also called ‘Screen Addition/Subtraction’ - despite also supporting division by two. In any case, this pave the way for realistic transparency, dynamic lighting, and other creative effects.

Image
The lamp sways along with the light, such daunting effect is accomplished by altering the S-PPU’s masking options.
Image
The parrot follows you around with a torchlight, which can point to either direction and bounce. This plays very well with the overall atmosphere.
Donkey Kong Country (1994) exploited the capabilities of the S-PPU’s blender to astonishing levels.

In essence, the process works as follows [22]:

  1. Internally, the S-PPU houses two rendering pipelines: Main Screen and Sub Screen, where programmers can assign backgrounds layers and the sprite layer to each.
    • The Sub Screen can also be filled with a solid colour instead of receiving layers.
    • High-resolution modes (Mode 5 and 6) consume the Sub Screen’s resources, preventing Color Math from working in those modes.
  2. The pixels of both screens can be masked using individual window parameters.
  3. The S-PPU separately merges the background layers within Main and Sub Screen, respecting the priority of each layer and window settings.
  4. Finally, the S-PPU lets programmers decide how to merge the content of Main Screen and Sub Screen. It can add or subtract the two screens, and then divide the result by two (achieving transparency effects).
    • Division by two is computationally cheap in digital circuits, as it only requires to shift the value one position to the right.

In the second Donkey Kong Country example, Main Screen consists of a single white layer, while Sub Screen contains the rest of the scenery. However, the latter is encoded with inverted colours. At the last stage of the pipeline, the S-PPU applies subtraction and division, producing a correctly coloured frame with transparency effects and enhanced brightness - effectively simulating the torchlight.

Cause of frame drops

On a different topic - what causes games to lag? When the V-Blank interrupt is triggered to allow graphics updates, the game may still be executing heavy code, causing it to miss the V-Blank window. As a result, graphics cannot be updated until the next V-Blank call, and since the frame remains unchanged, this manifests as a drop in frame-rate [23].

Conversely, extensive processing during a V-Blank can block the S-PPU from outputting the video signal, as the bus remains occupied. This can lead to black lines appearing during a scan, though this effect is barely noticeable since the frames refresh 50 or 60 times per second.

A convenient video out

All of the aforementioned advancements would be meaningless unless the console could transmit its picture to the TV through a medium both can understand. With the Super Nintendo, the company debuted some sort of universal-but-proprietary connection called Multi Out, capable of carrying many types of signals at the same time, including Composite, S-Video and RGB [24].

Nintendo bundled a ‘Multi Out-to-Composite’ cable with the console, as composite video was pretty much the common denominator of TVs at the time.

In Europe, however, the SCART port was widely popular, particularly among set-top boxes and VCRs. A major advantage of SCART is its ability to support multiple signal types, allowing AV equipment to select the most optimal format without compatibility issues. As far as I know, only French consumers were offered an official SCART cable that took advantage of the RGB pins exposed on the Super Nintendo [25].

Consequently, Nintendo altered the pinout of its PAL consoles to comply with the SCART protocol, replacing the ‘composite sync’ pin with a 12-volt signal - which instructs the TV to use a 4:3 aspect ratio. Thus, while Multi Out is theoretically universal, RGB cables, if any, are region-specific.

I think the practical benefits of Multi Out have become more apparent in recent years, as it allows users to leverage the RGB output on their modern tellies without tampering with the console’s internals. However, unlike Composite and S-Video, RGB requires an extra ‘sync’ signal. For this, cables can be wired up to capture the sync signal from Composite or S-Video - or for best results, use a dedicated sync line called ‘composite sync’. Unfortunately, as noted earlier, the latter signal is exclusive to NTSC consoles.


Audio

Just like its graphical abilities, the audio department of this console has undergone a significant overhaul. I would argue it even offers the most advanced synthesising techniques of its generation.

Architecture

Some companies partnered with Yamaha, while others devised an in-house solution. Well, Nintendo partnered with Sony - the electronics conglomerate behind the Walkman - to supply a sophisticated synthesiser.

And so, Sony delivered quite an audio subsystem, consisting of the following components:

The audio subsystem operates in parallel with the main CPU. When the console powers on, the SPC700 boots a 64-byte internal ROM that sets it up to receive commands from the main CPU [27]. After this setup, it remains idle until instructed.

Channels used for melody.
Drums are discriminated for demonstration purposes.
All audio channels.
Oscilloscope display of Star Fox (1993).

For the S-SMP to do useful work, it needs to load a type of program known as Sound Driver. This software instructs the chip on how to manipulate raw audio data sent by the main CPU to PSRAM, as well as how to control the S-DSP.

As evident, the sound subsystem was a major leap forward compared to previous generations, but it also posed significant programming challenges. The documentation provided by Nintendo was infamous for its vague explanations and omission of critical features, forcing developers to conduct their own research.

As a result, a wide variety of sound drivers emerged in the market [28], with some uncovering impressive capabilities.

Pitch control

Pitch bending enables to produce distinct notes using the same sample. Well, the S-SMP included a useful bender to alter the pitch in a smooth manner. Take a look at this extracted channel from Mother 2/Earthbound @[fig-pitch_bend], both examples come from the original soundtrack, however, the first one has the pitch control disabled.

No pitch bend.
With pitch bend enabled.
Oscilloscope display of Mother 2/Earthbound (1994).

Evolution from the NES

To visualise the evolution of sound from the NES to the Super Nintendo, here is an excerpt from two music scores - one from an NES game and another from its Super Nintendo sequel. Both feature the same composition.

Mother (1989).
Mother 2/Earthbound (1994).
Oscilloscope display of the same score across the two different games.

Advanced usage

Channels used for melody.
Channels used for drums.
All audio channels.
Oscilloscope display during a game of Kirby’s Dream Land 3 (1997).

Here’s a more instrument-rich composition that takes great advantage of pitch bending, echo and envelope.

This combination of techniques allowed the music to only require five channels in total, leaving the other three for sound effects.

Stereo confusion

The S-DSP’s volume controls are organised into signed 8-bits values [29], meaning that volume levels can be set to negative values. But hang on, if ‘0’ represents mute, what happens when the volume is set to ‘-1’? Well, it inverts the signal.

This technique is particularly useful for creating a surround effect, accomplished by setting the stereo channels out of phase - where one channel outputs the normal signal while the other outputs the same signal but inverted.

Unfortunately, abusing this feature results in very unpleasant results, such as the feeling that the music is playing inside your head. For this reason, most SNES emulators bypass this setting altogether.

Additionally, out-of-phase stereo is cancelled out on mono devices, so those games needed to provide a stereo/mono selector to avoid muting their own soundtrack.


Games

To be blunt, the main program is written in plain 65816 assembly and the music driver is written in SPC700 assembly. Needless to say, you won’t find any of the commodities available on 21st-century equipment.

There were, however, some tools distributed by Nintendo, Intelligent Systems and Ricoh to make life easier for programmers, these included [30]:

Curiously enough, several game studios - including Argonaut Software, Accolade, and SN Systems - developed custom in-house equipment, often providing more capabilities than the official offerings (e.g. memory editors, floppy disk readers, ISA-based devkits, etc.) [31].

Cartridge configuration

When it comes to accessing the cartridge, things get a lot more confusing compared to the relatively simpler mapping model of the NES. I find it interesting nonetheless, especially for understanding how it could be expanded.

The 65C816 features a 24-bit address bus, enabling to access up to 16 MB worth of data. However, due to the console’s architecture, a portion of the address space is reserved for memory-mapped components. Moreover, the 65C816 only comes with 16 address lines, which are then combined with internal registers to construct a 24-bit address. This is analogous to housing an internal mapper and requiring bank switching to access extra data beyond the boundaries of the address bus. If you explore other systems of the same generation, you’ll find this methodology somewhat familiar.

Image
Example cartridge boards designed with different configurations [32].
From top to bottom: LoROM (dual ROM with battery-backed SRAM), LoROM (single ROM with battery-backed SRAM) and LoROM (single ROM)

That being said, when it comes to designing a cartridge, there are many ways to electrically connect the address pins between the ROM and CPU, each utilising bank switching in a different way.

There are two fundamental models that enables accessing up to 4 MB of ROM and 64 KB of SRAM [33], and they work as follows:

In both cases, a significant portion of ROM space is mirrored across the leftover area of the CPU’s address space. However, here’s the interesting part: one half of the space operates at ~2.68 MHz while the other can reach 3.58 MHz - but only if the ROM chip supports the higher speed and the CPU’s FastROM flag is enabled [35].

Additionally, cartridges that bundle SRAM must house a MAD-1 (or similar) chip, which performs address decoding. This component is particularly crucial for correctly latching the pins that select between ROM and SRAM chips [36].

Beyond convention

Now, when programmers require more space, derivative models of LoROM and HiROM come into place. Two common variations, known as ExHiROM and ExLoROM, extend the ROM’s addressing space by reducing the mirrored area. Both can access ~7.9 MB of ROM.

Image
Star Fox (1993) uses the Super FX GSU chip to render 3D surfaces. Behind the scenes, the S-PPU only sees a background layer made of erratic tiles.

Alternatively, and most importantly, LoRom and HiROM can also be adapted to accommodate enhancement chips within the cartridge. These are additional processors that expand the capabilities of the console. To name a few examples of new configurations:

It’s difficult to overlook the impact this engineering had on 90s gaming, with many titles surpassing the console’s expectations - and without requiring expansion modules and whatnot. You could say this complicated Nintendo’s plans for a successor console, which may explain the cancellation of advanced games like Star Fox 2.


Anti-piracy / Region Lock

With the Super Nintendo, Nintendo assumed again the sole authority over game distribution. To enforce its policies, the company devised three layers of protection to prevent unauthorised cartridge distribution and circumvention of royalties.

Firstly, the external shape of cartridges is different between regions, so they won’t fit on consoles from different areas. Be as it may, this could be easily bypassed using a third-party adapter.

Secondly, like the NES, this console still incorporates the 10NES protection system to lock out unauthorised distributors. However, the CIC chip was eventually cloned.

As a final layer - specifically designed to combat bootlegging - games included a chain of piracy checks within their program, such as:

  1. SRAM size verifications: Bootleg cartridges often contain large SRAM blocks to accommodate various games.
  2. Code integrity checks: A series of checksums embedded throughout the game’s code verify whether the previous SRAM size verification routines have been removed. These checks are dispersed at different stages of the game, making them difficult to locate and remove.

While these measures could be nullified by manually stripping out the routines, this was a time-consuming task. After all, they would be scattered around the game only to upset the player (and eventually make them buy a legitimate copy). Truth to be told, you’ll notice that most ROMs available online have had all their piracy checks removed.


That’s all folks

Image
My modded SNES with an American cartridge.
That game was only released in the states. Luckily, a lad was selling it in Glasgow!

Contributing

This article is part of the Architecture of Consoles series. If you found it interesting then please consider donating. Your contribution will be used to fund the purchase of tools and resources that will help me to improve the quality of existing articles and upcoming ones.

Donate with PayPal
Become a Patreon

You can also buy the book editions in English. I treat profits as donations.

Book edition

A list of desirable tools and latest acquisitions for this article are tracked in here:

Interesting hardware to get (ordered by priority)

Acquired tools used

Alternatively, you can help out by suggesting changes and/or adding translations.


Copyright and permissions

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But you have to respect the license and reference the article properly. Please take a look at the following guidelines and permissions:

Article information and referencing

For any referencing style, you can use the following information:

For instance, to use with BibTeX:

@misc{copetti-snes,
    url = {https://classic.copetti.org/writings/consoles/super-nintendo/},
    title = {Super Nintendo / Famicom Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2019}
}

or a IEEE style citation:

[1]R. Copetti, "Super Nintendo / Famicom Architecture - A Practical Analysis", Copetti.org, 2019. [Online]. Available: https://classic.copetti.org/writings/consoles/super-nintendo/. [Accessed: day- month- year].

Special use in multimedia (Youtube, Twitch, etc)

I only ask that you at least state the author’s name, the title of the article and the URL of the article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you may state either the author’s name or URL of the article at the bottom of the image, and then include the complete reference in the video description. In other words, for any resource used from this website, let your viewers know where it originates from.

This is a very nice example because the channel shows this website directly and their viewers know where to find it. In fact, I was so impressed with their content and commentary that I gave them an interview 🙂.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.

Third-party publishing

If you are interested in publishing this article on a third-party website, please get in touch.

If you have translated an article and wish to publish it on a third-party website, I tend to be open about it, but please contact me first.


Sources / Keep Reading

Audio

CPU

Games

Graphics

Photography


Changelog

It’s always nice to keep a record of changes. For a complete report, you can check the commit log. Alternatively, here’s a simplified list:

2025-05-18

2024-09-30

2024-01-14

2022-11-19

Super revamp:

2021-07-10

2020-09-23

2020-08-23

2019-12-08

2019-10-28

2019-09-17

2019-09-01

2019-08-29

2019-06-28