MACE: an New Classic Mac emulator project

About Mini vMac and all other 68k emulators, including SoftMac, Executor, and MESS.

Moderators: Cat_7, Ronald P. Regensburg

User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

MACE: an New Classic Mac emulator project

Post by Pukka »

Hey,

I have been working with my friend on a ROM-less Classic Mac emulator. At the moment the project consists of System 6 software implementation, Motorola 68000 emulator and Disassembler, Debugger and Profiler tools. The plan is to implement System 7 + Color QuickDraw, 68040 instruction set, more hardware emulation, etc. in future.

At the moment this project is still in early/mid development state. The emulator is able to run various black&white Mac games and programs such as Dark Castle, MacPaint and Arkanoid. Read more details about the development process at https://mace.software (yes, apparently another project with this name :) ).

There is a prototype application running Stunt Copter programmed by Duane Blehm. For now the system requirements are OS X 10.7+. We are also working on support for different platforms and older Mac OS versions.

We will release more games and applications when getting legal details and software/hardware support completed.
Last edited by Cat_7 on Fri Dec 06, 2019 7:21 am, edited 1 time in total.
Reason: edited topic name and made sticky
User avatar
ClockWise
Site Admin
Posts: 4397
Joined: Mon May 20, 2002 4:37 am
Location: Uiwang

Re: New Classic Mac emulator project

Post by ClockWise »

Fantastic, thanks for sharing that.

I'm on Windows, but I hope someone here will try out the prototype you have made available.
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: New Classic Mac emulator project

Post by adespoton »

Should have gone with MINE as the project name (MINE Is Not an Emulator) since it's essentially doing WINE for the System 6 toolbox. Of course, being for Mac software, there's emulation that's needed as well as the toolbox handling layer, but hey....

I remember MACE from the first time it started up; today's environment seems a lot better to be attempting this; I wish you guys luck, and if you need any help with testing/debugging/finding old documentation, let us know :)
User avatar
ClockWise
Site Admin
Posts: 4397
Joined: Mon May 20, 2002 4:37 am
Location: Uiwang

Re: New Classic Mac emulator project

Post by ClockWise »

I trust, Pukka, that you also realize that Executor is open source?

Perhaps it could be of use:

https://github.com/ctm/executor
https://github.com/ctm/syn68k
User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

Re: New Classic Mac emulator project

Post by Pukka »

Thanks, yes I know Executor on Windows, however i'm not familiar with its current state. At least in earlier it was known to have accuracy and compatibility problems.

This project exists because we wanted to create something which would be the proper Mac emulator (or Not an Emulator :) ) in our opinion as a team. Additionally there are lot of aspects such as hardware emulation, OS programming, optimization etc. which keep the project motivating.
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: New Classic Mac emulator project

Post by adespoton »

The current state of Executor is... languishing. But it's been open sourced, and ported to OS X 10.6, compileable under Xcode: 3.2.3. And Cliff's still around, if you wanted to ask him questions too :)

Syn68k is his implementation of the 68LC040, which I believe could be useful as most of the other emulator cores are for 68000, 60020 or 68040. However, it's 32-bit, so some work would be needed to compile it in 64-bit. But as a reference architecture, it may be of use to you.
Jorpho
Master Emulator
Posts: 380
Joined: Fri Sep 17, 2004 4:22 am

Re: New Classic Mac emulator project

Post by Jorpho »

As Shapeshifter begat Sheepshaver, I've sometimes mused that a further play on "Executor" might be appropriate. Eggsycutar, maybe.
User avatar
Madd the Sane
Student Driver
Posts: 14
Joined: Fri Aug 31, 2012 6:27 pm
Location: Idaho

Re: New Classic Mac emulator project

Post by Madd the Sane »

My idea for a name for Executor (on the Mac, at least) would have been NeoClassic.

That said, Autc04's fork is developing at quite a pace. He's also working on PowerPC emulation and support.

That said, his syn68k fork also compiles for 64-bit architectures.
Get out of my mind, idea! I already have an idea in there!
User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

Re: New Classic Mac emulator project

Post by Pukka »

Hey,

Small update to this project. During the past months we have got several new programs working on the emulator, such as HyperCard, PhotoShop, Think Pascal and various games. At one point the emulator was also infected by nVir virus which is in its own way a good compatibility test :)
This week the emulator was able to run an old version of SoftPC successfully first time.

We got permission to share more games bundled with the emulation software. They are available on the project page for testing.

In software support there has been lot of updates to the file manager, quickdraw, list manager, resource manager and standard get/put file etc. + various bug fixes.

The current hardware emulation supports now full 68000 - 68040 instruction set excluding some misc supervisor and all FPU instructions.

At the moment we have Mac OS X 10.6 - 10.12 and Haiku OS compatibility. Additionally the Raspberry PI version was successfully compiled but stuck in some linker issues. We are planning to support more platforms in future.

More details and stories about the progress in the development diary at https://mace.software/news/
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: New Classic Mac emulator project

Post by adespoton »

Mods, can we have a sticky at the top of with a MACE header on it? The other, ancient MACE project seems dead in the water now (no updates in 4 years) but this one's actually functional and alive and can actually run some software :)
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: New Classic Mac emulator project

Post by adespoton »

In other news, out of curiosity, I decided to grab a copy of GunShy, and replace the data and resource forks with those from Cairo Shootout, just to see what would happen. Here's the results:

Code: Select all

GunShy\ 1.3.app/Contents/MacOS/GunShy\ 1.3 
InsetRect: 00420092[0,0,342,512] + DH:-3, DV:-3

InsetRect: 00420092[0,0,342,512] + DH:-3, DV:-3

InsetRect: 000009fa[0,0,342,512] + DH:-3, DV:-3

Illegal instruction: 4
I guess Cairo Shootout was a bit much. Next up when I have time: Daleks :)
User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

Re: New Classic Mac emulator project

Post by Pukka »

Tested your method and it seems both Cairo Shootout and Daleks works when replacing GunShy and %GunShy files inside the app bundle. I guess the file was not in correct format in this case.

Currently each game wrapped inside bundle have some configuration values such as processor type and some sound and input emulation related parameters which are set in compile time.
The simple games have almost identical settings, but more complex games such as Dark Castle could run but have issues with sound and input.

We are working on a generic version of the emulator which would allow selecting application to run.
At this point it still requires some more work to fix the remaining issues.
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: New Classic Mac emulator project

Post by adespoton »

Thanks; good to know; I specifically chose Cairo Shootout because I figured it would have a similar profile to GunShy, being compiled on the same compiler for the same target Mac at around the same time.

I'm curious why my files didn't work though. I created them by creating %Cairo Shootout from Cairo Shootout/..namedfork/rsrc and created the Cairo Shootout file by stripping the resource fork from the same file. Since it's a 0-byte data file though, I probably could have kept the original GunShy one.

What method do you guys use to split into apple double?

Also, is there an easy means to set the memory reservation for the application?

I'd like to try encapsulating some trickier games like Apache Strike that use extra data and resource files and a different type of polling on the mouse, but I figure it would have the same issues as other Silicon Beach Software titles like Dark Castle.
User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

Re: New Classic Mac emulator project

Post by Pukka »

It might be that the resource file is missing the apple double file header. It is described in this document:
https://nulib.com/library/AppleSingle_AppleDouble.pdf

I haven't participated yet to the file conversion, but Toni was saying he has been using plain hex editor for this purpose. Initial bytes in a working copy of Cairo Shootout resource file should look like this (there might be more than the header in here):

00051607 00020000 00000000 00000000 00000000 00000000 00040000 000A0000 00920000 00040000 00080000 00960000 00100000 00090000 00A60000 00200000 00020000 02000000 DEAE0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

The memory allocation is fixed 4 megabytes which is all available excluding the low memory area.

Apache strike should work fine with the Stunt Copter build, which has the relative mouse mode switch active.
Good luck :) and in case you get games or applications working, please keep them private at this point.
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: New Classic Mac emulator project

Post by adespoton »

Thanks, and will do :)

Another question to keep this project at the top of the list ;)

Any chance of compiling these to WASM? It seems to me like for older software, this would be a perfect target, as the layout and duplication to local userland is a fairly good match for what a Wasm binary would do, and then you'd have an extra target: any Wasm-capable browser. Would go well with archive.org too, and could enable MACE to replace js.PCE/macplus in many many situations for a more light-weight and responsive (and more shareable) experience.
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: MACE: an New Classic Mac emulator project

Post by Cat_7 »

Another question to keep this project at the top of the list
Something like this?

Best,
Cat_7
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: MACE: an New Classic Mac emulator project

Post by adespoton »

Looks good to me :)
User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

Re: MACE: an New Classic Mac emulator project

Post by Pukka »

Thanks for making this sticky :)

I remember we had a conversation about emscripten support over year ago and that point the conclusion was that there were some difficulties with thread based interrupts.

Have to ask Toni to write more about this topic as I have been mostly working on the CPU and tool side.
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: MACE: an New Classic Mac emulator project

Post by adespoton »

One more question: what would happen if you targeted the Finder application? Do you have a current profile that would line up with its requirements?

Obviously this isn't something that could be distributed, but it'd be interesting to be able to run a launcher and a selection of other software.

My next questions of course would be around desk accessories and loading INITs, including MACSBug :)

Also: have you tried ResEdit yet?
User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

Re: MACE: an New Classic Mac emulator project

Post by Pukka »

I have been also thinking about running the Finder randomly, but at this point the emulator is missing too much internal System support to be able to work properly yet.

The desk accessories are working fine in experimental level, however it seems for me they have to to be included inside the system resource file at this point.
https://mace.software/2019/04/08/experi ... v-support/

We haven't tested MacsBug yet. Currently our own debugger is attempting to emulate MacsBug functionality in the Xcode command line or by telnet connection. The public builds have it disabled. Briefly explained in here
https://mace.software/2019/02/17/remote ... ing-et-al/

ResEdit is working quite well currently, there was article about it in summer but after that there have been more improvements for compatibility:
https://mace.software/2019/07/24/update ... mpressors/

Did you have any success at getting applications or games running so far?
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: MACE: an New Classic Mac emulator project

Post by adespoton »

Haven't had a chance to get Apache Strike going yet, but basic ones like Cairo Shootout and Social Climber are a go :)
User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

Re: MACE: an New Classic Mac emulator project

Post by Pukka »

New answer to the question about running the Finder, yes it is now possible :)
Toni (the software emulation programmer) spent few late nights with this topic and got it running quite well even if there are still few things to be fixed.

Here is the detailed description about the progress
https://mace.software/2019/12/12/finding-the-finder/
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: MACE: an New Classic Mac emulator project

Post by adespoton »

Well done! Since there's no feedback form on the blog page, I'll add some stuff here:
Finder and system icons appear as documents, but that might be because those don’t yet exist in the System file. Not sure about that yet.
Those icons are stored in the System file, so you'll need to create your own replacements. Shouldn't be too difficult. There's a few other places in the Finder where it calls for System resources instead of Finder resources -- hence why I thought this would be a good app for testing robustness, as it assumes all sorts of stuff is available from the System/Toolbox instead of replicating it in Finder resources. It always amazed me that you could swap Finder applications in different System versions because of some of this stuff -- but Apple seems to have done a decent job in the early days of tracking all its resource IDs to avoid conflicts.
For some reason, doing “Get Info” on our Hard Drive turns our custom icon returned by the .NativeFS DRVR to a generic floppy icon.
This is part of what I'm talking about: from my days of skinning Finder 6.x, I can tell you that the Get Info doesn't use the same DRVR resource -- I believe this one comes from the toolbox, and you have to inject a resource with the correct ID into the System file to override the one provided by ROM. If you ResEdit a System file, you'll see the two sets of identical icons -- this is why there are two sets: they needed to use the two sets of IDs for compatibility purposes between System and Finder versions.
It’s interesting how Finder considers at the moment our custom Hard Drive as “AppleTalk” device, but that might be because we’re hooking into the ExtFS file manager hooks which *I think* were used by AppleTalk in the real System 6.x. Just another thing which needs more investigation.
I *think* you're correct here, but my memory on this is fuzzy. Looking at an earlier System when HFS / HDSC20 was loaded as an extension would probably help here; this was presented as a different device than the external AppleTalk device, and was patched on via the System before the Plus ROM incorporated it (with the same ID) into the boot ROM.
The Font Manager data caches do not clear completely, leaving some dangling handles/pointers to the old application zone
I seem to recall Apple had a separate routine for doing this, due to how Fonts, Desk Accessories and FKeys were loaded -- I think it was a cache manager routine running to actively manage this.
Getting back to Finder (or any shell) is not yet possible, as ExitToShell is still hard-coded to terminate the entire emulator, instead of launching LMGetFinderName() application. Getting this to work would also encourage researching the Emscripten and Process Manager compatibility, as all of those features share a common need for a better in-emulator process management.
Might I suggest changing ETS to call a routine at a specific place in memory instead of directly terminating the emulator? Then you can by default set the address to the terminate routine, but overwrite it with another memory location as needed. I used to do this with the programmer's key all the time; I usually used address FA700 to hold a routine that would call where I wanted to go; this allowed me to subvert Quit to open a DA (which was actually a mini launcher itself), which allowed for some interesting debugging opportunities.
The _Eject trap is not yet implemented (and in any case you will not be able to eject the NativeFS drives).
What implications does this have for attempting to trying to run installers that expect to be able to eject images and wait for the next disk to be inserted? I know we haven't got that far yet, but this will need to be explored in the future for disk image handling. Apple eventually started treating a folder structure as a valid replacement for disks in its installer, but early versions didn't do this, and neither did some third party installers.

Something else to remember: Dark Castle replaces the Finder with the Dark Castle application, so there may be some useful functionality added to DC on long tail errors from adding this Finder support.

Once again, great job guys!

[edit] One more thing I forgot to ask about ;) Did you try printing from the Finder? That will expose a whole new set of calls you'll likely need to handle or mask :) Personally, I'd love to see MACE support of a virtual Color LaserWriter that just writes a file to the host (as postscript, EPS or PDF, whatever's easier). Supporting the PrintToPDF INIT would also be interesting, but unneeded if your roll Postscript print capture directly into your System/Toolbox file.
User avatar
Pukka
Student Driver
Posts: 22
Joined: Mon Feb 25, 2019 9:15 pm
Location: Helsinki / Finland

Re: MACE: an New Classic Mac emulator project

Post by Pukka »

Thanks for sharing your information and experience. I'll leave more detailed commenting to Toni as he has been mostly the software programmer. I'm more dedicated to implementing the hardware support.
Printing and support for disks should be implemented all at some point.
User avatar
Toni_
Space Cadet
Posts: 3
Joined: Fri Sep 06, 2019 7:36 pm

Re: MACE: an New Classic Mac emulator project

Post by Toni_ »

Hi,

Pukka asked me to post some replies to this thread, so here's some quick answers. Sorry for the delay, I have been super busy with everything possible recently plus Christmas stuff...
adespoton wrote:Well done! Since there's no feedback form on the blog page, I'll add some stuff here:
Those icons are stored in the System file, so you'll need to create your own replacements. Shouldn't be too difficult. There's a few other places in the Finder where it calls for System resources instead of Finder resources -- hence why I thought this would be a good app for testing robustness, as it assumes all sorts of stuff is available from the System/Toolbox instead of replicating it in Finder resources. It always amazed me that you could swap Finder applications in different System versions because of some of this stuff -- but Apple seems to have done a decent job in the early days of tracking all its resource IDs to avoid conflicts.
Yes, actually after posting that I added some test icons to the System file and they worked pretty well. Actually, Apple uses complete icon bundles for FNDR (Finder) and ZSYS (System) in the System file, and including them not only added the icons to the "About Finder" window, but also added them to Desktop database and thus as correct icons in the Finder folder windows for Finder and System.
adespoton wrote: This is part of what I'm talking about: from my days of skinning Finder 6.x, I can tell you that the Get Info doesn't use the same DRVR resource -- I believe this one comes from the toolbox, and you have to inject a resource with the correct ID into the System file to override the one provided by ROM. If you ResEdit a System file, you'll see the two sets of identical icons -- this is why there are two sets: they needed to use the two sets of IDs for compatibility purposes between System and Finder versions.
Actually, I was referring to the oddity that using Get Info "changed" the icon for the remaining time of the Finder was in memory on that run. The original (correct) icon does not actually come from ROM, but on real Macs resides as part of the Apple_Driver partition, which contains the device driver for that particular disk. That is, for example, iomega ZIP disks show the ZIP disk image when mounted on a system without ZIP drivers. These icons exist only as a black & white 32x32 icon, and don't have color versions (which is why, for example ZIP disk and drives formatted with FWB Hard Disk Toolkit have only black & white icons). And they are accessed using Device Manager's PBControl trap on the volume's driver with csCode 0x16 and 0x17 (for logical and physical media icons). Of course, in System 7.x that icon can be naturally customized as any Finder icon with the "Custom icon" finder flag and -16455 icon family - and deleting that custom icon will again display the original icon originating from the driver. I think this behavior changed somewhat in Mac OS 8, when they introduced the new builtin color icons for disks, but we haven't *yet* looked that far into the future.

EDIT: I was very tired when writing that last night, so I forgot to mention, that the icon driver control codes also apply to also resource-based (RAM or ROM) DRVR device drivers, not only the SCSI drivers in the Apple_Driver APM partition. And as they only return a pointer to the icon data, there are multiple ways to store and provide it. For example, Cloud 7 driver mentioned below in next answer (and one RAM disk implementation I have seen) use embedded 32x32 icon & mask within the DRVR code, and others may simply return a dereferenced ICN# resource, which has the same format. But the black & white limitation still applies.
adespoton wrote: I *think* you're correct here, but my memory on this is fuzzy. Looking at an earlier System when HFS / HDSC20 was loaded as an extension would probably help here; this was presented as a different device than the external AppleTalk device, and was patched on via the System before the Plus ROM incorporated it (with the same ID) into the boot ROM.
It is true that the HD20 was quite a special case, I understand the extension was also necessary in later Systems to allow old ROMs to boot from the device, and load the HFS patches. But considering the usual use cases after HFS became standard, there's actually two use cases how the file system behaves - One is where the disk is a custom device, but contains a file system known by the System (such as RAM disks, or the really cool Cloud 7 at http://www.synack.net/~bbraun/68khttpdisk.html which exposes HTTP URL as HFS disk), and the other use case is when the file system is completely foreign (such as AFP, DOS disks, etc). I think Finder might not have had proper foreign file system support until 7.x, because in System 6.x you still had for example to use Apple File Exchange to read and write PC floppy disks. So that might be why Finder 6.x is oblivious to these ExtFS file systems. Additionally, around System 7.5, FSM became also an option, and I think Basilisk and/or Sheepshaver uses FSM interface to allow the Unix filesystem access in that emulator.
adespoton wrote: I seem to recall Apple had a separate routine for doing this, due to how Fonts, Desk Accessories and FKeys were loaded -- I think it was a cache manager routine running to actively manage this.
I haven't found any active code doing such polling, but there is a stack sniffer which monitors in VBL interrupts for potential stack-heap collisions. I think DAs (and drivers in general) were closed during Launch trap call by Segment Loader, Fonts were purged through resource manager calls done by InitApplZone. Additionally, System 7.x has a truckload of patches to these routines to allow the cooperative multitasking to work.
adespoton wrote: Might I suggest changing ETS to call a routine at a specific place in memory instead of directly terminating the emulator? Then you can by default set the address to the terminate routine, but overwrite it with another memory location as needed. I used to do this with the programmer's key all the time; I usually used address FA700 to hold a routine that would call where I wanted to go; this allowed me to subvert Quit to open a DA (which was actually a mini launcher itself), which allowed for some interesting debugging opportunities.
Not really limited to ExitToShell, but we have a number of cases where a certain trap will need to have different behavior depending on the configuration; for example, many quickdraw traps need to have two alternate implementations for color and the classic monochrome versions, ExitToShell needs to not only handle the case of handling launch of lowmem global FinderName process and bundle application's exit() call, but also have a third option for having Process Manager compatibility when we some day get to adding support for it. Right now we have all global emulator configurations as #define:s, but will need to refactor them to be dynamically configurable.
adespoton wrote: What implications does this have for attempting to trying to run installers that expect to be able to eject images and wait for the next disk to be inserted? I know we haven't got that far yet, but this will need to be explored in the future for disk image handling. Apple eventually started treating a folder structure as a valid replacement for disks in its installer, but early versions didn't do this, and neither did some third party installers.
Mostly the implications would be same as trying to eject the boot volume in later Mac OS versions :-) I know earlier Mac OS versions allowed the volume be in offline state, where it would be logically mounted but be physically ejected, which I think was used in the way you describe. However, we need to find some test cases to experiment this further (on both real Mac OS and in the emulator). But when it comes to disk-based installers, those might work out best when we some day add support for real HFS disks/images, but that is not a priority right now (we don't have yet any true HFS code, only the foreign filesystem code which abstracts the ExtFS interface like in AFP driver).
adespoton wrote: Something else to remember: Dark Castle replaces the Finder with the Dark Castle application, so there may be some useful functionality added to DC on long tail errors from adding this Finder support.
Actually, Dark castle is a prime example of how independent the shell application was from the other System software - it was one of the first applications we got to work one year ago and did not have any issues with it being used as Finder replacement :-) (ps. speaking of Dark Castle, check the link later in this post after the replies ;-) )
adespoton wrote: Once again, great job guys!
Thank you very much, it is nice to get positive feedback. Although we originally started this project for our own entertainment (to allow us play our favorite games), it is encouraging to know there is wider interest for it. This will definitely motivate us to work harder on it, to make it a tool that everybody can benefit from.
adespoton wrote: [edit] One more thing I forgot to ask about ;) Did you try printing from the Finder? That will expose a whole new set of calls you'll likely need to handle or mask :) Personally, I'd love to see MACE support of a virtual Color LaserWriter that just writes a file to the host (as postscript, EPS or PDF, whatever's easier). Supporting the PrintToPDF INIT would also be interesting, but unneeded if your roll Postscript print capture directly into your System/Toolbox file.
We actually had to already implement some dummy PrGlue (the Printing Manager dispatcher) traps for Adobe Photoshop to run, so we have partial hooks for the API, but no actual native-side implementation. We haven't discussed about this yet, but I was myself thinking about the possibility of using QuickDraw and Print Manager imaging/printing functions to be converter into PostScript code, which might be passed directly to the host system printing system, allowing the *theoretical* possibility of printing directly from Classic apps on modern systems. However, there is a ton of things to implement for this to work (first of all, the actual print manager APIs, the PostScript print driver emulator, and native hooks). I think at some point Pukka did mention something about ImageWriter emulation, which is also again another venture. However, this is definitely on the "To Do" list, but again not with very high priority.

---

Speaking of the Dark Castle earlier, because we have been so busy recently, and had very little new completed features, I wrote up a quick "Holiday update" with a couple early teasers (about future MacTCP support and experimenting on Windows version of emulator), and 20+ minutes of Dark Castle gameplay with the Christmas tree easter egg here:

Holiday update: https://mace.software/2019/12/26/happy-holidays/

Direct link to the short Dark Castle gameplay video: https://youtu.be/cN_imqya9-g

Merry Christmas and a Happy New Year!
Machines: Plus,II,LCII,C650,PM6100,PowerCenterPro210,iMacG3,G4Cube,iMacC2D 17",MacMiniC2D,PB280c,PBG3,MBP15"/2009,MBP13"/2015,MacPro/2010
M.A.C.E. project (new "Classic"): https://mace.software
Post Reply