Want to try builds of the new FS-UAE 4 & Launcher 4?

[FrodeSolheim]

Originally Posted by McNoise

Ok - sorry for bugging you ... in this way it works of course. Thank you!

Originally Posted by McNoise

Unfortunately starting with hard files/drives from the launcher still doesn't work (4.0.70). but no problem atm.

No, I haven't fixed that yet. I have however tested the MIDI functionality on macOS and Windows this week and it works (after applying an unofficial patch to portmidi to make it work on 64-bit Windows without crashing).

I've added some simple functionality to the Launcher to display the midi device names in order to make it a bit easier to use (full easy-to-use GUI will have to wait for later). Will probably release a build later today + instructions

[FrodeSolheim]

New builds of FS-UAE & Launcher ready - relates to MIDI support as mentioned in the previous post. Builds should be available via automatic update.

I've now tested the MT-32 version of King's Quest V with the MT-32 emulator Munt on Linux, macOS and Windows. Preliminary documentation here: https://github.com/FrodeSolheim/fs-u...r/docs/midi.md

[MrGimper]

I have to launch the launcher from a terminal using sudo on a MacBook with Big Sur 11.3. Double-clicking the icon does nothing.

Is this expected?

[FrodeSolheim]

Launcher update available:
- Fixed launching WHDLoad games on Windows
- Allows using non-automatic hard drives again (.hdf, directory hard drives)

Originally Posted by MrGimper

I have to launch the launcher from a terminal using sudo on a MacBook with Big Sur 11.3. Double-clicking the icon does nothing. Is this expected?

No, it is supposed to work. It could be a permission issue. Check in macOS settings if FS-UAE is denied access to the Documents folder for example.

[fehmi]

Originally Posted by FrodeSolheim

Launcher update available:
- Fixed launching WHDLoad games on Windows

Thank you so much for the fix - that was the biggest issue I was having!

[jbl007]

Bug: Amiga low pass audio filter is always enabled
(can still be force-disabled with --uae_sound_filter=off)
Simple test case: https://github.com/keirf/Amiga-Stuff/releases

Are there any plans to reduce cpu usage on the host? Right now fs-uae always maxes out one core.

[FrodeSolheim]

Originally Posted by jbl007

Bug: Amiga low pass audio filter is always enabled
(can still be force-disabled with --uae_sound_filter=off)
Simple test case: https://github.com/keirf/Amiga-Stuff/releases

Will check!

Originally Posted by jbl007

Are there any plans to reduce cpu usage on the host? Right now fs-uae always maxes out one core.

Yes, this is related to v-sync testing (and timing), where using busy-waits seems to be the best option in many cases for ensuring correct timing.

But it will of course be configurable (and will probably also default to off, at least when not using v-sync). Using the performance CPU governor on Linux works almost as well, but non-busywaiting sleeps are still not reliable enough. Sporadically, you'll get an oversleep by several milliseconds).

[jbl007]

Hm, oversleeping is always bad. Ask my employer!
Perhaps it depends on the kernel configuration, like preempt=idle/full/voluntary CONFIG_HZ_xxx and all the other fun stuff...

[FrodeSolheim]

FS-UAE 4.0.26-master (available via auto-update) contains fix for audio filter

Originally Posted by jbl007

Hm, oversleeping is always bad. Ask my employer!
Perhaps it depends on the kernel configuration, like preempt=idle/full/voluntary CONFIG_HZ_xxx and all the other fun stuff...

It probably depends on a lot of things - but it isn't really a bug, sleeping (unless you have real-time scheduling) does not guarantee anything. The sleep duration you specify is more like the "minimum" time you want to sleep.

Usually not a problem, but when you don't want to miss v-sync, sleeping 10 ms extra every now and then will cause occasional stuttering. With v-sync off, or g-sync/freesync, the problem (consequences) is not that big. Bug fans spinning loudly is annoying too, so it is reasonable to assume it will default to off - I'll probably end up with both a config option and a keyboard shortcut to toggle busy-waiting / sleep-wait mode.

[jbl007]

Audio filter works now. Thank you!

[McNoise]

Nice, that in version .72 starting with hard disks works again. Thanks.

I also found out how to configure the midi device on macOS: I simply used the device names listed in my DAW (Bitwig). So I added to my Default.fs-uae

serial_port = midi:MIDIFACE 2x2 Midi Out 2,MIDIFACE 2x2 Midi In 2

If the device names is incorrect it seems that FS-UAE uses the first available device in macOS. A good tool to check what happens on Midi ist "Midi Monitor" where you can watch all the in and out Midi action.

[MrDBUG]

Just wondered how I get out of the floppydisk selection menu ? I go in there with left ALT - but never get out :-(

[FrodeSolheim]

Originally Posted by MrDBUG

Just wondered how I get out of the floppydisk selection menu ? I go in there with left ALT - but never get out :-(

Left alt should get you out of there as well (also backspace, which is used to go up one level in the menu - it closes the menu if you're in the outermost menu). Will add escape as well later.

[MrDBUG]

Hehe that did the trick ! Thanks !
Backspace I mean !

[FrodeSolheim]

There was a problem with the newer builds with JIT on Windows (address space randomization used by default in newer GCC/MingGW prevented JIT from working). A fix has been added (forcing executable virtual memory base address to 0x400000), new build available

[McNoise]

hey guys ...

probably somebody remembers I reported issues with Midi and SysEx stuff.

I finally found out that this problem was caused by my Midi interface not macOS or FS-UAE.

It seems that Miditech's Midiface is unable to transmit SysEx data properly!

So I bought an old MOTU Fastlane USB and all SysEx problems are gone finally - FS-UAE and Midi works perfectly!

[ Show youtube player ]

[MrDBUG]

Extreme CPU usage is a problem for me :-/ but that is even worse on WinUAE under wine :-( no way to minimize it either it seems. Same on 3.0.5 I think.

[FrodeSolheim]

Originally Posted by MrDBUG

Extreme CPU usage is a problem for me :-/ but that is even worse on WinUAE under wine :-( no way to minimize it either it seems. Same on 3.0.5 I think.

As mentioned earlier, when I introduce a no-busy-wait option, FS-UAE will use less CPU (but not significantly less than 3.0.5).

Originally Posted by McNoise

So I bought an old MOTU Fastlane USB and all SysEx problems are gone finally - FS-UAE and Midi works perfectly!

Great! Thanks for the update

[RetroKing]

Hello Frode!

On my Windows 7 Ultimate Workstations:
FSUAE Launcher
missing: api-ms-win-core-path-l1-1-0.dll (dependency of python39.dll)

If i try to implement core-path.dll then python39.dll gives me the next error.
Is there a quick fix or this must i install python?

FSUAE Works

I would suggest to make your Autoupdater STANDALONE (exe). So that the Frontend works without strange depencies (Online & Offline) and also lightweight for older systems.

[FrodeSolheim]

Originally Posted by RetroKing

On my Windows 7 Ultimate Workstations:
FSUAE Launcher
missing: api-ms-win-core-path-l1-1-0.dll (dependency of python39.dll)

The issue is that Windows 7 is no longer supported by the Python project. Python 3.9 (well, the official builds at least) only supports Windows 8.1+.

Since these builds are built with Python 3.9, the minimum Windows version is 8.1 for these Launcher builds. I might reconsider and build the Windows version of the Launcher with Python 3.8 (the last Python version which supports Windows 7). But I'm not sure if it is worth it since Microsoft is no longer supporting Windows 7 either.

Originally Posted by RetroKing

I would suggest to make your Autoupdater STANDALONE (exe). So that the Frontend works without strange depencies (Online & Offline) and also lightweight for older systems.

The auto-updater is part of FS-UAE Launcher and uses the same dependencies as FS-UAE Launcher. No additional dependencies are introduced by the updater.