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?

  • 13
    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. Commented Jan 29, 2020 at 12:24
  • 9
    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
    Commented Jan 29, 2020 at 13:20
  • 8
    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
    Commented Jan 29, 2020 at 14:45
  • 5
    some computers did it. Many Itanium CPUs actually contain x86 CPUs inside
    – phuclv
    Commented Jan 29, 2020 at 16:14
  • 7
    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
    Commented Jan 7, 2021 at 19:47

2 Answers 2


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.

  • 4
    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. Commented Jan 29, 2020 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).
    – dave
    Commented Jan 30, 2020 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. Commented Jan 30, 2020 at 9:18
  • 5
    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. Commented Feb 1, 2020 at 17:43
  • 2
    @JörgWMittag which worries me as my company is developping code using an Ada library Commented Feb 1, 2020 at 17:47

But the chosen method is actually rather extraordinary when you stop and think about it.

But neither new or unheard of. The 1986 Apple IIgs, 8 years before even the PS1, already included a single chip Apple IIe, the Mega II, in addition to the IIgs hardware. All in spirit of 100% compatibility when running older software. The same chip was used as core of the Apple IIe card for the Mac. And by now as well hacked into the base for a Mini-IIe.

No, a second CPU was not needed, as the 65816 is fully compatible with the 65C02. which brings us to what maybe is the underlaying misconception:

The IBM PC AT did not incorporate an original PC on a chip.

Maybe because it didn't have to?

  • The 80286 was in next to all real mode aspects like the 8088 (just faster)

Beside that, even the little incompatibilities where taken care of: Remember the infamous A20 gate added to make the 80286 warp at 1 Mi exactly like a 20 bit wide 8088 address bus would?

The PC-AT hardware did include a lot of additions to make it fully PC compatible. Like 8 bit transactions on the 16 bit ISA as default and more. In that sense the a PC-XT is build into the PC-AT.

Something IBM also did with add on cards, do does the EGA as well as the VGA contain an 6845 (or replacement thereof) to make it more CGA compatible. Much like with the PS2.

  • "The 80286 was in next to all real mode aspects like the 8088 (just faster)": that's enough to make some games incompatible because they'd be too fast (ex: Popcorn) Commented Oct 13, 2022 at 18:45
  • @Jean-FrançoisFabre Well, then again that was already the case for any XT clocked faster than 4.77. So not a problem of the AT design, but bad software, handling a computer like it is a never changing game console. Same issues happened with any other system's faster follow up (or speed up like with the Apple II) Then again, I was quite happy with cranking my XT up to 6 MHz when playing Pool of Radience :))
    – Raffzahn
    Commented Oct 13, 2022 at 19:29
  • yes, I know, but Sony tried to guarantee that 100% of their software library would work, something that IBM and other compatibles didn't attempt. Commented Oct 13, 2022 at 20:17
  • @Jean-FrançoisFabre Err, don't get me wrong, I'm not criticising your answer in any way. I rather tried to point out some misconception about others not trying hard or the idea of keeping major old system parts around being new.
    – Raffzahn
    Commented Oct 13, 2022 at 21:09
  • don't worry I fully understand Commented Oct 14, 2022 at 15:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .