5A17B374 7AFB 4598 8FF0 48630C4AE47E

These days, we’re used to games evolving over time; developers add content, patch out bugs and generally tinker with their creations for months (if not years) after their publication, subtly re-shaping them into a form which often differs quite wildly from the initial release. Even though this practice wasn’t anywhere near as common back in the days before digital downloads and updates, publishers still changed games post-launch, as a recent example unearthed by Twitter user foone proves.

The example given not only shows how games on physical carts could be altered during production cycles, but also highlights how hard it is to accurate emulate vintage games on modern hardware. The game in question is Pilotwings, an early release for the SNES which is famous for its use of Mode 7 rotational effects.

As foone points out, Pilotwings contains a demo sequence which shows the famous red biplane either landing safely or crashing. If you dig out your copy from the cupboard now and load it up, which of these two scenarios occurs is all down to when the cartridge was actually manufactured; what makes this whole situation rather strange is that the ROM information on every single Pilotwings cartridge is identical. So why does the plane land on some copies, and crash on others?

If the plane lands successfully, then you’ve most likely got an early release of the game. While the ROM chip is the same across all versions, Nintendo added added an extra chip to help with calculations, even in quite early games like Pilotwings. This was an extension of the ‘memory mapper’ chips it had used to good effect in the NES / Famicom era, but this time around the idea was these additional (and optional) microprocessors would give the SNES a much longer lifespan, because Nintendo knew that as time went on the chips would become faster and cheaper to produce (this tactic ultimately led to the famous Super FX family of chips).

In the very first versions of Pilotwings, a NEC-made chip called the DSP-1 was included. The second revision included the DSP-1a and was merely a manufacturing change to bring costs down, so if you’ve got one of those inside your cart, the plane still lands. However, the third and final revision – the DSP-1b – is what causes the problems. This chip ‘fixed’ calculations to make them more accurate, and the result is that the plane now crashes.

Why? Well, it seems the new chip determines that the ‘stored’ button presses which influence that opening demo would, with the revised and more accurate calculations, result in a crash rather than a safe landing. Because Nintendo didn’t go back into the ROM and ‘re-record’ the button presses to alter the demo, we get the difference between the DSP-1/DSP-1a versions and the DSP-1b.

This leads onto foone’s next point — hardware-related revisions like this make emulation an incredibly difficult task. With the ROM information being identical, how do you accurately replicate the difference made by a chip like the DSP-1b? The aim of all emulation is to be as faithful as possible, but how can you account for incredibly subtle hardware changes like this example?

It’s a fascinating insight not only into the world of making games in the ‘90s, but also the challenges which face the people who create emulators — a group of insanely talent individuals who battle seemingly impossible odds (as well as negativity from certain sectors of the retro gaming community) to perfectly imitate the consoles and games we loved all those years ago.

[source twitter.com]