Install Mac OS 7 onto Raspberry Pi?

[Donji]

Hello,
Just for fun, I would like to install Mac OS 7 onto my new RPi.
Does anyone know how?

[mahjongg]

thats impossible, just as impossible as installing windows 98 (same time frame as OS-7) and expecting it to run fine!
The PI runs on an ARM processor, not on an 68020 processor. Emulating an 68020 processor is difficult because its a complex instruction microprocessor (well all modern CPU's internally now work like a RISC processor, they just use heaps of logic to turn CISC into RISC internally).
The ARM (advanced RISC Machine) CPU is already a RISC (reduced instruction set) processor.
Because 68020 has so many complex instructions its difficult and time consuming to emulate them (thats why intel with its x86 needs so many transistors to do it internally, and that is why it runs so hot).
It means that an 68020 (or x86 for that matter) emulator needs dozens of instruction to emulate the 68020/x86 instructions, so even with the same clock speed it would take many times longer, plus there is extra complexity to emulate all the other stuff of a Mac Personal Computer.
The result would be so slow, Its just not practical.

[post edited to change x86 to 68020]

[Heater]

Donji,

Out of curiosity, I would like to know how you came to think such a crazy idea was even possible?

Please believe I'm not suggesting you are crazy. But clearly there is a big hole in you understanding that has come from somewhere.

[JeremyF]

I can't believe that multiple people have misunderstood this question. Mac OS 7: https://en.wikipedia.org/wiki/System_7

Quite an old OS, but many emulators have been written to run it.

[itimpi]

I can't believe that multiple people have misunderstood this question. Mac OS 7: https://en.wikipedia.org/wiki/System_7

Quite an old OS, but many emulators have been written to run it.

However even that OS was not designed for an ARM processor!

In theory anything can be run under a suitable emulator given enough resources on the host system, but that does not mean that it is more than a fun exercise and it will run at a useable speed.

[Jim Manley]

Mac System (later aka Mac OS) 7 typically ran on 16 MHz 16/32-bit Motorola 68020/68030 up through 275 MHz 32-bit PowerPC 603 CPUs, so it should be feasible to emulate at least the lower-end hardware on the Pi, and PowerPC was based on early RISC technology. To be fair to those confused by the OS name, it first hit the streets 22 years ago, before most current college students were born, as hard as that is to believe! What a long, strange trip it's been, indeed

[ghans]

You could try PearPC , it worked on the Pi in the past (horrendously
slow though).


ghans

[Donji]

Donji,

Out of curiosity, I would like to know how you came to think such a crazy idea was even possible?

Please believe I'm not suggesting you are crazy. But clearly there is a big hole in you understanding that has come from somewhere.

I can't believe that multiple people have misunderstood this question. Mac OS 7: https://en.wikipedia.org/wiki/System_7

Quite an old OS, but many emulators have been written to run it.

However even that OS was not designed for an ARM processor!

In theory anything can be run under a suitable emulator given enough resources on the host system, but that does not mean that it is more than a fun exercise and it will run at a useable speed.

Logically (very crude logic haha), I would guess, 10 years later, running an old OS like OS7 would be easy because currently I can play n64 games on my android. Just humor me if I'm way far off.

It's all good, I'm new at this. I'm starting a visual communications major with hopes of later studying interaction design. I'm not a programmer (at least not yet) so this is my intro device.

What is an ARM processor?

[ghans]

Try PearPC or Basilisk.

It might work.


ghans

[Heater]

Donji

In this modern world there are two main processor types for consumer gadgets, Intel and ARM.

Intel is what you probably have in your Windows PC or laptop and is used by Apple for their desktops and laptops. However similar architecture processors are made by AMD. Windows and its applications made for Intel will run on AMD machines.

ARM is what you probably have in your mobile phone, or tablet. Android or Apple. Software made for ARM will not run on Intel and vice versa. Even MS now has Windows for Intel and ARM but you cannot just move applications from one to another, the instructions the processors understand are very different.

This is quite a sad situation really. Back in the day we had a lot more choice in processors.

ARM machines were created in England by the ACORN company to provide the processor for their next computers replacing the old 8 bit stuff. ARM is 32 bit. They were faster than any PC at the time.

See the history here: http://en.wikipedia.org/wiki/ARM_architecture

Except: In the modern world we also have operating systems made from Linux, like Debian, where the same OS and applications can be run on Intel, or ARM, or many other processor type. Debian on the Pi looks just like Debian on my PC. Such is the marvel of Open Source and Free Software. However you cannot move the binaries around and expect them to run. They require recompiling from their source code into what ever instruction set the target machine uses.

So what about that old Mac OS? I have no idea but I guess it is from the Motorola processor or PowerPC processor times. Again very different instructions sets. This stuff can only be run using some kind of processor emulation which is going to be very slow.

Many old games were made for different processors than we run them on today. Machine emulation is used to do that. Often the speed penalty of that does not matter as the old machines were so slow anyway.

[mrpi64]

everything is possible if you put your mind to it. if you don't believe that you can do it, throw it away and do something else (lol)

[N4HHE]

So what about that old Mac OS? I have no idea but I guess it is from the Motorola processor or PowerPC processor times. Again very different instructions sets. This stuff can only be run using some kind of processor emulation which is going to be very slow.

Mac OS 7 ran acceptably fast on 5 MHz 68000's back in its day. When faster PowerPC chips came along Apple included a 68k emulator which users never knew what was running what. Am not aware of Apple ever making a pure PowerPC OS no matter dropping the ability to run on a 68k CPU. When Intel CPUs came along Apple put a PowerPC emulator in the OS and only recently took the last PowerPC code out of MacOS X.

[IvanX]

Here's what you want, at least if you are ok with Mac Plus/SE (black and white 512x342) emulation. As far as I know, it will run any version of Mac OS through 7.5.5.

Mini vMac

It looks like there might already be a development version that runs on the Pi.

It's lightweight and simple, and I've used it successfully on Windows Mobile and iOS, which are also ARM-based.

[Jim Manley]

So what about that old Mac OS? I have no idea but I guess it is from the Motorola processor or PowerPC processor times. Again very different instructions sets. This stuff can only be run using some kind of processor emulation which is going to be very slow.

A 700 MHz 32-bit RISC ARM CPU can run an OS originally designed to run on an 8 MHz 16-bit (external) / 32-bit (internal) 68000 CPU quite nicely.

Mac OS 7 ran acceptably fast on 5 MHz 68000's back in its day. When faster PowerPC chips came along Apple included a 68k emulator which users never knew what was running what. Am not aware of Apple ever making a pure PowerPC OS no matter dropping the ability to run on a 68k CPU. When Intel CPUs came along Apple put a PowerPC emulator in the OS and only recently took the last PowerPC code out of MacOS X.

OS 7 transitioned to full PowerPC code by version 7.1.2 in March 1994, and backward compatibility with 68000-based systems was achieved via so-called "fat binaries" containing both 68000 and PowerPC executables (a benefit of the resource fork feature of Apple's file systems, where multiple code resources could be embedded in one file).

The original 128K Mac, 512K "Fat" Mac, Mac Plus, and Mac SE ran 68000s at a bit under 8 MHz, with the Mac SE/30 bumping it up to a 16 MHz 68030 CPU. It's still hard to believe that those machines all had only 1-bit B&W displays and achieved simulated gray scale via dithering, even after they introduced 24-bit Color QuickDraw for their Mac II series systems. By just dropping the Color QuickDraw system extension file into the System Folder of the B&W systems, 24-bit color was automatically mapped to dithered 1-bit shades (one of the reasons emulation works well on relatively old hardware compared with other systems from that era). Even on the B&W systems, output could be printed directly in color on color printers. Pretty amazing stuff thanks to legends like Bill Atkinson and Andy Hertzfeld. I'm still running Mac 128K, 512K, and Plus systems with Systems 1.1g through 7.5 to demo what life was like on that hardware, which includes Netscape web browsing, Word 1.0 (long before it existed for DOS and WIndows), Multiplan (which became Excel), and PowerPoint that started on the Mac and appeared on the PC years later.

[W. H. Heydt]

The original 128K Mac, 512K "Fat" Mac, Mac Plus, and Mac SE ran 68000s at a bit under 8 MHz...

And Apple made much of the fact that Macs ran at 8MHz as compared to the 4.77MHz PCs. What they *didn't* mention was that the display system stole 3 out of every 8 processor cycles, reducing the effective speed to....5MHz, or very nearly the same as those PCs they were snubbing.

[Jim Manley]

What they *didn't* mention was that the display system stole 3 out of every 8 processor cycles, reducing the effective speed to....5MHz, or very nearly the same as those PCs they were snubbing.

Apple wasn't making claims to that effect, that was the ever-dopey PC press that insisted on pursuing the MHz clock speed wars. As usual, you're also ignoring the fact that the 68000 had a 32-bit processor bus internally and a 16-bit bus externally, along with a 24-bit contiguous address space (no segmenting craziness). Meanwhile, the 8088 had a 16-bit internal bus and an 8-bit external bus, necessitating the ridiculous ten 64KB address segments and all of the associated segment-switching programming headaches that involved, especially when code crossed segment boundaries (and remember Bill Gates' apocryphal claim that "no one will ever need more than 640 KB of RAM"? Puh-leeeeze!).

If you're going to talk Apples, then don't talk oranges, kumquats, or whatever the apropos fruit metaphor should be for a PC (oh, yeah, lemons pretty much nails it ). BTW, the original IBM PC Monochrome Display Adapter (all that was available for two years until the Color Graphics Adapter shipped) had more hardware on it than the entire motherboard of the PC, which was otherwise not capable of much beyond pushing bits through a modem at a lightning-fast 300 bps, if you were lucky. Overall system functionality is what should be discussed, not meaningless single attributes such as clock speed.

[eps]

I guess nobody here remembers Palm PDAs. The first ones used DragonBall processors, derived from the Motorola 68k. Later models switched to ARM. Palm OS 5 allowed existing applications to run under emulation, courtesy of an amazing compatibility layer called PACE. Trap calls would deftly switch to the non-emulated OS. While there was a provision for calling native user code, this was generally only used where performance was an issue. Does this sound familiar? It should, because that's basically the paradigm Android uses today (with Dalvik taking the place of 68k emulation). Most of the later Palm OS 5 devices were ARMv5 at 312 MHz, although there were two 416 MHz models. So, no, there's no technical reason it couldn't be done, and I would expect a suitably optimized implementation to perform quite well indeed.