Feature: relative path support for savestates

[johnnovak]

In portable mode, path names in the configs are relative to the configuration directory when they are on the same drive. This is very good as this makes the configs portable between machines, or you can freely move your whole portable installation to any other root directory.

Savestates, however, always use absolute paths as far as I can tell. This makes them very rigid. Let's say you change the parent directory of your portable WinUAE installation, and you store the disk and HDD images within the portable WinUAE directory structure. Then suddenly all your savestates would be broken. This also makes it impractical to share savestates with other people who use WinUAE in portable mode with a well-defined directory stucture for the disk and HDD images within the WinUAE folder (that's my primary problem here).

One obvious solution would be to simply use the same config-relative path lookup mechanism for the savestates too when WinUAE is in portable mode:

• If the config file and the referenced disk image, HDD image, or directory hard drive are on the same host drive, write a relative path to the savestate.
• If they're on different drives, write an absolute path.

[tonioni]

Disk images already save both relative and absolute path and restore "fixes" the path when loaded (if possible). Please include example file and description what goes wrong?

[johnnovak]

Ok, you're right, and I managed to narrow down the problem. This happens because the path to the statefile gets saved as an absolute path into the config. Once I fixed up the statefile value in the config so it's a relative path (or the correct absolute path), the statefile gets loaded correctly when double-clicking on the config and everything works as expected.

So my bad, nothing is wrong with the statefile -- it's a config writing issue.

Just I poked around in the statefile a bit with a hex editor and saw some absolute paths. But as you just said, you're saving both the absolute and the relative paths of the mounts in there.

Relevant excerpt of my test config below. I can reproduce this every single time by saving a new statefile using "Save state" in the Miscellanous tab, then saving a new config. So I think you don't need anything else from me to reproduce.

filesystem2=rw,DH0:System:..\System-1.3,0
uaehf0=dir,rw,DH0:System:..\System-1.3,0
filesystem2=rw,DH1:MonkeyIsland1:"..\Games\Secret of Monkey Island, The\Harddisk",0
uaehf1=dir,rw,DH1:MonkeyIsland1:"..\Games\Secret of Monkey Island, The\Harddisk",0
[...]
statefile=D:\!amigaaaaa\RML-Amiga\Games\Secret of Monkey Island, The\Savestates\TestSaveState1.uss

So once I change it to relative, it all 100% works:

statefile=..\Games\Secret of Monkey Island, The\Savestates\TestSaveState1.uss

Related question, how stable are the savestates at this point? For fun, I experimented with loading 5.2.0 beta savestates into 4.9.x and vice versa, and I didn't run into any issues. Any weird issues to be aware of? E.g., don't load WinUAE 32-bit savestates into a 64-bit version, or is the savestate format internal WinUAE data structure agnostic at this point?

Thanks Toni!

[tonioni]

Fixed. statefile (and few others) used string save method instead of correct path save method that handles absolute/relative paths automatically.

32-bit/64-bit makes no difference to statefiles (they only store Amiga data which is always 32-bit only) and even most statefiles from 0.x days are still compatible as long as configuration is first manually set to match config which was used when statefile was created.

A500 statefiles should never have any problems, A1200 (68020+) state files can have problems if CPU internal timing changes in some updated. Statefile tries to store the exact state of CPU if it was mid-instruction but that requires CPU works mostly identically when saved and when loaded.

Most expansion devices don't support statefiles.

[johnnovak]

Thanks for the quick fix and the detailed reply @tonioni!

That's very good news about the savestates. My main use of savestates in my gamepack is to offer users a way to skip the extremely annoying manual-based copy protection checks in some games (e.g. all Delphine games). So I'll provide configs such as Future Wars [skip code check]. Those will always work then as the savestate is bundled with the config.

Will keep that in mind about the A1200, but 95% of the games will just run on an A500, some from a HDD setup that can be HD-installed cleanly without hacks.

People need to be a bit careful when using savestates for HDD games for their own purposes, of course, but I'm only using directory mounts which mitigates the data corruption problem, and all HDD games I've tried don't seem to cache the HDD's contents so it should be generally safe (e.g. when you open a load game dialog, it always looks at the actual filesystem).

[johnnovak]

Tested and confirmed working 👍🏻