If they can emulate a PowerPC system then they can run AmigaOS and MacOS/MacOSX for PowerMacs to run some legacy programs on Windows, Linux, Modern MacOSX, iOS, etc.
There were rumors that Microsoft would port Windows 10 to the XBox One and then convert XBox games to Windows 10 via the Windows Store, etc. Then you could buy or rent XBox, XBox 360, and XBox One games.
Apple had a Rosetta software that ran PowerMac stuff on Intel Macs until 10.7 removed it IIRC. So Apple has the patents and IP for that.
There was also an old ARDI Executor program that ran old Mac 68K stuff in Windows, Linux, BeOS, etc.
If you just need a PPC MacOSX emulator, look at PearPC. My laptop couldn't emulate a G3 at full speed in 2004 when I first tried it, but I'll bet a modern CPU would have a better chance.
This project doesn't look like it's emulating PowerPC, though. It's tracing the binary, disassembling it, and generating equivalent C++ code. It's a technique called static recompilation.
I suppose "incomplete" depends on what you're doing. It worked pretty well for playing around with all those years ago, and it at least still compiles. I don't have any PPC images around to throw at it.
Well, if you need another PPC Mac OS X emulator, look at QEMU. QEMU's Mac PPC support has improved by leaps and bounds recently. It's now a pretty competent Mac emulator for OS 9.0-10.5.
The Rosetta software (original name was QuickTransit) was developed by Transitive Corporation and licensed by Apple. They were acquired by IBM in 2009.
I'm pretty sure it relies on the fact that the xbox 360 enforces strict W^X.
Which means all the code on 360 games is clearly marked in the binary and it's impossible for the game to do anything weird like generate or decrypt new code on the fly.
That doesn't actually guarantee no funny business, someone could jump into the middle of a multibyte instruction. Generally speaking games shouldn't be doing that so it should be fine, but there's nothing stopping it. It does however show the problem that you can't always actually tell where some code starts within a block.
Note: I'm not talking about the Xbox specially. Its binary format my actually make it clear where every piece of code starts, or there may be other ways of telling.
> That doesn't actually guarantee no funny business, someone could jump into the middle of a multibyte instruction.
Does PowerPC use multibyte instruction that don't have to be aligned? It would be very atypical for RISC processors, but if you can provide evidence that these exist, I will believe you.
(sidenote: I am aware that Thumb and in partiular Thumb-2 on ARM uses instructions of variable length)
I wasn't talking specifically about the PowerPC architecture, I was just pointing out that just because a computer supports 'W^X' doesn't mean you can always know exactly what instructions a program will run. You need stronger guarantees then that (Like, for example, that you can't run unaligned instructions, and that all instructions are the same length). You could never really write a recompiler like this for x86 code even though you can mark data with the NX bit, because you can't tell where the instructions start, or whether or not a jump may end-up half-way between an instruction.
That said, when I wrote that comment I didn't know for sure if the XBox 360 CPU had that or not. Looking it up, it's still not 100% clear to me but I would wager no. There are extensions to the PowerPC architecture that have shorter instructions (It appears to be somewhat similar to Thumb), but I was unable to tell whether or not the XBox 360's Xenon supported that. Being that clearly people more familiar with the XBox 360 then I am believe compiling the code beforehand is possible, I think it's likely the XBox 360 doesn't have the optional support for variable-length instructions.
Still, there are some RISCs that have variable length instructions [0], but as you'd expect the majority of them are fixed length (Though, especially in this context RISC vs. CISC can be pretty arbitrary). Even just talking about Game Systems not all of them run RISCs. The 6502, z80, and 68k are all classified as CISC and have variable-length instructions sets, and all of those are featured in lots of Game Systems. So it is a problem you have to consider if you're going to be writing a JIT/recompiler/etc. for those architectures.
I can confirm. The PowerPC variant used in the 360 (and PS3) only supports 4 byte instructions and throws an exception if you try to force it to execute instructions not 4 byte aligned.
Both the PS3 and 360 are in a unique position where they both have strict W^X, OS enforced code signing, and an arch that doesn't let assembly programmers do weird things. This means they are both extremely viable targets for static recompilation. The programmers have zero ablity to do funky business.
Also on the PS3 (I'm not sure about the 360) the ABI requires the complier to generate and ship with a list of every single function entry point. Which basically means you are static recompiling with easy mode on.
However, you are correct about basically every other console, static recompilation is not easy. (Though it's my theory that static recompilation might be easier on the Atari 2600, because the limited ram makes it really hard for self modifying code to exist.
> Though it's my theory that static recompilation might be easier on the Atari 2600, because the limited ram makes it really hard for self modifying code to exist.
My gut feeling is you probably wouldn't get great benefits out of that since 2600 code relied on a lot of cycle counting to get anything other than pong out of the graphics hardware.
The amortization of instruction decode and dispatch represented recompilation (whether static or dynamic) probably doesn't get you much. You've got to do most of that bookkeeping either way to make the effects of the CPU cycle accurate with regards to the rest of the system. Pretty much every 2600 title relies on this.
So, in addition to lack of self modifying code, PS3/360 emulators benefit from hardware that's complex enough that it essentially has to be treated as non-deterministic by the original game developers (within reason). ie. code written against them uses explicit synchronization primitives rather than cycle counting. Sure you have to get things in the right ballpark (stuff like the bugs fixed in Dolphin by not making EXI->MemCard transfers happen instantly), but there's no code saying 'nop for 12 cycles, and expect the system to be in exactly the right state'.
> There were rumors that Microsoft would port Windows 10 to the XBox One and then convert XBox games to Windows 10 via the Windows Store, etc. Then you could buy or rent XBox, XBox 360, and XBox One games.
You can sorta do this already. Xbox One is running a Windows 10 core and major releases area aligned with windows. You can play significant percentage of Xbox, Xbox 360 and UWP games (like Astroneer for example) on Xbox One.
Yeah, the GPU is a custom part not found elsewhere (IIRC the NV2A GPU is meant to be somewhat similar to the GeForce 2 and GeForce 3).
However, there is an emulator being worked on for the original Xbox called CxBx Reloaded, which is a continuation of the CxBx emulator. To give an idea of how far along it is, here's some recent footage of JSRF:
Yeah, although not any more obscure than the GC/Wii GPU really.
I'd argue that the fact that the OG Xbox's homebrew scene used the illegally acquired official XDK for the mos part played a part. This meant that they didn't get as deep into documenting the hardware at that early stage, and instead relied on closed source libraries.
The same could be argued about the Dreamcast where there SDK was concerned but that has been emulated. Not perfectly but pretty well.
I have read it was not just interest in the console but the GPU.
I wonder if this type of project would be easier for the XBoxOne since it uses x86-64.
I realize x86 != PC as shown by the team that ported Linux to the PS4, another x86 system that has almost no standard PC hardware in it. So I'm sure trying to run XBoxOne binaries on other x86 systems still wouldn't be trivial.
Of course, you don't need to write the whole thing. Both parts (XBox 360 and PS4) are at least similar to existing Radeon GCN parts, and we have good quality open source Radeon drivers which outperform the closed ones.
If you want to run PC executables on PS4 and Xbox One (Xbox 360 has been made well before GCN, it's an AMD VLIW (R300 perhaps?) so I figure you mean Xbox One) you can probably make drivers from the Radeon drivers. However it does not help with running PS4/X1 executables on PC in any way other than knowing a bit about underlying hardware.
My brain scrambled while trying to write One. I have trouble keeping the names straight because they called the XBox Three the XBox One. I meant the new XBox.
I think I maybe misunderstood which way nejenendn was talking about. I thought nejenendn was referring to the difficulty of running Linux on a PS4/XBox One.
Sorry, i was speculating on running xbox one and ps4 executables on the desktopp. Assumably microsoft would add support for xbox executables in this scenario. I don’t see Sony ever doing that; we’d need something like wine, or an actual emulator/dynamic recompiler.
There were rumors that Microsoft would port Windows 10 to the XBox One and then convert XBox games to Windows 10 via the Windows Store, etc. Then you could buy or rent XBox, XBox 360, and XBox One games.
Apple had a Rosetta software that ran PowerMac stuff on Intel Macs until 10.7 removed it IIRC. So Apple has the patents and IP for that.
There was also an old ARDI Executor program that ran old Mac 68K stuff in Windows, Linux, BeOS, etc.