Progress on our new Mac App Compatibility Environment

[tt]

@Toni_ I mostly just wanted to bump this thread since I think it's such a great project. I am wondering if you have tried working with HyperCard 1.x and 2.x? I find it's one of the apps that emulators often struggle with, especially the visual transitions between cards.

 

[Toni_]

@Toni_ I mostly just wanted to bump this thread since I think it's such a great project. I am wondering if you have tried working with HyperCard 1.x and 2.x? I find it's one of the apps that emulators often struggle with, especially the visual transitions between cards.

Hi,

Thanks for the support, it is always appreciated!  The HyperCard situation is still the same as last year when we last discussed about it - basically, in Hypercard 1.x, some transitions are visible but feel a bit fast, while others are not visible almost at all, so it might be they are tied to the CPU speed in that version of the application. And I think I might have "broken" something, because now HyperCard 1.x makes a SysBeep every time a new stack is opened :-D  And HyperCard 2.x is still stuck on missing styled textedit toolbox API.

For the past half year, our focus has been a lot on the newly added color quickdraw (and other "phase 2" features) which we have been excited about (right now I'm updating PICT recording to work with color ports and PICT2 format, to make ResEdit work in color mode), and also the summer has slowed down the progress a little bit (so much real-life things to do, especially now as the epidemic ended temporarily here at the beginning of the summer).

But that's a good reminder, I think prioritizing some unfinished non-color, "phase 1" features to be completed (such as in this case, styled textedit for hypercard 2.x) might be a good idea. Especially as a couple other applications also need it (at least editing text in Excel's cells, speedometer help and SimCity 2000 help windows are ones requiring the same missing toolbox API calls).

 

[tt]

Oh yes, I forgot about that. I also had some time to read through the compatibility notes on your site. Thanks for the reply and I'm looking forward to seeing your future developments.

 

[danda]

Wow, just stumbled across this thread today - never heard of M.A.C.E before but it looks really cool! I knew of the Reclassification project, but that's been dormant on GitHub for a while and was never beyond planning / alpha-quality. It's great to see such great progress in this area! My interest is firmly with HyperCard - I maintain the "HyperCard Stacks" collection at the Internet Archive, with over 3,500 stacks added so far. (This uses a JavaScript port of the PCE emulator, to allow the stacks to run in-browser).

I'm curious as to what the final business model for something like M.A.C.E is? Do you plan to open-source it? Or will it be a paid (commercial) offering?

 

[james_w]

I maintain the "HyperCard Stacks" collection at the Internet Archive

Oh wow! And you're in the UK!

I've uploaded one of my more recent stacks into that collection  and it's super fun to explore being a mega HyperCard enthusiast myself

 

[Toni_]

Wow, just stumbled across this thread today - never heard of M.A.C.E before but it looks really cool! I knew of the Reclassification project, but that's been dormant on GitHub for a while and was never beyond planning / alpha-quality. It's great to see such great progress in this area! My interest is firmly with HyperCard - I maintain the "HyperCard Stacks" collection at the Internet Archive, with over 3,500 stacks added so far. (This uses a JavaScript port of the PCE emulator, to allow the stacks to run in-browser).

Thank you, it's always nice to hear there is interest in this project   

I'm curious as to what the final business model for something like M.A.C.E is? Do you plan to open-source it? Or will it be a paid (commercial) offering?

Right now, the major plan is to create a FREE "Classic"-type runtime environment to allow everybody to use old Mac apps, but still keep it closed-source.

Ideally it would be awesome, if there would someday be a interest for a GOG-style service for old Mac games. We don't personally aim to create such service ourself, but we're happy if our tools help the creation of such a service. But realistically, we're just asking around Mac developers for permission of distributing the old games for free, and bundling them up as ready-to-run app bundles which are supposed to be as easy to use as possible (zero-installation, zero-configuration hassle).

Of course when we get the generic runtime environment someday ready, everybody can run any apps/games, we just want to make sure everything works as great as possible before we announce it, so that people won't get disappointed because of unfinished code/features.

But yeah as business model, right now the only thing remotely related to this is running the ads on our project page to try to cover the hosting expenses :-D  Right now, we're covering a bit less than 0.1% of expenses per year :lol:  Somebody suggested adding crowdfunding/donations etc, but we don't feel comfortable with that right now, as that would just add pressure to get finished quickly, and we only have limited amount of time to work on the project alongside the daily jobs.

Ps. Sorry for not replying earlier, for the past couple weekends I was working on this little unrelated hack for Color VETTE!, which I posted in separate topic on this forum: 

 

[Toni_]

Hi again,

It's still been a bit slow, but I managed to make a tiny bit of progress during this weekend. It's not much, but I helped Pukka fix some major issues in the 68020-specific full extension addressing mode in the 68K emulation, which allows us to run a bunch of games much further. And for fun, I also recorded a short video of Continuum gameplay, which I had planned to do since last year.

I wrote more details about this & uploaded screenshots of latest progress over here:

https://mace.software/2020/08/31/fixes-to-full-extension-addressing-mode-new-video/

As said, the summer has been really slow, but personally I'm going to speed up the development again now that the summer holidays are over, and I'll update this thread when we make progress - hopefully next time with more substance  

 

[Toni_]

Another quick update!

I haven't posted for a while here, to not spam this thread too much, but we're still progressing on the emulator, although recently a bit more slowly due to real-life work duties and other things taking a lot of time. But I think today's update might be fun one to show here:

https://mace.software/2020/10/30/marathon-fixed-inits-revisited-fun-with-control-panel-cdevs-after-dark/

Since last time I posted here, we have been improving various things, most importantly fixed the DIVU bug in September, and got already Prince of Persia 2 (almost) working - but this week we did something crazy, and got the real, unmodified Control Panel desk accessory (AND After Dark cdev) to work in MACE, and now some of After Dark modules are working in the color mode nicely without problems There's still ton of things to do, but this is a nice inspiration & motivation for working on the "generic classic" environment mode in the emulator in the future, as it gives a glimpse how the user experience might be, after we write the non-apple replacement for the Control Panel DA in future! 

 

[Toni_]

I just wanted to give a brief update with some good news:

We recently managed to contact the authors of both Glider 4 and Scarab of RA, and just in time for the Christmas holidays, got permission for putting both of those classic games available for free download as M.A.C.E. application bundles!

So if you want something fun to play during the holiday break, here's the blog post I wrote about this just a few minutes ago with more details: https://mace.software/news/

Both signed and unsigned macOS versions are available, and also unsigned Windows 10 version here: https://mace.software/files/

If you have chance to try them, let me know how they work for you. There is at least one known audio issue with the classic sound emulation, which is mentioned on the update, but otherwise in our own testing we've found the games to work pretty well.

Happy holidays & stay safe!

 

[snes1423]

may I ask when this will be available

 

[olePigeon]

@Toni_ Don't suppose you could contact Ben Haller over at Stick Software?  He wrote my all-time favorite Mac game: Solarian II.  Unfortunately, he had a computer crash a while back and didn't have a backup.  So he lost most of the original source code for the OS X version.  So he hasn't bothered updating it.

Would be great to have Solarian II running on a modern computer.

 

[Toni_]

may I ask when this will be available

It depends which of our goals you are asking about...In the current stage, we are adding some individual applications as pre-packaged bundles as soon as we have both author's permission (if applicable), and when we have time to bundle them for testing. We already have a bunch of those available for trying out. The next milestones are still implementation of the generic runtime, and application bundle maker tool, but they are roughly still (at least) one year away. That is because we want to make sure everything is 100% compatible, as even though 99% of features and games are working, the missing 1% might cause disappointment which we want to avoid. But I estimate the black & white "classic" versions will be first available, with color version following as soon as the toolbox support is complete enough. 

@Toni_ Don't suppose you could contact Ben Haller over at Stick Software?  He wrote my all-time favorite Mac game: Solarian II.  Unfortunately, he had a computer crash a while back and didn't have a backup.  So he lost most of the original source code for the OS X version.  So he hasn't bothered updating it.

Would be great to have Solarian II running on a modern computer.

That's a great idea! I checked right now the compatibility of Solarian II in the emulator, and it seems that at least Color Manager custom search procedure support is needed to allow the game to start, so I'll need to follow up on that. But thanks for the suggestion!

 

[vanfanel]

Hello @Toni_!

I just registered this forum because of your project. MACE seems awesome!

Did you know there's something similar to MACE for running Acorn Archimedes software on Risc OS on modern systems?

https://forums.jaspp.org.uk/forum/index.php

I believe MACE does the same for MAC software (ie, reimplementing parts of the OS so apps run "natively" on the host system), right?

I am eagerly wanting to try MACE, but I am a GNU/Linux user and I can't see any Linux binaries to try.

MACE would be better without X11, directly accessing the framebuffer via the KMS/DRM infraestructure: SDL2 has a very nice KMSDRM backend, so... if you port MACE to SDL2, you can run MAC apps without X11, in a very lightweight enviroment.

So, what does MACE run on? Does it run on SDL2 for platform-abstraction?

Also, I would LOVE to have it running on aarch64

 

[Toni_]

Hello @Toni_!

I just registered this forum because of your project. MACE seems awesome!

Hi,

Thank you very much for the questions. I will try to answer here as well as I can:

Did you know there's something similar to MACE for running Acorn Archimedes software on Risc OS on modern systems?

https://forums.jaspp.org.uk/forum/index.php

I believe MACE does the same for MAC software (ie, reimplementing parts of the OS so apps run "natively" on the host system), right?

I was not aware of the Acorn RISC project, I am not familiar with it. But if it is similar to what Wine is for Windows, it might also share similar goals as M.A.C.E., although for different platform.

I am eagerly wanting to try MACE, but I am a GNU/Linux user and I can't see any Linux binaries to try.

MACE would be better without X11, directly accessing the framebuffer via the KMS/DRM infraestructure: SDL2 has a very nice KMSDRM backend, so... if you port MACE to SDL2, you can run MAC apps without X11, in a very lightweight enviroment.

So, what does MACE run on? Does it run on SDL2 for platform-abstraction?

Also, I would LOVE to have it running on aarch64

We use SDL in the current prototype (See https://mace.software/2018/03/12/sdl2-the-fake-rom-and-resource-maps/ ), but we plan to implement platform-specific adapters soon, because the SDL integration is causing limitations and problems we want to avoid in the future. For example, the seamless desktop needs Cocoa-specific API on Mac, and another problem is that for example at the moment the native menus are handled by SDL, which causes most annoyingly the Cmd+M to minimize the window

Currently we have tested M.A.C.E. on Mac OS X 10.6 through macOS 11.1, Windows 10 (64-bit), Haiku x64, and Raspberry Linux - with the two last ones having lower priority due to some complications:

• On Haiku, the SDL has problems with audio and mouse, so it may need platform-specific adaption or SDL update ( last tested in https://mace.software/2019/02/26/progress-on-haiku-port/ )
  
• On Raspberry Linux, audio does not work on my builds but the Linux X11 works, while audio works on my friend's (who I am working on the project) builds but SDL video output does not work properly for him ( status in https://mace.software/2020/01/01/happy-new-year/ ), and besides that, the builds we did only work on the Linux system they were compiled on - we tried with my friend to run precompiled build on each other's Raspberries, but the builds would not run, because the compiled programs seem to only run the exact specific Linux version they were compiled on.
  

We will support more platforms in the future, but right now the main focus is on getting the core functionality completed, and reach the most important milestones, so we get the fully generic mac application environment finished as soon as possible (in addition application packager & pre-packaged applications bundles) - which is most important step to get M.A.C.E. to the state, where it would be ready for a wider general purpose use, and be much more usable that way for a wider audience.

Also, I would LOVE to have it running on aarch64

M.A.C.E. core already runs on aarch64, as we tested the Rasperry Linux (as it is ARM) —  and actually just now on yesterday, I finally received and set up Apple Macbook Air with M1 processor, and verified that everything compiles and works perfectly on Apple Silicon, which is also 64-bit ARM (I will write later in this month details about the M1 progress to our blog and try to get universal macOS binaries ready by that time). — But as a teaser, the M1 is a quite good performance-wise; emulation seems to run roughly 4 times as fast on native M1 (speedometer score 146.2) compared to our previously fastest computer (2015 macbook pro, speedometer score 35.8) - and even Rosetta-emulated x86 code was 2.5 as fast (score 90.6). But more on that later...

 

[cheesestraws]

Did you know there's something similar to MACE for running Acorn Archimedes software on Risc OS on modern systems?

I was not aware of the Acorn RISC project, I am not familiar with it. But if it is similar to what Wine is for Windows, it might also share similar goals as M.A.C.E., although for different platform.

ADFFS is not really comparable to this.  It's aimed at running RISC OS software on RISC OS across some changes in CPU architecture details, and consists largely of patches to what is already there to provide older behaviours to older software, especially when it comes to video.  It's a very impressive piece of software, don't get me wrong, and I love it and use it extensively, but it's not a clean-room reimplementation of the RISC OS API, nor will it permit RISC OS software to run on a foreign OS.  This project, on the other hand, is a clean-room implementation of the classic Macintosh API, and it must run on a foreign OS as there is no real successor to the classic MacOS.  wine probably is a much closer parallel than ADFFS.  There have been attempts at similar approaches for RISC OS but I'm not sure any of them have got very far.

 

[vanfanel]

@Toni_ I know the MACE sources are not public, but since I am an SDL2 developer (I am in charge of the KMSDRM backend, which is a GREAT way to run MACE! No X11!), could I get private access to the code so I can try to build it for Pi Aarch64 on SDL2/KMSRM? Maybe I can help investigating these audio issues. Well, another couple of eyes can't be bad

What MACE does is a personal dream of mine: running Mac OS apps natively on GNU/Linux without X11, on something affordable as the Pi, is a dream come true, really. I would very happy to build, test and help in the realization of the dream.

I did the RetroGuru ports to SDL2, too, via private access to their code.

I have also been a "private" tester for ADFFS for years, and I never, ever filtered anything, and did hundreds of hours of testing and reports. I have no commercial interests anywhere (I don't work with computers, my FOSS developments are self-motivated ONLY).

 

[cheesestraws]

I have also been a "private" tester for ADFFS for years, and I never, ever filtered anything, and did hundreds of hours of testing and reports

(tiny sidetrack: thankyou for your work on this, I use ADFFS very regularly, and I'm very very glad it exists.)

 

[BacioiuC]

@Toni_ is there a way to get in touch with you guys regarding MACE? I'm working on a game for 68K macs and I MACE could help in bringing the game to a wider without requiring me to port it to other platforms.

 

[Toni_]

@Toni_ I know the MACE sources are not public, but since I am an SDL2 developer (I am in charge of the KMSDRM backend, which is a GREAT way to run MACE! No X11!), could I get private access to the code so I can try to build it for Pi Aarch64 on SDL2/KMSRM? Maybe I can help investigating these audio issues. Well, another couple of eyes can't be bad

What MACE does is a personal dream of mine: running Mac OS apps natively on GNU/Linux without X11, on something affordable as the Pi, is a dream come true, really. I would very happy to build, test and help in the realization of the dream.

I did the RetroGuru ports to SDL2, too, via private access to their code.

I have also been a "private" tester for ADFFS for years, and I never, ever filtered anything, and did hundreds of hours of testing and reports. I have no commercial interests anywhere (I don't work with computers, my FOSS developments are self-motivated ONLY).

Hi, and thanks for the question! It does sound interesting, but we should get back in touch with this later, when the project matures a bit. Our work on raspberry pi is still quite experimental, and we haven't had a lot of focus on it, but we do plan on exploring the support later more. Thanks for the tip on KMSDRM, it sounds interesting approach on that platform. We don't rule any options out right now, but things are a bit busy in the near future, so need to talk about this more later.

@Toni_ is there a way to get in touch with you guys regarding MACE? I'm working on a game for 68K macs and I MACE could help in bringing the game to a wider without requiring me to port it to other platforms.

Yeah if you have 68k game you'd like to have a MACE wrapper for, we'll be happy to try it in the emulator and build you the bundle. The plan is to make a bundle-maker application at some point (as soon as possible), which people could use to package any mac applications themselves, but there's still work need to be done on it, so at the moment we have to do the packages manually. Drop me a private messages when you want us to try it out, and I'll handle it ASAP. Do note though, that toolbox API support is still incomplete in a few places on "classic" mode - and in a lot of places on color mode - so there might be 1% chance that some things might not work as expected

(I think biggest step needed to have at least somewhat easy way to do custom packages is to switch from our current static configuration system to a dynamic one, so that things such as system version, machine type, resolutions, color depths, startup application name etc could be changed without needing to recompile the emulator - I am confident work on this will be done around summer this year)

 

[BacioiuC]

Drop me a private messages when you want us to try it out, and I'll handle it ASAP

Awesome, thanks! Trying to get a demo ready in a month's time and I'll poke you guys then.

Do note though, that toolbox API support is still incomplete in a few places on "classic" mode - and in a lot of places on color mode - so there might be 1% chance that some things might not work as expected

The game is targeting B&W compact macs so no color involved. Also side stepping a lot of quickdraw operations (outside of GetPic and DrawPic to put into GrafPtrs as texture atlases and the usual window toolbox + button routines) so hopefully there are not many problems to be found .

Thanks a ton, I'll be in touch!

 

[adespoton]

Hi, and thanks for the question! It does sound interesting, but we should get back in touch with this later, when the project matures a bit. Our work on raspberry pi is still quite experimental, and we haven't had a lot of focus on it, but we do plan on exploring the support later more. Thanks for the tip on KMSDRM, it sounds interesting approach on that platform. We don't rule any options out right now, but things are a bit busy in the near future, so need to talk about this more later.




Yeah if you have 68k game you'd like to have a MACE wrapper for, we'll be happy to try it in the emulator and build you the bundle. The plan is to make a bundle-maker application at some point (as soon as possible), which people could use to package any mac applications themselves, but there's still work need to be done on it, so at the moment we have to do the packages manually. Drop me a private messages when you want us to try it out, and I'll handle it ASAP. Do note though, that toolbox API support is still incomplete in a few places on "classic" mode - and in a lot of places on color mode - so there might be 1% chance that some things might not work as expected

(I think biggest step needed to have at least somewhat easy way to do custom packages is to switch from our current static configuration system to a dynamic one, so that things such as system version, machine type, resolutions, color depths, startup application name etc could be changed without needing to recompile the emulator - I am confident work on this will be done around summer this year)

Hey Toni_,

I was just about to shoehorn a few games into the existing packages, and then realized that summer has come and gone If you've got anything you want me to test, let me know.

Meanwhile, your contact link on the website is dead, as it points to the old 68kmla forum. Might be a good idea to update it

PM me if you're interested, otherwise I'll break out the hex editor in a week or so. The biggest pain will be fighting with Monterey to let the modified apps run. I'll probably have to build up the apps from scratch and paste in the binary code to evade Apple's protections at this point.

Also, a few questions:
I noticed that you're currently forcing Intel mode on the apps; I'm fully M1 on the host side now, and forcing the apps to run in Apple Silicon mode appears to work just fine. Is there a reason for explicitly setting Intel as your priority architecture?

I also noticed that you embed a few flags for things like fullscreen and hidpi. Is there a plan to migrate these to a plist for easier tweaking?

Thanks for keeping this project going!