In addition to Executor/DOS, a non-released version ran on the Sun 3 workstations (they too had 680x0 processors) and Executor/NEXTSTEP ran on NeXT machines, both the 680x0 based ones and the x86 powered PCs that could run NEXTSTEP.

Executor was the least compatible because it used no intellectual property from Apple. The ROMs and system software substitutes were all written in a clean room--no disassembly of the Apple ROMs or System file.

Although Executor ostensibly has a Linux port, it's probably hard to build (I haven't tried in a couple decades) in part because to squeeze the maximum performance out of a 80386 processor, the synthetic CPU relied on gcc-specific extensions.

I know a fair amount about Executor, because I wrote the initial version of it, although all the super impressive parts (e.g., the synthetic 68k emulator and the color subsystem) were written by better programmers than I am.

https://wiki.mamedev.org/index.php/Driver:Mac_68K

0. https://github.com/MiSTer-devel/MacPlus_MiSTer

vmware and virtualbox were backed by billion dollar corps

the 16 bit machines are much simpler than macs

game consoles had highly homogenous well documented hardware, and sold in much greater numbers (snes alone sold more than all macs from 1987 to 1995) so there's a larger community to draw devs and users from. writing a nes emulator is almost a weekend project now, it's so documented.

These seem to work:

https://archive.org/details/mac_rom_archive_-_as_of_8-19-201...

It would probably be easier to crack the software!

It's why the cursor stops moving sporadically when writing to a disk. The Mac has a 60 Hz interrupt timer that also tracks the cursor. It needs to be switched off when writing.

There's a story on Folklore.org by Andy Hertzfeld that mentions it in passing:

> Woz's disk technology required that the software feed it new data every 32 microseconds exactly. If we were even a single microsecond early or late, it would cause a glitch in the data and ruin it. In order to write the routines, I needed to know how fast the Macintosh executed each instruction. The manual gave the number of clocks for each instruction, but I wasn't sure how long it took to fetch from memory. So of course, I asked Burrell what the timings were, but I was surprised at his response.

> "I don't know. The Mac is synchronous, just like the Apple II, so each instruction has the same timing, every time you execute it, so you will be able to write disk routines that have exact timing. I don't know what it is, so we'll just measure it. Why don't you write your routine and we'll measure it with the logic analyzer."

-- https://www.folklore.org/Nybbles.html

This reminds me that all of the unusual Apple II disk stuff like spiral tracks and different-sized sectors and different nibbilization schemes were also, at least theoretically, possible on the Mac. I wonder if they were ever used for copy protection?

And there's also Clock Signal (CLK) "A latency-hating emulator of: the Acorn Electron and Archimedes, Amstrad CPC, Apple II/II+/IIe and early Macintosh, Atari 2600 and ST, ColecoVision, Enterprise 64/128, Commodore Vic-20 and Amiga, MSX 1/2, Oric 1/Atmos, early PC compatibles, Sega Master System, Sinclair ZX80/81 and ZX Spectrum." https://github.com/TomHarte/CLK

Inspired is a strong word. I didn't invent the concept of an accurate emulator, although I'm certainly a fan of his approach.

I go through phases with transparency off or on.

A color logo might be added with an overlay app – or you reminisce a black&white screen.

Links to the actual project are in the submitted post, so you can get an overview before then being directed to the project itself.

As always YMMV, indeed, YMWV, but I like seeing the announcement giving the context rather than a bare pointer to the project.