Previous working on Apple Silicon (natively!)

Started by larbob, December 30, 2020, 08:24:54 PM

Previous topic - Next topic

larbob



Got it working! Here's how you can get it working too:

Make sure you have xorg-server, readline, zlib, libpng, mesa, and cmake installed through MacPorts.

Then, grab SDL2 2.0.14 from http://libsdl.org/release/SDL2-2.0.14.tar.gz and extract it. Edit `src/video/x11/SDL_x11opengl.c` and change line 42 (`#define DEFAULT_OPENGL  "/opt/X11/lib/libGL.1.dylib"`) to `#define DEFAULT_OPENGL  "/opt/local/lib/libGL.1.dylib"`. This fixes where SDL2 looks for the OpenGL dynamic library since the official XQuartz.app doesn't support Apple Silicon yet. You can't use MacPorts' SDL2 X11 variant as it doesn't actually patch this properly (I've submitted a ticket).

Compile SDL2 with `./configure --disable-x11-shared --x-libraries=/opt/local/lib --x-includes=/opt/local/include` and install it with `sudo make install`.

You can then build Previous. I have the source up on GitHub, so you can grab it with `git clone https://github.com/larb0b/previous`. You can install it with something like `mkdir build && cd build && cmake .. && make -j && sudo make install`.

This'll give you a working app in /Applications, but it'll crash on launch normally. It needs the environment variable SDL_VIDEODRIVER set to x11, so I've been launching it in the terminal with `SDL_VIDEODRIVER=x11 /Applications/Previous.app/Contents/MacOS/Previous`. Also, make sure the X server is running when you launch Previous (`/Applications/MacPorts/X11.app`). There seems to be some incompatibility between Previous and SDL2's Cocoa support past SDL2 ~.10 or ~.12, even on Intel.

Also, you might want to enable "Option keys send Alt_L and Alt_R" in the X11.app preferences. You won't be able to unlock the mouse otherwise. Furthermore, you'll want to disable mouse auto-locking in the Previous configuration otherwise the mouse won't work properly once you've clicked in a Previous window.

EDIT: I've posted a link to a build here: http://www.nextcomputers.org/forums/index.php?msg=26610

EDIT 2: Xquartz now has alpha builds available with native support for Apple Silicon. With this, you shouldn't need to install mesa or xorg-server from MacPorts, and you shouldn't need to make that change to `src/video/x11/SDL_x11opengl.c`.


mikeboss

October 12, 1988 Computing Advances To The NeXT Level

larbob

Here's a copy: http://mirror.rqsall.com/misc/next/previous/apple_silicon/Previous.dmg

You're going to want xorg-server, mesa, readline, libpng, and zlib from MacPorts installed before trying to use this. SDL2 is bundled inside the .app as I had to patch it to look for the OpenGL library in the correct place.

You don't need to set the SDL_VIDEODRIVER environment variable like I had to above, this does it for you. You just need to launch Previous.app and everything should work fine as long as you have those prerequisites installed. It should automatically launch X11.app for you if you don't have it open already when launching.

larbob

Here's a video of me launching it and booting the OPENSTEP 4.2 installer:

itomato

-itomato

eagle

I don't recall Previous/x64 requiring X11; why is it required for the ARM version?  I mean, this is very cool, awesome work, I'm just curious.
My NeXTs:
NeXT Computer prototype (68030-25 x2, 68040-25)
Two NeXTstations (68040-25)
All mono

larbob

Quote from: eagle on January 08, 2021, 06:42:17 AMI don't recall Previous/x64 requiring X11; why is it required for the ARM version?  I mean, this is very cool, awesome work, I'm just curious.

Something seems to be broken between Previous' Cocoa stuff and the latest SDL2 versions, so using X11 instead seemed like a good enough solution.

larbob

Quote from: itomato on January 05, 2021, 08:53:44 PMNXBench results please :)





NeXTcube Turbo, no NeXTdimensions, NXBench 2.5. This was done on my M1 Air on battery power.

MahRain

I was able to compile from source (r1033-Trunk) and run on Big Sur 11.5 on an iMac M1. There was one bug related to a file named 'VERSION' in the src/Slirp folder, where renaming this to anything else fixes it (a known bug with macOS SDK 11.3).

I installed SDL from source and I don't need X11. Let me know if you need me to upload a binary somewhere?

zombie

I'm curious how fast the "variable" CPU reports when running on the M1. On the Mac Pro, I think it gets up to around 50Mhz.  So not much faster than a standard cube.  Would be great to see numbers get over 100MHz.

eagle

If you have a tarball, I'm happy to put it on my site -- previous.unixdude.net.  And, I'd love to have it for myself. :D
My NeXTs:
NeXT Computer prototype (68030-25 x2, 68040-25)
Two NeXTstations (68040-25)
All mono

MahRain

Quote from: zombie on July 25, 2021, 09:27:41 AMI'm curious how fast the "variable" CPU reports when running on the M1. On the Mac Pro, I think it gets up to around 50Mhz.  So not much faster than a standard cube.  Would be great to see numbers get over 100MHz.

I see the CPU number changes a bit, and increases with higher workloads. This is the highest I've seen it go doing a Mandelbrot calculation. Let me know if this is right, else I can run some other tests.

138MHz.


andreas_g

It is normal that the CPU frequency changes in variable mode. Only user mode code is executed at full speed. Supervisor mode code is always executed at the same (more realistic) speed. This is required, because else the timings would get out of control and on fast systems you would see weird problems causing instability. As a positive side effect Previous eats less host CPU cycles while being idle.

I just checked on my system (iMac early 2009, 2.66 GHz Intel Core 2 Duo): It peaks at 40 MHz when running the Mandelbrot demo. Note that CPU emulation only uses one CPU core, so we only compare single core performance here.

zombie

I notice that the emulator bombs and runs more buggy when using 60ns memory instead of 70. Is there a chance that is bad interplay with the variable CPU speed?