A savestate is a file that contains the entire state of the device, so that it can be restored in order to resume gameplay. An emulator can handle this easily, since it controls (and thus knows and can overwrite) the entire state —
its own state, really. But a flash cart has to play by the rules of the hardware, and it only has the Game Pak bus to interact with it. Let's break down what this device state entails, and how it could be accessed:
- ROM, banking state and save data. This is the easiest by far, because the flash cart already controls it.
- General-purpose RAM (WRAM, HRAM). This (and every item below this) requires running code in the device to access.
- Display RAM (VRAM, OAM). This has the additional complication of timing restrictions.
- CPU registers. These are easy to access if you can run code in the device, but hard to preserve, because any attempt at doing so will destroy something else, and attempting to preserve something else first will destroy them.
- I/O and interrupt registers. These are the hardest part of the state by far. Many of them aren't readable at all (e.g., interrupt master enable). Many of them are completely inaccessible (e.g., internal halves of timers). Most of them can't simply be restored to their old state (e.g., audio registers: writing back the old values would restart the current sound). And some of them can't be restored at all (e.g., serial transfers).
There's a lot of special cases I'm not going over in that last category because just about everything is a special case. But one particular area of complexity is timing: many games (either accidentally or on purpose) rely on the internal synchronization of components, and thus the timing of every component must be identical when the game is resumed as it was when it was stopped. For instance, it would have to be resumed rendering the same exact part of the screen it was rendering when it was stopped.
But none of this matters when you can't get past the first hurdle: getting CPU access. The Game Pak bus is mostly one-way, where the CPU requests an operation (a read or a write) and the cart fulfills it. This is pretty standard: there's no reason for the cart itself to have any control of the system (that's why you put a program in it that gets loaded by the console), and giving the cart control of the device would require an immensely more complex interface. (This is not an "old consoles" thing; modern consoles work the exact same way.) In principle, the game's code could be executing from anywhere — it's perfectly legitimate to write code to RAM and run entirely from there, and if a game does this, the cart would no longer have any control of the code being run. A truly generic solution would meet a complete showstopper here; there is no way around this problem. But since (as far as I know) commercial games don't usually do this, let's imagine a more realistic scenario.
All data from ROM (or SRAM) is delivered to the CPU pretty much in real time. (Technically, one or two cycles in advance, but that doesn't make a difference here.) That means that if the game is executing code from ROM, as games normally do, the cart could just feed the CPU any code it wants to instead of the original. However, it's virtually impossible to determine (externally and in real time) if a given access corresponds to code or data, and feeding the CPU altered data could have disastrous consequences, so this technique can't be used without care. Some instructions are also two or three bytes wide, and these bytes are fetched one at a time, so the cart cannot know in advance whether it's returning the beginning of an instruction or some follow-up byte for it — meaning it can't blindly replace code even after knowing it really is code.
There is some hope, though. Most CPUs have something called interrupts — events that the CPU will detect that will interrupt the current flow of code and cause some special handler code (called an ISR (interrupt service routine), or more commonly an interrupt handler) to run instead. The Game Boy has five of them, and the handlers are at fixed addresses, starting at $0040. All of these addresses are in ROM! If the cart could know that an interrupt handler is about to execute, it could replace the handler's code with its own, and thus gain CPU access.
User programs (I'm not calling them "games" because there's no requirement for a cart to actually contain a game, after all) can choose what interrupts they use, though. And they'll almost never contain interrupt handlers for interrupts they never enable in the first place. If they don't use a particular interrupt, they may use that area of ROM for anything else (and this isn't as uncommon as it would seem), and we would be back to square one. Fortunately, one of the interrupts, the very first one (the VBlank interrupt), is very common.
CRT screens render images by shooting electrons at the screen in a pretty mechanical way: there is an electron beam that moves across the screen and renders each pixel. When it reaches the end of the line, it has to stop rendering pixels while it moves back to the beginning of the next line; this short render pause is known as the horizontal blanking period, or HBlank for short. Likewise, when the beam reaches the end of the screen (typically the bottom right corner), it has to move all the way up to the opposite corner to render the next frame; this significantly longer pause is the vertical blanking period, or VBlank. The Game Boy doesn't have a CRT screen, of course. But while the PPU (the component that does the actual screen rendering) is rendering pixels to the LCD, the CPU cannot access display memory at all; therefore, it needs some rendering pauses so that the CPU can access display memory and thus actually put data there. Nintendo chose to emulate the HBlank/VBlank model, already familiar to developers of CRT-screen-based devices, where these pauses are merely PPU delays so that the CPU will get a chance. VBlank takes up 10% of the time spent in every frame, and thus it is the moment where games will do almost all of their rendering to screen. Since this interval is so important, there is a dedicated interrupt that fires at the beginning of VBlank, letting user programs place their rendering code in the interrupt handler instead of having to manually track each frame's timing. And this interrupt is nearly universally used. So this particular interrupt is the best hope of getting the cart to run its own code on the Game Boy's CPU.
Hooking the VBlank interrupt also has two advantages. One, when an interrupt fires, the return address is pushed to the stack, so the stack must be usable — which makes it easier to be able to preserve CPU registers. And two, the PPU state is known, so there are no frame timing issues. This, of course, is assuming that the VBlank interrupt fires on time (which may not happen; interrupts may be enabled when there's a VBlank interrupt pending), that the handler isn't simply called, and so on. But we're talking about the optimistic scenario here.
So, let's assume we get all the conditions right. The game uses the VBlank interrupt, the interrupt is enabled, and nothing else reads from the handler's address. The user hits the savestate button on the cart (for the sake of the example we'll assume it's a physical button on the cart; using a key combination is much more complex), the cart waits, and a read for address $0040 is requested. The cart starts sending its own code to the CPU (instead of the actual ROM contents at $0040) and the code runs fine. The cart's replacement handler begins by pushing the CPU registers to the stack to save them, and this works just fine: there is enough room on the stack and no useful data is overwritten. So far, this scenario isn't particularly unlikely, so if this works out, we might have a solution that works for many games, if not most.
Except that this was just the first hurdle. The music playing will often rely on timers, which are hard to preserve and restore. RNGs often depend on the divider register, which is another internal timer that is very hard to preserve and restore. Audio registers themselves are mostly unreadable. On-going DMA transfers would be very hard to resume.
And finally, there's the problem of how to trigger a savestate in the first place. I mentioned a hypothetical savestate button on the cart. But these carts don't have a button, and no firmware update will manufacture a button out of nowhere. The only option is to trigger them based on some key combination. But this goes back to the "no access to the CPU" problem, because CPU access is needed to detect key combinations in the first place. There is a joypad interrupt, but this is unreliable in most contexts and rarely used; most games do their own joypad reading using code that could be anywhere in the ROM. Working around this would require per-game patches to even get going. These are on top of the per-game patches that would be needed to solve all of the problems mentioned in the previous paragraph (by restoring the state each game expects). All of these patches would be very custom and would have to be developed independently for every single game that could support the feature.
And if you're going to make complex edits to games to support savestates, why not just edit the games to allow you to save at any time instead without relying on a flash cart?
Everything works on GB Boy!!! There is nothing to write and to expect!
@
RedColoredStars:
@
SylverReZ:
