Comment by kmeisthax

Comment by kmeisthax 4 days ago

6 replies

Emulating x86 would be an option - though given Sony's history, I doubt they'd consider it seriously.

For context...

- PS1 BC on PS2 was mostly hardware but they (AFAIK?) had to write some code to translate PS1 GPU commands to the PS2 GS. That's why you could forcibly enable bilinear filtering on PS1 games. Later on they got rid of the PS1 CPU / "IO processor" and replaced it with a PPC chip ("Deckard") running a MIPS emulator.

- PS1 BC on PS3 was entirely software; though the Deckard PS2s make this not entirely unprecedented. Sony had already written POPS for PS1 downloads on PS2 BBN[0] and PSP's PS1 Classics, so they knew how to emulate a PS1.

- PS2 BC on PS3 was a nightmare. Originally it was all hardware[1], but then they dropped the EE+GS combo chip and went to GPU emulation, then they dropped the PS2 CPU entirely and all backwards compatibility with it. Then they actually wrote a PS2 emulator anyway, which is part of the firmware, but only allowed to be used with PS2 Classics and not as BC. I guess they consider the purchase price of the games on the shop to also pay for the emulator?

- No BC was attempted on PS4 at all, AFAIK. PS3 is a weird basketcase of an architecture, but even PS1 or PS2 aren't BC supported.

At some point Sony gave up on software emulation and decided it's only worth it for retro re-releases where they can carefully control what games run on the emulator and, more importantly, charge you for each re-release. At least the PS4 versions will still play on a PS5... and PS6... right?

[0] A Japan-only PS2 application that served as a replacement for the built-in OSD and let you connect to and download software demos, game trailers, and so on. Also has an e-mail client.

[1] Or at least as "all hardware" as the Deckard PS2s are

lxgr 4 days ago

> Then they actually wrote a PS2 emulator anyway, which is part of the firmware, but only allowed to be used with PS2 Classics and not as BC.

To be fair, IMO that was only 80-90% of a money grab; "you can now run old physical PS2 games, but only these 30% of our catalog" being a weird selling point was probably also a consideration.

> Sony had already written POPS for PS1 downloads on PS2 BBN[0] and PSP's PS1 Classics, so they knew how to emulate a PS1.

POPS on the PSP runs large parts of the code directly on the R4000 without translation/interpretation, right? I'd call this one closer to what they did for PS1 games on the (early/non-Deckard) PS2s.

MadnessASAP 4 days ago

> No BC was attempted on PS4 at all, AFAIK. PS3 is a weird basketcase of an architecture, but even PS1 or PS2 aren't BC supported.

To Be Faiiiirrrrrr, that whole generation was a basket case. Nintendo with the motion controls. Microsoft with a console that internally was more PC then "traditional" console (and HD-DVD). Sony with the Cell processor and OtherOS™.

I do have fond memories of playing around with Linux on the PS3. Two simultaneous threads! 6 more almost cores!! That's practically a supercomputer!!!

  • anonfordays 4 days ago

    I remember the hype around cell processors being so high around the release of the PlayStation 3. It was novel for the application, but still fizzled out even with the backing it had.

  • lxgr 4 days ago

    In what sense would you say the Xbox 360 was more "PC-like" than "console-like"?

    • kmeisthax 4 days ago

      I'll try to answer in the parent commenter's place.

      Prior generations of consoles were true-blue, capital-E "embedded". Whatever CPU they could get, graphics hardware that was custom built for that particular machine, and all sorts of weird coprocessors and quirks. For example, in the last generation, we had...

      - The PlayStation 2, sporting a CPU with an almost[0] MIPS-compatible core with "vertex units", one of which is exposed to software as a custom MIPS coprocessor, a completely custom GPU architecture, a separate I/O processor that's also a PS1, custom sound mixing hardware, etc.

      - The GameCube, sporting a PPC 750 with custom cache management and vector instructions[1], which you might know as the PowerPC G3 that you had in your iMac. The GPU is "ATI technology", but that's because ATI bought out the other company Nintendo contracted to make it, ArtX. And it also has custom audio hardware that runs on another chip with it's own memory.

      - The Xbox, sporting... an Intel Celeron and an Nvidia GPU. Oh, wait, that's "just a PC".

      Original Xbox is actually a good way to draw some red lines here, because while it is in some respects "just a PC", it's built a lot more like consoles are. All games run in Ring 0, and are very tightly coupled to the individual quirks of the system software. The "Nvidia GPU" is an NV2A, a custom design that Nvidia built specifically for the Xbox. Which itself has custom audio mixing and security hardware you would never find in a PC.

      In contrast, while Xbox 360 and PS3 both were stuck with PPC[2], they also both had real operating system software that commercial games were expected to coexist with. On Xbox 360, there's a hypervisor that enforces strict code signing; on PS3 games additionally run in user mode. The existence of these OSes meant that system software could be updated in nontrivial ways, and the system software could do some amount of multitasking, like playing music alongside a game without degrading performance or crashing it. Y'know, like you can on a PC.

      Contrast this again to the Nintendo Wii, which stuck with the PPC 750 and ArtX GPU, adding on a security processor designed by BroadOn[3] to do very rudimentary DRM. About the only thing Nintendo could sanely update without bricking systems was the Wii Menu, which is why we were able to get the little clock at the bottom of the screen. They couldn't, say, run disc games off the SD card or update the HOME Menu to have a music player or friends list or whatever, because the former runs in a security processor that exposes the SD card as a block device and the latter is a library Nintendo embedded into every game binary rather than a separate process with dedicated CPU time budgets.

      And then the generation after that, Xbox One and PS4 both moved to AMD semicustom designs that had x86 CPUs and Radeon GPUs behind familiar APIs. They're so PC like that the first thing demoed on a hacked PS4 was running Steam and Portal. The Wii U was still kind of "console-like", but even that had an OS running on the actual application processor (albeit one of those weird designs with fixed process partitions like something written for a mainframe). And that got replaced with the Switch which has a proper microkernel operating system running on an Nvidia Tegra SoC that might have even wound up in an Android phone at some point!

      Ok, that's "phone-like", not "PC-like", but the differences in systems design philosophy between the two is far smaller than the huge gulf between either of those and oldschool console / embedded systems.

      [0] PS2 floating-point is NOWHERE NEAR IEEE standard, and games targeting PS2 tended to have lots of fun physics bugs on other hardware. Case in point: the Dolphin wiki article for True Crime: New York City, which is just a list of bugs the emulator isn't causing. https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New...

      [1] PPC 750 doesn't have vector normally; IBM added a set of "paired single" instructions that let it do math on 32-bit floats stored in a 64-bit float register.

      [2] Right after Apple ditched it for power reasons, which totally would not blow up in Microsoft's face

      [3] Which coincidentally was founded by the same ex-SGI guy (Wei Yen) who founded ArtX, and ran DRM software ported from another Wei Yen founded company - iQue.

philistine 4 days ago

Considering how the wins are blowing, I'm going to guess the next consoles from Sony and Microsoft are the last ones to use x86. They'll be forced to switch to ARM for price/performance reasons, with all x86 vendors moving upmarket to try and maintain revenues.