Share This Page

Here's the deal as I see it:
PowerPC processors run in all the following:
1. Older Mac computers
2. GameCube
3. Wii
4. PS3EDIT : (almost forgot about this one)
5. XBox 360

Since the GC, Wii, and at least earlier versions of the PS3 could run Linux and because of a little program called Mac-on-Linux there's no mystery on how Mac Software can be run on the other three.

Since PPC Macs are no longer produced, no one has really thought of making an emulator for either of these consoles although it would be a very efficient process since it WOULDN'T really have to EMULATE most of the code and could just run it natively. I'm sure, though, that just because of slower processor clocks and different Video hardware it would still be a little slow.

Wii can run GameCube games and homebrew natively.

A GameCube at least definitely can't take Wii or PS3 games because they're meant for something much more powerful. No one's every tried getting it to run less hardware intensive homebrew from the other consoles but that's usually just a matter of porting the code since so much of it's open sourced anyhow.

The same thing with the idea of PS3 on Wii. It's just silly to think it would run software meant for something that much more powerful.

That only leaves one thing to question :

Would it theoretically be possible to develop a virtual machine program that would run on a PS3 and could take and run Wii games and homebrew?The PS3 processor runs a 4X the clock speed of a Wii and that's not even including the PS3's cells. I figure that would be plenty of extra computation power to be able to emulate the differences in hardware. I'm not sure if the PS3's GPU is programmable but that would help, too.It would just be one short step from there to running GC software as I see it

There's also something Crediar was working on something called BroadOff to emulate Starlet which is the part of the Wii processor that isn't on the PS3.

I'm sure Nintendo (if not Sony) would go nuts if it was to be made, though.

Anyway, does that sound reasonable or am I the only one that thinks this is a good idea?
Any of the more techy PS3 guys willing to think about if it can or can't be done?
Better yet, any techy programming guys willing to give it a try?

The real show stopper is going to be RAM on the PS3, with just slightly over double what the Wii has for RAM it would make it almost impossible. That and having to emulate the NAND and and and... just not enough room in the PS3's memory for it.

but especially in that case I would have to agree with [member='PsionicRoshambo']. There's no way there's enough RAM for all of that plus the two redundant layers of emulation with VirtualPC and Dolphin.
And using a page file kinda defeats the purpose.

However having about twice the ram seems to me to like it would be enough since you don't have an OS to clog the space above the Wii's normal memory addresses.

but especially in that case I would have to agree with [member='PsionicRoshambo']. There's no way there's enough RAM for all of that plus the two redundant layers of emulation with VirtualPC and Dolphin.
And using a page file kinda defeats the purpose.

Click to expand...

pretty certain there are mac and linux builds of dolphin already...so you could save yourself 6 steps or so already, but yet again i doubt you would see dolphin running

but especially in that case I would have to agree with [member='PsionicRoshambo']. There's no way there's enough RAM for all of that plus the two redundant layers of emulation with VirtualPC and Dolphin.
And using a page file kinda defeats the purpose.

Click to expand...

pretty certain there are mac and linux builds of dolphin already...so you could save yourself 6 steps or so already, but yet again i doubt you would see dolphin running

Click to expand...

There was a GameCube emulator for PPC Macs called GCube or something like that...

but especially in that case I would have to agree with [member='PsionicRoshambo']. There's no way there's enough RAM for all of that plus the two redundant layers of emulation with VirtualPC and Dolphin.
And using a page file kinda defeats the purpose.

Click to expand...

pretty certain there are mac and linux builds of dolphin already...so you could save yourself 6 steps or so already, but yet again i doubt you would see dolphin running

Click to expand...

There was a GameCube emulator for PPC Macs called GCube or something like that...

Click to expand...

You'll need some sort of x86 virtualization technology to run Windows XP in a virtual environment in the first place.

While all three current consoles are based off the same underlying PowerPC architecture, they are all widely different takes on it. Of the tree, the Wii's CPU is the only one most closely resembling how older Macintosh computers operated. The 360's is multiple, homogeneous cores with each having full functionality, and a strong propensity for general-purpose processing. The PS3's is based off one super-capable core, but with up to 7 (1 disabled out of eight possibles so they could have an acceptable amount of yields from each wafer) micro-cores with limited scope and functionality. It's not really fair to say the PS3's architecture is truly multicore, as it is insanely parallel processing optimized.

Emulators have to at least emulate the basic underlying hardware effectively enough, along with overhead for BIOS and the like (in this case, the Wii's myriad of IOS's), before it could attempt to run a game.

PPC emulating x86 (or x64 for that matter) has and always was a trial in futility. Does anyone here remember having to use VirtualPC for Mac prior to the intel switch? That was just abominable.

If by some miracle the PPC-style code on the Wii/GC could be run natively on a PS3, it would be grounds for nintendo to file for patent infringement, given that you're dealing with integral functionality that allowed Nintendo's system to work, and it would be hard for Sony to prove they didn't just flat out steal it. Then again, original PlayStation could run SNES code near-natively, but that was settled out of court.

Just wayyyy too much to even consider before such an undertaking could happen... and even if the project went on its way, the legal red tape, if not the performance issues alone, would make it unwieldy to try.

While all three current consoles are based off the same underlying PowerPC architecture, they are all widely different takes on it. Of the tree, the Wii's CPU is the only one most closely resembling how older Macintosh computers operated. The 360's is multiple, homogeneous cores with each having full functionality, and a strong propensity for general-purpose processing. The PS3's is based off one super-capable core, but with up to 7 (1 disabled out of eight possibles so they could have an acceptable amount of yields from each wafer) micro-cores with limited scope and functionality. It's not really fair to say the PS3's architecture is truly multicore, as it is insanely parallel processing optimized.

Click to expand...

Okay, I'm going slightly off topic here but this has sparked my curiosity.

Is programming for PS3 similar to programming a hyperthreaded PC just with 8 threads for one core or is it more complicated than that? I've always wondered exactly what each of the cells could do that a normal core couldn't but do they then share their missing functions with the main core then or does the programmer have to take their limitations into consideration?

Not really; Sony has always favored extreme parallel processing in their consoles.

If anything, the 360 is more akin to a hyperthreaded PC, because each physical core can handle 2 threads at a time, and all cores have the same procesisng capabilities, cache, instructions, strengths, weaknesses... basically 3 identical cores, and each capable of processing 2 threads at a time.

The main SPU of the PS3's Cell CPU is the only one with full, unbridled access to cache, memory, and all instructions. the 7(out of 8) SPEs are limited in function and scope... if you remember way back with the early 386/486 intel days, there used to be additional floating-point/math co-processors. Those were limited in their scope, but for what they were programmed for, all one needed to get the job done. The ps3's architecture is much more like this... one main core with a lot of the functionality, with a small army of smaller co-processors that handle limited functionality, but rather efficiently.

The original PS2 did something very similar with regard to how it solved the backward compatibility issue... in short, early phat PS2's used a separate chip to handle I/O primarily... but this same chip was the one used as the CPU in the PS1, complete with its own cache and RAM. When it came time to load up and play a PSOne game on these PS2's, the bootloader would forfeit control from the EE to the MIPS CPU and used the GS chip for graphics. Later on, $ony decided to screw the pooch by removing this chip to try and save $0.00000005/console with the slim PStwo. However, since MIPS emulation on the EE ran so asstastically slow, they had to overclock the chips to compensate. Here's where it gets interesting. If a dev that was sure they weren't going to use the USB/1394 ports on the PS2 for any reason, there was an undocumented but exploitable feature in the SDK that allowed that MIPS chip to be treated as a co-processor for the PS2 as well. See where I'm going with this? with the slims, code that would normally be sent to the ps1 chip was now expected to be processed by something that was no longer there. This led to glitches and even some compatibility issues on games... which wouldn't be so bad if many of the games that used these features weren't high-profile titles. there was at least one known errata page I was able to find where the asian edition of the PStwo slim couldn't even play Final Fantasy VII... and a curiously high number of reports of those who did buy the first slims who couldn't play GTA: San Andreas... at all.

Back on Topic...

Another thing to keep in mind is that Nintendo and Microsoft's SDK's to work with their respective hardware does a lot of automatic performance monitoring of code that Sony's official one did/does not. Whether it does now is debatable (I haven't found any info suggesting this has improved, but I hope I'm wrong), but basically the Sony setup requires a lot more hand-tweaking and optomizing and monitoring that the other platforms don't require.