ROM and SRAM have no simple bearing on each other as far as offsets (offset being the location of something in a file). If you can make a cheat then you can edit savestates fairly happily, to edit most game saves you will want to either edit the ROM (I can see someone maybe making a cheat to defeat a save check but it would be rare) to ignore the check or figure out how the check is done and make a tool to recalculate the check result. Some will edit savestates because of the lack of protection in them compared to SRAM game saves, and ease of figuring out what is there. Editing these tends to focus on that, though I should say it was a popular means of running exploits at one point in time (most systems today block it fairly well, and by the time you usefully could run an exploit from one then you have an exploited machine in the first place). SRAM is what the devs of the game chose to save for the player to continue with when they next play. It is able to do the most profound changes, compared to savestates which are whatever is loaded into memory or you can maybe trick it into loading next.
#SNES EMULATORS THAT LOAD SAVE STATES CODE#
This is what the game ultimately runs from (barring some technicalities with network loaded code and stuff like the DS sticking the binary in RAM). That probably covers your later questions but taking them anyway Sections of SRAM game saves being compressed, especially on epic RPGs with characters with 50 stats, permanent changes to the world and so on, is not unheard of either. I have seen savestates, and individual sections thereof, be compressed in the past. Sometimes the hardware makers will help things along (if the random state after powering on risks a crash then send a working value in there however you will). Sometimes these matter, often they don't or the game will autocorrect it after a glitch or two.
If you have hardware derived savestates (various things have had this from the minicomputers right through to the GBA and DS) then not all memory might be accessible there is such a thing as write only memory, and there is read only memory/registers. Any variation in these (do you put the registers first and the memory second, intersperse it, this area is technically never used so is there a need to include it.) will obviously make the incompatible with each other, though trivial to convert once you have the differences. Most of the time emulator authors will take the contents of memory, stick it end to end, stick any registers that are not in memory in there somewhere and call it a savestate. Savestate formats have no defined format. Any checks here are the same ones that will trouble cheats as they are operating on the same thing really. Or if you prefer you save the entire state of the machine being emulated/simulated/whatever. Said people will also often have a header/footer added, and as these are the things you will typically get from gamefaqs (indeed they have or maybe had a rule about getting things from emulators).Ī copy of the contents of memory (give or take the parts of the memory dealing with the ROM itself), registers, CPU state and so forth. have been known to encrypt them as well, mostly this is when they sell access to a service but not always. Some save dumpers like those from Datel/gameshark/action replay/codebreakers/. To write an emulator you have to be a fairly competent coder and such people will know this, as such may provide some support but don't count on it.
Said header or footer can trouble some things (flash carts, some other emulators and such) and extra compression almost certainly will. Typically this is done so you might be able to figure out what it is for - if you have a file called 01.sav then you might have no idea what game it is for, the original dev would not have cared to add any indicators as the save is only going to be on your local copy of the game. Some emulator developers add their own header or footer to a save, or compress them beyond what might have been done by the devs. Said SRAM saves will tend also to have some kind of check done on them to see if they have been changed or developed an error. Some things may be lacking (I am sure we have all had games fill health after loading, or lose pickups upon loading.). Usually a condensed version of what is in the game as decided upon by the devs. (can also be other formats like EEPROM and Flash depending upon the game/system, hence some preferring terms like save games and game saves but I will ignore that for now)