Emulation GBA emulator for GBA?

[FAST6191]

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.

 

[TecXero]

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.

Oh, I didn't even think of using its own passcode system. Well, I'm daft.

 

[FAST6191]

Oh yeah if you are doing to do some kind of quasi savestate or "branch to level 4, set ammo/health/lives/stats to ???? as that is what the player had before and then go" thing all inside a game's own code, like what normal saves actually work like, for a game that never had anything like that then it is going to be an absolute pig and would at the very least require you to have an extensive mapping of the game's memory if you did not just basically make an actual savestate and somehow load that back up.

 

[TecXero]

Oh yeah if you are doing to do some kind of quasi savestate or "branch to level 4, set ammo/health/lives/stats to ???? as that is what the player had before and then go" thing all inside a game's own code, like what normal saves actually work like, for a game that never had anything like that then it is going to be an absolute pig and would at the very least require you to have an extensive mapping of the game's memory if you did not just basically make an actual savestate and somehow load that back up.

Yeah, that's pretty much what I was talking about earlier. Then you just come in and and come up with a much simpler and better solution, making me feel foolish. I can't believe I didn't think of that, it seems so obvious now. Running on 3 hours of sleep for over 24 hours must not be doing my mind any favors.

 

[Sergey]

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.

That's a whole load of useful information and resources. Thank you! And yes, patching each rom individually is what TecXero was talking about earlier and as I said before I'm looking into getting my hands dirty with that as a starting point.

So if I understand correctly, if patching a specific game, say, LEGO Knights' Kingdom which uses passwords instead of savestates, so that from the password screen I could continue the last completed level by, say entering empty password, I need to find and patch the following bits:

- where password is printed to the screen; look for whatever progress state bits exist in memory and save that in SRAM

- where password is decoded. point the progress state reference to where progress state bits are saved in SRAM

Is it the direction?

 

[FAST6191]

Theoretically the SRAM is mapped to memory so I guess that could work, however I would lean strongly towards having some you code yourself fetch it out of SRAM, stick it in the location in normal RAM where the normal password entry screen would have stuck the password entered conventionally and then either automatically loading it or letting the user press enter to try to load it.
The two main reasons I would do that rather than repointing directly to SRAM is SRAM reads are slightly picky -- you need to wait a certain amount, you only read 8 bits at a time and other things (it is all in http://problemkaputt.de/gbatek.htm#gbacartbackupsramfram ). Nothing drastic that you can not hack a game to do but I would much rather hack in a read routine myself and then have the game carry on like nothing has changed. If that was not enough though then if the game tries something like decoding a checksum or something and is trying to do it directly in the SRAM then the waits and the possibility for pointer maths (common enough on the GBA -- C and C++ were common languages in game dev for it after all). If it is already in normal memory the game knows how to handle normal memory and you do not get troubled.

If you wanted some kind of crazy end game/boss rush type hack where it loads every time then yeah by all means try something tricky with a cheat or a ROM read but SRAM read protocol is likely to get in the way for actually making a functioning save system like you describe.

There is a possibility the printed data is different at some level to the decoded data, however it will basically have to be directly and mathematically related. In that case I would probably fix/alter either the read or the write function so it matches both sides but it should only be something simple like if a value is 16 bits in memory (because 16 bits is a useful thing in memory and memory is not at such a premium on the GBA) but only ever uses 4 the decoded password might truncate something, similarly you might see an invert or it might not put it all together in one nice memory value. Ultimately it would be annoying but it is still trivial binary manipulation that will need to be done. This is not secure computing though so there is no practical reason not to have the key/save in memory at some point so I do not imagine this will happen. This sort of thing tends to crop up more if you are putting item number values in via cheats and hoping the game will save it. I would certainly still start this off by finding the decoded password value at the password entry/decode screen and then searching for that in and around the time the password was first generated/displayed.

One possible other option is the password screen wipes the memory location as it loads in so as to have a blank password. This should not really pose a problem if you can handle the other stuff though.

 

[Sergey]

Theoretically the SRAM is mapped to memory so I guess that could work, however I would lean strongly towards having some you code yourself fetch it out of SRAM, stick it in the location in normal RAM where the normal password entry screen would have stuck the password entered conventionally and then either automatically loading it or letting the user press enter to try to load it.
The two main reasons I would do that rather than repointing directly to SRAM is SRAM reads are slightly picky -- you need to wait a certain amount, you only read 8 bits at a time and other things (it is all in http://problemkaputt.de/gbatek.htm#gbacartbackupsramfram ). Nothing drastic that you can not hack a game to do but I would much rather hack in a read routine myself and then have the game carry on like nothing has changed. If that was not enough though then if the game tries something like decoding a checksum or something and is trying to do it directly in the SRAM then the waits and the possibility for pointer maths (common enough on the GBA -- C and C++ were common languages in game dev for it after all). If it is already in normal memory the game knows how to handle normal memory and you do not get troubled.

If you wanted some kind of crazy end game/boss rush type hack where it loads every time then yeah by all means try something tricky with a cheat or a ROM read but SRAM read protocol is likely to get in the way for actually making a functioning save system like you describe.

There is a possibility the printed data is different at some level to the decoded data, however it will basically have to be directly and mathematically related. In that case I would probably fix/alter either the read or the write function so it matches both sides but it should only be something simple like if a value is 16 bits in memory (because 16 bits is a useful thing in memory and memory is not at such a premium on the GBA) but only ever uses 4 the decoded password might truncate something, similarly you might see an invert or it might not put it all together in one nice memory value. Ultimately it would be annoying but it is still trivial binary manipulation that will need to be done. This is not secure computing though so there is no practical reason not to have the key/save in memory at some point so I do not imagine this will happen. This sort of thing tends to crop up more if you are putting item number values in via cheats and hoping the game will save it. I would certainly still start this off by finding the decoded password value at the password entry/decode screen and then searching for that in and around the time the password was first generated/displayed.

One possible other option is the password screen wipes the memory location as it loads in so as to have a blank password. This should not really pose a problem if you can handle the other stuff though.

Got it. Will definitely take that in count. So in bare bones I need to implement the following:

- writing to SRAM when level is completed

- copying from SRAM to RAM on password screen and passing a reference to the new RAM location

Will have to go over some good tutorials before I begin. Will start with yours here: http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2014-edition-out.73394/ it looks very promising. Thank you a lot!

Are there any additional resources (preferably screencasts) you would recommend on?

 

[FAST6191]

no$gba debug is free these days so the old standby of http://www.romhacking.net/documents/361/is not so useful as it once was.
Alas assembly debugging/pondering is the kind of thing that does not take too well to videos, same with most ROM hacking really, so there are not many videos beyond specific techniques for specific games, and even those I tend not to highly rate.

Some of the pokemon hackers have some slightly odd ideas but they have some stuff on assembly if you fancy it.

 

[Sergey]

no$gba debug is free these days so the old standby of http://www.romhacking.net/documents/361/is not so useful as it once was.
Alas assembly debugging/pondering is the kind of thing that does not take too well to videos, same with most ROM hacking really, so there are not many videos beyond specific techniques for specific games, and even those I tend not to highly rate.

Some of the pokemon hackers have some slightly odd ideas but they have some stuff on assembly if you fancy it.

Got it. Thanks!

 

[DanTheManMS]

This won't help much, but the Flash2Advance Ultra had two physical buttons on it that you would use for real-time save and load. I tested it with Metroid Fusion and it worked pretty well! There was only enough room for one real-time save though, so while you could have multiple ROMs with the feature enabled, you could only use one at a time. Still, revolutionary for the time.

 

[Boured]

Hi guys,

Is there an emulator for GBA (like Goomba for .gb files) that can take a .gba file and wrap it with features like save/load a state?

Thanks

....A gba flashcart?

I mean it doesn't emulate it as it just uses the hardware to run and the flashcart just loads it into memory, so it's not emulation just playing games on the hardware using a different vehicle.

 

[The Catboy]

I thought this was a legit new thread, not a bump ಠ_ಠ

 

[hobbledehoy899]

Why would you emulate something when the emulator itself is running on the native hardware of the system it's emulating?

 

[FAST6191]

Easier access for extra routines usually, especially for things like this which do not really have any kind of operating system you could use instead.

 

[Aether Lion]

I thought something like this would work on the Vita where you emulate itself and therefore you'd be able to play backupped games.
If this idea works I need credit mmk fam?