Backward compatibility

• 1. Introduction

  ›

  Backward compatibility means a newer piece of technology can still work with an older, legacy system, or with things built for that older system. On Xbox alone, players have racked up over a billion hours running games first made for earlier consoles. That number hints at how much this promise matters to people who already own machines and games. A companion idea, forward compatibility, points the other way: a product built today with a roadmap toward standards that do not exist yet. Together the two ideas raise real questions. Why do companies bother rebuilding old signals and old instructions into new hardware? What does it actually cost to keep decades-old software and hardware running? And why do some manufacturers eventually strip the feature out anyway?

• 2. Sum And Difference

  ›

  FM radio started out mono, sending just one audio channel down a single signal. When two-channel stereo broadcasting arrived, many listeners still owned only mono FM receivers. Engineers solved this by splitting the audio into two signals. One signal carried the sum of the left and right channels. The other carried the difference between them. A mono receiver could decode only the sum signal and ignore the difference entirely. A stereo receiver could decode a plain sum signal on its own, or combine both signals to separate left and right channels fully. Without a strict need for backward compatibility, engineers could have chosen a simpler method instead.

  That one decision, protecting listeners who already owned mono sets, shows a pattern that recurs on a far larger scale in computing hardware.

• 3. Chips That Remember

  ›

  IBM announced the first 360 models in 1964, then kept extending that same family for decades, through the 370, 390 and Zseries mainframes. Over that time the architecture moved from 32-bit registers and 24-bit addresses to full 64-bit registers and addresses. Newer machines in the family could still run instructions written for the much older ones.

  Intel followed a similar path. It announced the first 8086 and 8088 processors in 1978. Over the following decades that lineage carried on from 16-bit up to 64-bit. Engineers designed the 8086 and 8088 so that programs written for Intel's earlier chip could be translated across easily. Even so, the pair was not instruction-set compatible with Intel's own 8080 processor from 1974. The Zilog Z80, unlike Intel's own follow-up chips, was fully backward compatible with that 8080. A processor with full backward compatibility can run the exact binary instructions its predecessor ran. That lets a business adopt newer hardware without buying new applications or a new operating system.

  Wi-Fi tells a similar story over the air rather than inside a chip. Its success is attributed to broad compatibility in both directions, forward and backward. That flexibility is credited with making Wi-Fi more popular than rival standards that skipped backward compatibility. That same idea of running old and new side by side plays out differently once you move from circuitry into code.

• 4. What Software Promises

  ›

  In software development, the term backward compatibility describes pieces of software that interoperate without producing errors when one calls the other through an API. A piece of software is considered stable once the API used to invoke its functions stops changing across versions.

  Operating systems earn the same label when upgrading to a newer version still lets old executables and other files run as usual. Compilers earn the label in a similar way. A compiler for a newer version of a language keeps it if the compiler can still accept source code from the previous version. The same holds if it can still accept data that worked under that version. A data format qualifies too, when a newer version of the program can open it without errors, just like its predecessor could.

  None of this stability comes free, and the console industry shows exactly what businesses gain and lose by choosing to keep it.

• 5. Selling Nostalgia

  ›

  Backward compatibility can rescue software that would otherwise vanish once a manufacturer stops supporting older hardware. Video games are the clearest example, since their cultural weight is tied up in continued access to older titles. Losing backward compatibility, some argue, would simply make many of those games disappear.

  Microsoft took a slower route with the Xbox One, adding backward compatibility for select titles only several years into that console's life cycle. The hardware inside newer-generation consoles turned out powerful and similar enough to older systems that developers could reconfigure legacy titles to run on it. That approach ran counter to the industry trend of paid, studio-made remasters of classic games. Some see it as an important shift in how console makers set strategy. Both the PlayStation 5 and the Xbox Series X/S carry the same feature into the current console generation.

  That same feature carries a real price tag, one that has pushed some manufacturers to quietly remove it later in a console's life.

• 6. The Price Of Memory

  ›

  Modifying a system so it no longer supports its predecessor is what engineers call breaking backward compatibility. That kind of break usually brings a cost of its own, known as switching cost, layered on top of whatever comes next. Supporting old systems costs money too, starting with a larger bill of materials whenever hardware has to carry legacy support. Added complexity can slow a product's path to market, create technical hindrances, blunt innovation, and raise what users expect from compatibility. For video games specifically, this creates an incentive to build titles that work on both old and new systems at once. Developers chase the largest possible buyer base that way, which produces a shortage of software using the new system's most advanced features.

  Because of these pressures, several console manufacturers phased out backward compatibility toward the end of a console generation. Doing so cut costs and briefly reinvigorated sales before newer hardware arrived. Early PlayStation 3 revisions included backward compatibility with PlayStation 2 games. That relied on onboard Emotion Engine and Graphics Synthesizer chips built into the hardware. Later revisions removed those chips to cut costs and improve sales, eliminating PS2 compatibility from the console entirely.

  The GameCube offers a different kind of cross-generation link. It supports the Game Boy, Game Boy Color and Game Boy Advance through a Game Boy Player attachment. Most Wii models carried that same GameCube compatibility forward, until it was stripped out of later models released from 2011 onward, again to reduce costs.

  Not every manufacturer accepted that tradeoff quietly, and some found unusual engineering shortcuts to dodge the added cost altogether.

• 7. Clever And Costly Workarounds

  ›

  Early PlayStation 2 units built the original PlayStation CPU core directly into the console's I/O processor, letting one chip serve two purposes. That core could act as the main CPU in PS1 mode, or clock itself up to handle I/O duties in PS2 mode. Later PS2 systems replaced that original I/O core with a PowerPC-based chip, one built to emulate the very same functions as the old PS1 core.

  The Super Nintendo Entertainment System chose the unusual 65C816 CPU over more common 16-bit microprocessors available at the time. Engineers picked it because the 65C816 could run in an emulation mode compatible with the 6502 CPU. That, in theory, would make backward compatibility with the original Nintendo Entertainment System easier to achieve. The bet proved unworkable once the rest of the Super NES's architecture came together.

  The 65C816's emulation trick shows how a single chip-level decision can preserve a console's whole back catalog. The same kind of decision, built around the wrong architecture, can just as easily sink it.