Problem with hard drive and save states, and a few other questions

[gryf]

Hi there!

First of all, thank you for your hard work!

I have one issue with stable and development version of fs-uae. Way to reproduce:

1. Prepare simple hard disk directory containing whdload game (perfectly visible on Dyna Blaster)
2. Play game, clear first stage
3. Just BEFORE entering blue tile, save the game state.
4. Quit emulator
5. Run it again, go straight to the save states menu and load previously saved state.
6. Go to the blue tile and observe requester from WHDLoad (Installed program has modified the VBR detected on entering via 'resload_Decrunch'.)
7. From now on, whdload executable is filled with null (0x00).

This is quite strange, since on other emulator (e-uae) saving snapshots works well (there is warning that snapshots aren't supported for hard drives, but seems like it is working anyway).

Btw, is there any configuration options for switching off fade at emulator quiting? It's pretty annoying while hunting bugs (yes, I know that I can change code, which actually I'm doing anyway, but maybe I have missed something). And finally - is there a configuration option for turning mono audio output? Or maybe have control over software mixing channels?

Best regards!

[FrodeSolheim]

Hi, thanks for the test case. I will try to reproduce and see if there's any interesting conclusion to be drawn (or something to this).

This assumes that you use a normal (unzipped) directory - please let me know if this is not the case - there is a known problem when using zipped drives via the Launcher (save states are now disabled in *that* case in the most recent development version) but that is another problem.

Also, I suppose the "not supported" warning means that no-one will provide user-support for it (=it may work under ideal conditions)

Fade: I'll throw in an fade_out_duration (ms) or something, should be equally useful for myself

Mono/stereo: FS-UAE has no offical option for this, but you can use uae_sound_stereo_separation = 0. You can also modify OpenAL settings (outside FS-UAE), ~/.alsoftrc when using the OpenAL soft implementation.

[gryf]

Originally Posted by FrodeSolheim

Hi, thanks for the test case. I will try to reproduce and see if there's any interesting conclusion to be drawn (or something to this).

Thanks!

Originally Posted by FrodeSolheim

This assumes that you use a normal (unzipped) directory - please let me know if this is not the case - there is a known problem when using zipped drives via the Launcher (save states are now disabled in *that* case in the most recent development version) but that is another problem.

That's right - I'm using uncompressed directories, since I'm sharing directories I've created for e-uae. I don't use launcher at all; all games (the set I've choose ofc, not ALL of them ) and systems I've made accessible via Window Maker dynamic menu.

Originally Posted by FrodeSolheim

Also, I suppose the "not supported" warning means that no-one will provide user-support for it (=it may work under ideal conditions)

E-uae has no update for years, so I assume, that project is dead.

Originally Posted by FrodeSolheim

Fade: I'll throw in an fade_out_duration (ms) or something, should be equally useful for myself

Awesome!

Originally Posted by FrodeSolheim

Mono/stereo: FS-UAE has no offical option for this, but you can use uae_sound_stereo_separation = 0. You can also modify OpenAL settings (outside FS-UAE), ~/.alsoftrc when using the OpenAL soft implementation.

uae_sound_stereo_separation works just fine, thank you. Is there any documentation on those uae_ configuration options?

[FrodeSolheim]

Originally Posted by gryf

uae_sound_stereo_separation works just fine, thank you. Is there any documentation on those uae_ configuration options?

The options are passed on to the UAE core (with uae_ stripped), so it's the same options as e.g. WinUAE accepts in configuration files (but many "frontend" options won't work / have any effect). The best documentation I have is the source code: src/cfgfile.c (implicitly) lists the options along with valid values.

It is seldom needed, but you can use this to override low-level emulation settings when FS-UAE does not provide "supported options" for it.

[gryf]

Ok, that's fine. Thanks again!

[FrodeSolheim]

I did not manage to reproduce the "VBR detected" problem, but I have found a problem which may be the root cause. It is at least a problem in any case

When loading the state, the emulator tries to re-open files which were held open by Amiga programs when the state was saved.

The problem is that the Amiga path is simply appended to the hard drive path, and then checked for existence - but this will not always work:
(1) it will not work when the file is opened by the Amiga with another case than the real host file on systems such as Linux with case sensitive file systems!
(2) it should not work if the Amiga path names need special mapping against host file names.

I think (2) may affect WinUAE as well, but (2) is much more rare than (1), and (1) is not a problem on Windows.

I have solved this now by traversing the path, mapping each Amiga path element to it's host element (while also considering case, of course) when open files are restored by state loading.

Do you compile your own version of FS-UAE if I supply a patch?

A further complication:
- When the file to be restored is not found due to different case, the UAE code opens a new file (a dummy file) and sets the file position to the original position and fills the file with dummy data.
- But when the file is about to be opened, the path is correctly mapped from Amiga path to host path, and so the correct (existing) file will be opened, and the state loading routine overwrites the original data with dummy data!

So unfortunately, (some of) the files in the directory hard drive may have been corrupted when loading the state.

EDIT: attached patch, apply with patch -p1 < /path/to/filesys.patch.txt from the source root dir.

[Toni Wilen]

You may have noticed that it is just a hack, just enough to make it work even if file is missing. (work as in not immediately crashing). I think I needed it to debug something..

Proper solution (that I haven't bothered to do) is of course to create a virtual file and only save it back if it is modified.

[gryf]

Originally Posted by FrodeSolheim

Do you compile your own version of FS-UAE if I supply a patch?

I have compiled fs-uae with attached patch, repeated test case and:

1. WHDLoad executable does not have been overwritten,
2. WHDLoad gives message about modified VBR while trying to resume from saved state.

Tested with default letter cases and all-lowercase filenames. Same result.

[ztronzo]

Originally Posted by gryf

Hi there!

First of all, thank you for your hard work!

I have one issue with stable and development version of fs-uae. Way to reproduce:

1. Prepare simple hard disk directory containing whdload game (perfectly visible on Dyna Blaster)
2. Play game, clear first stage
3. Just BEFORE entering blue tile, save the game state.
4. Quit emulator
5. Run it again, go straight to the save states menu and load previously saved state.
6. Go to the blue tile and observe requester from WHDLoad (Installed program has modified the VBR detected on entering via 'resload_Decrunch'.)
7. From now on, whdload executable is filled with null (0x00).

This is quite strange, since on other emulator (e-uae) saving snapshots works well (there is warning that snapshots aren't supported for hard drives, but seems like it is working anyway).

Btw, is there any configuration options for switching off fade at emulator quiting? It's pretty annoying while hunting bugs (yes, I know that I can change code, which actually I'm doing anyway, but maybe I have missed something). And finally - is there a configuration option for turning mono audio output? Or maybe have control over software mixing channels?

Best regards!

Tested, confirmed and resolved..
I use NoVBRmove in the WHDLoad arguments prior saving the state file.
Do not use this option with all of your configurations as it may cause unexpected results or freeze during loading with some games.

[RuySan]

The unreliability of save states on FS-UAE is something that really prevents me from having the most fun I could. I just don't have the time to play First Samurai or Leander in one go. From what I gather, having unzipped Whdload files would solve the problems?

Also, what's this NoVBRmove argument? This is new to me. Will it solve the issue?