Yes, there was battery-backed SRAM, and then there was regular SRAM. Regular SRAM was volatile: it would be guaranteed to survive the CPU reboot instruction, but wouldn&#x27;t survive poweroffs. Only some consoles had it; these were usually the same ones with a really slow bus speed for the battery-backed SRAM. (And other consoles, like the C64, actually <i>didn&#x27;t clear main memory</i> on CPU reboot; on these consoles, you&#x27;d instead manually cycle through clearing everything <i>except</i> what you wanted to keep, and <i>then</i> reboot.)<p>In later consoles that had their own MMUs, like the PSX, this wasn&#x27;t a full hardware feature anymore, but rather a simulated convention. You&#x27;d &quot;reboot&quot; by dropping all your virtual-memory mappings except one, then asking the disk to async-fill some buffers from the binary you wanted to launch and then mapping those pages and jumping into them on completion. (Basically like unloading one DLL and then loading a different one, except you&#x27;re also forcefully dropping all the heap allocations the old DLL made when you unload it.)<p>In both the hard and soft implementations, the &quot;volatile SRAM&quot; page could be thought of as basically a writeback cache for the state in the actual battery-backed SRAM. You wouldn&#x27;t want to do individual byte-level writes to SRAM (writes to SRAM were <i>slowwww</i>), so when the game booted, you&#x27;d mirror SRAM to your state-page, and then update the state-page whenever you had something you wanted to persist—finally dumping it out to battery-backed SRAM when the player hit &quot;Save&quot;. Basically, most games were &quot;auto-saving&quot; from the beginning—but they were auto-saving to volatile memory.<p>But even games that had true &quot;auto-saving&quot;, like Yoshi&#x27;s Island, still kept an &quot;SRAM buffer&quot; like this; the write-to-SRAM event was just managed as a sequence of smaller bursts of memory-mapped IO done by modules that sat there playing music+animations and not doing any logic, like YI&#x27;s &quot;field&#x2F;title card&quot; submodule when re-entered from a loss-of-life event, or its &quot;field&#x2F;score card&quot; submodule entered by completing a stage. If there is ever what seems to be a &quot;pointlessly long&quot; animation in an auto-saving game of that era near a state-transition, it&#x27;s probably by design, to cover for an SRAM cache-flush. (The fact that flashy &quot;rewarding&quot; animations turned out to also be good game design, favored by slot-machine and casual-game designers the world over, is <i>mostly</i> coincidence.)<p>---<p>ETA: when you had neither kind of SRAM, but still wanted to preserve some state across a reboot, what could you do? Well, write it to video memory, of course!<p>On a system with a PPU, the PPU owned the VRAM; it wasn&#x27;t the CPU&#x27;s job to reset it, but rather the PPU&#x27;s. On a system with only a framebuffer, <i>nothing</i> owned the framebuffer (or rather, the framebuffer was an inherited abstraction from the character buffers of teletypes: the &quot;client&quot; owned the framebuffer, so it was up to the &quot;client&quot; to erase it. Restarting a mainframe shouldn&#x27;t forcibly clear all its connected teletypes; disconnecting from an SSH session shouldn&#x27;t forcibly clear your terminal, but rather <i>optionally</i> clear your terminal as a way your TTY driver is set to respond to the signal; etc.)<p>Either way, if you could get your data into VRAM generally or the framebuffer specifically, you could very likely read it back after reboot.<p>VRAM is also where many &quot;online&quot; development suites—the BASICs and Pascals of the time—expected you to write exception traces. Rather than trying to &quot;break into&quot; a debugger (i.e. cram a debugger into the same address space as your software), you&#x27;d simply have your trap-handler persist the stack-trace to VRAM, switch your tape drive over to the devtools disk, and reboot. The &quot;monitor&quot; would load, notice that there&#x27;s a stack-trace in VRAM, parse it, read the pages it mentions from your program (now on the slave tape) and display them.