Two CPUs did not mean twice the game

The Saturn paired two SH-2 processors, chips that execute a game’s instructions. But adding a second processor does not automatically make a program faster. The game’s work has to be divided into tasks that can run at the same time—and the processors must coordinate without tripping over shared data or waiting on one another.

That division was the hard part. A game might have one processor manage the main simulation while the other handled a separate batch of work, but only if developers could keep those jobs sufficiently independent. If one task needed results from the other, the second processor could sit idle while the game waited.

Coordination had a cost

The Saturn’s processors also had to communicate and share access to system resources. Developers needed to decide which processor owned each job, pass information between them, and keep the results synchronized. Every handoff added programming work; poorly timed access could create delays rather than extra speed.

This made the second CPU most useful for workloads that could be clearly separated. It was less helpful when a game’s next step depended on the result of the previous one. The console’s theoretical processing power therefore did not translate directly into simpler development or uniformly faster games.

The practical limit was not just how much hardware Sega put in the console, but how much of a game’s work could be split cleanly. For developers under time and budget pressure, leaving some of that capacity unused could be safer than building a fragile system around it.