3

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?

4

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 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.

NES

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 2k 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 Adavance

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 tradeoff between size and speed. Speed is indiacted 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 256kb
  • IWRAM is fastest (1 cycle), but smallest, being limited to 32kb.
  • 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 whathever 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 Sep 16 '18 at 0:20
  • 1
    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 Sep 17 '18 at 18:37
  • So for an archetypal game like Pokemon gen III or Legend of Zelda, most code is executed in real-time from the ROM? E.g. Pokemon cries, move graphics, etc? – forest Sep 18 '18 at 2:41
  • Yes indeed. Yes indeed. – Bregalad Sep 18 '18 at 9:30
  • 1
    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 Sep 24 '18 at 7:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.