Jump to content
Toni_

Progress on our new Mac App Compatibility Environment

Recommended Posts

8 hours ago, Toni_ said:

One important note we found out was that the transitions don't appear to have a speed throttle, so they're running too fast at least in HyperCard 1.0.1 we're testing. In the debug version with full logging the emulation slows down enough to allow transitions to be visible, but in release mode with no debug logging they're basically instant. I've checked that at least on Minivmac the speedup appears to follow same pattern.

I checked out the latest Basilisk build and noticed that now the HyperCard transitions are "gone", so they must be generating way too fast to see like you mentioned. I guess speed/timing in general for games/visuals is a challenge to get the right for emulation. But I wonder how the speed was regulated from a Mac Plus to a Quadra type machine.

Share this post


Link to post
Share on other sites

Hi again!

 

Today we managed to get a really cool feature functional - We can now run After Dark (and in future theoretically any *compatible* extensions/control panels) in our emulator :-)

 

https://mace.software/2019/04/08/experimenting-with-init-cdev-support/

 

I've written a blog post about this feature above, and there's also screenshots (and video!), in which we run After Dark (using default "Starry Night" as modules cannot yet be configured) loaded "inside" MacPaint application. :-D 

 

On 4/2/2019 at 9:02 AM, tt said:

I checked out the latest Basilisk build and noticed that now the HyperCard transitions are "gone", so they must be generating way too fast to see like you mentioned. I guess speed/timing in general for games/visuals is a challenge to get the right for emulation. But I wonder how the speed was regulated from a Mac Plus to a Quadra type machine.

I'm guessing (but not sure, as I haven't had time to verify this assumption) that the original versions of HyperCard didn't actually have any speed throttle, but it was probably added in later versions of HyperCard - A lot of the early software seems to have this same issue. Considering that HyperCard 1.x was developed in 1987, the same year as Mac II was launched, I thinks this the be highly probably. However, we will check this hypothesis when we someday get the Styled TextEdit to work and can start to work on adding HyperCard 2.x support :-) 

Share this post


Link to post
Share on other sites

Hi again!

 

It's been a bit quiet for the past month(s), a lot of the "getting-more-outside-less-staying-inside" type stuff going on in the summer, but I took a few evenings in the past weeks to do some work on TextEdit features, and wrote a quick summary on what's new:

 

https://mace.software/2019/06/17/mid-summer-update-textedit-progress/

 

Most interesting parts are probably that Scarab of RA is now almost completely playable (yey!), and HyperCard 1.x can enter "userlevel 5" which opens door to a bunch of interesting new options to edit the stacks :-)

 

The progress will probably be quite slow in the summertime, but hopefully in the fall we'll be at least a little bit closer to the goal of getting the more "Classic replacement"-type release of emulator, so you guys could try out more than just the few bundled apps :-)No promises yet though on the date...but we're definitely getting there someday!

Share this post


Link to post
Share on other sites

I saw! The Scarab of RA and HyperCard progress is especially amazing.

 

Not that you might find this interesting, but I've found all the MACE packaged apps that have been released work wonderfully under VMware (ESXi 6.7 and Fusion 11.1.0) on macOS Mojave.

 

That's more than I can say for most games. The only other ones I've found to work really well are Thimbleweed Park and (to a degree) RenPy-powered visual novels. That all seems to come down to the software OpenGL driver being insufficient for most... so, props for avoiding the GPU as much as possible! :)

Share this post


Link to post
Share on other sites
On 6/17/2019 at 4:15 AM, nglevin said:

I saw! The Scarab of RA and HyperCard progress is especially amazing.

 

Not that you might find this interesting, but I've found all the MACE packaged apps that have been released work wonderfully under VMware (ESXi 6.7 and Fusion 11.1.0) on macOS Mojave.

 

That's more than I can say for most games. The only other ones I've found to work really well are Thimbleweed Park and (to a degree) RenPy-powered visual novels. That all seems to come down to the software OpenGL driver being insufficient for most... so, props for avoiding the GPU as much as possible! :)

Thanks for the feedback, it's appreciated :-)

 

Interesting to know that they work under virtualization, we haven't tried that on the Mac OS X version...we're actually currently using SDL2 as platform abstraction back-end, which actually when running on Mac OS X defaults to OpenGL rendering, so it may be that if other applications are having hard time doing OpenGL under virtualization, that SDL2 might be smart enough to switch to non-accelerated back-end... In any case, we'll some day eventually switch to more native platform abstraction, which in Mac OS X case would be (at the moment) Cocoa (and at the same time we'll also fix the nasty mouse click issue people have been reporting on touchpads when testing the current application bundles).

 

Ps. I took a little break today to record a short video of how lemmings gameplay looks like, now that it finally works :-D

https://www.youtube.com/watch?v=qqSpRqhGf4U

 

Share this post


Link to post
Share on other sites

Hi again :-) We're back from holiday trips, and although we're still on summer vacation, I just wanted to let you guys know there's been some progress during this time; we can now basically run TeachText, with nearly all TextEdit features working. I did a quick blog update which includes one holiday photo from each/both team members, which also details a bit more what we've been up to in the past few weeks:

 

https://mace.software/2019/07/14/second-mid-summer-update-post-holiday-textedit-progress-clipboard/

 

Next up is resource fork write support, which is already nearly completed, but there'll be more details about that later when it's done :-)

Share this post


Link to post
Share on other sites
On 6/18/2019 at 2:31 PM, Toni_ said:

...we're actually currently using SDL2 as platform abstraction back-end, which actually when running on Mac OS X defaults to OpenGL rendering, so it may be that if other applications are having hard time doing OpenGL under virtualization, that SDL2 might be smart enough to switch to non-accelerated back-end...

That makes perfect sense. Thimbleweed Park also uses SDL 2 on Windows and Mac though apparently not for rendering.

 

I don't know if it's defaulting to a software renderer, or using the OpenGL APIs in a dumb-as-bricks way (draw to texture, copy texture to framebuffer levels of basic) that's almost complimentary to falling back to software rendering. Both seem completely possible.

 

I'd have to dig into the developer.apple.com graphics tools for OpenGL to see what's up, if they're still functional with the post Metal 2, modern macOSes.

 

On 6/18/2019 at 2:31 PM, Toni_ said:

In any case, we'll some day eventually switch to more native platform abstraction, which in Mac OS X case would be (at the moment) Cocoa (and at the same time we'll also fix the nasty mouse click issue people have been reporting on touchpads when testing the current application bundles).

Sounds good. Tapping into Cocoa/AppKit event handling sounds like a solid plan, the documentation is from a time when the Apple docs were up to date, comprehensive and easy to read.

 

23 hours ago, Toni_ said:

Next up is resource fork write support, which is already nearly completed, but there'll be more details about that later when it's done :-)

Very nice. This is absolutely putting cart before horse, but do consider reaching out to the Engsts @ TidBITS since I'm sure they'd love to play with it and give it a little publicity. Particularly for HyperCarding.

Share this post


Link to post
Share on other sites

Hi again,

 

I just wanted to let you guys know that we've made an interesting break-through progress in the emulator, we can now "almost" run Apple's ResEdit 2.x :-) As a side effect, we have now resource decompression support, and a bunch of cool screenshots :-D 

 

https://mace.software/2019/07/24/update-on-resource-fork-writing-resedit-and-resource-dcmp-decompressors/

 

There's still a lot to do, but we're working hard on getting the more general release out later this year...I'll get back to you later :-) 

On 7/15/2019 at 12:58 AM, nglevin said:

That makes perfect sense. Thimbleweed Park also uses SDL 2 on Windows and Mac though apparently not for rendering.

 

I don't know if it's defaulting to a software renderer, or using the OpenGL APIs in a dumb-as-bricks way (draw to texture, copy texture to framebuffer levels of basic) that's almost complimentary to falling back to software rendering. Both seem completely possible.

 

I'd have to dig into the developer.apple.com graphics tools for OpenGL to see what's up, if they're still functional with the post Metal 2, modern macOSes.

 

Sounds good. Tapping into Cocoa/AppKit event handling sounds like a solid plan, the documentation is from a time when the Apple docs were up to date, comprehensive and easy to read.

 

Very nice. This is absolutely putting cart before horse, but do consider reaching out to the Engsts @ TidBITS since I'm sure they'd love to play with it and give it a little publicity. Particularly for HyperCarding.

 

Thank you very much for the link and idea, it is highly appreciated and I will definitely reach out for them at some point. I think the best time to do that would be when we are ready for a more general release, as the currently packaged Stunt Copter and Missile don't really demonstrate the full capability of emulator at the moment, and there are still many things we need to fix before the general release. It's just that we don't want to make release of unfinished project to give people the wrong impression what we will aim as the final end result, but instead finalize and polish it as much as possible :-/ I think however after we get resource file write support working reliably, we will most likely be ready for a third simple demo application ;-) 

Share this post


Link to post
Share on other sites
On 7/26/2019 at 2:55 AM, olePigeon said:

I wouldn't be surprised if the people over at GOG are watching this thread and monitoring the project.

That would be a fun thought :-) I would love for everybody to have a chance to experience these fun games on modern computers - and something like "GOG" would definitely help with all the copyright things etc...

 

And speaking of games, check out this new video below ;-)

 

 

Does anybody know who owns the copyright for Apache Strike currently? I wonder if they might be open for allowing making a M.A.C.E. bundle of the game...

 

There's a huuuuuuuge amount of news since last update, but we just haven't had time to write about them in the blog...I think most important thing to mention briefly is that Dark Castle, Beyond Dark Castle, Apache Strike and PT-109 are currently 99.9% functional under M.A.C.E., mostly thanks to Pukka's recent integration of the "M68K Emulator Testsuite" by Gwenole Beauchesne, which has already helped to identify and fix most of the remaining CPU bugs :-) 

Share this post


Link to post
Share on other sites
5 hours ago, Toni_ said:

Does anybody know who owns the copyright for Apache Strike currently? I wonder if they might be open for allowing making a M.A.C.E. bundle of the game...

Maybe, but they're large enough that it's likely hard to get through to them. The best resource I can find from searching the U.S. Copyright Office involves a bulk reassignment to a very large video game company in 1999.

 

They have titles on GOG but not this one, in any form.

Share this post


Link to post
Share on other sites

Okay, I wrote yesterday the blog post about last month's improvements, AND we have now two more test games for trying out which I promised! :-) 

 

The newest blog post: https://mace.software/2019/08/20/a-lot-of-fixes-improvements-and-new-test-applications/

 

The two new test apps are ZeroGravity and Blob Mgr Demo, available at: https://mace.software/files/

 

Please let us know if you have any major issues with them. There is one known problem with ZeroGravity highscore (or 'loscore') saving, in which 10.13 sandbox security prevents saving score at the moment when launched from Finder, but it should work fine with old enough Mac OS X - however, if you launch it from command line, the score saving should work on newer systems too. We have a solution for that problem in development, which however is not yet finished.

 

Another improvements include support for the "touch to click" issue which was reported here on 68kmla, let us know if the clicking works now ok for you guys :-) Both previous test app bundles Stunt Copter and Missile have been updated with newest M.A.C.E. runtime too.

On 8/10/2019 at 3:42 AM, nglevin said:

Maybe, but they're large enough that it's likely hard to get through to them. The best resource I can find from searching the U.S. Copyright Office involves a bulk reassignment to a very large video game company in 1999.

 

They have titles on GOG but not this one, in any form.

Thank you for the information and effort, sadly I could not get the link to work. But I guess it is easier to focus at this point on the development, and see which games are easier to get the permission to distribute for. There are a couple cool favorite games we have been thinking about (Continuum, Fool's Errand, etc), but we still have some minor things to improve in the toolbox API before we get to the 100% completion on them (currently only known task/issue is to finish Standard File Package).

Edited by Toni_

Share this post


Link to post
Share on other sites

@Toni_  You know what'd be super duper useful to get working?  AppleShare Server or FTPd.  Some sort of networking app so we can exchange files between our vintage Macs and our modern ones.  With Apple removing ftp from Mojave, it's become a pain in the butt. :(

Share this post


Link to post
Share on other sites
3 hours ago, olePigeon said:

@Toni_  You know what'd be super duper useful to get working?  AppleShare Server or FTPd.  Some sort of networking app so we can exchange files between our vintage Macs and our modern ones.  With Apple removing ftp from Mojave, it's become a pain in the butt. :(

Amen to that.

Share this post


Link to post
Share on other sites
17 hours ago, Toni_ said:

Thank you for the information and effort, sadly I could not get the link to work.

Pardon me, the USA Copyright Office has an interesting concept of sessions and limited resources.

 

If you're willing to brave their system, search for document number V3435D122, there are three entries with the title "Apache Strike". From the link in "Title appears in document #[...]", you'll see where the ownership was transferred to.

 

Same entity that technically owns all remaining copyrights to the works of Infocom. It shouldn't be surprising, given that.

 

 

The games look great, by the way! Running all four on virtualized Mojave.

Share this post


Link to post
Share on other sites

Sorry I could not reply earlier, we have been very busy with work and programming in the spare time :-) 

On 8/20/2019 at 9:56 PM, olePigeon said:

@Toni_  You know what'd be super duper useful to get working?  AppleShare Server or FTPd.  Some sort of networking app so we can exchange files between our vintage Macs and our modern ones.  With Apple removing ftp from Mojave, it's become a pain in the butt. :(

Well, someday if we ever get to the point at which we implement MacTCP support and AppleTalk stack, theoretically AppleShare IP server could be run in the emulator.

 

At least on Mac OS X native AppleTalk cannot really be used without special network driver, as the BSD sockets API on the system appears to be limited to only IP-based protocols of the OSI Network layer, although on some systems may allow implementing custom protocols on that layer. One solution might be the custom driver, such as I think Basilisk II was using at least on Windows.

 

A FTP server would be rather unpractical, as all Macintosh files would need to be compressed and/or wrapped as BinHex/MacBinary to preserve resource forks and metadata, while AppleShare would allow files to be transferred directly without needing conversion on both ends.

 

Actually one interesting option might be to explore possibility of using serial connection, and some BBS software which supports Macintosh files, such as FirstClass. Maybe the native FirstClass server could be run on the real Mac, which FirstClass client could connect to from the emulated environment on through a USB-to-serial converter or something. This was an idea suggested by Pukka a few weeks ago, which I almost forgot about. This would also have the benefit of not requiring file conversion on either end.

 

(Ps. I myself personally do file transfers at the moment using USB sticks formatted with HFS+, from a PowerBook G3 running Mac OS 9 to the Mac OS X -  Although I hope Apple doesn't retire HFS+ too soon now that APFS is out...)

On 8/21/2019 at 3:41 AM, nglevin said:

Pardon me, the USA Copyright Office has an interesting concept of sessions and limited resources.

 

If you're willing to brave their system, search for document number V3435D122, there are three entries with the title "Apache Strike". From the link in "Title appears in document #[...]", you'll see where the ownership was transferred to.

 

Same entity that technically owns all remaining copyrights to the works of Infocom. It shouldn't be surprising, given that.

 

 

The games look great, by the way! Running all four on virtualized Mojave.

Thank you, I tried to shuffle the website for a moment but seems the search is rather obscure, or maybe my browsing skills are just limited :-) In either way, it's probably better that I focus on the programming and worry about that particular game later :-D 

 

I'm glad to hear the games work for you, we actually today updated the test bundles to new versions which have quite promising performance improvements, which I wrote a bit details about on the blog a few moments ago.

 

Thanks for the support, we'll get back to the coding and *hopefully* we will get more test applications for the next update.

Share this post


Link to post
Share on other sites

Hi again,

 

We're still in middle of preparing next update, but we just had yesterday a rather interesting thing happen by accident, which I wanted to share here because it is rather unusual: While trying out a couple potential test applications with the emulator, I ran into an application which was infected by nVIR A type virus ( https://en.wikipedia.org/wiki/NVIR ). What makes this interesting, is that it apparently was able to infect the System file of that application's bundle, as we now have near-complete resource write support:

 

1942701599_2019-09-07nvir.png.334120cfee63cd9df54a1a96eb3d31d5.png 

 

This is partial output of the "System" file's resource map debug dump, and the 'nVIR' and 'INIT' resources were actually written into the System file by the virus in infected application - and the system resource map seemed to be mostly still functional! I only found this out because a bug in resource writing corrupted Geneva font, causing the infected application to crash :-) A kind of controversial achievement, having good enough compatibility for even viruses to work in the toolbox emulation...

 

Luckily the infection was isolated to only a couple individual test applications, and I was able to identify the original source of infection on "MAC OS 6 App Collection.dsk" image at: http://www.toughdev.com/content/2016/12/system-6-0-8-on-a-vintage-macintosh-se-with-4mb-ram/

Please be extra careful if you download the disk image from page, I have written comment to the author to let him know about the infection.

 

One of the positive sides of the current per-application bundling of files as isolated file systems, is that the infection never was able to break out of the application bundle. I've also scrubbed through all disk images to make sure there will not be any risk of infection at later time (and run Disinfectant on the source Macs regularly). These viruses are ancient, but can awake up at any time it seems...

Share this post


Link to post
Share on other sites

That is inadvertently really cool. :D

 

There's a YouTube video of some of the more creative viruses and trojans on DOS.  I don't recall any particularly "fun" ones for the Mac.  They're amusing to watch.

Share this post


Link to post
Share on other sites

Responding here rather than the eBay Finds thread as it seem a better place for it.

 

49 minutes ago, nglevin said:

 

Perhaps MACE on Haiku will have you changing your tune, someday? :)

 

I was wrestling with how to express a sentiment around software making the platform. I'm sure someday, I'll have a bit more to write about Haiku as it (again, slowly) shapes itself.

I love the idea of MACE.  I think it could bring a lot of renewed interest in all things vintage Mac if people can run Mac applications on a modern computer.  (Somehow running things through an emulator on a web page makes it non-interesting to me personally.)  But running MACE on my primary machine is much more interesting to me than running MACE on Haiku, with which I have no experience.  I'm also not sure why I'd want to add another layer to be able to run the vintage applications. 

Share this post


Link to post
Share on other sites

To be completely honest with you, it was a tongue-in-cheek means of plugging the project. Perhaps effective at that.

 

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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
On 8/9/2019 at 3:08 PM, Toni_ said:

Does anybody know who owns the copyright for Apache Strike currently? I wonder if they might be open for allowing making a M.A.C.E. bundle of the game...

 

There's a huuuuuuuge amount of news since last update, but we just haven't had time to write about them in the blog...I think most important thing to mention briefly is that Dark Castle, Beyond Dark Castle, Apache Strike and PT-109 are currently 99.9% functional under M.A.C.E., mostly thanks to Pukka's recent integration of the "M68K Emulator Testsuite" by Gwenole Beauchesne, which has already helped to identify and fix most of the remaining CPU bugs :-) 

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.

Share this post


Link to post
Share on other sites
On 9/8/2019 at 11:14 AM, olePigeon said:

There's a YouTube video of some of the more creative viruses and trojans on DOS. 

I have two memorable experiences with Windows viruses that were, for lack of a better word, interesting.

 

The first one was on Windows XP back in mid 2004, where I got stuck in this very strange situation where the computer told me I was connected (I even heard all the right sounds and stuff), but nothing would work. Then, in an interesting twist, selecting shutdown or restart likewise did nothing. I couldn't even log off!!

 

For that, I pulled the plug and installed Windows 2000, which at the time seemed to be much more reliable than XP (there was the Sasser worm, but a decent antivirus took care of that. It wasn't long after that SP2 for XP came out, and it became much more solid, but that's a topic for another post.

 

Another was on 98SE in 2005 or so, and I got this very strange thing going where it behave very erratically, and the windowing controls and widgets (buttons, checkboxes, etc.) began reverting to their Windows 3.x equivalents. Needless to say, that install was completely trashed not long after, and it became unbootable.

 

I've never had the misfortune of getting any Mac viruses, but I hadn't really experienced the internet until shortly before it was rendered irrelevant by Mac OS X, so most of those old viruses weren't really in the wild anymore.

 

c

Share this post


Link to post
Share on other sites

Hi again!

 

On 9/10/2019 at 1:26 AM, nglevin said:

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...)

9 hours ago, Builder1 said:

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...

8 hours ago, LaPorta said:

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...)

Edited by Toni_

Share this post


Link to post
Share on other sites
12 hours ago, Toni_ said:

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,

I run 10.5.8 for HFS-write compatibility. Any chance you could compile with 10.5.x support too?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×