All emulated code ran faster on the ARM2 processor than the corresponding native versions.
#Pc 68 emulator mac software#
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. Pittard and Gavarini went to work on the Mobius project. Sculley plowed investments back into the Apple II product line. The Apple III, still based on the 6502 processor and not enough of a stretch, was finally detached from life support and pronounced dead. Mac was the sacred cow, but Apple II was the cash cow.
#Pc 68 emulator mac pdf#
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.Īpple 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.Īnd from the book-length pdf Mobile Unleashed: 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. Thanks that’s a very interesting addition!įrom an earlier time in Apple, another story of an emulation project: 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.Ī pretty powerful achievement back in the mid-90s. 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). Notably the File system interface calls were still 68K. They had not ported the entire thing at the beginning. On early PPC Macs, some of the ROM code was STILL in 68K.
#Pc 68 emulator mac Patch#
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. These were invoked through a TRAP mechanism. Many of the common routines were shipped in ROM on the machine. The other aspect of the Mac was the Toolbox ROM. 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. 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. This layer is why multiple segments didn’t need to know the other segments addresses. 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.
![pc-68 emulator mac pc-68 emulator mac](https://i.pinimg.com/736x/8a/6e/68/8a6e6816106069a45f84dd77734cb737--kik-messenger-pc-computer.jpg)
The Mac used the idea of Segments to break up its executable code. On the one hand, with the Mac architecture, it was straightforward. The 68K emulator in the PPC Macs was really quite a piece of work.