macOS Silicon + JAVA ARM64 *Solved*

[Jamie]

Edit: "What is this all about? I don't have Apple? (then stop reading )"
Well Apple decided to change the Intel CPU in their machines to it's own ARM processors a while ago. Pumping out a whole new range of laptops, iMacs and mini-Macs. The thing is PSX runs on Java. PSX on JAVA for ARM gave no Audio and no USB support. Java 8 runs on Intel.

The trick was an emulation layer, Apple invented Rosetta. Rosetta is kind of a software bridge between Intel-only software and the ARM processor. This allows to run PSX with Audio/USB-input on Silicon based (ARM processor) Macs.
Unfortunately Rosetta 2 will be phased out somewhere in 2027/2028. I had quite a few days off lately and the weather was bad anyways. So I found some time to dig into the (external) libraries PSX uses for it's Audio playback and USB input. Too long story short<g>: seems there is a whole bunch of people wanting to run JAVA Minecraft (a game) on Apple Silicon and older versions use the same PSX libraries.
I found some GITs, source code free to use on the internet. Started compiling those, had some trouble with it, but in the end succeeded.
Three binaries, one general, one Audio and one Input library which replaces the ones in PSX/Interfaces and are build for JAVA arm64.
- end edit -

These binaries are unofficial ARM64 builds for Mac Silicon (M1-M5) and are not official Aerowinx files!

That said...

The upcoming macOS "Golden Gate" v27 will be the last version which supports Rosetta 2, needed to run PSX on Java x64 on macOS.

I found this topic:
https://aerowinx.com/board/index.php/topic,7176.msg78278.html

This bothered me Especially while Apple plans to phase out Rosetta 2.

Then I found these:
https://shadowfacts.net/2022/lwjgl-arm64/
https://github.com/shadowfacts/lwjgl-arm64.git
https://github.com/shadowfacts/jinput-arm64.git

Archived:
https://github.com/JamieJanssen/jinput2-arm64-archive
https://github.com/JamieJanssen/lwjgl2-arm64-archive

So I started compiling them and fixed a few build errors. I now have:

* liblwjgl.dylib - v2.9.3 ARM64 build
* openal.dylib - v2.9.3 ARM64(?) build - obsolete, not needed.
* libjinput-osx.dylib 2.0.9 - ARM64 build

Surprisingly, this works on my MacBook Air M4 with Java SE 11 ARM64.

Sound + USB!
no errors in the error.log.

As far as I understand, I am allowed to share these files, so I have included the respective licenses.

TEST AT OWN RISK! ALWAYS BACKUP YOUR PSX!

Put them in your PSX directory/Interfaces

Download here (x64 + ARM64 compatible):
https://www.jamiejets.com/psx/psx-macos-arm64-x64-native-libs-unofficial.zip
This one should work for all. The link below is just a backup (ARM only).

ARM64 only version:
https://www.jamiejets.com/psx/psx-macos-arm64-native-libs-unofficial.zip

[Jamie]

/Please delete/

Yes 

I know Hardy strongly recommends v8, but I found v11 more modern:
jdk-11.0.30_macos-aarch64_bin.dmg

In macOS you can find your original Java install here:
/Library/Java/JavaVirtualMachines/

Check version installed (paste in terminal):
/usr/libexec/java_home -V

Code Select Expand

Matching Java Virtual Machines (1):
    11.0.30 (arm64) "Oracle Corporation" - "Java SE 11.0.30" /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home

[Will]

I know Hardy strongly recommends v8, but I found v11 more modern

Jamie, can you elaborate on this?

Thank you.

[Jamie]

If you want to install Oracle Java 8, it is only available as an x64 version (requiring Rosetta 2 Intel emulation). So there is very little chance of accidentally installing the wrong one.

I was mainly interested in seeing whether PSX could run natively on ARM, and for Oracle Java you need to move to Java 11 (LTS, Long-Term Support) to do that. I think alternatives like Azul have a JAVA8 for arm64 based CPUs.

Other than that, I don't think it makes much difference. I did some fairly extensive testing a while ago, and Java 11 seemed noticeably more stable in terms of FPS performance.

[Hardy Heinlin]

Jamie, you are a hero. This is great news indeed :-)

Thank you!

I also want to thank the anonymous guy at shadowfacts.net for all the hints and for his or her Github page.


Cheerio!

|-|ardy

[Jamie]

Thank you for PSX! And my company, for my duty roster

It looks like openal.dylib is the same version as the one included with PSX. The other two are definitely different.

I guess this still needs more testing. I had PSX running overnight on a long-haul flight, and everything was still working perfectly fine in the morning. USB, Audio and I'm still airborne Except my Xbox controller had fallen asleep, bummer. The Xbox controller is not very compatible with Mac unfortunately. If someone knows a good Mac portable compatible controller that works with cable, not BT. Maybe a Playstation controller?
Needs to be portable as my other half-brain forced me to the kitchen/living room. So no man-cave to build fancy cockpits 

[FlyItLikeYouStoleIt]

Thank you Jamie.

Your two dylibs liblwjgl.dylib and libjinput-osx.dylib are all that are needed to get this working on an M5 with Arm64 Java 11

The openal.dylib is useless as it is i32/x86 only and is completely superfluous.

In fact it turns out that openal.dylib can be deleted from the Aerowinx installation and PSX runs just fine using Apple's built-in OpenAL Framework. The following snippet proves that this is the OpenAL library used by a running PSX instance:

Code Select Expand

george@MacBook-Pro-M5 ~ % jps -v
50474 Aerowinx.jar -Xmx500m -Djava.library.path=Interfaces
50506 Jps -Dapplication.home=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home -Xms8m -Djdk.module.main=jdk.jcmd
george@MacBook-Pro-M5 ~ % vmmap 50474 | grep -i openal
__TEXT                      232943000-232964000    [  132K   132K     0K     0K] r-x/r-x SM=COW          /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
__DATA_CONST                296b131f0-296b13258    [   104    104     0K     0K] r--/rw- SM=COW          /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
__AUTH_CONST                2a1b366d8-2a1b36b88    [  1200   1200     0K     0K] r--/rw- SM=COW          /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
__DATA                      29b7ad588-29b7ad958    [   976    976    976     0K] rw-/rw- SM=COW          /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL

Finally, one can merge your Arm64 dylibs with the original Aerowinx dylibs to produce universal dylibs that support both Arm64 and X64 using the lipo command in the following general manner:

Code Select Expand

lipo -create -output liblwjgl.dylib liblwjgl.dylib-Jamie liblwjgl.dylib-Aerowinx
lipo -info liblwjgl.dylib


[Jamie]

Finally, one can merge your Arm64 dylibs with the original Aerowinx dylibs to produce universal dylibs that support both Arm64 and X64 using the lipo command in the following general manner:

Code Select Expand

lipo -create -output liblwjgl.dylib liblwjgl.dylib-Jamie liblwjgl.dylib-Aerowinx
lipo -info liblwjgl.dylib


Cool find! I "parked" openal.dylib aside and yes all works. That explains the build similarity.

Combining the two files works? O wow! Nice find/info!

[Jamie]

I still have a few questions:
1) FPS is not limited or limited at a lower setting than in the Settings e.g. 73 gives ~63Fps, 60 gives around 51Fps etc. This was the same with Rosetta. In Windows this is spot on. Why is that?

2) Activity Monitor

Code Select Expand

            CPU                                      GPU
Aerowinx    58,6    4:24,43    62    314    Apple    55,0    4:21,60    2216    jamie
How should I interpret this? like ~6% CPU (10Core, 4 perf/ 6 efficiency cores) and 55% GPU?

[Hardy Heinlin]

The OS might sleep 10 % longer after every thread loop in PSX, or the OS needs more computing time for graphic rendering etc., I don't know. My Intel iMac with Tahoe runs PSX at 67 fps. My old iMac, ten years ago, ran it at 73 fps.

This is the logic in PSX:

FPS limit label "48" : Thread sleep 20 ms (aiming for 50 Hz)
FPS limit label "60" : Thread sleep 16 ms (aiming for 63 Hz)
FPS limit label "73" : Thread sleep 13 ms (aiming for 77 Hz)

In every thread loop the sleep function is followed by the simulation program that the OS has to compute. On my old iMac this computation reduced the final fps from 50 to 48; from 63 to 60; from 77 to 73. So the computation increased the total sleep time by circa 0.7 ms. My newer Tahoe iMac needs 0.9 ms.

The computing time is just 0.2 milliseconds longer. A fraction of a millisecond. But it makes the difference between 67 fps and 73 fps (my eyes can't see the difference). Whether the additional time is required by newer security functions or by other OS features – I don't know. Or the thread sleep execution in the OS is slightly less precise. Or it's a mix of all these factors.

So, that's the background anyway :-)


Regards,

|-|ardy


By the way, PSX runs multiple threads. The high speed loop described above runs just a small part of PSX and the graphic rendering (only screen sections that need to be repainted). The biggest part of the simulation runs in the other thread loops. There are five PSX threads that Java can distribute to multiple CPU cores:

1 high speed loop, up to 73 Hz
1 loop at 20 Hz
1 loop at 5 Hz
1 loop at 1 Hz
1 loop at 0.3 Hz

[Jamie]

So the emulation was not the bottleneck anyway:
Rosetta 2 → ~63 FPS
Native ARM64 → ~63 FPS

At least we can enjoy PSX on the Mac for another decade 

my eyes can't see the difference

Nein, I was just wandering about the reason behing it. This explains it all. Thanks again!

Curious if someone with a M5 has the same results.

[Jamie]

I made a simple .java test:
A loop with a Thread.sleep(13); gives me exactly the ~63FPS.
A loop with a Thread.sleep(16); gives me exactly the ~51FPS.
A loop with a Thread.sleep(20); gives me exactly the ~42FPS.

On Windows my 'test' loop gives exactly the right values as in PSX. Sorry my OCD kicked in

So it's highly plausible that this is due to Java's thread sleep and scheduling behavior on ARM64 macOS.

[Hardy Heinlin]

I was just wandering about the reason

I know :-)

Apropos of frame rate limits: Actually, in the next PSX update I could decrease the sleep time by one millisecond or two. If all Macs and Windows machines nowadays need some more nanoseonds for their new stuff, there's no reason to keep those 13 ms in PSX that I programmed in 2008.

Edit:
I just noticed I reduced all thread sleep times in PSX version 10.50 already, in 2018 :-) I guess I should do that every 10 years :-)

[Jamie]

I know :-)

Apropos of frame rate limits: Actually, in the next PSX update I could decrease the sleep time by one millisecond or two. If all Macs and Windows machines nowadays need some more nanoseonds for their new stuff, there's no reason to keep those 13 ms in PSX that I programmed in 2008.

Edit:
I just noticed I reduced all thread sleep times in PSX version 10.50 already, in 2018 :-) I guess I should do that every 10 years :-)

Cool! haha Thanks Hardy! And sorry my OCD kicks in every now and then (more now than then)

[Hardy Heinlin]

You call that "OCD"? :-) I see no problem, no worries :-)

[Hardy Heinlin]

The frame rate is now increased by circa 10 % in PSX update 10.188:

https://aerowinx.com/board/index.php/topic,4191.0.html

My FPS sometimes exceeds 80 now. Macs that have been in the 60s should now reach the 70s.


|-|ardy

[Jamie]

Works as advertised Thanks!

[Jamie]

The openal.dylib is useless as it is i32/x86 only and is completely superfluous.

In fact it turns out that openal.dylib can be deleted from the Aerowinx installation and PSX runs just fine using Apple's built-in OpenAL Framework. The following snippet proves that this is the OpenAL library used by a running PSX instance:

Code Select Expand

george@MacBook-Pro-M5 ~ % jps -v
50474 Aerowinx.jar -Xmx500m -Djava.library.path=Interfaces
50506 Jps -Dapplication.home=/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home -Xms8m -Djdk.module.main=jdk.jcmd
george@MacBook-Pro-M5 ~ % vmmap 50474 | grep -i openal
__TEXT                      232943000-232964000    [  132K  132K    0K    0K] r-x/r-x SM=COW          /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
__DATA_CONST                296b131f0-296b13258    [  104    104    0K    0K] r--/rw- SM=COW          /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
__AUTH_CONST                2a1b366d8-2a1b36b88    [  1200  1200    0K    0K] r--/rw- SM=COW          /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
__DATA                      29b7ad588-29b7ad958    [  976    976    976    0K] rw-/rw- SM=COW          /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL


Just to make sure: should the OpenAL library included with PSX be left untouched, and only the other two be repackaged for Rosetta 2/ARM compatibility?

Finally, one can merge your Arm64 dylibs with the original Aerowinx dylibs to produce universal dylibs that support both Arm64 and X64 using the lipo command in the following general manner:

Code Select Expand

lipo -create -output liblwjgl.dylib liblwjgl.dylib-Jamie liblwjgl.dylib-Aerowinx
lipo -info liblwjgl.dylib


I did this for the liblwjgl.dylib and the libjinput-osx.dylib for maximum compatibility. Will change the .ZIP today.

[FlyItLikeYouStoleIt]

Just to make sure: should the OpenAL library included with PSX be left untouched, and only the other two be repackaged for Rosetta 2/ARM compatibility?

I did this for the liblwjgl.dylib and the libjinput-osx.dylib for maximum compatibility. Will change the .ZIP today.

The old openal library can be left untouched.

[DogsEarsUp]

OK - I'm aware I'm swimming in waters that are over my head here...

First of all thanks for all the work from you folks that has gone into this.

I've installed all as posted above, including Java 11
I use the demo.situ to check it's all working. Sound & USB all good

One thing that I've noticed is that Java 11 on my M3 Mac/Tahoe is "smoother" - there seems to be a more or less constant frame rate . I'm running at 2560 x 1440 Retina and getting around 30FPS average (estimated).

Here's a thing - If you want to see FPS Rocket on a Mac, turn off Retina and use standard 1 x 60Hz - I use a tiny app called easy res to toggle. Suddenly I'm running at 75FPS+

If everybody else in the world knows all this except me - sorry