It is well known that the PlayStation 2 implemented compatibility with the previous console by essentially incorporating a PS1 on a chip.

The fact of backward compatibility is unremarkable as far as it goes. Many computational devices over the years have done that, indeed the vast majority of all programmable computational devices ever manufactured have done so, for the obvious reason that the ability to run existing software is a valuable feature that attracts customers.

But the chosen method is actually rather extraordinary when you stop and think about it. The IBM PC AT did not incorporate an original PC on a chip. Nor did the BBC Master thus implement compatibility with the BBC model B, nor the Macintosh 2 or the iPhone 2 or the iPad 2. They all provided backward compatibility by being supersets of the previous version. To the extent that they contained duplicates of the circuitry from the previous version, those duplicates were dispersed in the new circuitry, and used for their intended purpose even when the new machine was being used in its new mode. For example, when a 386 is running 32-bit code, the old AX register is part of the new EAX register.

But the PlayStation 2 implemented backward compatibility by segregating the entire previous machine into a separate chip (which, when a PS2 game was running, was used, if at all, only for some secondary purpose). Why?

It's not about the CPU instruction set. Both machines are based on a MIPS CPU. The PS2 CPU also provides a high-performance vector unit, but that's as well as, not instead of, the MIPS core.

Is it to do with the graphics chip?

But generations of PC graphics cards have provided backward compatibility, and as far as I know, they have not done so by segregating the previous GPU onto a separate chip.

The only salient difference I can think of is that PC graphics cards are accessed by device drivers. Could it be that there is something about GPU instruction sets that makes it unreasonably difficult to provide backward compatibility by the superset method normally used by CPUs, such that easy backward compatibility can only happen when games are screened from the hardware by a device driver, and when games have directly accessed the hardware like on a console, there is nothing for it but to segregate the old GPU onto a separate chip?

If that is the case, then why are GPUs so different from CPUs in that regard? And if not, then what is the explanation?

  • 8
    nintendo does that all the time. the gba contained a z80, the NDS had a GBA ARM7 processor... it's just the best way to ensure 100% compatiblity. Jan 29 '20 at 12:24
  • 6
    A game console is much more than just the CPU, companion chips also need to be handled (like the GPU). Developers (ab)used hardware quirks to get every last drop of performance and wrote/write "close to the metal". Emulating that in software is hard. On the other hand, PCs, smartphones, etc. have (most of) these things abstracted away so it's easier to ensure compatibility: the compatibility can be maintained at a higher level. These abstraction come at a (performance) cost. Also, there's usually just one game console hardware with only slight variations, but lots of hardware for PCs etc.
    – DarkDust
    Jan 29 '20 at 13:20
  • 5
    Around the era of 8086 PCs, many games programmed for 4.77 MHz XTs ran too fast on 8 MHz clones, nevermind on 286s.
    – ninjalj
    Jan 29 '20 at 14:45
  • 3
    some computers did it. Many Itanium CPUs actually contain x86 CPUs inside
    – phuclv
    Jan 29 '20 at 16:14
  • 2
    A good older example would be the Apple IIgs, which for backwards compatibility contained all of the logic for an Apple II motherboard, disk controllers and a few other standard peripherals in one ASIC. A similar chip would be used to provide the "Apple //e on a card" add-on for the Macs.
    – RETRAC
    Jan 7 '21 at 19:47

Probably because it was the only way to get 100% compatibility with the old software library, which was required while most PS2 titles weren't developed yet. No one wants to buy a machine without games, and no one wants to upgrade and lose the ability to play old games.

Note how console makers have an "all or nothing" way of handling compatibility. For instance Nintendo GameBoy Advance includes a Z80 only to be compatible with the GameBoy. Nintendo DS contains an ARM9 but also an ARM7 to be able to perfectly run GBA games.

Here, the PlayStation 2 contains a 34 MHz MIPS processor only here to run PS1 games.

The console isn't powerful enough to software emulate the PS1 hardware so you had to have a PS1 inside.

Some didn't follow that path:

When the PowerPC Macintosh was out, they didn't integrate a 68040 inside it, but went for emulation for old applications. This worked pretty well because the PowerPC was far more powerful than the 68040, and when an application called the operating system (quite a lot, on macintosh), it ran on native PPC code. The main wasn't to preserve 100% of the apps & games from yesteryear. Some where ported/recompiled, and the rest was just... slower.

The Amiga 1200 was supposed to be backwards compatible with the Amiga 500 but a more powerful CPU (68020 vs 68000) meant that some games would fail because they were using 68000-specific tricks (prefetch, read SR, CPU-dependent loops).... Not talking about custom processors that got a rehaul too. And wrongly programmed old games would fail, just because they involuntarily trigger new features bit writing to locations that did nothing on the old chips, but triggered a feature on the new chips.

So even if a lot of titles were running, not 100% (much less than that) of games were compatible.

On Intel machines using windows, it's different:

  • First, Intel worked hard to ensure maximum compatibility with all x86 processors.
  • Second, all games now use the operating system, and aren't banging the hardware
  • Third, Windows/Intel don't guarantee that old software work. It's a "best effort" policy. But it's a very powerful computer and there are other ways: CPU/machine emulation, virtual machines (VMWare).

On tablets, it's globally the same thing. The (mostly) ARM processor is backwards compatible, but the majority of the code is compiled, which means no low-level CPU tricks, self-modifying code, etc.. Also, applications depend on the system, not directly on the hardware. But I've seen old applications not working on higher versions of iOS.

  • 3
    68000 has a MOVE SR instruction which runs in user mode, but was moved to supervisor in 68020 since it allowed to access to interrupt state. In that case it failed even for well-programmed games. Also the CPU isn't the only source of incompatibilities (coprocessor, memory layout, speed). Well-programmed applications generally work, but you never know. Jan 29 '20 at 12:55
  • 3
    Intel sells CPUs so it's in Intel's interest to make the CPU compatible. Companies selling computers have an interest in making the computer compatible; whether that's done in hardware or software may be an economic decision. Likewise for game consoles. Sometimes throwing extra hardware at a problem is the cheapest approach (especially if time-to-market matters). Jan 30 '20 at 0:27
  • 2
    Intel did that, but Motorola didn't hesitate to remove 68040 instructions (MOVEP) for the 68060, replacing that by a software library. If you're banging the metal, and you find this instruction, it just crashes. Jan 30 '20 at 9:18
  • 4
    Apple recently instituted a new policy that requires all apps for the Mac App Store to be delivered in ISA-independent LLVM bitcode format, so they can change the ISA whenever they want: they just need to compile for the new ISA. (Leading to speculation that they may want to ditch Intel in the near-to-mid-future.) I believe, but do not know, that they have been requiring the same for the other app stores for quite a while as well. That's a way of implementing not only backwards but also forwards compatibility as well. Feb 1 '20 at 17:43
  • 2
    @JörgWMittag which worries me as my company is developping code using an Ada library Feb 1 '20 at 17:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.