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 is an API-level reimplementation of 1980s-era Mac OS
31–40 of 70 posts
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#32I 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 get around the limitations of the features.
I don't know if the decision apple made was specifically with future machines in mind. It certainly would have been a headache to make new machines 5 generations down the track if the first one had player missile graphics.
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#33Earlier quoted context omitted.
Strange it errors out on given that I assume the thing does run elsewhere. The X11 version sometimes shows the opening screen but any attempt at interaction leads to the mentioned error. The VLC version shows the error directly.
Any interaction with the Welcome application terminates it. Try setting AMS_APPNAME=Tic-tac-toe in the environment, or AMS_APPNAME="Nyanochrome Cat".
Yes, that works, the tic-tac-toe thing appears and remains even though the error message regarding OpenDF is shown. In other words that error message can be ignored, at least as long as whatever is in AMS_APPNAME does not require whatever OpenDF provides.
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#34This is quite the feat. I’d love to know more about the process to make this, the motivation, how much time was spent, etc.
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…
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.
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#35I 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...
There were plenty of apps that relied on implementation quirks.
They mostly relied on OS/Toolbox implementation quirks though, not hardware implementation quirks, because applications that relied on the latter wouldn’t run on the Macintosh XL and that mattered to certain market segments. (Like some people using spreadsheets, who were willing to trade CPU speed for screen size.) Similarly anything that tried to use floppy copy protection tricks wouldn’t work due to the different system design, so that wasn’t common among applications.
So even things that wrote directly to the framebuffer would ask the OS for the address and bounds rather than hardcode them, copy protection would be implemented using license keys (crypto/hashes, not dongles) rather than weird track layouts on floppies, etc. It led to good enough forward compatibility that the substantial architectural changes in the Macintosh II were possible, and things just improved from there.
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#36I 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...
There were plenty of apps that relied on implementation quirks.
Out of curiosity, what app are you thinking of? Of all of types of software used with classic Mac OS (INITs, CDEVs, FKEYs, Desk Accessories, Drivers, etc.), apps would be the least likely to rely on implemention quirks.
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#37Earlier quoted context omitted.
There were plenty of apps that relied on implementation quirks.
They mostly relied on OS/Toolbox implementation quirks though, not hardware implementation quirks, because applications that relied on the latter wouldn’t run on the Macintosh XL and that mattered to certain market segments. (Like some people using spreadsheets, who were willing to trade CPU speed for screen size.) Similarly anything that tried to use floppy copy protection tricks wouldn’t work due to the different s…
Eh, there were plenty of games that were coded for a particular clock speed, and then once the SE came out, had an update that included a software version of a turbo button, let you select which of two speeds to run at. They run FAST on an SE/30 or Mac II and unusably fast on anything newer.
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#38I'd like to see something like Carbon for old apps so that they boot in modern window frames (without the missing Tahoe corners) and can save to files.
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.
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#39Earlier quoted context omitted.
They mostly relied on OS/Toolbox implementation quirks though, not hardware implementation quirks, because applications that relied on the latter wouldn’t run on the Macintosh XL and that mattered to certain market segments. (Like some people using spreadsheets, who were willing to trade CPU speed for screen size.) Similarly anything that tried to use floppy copy protection tricks wouldn’t work due to the different s…
Eh, there were plenty of games that were coded for a particular clock speed, and then once the SE came out, had an update that included a software version of a turbo button, let you select which of two speeds to run at. They run FAST on an SE/30 or Mac II and unusably fast on anything newer.
I didn’t encounter too many of those back in the day, I think because there was the VBL task mechanism for synchronizing with screen refresh that made it easy to avoid using instruction loops for timing.
Much more common in my experience was the assumption that the framebuffer was 1-bit, but such games would still run on my IIci if I switched to black & white—they’d just use the upper left 3/4 of the screen since they still paid proper attention to the bytes-per-row in its GrafPort.
Could be that by the time I was using a Mac II though that all the games that didn’t meet that minimum bar had already been weeded out.
Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
#40This is quite the feat. I’d love to know more about the process to make this, the motivation, how much time was spent, etc.
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?"