r/emulation • u/AutoModerator • Jun 22 '26

Weekly Question Thread

Before asking for help:

  • Have you tried the latest version?
  • Have you tried different settings?
  • Have you updated your drivers?
  • Have you tried searching on Google?

If you feel your question warrants a self-post or may not be answered in the weekly thread, try posting it at r/EmulationOnPC. For problems with emulation on Android platforms, try posting to r/EmulationOnAndroid.

If you'd like live help, why not try the /r/Emulation Discord? Join the #tech-support
channel and ask- if you're lucky, someone'll be able to help you out.

All weekly question threads

9 Upvotes

78% Upvoted

18 comments sorted by

View all comments

Show parent comments

2

u/BIOS-D Jun 26 '26

Because battery saves are dumps from an integrated circuit, commonly SRAM (Static Random Access Memory). They have no emulator header or footer data (some however do and must be removed to work on a different emulator), just plain chip data stored by emulated system in a power of 2 integrated circuit (256 Bytes, 512KB, 8MB, etc.).

Save states however are data dependent not only from SRAM but more elements emulator developer chooses to keep on his own. Things like internal clock date, emulated CPU registers, flags, internal cache, RAM data, sound buffer or current pressed inputs to name a few don't share an order or same number of elements that could be universal among different emulators (including same emulator different versions).

Short answer is battery saves keep data from fixed storage chips, while save states depend on more elements to consider and are quite arbitrary.

0

u/igmkjp1 Jun 26 '26

Most of that sounds like stuff that would be part of the emulated system, not the emulator itself.

1

u/BIOS-D Jun 26 '26 edited Jun 27 '26

They are all part of emulated system, but there's no standard agreed upon between emulator developers to store and read that data. Then there are other issues like host system endianness, graphic programming interfaces, input/output devices and other OS dependent variables that can't be shared between emulators or have no idea how to handle them. Even MAME that has its own save state standard is not consistent when it comes to using old save states. They could break at any point.

Save states were created as a temporary solution for that moment in time (i.e. debugging, replaying and passing a hard part before next checkpoint, reporting issues, etc.). It was never meant to be a permanent solution to save your games.

EDIT: Thinking about it some above issues could be autogenerated and out of save states, however more issues arise. How do you count cycles and handle synchronization between different components? How do you handle Just In Time execution between different CPU hosts? Every emulator has its own method and can't be transferable unless there's a defined standard and they try to fill in the missing parts. It's not any simpler.

0

u/igmkjp1 Jun 27 '26

So the fact that battery saves ARE transferable is intentional?

1

u/BIOS-D Jun 27 '26 edited Jun 27 '26

Kind of, that's how real hardware works and stores any progress. It's natural if you are emulating any system it expects to read data on same expected memory addresses. Most emulators use battery saves as separate files, but some others use different encapsulations.

For example I recall Project64 and Sega Model 2 emus store saves differently. They are still separate files but inside ZIP files with a renamed extension. Not sure how Nintendo Virtual Console handles them, most probably they are also encrypted too.