Post by the Computer History Museum on the history of Mac emulation
Last week, on June 22, 2020, Apple announced that it will be transitioning future Mac computers away from using Intel microprocessors to chips based on its own designs, using the ARM architecture already being used on its iPhones and iPads. This isn’t the first time Apple has switched out the chips used in the Mac. In 2005, Steve Jobs announced Apple was moving Macs away from PowerPC processors to Intel. And in 1994, Apple shipped its first Macs with PowerPC chips, replacing the Motorola 68000 series of chips used since the original 1984 Macintosh.
[…]
CHM recorded a set of oral history interviews with Gary Davidian on February 5, and March 15, 2019. In particular, Davidian discusses his work on the 68K emulator in Part 2 of the oral history.
The 68K emulator in the PPC Macs was really quite a piece of work.
On the one hand, with the Mac architecture, it was straightforward. The Mac used the idea of Segments to break up its executable code. The main affect about this, particularly in this use case, was that when you called routines in a segment, the call was routed through an extra layer. That layer was always there. This layer is why multiple segments didn’t need to know the other segments addresses. So, when you made a call to a segment, the segment could be loaded on demand, and, in between calls, the segment can be moved in memory.
Since you had this extra layer, it was straightforward to interject a step to check if you were calling 68K code, and then route to the emulator rather than directly to the code.
The other aspect of the Mac was the Toolbox ROM. Many of the common routines were shipped in ROM on the machine. These were invoked through a TRAP mechanism. As the OSes grew and changed over time, the system was able to patch TRAP mechanism, so you could call code that was loaded in to RAM instead of ROM and thus replace (or augment) a ROM call.
On early PPC Macs, some of the ROM code was STILL in 68K. They had not ported the entire thing at the beginning. Notably the File system interface calls were still 68K. That means that you had to be able to invoke 68K calls from PPC code (in contrast to having to run an entire 68K program on a PPC).
So, the early PPC Macs were able to jump back and forth from PPC code to 68K code and back, and intermix it relatively freely.
A pretty powerful achievement back in the mid-90s.
Thank you, that’s very, very interesting, it ties into a thing I’ve researched and written about a couple of years ago, regarding Apple and NeXT’s work on the m88k and in the meantime more tidbits and useful data is emerging:
Through 1993, it actively updated GS/OS for the Apple IIGS, which served as a sort of affordable Macintosh, incorporating a similar mouse-based, windowing interface. An earlier effort, Möbius, intended to develop an advanced Apple II model capable of emulating Mac software using a RISC processor designed by Acorn.
Apple had earlier evaluated the Acorn RISC Machine processor for use in its Möbius project, but now it was interested in working with Acorn to optimize its simple but powerful and efficient desktop-class ARM processor for use in mobile devices, specifically to power the Newton Message Pad.
Mac was the sacred cow, but Apple II was the cash cow. The Apple III, still based on the 6502 processor and not enough of a stretch, was finally detached from life support and pronounced dead. Sculley plowed investments back into the Apple II product line. The Apple IIGS was nearing release…
Pittard and Gavarini went to work on the Mobius project. Their two-year effort created a board using a VLSI Technology ARM2 chip plus software emulating the entire Apple desktop computer lineup: a 6502 or 65C816 running Apple II code, and a 68000 running Mac code. All emulated code ran faster on the ARM2 processor than the corresponding native versions.
Mobius boldly explored some of Apple’s technology problems, but created a potentially dangerous set of marketing nightmares. Blurring the lines between the two major Apple hardware product lines made few friends internally.
I don’t know, but I honestly think that the '816 in the GS was hamstrung to the Apple II compatibility tail wagging the GS dog to prevent it from running at a much higher speed than 2.8MHz of the GS. I know the modern ones can go to 14MHz, I would imagine even back then they could have jumped up to 8MHz. The IIGS market did (does?) have accelerator cards that can push the '816 far higher than the stock speed.
And if the ARM simulator could outperform an 8Mhz 68K, it could probably outperform a similarly clocked '816. But also consider how busy the 68K was on the original Macintosh. Getting an actual 8MHz of pure CPU time out of that machine was a real trick, video et al was quite expensive in that design.
Note that the 8MHz Mac had a very conservative 2MHz DRAM (same as the Apple II, but with twice the width so twice the bandwidth). I was able to redesign the Mac to have a 4MHz DRAM, so the GS could have probably have worked at 4MHz as well.
The 8MHz ARM2 could push a 4MHz DRAM to bursts of 8MHz for sequential access using the DRAM’s page mode, which no other processor did until internal caches became common (the Mac SE did use this for video). So it had an average DRAM of 6MHz, 4 bytes wide. It had 24MB/s to emulate the 4MB/s Mac or the 2.8MB/s Apple II GS. Seems doable.
I don’t think people quite appreciate how much of a magic trick was involved in getting these machines to run.
“8MHz 68000!!” Whoo!!! But, wait…
Much like the IBM PC. 4.77 MHz, but is it really? It was a pretty ham strung 4.77MHz.
The original iPhone was a total magic trick. Boy was that thing slow, but the graphics accelerator (and software) made all of the shazam on the screen come to life. The actual CPU was glacial.