About FS-UAE for Mac M1 hardware
 

I do get occasional questions about native FS-UAE for Apple Silicon / macOS on M1 hardware.

I know that the source code compiles successfully and the resulting binary runs natively on M1, because at least a couple of people have already tested this. So the reason that I don't provide builds for M1 hardware yet (or universal binaries) is not that it isn't possibly, but rather that:

- I don't have a practical way to generate M1 builds every time I do a release, and also
- I'm hesitant to distributing builds that I haven't got oversight over or ability to test

Hopefully, GitHub Actions will eventually add support for running automation on M1 hardware so I can automatically build versions for this architecture along with the rest.

But of course, if an M1 user or a group of M1 users want to dedicate time to regularly providing M1 builds, I could of course link to that.

For the time being, I'm more interested in seeing if the only actually reported problem with running via Rosetta 2 (joysticks not working) is fixed with a newer SDL library included with FS-UAE.

Links to some relevant threads:

"Compiling FS-UAE for Apple Silicon "
https://eab.abime.net/showthread.php?t=106154

"FS-UAE Joystick Support (Apple Silicon)"
https://eab.abime.net/showthread.php?t=105950

The following thread contains a link to a newer, not officially released, 3.0.x release (for x86-64) compiled with newer libraries, which might work better on both macOS 11.0 and M1 hardware compared to 3.0.5: https://eab.abime.net/showthread.php?t=106794

Also, you can test the new 4.0 in-development builds available here: https://eab.abime.net/showthread.php?t=106562 and see if that solves issues you have with 3.0.5.

Hey Frode, I'm happy to compile current builds when I'm able. I personally am not a fan of relying on Rosetta2 - it eats up a ton of resources. When Discord takes up more CPU cycles and memory than Logic Pro, we've got a problem :P

I hope this is the best thread to ask if someone wants to share his experience in running FS-UAE 3.0.5 on a Mac Mini M1.

FS-UAE is my tool of choice to develop Reshoot Proxima 3, and I think about switching my iMac of 2011 for a recent Mac Mini. Makes sense only if FS-UAE 3.0.5 works reliably; otherwise I'd rather wait until a more recent version of FS-UAE runs stable with controller-support, debugging capabilities uncompromised.

Rumor has it that 3.0.5 does not work with controllers on M1 hardware. This might be a due to a combination of something Apple have changed + an "old" SDL2 library.

I have built a version of FS-UAE (basically 3.0.5 + a few bugfixes) with newer libraries (and also via new build infrastructure - GitHub Actions). This test version is available here: https://eab.abime.net/showpost.php?p...43&postcount=2. I'd like some feedback if controllers work on M1 hardware with this version...!

Jason_H confirmed (http://eab.abime.net/showpost.php?p=...7&postcount=10) that the joysticks support works again with the newest builds. Which means that as far as I know (I haven't gotten reports suggesting otherwise), the x86-64 version works fine on M1 hardware.

(It is also fairly trivial to compile FS-UAE for M1 hardware if one wants to - JIT is automatically disable due to not being supported on ARM)

I built from source to get a native version on my M1 Mac mini.

It works great besides one thing: scanlines = 1 doesn't do anything (I put it in my .fs-uae file I'm using)

What could be the reason for that?

If you built from the master branch, then it won't do anything (not implemented). See http://eab.abime.net/showthread.php?t=106562 for more information.

Frode, do you know if the built-in Debugger of version 3.0.5 runs on an iMac with M1?

I don't *know* for sure, but I don't see why it shouldn't work. All feedback I've gotten suggest that the x86-64 version works fine on M1 as is, through the Rosetta 2 emulation layer (*).

(*) Joystick support requires that FS-UAE is bundled with a newer SDL library than what's included in the 3.0.5 download.

That sounds great, thanks a lot!

There are now official ARM64 builds available for M1 hardware: http://eab.abime.net/showthread.php?t=107283

I'd just like to thank you, FrodeSolheim, for the work you've done with FS-UAE.
I don't have a Windows box, so use FS-UAE on my Intel Mac. It's a fantastic piece of work, and has enabled me to dive back into the wonderful world of the Amiga after a decade's absence. :great

I hope you don't mind if I post some quick feedback, after I have been using FS UAE 3.1.17 for some weeks now to develop RESHOOT PROXIMA 3 on Mac Mini M1. Almost everything works perfectly fine. Speed and accuracy is incredible.

May I add two suggestions:

- Would be great if PF1H0/1 and PF2H0/1 would work as intended. As is, PF2H0/1 seems to be mirrored to PF1H0/1, effectively disabling subpixel scrolling in dual playfield mode

- FS UAE seems to disable Screensaver and Sleepmode. I need to kill FS UAE prior to sending my Mac to sleep, otherwise it will wake up regulary

@buzzybee I'm not sure about the first one, but I can answer the second one here and now:

Yes, running FS-UAE inhibits the screensaver (because you don't want the screensaver to kick in while playing a game - usually. This is the default behavior in the SDL library).

You can disable this feature by setting the following environment variable:

I added SDL_VIDEO_ALLOW_SCREENSAVER=1 to the general prefs using the FSUAE Launcher, also added it to Macs environment variable table. In both cases, the screensaver did not init itself. Grrr.

Generally speaking, I would expect the screensaver not to kick in as long as mouse, keyboard or controller are used. Therefore, playing using FSUAE should not be of concern regarding the screensaver, or do I miss something here?

I'm quite sure I tested this, but I will doublecheck later. No need to grrr :)

Well, people could be watching a demo, and time-to-screensaver can be quite short on laptops by default. So I think the default behavior of inhibiting the screensaver makes sense. Anyway, it would be best with a GUI option in FS-UAE Launcher to allow the user to discover this feature, so I created a tracking issue: https://github.com/FrodeSolheim/fs-uae/issues/272.

screensavers lol

What's the point

Well with modern displays (read OLED) Burn in is a thing again! So there is that. The new M1s have Mini LED, I'm not sure how the burn in is on those though. But for laptops, you generally want them to have a more aggressive sleep state, and turning off the screen is definitely one of those things that help save battery.

Yeah sorry I was assuming by screen save you meant like the graphical ones, rather than just putting the screen to sleep. Which is defo the more sensible thing :)

I've tested on macOS and confirmed the issue. Turns out I had written screensaver-inhibiting code (for Windows and macOS) long ago, before SDL supported it. I'm going to post updates with this legacy code removed, which will allow

SDL_ALLOW_SCREENSAVER=1

to work as intended.

I've replied you to on this before (via e-mail). Looks like subpixel scrolling needs a more up-to-date UAE code, as found in FS-UAE 4 (where the option uae_chipset_subpixel=true can be set). This will not be backported to FS-UAE 3.