Older systems, such as the NES, would often access the ROM in real-time rather than caching the data in system memory, sometimes even reading the same data every single frame. This would result in an immediate and dramatic effect when the connection to the cartridge was broken. Newer systems, such as the Nintendo DS, would instead load from the cartridge into memory* only when needed. Because of this, breaking the connection to the cartridge would result in the system freezing the next time data needed to load (e.g. when a new entity is about to spawn).

My understanding is that the older behavior was common when memory was slow enough that reading from ROM was not significantly slower than reading from memory, and limited enough in size that keeping an entire "scene" in memory was not practical. Only when memory capacities got larger and the RAM became significantly faster than ROM did this change.

What did Game Boy Advance cartridges do? For example, was audio constantly streamed from the cartridge in real-time, or was it cached in memory and played from there? Is there any data that is read from ROM every single frame, rather than being read from memory? In other words, was data constantly being read from ROM, or only when "loading" new areas or entities?

* Interestingly, it seems like the Nintendo DS was unable to execute directly from ROM (it wasn't mapped to an address) and needed to first copy to system memory. I believe this was due to copy protection.

1 Answer 1


It depends on how the game (or the program, if not running a game) is programmed. It does not depend on the system, but on where the memory where program is executed is physically located. If a program is loaded in RAM that stays inside the system and uses RAM which is inside the system, it won't freeze when removing the cartridge. On the other hand, if the program is executed directly from ROM or RAM that is inside the cartridge, it will freeze when removing the cartridge, as the CPU will fetch instructions from a non-existing memory. This is applicable to both NES and GBA.


In the vast majority of cases there's no reason not to execute code from ROM directly, as code runs at the same speed constantly. There's no point copying code to RAM if there's no need to. It is however perfectly possible to load a program in the system's internal 2 KiB of RAM and execute it, if the ROM is not used anymore it is possible to make a program that does not crash when removing the cartridge(*). This technique is called hotswapping and is actually used, for example to dump games or to test expansion audio chips from genuine Famicom cartridges without destroying them.

Game Boy Advance

The system has more types of memory: In addition to cartridge ROM, there's on-system WRAM and on-system IRAM. Each type of memory is a trade-off between size and speed. Speed is indicated as (x / y), where x is the # of cycles per instruction in 16-bit Thumb mode, and y the # of cycles per instructions in 32-bit ARM mode. According to GBATEK, when it comes to executing code

  • Cartridge ROM is the slowest (8 / 5 cycles) but also the largest
  • WRAM is faster (6 / 3 cycles) but limited to 256 KiB
  • IWRAM is fastest (1 cycle), but smallest, being limited to 32 KiB
  • VRAM can also be used to execute code (2 / 1 cycle). It is however small, and using it removes space normally used for display, so using this limits graphic possibilities
  • Cartridge RAM (8 cycles) could be used but there's really no point as it is normally dedicated to save games

Whether code is executed from WRAM, IWRAM or VRAM, it will not crash when removing the cartridge. When it is executing from cartridge ROM (or from cartridge RAM - something almost completely useless) it will crash as soon as the cartridge is removed.

In most cases, games runs the majority of the code directly from ROM as RAM is limited, and does so in 16-bit Thumb mode. Critical bottlenecks are loaded in IWRAM and executed in ARM mode. This is however not an absolute, any game can do whatever it likes to.

You can extend this concept to any other system using cartridges.

(*) However, as the cartridge is also used as a source for pattern assets, the graphics will be completely screwed up, but technically the program does not freeze.

  • This is at odds with the previous answer. So for GBA games (common ones like Pokemon gen III, Zelda, etc), most code is executed directly from ROM?
    – forest
    Commented Sep 16, 2018 at 0:20
  • 3
    I don't look into it, but most probably yes. On GBA the only reason to go through the hassle of downloading code into RAM is if you want it to execute faster, Otherwise, RAM is better used to keep dynamic game state information. Typically the music mixer runs in RAM, as it is required to be fast, and GBA games typically devote a lot of time for this.
    – Bregalad
    Commented Sep 17, 2018 at 18:37
  • 2
    If you want to know the internals of a particular game, I suggest reverse-engineering it. Every game is different so it's hard to say what games "usually" does. The ones I've seen had only audio mixing run from RAM in mixed ARM and THUMB mode, the rest running from ROM in Thumb mode.
    – Bregalad
    Commented Sep 24, 2018 at 7:28
  • 1
    @Bregalad another reason to go through the hassle is that some GBA games permit two-player link-ups with a single cartridge, so will download themselves to the remote RAM for that use. I guess you could also make an educated guess as to how much those titles need the cartridge storage while playing based on how cut-down that mode is. This purports to be a complete list of games that can play that way at all: ign.com/articles/2004/01/17/the-ultimate-list-multi-boot-games
    – Tommy
    Commented Feb 18, 2020 at 19:23
  • 2
    It's also possible that some games might store data compressed in ROM and decompress it into RAM as a way to reduce per-cartridge materials costs. Sega did that (1,2,3,4) with Sonic the Hedgehog on Sega Genesis and that's why the end-of-level animations are unskippable. (They're loading screens in disguise.)
    – ssokolow
    Commented Feb 24, 2020 at 14:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .