Builds for macOS ARM64 / M1 / Apple silicon have arrived

[FrodeSolheim]

The following links point to the latest stable version compiled for macOS_ARM64. These are 3.1.x versions based on slightly newer code than the 3.0.5 version.

FS-UAE-Launcher_Stable_macOS_ARM64.dmg
FS-UAE_Stable_macOS_ARM64.dmg

EDIT: Please see this thread about FS-UAE 3.1 instead: https://eab.abime.net/showthread.php?t=108745

Compared to previous downloads, FS-UAE Launcher.app no longer contains an embedded FS-UAE.app. Therefore, you need to download both of the .dmg files above and place FS-UAE Launcher.app and FS-UAE.app beside eachother, for example in the /Applications folder. I haven’t had time to fix builds of FS-UAE Arcade yet.

There are also macOS_ARM64 builds available for the 4.x development snapshots. If interested, please see this forum thread for links and more information.

[bubbob42]

The M1 version works fine and reaches about 46k Dhrystones in SysInfo using a 030 configuration with MMU and no JIT.

Thanks!

[Pyromania]

Nice to see an M1 build. I’m budgeting for some type of macOS M1 machine in the development suite this year. I might hold out for the M1X. I hope Apple does not kill the Touchbar I actually like it and it would be cool if FS-UAE supported it.

[Jason H]

Great to have a native version running on my M1 Mac. Thank you Frode

[reno]

Hi,

These work great thanks, I just have one annoying problem : I can't run CAPSImg with this build.

There is no Apple Silicon Mac build in the CAPSImg plugin pack on FS-UAE website, so I built one myself : https://github.com/renaudguerin/caps...eases/tag/v5.1
This works fine with e.g. my Greaseweazle.

I copied the library binary to ~/Documents/FS-UAE/Plugins/CAPSImg/macOS/arm64/capsimg.so, but there is a first problem here : looking at the FS-UAE log, it can't properly detect the arm64 arch and looks for "unknown" instead ("/Documents/FS-UAE/Plugins/CAPSImg/macOS/unknown/capsimg.so")

No problem, I just symlinked "unknown" to "arm64".
This time it can find it but can't load it :

[PLUGINS] Checking "/Users/xxxx/Documents/FS-UAE/Plugins/CAPSImg/macOS/unknown/capsimg.so"
DLOPEN: dlopen(/Users/xxxx/Documents/FS-UAE/Plugins/CAPSImg/macOS/unknown/capsimg.so, 2): no suitable image found. Did find:
/Users/xxxx/Documents/FS-UAE/Plugins/CAPSImg/macOS/unknown/capsimg.so: code signature in (/Users/xxxx/Documents/FS-UAE/Plugins/CAPSImg/macOS/unknown/capsimg.so) not
valid for use in process using Library Validation: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)
DLOPEN: Failed to open /Users/xxxx/Documents/FS-UAE/Plugins/CAPSImg/macOS/unknown/capsimg.so

Here's what my library looks like (similar to the x86-64 one but Universal) :

$ file capsimg.so
capsimg.so: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64]
capsimg.so (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
capsimg.so (for architecture arm64): Mach-O 64-bit dynamically linked shared library arm64

Any ideas ? Thanks !

[reno]

Ok, I've read a bit more and I think I know what the problem is :

It's simply that this Apple Silicon FS-UAE build has "Library Validation" enabled, which prevents it from using libraries that are unsigned or signed by other people.

https://developer.apple.com/document...ary-validation

@FrodeSolheim Looking at your CAPSImg plugin pack, the libraries are not signed here either:
$ codesign -v x86-64/capsimg.so
x86-64/capsimg.so: code object is not signed at all

So, this probably means that you had Library Validation disabled in the Intel macOS FS-UAE builds (otherwise CAPSImg would never have worked), but it became enabled by mistake (or rather by a new XCode default ) with the Apple Silicon build.

Would you mind making a new build with this flag disabled ? Or, if it causes other problems, distribute a signed version of the CAPSImg plugin pack (you can check out my fork on github if any problems for compiling it for arm64).

Thanks!

[Tigerskunk]

Looking forward using it on the MacBook Pro I intend to buy when it gets released (hopefully) this year.

[S0ulA55a551n]

Originally Posted by Steril707

Looking forward using it on the MacBook Pro I intend to buy when it gets released (hopefully) this year.

I am too am eagerly awaiting the 15inch mac book pros they must release this year. I bought the wife the m1 macbook air, and I am so impressed with the performance and battery life.

[reno]

Originally Posted by FrodeSolheim

The following links point to the latest stable version compiled for macOS_ARM64. These are 3.1.x versions based on slightly newer code than the 3.0.5 version.

FS-UAE-Launcher_Stable_macOS_ARM64.dmg
FS-UAE_Stable_macOS_ARM64.dmg

Compared to previous downloads, FS-UAE Launcher.app no longer contains an embedded FS-UAE.app. Therefore, you need to download both of the .dmg files above and place FS-UAE Launcher.app and FS-UAE.app beside eachother, for example in the /Applications folder. I haven’t had time to fix builds of FS-UAE Arcade yet.

There are also macOS_ARM64 builds available for the 4.x development snapshots. If interested, please see this forum thread for links and more information.

Hi Frode, did you get a chance to look into disabling "Library Validation" in order for IPF/CAPSImg to work (per my message above) ?

Thanks !

[Pyromania]

Is this build on the M1 a 1000x faster and more powerful?

[bni]

I have been using this build for a while and I can report it works great for my use cases.

Nothing special, but I do use a physical CF-card as disk (/dev/disk4) and it works fine.

[AprilHare]

Great work, many thanks! Just one request: PPC support?

[FrodeSolheim]

PPC support is (somewhat) available - meaning that FS-UAE is compiled with support for it, and I've compiled a QEMU-UAE plugin for macOS/ARM64. However, the plugin seems to crash when trying to boot AmigaOS 4.1. I haven't had time to do any debugging on that.

[Dic_Ray]

Dear Frode,

please would you tell us, if there will be an actual FS-UAE version be available for the Raspi 400? I bought AmiKit for Raspi, but atm the used Amiberry has problems with autoscaling the picure in demos like Nexus 7 and CrazySexyCool.

Would be great to try FS-UAE on my Raspi 400.

Best regards

[FrodeSolheim]

Originally Posted by Dic_Ray

please would you tell us, if there will be an actual FS-UAE version be available for the Raspi 400?

Almost certainly

[reno]

Originally Posted by reno

Ok, I've read a bit more and I think I know what the problem is :

It's simply that this Apple Silicon FS-UAE build has "Library Validation" enabled, which prevents it from using libraries that are unsigned or signed by other people.

https://developer.apple.com/document...ary-validation

@FrodeSolheim Looking at your CAPSImg plugin pack, the libraries are not signed here either:
$ codesign -v x86-64/capsimg.so
x86-64/capsimg.so: code object is not signed at all

So, this probably means that you had Library Validation disabled in the Intel macOS FS-UAE builds (otherwise CAPSImg would never have worked), but it became enabled by mistake (or rather by a new XCode default ) with the Apple Silicon build.

Would you mind making a new build with this flag disabled ? Or, if it causes other problems, distribute a signed version of the CAPSImg plugin pack (you can check out my fork on github if any problems for compiling it for arm64).

Thanks!

Hi Frode,
Any thoughts about this ?
Thanks!

[FrodeSolheim]

Library Validation disabled was disabled in older builds yes. I enabled it because getting apps notarized correctly is increasingly difficult, and I assumed it is only a matter of time until Apple makes using exceptions (such as disabling library validation) harder. So I enabled it after checking that signed plugins work fine, but I forgot to publish the links. Sorry about that.

The signed plugins are available here:
https://fs-uae.net/files/CAPSImg/Master/5.1.0.7-fs/
https://fs-uae.net/files/QEMU-UAE/Master/3.8.2.10/

(Both for x86-64 and ARM64)

[reno]

Originally Posted by FrodeSolheim

Library Validation disabled was disabled in older builds yes. I enabled it because getting apps notarized correctly is increasingly difficult, and I assumed it is only a matter of time until Apple makes using exceptions (such as disabling library validation) harder. So I enabled it after checking that signed plugins work fine, but I forgot to publish the links. Sorry about that.

The signed plugins are available here:
https://fs-uae.net/files/CAPSImg/Master/5.1.0.7-fs/
https://fs-uae.net/files/QEMU-UAE/Master/3.8.2.10/

(Both for x86-64 and ARM64)

Thank you very much for this !
I've just tried with the 3.1.27 M1 build: it didn't work at first because FS-UAE detects the architecture as "unknown" instead of "ARM64". So, I had to rename the CAPSImg/macOS/ARM64/ directory to CAPSImg/macOS/unknown/. Now it's working !

Another problem I have with this build is that I get the "universalAccessAuthwarn" macOS Security pop-up *every* time FS-UAE (not the launcher) starts, even though both Launcher and FS-UAE are already approved for keyboard input in the Preferences.

[FrodeSolheim]

I though I had fixed the plugin architecture name, but I will check.

As for the warning, I've traced that to the support for multiple mice, which needs low-level access to devices. For some reason, the warning appears every time. Not sure why. I'm implementing a workaround where support for multiple mice is disabled on macOS by default and needs to be enabled via an option (multiple_mice = 1). This way, the warning will not be shown for most use cases.
EDIT: I though this was the case, but it looks like I might have been mistaken. It is however the case that the warning appears because/when FS-UAE Launcher runs fs-uae-device-helper.
EDIT2: It was manymouse, but I also upgraded to SDL 2.0.16 a few days ago, and that seems to also have introduced this security warning. Which is why I got confused today, since disabling manymouse did not help any more...

[FrodeSolheim]

@reno Please try
https://fs-uae.net/files/FS-UAE/Stab...S_ARM64.tar.xz (3.1.31)

It should fix both the plugin architecture (ARM64 should be recognized) as well as fix the warning about intercepting key presses from other applications on macOS.