Fixing Emulator Save Files Whose In-Game Clock Drifts or Resets
A non-destructive RTC troubleshooting workflow covering save provenance, host time, core format, latch and halt state, state conflicts, migration, and proof.
When an emulated game’s clock resets, drifts, or jumps after restart, the ROM may be correct while RTC state is missing, unreadable, or overwritten by an old save state. Battery-backed memory and clock metadata can live in separate files or one core-specific format. Preserve every candidate before testing; opening and closing the emulator can overwrite the best recovery copy.
Freeze the evidence
Close the emulator cleanly, then copy the save directory with timestamps and hashes. Record ROM hash, core/emulator name and version, platform, content path, save path, configured timezone, host wall time, and whether automatic cloud sync is active. Duplicate filenames from different regions or revisions can collide if the frontend keys saves only by basename.
Identify battery/save RAM, RTC sidecar, save states, autosaves, and cloud-conflict copies. Do not rename them in the only directory. Work on a copy with networking/sync disabled and keep the original read-only.
Separate clock policy from corrupt storage
First verify the host’s date, time, timezone, and synchronization. A cartridge RTC generally advances by elapsed time, so changing timezone alone should not add hours unless the emulator stores local civil time incorrectly. A host clock moved backward can create a negative elapsed interval; note whether the jump matches the host adjustment.
Start a new temporary game with the same core, save normally, exit, wait a known interval, and reload. If the test clock advances, the core’s basic persistence works and the old file or path is suspect. If it resets too, inspect permissions, sandbox access, read-only directories, save-on-exit errors, and core/frontend version changes.
Check logs for exact read/write paths and sizes. A zero-byte file, wrong expected length, or write to a different directory is more actionable than editing binary values. Ensure the emulator can atomically replace the save and that antivirus, sync, or backup tools do not race it.
Respect hardware clock semantics
RTC cartridges can include halt, carry, day-counter, and latch bits. A legitimately halted clock is not fixed by adding host elapsed time. A day counter that overflowed may set a carry flag visible to the game. Use format documentation or the emulator source before changing bytes; different cores can serialize registers and timestamps differently despite using the same .rtc extension.
Do not download a “blank RTC” or copy one from another title. If migration is required, use the core’s documented conversion or write a reproducible parser that validates magic/version, preserves save RAM, and emits a new file. Retain before/after hashes and never overwrite the only original.
Resolve save-state conflicts
Loading a months-old save state may restore old RTC registers and battery memory, then autosave them over current persistent files. Disable automatic state loading, start from the normal in-game save, and observe. If the normal save is correct, archive incompatible states and change the frontend policy so state load cannot silently commit older persistent data.
For netplay, achievements, movies, or deterministic replay, confirm whether the frontend deliberately fixes the RTC epoch. That controlled clock is a feature, not drift. All participants need identical core, content hash, save hash, epoch, and timing policy.
Verify across power cycles
Set an identifiable in-game time, save through the game, exit, record file hashes/timestamps, wait, relaunch without a state, and compare expected elapsed time. Repeat after host sleep, reboot, timezone change, and an emulator update on copied data. Confirm unrelated progress remains intact.
The durable repair identifies which layer owns time—host, emulated registers, persisted epoch, frontend state, or sync—and changes only that layer. With immutable originals and a small controlled experiment, clock problems become a format/lifecycle diagnosis rather than binary-file guesswork.
Related:
- Cartridge Mappers and Bank Switching: How Consoles Addressed Games Larger Than Memory
- Battery-Backed Save RAM and Real-Time Clocks: Persistent State Beyond Save States
Sources: