Portable Mode and State Files

09 July 2018, 05:13

In portable mode if I create a state file then the floppy drive images are saved as being relative to WinUAE, but the hard drive directories are saved as absolute paths, so the hard drive won't be found if I move the USS file to a different location, system, drive letter. Can this be changed so the hard drive locations are also portable?

Also, has the state file changed since version 3.5? Some older USS files that work with 3.5 immediately give CPU trace errors and crash with newer versions of WinUAE.

Toni Wilen · 09 July 2018, 15:37

Quote:

Originally Posted by MAD67

In portable mode if I create a state file then the floppy drive images are saved as being relative to WinUAE, but the hard drive directories are saved as absolute paths, so the hard drive won't be found if I move the USS file to a different location, system, drive letter. Can this be changed so the hard drive locations are also portable?

Do you mean directory harddrives or HDFs? Directory harddrive does not seem to support relative/absolute conversion when restoring. (Saved path type isn't important)

Does http://www.winuae.net/files/winuae.7z fix it?

EDIT: I misunderstood, wait..

Quote:

Also, has the state file changed since version 3.5? Some older USS files that work with 3.5 immediately give CPU trace errors and crash with newer versions of WinUAE.

68020/68030 "more compatible" mode was heavily rewritten to better match real CPU behavior, this can cause compatibility problems with some old state files because not all prefetch related fields have matching part in new mode.

Attach/email few for testing, thanks.

Tomislav · 10 July 2018, 16:23

Suggestion: Do not use save state with hard drives, CD ROMs and to much memory.

Save state is good for games which don't have autosave and which are on floppies.

Biggest memory means more to save, if you have 8MB it will save those 8MB because it can't know which part of memory is used by game. (Today 8MB is not to much, think about 128MB or more, times how many you have uss files ...)

Save state of hard disks can be problem because data on HD can be changed after saving state and that can somehow invalidate data on HD while using that save state.

Toni Wilen · 10 July 2018, 17:10

Saved memory is compressed by default.

Directory harddrive state saving is almost 100% safe, worst case is file that was open for writing gets truncated/partially written only.

HDFs should be only used when mounted as read-only.

10 July 2018, 22:59

As you stated : Directory harddrive does not seem to support relative/absolute conversion when restoring. I was asking if that can be changed, so it is portable just like an ADF or HDF. State files are useful for skipping longs intros and load times. I can change hard drive directories to HDFs, but manipulating files is easier from within Windows rather than AmigaDOS.

I went though 239 state files that were made with 3.4/3.5 and of those 15 give errors using a newer WinUAE. As you said all were 68020 except one which was a 68000 that fixed itself after one CPU trace : GET 0007ff7e 1 2 NOT FOUND! error. Don't know if this info is useful. I simply remade new state files.

Toni Wilen · 13 July 2018, 13:03

Quote:

Originally Posted by MAD67

As you stated : Directory harddrive does not seem to support relative/absolute conversion when restoring. I was asking if that can be changed, so it is portable just like an ADF or HDF. State files are useful for skipping longs intros and load times. I can change hard drive directories to HDFs, but manipulating files is easier from within Windows rather than AmigaDOS.

It is too late to fix this fully in 4.0.1 but I'll add partial fix: write both full and relative path to state file. This new data is ignored by old versions but future version can use it.

Old path field behavior can't be changed for compatibility reasons.

Quote:

I went though 239 state files that were made with 3.4/3.5 and of those 15 give errors using a newer WinUAE. As you said all were 68020 except one which was a 68000 that fixed itself after one CPU trace : GET 0007ff7e 1 2 NOT FOUND! error. Don't know if this info is useful. I simply remade new state files.

Only useful info is attached non-working statefile

Toni Wilen · 13 July 2018, 14:51

It is far too late but full support is now done.. When restoring new fields (if new fields are in statefile) are used to reconstruct correct new path if path mode is different when saving.

http://www.winuae.net/files/b/winuae.7z

09 July 2018, 05:13	#1
MAD67 Posts: n/a	Portable Mode and State Files In portable mode if I create a state file then the floppy drive images are saved as being relative to WinUAE, but the hard drive directories are saved as absolute paths, so the hard drive won't be found if I move the USS file to a different location, system, drive letter. Can this be changed so the hard drive locations are also portable? Also, has the state file changed since version 3.5? Some older USS files that work with 3.5 immediately give CPU trace errors and crash with newer versions of WinUAE.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Relative path in portable mode:	bladecgn	request.UAE Wishlist	2	01 October 2017 18:54
Change CPU in Save State Mode	arti	support.WinUAE	9	23 December 2010 19:27
something about state files	nkarytia	support.WinUAE	1	28 July 2009 14:32
Hunt for Red October (Grandslam) and state-saving in pause mode	andreas	support.WinUAE	6	23 October 2008 22:57

10 July 2018, 16:23	#3
Tomislav Registered User Join Date: Aug 2014 Location: Zagreb / Croatia Posts: 302	Suggestion: Do not use save state with hard drives, CD ROMs and to much memory. Save state is good for games which don't have autosave and which are on floppies. Biggest memory means more to save, if you have 8MB it will save those 8MB because it can't know which part of memory is used by game. (Today 8MB is not to much, think about 128MB or more, times how many you have uss files ...) Save state of hard disks can be problem because data on HD can be changed after saving state and that can somehow invalidate data on HD while using that save state.

10 July 2018, 17:10	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	Saved memory is compressed by default. Directory harddrive state saving is almost 100% safe, worst case is file that was open for writing gets truncated/partially written only. HDFs should be only used when mounted as read-only.

10 July 2018, 22:59	#5
MAD67 Posts: n/a	As you stated : Directory harddrive does not seem to support relative/absolute conversion when restoring. I was asking if that can be changed, so it is portable just like an ADF or HDF. State files are useful for skipping longs intros and load times. I can change hard drive directories to HDFs, but manipulating files is easier from within Windows rather than AmigaDOS. I went though 239 state files that were made with 3.4/3.5 and of those 15 give errors using a newer WinUAE. As you said all were 68020 except one which was a 68000 that fixed itself after one CPU trace : GET 0007ff7e 1 2 NOT FOUND! error. Don't know if this info is useful. I simply remade new state files.

13 July 2018, 14:51	#7
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	It is far too late but full support is now done.. When restoring new fields (if new fields are in statefile) are used to reconstruct correct new path if path mode is different when saving. http://www.winuae.net/files/b/winuae.7z

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)