Sega-Saturn-Architektur – eine praxisnahe Analyse (2021)
(copetti.org)- Der Sega Saturn war eine Konsole aus der Übergangszeit zu 3D, wurde aber statt mit einem einzelnen 3D-Beschleuniger als Parallelarchitektur aus Dual-SH-2-CPUs, SCU, VDP1/VDP2 sowie unabhängigen Audio- und CD-Subsystemen entworfen
- Als CPUs wurden zwei Hitachi SH-2 mit ca. 28,63 MHz in einer Master-Slave-Konfiguration eingesetzt; da sie sich jedoch den externen Bus teilten, verdoppelte sich die Leistung nicht einfach, und die Entwicklung war anspruchsvoll
- Bei der Grafik zeichnet VDP1 viereckbasierte Sprites in den Framebuffer, während VDP2 Hintergründe, Ebenen und Layer-Compositing übernimmt; dadurch war die Konsole stark bei 2D, hatte bei 3D aber erhebliche Einschränkungen bei Visible Surface Determination und Halbtransparenz
- Das Audiosystem kam mit SCSP/Yamaha YMF292, Motorola 68EC000 und 512 KB Sound-RAM einem separaten Computer nahe; dank CD-ROM konnten PCM-Samples und hochwertige Soundtracks auf CD-DA-Basis genutzt werden
- Gegen CD-Kopien setzte Sega einen Ring außerhalb des standardisierten CD-Bereichs und eine SH-1-Verifikation im CD-Laufwerk ein; später erschienen Umgehungs- und Homebrew-Methoden wie Modchip, Swap Trick, PseudoSaturn, Satiator und ODE
Komplexes Konsolendesign in der 3D-Übergangszeit
- Nach dem Mega Drive war der Sega Saturn eine Konsole, die nicht ausschließlich 3D erzwang, sondern mehrere Hardwarekomponenten kombinierte, um bei Bedarf Polygon Drawing zu unterstützen
- Die gesamte Schaltung ist in zahlreiche Prozessoren und vier wichtige Subsysteme unterteilt
- CPU-Subsystem: Hier befinden sich Haupt-CPU, Speicher und SCU
- Video-Subsystem: Hier befinden sich die Grafikbeschleuniger
- Audio-Subsystem: Besitzt eine Audioverarbeitung, die einem separaten Computer nahekommt
- CD-ROM-Subsystem: Hat wegen des Kopierschutzmechanismus eine geschlossene Struktur
- Jedes Subsystem ist an einen eigenen Bus angebunden; Video- und Audio-Subsystem teilen sich einen Bus
CPU: zwei SH-2 und die SCU
- Sega wählte für Spiele der nächsten Generation und 3D-Funktionen CPUs aus Hitachis SuperH-Familie
- SuperH war zwar als CPU für Embedded-Anwendungen gedacht, enthielt aber für die damalige Zeit Designelemente aus der RISC-Welt
- Eine Load-Store-Architektur trennt Speicheroperationen von Registeroperationen
- Bietet einen 32-Bit-Datenbus und eine 32-Bit-ALU
- Bietet 16 universelle 32-Bit-Register
- Ein 32-Bit-Adressbus ermöglicht die Adressierung von bis zu 4 GB Speicher
- Eine fünfstufige Pipeline verarbeitet mehrere Befehle schrittweise
- Frühe SuperH-Modelle enthielten eine 16-Bit-Multiplikationseinheit
- Die SuperH-ISA ist zwar ein RISC-Design, aber alle Befehle sind 16 Bit breit
- Da die CPU Befehle in 32-Bit-Einheiten holt, kann sie pro Zyklus zwei Befehle holen
- Dieser Ansatz entschärft das Problem der Codedichte von RISC-Architekturen
- Auch typische Einschränkungen von RISC-Designs bleiben bestehen
- Wegen Control Hazards müssen Programme den Branch Delay Slot berücksichtigen
- SuperH bietet Delayed Branch Instructions mit Delay Slot
- Data Hazards behandelt die CPU, indem sie die Pipeline bei Bedarf automatisch anhält
Wahl des SH-2 und Dual-CPU-Struktur
- Sega sah die 16-Bit-Multiplikationseinheit als möglichen Flaschenhals bei der Verarbeitung großer Datenmengen in 3D-Spielen und forderte von Hitachi Verbesserungen
- Hitachi erweiterte die Multiplikationseinheit und entwickelte den SH-2, der Segas Anforderungen berücksichtigte
- Mit Blick auf die CPU-Wahl konkurrierender Konsolen wollte Sega auch eine höhere Taktfrequenz, doch bei Chips in der Fertigungsphase ließ sich der Takt nicht mehr erhöhen
- Hitachi hatte in der SH-Forschungsphase minimale Schaltungen ergänzt, damit mehrere SH-CPUs gleichzeitig in demselben System arbeiten konnten; Sega übernahm für den Saturn eine Zwei-Chip-Konfiguration
- Die endgültige CPU-Konfiguration vereinte Parallelisierungsmöglichkeiten und Flaschenhälse
- Zwei Hitachi SH-2 arbeiten jeweils mit etwa 28,63 MHz
- Die beiden CPUs sind physisch identisch, aber als Master-Slave angeordnet
- Die Master-CPU kann der Slave-CPU Befehle senden
- Da sie sich denselben externen Bus teilen, kann es zu Bus-Engpässen kommen
- Der SH7604-Chip enthält Funktionen zur Verbesserung der Ausführungsleistung
- Fünfstufige Pipeline und erweiterte SuperH-ISA
- 32-Bit-Multiplikationseinheit
- Gemeinsamer externer 32-Bit-Datenbus
- 4 KB Cache
- 32-Bit-Divisionseinheit
- Interner DMA-Controller
- Little-Endian-Unterstützung
- Zwei CPUs bedeuten nicht, dass Spiele doppelt so schnell laufen; für effiziente Parallelverarbeitung ist komplexe Programmierung nötig, die den gemeinsamen Bus und die Cache-Nutzung berücksichtigt
Speicher und SCU
- Das CPU-Subsystem besitzt 2 MB Work RAM für allgemeine Zwecke
- Das Work RAM ist in zwei Blöcke aufgeteilt
- WRAM-H: 1 MB SDRAM mit hoher Zugriffsgeschwindigkeit; der Bus wird mit anderen Komponenten geteilt
- WRAM-L: 1 MB DRAM mit geringerer Geschwindigkeit; der Bus ist jedoch der Haupt-CPU vorbehalten
- Zur CPU-Gruppe gehört neben den beiden SH-2 auch die Saturn Control Unit (SCU)
- Die SCU besteht aus zwei Modulen, die Datenbewegung und Rechenunterstützung übernehmen
- DMA-Controller: Vermittelt den WRAM-L-Zugriff zwischen drei Subsystemen ohne CPU-Eingriff
- DSP: Wird wie eine Fixed-Point-Geometry-Unit genutzt und führt Matrix- und Vektorberechnungen wie 3D-Transformationen und Beleuchtung schneller aus als der SH-2
- Der SCU-DSP arbeitet mit halber Geschwindigkeit, hat einen komplexeren Befehlssatz und nutzt für Data Fetch und Store das langsame WRAM-L sowie DMA
- Die SCU enthält 32 KB SRAM zur lokalen Nutzung
Grafikarchitektur: VDP1 und VDP2
- Der Saturn verwendet zwei eigenständige GPUs mit unterschiedlichen Rollen, VDP1 und VDP2, die parallel arbeiten
- Im Grafikdesign der 3D-Generation wurde der Framebuffer wichtig
- Die GPU zeichnet das Bitmap einer Szene in einen Teil des VRAM, anschließend gibt der Video-Encoder es aus
- Die Größe des Framebuffers ist proportional zur Bildschirmauflösung und Farbtiefe
- Beispielsweise kann 600 KB VRAM einen Framebuffer mit 640×480, 32K Farben und 16 bpp aufnehmen
- Die Beschleunigung von Vektoroperationen übernimmt beim Saturn nicht der SH-2 selbst, sondern die SCU
VDP1: viereckbasierte Sprites und Framebuffer
- VDP1 zeichnet Sprites, auf die geometrische Transformationen angewendet wurden, schreibt das Ergebnis in den Framebuffer und übergibt es zur Anzeige an VDP2
- Programmiert wird durch das Ausgeben von Drawing Commands
- Für Befehle, Texturen/Tiles, Color-Lookup-Tabellen und Ähnliches werden 512 KB dediziertes RAM verwendet
- Die Grundform ist ausschließlich ein Viereck (Quadrilateral)
- Modelle bestehen aus Polygonen mit vier Eckpunkten, also aus Sprites
- Forward Texture Mapping ordnet Texturpunkte den Vierecken zu
- Da es keine Filtering- oder Interpolationsverfahren gibt, entsteht beim Rendering Aliasing
- Zu den angebotenen Effekten gehören Flat- und Gouraud-Shading, Anti-Aliasing, Clipping und Transparency
- Zwei 256-KB-Framebuffer-Chips werden genutzt, sodass die nächste Szene in einen Buffer gezeichnet wird, während der andere angezeigt wird
- Wenn das Rendering des zweiten Buffers abgeschlossen ist, wird per Page Flipping der Anzeige-Buffer gewechselt
VDP2: Hintergrundebenen, Layer-Compositing und perspektivische Korrektur
- VDP2 ist darauf spezialisiert, große Ebenen mit bis zu 4096×4096 Pixeln durch Rotation, Skalierung und Verschiebung zu rendern
- Ohne Framebuffer rendert er on the fly entsprechend dem Verlauf des CRT-Strahls
- Unterstützt 24-Bit-Farben mit bis zu 16,7 Millionen Farben
- Er zeigt auch den Ausgabebuffer von VDP1 an und kann ihn mit eigenen Layern transformieren und mischen
- Für den Bildaufbau wird eine der folgenden Optionen gewählt
- Bis zu vier 2D-Ebenen und eine 3D-Ebene
- Oder zwei 3D-Ebenen
- VDP2 setzt Ebenen aus Tile-Maps zusammen und wendet bei 3D-Textur-Mapping Perspective Correction an
- Zu den Effekten gehören Multi-Texturing und Shadowing
- Er kann die Helligkeit der von VDP1 erhaltenen Sprites reduzieren und sie halbtransparent mischen
- Da er jedoch nur einen Sprite-Stream passend zur Geschwindigkeit des CRT-Strahls erhält, sind Encoding und Betrieb schwierig
- VDP2 enthält 4 KB CRAM, um die indexed-colour-Werte von VDP1 in 24-Bit-RGB umzuwandeln
- 3D-Ebenen sind auf zwei beschränkt, doch die CPU kann das VDP2-VRAM wie einen Software-Framebuffer nutzen, um zusätzliche 2D- und 3D-Grafik zu zeichnen
Eine Grafikmaschine stark in 2D, schwierig in 3D
- Die Fähigkeit des Saturn, 2D-Szenen zu verarbeiten, war deutlich größer als beim Mega Drive oder SNES, war aber nicht das wichtigste Verkaufsargument der Konsole
- In 2D-Spielen zeichnet VDP1 traditionelle Sprites, während VDP2 Hintergrundebenen zeichnet und anschließend automatisch zu einer fertigen Szene zusammensetzt
- In Mega Man X4 übernimmt VDP1 die Sprite-Ebene, während VDP2 mehrere Hintergrundebenen aufbaut
- Mit VDP2-Funktionen lassen sich durch Skalierungseffekte Szeneneffekte wie Hitzeflimmern erzeugen
- Bei 3D zeigen sich Stärken und Schwierigkeiten zugleich
- Es gab Spielraum, acht Prozessoren zu nutzen, doch Entwickler mussten die Funktionen innerhalb einer kurzen kommerziellen Lebensdauer erlernen und Spiele veröffentlichen
- Die Spielqualität unterschied sich stark je nach Titel und Herangehensweise des Studios
- Der Saturn definiert Distorted Sprites, also Vierecke aus vier Punkten in beliebigen Winkeln, und füllt die Flächen per Texture Mapping
- Wenn CPU und SCU die 3D-Welt aufbauen und in den 2D-Raum projizieren, rendern die VDPs diese Daten, wenden Effekte an und geben das Ergebnis an den Fernseher aus
- Welche VDP die zentrale Renderarbeit übernimmt, war von Spiel zu Spiel unterschiedlich
- Einige Entwickler ließen nahe Polygone von VDP1 und ferne Hintergründe von VDP2 behandeln
- Andere Entwickler entwickelten Umgehungstechniken, damit VDP2 auch nahe Polygone zeichnen konnte
Visible Surface Determination und Einschränkungen bei Halbtransparenz
- Beim Projizieren von 3D-Polygonen in den 2D-Raum muss unterschieden werden, welche Polygone aus Kamerasicht sichtbar und welche verdeckt sind
- Dieses Problem ist als Visible Surface Determination (VSD) bekannt und beeinflusst die Korrektheit der Modelldarstellung, Transparenzeffekte und die Nutzung von Hardwareressourcen
- VDP1 des Saturn implementiert keine VSD-Funktion
- Wenn Geometrie nicht in der richtigen Reihenfolge übergeben wird, kann die Darstellung fehlerhaft werden
- Segas Grafikbibliothek SGL implementiert Z-Sort beziehungsweise den Painter’s Algorithm in Software
- Polygone werden nach Entfernung zur Kamera von fern nach nah sortiert
- Anschließend werden in dieser Reihenfolge VDP1-Befehle ausgegeben
- Die Z-Order-Werte beim Z-Sort sind Näherungen, daher können in 3D-Umgebungen weiterhin Grafikfehler auftreten
- Einige Programmierer implementierten statt SGL eigene Algorithmen
- Der Saturn kann halbtransparente Grafik rendern, allerdings mit großen Einschränkungen
- Halbtransparentes Pixel-Blending kann nur VDP2 verarbeiten
- VDP1 gibt den gerenderten Buffer ohne Unterscheidung überlappender Sprites aus, sodass halbtransparente Sprites darunterliegende Sprites verdecken
- Das Forward Texture Mapping von VDP1 verursacht Probleme, wenn Halbtransparenz auf Distorted Sprites angewendet wird
- Halbtransparente Pixel benötigen beim Zeichnen sechsmal so lange
- 2D-Spiele können dies umgehen, indem sie die Mesh-Eigenschaft von Texturen nutzen und bestimmte Koordinaten vollständig transparent machen
- Bei Composite-Video-Signalen verschwimmt das Mesh-Muster und erzeugt einen Effekt, der wie Halbtransparenz wirkt
- Auch bei dieser Methode bleibt das Problem bestehen, dass undurchsichtige Teile andere Sprites verdecken
- Daytona deaktiviert Halbtransparenz, wodurch Hintergründe plötzlich auftauchen; Sonic R nutzt das Mix-Ratio-Register von VDP2 und Wechsel der Beleuchtungsstufe, um Transparenz- und Fading-Effekte umzusetzen
Audio: unabhängiges Sound-Subsystem
- Die Audiofunktionen des Saturn stehen im damaligen digitalen Übergang, der CD-ROMs mit Sample-Synthesizern verband
- Das Sound-Subsystem besteht aus SCSP/Yamaha YMF292, Motorola 68EC000 und 512 KB Sound-RAM
- SCSP ist in zwei Module unterteilt
- Multifunktionaler Soundgenerator: verarbeitet bis zu 32 Kanäle als PCM-Samples oder FM-Kanäle
- DSP: wendet Audioeffekte wie Echo, Reverb und Chorus an
- PCM unterstützt Samples in CD-Qualität mit bis zu 16 Bit und 44,1 kHz
- Der Motorola 68EC000 steuert die Audiokomponenten und bildet die Schnittstelle zur Haupt-CPU
- Der 68EC000 des Saturn arbeitet mit 11,3 MHz und ist über einen 16-Bit-Bus angebunden
- Er führt den Sound Driver aus und betreibt die Peripheriemodule
- 512 KB Sound-RAM speichern Audiodaten wie Sound Driver und PCM-Samples und dienen auch als Arbeitsbereich für den DSP
- Die Audio-Pipeline wird von Haupt-CPU, 68EC000, SCU und CD-Subsystem gemeinsam übernommen
- Die Haupt-CPU initialisiert die Audiokomponenten und lädt den Sound Driver ins Sound-RAM
- Danach aktiviert sie den Motorola 68EC000
- Während des Spiels kann die SCU PCM-Samples von der CD ins Sound-RAM übertragen
- Das CD-Subsystem kann unkomprimiertes CD-DA-Audio direkt an SCSP senden
- Mit einer Video-CD-Karte kann komprimiertes Audio auf der Karte dekodiert und anschließend an SCSP weitergegeben werden
- Dank CD-ROM und PCM-Verarbeitung konnten Studios Soundtracks selbst aufnehmen und produzieren und ohne Neuarrangement ins Spiel integrieren
Booten, IPL und integrierte Shell
- Beim Einschalten arbeitet zuerst der SMPC (System Management and Peripheral Control)
- Der SMPC ist ein 4-Bit-Mikrocontroller und übernimmt die Initialisierung von Peripheriechips, etwa das Einschalten der beiden SH-2 und das Einrichten der Master-Slave-Konfiguration
- Danach wird der Reset Vector des Master-SH-2 auf
0x00000000gesetzt; diese Adresse verweist auf den Initial Program Loader (IPL) im 512-KB-ROM - Nach der Hardwareinitialisierung prüft der IPL die Boot-Ziele in folgender Reihenfolge
- Ist ein Cartridge mit ausführbarem Code vorhanden, wird von dort weiter gebootet
- Ist eine Video-CD-Karte vorhanden, wird diese gebootet
- Ist eine Disc vorhanden, wird geprüft, ob es sich um ein Original handelt
- Ist sie original, wird das Spiel gebootet
- Ist sie nicht original oder fehlt eine Disc, wird eine interaktive Shell gestartet
- Der Saturn besitzt neben Spielen einen integrierten Musikplayer namens Multiplayer
- Von dort aus lässt sich der Speicherdatenmanager aufrufen
- Ist eine Video-CD-Karte vorhanden, kann auch von der Karte dekodiertes MPEG-Video abgespielt werden
- Das Saturn-ROM wird im Gegensatz zum PlayStation-BIOS eher IPL genannt, statt primär als Paket von Entwickler-APIs genutzt zu werden
- Allerdings enthält das IPL-ROM auch System-Program-Dienste, etwa für Speicherdatenverwaltung, Stromsteuerung und Semaphoren zur Multiprozessor-Synchronisierung
Spielmedien und Entwicklungsumgebung
- Offizielle Saturn-Spiele werden von einem 2x-CD-ROM-Laufwerk geladen
- Das Medium ist eine angepasste Variante der Compact Disc, hat 650 MB Kapazität und folgt dem Standard ISO 9660
- Viele Spiele enthalten neben der Datenspur Audiospuren, um während des Spiels unkomprimiertes Audio zu streamen
- CDs speichern Informationen in winzigen Pits und Lands auf der Polycarbonat-Oberfläche und rekonstruieren Daten durch Auslesen der Infrarot-Reflexion
- CDs nutzen für Speicherdichte und Synchronisierung mehrere Encoding- und Fehlerkorrekturverfahren
- NRZI zeichnet bei Pit-Land-Übergängen eine
1auf - EFM wandelt 8-Bit-Kombinationen in 14-Bit-Sequenzen um, die zu den Einschränkungen von CD-Readern passen
- CIRC verteilt Daten über die Disc und fügt Redundanz hinzu, sodass beschädigte Bereiche wiederhergestellt werden können
- NRZI zeichnet bei Pit-Land-Übergängen eine
- Der Saturn nutzt das Format CD-ROM XA
- Es kann Daten, unkomprimiertes Audio und interleaved Multimedia Tracks speichern
- Das ist wichtig, um Audio und Bilder auch mit langsamen Laufwerken in angemessener Geschwindigkeit zu streamen
- Für die Dekomprimierung bei Videowiedergabe ist eine separate Video-CD-Karte nötig
- Die Entwicklungsumgebung war anfangs belastend, wurde später aber durch Werkzeuge ergänzt
- Sega stellte keine ausreichenden Softwarebibliotheken und Entwicklungstools bereit, und auch die frühe Dokumentation enthielt Ungenauigkeiten
- Für akzeptable Leistung war anfangs Assembler-Programmierung wichtig
- Später stellte Sega SDKs, Hardware-Kits sowie Bibliotheken für I/O- und Grafikunterstützung bereit
- Saturn-Spiele wurden in einer Kombination aus C und mehreren komponentenspezifischen Assemblersprachen geschrieben
- I/O und RTC verwaltet der SMPC; der SH-2 steuert ihn durch gesendete Befehle
Erweiterungsschnittstellen
- Der Saturn verfügt über mehrere externe Anschlüsse und Schnittstellen
- Der Cartridge Slot hinter dem Laufwerk wird offiziell für zusätzlichen Speicherplatz für Speicherdaten oder als Extra-RAM genutzt
- In Japan und den USA wurde auch ein Modem für Online-Verbindungen angeboten
- Auf der Rückseite befindet sich der Slot für die Video CD Card
- Sie übernimmt MPEG-Dekompression für unterstützende Programme oder Spiele
- Der Communication Connector auf der Rückseite ist eine Schnittstelle, für die Sega keine Entwicklerdokumentation veröffentlichte
- Reverse Engineering ergab, dass er mit den MIDI-Pins des SCSP und dem Serial Interface (SCI) der beiden SH-2 verbunden ist
- Sega veröffentlichte ein Floppy Drive, das diese Schnittstelle nutzt
Kopierschutz und Homebrew-Ausführung
- Da CD-Kopien einfach waren, implementierte Sega Kopierschutz und Region Locking, um die Spieleverteilung zu kontrollieren
- Der Kopierschutz des Saturn weicht absichtlich vom Standard-CD-Format ab
- Gewöhnliche CD-Brenner können keine perfekte Kopie eines Saturn-Spiels erstellen
- Der Disc-Reader des Saturn sucht während der Verifikation nach nicht standardkonformen Merkmalen
- Am äußeren Rand von Saturn-Discs ist ein ungewöhnliches Datenmuster eingeprägt
- Dieses Muster bildet einen sichtbaren Ring mit eingeprägtem Markenlabel
- Der Ring liegt außerhalb der standardisierten Datenbereiche Program Area und Lead-out
- Normale Laufwerke können auf diesen Bereich nicht zugreifen und ihn nicht kopieren
- Im Saturn-CD-Laufwerk befindet sich ein dedizierter SH-1-Prozessor, der unabhängig von der main CPU prüft, ob der Ring vorhanden ist
- Diese Prüfung wird nur einmal durchgeführt
- Traditionelle Umgehungsmethoden konzentrieren sich darauf, den Disc-Verifikationsprozess zu täuschen
- Ein Modchip wird installiert, um den CD-Reader unabhängig von der eingelegten Disc zu täuschen
- Beim Swap Trick wird direkt nach der Verifikation einer Original-Disc auf eine gebrannte Disc gewechselt
- Später erschienen ausgefeiltere Methoden zur Homebrew-Ausführung
- PseudoSaturn nutzt einen Exploit im Kopierschutzmechanismus, um Disc-Spiele ohne Verifikation zu booten
- Stand 2022 wird der neuere Fork Pseudo Saturn Kai verwendet
- 2016 erschien eine Methode, die ausnutzt, dass das Video-CD-Add-on das CD-Laufwerk umgehen und unverschlüsselten Code in das CD-Subsystem injizieren kann
- Dieser Video-CD-Exploit wird als Produkt namens Satiator verkauft
- Ein Optical Drive Emulator (ODE) ersetzt den CD-Reader durch einen SD- oder SATA-Adapter und lässt es für den Saturn so aussehen, als würde eine CD gelesen, während tatsächlich ein Disc-Image gelesen wird
1 Kommentare
Meinungen auf Hacker News
Der Artikel stellt das Design als erstaunlich dar, etwa weil so viele Chips verbaut waren, aber man muss den Kontext sehen: Zwischen dem japanischen und dem US-Team gab es keinerlei Synergie, sondern einen Machtkampf.
SEGA JP entwickelte eine 2D-Konsole, SEGA US eine 3D-Konsole, und genau als das japanische Team diesen Kampf zu gewinnen schien, tauchte die PSX auf und führte praktisch dazu, dass beides zusammengeworfen wurde.
Im Ergebnis wurde es eine 2D-Konsole mit Bauteilen einer unfertigen 3D-Konsole, was aus Designsicht keinen Sinn ergibt.
Für Technikfans oder Leute, die gern Entwickler-Retrospektiven lesen, ist das ein Spektakel, aber für alle, die sauberes Design mögen, ist es endlos irritierend.
Für Mainstream-Gamer jener Zeit ging es im Kern um „Arcade im Wohnzimmer“, und der Saturn war enttäuschend; dass SEGA nicht wusste, worauf es sich konzentrieren sollte, half überhaupt nicht.
Im Wikipedia-Artikel gibt es weitere Details: https://en.wikipedia.org/wiki/Sega_Saturn
In einem Interview mit einem Saturn-Hardwaredesigner (https://mdshock.com/2020/06/16/hideki-sato-discussing-the-se...) bekommt man eine Perspektive darauf, warum sie diese Hardwarekonfiguration gewählt haben.
Im Grunde erkannte er anhand der Reaktion auf die PSX, dass 3D die Zukunft war, aber abgesehen von SEGAs AM2-Team, das 3D-Arcade-Spiele wie Virtua Fighter und Daytona USA entwickelte, lag die interne Expertise bei traditionellen 2D-spritebasierten Spielen.
Deshalb hielt man eine Konsole, die bei 2D-Spielen hervorragend und auch zu einem gewissen Grad 3D-fähig war, für den besten Kompromiss.
Der größte Fehler lag meiner Ansicht nach darin, zu unterschätzen, wie schnell die Branche auf 3D als Schwerpunkt umschwenken würde.
Das tatsächliche Ergebnis der internen SEGA-Konflikte war noch viel dümmer. Sega of America wollte ein konservativeres Design als den Saturn, mit dem Motorola 68020, dem Nachfolger des 68000 im Genesis; es wäre weniger leistungsfähig gewesen, aber Entwickler wären mit der Hardware vertrauter gewesen.
Nachdem SOA diesen Kampf verloren hatte, kam man dort zu dem Schluss, dass der Saturn zu teuer sei, um ihn in den USA gut verkaufen zu können, und entwickelte das 32X, ein 200-Dollar-Add-on für den Genesis.
Das 32X nutzte denselben SH2-Prozessor wie der Saturn, zeichnete die Grafik aber komplett in Software und legte sie über die Genesis-Grafik.
Der ursprüngliche Plan war, den Saturn zwei bis drei Jahre lang Japan vorbehalten zu lassen und das 32X im Ausland zu verkaufen.
Sega of America gab enorme Summen aus, um Interesse am 32X zu wecken, und konzentrierte auch die interne Entwicklung ausschließlich auf das 32X, aber sowohl Entwickler als auch Medien zeigten im Vergleich zum Saturn kaum Interesse am 32X.
Als klar wurde, dass sich das 32X am Markt nicht halten würde, brachte Sega of America den Saturn überstürzt heraus, um die Aufmerksamkeit vom 32X abzulenken. Da man das vorangegangene Jahr jedoch mit der Entwicklung von 32X-Titeln verbracht hatte, musste man sich auf japanische Spiele verlassen, von denen viele nicht zum US-Markt passten.
Beim 32X gab es mehr eingestellte als veröffentlichte Titel, und all das verwirrte und verärgerte Entwickler wie Verbraucher.
Oft wird behauptet, der VDP2 sei später zur 3D-Unterstützung ergänzt worden, aber der VDP2 macht überhaupt kein 3D, sondern ist für Hintergrund-Layer im Stil von SNES Mode 7 zuständig.
Selbst wenn man den VDP2 entfernt, bleibt – wenn man ignoriert, dass der VDP für den Video-Scanout zuständig ist – eine Konsole übrig, die weiterhin gut 3D darstellen kann.
Tatsächlich nutzen viele 3D-Spiele den VDP2 kaum.
2D-Spiele müssten Hintergründe mit Hunderten von Sprites rendern und würden dadurch Qualitätsverluste hinnehmen, aber es wäre möglich.
Entfernt man dagegen den VDP1, bleiben nur die 2D-Hintergrund-Layer des VDP2 übrig.
Dann gibt es weder 3D noch die Möglichkeit, Sprites auf den Bildschirm zu bringen, wodurch er praktisch auch für 2D-Spiele nutzlos wird.
So wie es aussieht, war der Saturn von Anfang an darauf ausgelegt, sowohl VDP1 als auch VDP2 zu haben, und beide wurden für das Zusammenspiel entworfen.
SEGAs japanische Absicht war offenbar, wie am finalen Design zu sehen, eine 2D-Monsterkonsole mit begrenzten 3D-Fähigkeiten.
Das heißt nicht, dass es zwischen SEGA JP und SEGA US keine Auseinandersetzungen gab; dafür scheint es durchaus Belege zu geben.
Ich glaube nur nicht, dass in letzter Minute ein japanisches und ein amerikanisches Design vermischt wurden.
Da der Saturn in Japan 12 Tage vor der PSX erschien, ist es auch schwer zu glauben, dass die PSX diese Auseinandersetzung beeinflusst hat.
Deshalb präsentierte jedes Unternehmen eine andere Lösung, jeweils mit eigenen Vor- und Nachteilen, aber alle sind interessant zu analysieren und zu vergleichen.
Genau deshalb wurde dieser Artikel geschrieben.
https://www.copetti.org/writings/consoles/playstation/
https://www.copetti.org/writings/consoles/nintendo-64/
Im Shoot-’em-up-Genre war der Saturn voll mit japanischen Shootern, und viele davon waren perfekte oder nahezu perfekte Arcade-Umsetzungen.
Die Sega Saturn hatte eine ziemlich komplexe Hardware-Architektur.
Ich verstehe, dass es aus Kosten-Nutzen-Sicht sinnvoll erscheinen kann, Spiel-„Aufgaben“ auf mehrere CPUs und dedizierte Prozessoren zu verteilen und so zu skalieren, aber das dürfte zu den vergleichsweise schwachen Verkaufszahlen der Saturn beigetragen haben.
Am Ende hieß es oft, für Firmen sei es schwer zu rechtfertigen gewesen, die nötigen Investitionen zu tätigen, um alles zu lernen und Spiele zu entwickeln, die die Hardware wirklich ausnutzen.
Mir kommt Sid Meiers Satz in den Sinn: „Nicht der Spieleentwickler soll Spaß haben, sondern der Spieler“; in diesem Fall hatten vielleicht die Hardware-Designer etwas zu viel Spaß.
Hier war der Mega Drive, also die Genesis, zwar nicht ganz so erfolgreich wie das SNES, aber fast, und alle hatten einen Mega Drive oder spielten regelmäßig bei Freunden damit.
Es war wirklich beliebte Hardware.
In der nächsten Generation hatten dann aber alle eine Playstation, und ich kannte genau ein Kind, das sich eine Saturn gekauft hatte.
Wenn man bedenkt, dass die Saturn hier ein paar Monate vor der Playstation erschien, ist das wirklich merkwürdig.
Ich weiß nicht, ob es daran lag, dass die Saturn damals wie die schlechtere Wahl wirkte, ob es Preis- oder Lieferprobleme gab oder ob andere Faktoren eine Rolle spielten, aber die Playstation dominierte völlig.
Danach verschwand Sega.
Die Saturn hatte unter den großen drei die höchsten Herstellungskosten, und dass Sega preislich mit der PlayStation mithalten musste, wurde für das Unternehmen zu einem finanziellen Desaster.
Wegen der Stelle „Daher wurde VDP1 so entworfen, dass es Vierecke als Grundform verwendet, und Modelle nur aus Polygonen mit vier Eckpunkten, also Sprites, aufgebaut werden können“ wirkten 3D-Spiele auf der Sega Saturn kantiger als ihre PS1-Pendants.
Wenn man die Saturn- und die PS1-Version von Resident Evil nebeneinander vergleicht, sieht man den Unterschied gut.
Insgesamt bekamen Sega-Saturn-Spiele dadurch eine eigene Ästhetik unter den 3D-Spielen der 90er.
Erwähnenswert ist auch, dass die Sega-Saturn-Emulation anderen Plattformen ziemlich hinterherhinkt.
Vermutlich kamen der geringe Erfolg im Westen und die komplexe Architektur zusammen.
Es stimmt aber, dass sie lange Zeit recht schwach war.
Titel, die man wirklich mag, kann man dann immer noch im Original bei eBay kaufen und so das Gefühl haben, sie zu unterstützen.
Jedes Mal mit Gummihandschuhen die CD aus der Plastikhülle zu nehmen und wieder einzulegen, nur um den Sammlerwert zu erhalten, ist mir zu umständlich; trotzdem möchte ich das Original-Spielerlebnis nicht durch Emulation ersetzen.
Auf der Sega Saturn gab es etliche versteckte Meisterwerke wie Panzer Dragoon Saga, Shining Force III, Burning Rangers und Dragon Force I & II, und soweit ich weiß, wurden sie weder portiert noch neu aufgelegt.
Natürlich darf man Saturn Bomberman nicht vergessen.
Die Saturn und ihr Nachfolger, die Dreamcast, waren ziemlich gut und hätten mehr Erfolg verdient gehabt.
Tatsächlich kenne ich nur Spiele, die sowohl auf Saturn als auch auf anderen Plattformen existieren, bei denen die Saturn-Version ein Port war, aber keine Portierungen in die Gegenrichtung.
Wenn ich mich irre, kann mich sicher jemand korrigieren.
Soweit ich es verstehe, ist auch die Saturn-Emulation bis heute eher schwierig, auch wenn es in den letzten zehn Jahren erhebliche Fortschritte gab.
Mein Lieblingsvideo zur technischen Analyse bzw. zum Hacking der Saturn ist dieses:
https://www.youtube.com/watch?v=jOyfZex7B3E
Die Vielfalt der Konsolen erinnerte mich an die Vielfalt aus der Zeit, als der Ruhm der Heimcomputer verblasste, bevor der PC dominierte.
Einige derselben OEMs und Publisher haben bis heute überlebt.
Ich würde das gern als Infografik sehen, und vielleicht bekomme ich sogar Lust, sie selbst zu erstellen.
Ich mag Copettis Arbeit und habe sie früher auch zitiert, aber sie wirkt auf mich immer etwas zu high-level.
Trotzdem fühlt es sich immer unfair an, mehr zu verlangen, weil ich weiß, wie viel Arbeit in solchen Texten steckt.
Am Ende haben Marketing und Sonys Finanzkraft SEGA geschlagen. Das war wirklich alles.
Natürlich hat SEGA auch viele beinahe selbstzerstörerische Fehler gemacht.
Wenn man auf die Spiele schaut: Welche PSX-Spiele haben die Welt wirklich erschüttert? Resident Evil 1996 und FFVII 1997?
Auch die Saturn hatte Killer-Games, besonders 1996; persönlich glaube ich also nicht, dass es an der Bibliothek lag.
Dass sie schwer zu programmieren war, ebenfalls nicht: Eine Generation später kamen Entwickler gut mit der Playstation 2 zurecht, und die Dreamcast war leicht auszunutzen, wurde aber von allen fallen gelassen, als SEGA sie einstellte.
In den USA war die Nutzerbasis auch in Ordnung; bei Europa weiß ich es nicht.
Es gab zwar ein Problem mit der Verbraucher-Sympathie für SEGA, aber wenn man die Zuverlässigkeitsprobleme der Systeme von Sony und MS betrachtet, passt auch das nicht ganz.
Besonders die 360 war ziemlich schlimm, aber dem langfristigen Überleben der Konsole schadete das überhaupt nicht.
Die SEGA CD war zumindest in den USA kein Flop.
Sie war immer ein hochwertiges und etwas unnötiges, aber cooles Produkt, hatte auch hervorragende Spiele, nur keine Killer-App.
Für SEGA war sie erfolgreich.
Der 32X war zwar tatsächlich ein riesiger Fehltritt für alle Beteiligten, aber ich glaube nicht, dass seine kurze Existenz auf Massenkundenebene die Saturn allein ruiniert hat.
In den USA kaufen die Leute meiner Meinung nach alles, wenn das Marketing stimmt.
Das US-Marketing der Saturn war miserabel.
SEGA bekam die Kurve nicht und warf alles über Bord, was die Genesis erfolgreicher gemacht hatte als das SNES.
Man kann über Technik und Details reden, darüber, was bei der Konsole gut und schlecht lief, aber tatsächlich haben Marketingversagen und das Fehlen eines richtigen Sonic zum Launch und auch danach die Saturn ruiniert.
1997 war mit FF7, FF Tactics, Tekken 3, Symphony of the Night usw. ein großartiges Jahr.
Gute Analyse. Ich habe meinen ursprünglichen Sega Saturn, den ich seit 1996 besitze, immer noch und schalte ihn gelegentlich ein, um eine ordentliche Nostalgie-Bombe abzubekommen.
Er läuft heute noch genauso perfekt wie am Tag des Unboxings.
Die Hardware-Architektur mag ziemlich kompliziert geworden sein, aber die Zuverlässigkeit alter Konsolen muss man einfach mögen.
Über modernere Konsolen, die ich in den letzten Jahren genutzt habe, kann ich das kaum sagen: Sie sind überhitzt oder auf andere Weise kaputtgegangen.
Mit dem Einstieg von Sony und MS begann bei der Zuverlässigkeit von Konsolen bereits die Kostensenkung, und so sind wir dort gelandet, wo wir heute stehen.
Disc-Lesefehler bei der PSX und der Playstation 2 waren damals sehr häufig und gravierend.
Aber als die Leute es bemerkten, hatten sie schon jede Menge Spiele und kauften einfach eine neue Konsole.
Wenn wir schon bei seltsamen Sega-Architekturen sind: MattKC hat vor Kurzem auf seinem zweiten Kanal auch ein Video zum 32X veröffentlicht.
Falls du den 32X nicht kennst: Das war ein merkwürdiges Modul, das man in den Cartridge-Slot des Genesis steckte, um eine separate Reihe von 32-Bit-Spielen auszuführen.
Im Grunde arbeiteten dabei zwei Konsolen zusammen, also eine weitere Situation, in der zwei CPUs kooperierten, um die Videoausgabe zu erzeugen.
Beim direkten Anschließen der Videokabel fand er heraus, dass man, wenn man das Videosignal eines der Geräte kappt, nur die von der anderen Seite gerenderte Ausgabe erhält.
Der 32X selbst gab 3D-Rendering aus, während der Genesis 2D-Grafiken wie Menüs, HUD und Sprites lieferte.
https://www.youtube.com/watch?v=rl9fjoolS2s