23

Example in mGBA (mirror) — SOUND WARNING.

When you remove a game cartridge from a powered-on GBA, it makes this horrible, loud glitching sound. I can tell that a small portion of the looped sound is whatever was in the audio buffer at the time of removal (maybe I'm wrong with this), but what is the rest of it? How come Nintendo didn't simply create a screen saying something like:

Game Pak has been improperly removed. Please power the Game Boy Advance off and back on.

Reposted from this question on Arqade as suggested by another user. I'm curious if anybody could give a technical explanation on the specifics of this result.

4
  • 10
    From what I know, hot-swappable connectors have to be specially designed, so that certain pins make/break contact before others (look at the USB A plug, where the outer pair of pins are longer than the inner pair; this is no accident!). The GBA cart slot looks entirely symmetrical; even detecting hot swapping may be difficult, and there is even possibility that yanking the cart might damage the handheld electrically. And if Nintendo were to spend the design effort to make a hot-swappable cart connector, why not make it do something more impressive than just display a lame error message? May 3 at 14:18
  • @user3840170 FWIW, I have seen some very small GBA homebrew that still runs perfectly fine when the cartridge is removed. I assume such occurrences were, as you pointed out, seldom considered.
    – leetbacoon
    May 3 at 19:34
  • 3
    It's possible that homebrew cart copied code to RAM and executed from there. In which case, that may even work relatively reliably. May 3 at 20:21
  • 2
    Note that if you insert a cartridge into a GBA while it is in this glitchy state, you risk damaging save data. This is because GBA games (unlike CGB and DMG) don't have a write-protect for save data.
    – forest
    May 4 at 1:04

3 Answers 3

21

One does not simply make a hot-swappable cartridge connector.

For an electrical connector to handle hot-swapping well, it has to be specifically designed with that in mind. In particular, the contacts have to be designed to connect in a specific, predictable order to avoid erratic behaviour and electrical surges that could cause glitches, and in the worst case, fry the circuit outright. PS/2 sockets for PC keyboard and mice were somewhat notorious for this, although it got better in the later years, before they were entirely displaced by USB. For more details, I invite you to check out a similar question over at Electronics. While I have a hard time finding a good image of a GBA cartridge slot and connector, the images I do find show pretty clearly that it’s entirely symmetrical, with all pins of equal length. With such a design, seamless hot-swappability is a non-starter: there is no way to make it safe to the circuitry, never mind detect when it happens.

So that’s one reason why the GBA does not handle disconnecting a live cartridge more gracefully. One could ask: why didn’t Nintendo design the connector to allow hot-swapping then? I suppose there just wasn’t a compelling enough case for it. Nintendo didn’t have any interesting functionality in mind that would require carts to be hot-swappable; there is no point spending design effort on it just to display a lame error message. I guess it might also have complicated compatibility with the original Game Boy, and Nintendo may have been assuming that players would not do stupid things that could risk damaging their, after all, not all that cheap hardware.

These days they would have probably known better.

With all that out of the way: what happens when you ignore the dangers and rip the cartridge out of the handheld?

A cartridge slot is basically a direct extension of the CPU’s memory bus; it’s not so different from an expansion card slot in a desktop PC. When a cartridge is connected, the CPU can directly communicate with the devices present on the cartridge (which most of the time are simply a couple of ROM chips, sometimes some battery-backed SRAM for save states) simply by putting the address of the device on the memory address bus and then waiting until the device uses the data bus to either read the data the CPU sent its way or send the data the CPU wants. In normal operation, the CPU fetches instructions one after another as they are executed, either directly from the ROM, or mediated via a mapper chip on the cart. (Some emulator consoles that can read original cartridges are known to instead read the entire ROM in bulk into working memory and run it from there, leaving the cartridge an idle prop most of the time.)

When the cartridge is pulled, the CPU keeps fetching instructions from memory addresses that are no longer connected to a ROM. This situation, where a CPU accesses a memory address not answered by any device, is known as an open bus, and it’s infamous for causing lots of headaches for emulator developers. As the CPU hopelessly tries to fetch instructions from ROM that is no longer there, the game appears to freeze. The CPU keeps running, though, at least for a while; it just keeps executing garbage instructions obtained from the open bus. If the game happens to be running from built-in RAM, though, it may even keep actually working; at least, until it decides to read the cartridge ROM.

But that directly affects only the core logic. The RAM, which is installed in the handheld itself, is still present, and the video and sound hardware maintain their state: as such, the screen contents stay intact, and the sound keeps playing. Eventually though, the audio buffer runs out, and the audio hardware attempts to signal the CPU about it with an interrupt request; but since there is no game code to refill the buffers any more (or data to refill it from), the sound hardware just plays whatever garbage happens to be next to the audio data in memory, and eventually loops back to the start.

10
  • 4
    @leetbacoon The instant even one cartridge pin is disconnected the CPU will read a random instruction or random data word instead of what the cartridge ROM would contain so it may try to executes a random instruction which can do anything or it might be an invalid instruction caught by CPU hardware which stops execution, or if code is run from internal RAM, it might need data from cartridge and do something based on the data and if it is random data instead of correct data then it will process it incorrectly. There's no way to know if data bus has a correct or random value.
    – Justme
    May 3 at 20:00
  • 8
    @leetbacoon Because while memory reads no longer work, the CPU still runs. It doesn't halt, it just executes bogus instructions that most of the time do nothing useful. When you reinsert the cartridge, the program counter doesn't pick up at the same place it was when the cart was removed. There's little hope of syncing it back in such a case. May 3 at 20:18
  • 1
    A GBA cartridge runs at 3.3V and is pretty simple and internally rugged. I'd be surprised if you could cause damage to a GBA cartridge electrically by removing it.
    – forest
    May 4 at 1:41
  • 4
    @forest Standard electronics rules apply here too, even if it might surprise you. Chips in the cart are not designed to handle voltages on their bus pins while not being powered. If the cartridge power supply or ground pin disconnects before the data pins, the chips suck power via internal protection diodes, and the CPU might not handle that case when it has components that suck power via address and data bus. For example, USB connector is mechanically designed to make sure power contacts mate before data and data disconnects before power, which makes USB hot-pluggable electrically.
    – Justme
    May 4 at 10:12
  • 1
    @Hobbamok - PS/2 superior latency has has been a myth for decades now - unless you have literally cheapest possible USB 1.0 low-speed keyboard, almost any USB keyboard is actually going to have latency in the same range as PS/2, and better USB keyboards are actually going to have noticeably lower latency than PS/2: see for example youtu.be/eEswl6kZq5k?t=616 (do watch the whole video for details) May 5 at 20:46
18

This game seems to be playing PCM audio from memory buffer with DMA. Normally the CPU handles playback of DMA buffers and renders new audio into buffers for playback. When you unplug the game cartridge, the CPU won't have a program any more to run or can't access any data it might need and it likely just halts as it can't read valid opcodes from the data bus.

The DMA hardware is never told to stop so it repeatedly plays back the buffers it has been told to, and the buffers may contain literally anything, such as code, data, or the area may have been used as temporary buffers for decompressing something etc.

So nothing unusual, it is similar if a standard DOS PC hangs while autoinit DMA playback is left running, or you have a sound card that can play looped samples from onboard memory.

So that's what happens, and why there are no messages about unplugged cart is also simple. Cost.

First of all, the connector for the game cartridge is simply an electromechanical connector to exchange memory chips on a bus. Neither the CPU from where the bus comes from, or the chips on the game cartridge where the bus goes to, are not designed to support live hot-plugging, and so the connector also does not need to support it, and no electronics or programming needs to be designed or added to support hot-plugging. Just a note in the manual is enough to say to people it's not supported, it may damage things, so don't do it.

If support for live hot-plugging is considered, it can be made but at a cost. For example, there needs to be a mechanism to safely disconnect bus and power to cartridge socket, which can be made by adding bus buffers. There needs to be a way to detect when the cartridge is present so it can be powered up and when it is about to be removed, so either there needs to be more pins on the cartridge to allow detection of removal, or a separate detector, or a hatch which signals unpowering when opened.

And then there needs to be software developed to monitor the cartridge detection, and to print out something with some font or graphic image, which might require a larger and more expensive ROM chip to store all that, someone needs to write and test the code, design and test the electronics etc, design the graphics or font, the text to display, etc.

So, it's just much simpler to omit such a feature because it does not add any value for the price it requires to have such a feature.

1
  • 1
    Very good detailed answer, thanks for the breakdown.
    – leetbacoon
    May 3 at 19:50
5

The reason that particular sound is generated has already been explained well by other answers, so I'll try to expand on the specific reasons for the second part of your question.

How come Nintendo didn't simply create a screen saying something like:

There are two main reasons. First, in order to detect removal of a Gamepak, it is necessary to have a particular pin (usually /REQ on pin 31 which is used for Gamepak IRQs or DMA requests) be shorter than all the others. This ensures that it will disconnect first if the cartridge is removed. Most cartridges do not have a shorter pin 31 and as such the interrupt cannot be triggered until it's too late.

The second reason is cost. Not the cost of hardware, but resources. When the /REQ pin is triggered, an IRQ (interrupt request) is fired off. The interrupt handler can't be in ROM because it is no longer accessible, so it must be stored in WRAM. For performance reasons, only the highest-priority code is kept in WRAM. Wasting any of the limited space there (256K slow EWRAM and 32K fast IWRAM) just to print a pretty message would require moving some hot code from WRAM back to ROM. This would result in a serious performance hit and would not be worth it.

These, combined with the fact that there was no pressing need to support hot-pluggable cartridges as another answer aptly pointed out, explain why Nintendo decided to do what they did.


The GBA technical reference describes what would be needed to handle cartridge removal:

Enable the Gamepak Interrupt (it'll most likely get triggered when removing the cartridge), and hang-up the GBA in an endless loop when your interrupt handler senses a Gamepak IRQ. For obvious reason, your interrupt handler should be located in WRAM, ie. not in the (removed) ROM cartridge. The handler should process Gamepak IRQs at highest priority. Periods during which interrupts are disabled should be kept as short as possible, if necessary allow nested interrupts.

[...]

In SRAM/FRAM cartridges, the /REQ pin (Pin 31 of Gamepak bus) should be a little bit shorter as than the other pins; when removing the cartridge, this causes the gamepak IRQ signal to get triggered before the other pins are disconnected.

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.