PPC Emulators To Debut at MacWorld Tokyo 47
jx100 writes: "I've been following the Mac emulation community for awhile, and, apparently, Mac PPC emulators are about to be unveiled for the PC. Emaculation.com says that Microcode Solutions and Emulators Inc. are planning on showing their emulators at MacWorld Tokyo 2002."
Why so long? (Score:1)
Re:Why so long? (Score:1)
I'm sure the issues surrounding Open Firmware et al will keep Mac OS X confined to native Mac hardware until Apple decides otherwise.
Re:Why so long? (Score:1)
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.
Re:Why so long? (Score:1)
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.
Just thought I would mention what I knew.
Jeff.
Re:Why so long? (Score:1, Insightful)
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.
interesting quote. (Score:2, Interesting)
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.
OK I get the point. (Score:1)
YOU
DONT
NEED
TO
USE
SO
MANY
LINES.
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.
This sig is a virus, take it and use it.
Re:OK I get the point. (Score:2)
Re:OK I get the point. (Score:1)
Re:interesting quote. (Score:1)
according to diagnostic software in WinUAE (amiga emulator, uses the same 68k JIT core as Basilisk II), this 1.47Ghz athlon performs like a 600Mhz 68040.
That's pretty speedy really
Re:interesting quote. (Score:2)
Re:interesting quote. (Score:2)
Re:interesting quote. (Score:2)
Sad that ARDI seems out of the course. (Score:1)
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!
This is old news...sorry (Score:1)
This sig is a virus, take it and use it.
Not PPC Emulation, but very cool... (Score:3, Interesting)
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.
Think different? Think melting watches in half a man's derby hat on a fish.
Re:Not PPC Emulation, but very cool... (Score:1)
Really?!?
Re:Not PPC Emulation, but very cool... (Score:1)
Apple's reaction? (Score:2, Insightful)
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.
Jesus Christ! (Score:1)
Re:Free extras! (Score:1)
my ipod is plugged into one as i type this, not to mention my cd toaster.
btw hearing the mac start up bell on a pc would make me sick, more sick that hearing w*ndows chimes on vpc.
Re:Free extras! (Score:1)
Office 2001 on linux (Score:2)
Re:Apple Laptop Keyboards Unacceptable to Unix Use (Score:1)
You misspelled "want." Or do you mean to imply that Unix detects the keyboard layout and refuses to function if the control key is not in its place?
Old dogs... (Score:2)
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
-- Len
Bzzzzzzzt! Wrong, try again... (Score:2)
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.
-- Len