Hi again!
Though I was following some train of thought that went something like, SheepShaver was originally created to bridge an applications gap with BeOS during its PowerPC years by bringing over Mac apps with the right hooks to support a full System 7 environment.
MACE is bridging that same gap, with an earlier version of the Macintosh Toolbox, in a more interesting way.
I recall reading about SheepShaver back in the day when BeOS on PowerPC was topical, but sadly I did not have chance to try BeOS until the x86 version (which I think SheepShaver did not work on at that time). It is such a long time ago, that I had to refresh my memory by doing some reasearch, but I found out (from
http://www.atpm.com/4.09/page12.shtml ) that it is true that one unique aspect about SheepShaver on PowerMacs was that it did not require ROM image, but used the actual ROM in the machine in the emulator. That is quite neat feature, and is a little closer to Apple's Classic environment, compared to other emulators such as Mini vMac, Basilisk II, and the x86 version of SheepShaver. All of those options, even Apple's Classic environment, still require installation of the real Mac OS, which is something M.A.C.E. does not require. I think the closest equivalent would be ARDI Executor, which also requires neither ROM or system software, but compared to it we are aiming to have better compatibility in the long run (especially to get older classic games to work, which have strict requirements for hardware emulation especially for sound/video buffers, 24-bit memory manager, etc...)
Reading your update on the work you are doing with Performance improvements and SystemTask, it looks like you have just added a threading model to the Toolbox!
I can’t help but think of the nanokernel (in 8.6 and later) rewritten in C and patched together with M.A.C.E.
Is this one of your goals!?!
Are you working toward preemptively multitasking and memory protection via the nanokernel for M.A.C.E. ? Would it even be possible?
The thought of a community-driven "Copland-like" system (even if it is minimal) is VERY alluring !!! Obviously a kernel does not make a system but still.... very alluring
J
Actually not really, technically we are only using the multithreading capabilities of host system to simulate interrupt and CPU "idle" operations. From the perspective of emulated applications, everything is still working as on the real Mac. The same "thread-safety" rules apply as on real Macs (which mostly can be identified by warnings in IM documents mentioning certain calls not being interrupt-safe - such as memory allocation calls not allowed from VBL handlers, etc...). The main application code running on main thread in the emulator equals to the single execution context on real Macs, which the interrupt handlers can, well, interrupt, but the code running in interrupt handlers cannot be be itself interrupted.
Technically, real Macs have various interrupt levels, which allow interrupts to be nested, but that is currently not supported as it has not been needed. For example, if VBL handlers exceed the 16ms limit (which is how often VBL interrupt fires), on real Mac a new VBL interrupt would be generated, which would only increase Ticks lowmem, but not re-enter the VBL task execution as it would already be running from the previous interrupt. This is one of the reasons sometimes on older computers, when VBL task exceeds the time limit, the mouse cursor would start getting "jittery" and "laggy", but the TickCount would still be valid as the Ticks would get updated properly. In our emulator, however, we run those "missed" Ticks increments on the next VBL interrupt, counting the number missed from the same timer which runs the audio synchronization with SDL audio thread.
However, nothing prevents running multiple M.A.C.E. instances on the same host operating system, and as they would be individual virtual machines, each of them would have from their own perspective exclusive ownership of the CPU, while in actuality the host system would schedule execution time between them, like currently on Mac OS X when running multiple M.A.C.E. applications at once. The downside of this is, though, that process manager-aware applications would only see their own instance, as the memory space is currently unique to each application. This is not yet a problem, but at some point there will be work needed to see whether process manager support is better to be implemented as System 7-style cooperative multitasking using exact process manager emulation, or whether for example launching of applications could be delegated to host system. This would however create challenges on how to handle program-to-program-communications, "shared" memory (on real Macs all apps share the same address space, and thus see each other AND the temporary memory allocated from the process manager/system heap).
I hope that information makes some sense - I am really better at writing code for all this, compared to writing documentation *about* it
Semi-off-topic: Of course, a dream situation would be to be able to create a completely independent Mac OS 7/9 operating system, but that would require adding a kernel and drivers, as currently the emulator depends a lot on host system to do a lot of the heavy lifting. However, I did write a couple years ago a small x86 "PC" BIOS bootloader, which can parse real HFS+ filesystem on MBR volume and launch executable stage 2 boot loader from "System" file in "blessed" System Folder (posted on
https://forum.osdev.org/viewtopic.php?f=1&t=12087&start=3297, direct link to image:
https://forum.osdev.org/download/file.php?id=3851&mode=view ). This however is quite far-fetched idea, so not really in scope for at least the next couple years...
I do know with 100% certainty that a number of years ago, Mark Stephen Pierce and SuperHappyFunFun purchased the rights to the Dark Castle series in order to release Return to Dark Castle. These were purchased from Delta Tao, who had acquired the rights in the 90s to make Color Dark Castle. Memory escapes me as to who they purchased them from originally, but it was whatever company had acquired Aldus (who, in turn, purchased Silicon Beach Software in the late 80s). So somewhere in that chain someone own the rights. It could be MSP himself, but at the least he would probably be the best person to ask for sure.
I was actually checking the ZSculpt website recently, as we have Dark Castle 99.9% complete (only issue left is that some [probably] CPU bug is causing the robots to behave erratically - otherwise everything works including controls, sound, gameplay, high-scores, etc), to see who to contact in case we get the game finally to full 100% completion. It would be really great to have this original, iconic game again publicly available on the modern Macs. Although Return to Dark Castle is also an awesome game - we played it through on easy level with Pukka a couple years ago in the office after-hours
(original Dark Castle we completed I believe at least on the intermediate difficulty, maybe even on advanced...cannot remember exactly).
Ps. There was request on Facebook for 10.6.8 compatibility for the emulator, so I actually added it to the build today (previously 10.7 was minimum), and updated the bundles with new version. So if any of you guys have 10.6.x, you can now give the apps a try on that system (it's actually very ironic, and kind of sad, that how blazingly fast the 10.6.8 is on iMac 2006 compared to 10.14 on 2015 MacBook Pro...with less memory, spinning hard drive, and much older CPU...)
