Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

v68k.org

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#61

Post by jjuran »

anthk wrote: post #45
jjuran wrote: post #25

Earlier quoted context omitted.

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 wi…

I had that error with Nethack 3.6.7 for m68k.

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!

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#63

Post by andai »

jjuran wrote: post #41
andai wrote: post #31

Very cool. If it's built on SDL2, it should be straightforward to make it run in the browser via Emscripten, right?

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, Quar…

As far as I can tell, the simplest solution would be to run the whole thing in a PC emulator. Simultaneously elegant, and deeply unsatisfying ;)

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#64

Post by philistine »

Lerc wrote: post #32
londons_explore wrote: post #17

I am amazed that 1980's software works on binary API compatibility rather than relying on API quirks like timing, memory alignment quirks, memory layout from specific allocator behaviour, etc. It only takes one unintentional reliance on an implementation detail to make an application not run on another OS implementation...

The Mac classic was about as pure as you could get from an architectural point of view. A 1 bit framebuffer and a CPU gets you most of what the machine can do. Most of the quirk abuse of 8-bit machines came from features that were provided with limitations. Sprites, but only 8 of them, colours but only 2 in any 8x8 cell. Multicolour but only in one of two palettes and you'll hate both. Almost all of the hacks were to…

They absolutely knew that they were making a platform that needed as much hardware independence as possible. The 512k was already in development before they even finished the original, and they had the experience of the Apple II, which for all of Wozniak’s legendary work, was a dead-end because it relied too heavily on hardware hacks.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#65

Post by hyperhello »

jjuran wrote: post #54
keepamovin wrote: post #52

This is super cool. I love that look. Something about classic black & white macos has a timeless "alternative timeline" L'Air de Panache aesthetic that to me says credibility and stability. Maybe it's the memory of the rows of Macintosh SE or Plus, those solid little upright beige bricks, in the computer room at my elementary school. I made a MacOS system 7 web desktop UI with real web browsing: https://win9-5.com/ma…

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…

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.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#66

Post by tmoertel »

bitwize wrote: post #40
whartung wrote: post #6

Earlier quoted context omitted.

I'm guessing they reimplemented the toolbox at the TRAP level (most MacOS calls at the time were accessed through the 68K TRAP instruction). So, rather than emulating hardware to run native ROMs, they "simply" reimplemented the ROMs. A friend of mine did this at another level. He basically rewrote the bulk of the toolbox as a C library so that the company, who had a Mac application, could port it to run on a PC, whil…

As I recall MacOS system calls were done through invalid instructions which would cause the CPU to "trap" (raise an interrupt). Giving rise to the question Mac extension writers asked of each other: "How many traps did you patch?"

The question serious patch trappers ask is whether you patched the traps used to patch traps to make sure that, when you patched traps, no other INIT could patch those traps after you to get in line before you when the traps were handled.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#67

Post by jjuran »

philistine wrote: post #64
Lerc wrote: post #32

Earlier quoted context omitted.

The Mac classic was about as pure as you could get from an architectural point of view. A 1 bit framebuffer and a CPU gets you most of what the machine can do. Most of the quirk abuse of 8-bit machines came from features that were provided with limitations. Sprites, but only 8 of them, colours but only 2 in any 8x8 cell. Multicolour but only in one of two palettes and you'll hate both. Almost all of the hacks were to…

They absolutely knew that they were making a platform that needed as much hardware independence as possible. The 512k was already in development before they even finished the original, and they had the experience of the Apple II, which for all of Wozniak’s legendary work, was a dead-end because it relied too heavily on hardware hacks.

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.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#68

Post by jjuran »

epenn wrote: post #51

Very cool! This reminds me of ARDI Executor [1] - a piece of (discontinued) commercial software first released in 1990 that took the same API-level reimplementation approach used here. And it did so jaw-droppingly fast considering that it was running on 90s PC hardware. As a little kid using it to play a few Mac games on my Windows PC, it was genuinely inspiring to me to see that this was possible at a time when I wa…

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

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#69

Post by keepamovin »

hyperhello wrote: post #65
jjuran wrote: post #54

Earlier quoted context omitted.

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…

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.

Beautiful little story about Ziggy

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#70

Post by eschaton »

drob518 wrote: post #57
eschaton wrote: post #28

Earlier quoted context omitted.

It was actually mostly written in assembly, but used Pascal calling conventions and structure layouts since that was expected to be the primary language for application developers. As it had been for Lisa, as it was for “large” applications on Apple II, and as was the case for much of the rest of the microcomputer and minicomputer industry and even the nascent workstation industry (eg Apollo). It was the Lisa system…

That brings back the memories. I had a copy of Lightspeed C for the Mac in college. In the workstation world, most companies used C and not Pascal. Apollo was different in that regard as their operating system, Domain, was unique to themselves, while most of the other workstation companies (Sun, HP, DEC, and IBM) were using Unix variants of some time (either BSD-based or System V-based in most cases). Apollo Domain w…

You’re talking about the workstation world circa 1985 and later, but prior to then the victory of C and UNIX wasn’t a sure thing. Apollo was the big player, but they weren’t the only ones.

In particular, many minicomputer vendors had some type of graphics and engineering workstation system built around their minicomputer product line, whether multi-user (where you’d have one minicomputer or even mainframe serving multiple bitmap or vector graphics terminals) or single-user (whether using a dedicated low-end minicomputer as a single-user system or using a new CPU design).

The Xerox Alto is what everyone cites as the start of the workstation trend, but it didn’t just beget the Xerox Star, the Lisp Machine, and the Lisa, it also led to the Three Rivers PERQ and CAD/CAE environments built on top of modular hardware from Data General and DEC, to the point where eventually DG, DEC, HP, and others released their own graphical workstations based on their minicomputer architectures.

All of these used vendor operating systems, not UNIX, and almost all emphasized the use of Pascal and FORTRAN for high-level application development. (The ones that didn’t had vendor languages too, like InterLISP and Mesa for Xerox.)

Post reply on HN