[pam22]

What is the difference between SRAM and savestates? What are the differences between savestate formats? What is the difference between changing values in a ROM file and SRAM/savestates?

If you were to find offset values in a ROM file, are those the same values in SRAM? How are those different in savestate formats?

Any information or resources would be appreciated, thank you.

[FAST6191]

SRAM. (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)
Usually a condensed version of what is in the game as decided upon by the devs. Some things may be lacking (I am sure we have all had games fill health after loading, or lose pickups upon loading...). 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 emulator developers add their own header or footer to a save, or compress them beyond what might have been done by the devs. 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. Said header or footer can trouble some things (flash carts, some other emulators and such) and extra compression almost certainly will. 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.
Some save dumpers like those from Datel/gameshark/action replay/codebreakers/.... have been known to encrypt them as well, mostly this is when they sell access to a service but not always. 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).

Savestates
A 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. Or if you prefer you save the entire state of the machine being emulated/simulated/whatever. Any checks here are the same ones that will trouble cheats as they are operating on the same thing really.

Savestate formats have no defined format.
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. 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.
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. Sometimes these matter, often they don't or the game will autocorrect it after a glitch or two. 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).
I have seen savestates, and individual sections thereof, be compressed in the past. 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.

That probably covers your later questions but taking them anyway
ROM file.
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). 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.
SRAM is what the devs of the game chose to save for the player to continue with when they next play. 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).

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. 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.

ROM and SRAM have no simple bearing on each other as far as offsets (offset being the location of something in a file). Technically you could analyse the ROM such that you know how it uses the save format but that is an awful lot of quite hard work.
Savestates, as mentioned before, are a copy of the contents of memory. I don't think generalisations are terribly useful here
I have seen plenty of games just copy a chunk of memory (or several chunks) directly into the save, hash it and call it a day.
I have equally seen plenty of games take an aspect of memory, do some crazy maths on it, stick it in a save, do the same for a bunch of other aspects, hash that and carry on with life.
I have seen games recalculate stats after load -- if you gain one health per level and you are level 50 then no need to store the health value if you have the level one. On the other hand the game may not want to do that every time so your savestate editing may well have a means to give you a far greater max health without worrying the level value.
I have seen games use trivial saves like mentioned above but have serious anti cheat in their memory (mirror values, inverted values, alternating locations...) and vice versa games have hideous saves but simple memory.

Likewise editing a savestate (or making a cheat which is more or less the same thing) can be an easy way to edit the contents of SRAM. Say I want a save with 256 potions in it. I could figure out the save format (would take a little while but doable enough), figure out the hash format and either make a tool to do it or the steps to do it manually, fair bit of work really. Alternatively I could make a cheat (standard cheat finding thing of get say 100 potions, use one, search, do nothing in the game but use another potion, search.... eventually find the RAM location, set the value to 256 or make a cheat to do the same, load my save I want to edit, have the cheat run/edit the memory myself, save the game and have it handle all the putting it in the right place and hashes.

I am starting to waffle and what started out quite clean and concise is getting extra sections added in so I will cut it off there for now.

[Psyklax]

Let me try to be a tad more concise.

Consoles have RAM, cartridges have SRAM. The main idea is that once you turn off the power, RAM is wiped clean, but if you provide some power from a battery, you can keep SRAM indefinitely. Some consoles like the Sega CD have SRAM because they need to save your games.

Save states save whatever is in the RAM, but generally the cartridge SRAM is included in that. Take the NES: the ROM is accessed between $8000 and $FFFF (or a few bytes before the end). SRAM is accessed between $6000 and $7FFF (ish). Between $0000 and $5FFF is where all the console's stuff is accessed: the internal RAM, various registers and so on. A save state just takes all of that and saves it to a file.

If you edit RAM, it'll stay like that until an instruction changes it. If you edit a ROM, it'll stay like that forever, because it's Read Only Memory.

Any offsets in a ROM may or may not be the same in RAM, it depends. Different systems, different situations. Save states may vary between emulators, but SRAM files are usually the same, since it's just the SRAM, nothing more. I've ported SRAM saves between emulators before.

Bottom line is that if you want permanent things, learn assembly and hack the ROM. Hacking SRAM files is fine if you aren't so proficient, and just want to do something like cheat in a game.

Any questions, I'm all ears.

EDIT: I might be incorrect about the NES not using SRAM internally, but I think it's a bit of a misnomer anyway. SRAM just means it's Static, so it doesn't need refreshing (ideal to sit on a cartridge untouched for years) while DRAM is Dynamic, so it needs refreshing or it disappears. It doesn't really matter though.

[Disch]

EDIT: I might be incorrect about the NES not using SRAM internally, but I think it's a bit of a misnomer anyway. SRAM just means it's Static, so it doesn't need refreshing (ideal to sit on a cartridge untouched for years) while DRAM is Dynamic, so it needs refreshing or it disappears. It doesn't really matter though.

Sorry, this is a total sidetrack.  I'm asking because I know very little about different kinds of RAM and I'm curious.

What exactly is "refreshing" in this context?  That means it needs a constant power source, right?

If that's the case then I don't think there was any SRAM on older consoles, as AFAIK that wasn't really a popularized thing until thumb drives and SSDs.  Everything prior to that was some kind of magnetic storage device, or required a battery to keep memory refreshed.  Specifically, any NES or SNES cart that wanted a save game NEEDED a battery to keep the RAM alive.

Or is my understanding completely incorrect?

Again... sorry for the sidetrack.  I'm fuzzy on all this stuff but I find it interesting.   

[KingMike]

Well, on the Famicom I think Bandai was the only company using EEPROMs to store save data.
Didn't you guess how that worked in your private emulator you wrote years ago? (I don't know if that has been supported in any publicly available emulator.)
(if it was never confirmed, I imagine it would be by someone wanting to do it for science Bandai isn't exactly the most favorite publisher for the console and the SD Gundam RPGs are considered average at best, even though I'm interested in them)

[Psyklax]

What exactly is "refreshing" in this context?  That means it needs a constant power source, right?

Nope, refreshing is something else. To quote Wikipedia:

"each bit of memory data is stored as the presence or absence of an electric charge on a small capacitor on the chip. As time passes, the charges in the memory cells leak away, so without being refreshed the stored data would eventually be lost. To prevent this, external circuitry periodically reads each cell and rewrites it, restoring the charge on the capacitor to its original level"

So with DRAM you need to constantly and actively write and rewrite to memory, otherwise it disappears, but with SRAM, you can just stick a battery to it and call it a day, because it'll stay there as long as there's a power source.

As Wikipedia says, DRAM was cheaper but needed refreshing, while SRAM was pricier but didn't. Hence, computers with lots of on-board RAM would use DRAM and just use a circuit to refresh the memory.

[Jorpho]

Hacking SRAM files is fine if you aren't so proficient, and just want to do something like cheat in a game.

Worth noting, however:

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.

There is unfortunately no way of knowing in advance if an SRAM save has an internal checksum, much less any way of knowing how that checksum is calculated.  There's one specific example available for Final Fantasy V:
https://www.romhacking.net/documents/627/

As noted therein, in such cases you may be able to hack the ROM to disable the checksum verification rather than reverse-engineering the algorithm.

Savestates, on the other hand, are much less likely to have any such protections.

[KingMike]

As noted therein, in such cases you may be able to hack the ROM to disable the checksum verification rather than reverse-engineering the algorithm.

Well, checksum algorithms are usually simple enough that if you know ASM (which you probably would need to in order to find the routine in the first place) you could easily recreate them, if you were making an editor.

If you're trying to cheat then yes, savestates would be the better option (though those are emulator-specific and often even version-specific).

[Disch]

Well, on the Famicom I think Bandai was the only company using EEPROMs to store save data.

Yeah but that's not RAM so I forgot about it 

So with DRAM you need to constantly and actively write and rewrite to memory, otherwise it disappears, but with SRAM, you can just stick a battery to it and call it a day, because it'll stay there as long as there's a power source.

Okay, but then I'm still a little confused.

With SRAM, what is the battery/power doing if it's not reading/writing the memory?  I mean there still has to be a circuit because that's how electricity works, and the circuit must pass through the memory, right?  Otherwise what's the point?

My understanding of how RAM physically works is very minimal, so my apologies if this is a dumb question.  I guess I could try to look this up myself, but I'm too lazy.  XD

Thanks.

[Psyklax]

With SRAM, what is the battery/power doing if it's not reading/writing the memory?  I mean there still has to be a circuit because that's how electricity works, and the circuit must pass through the memory, right?  Otherwise what's the point?

All I know, I know from Wikipedia et al.

From five minutes reading the articles on DRAM and SRAM, it appears that the reason it's called Static RAM is because when you write to a memory address, it stays there. But it's volatile because if there's no power, it's all gone. So the battery basically gives it a teeny tiny bit of power, enough to hold the information, and as long as that battery has a charge, it will keep the data.

DRAM doesn't work that way: even with a charge, it will degrade, and lose the information. So you need to have a circuit that refreshes it (reads it and rewrites it) constantly, just to keep it in memory. Computers used this because it's cheaper than SRAM, and putting the circuit in there working while the machine is on is a no brainer.

Don't ask me how the data stays on SRAM, that's beyond my understanding. All I know is that if a cartridge used DRAM to store a save game, it wouldn't work, unless you built a refresh circuit into the cart, which would be silly. Given the tiny amount of data necessary to save, SRAM is economical, but using it for on-board RAM wouldn't be cost effective.

Again, I'm no expert, I just like reading about these things.

[Disch]

Okay I think the word "circuit" was throwing me off.  I was thinking like how anything using an electrical current is a circuit -- but you mean like having some kind of logic gates or mini-processor that actually probes memory.

Alrighty!  Thanks.