FS-UAE Stable Series - Questions, Feedback and Bug Reports

[FrodeSolheim]

Originally Posted by Romanujan

I think this is a great piece of software (I especially like the GUI), but there are, unfortunately, some WinUAE features I miss in FS-UAE

Hi, the features you are requesting can of course be useful, but for most users, the existing configuration / launcher GUI is sufficient (CPU/FPU type is automatically set from Amiga model, etc).

To cater for advanced needs - when you need to create a custom setup, FS-UAE allows to specify uae options directly (just prefix them with uae_).

So for example, to enable Akiko functionality, something like:

uae_cd32c2p = true
uae_cd32cd = true
uae_cd32nvram = true

(may perhaps need other options as well, haven't tested).

Likewise, you can use uae_cpu_model, uae_fpu_model and uae_mmu_model, etc. The values are the same as they are in WinUAE configuration files.

AHI sound is not supported yet, and there's no immediate plan to implement it since the current audio code in FS-UAE is not suited for AHI.

About "Wazp3D soft3d support" - After some quick googling, it seems this uses an extension feature in WinUAE where Amiga-side software communicates with a native DLL through WinUAE. This is not implemented in FS-UAE (and neither is it planned).

[FrodeSolheim]

An update to FS-UAE 2.2 has been released. Changes in FS-UAE 2.2.1:

• Show on-screen warning if OpenAL device cannot be opened, log OpenAL error code.
• New option save_state_compression can be used to disable save state
  compression.
• New option “log” which can be used to enable misc types of debug logging.
• Queued input events are processed in hsync handler.
• Use CD32 + FMV quickstart for CD32 model, update cd.device in cartridge ROM fixes problem with Pirates Gold intro.
• Removed a couple of left-over / unnecesary log statements.
• Support language option to override GUI language.
• New translations: tr [Decypher].
• (Launcher) Fixed bug when specifying window_width / window_height in custom settings.
• (Launcher) Warn when using A1200 model with < 2 MB chip RAM.
• (Launcher) Fixed a bug where 0-byte screenshot / covers files could be stored if a network error occurs while downloading.
• (Launcher) Better support for A3000 and A4000 with the game database.
• (Launcher) Support hiding variants from the database based on _status.
• (Launcher) Cycle-exact can be disabled from database if abs. necessary.
• (Launcher) Support language option to override GUI language.
• (Launcher) New translations: tr [Decypher].

[Toni Wilen]

Originally Posted by FrodeSolheim

[*]Use CD32 + FMV quickstart for CD32 model, update cd.device in cartridge ROM fixes problem with Pirates Gold intro.

This breaks Cannon Fodder, it uses FMV module for intro if detected. Also it is possible other games break due to different memory usage.

[FrodeSolheim]

Originally Posted by Toni Wilen

This breaks Cannon Fodder, it uses FMV module for intro if detected. Also it is possible other games break due to different memory usage.

Thanks, I was meaning to ask if enabling that ROM by default was a good idea or not

An 2.2.2 update will be released fairly soon with some other bugfixes, and there'll be a separate CD32/FMV model which includes the FMV ROM (for Pirates Gold). The CD32 model will revert to it's previous configuration.

[FrodeSolheim]

An update to FS-UAE 2.2 has been released. Changes in FS-UAE 2.2.2:

• With video_sync = auto, allow some slack when deciding to enable full sync or not (accept host refresh rate 49 instead of just 50, ..).
• New option: assume_refresh_rate (int) to manually specify host refresh rate when refresh rate detection fails. This option in combination with video_sync = auto effectively replaces video_sync = full.
• video_sync = full is now an alias for video_sync = auto.
• Fixed bug causing FS-UAE to hang when pausing with video_sync = off.
• New model CD32/FMV (includes FMV ROM), CD32 model reverted to original.
• Fixed compatibility issues in scanline GLSL shaders.

[Neil79]

I think I just screwed up my FS-UAE

I decided to go with AMIKIT instead of the 3 installed operating systems and a multitude of folders all over the place and just have two clean installs. 1 being FS the other being AMIKIT. However even though I did a new rescan of all my gaming folders and kickstarters it's coming up with devs/kickstart errors and failing to load any games. The kickstarters are all ticked as well.

So I'm going to try again tomorow, but this time completely uninstall FS-UAE and everything related to it. Then re-import the kickstarters and folders one by one.

Been a crappy few days lately with the AMIGA side of things, might be user error

[Neil79]

Woohoo!

Everything works as it should

AmiKit, FS-UAE and ofcause my real Amiga

Sometimes just a complete clean reinstall and scan of folders does wonders. All my games work now with out fault, yay!

[FrodeSolheim]

Version 2.2.3 (beta):

* On windows, read file name (as program parameter) with MBCS encoding (CP_ACP) so paths with non-ASCII characters are handled correctly.
* Windows executables are digitally signed by "Frode Solheim".
* (Launcher) Only add Cloanto "Amiga Files" to search path if directory exists (Windows).
* (Launcher) Fix slash direction in default search directory on Windows so it does not look weird.
* (Launcher) Updated translations: it [speedvicio].

http://fs-uae.net/stable/2.2.3b1/

(It will be officially re-released as "2.2.3" if all these fixes work properly )

[FrodeSolheim]

Bugfix update (2.2.3) released: http://fs-uae.net/2013/06/25/fs-uae-2-2-3-released

[Leffmann]

A small bug report: on Mac, the ".DS_Store" settings file left by Finder prevents AmigaDOS from deleting an otherwise empty directory.

Also, could it work to hide the .UAEM files on Mac by prefixing with a period sign? It would look much nicer and cleaner when browsing your directory-based drives on the Mac side.

[amigafreak68k]

Normally files with a leading "." should be hidden on Mac OS X

I've tested it with a newly created Folder. Renaming it in Terminal with a leading point and it was hidden immediately.

[FrodeSolheim]

Originally Posted by Leffmann

A small bug report: on Mac, the ".DS_Store" settings file left by Finder prevents AmigaDOS from deleting an otherwise empty directory.

Thanks, a good point I hadn't though about. FS-UAE should try to delete the ignored files (.DS_Store, Thumbs.db) before trying to delete the dir

Originally Posted by Leffmann

Also, could it work to hide the .UAEM files on Mac by prefixing with a period sign? It would look much nicer and cleaner when browsing your directory-based drives on the Mac side.

I did think hard and long on that one (and with leading dot *and* hidden attribute on Windows, they'd be hidden on all platforms. I also considered having a hidden .uaem directory with the meta files bundled up, etc.

But the winning argument was this: When moving / copying files on the host side, you *should* include the .uaem files as well, so the metadata is preserved. If the files are hidden, many people won't even know they are there. Now, it is at least obvious that there are some files there you must be aware of (and they'll generally be stored side-by-side with the original file since it includes the original filename as prefix).

And I don't really want this to be configurable, since then the directory hard drives will no longer be portable between systems / users which has different preferences.

(But I do have in mind a per-volume option to skip storing .uaem files at all, if you don't need full metadata support for a volume...)

Originally Posted by amigafreak68k

Normally files with a leading "." should be hidden on Mac OS X

Yes, Leffmann meant adding a leading dot to *.uaem files, there is no leading dot currently.

[Leffmann]

Yeah you're right, it makes no sense to hide these files. But, have you considered using extended file attributes to store this data with the actual file, just like WinUAE does?

[FrodeSolheim]

Originally Posted by Leffmann

Yeah you're right, it makes no sense to hide these files. But, have you considered using extended file attributes to store this data with the actual file, just like WinUAE does?

Yes, but that's much worse IMHO. That would mean that the attributes usually work, but if you do something like the following, the attributes could be lost:
- Copied / moved files to a removable device with does not support those attributes
- Restoring files from backup might mean attributes are lost (if the backup / restore application does not support it)
- You cannot zip down a set of files with attributes intact and sent to another person (you can now if you just include the .uaem files in the archive).
- It would be (more or less) impossible to have Amiga-attributes on a remove device / networked hard drives shared between multiple operating systems
- and other similar reasons...

I don't mean this as criticism of the the behavior in WinUAE, this is clearly a case where there is no obvious right or wrong, only different solutions with different compromises. I personally think the current approach in FS-UAE gives the best compromise, delivering reliable and predictable operation in many scenarios, with the cost being increased clutter in the host-visible file system.

(A bonus of the *.uaem files is that is is really easy to make tools to read/write metadata. You can even edit the metadata in a text editor (try opening one in notepad )

[Leffmann]

Personally I prefer the extended attributes because it's much tidier and sort of works the way it does on a real Amiga, where you have to resort to LHA-archiving the files anyway if you want to guarantee consistency when moving them across systems. But you're right there are only compromises and no ideal solution.

Another thing: AmigaDOS file notifications are not sent when modifying directory-based drives from outside the Amiga. I pointed it out in support.WinUAE but thought I would mention it here as well.

Thanks.

[Leffmann]

I'm trying to get FS-UAE to stop using floppy overlays, which are now stored as part of the save states, but it always keeps both the save states and overlays, and never updates my ADFs. I've added these lines to my config:

writable_floppy_images = 1
save_states = 0

This should work according to the docs, or am I missing something here? I've attached all log files.

Also, using 800% and turbo speed floppy emulation causes occasional read/write errors on ADF images. Not sure if anything above 100% is supposed to work flawlessly, but since it's not pointed out in the docs..

[lesta_smsc]

Just realised that FS-UAE notifies of update! Thank you!

Hmmm the latest development series fails to recognise my old settings.

[TCD]

Originally Posted by lesta_smsc

Hmmm the latest development series fails to recognise my old settings.

Do you mean the preferences, custom configuration or things in one (or all) of your configs?

[lesta_smsc]

The games config section all blanked out and now IRC channel.

Old:

New:

[FrodeSolheim]

Originally Posted by Leffmann

I'm trying to get FS-UAE to stop using floppy overlays, which are now stored as part of the save states, but it always keeps both the save states and overlays, and never updates my ADFs. I've added these lines to my config:

writable_floppy_images = 1

This should work according to the docs, or am I missing something here? I've attached all log files.

Yes, and no. This option does indeed work, for FS-UAE itself. But using it with FS-UAE Launcher will have less of an effect, since FS-UAE Launcher also currently extracts/copies disk images to a temporary directory before launching FS-UAE. So the net effect is that floppy overlays are not used, but instead, modified .adf files are saved in the state dir instead.

I'll have to either make FS-UAE Launcher respect writable_floppy_images too, and behave differently if set, or do something else to support this use case. I'll think on what's the best way to proceed...

Originally Posted by Leffmann

Also, using 800% and turbo speed floppy emulation causes occasional read/write errors on ADF images. Not sure if anything above 100% is supposed to work flawlessly, but since it's not pointed out in the docs..

Only 100% is supported, other speeds may or may not work depending on the game. The online docs are updated.

Originally Posted by lesta_smsc

Just realised that FS-UAE notifies of update! Thank you! Hmmm the latest development series fails to recognise my old settings.

You must run a simple file re-scan in order for database entries to reappear, the database schema was updated in the development version and there is no automatic database migration. Oh, and keep in mind going forward not to use the stable thread for devel-version issues, or people might get confused

EDIT: Yes, I see from the screens that other settings are missing. Perhaps you downloaded the portable version? That version will use its own settings file... to keep it portable...