About savestates ...

[giantclambake]

This is another feature I'm just getting to...

From the wiki -> In this panel, you can create new Save States or Load existing ones that you have previously saved.

..that isn't pointing out the fact that the emulation must be running, to be able to load/save the .uss file. It's a given the emulation must be running to save a Savestate file, however, the emulation must be running (using the same disk/config.uae that relates to the .uss file), before you can load the Savestate file (an error msg pops alerting user to this fact, if you try to load a Savestate without emulation running)... I know ; I tried doing the same thing ~ this is likely because I'm used to doing that, with virtual machine 'snapshots', wherein you just load the snapshot directly and boot straight to desktop, rather than go through the (guest) OS bootup sequence.

From the wiki -> The filename for the save states is based on the currently loaded configuration or floppy disk

This is at odds with Savestate helptext of Savestates are stored with the name of the disk in drive DF0

Question: I take it the wiki is correct? ...ie; both same configname.uae or same floppy-image name in DF0: work here?
.
.
.
How would I use the Savestate function? Something akin to how I use the VM snapshot function ... example case;

• the Pimiga3 default workbench harddrive directories, copied to this amd64 bookworm system, with attached config.uae

caveat: no JIT with PLATFORM=x86-64 but afaik the config is set to have emulation go fast as it can.

Start amiberry -> Configurations -> double-click on pimiga3 config entry

Time taken for the emulation to get to working Workbench screen -- approx 30seconds

• F12 -> Savestates -> save this state to .uss file (with screenshot) --> Quit amiberry

Now... Start amiberry -> Configurations -> double-click on pimiga3 config entry -> emulation starts, hit F12 -> Savestates -> load previous saved .uss -> emulation goes straight to Workbench screen...

Time taken for the emulation to get to working Workbench screen -- approx 5 seconds (even with having to go to F12, load state)

This could be more streamlined, if GUI -> Savestates had something like a 'Load&Run' button...ie; check the conf/ directory for matching .uae file. start the emulation using that config and then pause emulation, load the .uss data, and resume. Would that be possible?

TIA

Pimiga3.uae.gz

[midwan]

I've updated the Savestate help text, with c7123d6

Not sure about the Load & Run thing, I'll need to check the code to see if that would be possible. And it wouldn't work for non-config files, like floppy disks for instance.

[giantclambake]

Thanks, that reads a lot better now ;)

About the Load & Run thing, the only part of that I don't really like, is having to go to the Savestates panel to make that happen ...ie; the more standard approach with amiberry is to start the emulation from the Quickstart or Configurations panel.....

....if I span this thought to a point beyond #1140 being completed, then creating a config file (ie; for floppy disks) should/will be dead simple for users (savestate startup would then work with floppy images)....usual savestate operations wrt floppy images (and no config) work as they do now...

.....when I think about that (too much =), it sort of makes 'better' sense, if there was something like a 'start from savestate' widget in the Configurations panel ...then for instance I could start the emulation 'normally' using the selected config entry, or, select this widget and the emulation boots to the associated savestate (if it exists).... something like that... /me just thinking out loud

edit: actually, wouldn't this be akin to ./amiberry -f conf/somename.uae --statefile savestates/somename.uss -G ....? Or does --statefile source the required config.uae before following the -G directive?

edit2: Seems it is...../amiberry -f conf/Pimiga3.uae --statefile savestates/Pimiga3-2.uss -G works as expected =)

So as cmdline works, if such a thing were to exist, it really should be on the Configurations panel in a sense ...ie; load config file with or without savestate file, would be the wordy way to put it.

[giantclambake]

Note: Savestates may or may not work with HDDs, JIT or RTG. They were designed to work with floppy disk images.

I question the above line ~ do you know where it came from?....ie; is it the result of experience/testing this feature? Was this feature extensively/recently tested with amiberry on x86-64 platform?(*)

"HDDs" - are we talking physical hdrive, harddrive directories, .hdf files ...?... all cases here?

"designed to work with floppy disk images" - without JIT apparently?...such is the inference...

By way of omission, the inference is CD32/CDTV bin/cue/iso files & whdload.lha archives work with savestates?

(*)...I've spent the last few days doing such testing on x86-64 ....I can't test JIT obviously, but I'll redo the test cases on the rpi4, to get the best holistic picture.

So far, I've tested both harddrive directories, and .hdf type setups, with all sorts of Amiga setups...ie; virgin wb1.3/2/3 hdrive installs, ClassicWB (with & without P96). AIAB, Amideb, Pimiga, MegaAGS... you get the idea... create a savestate after emulation boots & OS is finished loading, quit and load the .uss as per cmdline above -- seems to work fine, no exceptions, RTG or not, using these 'HDD medias'

I thought I'd try something 'harder'... create a savestate midway through a demo running .. there's some jitter from the capture process, but IRL it runs just fine from here, to demo completion and back to WB ... https://www.youtube.com/watch?v=Ep_BJt4yEYA

Checked about 10 different whdload.lha archives - works as expected
Checked about 5 CD32 titles (cue & iso) -- works as expected (smaller sample size as many are available in whdload format)
Checked a few floppy images - works as expected both with & without associated conf.uae

So far ... "works every time" is a long way from "may or may not work" ...(with these HDD types & RTG), and I'm really left with a hunt to find out when savestates do NOT work...

As said, I'll redo these tests on the rpi4 to establish whether or not savestates breaks with JIT enabled...

...and the point to all this waffle, is to see if the opening line here is better described as something like "Although originally designed for floppy images, the savestate function works with all media types. [Note: savestates do not work with JIT enabled]"

....I'll see if I can prove that [speculation] =)

[midwan]

Savestates were originally designed for floppy disks, so all other scenarios are not guaranteed to work.
From experience, it does seem to work fine on WHDLoad titles using Amiberry's WHDBooter feature, yes. But since there have been some cases of users having problems when trying to use savestates as a sort of "VM Snapshot" feature (which it's not), I thought a fair warning might be in order there.

[giantclambake]

Thanks ~ it's hard to be aware of of previous history wrt users having savestate problems without asking ;)

Yes, it seems to treat a whdload.lha file in the same way as a floppy image, saving the .uss with the current name of lha file, and the cmdline of ie; './amiberry --autoload StuntCarRacer_v1.3_0222.lha --statefile savestates/StuntCarRacer_v1.3_0222-2.uss -G' works.

Savestates appear to work in like fashion on the rpi4, with/without JIT enabled...so seems my above [speculation] is wrong. Of course, there'll be innumerable usage cases, and I can't find one that gives issues ~ but you get that =)