PlayStation-Architektur
(copetti.org)- Die PlayStation-Architektur setzte auf einen einfachen und praktischen Aufbau, um die Komplexität der 3D-Hardwareentwicklung zu verringern, hinterließ dadurch aber zusätzlichen Aufwand für Entwickler sowie visuelle Grenzen bei Grafiksortierung, Texturkorrektur und Präzision
- Der Sony CXD8530BQ ist ein SoC, das einen MIPS-R3000A-kompatiblen Core auf Basis von LSIs CoreWare sowie CP0, GTE und MDEC integriert, mit 33,87 MHz arbeitet und den Datentransfer rund um 2 MB RAM, 1 KB Scratchpad und DMA organisiert
- Bei der Grafik übernimmt die GTE 3D-Projektion, Beleuchtung und Clipping, während die GPU auf Befehlsbasis Linien, Rechtecke und Dreiecke rendert; statt eines Z-Buffers wird eine Ordering Table verwendet, sodass die CPU die Polygonreihenfolge festlegen muss
- Die GPU verursacht wegen affine texture mapping, nearest neighbour, ganzzahligen Koordinaten und fehlender Subpixel-Auflösung Zittern, Überlappungen und Texture Warping; als Umgehungslösungen wurden Tessellation, Ersatz durch Vollfarben und vorgerenderte Hintergründe genutzt
- Das auf CD-ROM basierende Design veränderte mit 620 MB Speicherplatz, 44,1-kHz-ADPCM-Audiostreaming, einer BIOS-basierten Laufzeitumgebung sowie dem Kopierschutz Wobble Groove samt Region-Lock die Entwicklung und Distribution von Spielen
Grunddesign und CPU
- Die PlayStation war auf ein einfaches und praktisches Design ausgerichtet, ausgehend von der Annahme, dass 3D-Hardware in der Entwicklung schnell zu komplex werden kann, und nahm dafür gewisse Einschränkungen in Kauf
- Der Hauptchip Sony CXD8530BQ entspricht in heutiger Terminologie einem SoC und nutzt einen CPU-Core auf Basis von LSIs CoreWare, der zur MIPS-R3000A-Familie und auf Binärebene kompatibel ist
- Der CPU-Core bietet 33,87 MHz, MIPS I ISA, 32-Bit-Wörter, 32 allgemeine Register, einen 32-Bit-Datenbus, einen 32-Bit-Adressbus, eine 5-stufige Pipeline und 4 KB Instruktionscache
- Einen Datencache gibt es nicht; stattdessen wird der ursprünglich dafür vorgesehene 1-KB-Speicher als auf feste Adressen gemapptes Scratchpad bereitgestellt und wie schnelles SRAM verwendet
- Das System bietet 2 MB EDO RAM für allgemeine Aufgaben; EDO RAM wird als Chip beschrieben, der gegenüber normalem DRAM etwas effizienter arbeitet und geringere Latenzen bietet
Busse und Coprozessoren
- Der Datenbus ist in einen 32-Bit-Main Bus und einen 16/8-Bit-Sub Bus aufgeteilt; der Main Bus verbindet MDEC und GPU, der Sub Bus die übrigen Komponenten und I/O
- CD-ROM controller, MDEC, GPU, SPU und der Parallel Port können auf den DMA controller zugreifen; DMA übernimmt den Main Bus ohne Beteiligung der CPU und überträgt Daten mit hoher Bandbreite
- Während DMA aktiv ist, kann die CPU nicht auf den Main Bus zugreifen; wenn im Scratchpad keine zu bearbeitenden Aufgaben vorliegen, wartet sie entsprechend
- CP0, der System Control Coprocessor, verwaltet Cache-Implementierung, direkten Scratchpad-Zugriff, Instruktionscache-Isolierung, Interrupts, Ausnahmen und Breakpoints
- CP2, die Geometry Transformation Engine, beschleunigt festkomma-basierte Vektor- und Matrixberechnungen und übernimmt frühe Schritte der Grafikpipeline wie 3D-Projektion, Beleuchtung und Clipping
- MDEC dekomprimiert ähnlich wie JPEG codierte Macroblocks in ein Format, das die GPU versteht, und kann 9.000 Macroblocks mit 8×8 Pixeln bei 24 bpp pro Sekunde verarbeiten, wodurch sich 320×240px-FMV mit 30 fps streamen lässt
- Eine FPU als CP1 gibt es nicht; Fließkommaberechnungen können per Software oder Festkomma umgesetzt werden, was aber bei Geschwindigkeit und Präzision Einschränkungen mit sich bringt
Pipeline und Delay Slots
- Die MIPS-I-Pipeline ist anfällig für control hazards und data hazards und besitzt das Verhalten eines branch delay slot, bei dem die Instruktion nach einem branch oder jump in jedem Fall ausgeführt wird
- Load-Instruktionen halten die Pipeline nicht an, bis die geladenen Daten bereitstehen; wenn die direkt folgende Instruktion vom Ergebnis des vorherigen load abhängt, ist daher ein Filler nötig, um den korrekten Operanden zu erhalten
- Einige Delay Slots können mit sinnvollen Instruktionen gefüllt werden und sind daher nicht immer verlorene Taktzyklen
- MIPS entschied sich auf Basis der RISC-Philosophie dafür, die CPU-Pipeline für Entwickler und Toolchain sichtbar zu machen, in der Annahme, dass hochwertige Compiler und Assembler das Umordnen von Instruktionen oder das Einfügen von Fillern übernehmen
- Dieses Design hat auch den Nachteil, dass mit dem Auftreten neuer Mikroarchitekturen in nachfolgenden CPU-Generationen die Abwärtskompatibilität schwieriger wird
Grafikpipeline
- Ein großer Teil der Grafikpipeline wird von der GTE verarbeitet; die Ergebnisdaten werden anschließend an Sonys proprietäre GPU zur Darstellung übergeben
- Das System speichert Frame Buffer, Texturen und andere Rendering-Ressourcen in 1 MB VRAM, den die CPU per DMA befüllen kann
- Im VRAM früher Modelle kam eine Dual-Port-Struktur mit zwei 16-Bit-Bussen zum Einsatz, sodass CPU, DMA, GPU und Videoencoder gleichzeitig zugreifen konnten
- Spätere Modelle wechselten zu SGRAM mit einem einzelnen 32-Bit-Datenbus; wegen abweichender Timings können spätere Spiele wie Jet Moto 3 auf VRAM-basierten Systemen Grafikfehler zeigen
- Die CPU kann bis zu drei Befehle in den 64-Byte-FIFO-Puffer der GPU schreiben, um Geometriedaten zu senden; die Befehle fordern Rendering, Konfigurationsänderungen oder VRAM-Operationen an
- Die GPU kann Linien, Rechtecke und Dreiecke einzeln zeichnen; Dreiecke dienen dabei als grundlegende Bausteine für komplexe 3D-Modelle
- Das Koordinatensystem der GPU ist ein Modell mit ganzzahligen Koordinaten, bei dem jede Koordinate dem Sampling-Punkt im Pixelzentrum entspricht; fractional coordinates werden nicht verwendet
Sichtbarkeit, Rasterisierung und Texturen
- Die PlayStation-GPU bietet keine hardwareseitige Sichtbarkeitslösung; über eine ordering table werden stattdessen GPU-Command-Adressen nach Tiefenwert verwaltet
- Die CPU sortiert die Polygone vorab, trägt Referenzen in die passenden Einträge der Tabelle ein und sendet die Tabelle dann per DMA an die GPU, damit in der richtigen Reihenfolge gerendert wird
- Die GPU benötigt nur einen einzelnen Frame Buffer, während der Rasteriser Vertices in Linien, Dreiecke, Rechtecke und Pixel umwandelt
- Dreiecke sind die komplexesten und universellsten Primitives mit Unterstützung für Texturen und Shading; Linien sind schnell, aber ungeeignet für texturierte Oberflächen, und Rechtecke sind auf Sprites bis 256×256 Pixel beschränkt und bieten weder Shading noch affine Transformationseffekte
- Für Lichteffekte gibt es flat shading und Gouraud shading; flat shading kann pro Sekunde etwa 2,5-mal so viele Polygone füllen wie Gouraud shading
- Texturen werden per inverse texture mapping angewendet, bei dem für jedes rasterisierte Pixel der passende Texel aus der Texture Map ermittelt wird
- Das Affine Texture Mapping der PlayStation-GPU verwendet nur 2D-Koordinaten in X/Y und verwirft die Tiefe, weshalb keine Perspektivkorrektur erfolgt
- Texture Filtering ist nicht implementiert; zur Skalierungskorrektur kommt nearest neighbour zum Einsatz, was schnell und günstig ist, Texturen aber blockig wirken lässt
- Die GPU unterstützt für Dreiecke semi-transparency und dithering; in diesen Effekten gilt die PlayStation als besonders stark
VRAM-Nutzung und visuelle Grenzen
- Die Idee, die gesamten 1 MB VRAM großflächig für den Frame Buffer zu verwenden, erfordert eine Anpassung an TV-Standardformate und verringert den Platz für Texturen und Colour Tables; zudem kann die GPU selbst höchstens einen 640×480-Pixel-Frame-Buffer mit 16-Bit-Farben rendern
- Ein 640×480-16-Bit-Buffer lässt 424 KB VRAM für Assets übrig, bringt auf damaligen Heimfernsehern aber keinen besonders deutlichen Vorteil durch die höhere Auflösung
- Ein adjustable frame-buffer vermeidet es, VRAM für eine subjektiv wenig wahrnehmbare Auflösung zu verschwenden, indem die Größe des Frame Buffers reduziert und mehr Platz für Texturen und Colour Lookup Tables geschaffen wird
- Halkuns Demo Gears Episode 2 zeigt eine Konfiguration, bei der ein 640×480-Frame-Buffer in zwei 320×480-Buffer aufgeteilt und page flipping genutzt wird, um während der Anzeige einer Szene die andere zu rendern
- Dieses Layout belegt nur 600 KB VRAM, sodass die verbleibenden 424 KB für Colour Lookup Tables und Texturen genutzt werden können, und bildet zusammen mit dem 2-KB-Texture-Cache eine effiziente Konfiguration
- VRAM kann mehrere Farbtiefen gleichzeitig abbilden, sodass neben einem 16-bpp-Frame-Buffer auch ein 24-bpp-Bitmap platziert werden kann, wie es oft für FMV-Frames verwendet wird
- Da der Rasteriser nur auf Pixelebene arbeitet und nicht verfolgt, welchen Anteil eines Pixels ein Dreieck tatsächlich bedeckt, kann es zu springenden Modellkonturen sowie Flackern und Überlappungen an Dreiecksübergängen kommen
- Die ordering table überträgt die Last, zu bestimmen, welche Geometrie vorne liegt, an Entwickler oder Programme; wenn zur Leistungssteigerung zu stark angenähert wird, kann das zu Flackern oder Problemen mit verdeckten Flächen führen
- Die affine Transformation vermittelt kein Tiefengefühl und kann texture warping erzeugen, wenn die Kamera nah am Modell und senkrecht zur Blickrichtung steht; manche Spiele reduzierten die Verzerrung durch Tessellation oder den Ersatz durch Vollfarben
- Vorgerenderte Hintergründe wurden eingesetzt, wenn realistischere Szenen nötig waren, als die GPU in Echtzeit darstellen konnte; dabei wurde ein per MDEC gestreamtes Bild auf zwei Dreiecke gelegt
Audio und CD-basierte Spiele
- Die SPU unterstützt 24 Kanäle mit 16-Bit-ADPCM-Samples in Audio-CD-Qualität bei 44,1 kHz
- Die SPU bietet pitch modulation, frequency modulation, ADSR envelope, looping und digitalen Reverb
- Der Audiopuffer Sound RAM besteht aus 512 KB DRAM; Spiele können davon nur 508 KB zur Speicherung von Samples verwenden, und bei aktiviertem Reverb sinkt die verfügbare Kapazität weiter
- Der CD controller kann Samples ohne Audiopuffer oder CPU-Beteiligung direkt an den Audio-Mixer senden; mit XA encoding komprimierte Samples kann die SPU in Echtzeit dekodieren
- Das CD-ROM-Medium bot PS1-Spielen 620 MB Speicherplatz, hohe Audioqualität und die vergleichsweise schnelle Lesegeschwindigkeit eines 2x-Laufwerks
- Von den bis 1997 erschienenen PS1-Revisionen ist bekannt, dass ihre fehleranfälligen CD-Laser häufig zu Aussetzern bei FMV und Audio-CDs führten; spätere Modelle verbesserten Lasereinheit und Gehäuse, um das Problem zu mindern
I/O, BIOS und Entwicklungsumgebung
- Frühe PlayStation-Modelle besaßen Serial- und Parallel-I/O-Ports für Add-ons, die in späteren Revisionen wegen geringer Verbreitung und Sorgen um die Umgehung des Kopierschutzes entfernt wurden
- Das CD-Subsystem besteht aus einem DSP zur Steuerung von Motor, Laser und RF-Signalen, einer Sub-CPU mit Motorola 68HC05 microcontroller sowie 512 B RAM und 16 KB ROM, einem CD Controller als Vermittler zwischen Haupt-CPU und CD-Subsystem und einem 32-KB-SRAM-Puffer
- Das ROM-Programm der Sub-CPU implementiert die Kopierschutzprozedur und erzwingt sie unabhängig vom Willen der Haupt-CPU
- An der Vorderseite befinden sich vier Buchsen für zwei Controller und zwei Memory Cards; alle vier Slots sind elektrisch identisch und ihre Adressen fest verdrahtet
- Das System speichert das BIOS in 512 KB ROM; das BIOS stellt Startvorgang, User Shell und I/O-Routinen bereit
- Der Zugriff auf das BIOS-ROM ist wegen des 8-Bit-Datenbusses sehr langsam; daher wird die API als Kernel bereitgestellt, der beim Booten in den Hauptspeicher kopiert wird, wobei 64 KB des Main RAM für das PlayStation-OS reserviert sind
- Der Bootvorgang läuft in der Reihenfolge BIOS-ROM-Ausführung, Laden des PlayStation-OS, Anzeige des Splash-Screens, Prüfung der Echtheit der CD, Prüfung und Ausführung von
SYSTEM.CNFoder Anzeige der Shell ab - Die Shell ist eine einfache grafische Oberfläche zum Kopieren und Löschen von Spielständen auf der Memory Card sowie zum Abspielen von Audio-CDs
- Sonys SDK enthielt einen C-Compiler und Bibliotheken; die Bibliotheken binden sich für den Hardwarezugriff an BIOS-Routinen an
- Das DTL-H2000 für Studios ist eine ISA-Karte mit zwei Steckplätzen, die die PS1-Innereien sowie I/O- und Debugging-Schaltungen enthält, und benötigt Software, die auf einem PC mit Windows 3.1 oder 95 läuft
- Das Net Yaroze für Hobbyisten lieferte Toolkit, Handbuch und eine schwarze PS1-Konsole, hatte aber die Einschränkung, dass ohne Zugriff auf das CD-Laufwerk die gesamte Homebrew-Software in den Main RAM passen musste
Kopierschutz und Region-Lock
- Sonys Kopierschutz funktioniert so, dass die Sub-CPU prüft, ob das Inhaltsverzeichnis der CD einen mit einer bestimmten Frequenz geprägten Wobble Groove besitzt
- Wobble Groove wird während des Mastering-Prozesses eingebracht, lässt sich mit normalen CD-Brennern nicht kopieren, und das Inhaltsverzeichnis liegt im Lead-In-Bereich der CD und wird zur Fehlertoleranz mehrfach wiederholt
- Das Inhaltsverzeichnis eines Spiels enthält einen der Strings SCEA, SCEE oder SCEI; dieses Verfahren wird auch für den Region-Lock genutzt
- Die Prüfung erfolgt nur einmal beim Start, sodass sie mit dem sogenannten Swap Trick umgangen werden kann, indem die Disc direkt nach der Authentifizierung manuell gewechselt wird, was allerdings das Laufwerk beschädigen kann
- Einige Spiele versuchten, den Swap Trick zu verhindern, indem sie das Laufwerk während des Spielens erneut initialisierten und die Prüfung wiederholten
- Ein Modchip ist eine kleine Platine, die so programmiert wurde, dass sie das Wobble-Groove-Signal imitiert; sie wurde in die Konsole eingelötet, war rechtlich umstritten, aber äußerst beliebt
- Spätere Spiele ergänzten als Reaktion auf die Verbreitung von Modchips, CD-Brennern und Emulatoren eigene Schutzmechanismen auf Basis von Checksums
- Libcrypt von Sony kombiniert einen hardwareseitigen Ansatz, bei dem bestimmte Sektor-Checksummen im Sub-Channel der Disc gespeichert werden, mit softwareseitigen Routinen im Spiel, die diese Checksummen an vielen Stellen abrufen, mit anderen Werten mischen und verifizieren
1 Kommentare
Hacker-News-Kommentare
Es gibt Speicherbereiche, die auf denselben physischen Speicher gemappt sind — https://psx-spx.consoledev.net/memorymap/
Als wir Metal Gear Solid auf den PC portiert haben, nutzten die Konami-Programmierer einen ziemlich radikalen Trick, um zu speichern, ob C4-Sprengstoff an einer Wand oder auf dem Boden platziert war.
Im Wesentlichen zeigte der Pointer auf dieselbe physische Speicheradresse, aber je nachdem, ob es an der Wand oder auf dem Boden angebracht war, wurde wohl etwas wie
80000000hper OR verknüpft oderA0000000hverwendet. Das ist lange her, daher erinnere ich mich nicht mehr genau, was sie gemacht haben, aber der Port auf den PC war interessant.Im BIOS-Code gibt es einen fehlerhaften Array-Iterator, mit dem sich beliebige Daten an eine höhere Position im Memory-Map relativ zu einem Basis-Pointer kopieren lassen. Normalerweise liegt dieser Basis-Pointer so weit oben, dass sich kein ausführbarer Code überschreiben lässt, aber durch Memory-Aliasing kann man die Werte passend setzen, sodass der Schreibzugriff „herumwickelt“ wird und das BIOS überschreibt.
Dadurch kann man faktisch schon beim Betreten des Memory-Card-Bildschirms ein Custom-BIOS booten und von dort PSX.EXE ausführen, ohne die mechacon-Prüfung zu durchlaufen, wodurch sich der Kopierschutz umgehen lässt.
Ich würde auch gern mehr über den MGS-Port hören. Falls du dich an etwas erinnerst, wäre das spannend. Soweit ich weiß, wurde für den Großteil des Scriptings TCL verwendet, und ich glaube, MGS 1 bis 4 nutzten Skriptsprachen derselben Linie.
Kürzlich ist der MGS2-Quellcode geleakt, aber vermutlich wurde dort fast alles neu geschrieben, sodass wahrscheinlich kaum etwas mit der PSX-Codebasis gemeinsam war.
Die PS1 hatte außerdem nicht genug RAM, um das gesamte Decoding-Fenster des RAM abzudecken, weshalb RAM-Aliasing entstand. Ich kenne den genauen Mechanismus nicht, aber ich habe schon gesehen, dass ein PS1-Executable den Stack-Pointer auf das Ende des 8-MiB-RAMs im Devkit setzt und er auf Retail-Geräten trotzdem effektiv am Ende des 2-MiB-RAMs landet und normal funktioniert. Theoretisch könnte man dort ebenfalls Bits unterbringen, ohne Speicherbereiche mit anderem Cache-Verhalten zu berühren.
https://github.com/FoxdieTeam/mgs_reversing/blob/master/sour...
https://en.wikipedia.org/wiki/Classic_Mac_OS_memory_manageme...
Dadurch gab es bei einigen Modellen einen Abwärtskompatibilitätsmodus, der sich nicht stark vom A20-Gate beim PC unterschied, aber diese Phase war kurz.
Es gibt Arm Top Byte Ignore (TBI), Intel Linear-Address Masking (LAM) und die überarbeitete Variante Linear Address Space Separation (LASS) sowie AMD Upper Address Ignore (UAI); UAI ist allerdings noch nicht gegen SLAM-Angriffe abgesichert. Darüber hinaus gibt es Sicherheits-Erweiterungen wie ARM Memory Tagging Extension (MTE).
Großartiger Artikel, aber ursprünglich wurde er schon 2019 veröffentlicht. Frühere Diskussionen dazu gab es 2020 unter https://news.ycombinator.com/item?id=22932134 und 2021 unter https://news.ycombinator.com/item?id=27576902, jeweils mit 114 Kommentaren.
Eine wirklich wunderschön gestaltete Website. Alles ist mit viel Bedacht angeordnet und wirkt wie ein gutes Beispiel für einen sorgfältig kuratierten digitalen Garten. Sie wirkt gepflegt und deutlich von Menschenhand gemacht.
Ich arbeite gerade an einem PS1-bezogenen Projekt und wollte diesen Artikel posten, weil ich es bald veröffentlichen möchte.
Mich würde interessieren, ob jemand einen PS1-Web-/JS-/WASM-Emulator empfehlen kann. Auf dem Desktop waren PCSX-Redux [0] und DuckStation [1] gut.
Ich habe ein paar JS-/emscripten-basierte Versuche gefunden, wäre aber für Empfehlungen dankbar.
[0] https://github.com/grumpycoders/pcsx-redux/
[1] https://duckstation.org/
Die PS1 war für mich die Architektur, durch die ich RISC, oder genauer gesagt eine Load-Store-Architektur, schätzen gelernt habe und verstanden habe, dass ich bei x86 einiges falsch gedacht hatte.
Die PS1-Architektur ist faszinierend. Sie zeigt auch, warum PS1-Spiele einen so unverwechselbaren und bis heute oft nachgeahmten Stil bekommen haben.
Ich mag die Artikel von Copetti. Ich verstehe nicht unbedingt alles, was behandelt wird, aber schon das Durchlesen der Texte und Diagramme macht Spaß.
Besonders reizvoll ist der Versuch zu verstehen, was im Inneren von Maschinen wie Konsolen der 5. und 6. Generation eigentlich vor sich geht.
https://fabiensanglard.net/
Noch besser, weil es vor Claude geschrieben wurde
Dass Befehle nach einem Sprung ausgeführt werden, wirkte anfangs völlig verrückt, aber nach ein paar Tagen fühlte es sich ganz natürlich an. Auf dem N64 gab es ein ähnliches Problem, bei dem man einen Befehl zwischen zwei Multiplikationen finden musste
Wenn die erste Multiplikation etwa mit 0 multiplizierte und dadurch nach zwei Zyklen fertig war, hielt die CPU an, wenn auch der nächste Befehl eine Multiplikation war
Wenn also eine Exception auftrat, musste der Kernel-Interrupt-Handler prüfen, ob der nächste Befehl COP2 war, und den Programmzähler um 4 erhöhen, damit er nicht zweimal ausgeführt wurde
Außerdem konnten COP2-Befehle nicht in einen Branch-Delay-Slot gesetzt werden, vermutlich aus einem ähnlichen Grund. Allerdings taten das einige Spiele, wenn ich mich richtig erinnere tatsächlich Tekken 3. Mehrere Emulatoren hatten an dieser Stelle Probleme oder brauchten Sonderbehandlung, deshalb habe ich mich immer gefragt, ob das ein heimlich eingebauter Emulator-Schutz war
Diese Artikelserie ist immer hervorragend
PS1-Spiele sind nach heutigen Maßstäben nicht besonders gut gealtert, aber wenn man PS2-Spiele auf 1440p~4K hochskaliert, wirken sie fast perfekt
Sicher spielt Nostalgie eine große Rolle, aber der Stil hat eindeutig seinen Reiz, und seit ich die besonderen Hardware-Beschränkungen der PS1 kenne, gefällt sie mir mit der Zeit immer besser. Schon ein Blick in Social-Media-Feeds zeigt, dass „PS1-Grafik“ gerade eine kleine Renaissance erlebt und viele versuchen, dieses Gefühl nachzubilden
Spielerisch betrachtet hat diese Konsole eine riesige Bibliothek mit tausenden kommerziell veröffentlichten Spielen und vielen Geheimtipps. Ich wäre eher überrascht, wenn ein Gamer in dieser Liste nicht ein einziges Spiel finden würde, das zum eigenen Geschmack passt