Slashdot Mirror
Where are the PPC Emulators?
mikenetaim asks: "Numerous people have started projects aimed at emulating the PPC based Macintosh. Those that run on machines with a PPC tend to succeed (MacOnLinux, Sheepshaver, iFusion), and every single one which attempted to emulate the CPU failed. Everyone admits that an emulated CPU will run slowly, but no one has ever released a working PPC emulator at any speed (except for an incomplete one, whose name escapes me, that was released a long time ago to statically translate AIX binaries). There are a ton of 68k emulation code floating around the 'net, and a PPC emulator should be easier to produce (due to fixed instruction length, branch predication, opcodes that dictate if CCR flags must be generated, etc). Most of the authors just claim their project was harder than they expected before disappearing. Why do all these projects fail? Can anyone point me to any information or code?"
Same reason Apple has minority marketshare.
Lack of software.
As you obviously know who these people are who claim it is so difficult, you do not lack information. So here is a suggestion: Instead of the old pabulum whereby you come around here and waste time and spread hot air day in and day out, why don't you try writing the emulator yourself? Then maybe you wouldn't have so much tripe to post and time to do it in.
There is an emulator that is a GNU Project part of the gdb source. Located under the directory sim.
So there are some PPC Emulators even some under the GNU license.
That would be here
Preferred the Double-Gauss Sunders, myself, but they took that out of the current build.
I'd love to be sponsored on such a project. Unfortunately, I don't think anyone interested would want to pay my rates. Plus, once I was done, I'm not sure I could get my day job back. :)
But it's fun to dream. I've always wanted to try my hand at an emulator.
Secession is the right of all sentient beings.
First of all, the "emulators" you speak of for PPC machines aren't really emulators at all, they use the PPC processor natively, just allowing a MacOS that could run on that machine anyway, to run simultaneously under BeOS or Linux. There's no PPC emulation going on, really, with apps like SheepShaver; the PPC chip itself is used, not a full emulation ofn the chip.
:-) Several other enthusiasts have also been working on PPC emulation, though nothing usable is yet evident.
:-) That's an enthusiast's wetdream. Apple would sh*t a brick, and may well sue, but hey--there'd be a lot of happy customers to finance the defense. :-)
There are many reasons why PPC emulation on x86 is difficult, and why the resulting emulators have probably always been too embarrassingly slow for their creators to make and release a finished emulator. You *can't* just map PPC registers to x86 registers like you can when emulating many lesser CPUs--*way* too many on the PPC, embarrassingly too few on x86. To even have a chance at being useful, you'd have to go the route of using a JIT compiler to dynamically translate PPC ops to x86 ops, and even then you're obviously paying a big speed penalty. In any event, while a usable G3 emulation is very possible, a usable G4 emulation will be impossible for many years thanks to the nice 128-bit Altivec unit.
This is a hard way to work, from what programmers trying to produce PPC emulations tell me. This is why I think the best way to get PPC support on regular commodity PCs is by not emulating the CPU at all. Instead, one could use a real PPC processor on an add-in card, maybe even with its own system RAM to increase speed. Then, emulate the rest of the hardware on a given PPC Mac using some "glue" software. These cards have been available for a long time in PCI form factors, though not yet used for PPC/Mac "emulation"; most are sold as "processor upgrades" for older Macs, and some are sold on the high-end for PCI backplane machines, and some are add-in cards for extra processing power that come with plug-ins allowing Photoshop to use the extra processors and SDKs to develop support for other apps to use the extra horsepower. There are even a couple of whole-computer-on-a-PCI-card hardware firewalls available; I don't know offhand if any are PPC, but that may be. This, of course, makes the use of G4 and when available G5 processors, possible, if one uses an add-in card.
Jim Drew of Microcode Solutions (whose website only says "new website coming soon" right now) was contacted by one of the manufacturers of PPC add-in upgrade cards for Macs, and contracted to write an emulator which would emulate the hardware of an (old) iMac while using one of their PPC processors on a card to run the actual PPC software, such as Mac OS 9. He was supposed to show this creation at Macworld Tokyo, but claims that the company which contracted with him was not ready to show it. This could be a lie to cover for the fact that he's still not done yet, or it could be the truth--any company releasing such a product, which could presumably let a PC run anything that would run on an old-model iMac, would surely incur the wrath of Apple Legal. So, it's entirely possible that such products are finished by one or more of the add-in PPC card companies, but they're too frightened of releasing them at the moment.
Time will tell. Darek Mihocka claims to have already created working PPC Mac emulation, but that he isn't releasing it until PCs are "fast enough" to run it well enough. Jim Drew also claims that he's been working on a software-only PPC Mac emulation, but that it won't be released until the hardware assisted version is released due to contractual agreements with the hardware maker. Or something like that.
In any event, I still happily play my old 68k Mac games under OS 8 or System 7.5.5 on occasion. I've come to love the open-source 68k Mac emulator Basilisk II for that. And, I have no doubt that sooner or later someone, somewhere, regardless of Apple Legal's threats, will release an emulator--whether all-software or hardware-assisted--which will let me smoothly run OS 9 and let me run OS X as well as or a bit better than an older iMac could. I kinda hope for the hardware sol,ution myself, since it would unlock a much faster Mac emulation, with the ability to upgrade the PPC CPU--and it would just be plain cool to have a real PPC machine running inside and accessible from my PC. Imagine the possibilities that an 800MHz G4 PPC processor card (or even a slower one) for PCs, maybe with a RAM slot or 2 on-card, with software to emulate the rest of the Mac, could bring to the PC. x86 Linux, OS X, and Windows all on the same box, at native speeds.
All in due time, my friends...
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
Aparently the problem is that emulating an PPC on an x86 is an incredable headache. While emulating a x86 on a PPC is a piece of cake.
Though in theory, not matter how embarassingly slow the emulator is, it should be possible to make one.
In general you need a host processor 50 times faster, Mhz for Mhz than the one you want to emulate to get any decent performance on a first-generation emulator.
Emulating a 68K Amiga or Mac (at like 8Mhz) only takes a 400Mhz processor to perform decently. A 100Mhz PPC would require a something like a 5Ghz Host processor to get about the same performance. Take into account all the other hardware while you are at it.
Second generation emulators (Optimized, dynamic recompilation, all other buzz words, etc) require something in the rage of 10 times more powerful.
No GameCube emulation till we are in double-diget Ghz processors, or someone gets the brilliant idea of not emulating the CPU/Graphics Hardware.
Start with the 'emplant' system for the ye-olde amiga, which was supposed to emulate every system under the sun. In the end it only really emulated the 68k mac, and even then, the emplant hardware ended up being just a humongous dongle. (I think it did a couple of 8 bit systems as well?).
This guys been lying about his emulation for at least 10 years. Don't hold your breath for a PPC emulator.
Don't believe his hype
merkac
Cool, but useless.
You're absolutely right that Jim Drew's reputation in the emulation community is crap. He always delivers what he promises years late and with big features which were advertised early on in the project lacking.
In the case of his PPC emulation, it's over a year late already, and he announced around December that it would show at MacWorld Tokyo. Given his typical timetable for falling behind, even if it's not finished yet, it should be finished for sure and on the market (if the hardware company lets it be) before the year is out.
That said, there's no telling whether the iMac emulation will be complete. I'm betting that it will initially only support OS 9 due to incomplete implementation--but that eventually, it should be able to run OS X with some finegling, especially since the Darwin layer is open-source and people have already hacked it to make OS X run on unsupported machines with processor upgrades.
No, Jim Drew isn't timely and he's liable to hype. And in fact, most of the emulation scene hates him right now for letting everyone believe up until the last minute that his PPC emulator would be demoed at Macworld Tokyo. But he does *eventually* deliver products that offer good Mac emulation. Fusion was, for example, the best 68k Mac emulator by far when it first came out, and then for some time afterwards, although Basilisk II slowly but surely beat the crap out of both Fusion and its competitor SoftMac.
At any rate, I think hadware-assisted is the way to rally go for PPC Mac "emulation" on the PC. There are so many high-quality PPC add-in cards out there now, that people really interested in running PPC code on their machines should pick one that's available in decent quantities and start coding the emulation support for it. After that, once the core "glue" emulation is done that can emulate the other Mac hardware and hand off instructions to the PPC add-in card, other PPC add-in boards could be supported, and Darwin could be hacked where necessary to allow OS X to work with any shortcusts that might need to be taken, much as it is hacked now to get OS X working on unsupported Macs with upgrade cards.
It's very doable when approached that way; unfortunately, no one but Drew seems to have been interested in that path. It's a pity, because even though it's more of an accomplishment to emulate a PPC CPU, it's much more practical and could be done much faster if one just emulates the other hardware on a given PPC Mac and "glues" it into using the PPC card for processing. Plus, it would allow the PPC Mac OS to run simultaneously with a Linux or Windows that's actually usable, whereas a "pure" emulation would eat up *all* the x86 CPU's cycles and make it so that one could only practically use the Mac emulator and nothing else.
Wouldn't it be great to have a fully working PPC processor card running Mac OS X, while simultaneously being able to use x86 Linux or Windows on your x86 CPU, all on the same machine? *That* is the idea we should really be going for, not a totally-emulated PPC core. PCI G3 and G4 Mac upgrade cards are *so* plentiful--why aren't more people trying to put them to use for Mac emulation on the PC?
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
Methinks you just want to play nova!!!
Sig you!
PPC is a risc processor ,no ? then why, with a small instruction set does it become more difficult to emulate ? I would have though this would make it easier...
Electronic Music Made Using Linux http://soundcloud.com/polyp
RISC is passe. The PPC folks have been adding instructions like mad, and that's the problem. PPC is RISC only in name. By definition it's a CISC CPU. The difference is that when one sets out to design a CISC CPU from the start, it doesn't end up being such a kludge.
registers. they can't be substituted for a stack and still perform like a register. The're a hardware thing. Encoding - more hardware.
--
"we live in a post-ideological world..." - Billy Bragg.
RISC has nothing to do with the number of instructions on the CPU. It's a philosophy of CPU design where all the instructions are the same size, the architecture is load/store (no memory-to-memory instruction operands -- everything goes through the regsiters), you have a large number of general purpose registers, and (with the exception of really complicated things such as floating point, memory access, etc.), everything executes in the same number of clock cycles.
In the early days of RISC, these designs often involved having few instructions that the CISC processors of the days, hence the RISC nomenclature. However, as CPU requirements have become more complicated, more instructions were necessary. The instructions are still noticably simpler than those found in a CISC CPU, however, so the "R" in "RISC" could be said to stand for "Reduced complexity" instead of just "Reduced."
The PPC is still a RISC by the modern definition of the term. All the instructions are 32 bits in size, they all execute in the same number of clock cycles (with the aforemention exception of floating point), it's a fully load/store architecture, it has plenty of registers, and doesn't allow memory-to-memory instructions. Compare that with a CISC like the x86 where instruction sizes vary, you have a puny register set, many instructions can accept memory addresses instead of registers as operands, and instruction execution time also varies.
Decoding of the instruction set is by far the most intensive of the interpretive process. You'd get at most about 2MIPS with modern x86 CPU driven with that style of engine, so having a strong JIT to get around those issues is absolutely necessary.
I measured this when I was writting DorkCore. The front and back ends of the comiler where pretty easily completed, but the stuff in the middle, intermediate representation, etc... is the real killer for high performance JITs.
You have to do stuff like lazy variable analysis, some kind of SSA (static single assignment) to reduce redundance of writting to a the register file constantly, etc...
Putting everything into registers instead of memry increased speed by 50x, but that's still paultry since you have to execute more RISC instructions for the same CISC one, maybe divide by 3x.
It's not a trivial topic at all.
People think that iMac emulation should be easy. They think the big hold up is emulating the PPC CPU. Well, unless you know the iMac and PPC achitecture, you would have no idea what is the more difficult of the two. I certainly do...
Emulating the iMac's proprietary hardware at a level that would allow ANY OS, ANY real PCI hardware, and ANY peripheral to work as it was being used in a real iMac, is by far the most difficult task. We spent several YEARS (not weeks or days), disassembling PPC code and reverse engineering the custom chips (at a hardware level) in the iMac just to get iFUSION for the Amiga to work. We have further refined this technology for the new hardware that will be released.
NONE of the existing PPC cards for the PowerMac will work in the PC for PowerMac emulation purposes. How do I know?? - We tried working with several different boards (from the Sonnet's Crescendo to a multi-processor PPC card), and NONE of these have the appropriate hardware necessary for workable emulation. After making phone calls to ALL of the PPC manufacturers, only two were actually interested in producing a stand alone card for the PC.
As far as the release goes, we have no control. I was anticipating Christmas of last year, but that did not happen... neither did the Macworld show release. Oh well, things happen. I never promise any type of release date, as that is foolish in the industry. We do occassionally mention planned release dates, but everything is subject to change. Occassionally, we are early with release dates (such is the case with FUSION-PC).
As far as our capabilities for emulations go - we are second to none. Basilisk II only caught up (and eventually passed) FUSION-PC, long after we sold it to Emulators, Inc. We have always produced the first and best in every type of emulation we have developed. Nothing will change in that area. People are just getting impatient.
iMac emulation is obviously a touchy subject with Apple Computers, Inc. There are a lot of rules you have to play by when developing and releasing a product of this magnitude if you expect it to be placed on the shelves of stores world-wide without an immediate injunction being placed on the product.
The level of complexity for releasing such a product is much deeper than most can imagine. Just hang in there...
Jim Drew, CEO - Microcode Solutions
I never said iMac emulation should be "easy." I realize that it must be harder to emulate than anything yet emulated, with the exception of some of the more "exotic" hardware that's been worked on hard by the MAME dev team.
I just said that the poster above is correct that your reputation isn't good in the emulation community at this point, due to the fact that your releases are consistently late. People understand lateness; what they don't understand, and get angry about, is announcing that something will be late only a day or two before it's supposed to debut. The Macworld Tokyo debacle is the prime example--people in the emulation community are peeved at you because you didn't mention that the long-awaited demo of your latest product wouldn't be occurring, until just before it was supposed to.
That's why there's a negative attitude among some when your name is mentioned. I did however point out that, late or not, you *do* eventually produce quality products. Fusion was the first Mac emulator I used, and it was the best of its day. To this day it still supports features which SoftMac doesn't, and in fact SoftMac is a POS compared to Fusion. Basilisk II JIT is by far the best 68k emulator now, but as you point out, it took a long while to catch up and meanwhile no real work has been done to Fusion except for Mihocka's little "tweaks."
I do understand the complexities you've been dealing with, and to some extent I agree that your reputation in some circles is unfair. You do, however, contribute to it by allowing the impression that things will happen at a certain time, and then only "cancelling" them with very short notice.
That said, I do look forward to seeing your hardware-assisted product, if it does ever debut. I'd be willing to pay in the $500 range if it supports OS X, and the $350 range if it doesn't. In any event, good luck with the project, and I hope it makes it into a real product.
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus