Analyse des Innenlebens von Super-Nintendo-Cartridges
(fabiensanglard.net)- Super-Nintendo-Cartridges waren nicht nur einfache Speichermedien, sondern Hardware, die mit CIC-Kopierschutz, SRAM und Zusatzprozessoren die Funktionen der Konsole erweiterte
- Die ROM-Größe wurde damals in Bit statt Byte beworben; unter den untersuchten 3.378 Titeln hatten Star Ocean und Tales of Phantasia 48Mb, Super Mario World hingegen 4Mb
- Die Speicherfunktion beruhte auf batteriegepuffertem SRAM; es gab auch Fälle wie das Zelda-III-PCB, das zusätzlich einen MAD-1-Adressdecoder zur Steuerung des ROM-/RAM-Zugriffs enthielt
- Insgesamt kamen 13 Arten von Zusatzchips in 72 Spielen zum Einsatz und übernahmen auf der Cartridge Aufgaben wie CPU-Beschleunigung, Sprite-Verarbeitung, Dekompression, mathematische Operationen und Polygon-Rasterisierung
- Diese Chips erweiterten die damaligen Darstellungsmöglichkeiten erheblich, hinterließen für die Emulator-Implementierung aber eine langfristige Last durch Reverse Engineering, wie etwa der Fall zeigt, in dem wegen unbekannter S-DD1-Interna ein Grafikpaket nötig war
Grundaufbau einer Cartridge: CIC, ROM, SRAM
- Super-Nintendo-Cartridges konnten neben den Instruktionen und Assets auf dem ROM-Chip auch einen CIC-Kopierschutzchip, SRAM und Zusatzprozessoren enthalten
- CIC arbeitet so, dass der Chip in der Konsole und der Chip in der Cartridge im Lockstep miteinander kommunizieren
- Erkennt der Konsolen-CIC einen anomalen Zustand, setzt er alle Prozessoren zurück
- Nicht alle SNES-Cartridges besitzen einen CIC; das inoffizielle Spiel Super 3D Noah's Ark hat keinen
- Bei Super 3D Noah's Ark muss man zuerst das Spiel in die Konsole stecken und darauf dann eine offizielle Cartridge; von Noah's werden die Bus-Leitungen zum CIC des offiziellen Spiels durchgereicht
- Die ROM-Größe wurde damals nicht in Byte, sondern in Bit angegeben
- Zelda III wurde nicht als 1.048.576 Byte, sondern als 8Mb-ROM beworben
- Die untersuchte Liste umfasst 3.378 Titel aus USA, Japan und Europa
- Star Ocean und Tales of Phantasia gehören mit 48Mb bzw. 6.291.456 Byte zu den größten
- Super Mario World verwendet ein 4Mb- bzw. 524.288-Byte-ROM
- Einige Titel mit Speicherfunktion verwendeten batteriegepuffertes SRAM
- Wenn die Konsole ausgeschaltet wird, geht das SRAM zur Reduzierung des Stromverbrauchs in einen Low-Power-Modus
- Das Zelda-III-PCB enthält den CIC (D413A) an U4, ein 0x80000-ROM (524.288 Byte) an U1, ein LH5268AF-10TLL-64Kbit-SRAM (8KiB) an U2 und den MAD-1-Speicheradressdecoder an U3
Die Bandbreite der Zusatzchips und SA-1
- Der bekannteste Zusatzprozessor ist Super FX aus Star Fox von 1993, doch schon davor wurden EC-Chips eingesetzt
- Insgesamt kamen 13 Arten von ECs in 72 Spielen zum Einsatz
- Die vollständige Liste ist bei wikipedia und snescentral.com zusammengefasst
- SA-1, also Super Accelerator 1, ist ein repräsentativer Zusatzchip, der in 34 Cartridges enthalten war
- Er nutzt wie die SNES-Haupt-CPU eine 65C816-CPU, läuft aber mit dem vierfachen Takt von 10,74MHz
- Er enthält 2KiB SRAM und einen integrierten CIC
- Das Super-Mario-RPG-PCB hat keinen separaten CIC; an U3 sitzt der SA-1, an U1 das ROM und an U2 ein SRAM mit integriertem Decoder
- SA-1 arbeitet ohne separaten Oszillator, übernimmt den System-Master-Clock des Cartridge-Ports und teilt ihn intern durch zwei: 21.4772700MHz / 2 = 10,74MHz
- SA-1 startet im Stop-Zustand; die SNES-CPU erzeugt den Reset Vector und setzt SA-1 fort
- Der anfängliche Instruction Pointer des SA-1 wird aus einem eigenen Reset Vector geladen
- Es gibt drei Betriebsarten: Accelerator, Parallel Processing und Mixed Processing
- In der stärksten Konfiguration arbeiten SA-1-CPU und Super-NES-CPU gleichzeitig, wodurch die Leistung des Super Accelerator Systems auf das Fünffache eines normalen Super NES steigt
- Die gesteigerte Rechenleistung wurde unter anderem genutzt, um alle 128 von der PPU bereitgestellten Sprites zu animieren, Kollisionen zu erkennen und Sprites in Echtzeit zu rotieren bzw. zu skalieren und anschließend in die PPU-VRAM zu schreiben
- Eine Nintendo-SA-1-Demo-Cartridge zeigt diese Verbesserungen
- Die Retro-Gaming-Community hat mit Projekten wie Eliminating slowdown in Super Mario World, Gradius III slowdown removal und Contra III slowdown removal die Verlangsamungen bestehender Spiele reduziert
- Um einen Titel auf SA-1 umzurüsten, ist insbesondere ein Remapping der RAM-/ROM-Zugriffe nötig, was recht komplex wirkt und Fragen aufwirft, zumal die SA-1-Dokumentation festhält, dass „SNES und SA-1 dasselbe Memory Mapping verwenden“
- 2019 lief mit dem SA-1 Collection Project bereits Arbeit daran, mehr SNES-Spiele automatisch umzubelegen und auf SA-1 umzustellen
Grafik-, Kompressions- und Mathematik-Zusatzchips
- CX4 ist ein Capcom-Chip für Mega Man X2 und Mega Man X3
- Er kann 3D-Wireframe-Rendering, verschiedene mathematische Operationen sowie Sprite-Skalierung und -Rotation mit anschließendem Schreiben in die VRAM ausführen
- Beispiele sieht man im Intro und im Bosskampf von MMX2
- CX4 bietet nicht nur Wireframe-Funktionen, sondern auch sprite functions, propulsion, vector, triangle, trigonometric functions, result tables und coordinate transform functions; in MMX2 und MMX3 verarbeitet er sämtliche Sprites
- Das Mega-Man-X2-PCB enthält den CIC an U4, ein 8M-ROM an U1, ein zusätzliches ROM an U2, den CX4 an U3 und einen 20MHz-Oszillator an X1
- S-DD1 ist ein Chip zur Sprite-Dekompression und kann Daten direkt an die PPU-VRAM liefern
- Er wurde in nur zwei Spielen verwendet: Star Ocean und Street Fighter Alpha 2
- Es gab das Gerücht, der Blank vor dem Rundenstart in Street Fighter Alpha 2 liege am S-DD1, doch laut der Erklärung von Modern Vintage Gamer lag das eigentliche Problem bei der Übertragung von Audiosamples in den DSP-RAM
- Das Street-Fighter-Alpha-2-PCB enthält an U1 ein 4MiB-ROM und den S-DD1, der Assets on the fly dekomprimiert; der CIC ist in den S-DD1 integriert, es gibt also keinen separaten Chip
- DSP-1 macht 16 der 19 unterstützten Titel der DSP-Familie aus und kam in Super Mario Kart und Pilotwings zum Einsatz
- Das DSP im Namen steht für Digital Signal Processor, gilt hier aber als Fehlbezeichnung, weil keine kontinuierlichen Signale wie bei üblichen DSPs verarbeitet werden
- Laut Entwicklerhandbuch arbeitet DSP-1 im Blocking Mode, das heißt: Während der DSP Daten verarbeitet, wartet die Super-NES-CPU
- Er bietet Befehle für schnelle 16-Bit-Multiplikation, Kehrwert, sin/cos projection, vector size und rotation und war damit wichtig für HDMA-Programmierung und die Aktualisierung der 3D-Ansicht in Mode 7
- Das Super-Mario-Kart-PCB enthält einen externen CIC, ROM, SRAM zum Speichern, einen MAD-1-Adressdecoder, eine Batterie und einen Oszillator für 8MHz-Betrieb
- Die drei Versionen DSP-1, DSP-1a und DSP-1b führten Fehlerbehebungen und Prozessverbesserungen ein, unterschieden sich aber leicht im Verhalten, sodass im Pilotwings-Demo ein Flugzeug mit dem Boden kollidierte
- Auch andere kleinere Chips wurden nur begrenzt in einzelnen Spielen genutzt
- DSP-2 wurde nur in Dungeon Master verwendet, um Routinen vom Atari ST umzusetzen, und scheint vor allem bei der Sprite-Skalierung geholfen zu haben
- DSP-3 kam nur in SD Gundam GX zum Einsatz
- DSP-4 wurde in Top Gear 3000 und The Planet's Champ TG 3000 verwendet
- OBC-1 wurde nur in Metal Combat: Falcon's Revenge genutzt; es gab Gerüchte über Sprite-Manipulation, die auf nesdev.org jedoch umstritten sind
- S-RTC ist ein Chip zur Verfolgung einer Echtzeituhr in nur einem Titel, Daikaijuu Monogatari II; warum ein Hudson-Soft-Entwickler Echtzeitverfolgung brauchte, ist unklar
- Epsons SPC7110 ist ein Daten-Dekompressionschip für Tengai Makyou Zero, Momotaro Dentetsu Happy und Super Power League 4; in Super Power League 4 bietet er zusätzlich eine Echtzeituhrfunktion
- Die ST-Familie von SETA Corporation sollte Berichten zufolge die Spiel-KI verbessern; ST-010 kam nur in Exhaust Heat 2, ST-011 nur in Hayazashi Nidan: Morita Shougi und ST-018 nur in Hayazashi Nidan Morita Shougi 2 zum Einsatz
- ST-018 scheint eine ARM-CPU mit im internen ROM gespeicherten Instruktionen zu sein
Die Super-FX-Familie und Community-Modifikationen
- GSU-1 kam in fünf Spielen zum Einsatz: Star Fox, Stunt Race FX, Vortex, Dirt Racer und Dirt Trax FX
- Er gehört zu den am besten dokumentierten Zusatzchips; es gibt Wikis, Tutorials und Material aus dem Super Nintendo Developer Manual Book II
- Er arbeitet mit 10,74MHz und teilt den 21,47MHz-Master-Clock intern durch zwei
- Dank des internen 512-Byte-Instruction-Caches kann er arbeiten, ohne die SNES-CPU auszuhungern
- Wenn seine Arbeit abgeschlossen ist, kann er einen Interrupt an die Konsolen-CPU C-CPU auslösen
- Während PPU1/PPU2 des SNES auf Tilemaps und Sprites ausgerichtet sind, ist Super FX stark bei Pixel-Rendering und Polygon-Rasterisierung
- Üblicherweise rendert er in einen Framebuffer auf der Cartridge
- Der Inhalt des Framebuffers wird während VSYNC in die VRAM übertragen
- Das Star-Fox-PCB enthält GSU-1 an U3, den CIC an U5, 74LS139 an U4 und das ROM an U1; an U2 sitzt ein 32KiB-SRAM ohne Batterie
- Dieses SRAM dient nicht als Spielstandspeicher, sondern teilweise als Speicher für den Super-FX-Framebuffer
- Die SNES-Community investiert wie beim SA-1 auch Zeit in den GSU-1 und versucht mit Projekten wie Project Super FX, ältere Titel so weit wie möglich zu verbessern
- GSU-2 ist ein GSU-1, der mit voller Geschwindigkeit von 21,47MHz läuft, und wurde in drei Spielen genutzt: Super Mario World 2: Yoshi's Island, DOOM und Winter Gold
- Es gibt Community-Experimente, bei denen der GSU-1 aus einer Star-Fox-Cartridge durch einen GSU-2 ersetzt wurde, um Leistungszuwächse zu demonstrieren
- Randy Linden von der SNES-Version von DOOM hat sowohl den GSU-Chip als auch den DOOM-Quellcode komplett per Reverse Engineering erschlossen, da ihm beides nicht vorlag
- Die SNES-Version von DOOM war die einzige Konsolenportierung, die die PC-Level verwenden konnte; andere Konsolen mussten die Geometrie vereinfachen
- Yoshi's Island nutzt den GSU-2 hauptsächlich für Sprite-Skalierung und -Streckung und schreibt die manipulierten Sprites anschließend zurück in die PPU-VRAM
- Das Yoshi's-Island-PCB besitzt eine Batterie, sodass das SRAM sowohl für den Framebuffer als auch für Speicherstände verwendet wird
- DOOM wurde auf 32MHz übertaktet, wodurch die Bildrate von 10–11fps auf 14–15fps stieg
- MSU-1 ist kein Chip, der in real ausgelieferten Cartridges verbaut wurde
- Near entwarf ihn, um auf dem SNES CD-Qualitäts-Audio-Streaming, FMV-Wiedergabe und den Zugriff auf bis zu 4GB RAM zu ermöglichen
- Zielgruppe war die Game-Modding-Community; Ergebnisse sieht man in Enhanced Zelda III: A link to the past und Enhanced Another World
Die Last für Emulator-Implementierungen
- Zusatzchips verbesserten das Spielerlebnis deutlich und senkten die Kosten für Publisher, wurden später für Emulator-Entwickler aber zu einer schwierigen Aufgabe
- Einige Spiele, die von ungewöhnlichen ECs abhängen, wurden erst 2012 korrekt emuliert
- Weil man die innere Struktur des S-DD1 anfangs nicht kannte, wurden Spiele wie Street Fighter Alpha 2 zunächst nur dadurch „emuliert“, dass vorab dekomprimierte Sprite-graphic packs benötigt wurden
- Die Implementierung dieser Chips erforderte erhebliches Reverse Engineering
- Manche Chips hatten hartkodierte Funktionen, was ein De-Capping nötig machte
- Bei Chips wie ARM-basierten Varianten, die Instruktionen in internem ROM speichern, muss der Emulator eine BIOS-Datei erhalten
- Selbst mit Stand 2020 war die Emulation einiger der seltensten Chips noch nicht abgeschlossen
1 Kommentare
Hacker-News-Kommentare
Ich finde es wirklich großartig, dass die Module älterer Konsolen fast dasselbe waren wie PCI-Erweiterungskarten für PCs
Sie waren direkt an den Bus angeschlossen und konnten dadurch praktisch alles Mögliche tun, aber leider endete diese Praxis nach dem GameBoy Advance, und ab dem Nintendo DS wurden sie eher zu reinen Datenspeichern
Deshalb sind heute auch seltsame moderne Erweiterungen wie ein Raytracing-Chiphttps://www.youtube.com/watch?v=2jee4tlakqo möglich, ebenso wie der MSU1-Erweiterungschip, der anscheinend nicht als echter physischer Chip existiert, sondern nur in Software-Emulatoren
Theoretisch wäre die Herstellung möglich, also sollte man auch ein echtes SNES-Modul von Road Blasterhttps://www.youtube.com/watch?v=BvIXUOr4yxU bauen können
Im Artikel selbst ist „Street Fighter Zero 2“ in der Liste als USA-ROM aufgeführt, aber Street Fighter Zero war der in Japan verwendete Name für Street Fighter Alpha, daher müsste Zero 2 die japanische Version von Alpha 2 sein
Dabei passieren seltsame Dinge, wenn man das Modul durch einen modernen Computer ersetzt. Zum Beispiel kann man auf einem NES praktisch eine PowerPoint-Präsentation über Humor halten
https://www.youtube.com/watch?v=ar9WRwCiSr0
Es gab also eine begrenzte Möglichkeit, Funktionen hinzuzufügen, und auch wenn das nicht so interessant ist wie eine zusätzliche CPU, hat man auf dem GBA auch nicht so oft derart extreme Dinge gesehen
Ich würde gern wissen, ob das für einen bestimmten Anwendungsfall vorgesehen war oder ob es einen separaten Kanal für eingeschränkte Erweiterungskomponenten im Modul gab
Ein weiteres Detail, das hier fehlt, ist, dass selbst Module ohne Erweiterungschips unterschiedliche Leistungsklassen hatten
Die SNES-CPU lief nominell mit 3,58 MHz, aber tatsächlich war diese Geschwindigkeit nur mit einem eingesteckten „FastROM“-Modul möglich. Nintendo bot Publishern auch das günstigere „SlowROM“-Format an, bei dem die CPU auf 2,68 MHz sank
Es gibt auch eine Modder-Community, die Patches entwickelt, um SlowROM-Spiele in FastROM-Spiele umzuwandeln und so Latenzen zu verringern. Ich habe einmal gelesen, dass einige SlowROM-Spiele ursprünglich für FastROM entwickelt wurden und erst spät wegen Kostensenkungsvorgaben des Publishers auf SlowROM umgestellt wurden
Wenn ich mich richtig erinnere, wurde damals behauptet, dass SlowROM in diesem Fall satte 50 Cent pro Modul einsparte
Der Konkurrent TurboGrafx-16 lief normalerweise mit 7 MHz und nutzte eine CPU aus der 6502-Familie mit ähnlichen Speicher-Timings, deshalb war ich immer verwirrt, warum das SNES beim Tempo so knauserig war
Trotzdem scheiterte der TurboGrafx im Westen, während das SNES weltweit erfolgreich war, also muss man wohl etwas richtig gemacht haben
Letztlich hatten doch alle SNES-Module Mask-ROMs
Ich wünschte, Entwickler würden solche Details weiterhin in geschriebener Form in Blogs festhalten, statt daraus YouTube-Vlogs zu machen
Man kann sehr viele Details in ein paar KB unterbringen
„Super Mario World“ ist immer noch ein absolutes Meisterwerk. Erstaunliche Figuren, Sprites und Levels in gerade einmal 360 KB
Nur im ZIP-Format komprimiert kommt es auf ungefähr 360 KB
Großartige Musik, präzise Steuerung und charmante Grafik – es macht einfach jeden Aspekt eines Jump-’n’-Run richtig
Terranigma ist fast auf demselben Niveau, und für mich liegt Super Mario World wahrscheinlich auf Platz 3
Text kann man kopieren, ein paar Wörter ändern und dann auf SEO-Werbeseiten wiederverwenden
Ich frage mich, was man mit moderner Technik anfangen könnte, wenn man die Fähigkeit, Erweiterungschips in Module einzubauen, ausnutzt
Beim SuperFX heißt es, es habe einen eigenen Framebuffer und kopiere diesen vollständig ins VRAM
Wäre es also technisch möglich, ein absurd leistungsstarkes SoC in ein Modul einzubauen, damit moderne Grafik in SNES-Auflösung zu rendern und die resultierenden Frames dann ins SNES-VRAM zu kopieren?
Ich frage mich, wo die Grenzen liegen
Der Teil „Randy Linden, der Autor von DOOM für das SNES, hatte weder Zugriff auf die Dokumentation des GSU-Chips noch auf den DOOM-Quellcode. Er hat alles per Reverse Engineering gemacht“ ist technisch beeindruckend, aber ich frage mich, warum das nötig war
Randy Linden, der einzige Programmierer des Ports, war von dem Spiel so fasziniert, dass er zunächst auf eigene Faust damit begann, Doom auf das Super NES zu portieren
Da der Doom-Quellcode damals noch nicht veröffentlicht war, nutzte Linden die Unofficial Doom Specs, um die lump-Struktur des Spiels im Detail zu verstehen. Die Ressourcen wurden aus der IWAD extrahiert, aber einige wurden wegen technischer Einschränkungen nicht verwendet
Laut einem Interview fehlte es an einem Entwicklungssystem für Super FX, daher entwickelte Linden vor der eigentlichen Portierung auf seinem Amiga selbst ein Toolset namens ACCESS aus Assembler, Linker und Debugger
Als Hardware-Kit dienten ein gehacktes Star-Fox-Modul und zwei modifizierte Super-NES-Controller, die in die Konsole gesteckt und mit dem Parallelport des Amiga verbunden wurden; um zwei weitere Geräte anzuschließen, wurde ein serielles Protokoll verwendet
Nachdem er einen vollständigen Prototyp erstellt hatte, zeigte er ihn seinem Arbeitgeber Sculptured Software, und das Unternehmen half bei der Fertigstellung. Linden sagte, er hätte gern die fehlenden Level eingebaut, aber das Spiel hatte mit 16 Megabit, also etwa 2 MB, bereits die maximale Größe eines Super-FX-2-Spiels erreicht, und es blieben nur ungefähr 16 Byte frei
Außerdem fügte er Unterstützung für die Super Scope-Lichtpistole, die Super-NES-Maus und das XBAND-Modem für Multiplayer hinzu. Sein Kollege John Coffey, selbst Fan der Doom-Reihe, überarbeitete Levels, aber einige davon wurden von id Software abgelehnt
Um solche Geschichten herum gibt es immer großartige Historie, und ich habe dazu hier auch noch etwas mehr geschrieben: https://eludevisibility.org/super-noahs-ark-3d-source-code
Wenn ich mich richtig erinnere, arbeitete auch das Crash-Bandicoot-Team ohne SDK mit eigenem Code und entdeckte dabei einen Hardware-Bug beim Speichern auf Memory Cards
Ich frage mich, woher bei mehreren Spielen die Byte-Zahlen stammen
Die Spiele lagen auf ROM-Chips, und wie bei ROM-Chips üblich waren deren Größen Zweierpotenzen. Super Mario World erschien zum Beispiel auf einem 512-kb-ROM; woher kommt dann die Zahl 346.330 Byte? Ist das die komprimierte Größe?
Ich sollte ein Programm schreiben, das jedes ZIP entpackt und die 0-Byte-Padding-Daten am Dateiende zählt
Heute ist es zu spät, ich schreibe es morgen und aktualisiere den Artikel dann
Es gibt noch andere Probleme. Der Artikel klingt so, als hätte MVG herausgefunden, dass die Hänger in SFA2 durch das Nachladen von Audiodaten verursacht werden, dabei war das schon lange vor diesem Video bekannt: https://forums.nesdev.org/viewtopic.php?p=70474#p70474
Auch beim RTC wirkt das Ganze ziemlich verwirrend. Es geht offensichtlich darum, dass die Uhr auch dann weiterläuft, wenn die Konsole ausgeschaltet und das Modul entfernt ist, wie bei den Pokémon-Spielen auf GBC/GBA, aber dann wird so getan, als könnte es an NTSC-Clock-Drift liegen. Ich habe keine Ahnung, was damit gemeint sein soll
Zum Teil „Super Mario World wurde ebenfalls so behandelt. An Verlangsamungen erinnere ich mich nicht, aber damals war ich erst zwölf“: In Yoshi’s Island 4 gibt es unter bestimmten Bedingungen Verlangsamungen
Wenn man auf Yoshi sitzt, einen Starman bekommt und dann einen P-Switch drückt, passiert das; es gibt wohl noch ein anderes Level, an das ich mich nicht genau erinnere, mit sehr vielen Monty Moles, die gleichzeitig herausspringen, ich glaube auf Chocolate Island
Es gab wohl auch einen dritten Fall, bei dem zwei Sumo Bros. und der Amazing Flying Hammer Bro. gleichzeitig auf dem Bildschirm waren
Ich habe nie verstanden, wie ROMs für Emulatoren von Modulen gedumpt werden
Ich verstehe, dass man Befehle und Assets dumpt und daraus eine Datendatei macht, die der Emulator interpretieren kann. Aber wie modelliert der Emulator dann all die Erweiterungschip-Hardware im Modul? Wie wird die aus dem Originalmodul herausgedumpt?
Meiner Meinung nach war die Lage beim NES, dem Vorgänger des SNES, sogar noch etwas schlimmer
Im NES gab es ziemlich viele Erweiterungschips, sogenannte Mapper. Ihre typische Funktion war weniger, zusätzliche Prozessoren oder Fähigkeiten hinzuzufügen, sondern eher den Speicherraum des NES zu erweitern; ohne sie war das NES nämlich auf 32 KB PRG-ROM und 4 KB oder 8 KB CHR-Grafik-ROM beschränkt, weshalb sie in den meisten Spielen verwendet wurden
Die meisten Spiele nach der Einführung des NES nutzten solche Chips
Auch sie mussten zusammen mit der Konsole selbst per Reverse Engineering erschlossen werden. Zum Glück war das deutlich einfacher, als zusätzliche CPUs oder Beschleuniger per Reverse Engineering zu analysieren
Es gibt verbreitete Chips wie MMC1 und MMC3, die in vielen Spielen verwendet wurden, und auch Chips wie MMC2, die praktisch nur für Punch-Out eingesetzt wurden
Es gibt nicht extrem viele Arten von Erweiterungschips, daher ist das nicht völlig unbeherrschbar
Der Kopierschutz des SNES ließ sich aus Verbrauchersicht leicht umgehen. Für Spieleentwickler oder Publisher galt das möglicherweise nicht.
Damals hatte praktisch jeder solche „Backup-Geräte“ für das SNES. Man steckte sie an das SNES an, sie hatten ein Diskettenlaufwerk, und Spiele wurden auf sehr günstigen 3,5-Zoll-Disketten „gesichert“.
Für den Betrieb des Systems brauchte man nur ein einziges Originalmodul; steckte man es in den Kopierer, verwendete das Gerät den CIC-Chip dieses Moduls wieder.
https://en.wikipedia.org/wiki/Game_backup_device
Bei der Passage „Es gab drei Versionen des DSP-1: DSP-1, DSP-1a und DSP-1b. Mit Bugfixes und Verbesserungen im Fertigungsprozess änderte sich das Verhalten des Chips leicht, und dadurch stürzte das Flugzeug in der Pilotwings-Demo in den Boden“ dachte ich: Wenn mich jemand fragt, warum ich so schlecht bin, sollte ich diese Ausrede verwenden.