In my 68K Mac emulator running on modern (or even decade-old) hardware, performance in the traditional sense is less of a concern, but other issues arise. The big ones include CPU-burning loops that wait for a length of time or for an interrupt-decremented counter to reach zero, as well as invalid memory accesses (which I've made crash — no NULL deref for you).
> We considered creating a plugin that fixed all these things, it would have been hard to maintain, in the end we travelled around to the people who made these apps and talked them through their problems
Since talking to developers is no longer an option, I actually do write "Such-and-such Tune-up" extensions that patch applications dynamically to make them run better (or at all) in Advanced Mac Substitute, or even Mac OS itself.
Yeah those low core global system variables (including a readable/writeable 0) at fixed addresses were very much a thing, they were a bad design decision made for the original Macs with almost no memory, and made running more than one app (switcher/multifinder) a difficult transition back in the day. Someone wasn't planning ahead
I also worked on the original A/UX port for the Mac II, some hardware (like the IWM) required tiny buzzy loops, we ran into one bug where using the floppy caused ADB to freeze, but only on the release machines, not the prototypes all our engineers had, turned out there was hardware that made access to the VIA faster by pulling the clock in for 1 cycle, if you sat in a loop reading the timer in the via to measure a sector time for the IWM in too tight a loop it upped the output clock from the VIA to the ADB chip and over clocked it ....
I knew of Executor, but never saw it in action. Winning back performance lost to emulation was critical when competing with contemporary real hardware, and kudos to ctm and ARDI for their clever solution.
Decades later, though, emulation performance is mostly a non-issue (and even improves automatically with faster hosts). What matters now is portability (which requires ongoing maintenance) and renovation of programs designed around having the CPU to themselves (via dynamically applied patches).
You want to talk trap patches? Your Mac's INITs have minimal trap patches, touch the Toolbox in boring places like SysBeep() and GetNextEvent(). The Developator's Mac has big, tricky INITs with trap patches that hook into half of the Device Manager.[1] The Developator is in touch with the metal, starts like a warm boot off the ROM reset vector, stops on an NMI.
Oh wow. Once I saw the smiling machine and empty progress bar, I went straight to NoScript and enabled your domain without a moment's hesitation — highly unusual for me. It's charming! I laughed out loud when I saw your screen-saver.
It's familiar and alien at the same time, like I'm seeing an alternate universe.
It was a way to become more familiar with CSS and JS (and indulge my classic Mac OS nostalgia), but my biggest takeaway was that the web wasn't a foundation I wanted to build complex structures on, and indirectly helped spur me to create Advanced Mac Substitute.
Sharing our Mac themes simulators? Here is my entrant: https://hcsimulator.com/ Full compatibility with HyperCard stacks, including their resource forks if they are in StuffIt archives.
Hey, I’ve been thinking about building a genesis emulator to play Revenge of Shinobi. Never thought about trying to replace the genesis rom.. let’s get the game working first :)
Advanced Mac Substitute uses a factored approach. 68K emulation happens in the back end, which is a collection of processes connected by Unix-domain sockets, portable to basically any POSIX system.
The front end deals with displaying graphics and forwarding user input to the back end. Working front ends include SDL2 (by a contributor), X11, Linux fbdev, VNC, and five different macOS APIs (Cocoa/OpenGL, CGL, AGL, Quartz, and QuickDraw).
The front and back ends communicate using FIFOs and shared memory. I'm aware that certain platforms will require refactoring all of this to run in a single process. If Emscripten is one of them, then it won't be as simple as you suggest.
In any case, if I were the one doing the port, I might write a bare-bones front end just for this purpose, possibly using the fbdev one as a starting point.
> We considered creating a plugin that fixed all these things, it would have been hard to maintain, in the end we travelled around to the people who made these apps and talked them through their problems
Since talking to developers is no longer an option, I actually do write "Such-and-such Tune-up" extensions that patch applications dynamically to make them run better (or at all) in Advanced Mac Substitute, or even Mac OS itself.