Verify the MacOS Binary

[nbarger]

I'll try building this through MacOS. If it works, I'll upload it here. If not, I'll see what I can do to make it work.

To build it yourself:

Make sure you have:

XCode Command Line Tools (May be installed already on your computer)
SDL2
CMake
Make
A C++ compiler

Now make sure you have Homebrew

Install the requirements on Terminal with:

#xcode-select --install
brew install sdl2
brew install cmake

The rest of the building is the same as the normal source building.

If this brings you an error than let me know and I'll try and find the cause.

[nbarger]

Worked just fine. For anyone who wants it, here is the binary. If possible, I would appreciate if it was added to releases. MacOS.zip

Thanks. Consider me a MacOS tester. :)

[sam-astro]

Hi! Thank you for your work. Before this is placed with the other releases, I will need at least one more person to verify it.

[nbarger]

Thanks, it was nothing!

But yeah, that's what I thought, because Mac is a very, uh.. funky... and unpredictable platform. Whenever I try to build stuff most of the time it doesn't work for me, however it does for other people. So I guess we'll just have wait and see.

Also I believe the build I made for it only works on Intel Macs so we need someone who can build for the other arch. I actually forgot what it is :| I also forgot to add build instructions.. I'll just need to put the requirements.

[bc1bb]

I can confirm the code compiles on my M1 MacBook Pro, but this exe doesnt work for me;

it requires x86 libSDL2 to be available in what I would consider a strange path (/usr/local/lib/libSDL2-2.0.0.dylib), but a simple sudo ln -s /opt/homebrew/lib/libSDL2-2.0.0.dylib /usr/local/lib/libSDL2-2.0.0.dylib can solve this problem if you have installed SDL2 from homebrew just like but then you'd need to have x86 SDL2, which I do not so I just built from scratch.

Anyway, here is a Apple Silicon compatible build: Astro8-Emulator.zip

[nbarger]

Thanks for your contribution!

it requires x86 libSDL2 to be available in what I would consider a strange path (/usr/local/lib/libSDL2-2.0.0.dylib), but a simple sudo ln -s /opt/homebrew/lib/libSDL2-2.0.0.dylib /usr/local/lib/libSDL2-2.0.0.dylib can solve this problem if you have installed SDL2 from homebrew just like me.

I believe the reasoning for this is because I used the SDL installed from the DMG on the website, and it installed into /usr/local/lib which is the default library location. A better way to manage this issue to keep users from having to install SDL2 to run it is to either package the program in a .app along with the SDL lib, or attach the EXE in a folder with it. Then you'd have to set the build to use the lib in the folder instead of in the /usr/local/lib/libSDL2-2.0.0.dylib path. Packaging the exe into an app might not work, however, because the program uses command-line input which requires use starting with the terminal.

If the EXE isn't working, then it's probably because I built it on an Intel Mac, which uses a completely different CPU architecture than the Apple M1. I think there's some software that allows you to run the Intel apps, but I forgot the name. If I got this wrong, then please forgive me.

[bc1bb]

I believe the reasoning for this is because I used the SDL installed from the DMG on the website, and it installed into /usr/local/lib which is the default library location.

Oh, yeah, probably!

is to either package the program in a .app along with the SDL lib, or attach the EXE in a folder with it.

That's a good idea!

If the EXE isn't working, then it's probably because I built it on an Intel Mac,

The problem wasn't the exe but the library, I had it for arm and you built for x86 so it didn't work, tho what you were talking about is Rosetta, a translation layer (just like WINE) that works very well on macOS and there is nothing to enable BTW, when you run a x86 executable it'll go through Rosetta inevitably,

I think packing everything into an x86 .app (like most apps do) could allow both Silicon and Intel users to use the application correctly btw

[nbarger]

I think packing everything into an x86 .app (like most apps do) could allow both Silicon and Intel users to use the application correctly btw

The only problem with this is that the application uses command line features (command line arguments and debugging) to load files. We could make a version of the program that works kinda like an emulator (FCEUX or Mesen) and allow you to load a program by using the menu at the top (file, edit, etc..). This could also allow for pausing, running, memory viewing, and other things useful for debugging. We could even integrate this into the main version of the program if @sam-astro is okay with it. But ANOTHER problem is that we'll have to use another library to handle the window menu and stuff. This would most likely be done with Qt since it supports SDL rendering; but, since it's quite a heavy library, "that seems like a huge dependency for such a simple thing," as said by Daniel_Gibson in this forum

I'm not much of a C++ pro, however I'm trying to get better. I'll try integrating this feature somehow, maybe with a pull request or fork. I could also possibly rewrite an emulator in Java, which is cross platform and supports SDL, windowing, etc..

[nbarger]

This is probably gonna make a big loophole, but I'll do it.

I'm either going to make my own fork of the project, or I'm going to add a pull request.

Help would be appreciated, I tend to mess things up, and other people helping would be nice, plus I would have more motivation to continue on.

I'll make use of the current engine, combined with Qt. I may also clean up the project a little (separating the VM functions into it's own files for example). Instead of making use of the console, it will instead use the menu at the top of the window/screen to interact, like loading files, pausing and debugging the machine.

[nbarger]

Now switched to #22

[bc1bb]

I think you can make a simple gui wrapper that could ask for arguments and then simply launch the executable in the user’s favourite terminal

[Dark-Rock]

Worked fine on my M1 Mac.

[bc1bb]

Worked fine on my M1 Mac.

Which file worked ?