jjuran

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.

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

A Mac 512K of sorts was already built before the Macintosh introduction at the 1984 shareholders meeting — the demo wouldn't run in 128K of RAM.

Funny you should bring up MacRelix — the very first front end for Advanced Mac Substitute was built in it.

The latter. There's only one heavy drinker in Dark Castle, and it's not the hero. ;-)

It's not you; it's me. My implementation of LoadScrap() (which is called at startup) is calling FSOpen(), and it turns out the glue code for that tries OpenDF() before falling back to PBOpen(). TIL.

The call is coming from within the OS!

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.

[1] See https://www.macrelics.com/legacynth/

A Genesis has to start somewhere. ;-)

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.

I made my own web-based Mac simulator some time ago: https://www.metamage.com/apps/maxim/

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.

My earliest recollection of what motivated me is a desire to resurrect The Fool's Errand.

The irony is not lost on me. :-)

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.

Advanced Mac Substitute stores documents and preference files in sandboxed host directories.

For example, check out the MacPaint demo:

https://www.v68k.org/advanced-mac-substitute/demo/MacPaint-A...

If you were to double-click the Hello document in macOS' Finder, it would launch and open in MacPaint.app.

Correction: 68K Mac OS calls were A-line traps — in other words, they had opcodes of the form `$Axxx`. To the processor, they're unimplemented instructions that each take an exception through the same vector. The exception handler is the Mac OS trap dispatcher.

`TRAP` is a different instruction, with opcodes `$4E4x`. Each one gets its own exception vector.

It's not just trap calls, though — sometimes applications write directly to the sound buffer or use hardware page flipping.

Any interaction with the Welcome application terminates it. Try setting AMS_APPNAME=Tic-tac-toe in the environment, or AMS_APPNAME="Nyanochrome Cat".

Ah, yes, the two front ends I haven't touched in years. This should be fun. :-)

You clipped the part that said "Starting VNC server on 127.0.0.1:5900". Did you try connecting a VNC client?

The FSSpec calls added in System 7 are mostly new interfaces to existing File Manager functionality. There's an actual high-level `OpenDF()` call, which is like `FSOpen()` except that it won't try to open a driver when the name begins with `.`.

Some applications call `OpenDF()` without checking its availability, but fall back to `FSOpen()` or equivalent if `OpenDF()` returns `paramErr`, which is what the parent is witnessing. See `68k/modules/ams-fs/Files.cc` in the `metamage_1` repo.

If the error message is confusing people, maybe it's time to implement `OpenDF()` for real.

Implementing fork() without address translation is possible — it's just expensive.

In MacRelix (a POSIX-like environment for classic Mac OS), when a process calls fork(), the system allocates backup memory regions for it and its child. Whenever one of them is switched in after its counterpart was the last of the two to run, the old one's regions are backed up and the new one's regions restored.

Rhapsody DR2 is not a solution for classic Mac OS on x86. Lunduke writes:

"Unfortunately [the Blue Box] was only available on PowerPC versions of Rhapsody"

Another option is Advanced Mac Substitute. It doesn't run everything, but what it does run it runs really well. One of my goals is that you can use a 68K Mac application (e.g. MacPaint) as part of your personal computing workflow, if you wish.

https://www.v68k.org/ams/

You're in luck: <https://github.com/ravynsoft/ravynos/discussions/529>

ravynOS is moving to Darwin.

If you're okay with a System 6 appearance, I've already made one <https://github.com/jjuran/metamage_1/tree/master/68k/modules...>, for Advanced Mac Substitute <https://www.v68k.org/ams/>.

I do appreciate Alan Kay's thinking, in particular his talk "Normal Considered Harmful" <https://www.youtube.com/watch?v=FvmTSpJU-Xc>

My own high-level language, Varyx, has somewhat LISPy internals and is very dynamic — for example, you can annotate a variable with a type that's determined only at run time — and has an eval() that insulates the caller from the payload and vice versa. You can sequester mutable state within a closure, which can't be cracked open. Using an experimental Varyx build with some bindings for Apple's Core Graphics API, I wrote a script that rendered an arrow cursor (which I donated to the ravynOS project).

Perhaps we should talk. :-)

I hate to disappoint you, but the canonical way to clear a 68K address register is `SUBA.L An,An`. My asm-coded replacement for the Metrowerks code resource runtime uses it:

<https://github.com/jjuran/metamage_1/blob/master/mac/toolcha...>

The vulnerability did require JavaScript to trigger.

Can you back this up with a citation?

It's mostly checking Gestalt() and scanning the unit table for specific graphics drivers, occasionally peeking in low memory. (My own v68k core identifies itself through undefined CCR bits in the CHK instruction.)

Have a look at tools/mac/system-info/system-info.cc and mac/libs/mac-sys-utils/mac_sys/has/virtualization.hh in the metamage_1 repository.

At the very least, MacTCP supports System 6 and the 68000; Open Transport is incompatible with both.

(I seem to recall there's a version of OT you can use with System 7 Pro, a.k.a. System 7.1.1.)

Yes, MacTCP support is absolutely doable. It's a question of free time and priorities.

MacRelix has an `upgrade` command that will check for and fetch a new version of itself.

The installer is merely a stripped-down, single-file build of MacRelix with just enough tools to run the installer script, including `upgrade`.

Yes and no. The MacRelix toolchain does, in a very trivial sense, generate Metrowerks-compatible object files, because mwcc is ultimately a wrapper around the Metrowerks-proprietary MWC68K and MWCPPC tools that run in MPW.

I reverse-engineered enough of the .o header format so that MacRelix's ar and ld could retrieve architecture and runtime information from a static library instead of making the caller provide it via a switch.

Separately, I've been writing post-linkers that patch or rewrite the Metrowerks-provided startup code in 68K code resources. The next step on this path might be writing my own compatible linker.

The Perl interpreter is v5.6.1, though strictly speaking it's miniperl, not perl — there's no support for XS (i.e. native-compiled) modules.

Unlike MacPerl, it supports system(), exec(), and backticks in the Unixy way you'd expect. In fact, the program that packages up a MacRelix archive is a Perl script running in MacRelix.

I guess we'll just have to disagree about the Tolkien references. :-)

Indeed, I use .mbin for MacBinary, as the more conventional .bin is overloaded with other meanings.

I also use .mbim for MacBinary+, which encodes a directory tree instead of a single file.

Author of MacRelix (and system-info) here.

I'm delighted that you've noticed and appreciate this. :-)