How to convert FECUX to other NES emulators savestates?

[GAPMan]

I am currently using an old version of an FCEUX emulator of a Mega Man 3 playthrough. The thing is, I want to convert my savestate so that I can use load it in something more accurate. How can I do this? How do convert a FECUX 2.3.0 savestate to more accurate emulators like puNES, Nestopia or Mesen?

 

[FAST6191]

I assume you checked to see if there is an existing tool. I have seen some for other emulators of other platforms.

Anyway a savestate is nothing but a dump of the RAM, CPU registers, CPU state, IO, whatever the cartridge has here (some NES mappers will add more interesting things) and basically everything that is used in the runtime of a system. For a PC emulator then you get everything, for some consoles done internally then some things are write only and things get to be made up so we can skip that one for today.
For the most part on the NES then everything listed above is in some way in the main memory bus (other consoles might have things separately). To that end most emulators, flash carts and whatever else will dump everything listed above in order.
The differences then come in how much padding is put between sections (for some purposes in some languages/computers having a data section start on a particular alignment/multiple is faster so some will waste the space to achieve it, or indeed it might be that way in your emulator's memory*), byte order (less of an issue as you tend to want to mimic what is there but still could be one) and some things to come below that might be referred to as metadata or meta concepts.
Some emulators will add a small header/footer to note what ROM it belongs to and maybe some other metadata, some will add internal emulator states (occasionally even necessary in later devices where some kind of dynamic recompilation might be in action), and some will be geared to different flavours of the system (if the emulator supports both the famicom and FDS on top of the baseline western NES then it might make sense to gear savestates for that/any extras that will be present for that and load accordingly). Some emulators will also compress things (possibly with a flag/note to say this one is compressed so act accordingly) but that is less of a concern for the NES, and most times there will be an option somewhere to disable that (it makes it hard for savestate hackers to do things so it tends to then be optional) and even then most of the time it is a basic scheme rather than anything radically custom as it has to happen in real time and space savings are not going to be that great if you did go fancy.

*the average system in my experience has the ROM plus any save in a fixed location either before or after everything else. Consequently a quick and easy savestate might be dump memory as it is in the emulator rather than go section by section).

You can determine this all experimentally easily enough* and people have in the past (around here trying to convert flash cart savestates to emulator ones and vice versa). It is however noted FCEUX is open source ( https://github.com/TASEmulators/fceux , not sure if versions change things but it is less common) and chances are your target is as well (accuracy focused emulators often are). Your main problem might be different mappers if you get into the truly exotic stuff and one or the other emulators does not support it, anything in the seal of approval plus Tengen world should be fine though and it is more modern homebrew efforts and random pirate multicarts that will be the trouble.

*fill each independent area with some notable value series (DEADBEEF, D00GF00D https://nedbatchelder.com/text/hexwords.html if basic AAAA.... BBBB.... CCCC... does not work or you face byte order issues).

If you wanted to learn programming then this is a wonderful learning project for that (simple enough but not so simple as to be boring, and with tangible results in the end) for pretty much any language you care to employ. Alternatively once you know where the sections are in the source you could probably halt the emulator, insert everything back in with a hex editor that supports memory editing (not all will but many do, including free ones), resume emulator and have it go from there.

 

[elk1007]

For a game without battery saves like MM3, your best option is to get the password instead of trying to convert a save state between emulators.
Using the password will take less time than reading the post above mine.

 

[GAPMan]

For a game without battery saves like MM3, your best option is to get the password instead of trying to convert a save state between emulators.
Using the password will take less time than reading the post above mine.

You may be right. The above option is complicated but I really do not want to lose progress.

I assume you checked to see if there is an existing tool. I have seen some for other emulators of other platforms.

Anyway a savestate is nothing but a dump of the RAM, CPU registers, CPU state, IO, whatever the cartridge has here (some NES mappers will add more interesting things) and basically everything that is used in the runtime of a system. For a PC emulator then you get everything, for some consoles done internally then some things are write only and things get to be made up so we can skip that one for today.
For the most part on the NES then everything listed above is in some way in the main memory bus (other consoles might have things separately). To that end most emulators, flash carts and whatever else will dump everything listed above in order.
The differences then come in how much padding is put between sections (for some purposes in some languages/computers having a data section start on a particular alignment/multiple is faster so some will waste the space to achieve it, or indeed it might be that way in your emulator's memory*), byte order (less of an issue as you tend to want to mimic what is there but still could be one) and some things to come below that might be referred to as metadata or meta concepts.
Some emulators will add a small header/footer to note what ROM it belongs to and maybe some other metadata, some will add internal emulator states (occasionally even necessary in later devices where some kind of dynamic recompilation might be in action), and some will be geared to different flavours of the system (if the emulator supports both the famicom and FDS on top of the baseline western NES then it might make sense to gear savestates for that/any extras that will be present for that and load accordingly). Some emulators will also compress things (possibly with a flag/note to say this one is compressed so act accordingly) but that is less of a concern for the NES, and most times there will be an option somewhere to disable that (it makes it hard for savestate hackers to do things so it tends to then be optional) and even then most of the time it is a basic scheme rather than anything radically custom as it has to happen in real time and space savings are not going to be that great if you did go fancy.

*the average system in my experience has the ROM plus any save in a fixed location either before or after everything else. Consequently a quick and easy savestate might be dump memory as it is in the emulator rather than go section by section).

You can determine this all experimentally easily enough* and people have in the past (around here trying to convert flash cart savestates to emulator ones and vice versa). It is however noted FCEUX is open source ( https://github.com/TASEmulators/fceux , not sure if versions change things but it is less common) and chances are your target is as well (accuracy focused emulators often are). Your main problem might be different mappers if you get into the truly exotic stuff and one or the other emulators does not support it, anything in the seal of approval plus Tengen world should be fine though and it is more modern homebrew efforts and random pirate multicarts that will be the trouble.

*fill each independent area with some notable value series (DEADBEEF, D00GF00D https://nedbatchelder.com/text/hexwords.html if basic AAAA.... BBBB.... CCCC... does not work or you face byte order issues).

If you wanted to learn programming then this is a wonderful learning project for that (simple enough but not so simple as to be boring, and with tangible results in the end) for pretty much any language you care to employ. Alternatively once you know where the sections are in the source you could probably halt the emulator, insert everything back in with a hex editor that supports memory editing (not all will but many do, including free ones), resume emulator and have it go from there.

I will give that a shot when I have the chance.

 

[InZaneGamer84]

Bump!

This seems like a good candidate for a new? "save-state conversion" tool!

In Python of course...

I'm going to look into this. Starting with NES save-states.

Thoughts on feasibility?

 

[FAST6191]

Python is well suited to minor file reorderings, byte order tweaks, padding out things, compression and such like (it is probably its main job in the computing world at large) which is what this tends to entail until you run into either dynamic recompilation emulators that retain info and might not share a common format or emulators that cover multiple regions that might have different hardware (NES and famicom, or maybe famicom disk system, if sticking with NES) with the more complicated of the devices being assumed to be the base case and anything not present in the simpler (and generally more popular) system being blanked out, or the write only hardware derived savestates (the DS seeing this with its 3d having several write only areas, not a problem for a PC emulator but a flash cart making a savestate faces a different issue).

Whether you try to make a universal case such that people can do plugins for new emulators, revisions and such like is up to you. That would be harder and probably end up almost back at another programming language which is fine if your base program is in C or something low level but kind of redundant for something as relatively easy to get to grips with as python (understanding byte ordering and the general workflow for figuring out savestate formats if there is no source code to look at is probably a greater hurdle than fiddling with some python to say put this memory section down first in the new file rather than in the original order).