Savestate also for Harddisks

[Konrad]

I thought I read about this some time ago, but I couldn't find anything about it. However is it possible to make hd's also work with savestates ?

But I'm sure that there's a reason why Tony didn't add this until now, am I right ?

[Toni Wilen]

I can't find it either..

It can never work properly. OS and applications can easily get confused and worst case is data loss if any program writes to HD between saving and restoring state files.

For example:

State file saved, you continue playing the game/using text editor/etc, it decides to do autosave (or maybe update highscores or just write something to HD), load state file, AmigaOS or game's internal state is now incorrect (there is already autosave saved on HD but AmigaOS/game thinks the file is not there) -> program writes to disk again -> possible data loss or crashes etc..

IMHO best option is to implement WHDLoad specific statefiles (with possible help from emulation side), only safe and compatible way to do it. (but it won't be trivial either)

[thomas]

Couldn't you calculate a CRC sum of the HDF and if the CRC does not match on load, tell the user that the HDF has been changed and ask him if he wants to continue anyway with the risk of data loss ?

Also, doesn't the same problem apply to ADFs, too ? Or do you store the entire ADF in the state file ?

[killergorilla]

Maybe the possibity of read-only hdfs?

[Marcuz]

Originally Posted by killergorilla

Maybe the possibity of read-only hdfs?

that would be useful only with read-only little whdload hdfs, and this would so render not unuseful but almost unuseful the thing: a savestate is prolly helpful on main HD because you would use it casually. on little whdload hdfs, why should i play them instead of direct adfs if my interest is saving states?

[Toni Wilen]

Originally Posted by thomas

Couldn't you calculate a CRC sum of the HDF and if the CRC does not match on load, tell the user that the HDF has been changed and ask him if he wants to continue anyway with the risk of data loss ?

Using HDF would "always" result in a filesystem corruption or crash except in read-only mode. (AmigaOS buffer cache would contain invalid data)

I won't implement features that can cause easy HD data loss.

Directory harddrive support is less dangerous (only currently open files can be lost or system can "only" crash) but it won't be too realiable either..

Also, doesn't the same problem apply to ADFs, too ? Or do you store the entire ADF in the state file ?

Yes, same thing can happen with ADFs but it isn't too dangerous (worst case is single ADF lost instead of big HD partition) and most disk-based programs won't do "random" writes (no background utilities/patches active), use simple custom disk routines (no buffering) and writing is only used for saves.

[Anubis]

Originally Posted by Toni Wilen

IMHO best option is to implement WHDLoad specific statefiles (with possible help from emulation side), only safe and compatible way to do it. (but it won't be trivial either)

I don't think that I would like to see this either as time to write back to disk from WHDLoad session is loooong, and those files will be the size of memory (compressed probably) which is huge for WHDLoad settings.

Originally Posted by Konrad

Take ShadowOfTheBeast for example. You have to watch the intro sequence before you can play the game.

You can map one of the buttons to 0x20F (Warp mode) and speed up movies.

[Toni Wilen]

Cabinet discussion moved to http://eab.abime.net/showthread.php?t=25801

[Toni Wilen]

I have quite crazy idea... implement trackdisk.device patch that allows use of really big adfs. (=regular partition hardfiles)

Statefile problem fixed

[Marcuz]

that's a great idea! but wouldn't be the read/access/write time longer than to hdfs?

[Anubis]

We talking about one huge adf per game?

Will that work with amiga disk formats? (some games don't like even turbo read mode)

[thomas]

Originally Posted by Toni Wilen

Using HDF would "always" result in a filesystem corruption or crash except in read-only mode. (AmigaOS buffer cache would contain invalid data)

That's no problem IMHO. When you load the state file, you check if the HDF has been changed and if it has, you reject the load (rendering the state file unusable). If the HDF hasn't changed, you restore the entire memory including HDD buffers, so no data is lost.

The HDF is always usuable. The Amiga is designed to be switched off at any point, so disk buffers cannot be an issue. Of cource, saving the state in the middle of a write operation is dangerous as is switching power off in the middle of an operation. But if the HDF is not touched between save and load of the state, there is no problem.

[Toni Wilen]

Originally Posted by thomas

The HDF is always usuable. The Amiga is designed to be switched off at any point, so disk buffers cannot be an issue.

That is a different problem. Switching the Amiga off and back on results in full OS memory rebuild (including buffers) from the disk = disk<>memory out of sync situation can't happen.

When you load the state file, you check if the HDF has been changed and if it has, you reject the load (rendering the state file unusable).

Yes but the HDF will be changed in most cases. Single save or high score file created and the statefile will be useless..

We talking about one huge adf per game?

Will that work with amiga disk formats? (some games don't like even turbo read mode)

Yes and no. It is about emulating harddrive "inserted" in floppy disk drive (by hacking the OS trackdisk.device to support very large disk images, basically regular HDF images with OFS or FFS format) Nothing to do with trackloading programs.

but wouldn't be the read/access/write time longer than to hdfs?

I don't think so if all delays are removed from trackdisk.device (like rw-head step delays) and implementing some kind of "super-turbo" floppy speed mode .)

[Anubis]

So this means that we will be able to add HDF file into flopy drive, start emulator and play the game. We don't need then internal save option of WHDLoad (drive can be read only).

Now, can you make dynamic HDF that will grow as more files we place into them or at least some HDZ - compressed HDF?

See, it takes a small initiative for us to come up with some crazy ideas.

[TTSAddict]

Sorry for gravedigging, I just stumbled across this thread via search. I immediately remembered VMWares state saving capability. The VM keeps track of all changes to the virtual harddisk and stores that together with the state. States can be erased and then the changes get flushed to the real hardfile or discarded if a previous state is to be reconstructed.

[Anubis]

WinUAE does something similar to floppy disk images.

For HDF, just 7zip it before making big changes.

[thomas]

I still don't see how a currupted state file can be dangerous for a HDF. Deleting a state file is like switching off the computer. It's the same as pressing Alt-F4 in the middle of a session. People do this all the time, it's the only way to shut down AmigaOS.

To prevent using a state file with a changed HDF, you could save a checksum of the HDF into the state file. Every change to the HDF will render the state file unusable. That's ok IMHO. You could offer an option for advanced users to override the change check, so that they can load the state file at their own risk.

[Toni Wilen]

Originally Posted by thomas

I still don't see how a currupted state file can be dangerous for a HDF. Deleting a state file is like switching off the computer. It's the same as pressing Alt-F4 in the middle of a session. People do this all the time, it's the only way to shut down AmigaOS.

It isn't same. It isn't going backwards in time.

For example:

- Save state
- Load state, after load, some file gets modified, it may cause recreation of some filesystem blocks (for example bitmap or hash tables if OFS/FFS).
- Load state again. Now statefile loaded filesystem buffers contain recently saved/modified blocks with old contents. But actual HDF has new contents.
- Bad things start happening.

It is even worse with journal based filesystems that think some atomic operation has been completed when it actually does not exists. Which is 100% impossible condition in real world.

I won't do anything until someone confirms that there is at least one filesystem that does not get too confused when time goes backwards. Or at least some way/hack to force full flush of all filesystem buffers and metadata. This would be the best solution.