Why haven't we seen any PPC emulation before this? I know that Apple uses the ROM so that it wouldn't be a threat to them. I particularly wonder why there has been no open source implementation of PPC, particularly as IBM is both a supporter of OS and creater of the PPC architecture. Unless the speed just hasn't been there, but it seem like it should be easier to emulate a RISC architecture with a CISC instruction set than the reverse. And Softwindows and the like for Mac OS have been around for ages.

Actually, you're off on two counts. [slashdot.org] There are both open PPC implementations sold by third parties (reference designs were created by IBM/Motorola), and Apple's reliance on their toolbox ROM isn't an issue with NewWorld Macs.

I didn't mean to imply that only IBM was part of the PPC group. I realize that several parties were involved, which makes sense with something proposed as a new standard:)

The information about roms is new to me, however. As far as I knew all version of Mac OS had a special rom file, without which the OS would not run. I guess that has changed. What are the issues with open firmware? I hadn't heard about any particular issues. I thought the great thing about "open firmware" was that it ran on so many different hardware platforms. Sun uses it in their Sparcs, for instance, IIRC.

Although the other poster did have a point. The original iMac and all systems after it used the "new world ROM" which was different from the former "Mac ToolBox ROM". This is also part of the reason why the old Macs used slightly less RAM to run the OS (much of it was ROM). Now, however, we use BootROM and OpenFirmware. As you mentioned, Sun does use OpenFirmware in their Sparc systems (and what they have done with that is really quite amazing). However, the issue here is the BootROM. As many people probably know, this was the reason why you had to send back your daughtercard to the upgrade manufacturer when you bought an iMac CPU upgrade. This was because they needed to harvest the BootROM to graft it onto new upgrade cards. I am not sure, though, if this is relevant to the emulator since I am not sure what, specifically, uses it.

"but it seem like it should be easier to emulate a RISC architecture with a CISC instruction set than the reverse."

I don't quite see this. Emulating CISC on RISC should be comparatively easy, since you could just translate every CISC instruction into a specific group of RISC instructions. Going the other way around seems way more difficult, since there are many different groups of RISC ops that are functionally equivalent to one specific CISC op, so you'd have a hard time correctly identifying such groups in a program. Worse, there might be RISC ops in a program that just don't happen to be grouped in a form that translates into a specific CISC op at all, so you'd have to translate each one of them into a (unnecessarily complex and slow) CISC operation indiviually (-> overhead). Also, whereas emulating the limited x86 register set on the PPC should be pretty straightforward (with the possible exception of the FPU register stack), emulating the PPC's 32 GP registers on a processor that only has 8 of them is probably significantly more difficult.

"Just because things have been practically dead for us for over a year doesn't mean Mac emulation's days are over..."

Your scope. So limited. Over a year? Heh.

We've had 040 since 1994 or so.

What's really happened since the first releases of Fusion, Executor and BasiliskII?

I'll tell you what. Color graphics. That's it. That's the big thing. Thats the only 'milestone' that's happened since this whole 68k mac emulation thing began. Oh okay and the ability to run a shitty 040 at the equivalent of a 68040-9000mhz. Whoop-dee-fucking-doo.

Up to now, what we've had has been a few useless toys that let us run Claris Works, Photoshop 3.0 and Escape Velocity. (Note to all of you guys out there who have a sincere need to keep running your 68k apps: you don't count. At all. I don't care what your excuse is. MOVE ON.)

Do you guys REALLY think that it's all going to come together one month from now?

Again, my point is, people who just discovered this scene a year or so ago don't realize how long it's REALLY been.

I mean. If you get on the train right before the last stop, you wonder what all the passengers who have been on there for 3000 miles are complaining about!

I'm not believing a goddamn thing until I see it running on my system.

Has any other respectable site besides Emaculation uttered a word about this? If this was really going to happen, Apple would be on Drew faster than Sony on Bleem.

Until I see it running - I'll have to conur with Duckie... "yawn".

From what Jim Drew has said, this isn't just about Macintosh emulation on a PC. His PPC product, whatever it may be, seems to have a much broader scope than that.

Y'all can start a countdown if you want, but I wouldn't be wetting my pants just yet.

And take up an entire page on my screen, its called a paragraph, learn to use them!!!
And if I was alowed to moderate this collum I'd find something to mark you down for. I used caps for effect, I know quinto didn't.

It's fast as the current G3. Measure how fast a G3 will emulate x86 and we might be able to get some comparison benchmarks out. Trying several processors on each side of the house would would help isolate emulator overhead.

Old timers can remember about Executor, made by a little New-Mexican company named ARDI [ardi.com].

It featured a quick 68k emulator, and it was the only 'legal' Mac emulator available on PC: they did re-write most of Apple's code (the ROM and the OS itself), allowing them not only to be free from Apple's code but to make it really fast too, by having rewritten the system calls in native x86 code.

I'd sure love to see this little company putting together a G3/G4 emulator. Wishful thinking, I know.

Anyway, if an iMac emulator appears, I hope those cheap multi-gigahertz AMD boxes will be able to emulate a little G3 on inexpensive hardware: finally all those x86 OS X curious, not wanting to buy a Mac because of its price will have a way to play with OS X... And to upgrade with the real thing!

No I'm not trolling, I've been to Emulators online web site before. I think it was a year ago, or darn close to a year ago. They've been saying they are close to a g3/g4 emulator for that long, about a year. As far as I can tell this is vaporware. I just gave up waiting for the emulator and got a G3 to play with OS X. As much as I would like this to be real, cuz I'd rather just emulate the G3/G4. I agree with the other post, I won't belive it untill I or someone trustable, sees it in person.This sig is a virus, take it and use it.

For Amiga users with a PPC accelerator card, there's a product called iFusion [blittersoft.com], which lets an Amiga emulate an iMac. It's reputed to work with most software, and to work more quickly than a Mac with the equivalent processor, just as AMax did with an Amiga emulating a 680x0 Mac in the late 80s.

If you ever doubted the creative insanity of the Amiga community, let this put an end end your nonbelief.

I could see it going two ways. One, very opposed to it, cease and disist orders all over the place.

Or, more likely, they will be completely silent about it. This would make sense from their point of view, suddenly people could start trying out OS X on their PC's. It won't be full speed or offer all the solutions that it will on a mac, but it will give people a really good "preview" of what they might be missing.

Hmmmm I was just being silly, but on re-reading my post I can see why it was modded down... I use FireWire every day on each of my 3 Macs - usually in the much understated 'Target Disk Mode', occasionally for video, and I *wish* I had an iPod.

Really, what platform are these emulators being written for? Do they call x86 functions directly and reveal ppc instructions to the mac os or do they call direct x and windows apis and expose PPC to mac OS. Or,(pant-pant)does this run on linux/FreeBSD/*nix on x86? How hard to port OS X directly instead of emulating PPC?

Why do you need the Control key placed there? PC's have the Control key in the exact same place as where Apple put it, because it makes it so much easier to press Alt-Ctrl-Del when it is where it is at.

Most modern UNIX systems have devalued the Control key anyway. Sun uses Apple's Command Key shortcuts while SGI and HP use stupid Windows ones with the same lower-left Control Key placement.

I bet if you just gave it half of the effort that you put in to that last post, you could get used to the Control key being where it is now. Better yet, you could map another really illogical spiffy key like F7 to be the Control key.

By the way, I learned UNIX by using my old Apple//c to connect to my University's mainframe. It had the Control key where the Caps Lock key now sits. Blame the PC for the current location and get a USB keyboard with the control key where you want it.

I'm only responding to this AC, because he/she is SO wrong, that I would hope that their thought processes won't poison too many people.

PPC is Big Endian (the right way!) in it's Mac application, while x86 and other intel crap is little endian. There is no overhead in processing one way or the other, although the PPC is much more adept at handling endian issues than the antiquated x86.

From the beginning, the PPC architecture has featured bi-endian ability. Natively, it is Big Endian, like all real processors, favoring the Most Significant Bit (MSB) at the lowest adressed data line. Unlike almost all other processors though, the PPC can switch to Little Endian mode favoring the Least Significant Bit (LSB) at the lowest addressed data line. Big Endian is how we (westen culture humans) read binary numbers, while Little Endian is the other way arround.

The endian issue is only an issue when dealing with things like memory space and floating point numbers. Important problems, no doubt, but not so large that it would incapacitate most modern processors. The memory space issues are usually handled in hardware (PCI is little endian even in the Mac), while transform functions (think MMX, SSE, 3DNow) could easily deal with endian data issues.

Connectix Virtual PC actually switches the endianness of the PPC chip in execution, to help emulate the x86. This does make the emulation much faster. Unfortunately, the same trick cannot be used on x86 to emulate the PPC, as MMX and friends would cause a context switch and register flush on both sides of execution. If the code were to be dynamically recompiled though, the endian issue could be greatly reduced by only doing the conversion when absolutely necessary. Unfortunately, the differences between CISC and RISC code (ignoring AltiVec) would make this a very difficult proposition. RISC's ability to emulate CISC instruction sets is why both intel and AMD have RISC cores in both the P6 family and the Athlon, and not the other way around.