General theory of operation.
A password is just a more human readable version ( http://uk.ign.com/cheats/games/worms-2-pc-3143 ) of binary data, or on very rare occasions a kind of unlock. You can not store a great deal of info, indeed many games will lose things using passwords (Road Rash on the megadrive/genesis and it losing the weapons you have being a nice example) but if all you are storing is "levels 1-5 done, upgrade levels ? on *", or you can otherwise generate things back then it is not that bad.
Entering it into the password decoder will then decode said password back into binary, probably check that it is OK and then launch it. You then instead tell it to read from the SRAM location (probably not a single read memory instruction but nothing drastic), put that the decode position and run/branch to the decode routine. You probably would not even have to know the checksum or what each part of the password reflects in the game.
http://problemkaputt.de/gbatek.htm#gbacartbackupsramfram for the SRAM protocol. If you were really good you would make it work a la flash carts right away, or at least make it so patchers will work.
Getting it into SRAM in the first place would be marginally more annoying, though with an appropriate savestate in the emulator I imagine it would be but a few minutes. Personally I would savestate before the password is generated/displayed and then figure out where things might be in memory, automatically fire that into SRAM and call it a day.
Again if you want to remove the password screens, change menu option names, have multiple saves and more fun things it will be a pain and you will have to do a lot more work but adding such a thing should not be too hard.
For things like the NES, SNES, GB/GBC and such you will tend to only see it for games that had it in other regions, had it disabled before release/after beta, for very simple games that do not have all the fun bankswitching and whatever else but actually the theory of operation is not that much different. Here is one for the GB to get high scores to stick in Tetris ( http://www.romhacking.net/forum/index.php?topic=17979.0 ). Likewise implementing a save for a game that never had anything of the sort (think old commodore/I will leave it on over dinner/night to keep my game sort of thing) might well be a nightmare unless you can figure out how to restore enough of the game's memory info to get it running properly again.
A password is just a more human readable version ( http://uk.ign.com/cheats/games/worms-2-pc-3143 ) of binary data, or on very rare occasions a kind of unlock. You can not store a great deal of info, indeed many games will lose things using passwords (Road Rash on the megadrive/genesis and it losing the weapons you have being a nice example) but if all you are storing is "levels 1-5 done, upgrade levels ? on *", or you can otherwise generate things back then it is not that bad.
Entering it into the password decoder will then decode said password back into binary, probably check that it is OK and then launch it. You then instead tell it to read from the SRAM location (probably not a single read memory instruction but nothing drastic), put that the decode position and run/branch to the decode routine. You probably would not even have to know the checksum or what each part of the password reflects in the game.
http://problemkaputt.de/gbatek.htm#gbacartbackupsramfram for the SRAM protocol. If you were really good you would make it work a la flash carts right away, or at least make it so patchers will work.
Getting it into SRAM in the first place would be marginally more annoying, though with an appropriate savestate in the emulator I imagine it would be but a few minutes. Personally I would savestate before the password is generated/displayed and then figure out where things might be in memory, automatically fire that into SRAM and call it a day.
Again if you want to remove the password screens, change menu option names, have multiple saves and more fun things it will be a pain and you will have to do a lot more work but adding such a thing should not be too hard.
For things like the NES, SNES, GB/GBC and such you will tend to only see it for games that had it in other regions, had it disabled before release/after beta, for very simple games that do not have all the fun bankswitching and whatever else but actually the theory of operation is not that much different. Here is one for the GB to get high scores to stick in Tetris ( http://www.romhacking.net/forum/index.php?topic=17979.0 ). Likewise implementing a save for a game that never had anything of the sort (think old commodore/I will leave it on over dinner/night to keep my game sort of thing) might well be a nightmare unless you can figure out how to restore enough of the game's memory info to get it running properly again.