7

I say "a device" because I'm not convinced that this happens on an actual Game Boy. (I haven't been able to provoke it on mine yet.)

I've seen several videos of people showing how their Analogue Pocket (modern FPGA Game Boy "emulator" device) hangs (or maybe it's the game itself that hangs?) if you even touch the inserted cartridge while running the game.

The Analogue Pocket has, seemingly for (dubious) aesthetic reasons, made it so that an original Game Boy cartridge is barely held in place on the back of the console, with almost nothing of the cartridge "covered" physically, unlike the original Game Boy into which you slide the cartridge and it's physically held in place tightly.

Most of the time, why would either the game or the console care at all about briefly losing electrical connection with the ROM? Surely data is not constantly transferred to and from the cartridge? Only when loading a new level or starting the game and things like that? Otherwise, the device has the data in its own working memory, no?

Why would briefly losing electrical connection with the ROM cause it to immediately freeze/hang/glitch out when it's not even trying to retrieve data? Why would it even be aware that this has happened?

PS: I tried to search for one of those videos that I have seen to link to it here, but just can't find anything when I need it.

Improve this question
7
  • 3
    Substantially covered by What causes the glitchy sound when a GBA cartridge is removed?. I’ll leave to the community whether this should be closed as duplicate or not.
    – user3840170
    Dec 15, 2022 at 18:27
  • 3
    Such as it’s relevant: the game runs from the cartridge ROM, not from RAM. The only comparable system of that era that treats the cartridge purely as external store that I can think of is the Lynx, which was originally designed to take either cartridges or micro-cassettes.
    – Tommy
    Dec 15, 2022 at 18:50
  • 1
    You might also ask why an emulator would access the cartridge constantly, rather than just reading it once and then having the game stored in the emulator's own, much faster memory. Presumably, this is done so that all custom chips in the cartridge are faithfully "emulated" (since they're actually not emulated at all)
    – user253751
    Dec 16, 2022 at 10:17
  • 3
    @user253751 the Analogue Pocket is an FPGA-powered hardware emulator; to play Game Boy games it configures itself as their hardware reimplementation of the Game Boy, which [ideally] has exactly the same relationship with the cartridge slot as the original hardware.
    – Tommy
    Dec 16, 2022 at 16:36
  • 1
    @Diggs What do you mean by "poking an inserted cartridge"? Do you mean removing?
    – Nayuki
    Dec 17, 2022 at 5:22

4 Answers 4

Reset to default
34

Surely data is not constantly transferred to and from the cartridge?

Surely it is. That's the huge benefit of cartridges.

Only when loading a new level or starting the game and things like that? Otherwise, the device has the data in its own working memory, no?

There's only 8kB of that "working memory", but it shares an address space with the cartridge ROM, and optional external RAM on the cartridge. Code isn't transferred from the cartridge to RAM and then executed from there; it's executed directly from ROM. So as long as anything is running, the cartridge needs to be there. Likewise bulk data like level maps and most graphics will be accessed directly from ROM, not loaded into RAM. Anything that's put into the external RAM is also accessed over the cartridge connector of course.

This is fine because, unlike the kinds of external storage devices you're used to, the cartridge runs at effectively the same speed as the CPU and the RAM (it doesn't even look like the cartridge has a pin to inject a wait state). So copying stuff into RAM doesn't make it any faster anyway. You only put stuff in RAM if it's game state that needs to be dynamically modified.

Improve this answer
5
  • 2
    With the caveat that they may copy stuff into RAM for other reasons. For example, I remember reading that the Sonic the Hedgehog games on Genesis/Mega Drive stored level data compressed to cut the cost of manufacturing the mask ROMs, and I believe another Q&A on here said that, in (at least some?) Gameboy cartridges, the ROM in the cartridge is slower than the system RAM and so game designers copy hot code to RAM for performance reasons. (Given that PC BIOSes also used RAM shadowing for performance reasons, I assume this isn't uncommon.)
    – ssokolow
    Dec 16, 2022 at 0:35
  • 8
    Yeah, occasionally there are reasons (IIRC Pokemon has compressed battle sprites). I didn't mean to say that it never happens, just that it isn't happening 99% of the time, so the cartridge is going to be accessed constantly. Phrasing is hard :)
    – hobbs
    Dec 16, 2022 at 4:01
  • 2
    I've never noticed any game boy cartridges to be slower than the system RAM, I can say that it's necessary to execute sprite DMA from RAM, but that's about it. I also typically copy interrupt handlers to RAM just to avoid condition checking during an IRQ but that's just me.
    – puppydrum64
    Dec 16, 2022 at 14:58
  • 5
    FWIW, the Super NES had "Fast ROM" and "Slow ROM" cartridges. I don't know if any GameBoy games had differences, but the general principle applies, the cartridge isn't just a data storage device (like a hard drive in a newer console, or a game cart on the Switch), it literally becomes part of the circuitry of the system and participates on the bus.
    – Michael Stum ♦
    Dec 16, 2022 at 16:26
  • 1
    Running software directly from ROM or Flash is often called execute-in-place (XIP).
    – user71659
    Dec 17, 2022 at 0:44
4

On the Game Boy and Game Boy Color the cartridge roms were connected more-or-less directly to the main memory bus and were as fast as any other memory. Working ram in the console was also quite limited. The same applies to pretty much every other 8-bit console*.

So it was absolutely normal for games to read all of the code and read-only data directly off the cartridge as and when they needed it. Some games (for-example Pokemon) even went as far as using some of the ram located on the cartridge as extra working ram.

On the Game boy advance, cartridge rom was substantially slower than ram. However ram was still in fairly limited supply and a lot of games frankly did not need the full performance of the GBA's CPU. So it was still very common to run code directly from the memory on the cartridge.

It was only with the DS that nintendo's portable line moved to a cartridge that behaved in a more "disk like" manner with data being read in sectors.

* I'm not sure about the architecture of later home-consoles that used cartridges, I haven't studied them in detail and a quick google is not turning up good results. I know they could run code directly off the cartridge, but i'm not sure if it was full-speed like the 8-bit consoles or reduced speed like the GBA.

Improve this answer
1
  • 3
    Later home consoles: NES and SNES are roughly equivalent to the Gameboy, and N64 is like neither: the cartridge is mapped to an address region, but I'm not sure if the processor can directly run code from it; it's much more normal to use "PDMA" (parallel DMA) to read from the cartridge into RAM. The thing that makes me unsure whether direct execution is possible is the fact that the boot ROM copies the cartridge bootloader into RAM instead of directly executing it on the cartridge.
    – user253751
    Dec 16, 2022 at 17:11
3

The other answers have corrected the misconception about whether games run directly from ROM (they do), but I wanted to add a second reason why messing with the electrical connection could cause glitches: you’re messing with the electrical connection. The Gameboy cartridge pins are directly connected to the main address+data bus.

  • A short circuit between two pins is extremely likely to cause glitches: the bus is electrically connected all the time, whether or not cartridge ROM is currently the selected address to be accessed.
  • An open circuit across one or more pins can be just as bad — if the ROM chip select and output enable goes low, it starts driving the bus, whether or not that’s what the CPU requested. Or, if the address or data line reads any bit incorrectly, it’s reading the wrong opcode and the CPU loses synchronization with the game code. A single incorrect instruction is enough to crash the entire game.
  • If you remove and reapply power to the ROM, the datasheet won’t guarantee its behavior across the address and data pins for several cycles, so it might cause garbage on the bus, even if you haven’t disrupted any other pins. (Normally this is handled by the RESET circuitry staying active long enough for every device, including ROM, to finish acting wacky at their startup, before the CPU starts controlling the bus, but if you RESET in the middle of the game— that’s GAME OVER).
Improve this answer
2
  • It's unlikely there will be a short circuit (that would require much more cartridge movement), much more likely it'd be an open circuit (broken connection).
    – Hearth
    Dec 17, 2022 at 19:57
  • @Hearth good point. updated, thanks.
    – Jacob Krall
    Dec 17, 2022 at 20:53
2

The X-factor is, fast ROMs were far cheaper than RAM

Surely data is not constantly transferred to and from the cartridge?

You're thinking modern - where RAM is cheap and abundant, and all software code is loaded into RAM from media such as hard drive or SSD. "ROM was just another SSD, right?"

No, actually. Back then, it was dirt cheap to make ROM cartridges that would interact at the full CPU bus speed -- far cheaper, K for K, than the equivalent RAM. (Heck the original Apple II came with 10K of ROM but only 4K of RAM - ROM was cheap.)

So ROM cartridge memory was simply mapped into the system memory space, and treated as RAM in the system design, with Code running directly off the ROM data. In fact that's how most things booted up, including PCs well into the 1990s at least. (now, the boot ROM is SSD of some kind).

I've seen several videos of people showing how their Analogue Pocket (modern FPGA Game Boy "emulator" device) hangs (or maybe it's the game itself that hangs?) if you even touch the inserted cartridge while running the game.

The Analogue Pocket has, seemingly for (dubious) aesthetic reasons, made it so that an original Game Boy cartridge is barely held in place on the back of the console, with almost nothing of the cartridge "covered" physically, unlike the original Game Boy into which you slide the cartridge and it's physically held in place tightly.

Well, that's just a faulty socket design! They should design a better socket, or maybe, buy a COTS socket component from a reputable electronics supplier, gosh!

It doesn't matter if the cartridge moves, it matters if the cartridge loses electrical contact with the socket. If the connection of any address pin is lost, the ROM will hear the wrong memory address. If any data pin is lost, the ROM cannot return the correct data.

Improve this answer

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