Architecture de la Sega Saturn – analyse pratique (2021)
(copetti.org)- La Sega Saturn est une console sortie pendant la transition vers la 3D, mais au lieu d’un accélérateur 3D unique, elle a été conçue autour d’une architecture parallèle combinant deux CPU SH-2, le SCU, les VDP1·VDP2, ainsi que des sous-systèmes audio et CD indépendants
- Les CPU consistaient en deux Hitachi SH-2 à environ 28,63 MHz en configuration maître-esclave, mais comme ils partageaient le bus externe, les performances n’étaient pas simplement doublées et le développement était plus difficile
- Côté graphismes, le VDP1 dessine dans le frame buffer des sprites basés sur des quadrilatères, tandis que le VDP2 se charge de la composition des arrière-plans, plans et layers : la machine était donc solide en 2D, mais plus limitée en 3D, notamment pour la détermination des surfaces visibles et la gestion de la semi-transparence
- L’audio reposait sur un SCSP/Yamaha YMF292, un Motorola 68EC000 et 512 KB de RAM audio, formant presque un ordinateur séparé, et le CD-ROM permettait d’exploiter des échantillons PCM ainsi que des bandes-son de haute qualité basées sur le CD-DA
- Pour lutter contre la copie des CD, Sega utilisait un anneau hors de la zone CD standard et une vérification SH-1 intégrée au lecteur CD, mais des méthodes de contournement et d’exécution homebrew comme les mod chips, le swap trick, PseudoSaturn, Satiator et les ODE sont apparues par la suite
Une conception de console complexe à l’ère de la transition 3D
- Après la Mega Drive, la Sega Saturn n’a pas été pensée pour imposer uniquement la 3D, mais comme une console combinant plusieurs éléments matériels afin de prendre en charge le rendu de polygones quand nécessaire
- L’ensemble du circuit est divisé entre plusieurs processeurs et quatre sous-systèmes principaux
- Sous-système CPU : contient les CPU principaux, la mémoire et le SCU
- Sous-système vidéo : contient les accélérateurs graphiques
- Sous-système audio : dispose d’une structure de traitement sonore proche d’un ordinateur séparé
- Sous-système CD-ROM : adopte une structure fermée à cause du mécanisme anti-copie
- Chaque sous-système est relié à son propre bus, tandis que les sous-systèmes vidéo et audio partagent un même bus
CPU : deux SH-2 et le SCU
- Sega a choisi la famille de CPU SuperH de Hitachi pour les jeux de nouvelle génération et les fonctions 3D
- SuperH était à l’origine pensé pour l’embarqué, mais il intégrait déjà des éléments de conception de type RISC à l’époque
- architecture load-store, séparant les opérations mémoire des opérations sur registres
- bus de données 32 bits et ALU 32 bits
- 16 registres généraux de 32 bits
- bus d’adresses 32 bits permettant d’adresser jusqu’à 4 GB de mémoire
- pipeline à 5 étages traitant plusieurs instructions par étapes
- les premiers SuperH intégraient une unité de multiplication 16 bits
- L’ISA SuperH relève d’une conception RISC, mais toutes les instructions ont une largeur de 16 bits
- le CPU allant chercher les instructions par mots de 32 bits, il peut récupérer deux instructions par cycle
- cette approche atténue le problème de densité de code propre aux architectures RISC
- Certaines contraintes typiques des conceptions RISC restent présentes
- à cause des hazards de contrôle, les programmes doivent tenir compte du branch delay slot
- SuperH fournit des delayed branch instructions avec delay slot intégré
- pour les hazards de données, le CPU interrompt automatiquement le pipeline lorsque nécessaire
Le choix du SH-2 et l’architecture à double CPU
- Sega estimait que le multiplicateur 16 bits risquait de devenir un goulot d’étranglement pour le traitement massif de données dans les jeux 3D, et a demandé à Hitachi de l’améliorer
- Hitachi a étendu l’unité de multiplication et créé le SH-2 en intégrant les exigences de Sega
- Soucieuse du choix de CPU des consoles concurrentes, Sega voulait aussi augmenter la fréquence, mais il était impossible de relever l’horloge sur une puce déjà au stade de fabrication
- Hitachi avait ajouté un minimum de logique dès la phase de recherche sur SH afin que plusieurs SH puissent fonctionner simultanément dans un même système, et Sega a retenu une configuration à deux puces pour la Saturn
- La configuration CPU finale portait donc à la fois un potentiel de parallélisme et des goulots d’étranglement
- deux Hitachi SH-2 fonctionnant chacun à environ 28,63 MHz
- les deux CPU sont physiquement identiques mais organisés en mode maître-esclave
- le CPU maître peut envoyer des instructions au CPU esclave
- comme ils partagent le même bus externe, une congestion du bus peut se produire
- La puce SH7604 inclut des fonctions destinées à renforcer les performances d’exécution
- pipeline à 5 étages et ISA SuperH étendue
- unité de multiplication 32 bits
- bus de données externe partagé de 32 bits
- cache de 4 KB
- unité de division 32 bits
- contrôleur DMA interne
- prise en charge du little endian
- Avoir deux CPU ne signifie pas que les jeux tournent deux fois plus vite : pour exploiter efficacement le parallélisme, il fallait une programmation complexe tenant compte du bus partagé et de l’usage du cache
Mémoire et SCU
- Le sous-système CPU dispose de 2 MB de Work RAM à usage général
- La Work RAM est divisée en deux blocs
- WRAM-H : 1 MB de SDRAM, avec un accès plus rapide, mais un bus partagé avec d’autres composants
- WRAM-L : 1 MB de DRAM, plus lente, mais dont le bus est réservé au CPU principal
- En plus des deux SH-2, le groupe CPU comprend aussi le Saturn Control Unit (SCU)
- Le SCU se compose de deux modules chargés des transferts de données et de l’assistance au calcul
- Contrôleur DMA : arbitre les accès à la WRAM-L entre trois sous-systèmes sans intervention du CPU
- DSP : utilisé comme une unité géométrique en virgule fixe, il exécute plus vite que les SH-2 les calculs de matrices et de vecteurs liés à la transformation 3D et à l’éclairage
- Le DSP du SCU fonctionne à demi-vitesse, possède un jeu d’instructions plus complexe et utilise la WRAM-L plus lente ainsi que le DMA pour les opérations de fetch et de store
- Le SCU comprend aussi 32 KB de SRAM pour son usage local
Architecture graphique : VDP1 et VDP2
- La Saturn utilise deux GPU propriétaires aux rôles distincts, VDP1 et VDP2, qui travaillent en parallèle
- Dans les conceptions graphiques de la génération 3D, le frame buffer devient essentiel
- le GPU dessine d’abord un bitmap de la scène dans une partie de la VRAM, puis l’encodeur vidéo l’affiche
- la taille du frame buffer est proportionnelle à la résolution d’écran et à la profondeur de couleur
- par exemple, 600 KB de VRAM peuvent contenir un frame buffer 640×480, 32K couleurs, 16bpp
- Sur Saturn, l’accélération des opérations vectorielles n’est pas assurée par les SH-2 eux-mêmes mais par le SCU
VDP1 : sprites à base de quadrilatères et frame buffer
- Le VDP1 dessine des sprites avec transformations géométriques, enregistre le résultat dans le frame buffer, puis le transmet au VDP2 pour l’affichage
- Sa programmation repose sur l’émission de drawing commands
- il utilise 512 KB de RAM dédiée pour stocker commandes, textures·tiles, tables de correspondance de couleurs, etc.
- La forme de base est uniquement le quadrilatère
- les modèles sont composés de polygones à quatre sommets, autrement dit de sprites
- le Forward Texture Mapping associe les points de texture au quadrilatère
- l’absence de filtrage et d’interpolation entraîne de l’aliasing au rendu
- Les effets proposés incluent le flat shading, le Gouraud shading, l’anti-aliasing, le clipping et la transparency
- Deux puces de frame buffer de 256 KB sont utilisées pour dessiner la scène suivante dans un buffer pendant que l’autre est affiché
- une fois le rendu du second buffer terminé, l’affichage bascule via page flipping
VDP2 : plans d’arrière-plan, composition de layers et correction de perspective
- Le VDP2 est spécialisé dans le rendu de grands plans allant jusqu’à 4096×4096 pixels, avec rotation, mise à l’échelle et déplacement
- Il effectue le rendu on the fly, sans frame buffer, au rythme du balayage CRT
- Il prend en charge une couleur 24 bits allant jusqu’à 16,7 millions de couleurs
- Il peut aussi afficher le buffer de sortie du VDP1 et le transformer ou le mélanger avec ses propres layers
- La composition d’une frame se fait selon l’un des deux choix suivants
- jusqu’à quatre plans 2D et un plan 3D
- ou deux plans 3D
- Le VDP2 construit les plans à l’aide de tile-maps et applique une perspective correction au texture mapping 3D
- Les effets pris en charge incluent le multi-texturing et le shadowing
- il peut réduire la luminosité des sprites reçus du VDP1 et les mélanger en semi-transparence
- mais comme il ne reçoit qu’un flux de sprites synchronisé sur la vitesse du faisceau CRT, l’encodage et l’exploitation restent délicats
- Le VDP2 inclut 4 KB de CRAM pour convertir en RGB 24 bits les valeurs de couleur indexée du VDP1
- Le nombre de plans 3D est limité à deux, mais le CPU peut utiliser la VRAM du VDP2 comme un frame buffer logiciel pour dessiner des graphismes 2D ou 3D supplémentaires
Une machine graphique forte en 2D, plus délicate en 3D
- Les capacités de traitement de scènes 2D de la Saturn étaient bien supérieures à celles de la Mega Drive ou de la SNES, sans pour autant constituer l’argument commercial principal de la console
- Dans les jeux 2D, le VDP1 dessine les sprites traditionnels, le VDP2 dessine les plans de fond, puis la composition est faite automatiquement pour produire la scène finale
- Dans Mega Man X4, le VDP1 gère le plan de sprites et le VDP2 compose plusieurs plans d’arrière-plan
- Les fonctions du VDP2 permettent de créer des effets de scène comme les mirages de chaleur via la mise à l’échelle
- En 3D, ses points forts s’accompagnent aussi de difficultés
- il y avait de quoi exploiter 8 processeurs, mais les développeurs devaient maîtriser l’architecture et sortir leurs jeux dans une fenêtre commerciale courte
- la qualité des jeux variait fortement selon les titres et l’approche de chaque studio
- La Saturn définit des distorted sprites, c’est-à-dire des quadrilatères à quatre points orientés librement, puis remplit leur surface par texture mapping
- Une fois que les CPU et le SCU construisent le monde 3D et le projettent dans l’espace 2D, les VDP en assurent le rendu, appliquent les effets et envoient le résultat au téléviseur
- Le VDP chargé du rendu principal variait selon les jeux
- certains développeurs confiaient les polygones proches au VDP1 et les arrière-plans lointains au VDP2
- d’autres ont créé des techniques de contournement pour faire dessiner au VDP2 jusqu’aux polygones proches
Détermination des surfaces visibles et limites de la semi-transparence
- Lorsqu’on projette des polygones 3D dans un espace 2D, il faut distinguer ceux qui sont visibles depuis la caméra de ceux qui sont masqués
- Ce problème est connu sous le nom de Visible Surface Determination (VSD) et influe sur la fidélité d’affichage du modèle, les effets de transparence et l’usage des ressources matérielles
- Le VDP1 de la Saturn n’implémente pas de fonction VSD
- si la géométrie n’est pas envoyée dans le bon ordre, l’image peut se dégrader à l’écran
- La bibliothèque graphique de Sega, SGL, implémente en logiciel un tri Z, ou Painter’s algorithm
- les polygones sont triés du plus éloigné au plus proche selon leur distance à la caméra
- puis les commandes VDP1 sont émises dans cet ordre
- La valeur de Z-order utilisée pour le tri Z étant approximative, des défauts graphiques peuvent encore apparaître en environnement 3D
- Certains programmeurs ont implémenté leurs propres algorithmes au lieu de SGL
- La Saturn peut rendre des graphismes semi-transparents, mais avec de fortes contraintes
- seul le VDP2 peut gérer le mélange de pixels semi-transparents
- le VDP1 produit un buffer déjà rendu sans distinguer les sprites superposés, donc un sprite semi-transparent masque celui qui est dessous
- le forward texture mapping du VDP1 pose aussi problème lorsqu’on applique de la semi-transparence aux distorted sprites
- dessiner des pixels semi-transparents prend six fois plus de temps
- Les jeux 2D pouvaient contourner une partie du problème via la propriété mesh des textures, qui rend certaines coordonnées totalement transparentes
- sur un signal vidéo composite, le motif mesh se brouille et donne un effet proche de la semi-transparence
- cette méthode ne résout toutefois pas le fait que les zones opaques continuent de masquer les autres sprites
- Daytona désactive la semi-transparence, ce qui rend visibles des apparitions brusques de l’arrière-plan, tandis que Sonic R utilise le registre de mix ratio du VDP2 et des changements de niveau d’éclairage pour produire des effets de semi-transparence et de fading
Audio : un sous-système sonore indépendant
- Les capacités audio de la Saturn s’inscrivent dans la transition numérique de l’époque, où CD-ROM et synthèse par échantillons se combinaient
- Le sous-système sonore est composé du SCSP/Yamaha YMF292, d’un Motorola 68EC000 et de 512 KB de sound RAM
- Le SCSP se divise en deux modules
- générateur sonore polyvalent : traite jusqu’à 32 canaux sous forme d’échantillons PCM ou de canaux FM
- DSP : applique des effets audio comme l’echo, la reverb ou le chorus
- le PCM prend en charge des échantillons de qualité CD quality jusqu’en 16 bits, 44,1 kHz
- Le Motorola 68EC000 contrôle les composants audio et sert d’interface avec le CPU principal
- sur la Saturn, le 68EC000 fonctionne à 11,3 MHz et est connecté via un bus 16 bits
- il exécute le sound driver pour piloter les modules périphériques
- Les 512 KB de sound RAM stockent les données audio comme le sound driver et les échantillons PCM, et servent aussi d’espace de travail pour le DSP
- Le pipeline audio est réparti entre le CPU principal, le 68EC000, le SCU et le sous-système CD
- le CPU principal initialise les composants audio et charge le sound driver dans la sound RAM
- il active ensuite le Motorola 68EC000
- pendant le jeu, le SCU peut transférer des échantillons PCM du CD vers la sound RAM
- le sous-système CD peut envoyer directement l’audio non compressé CD-DA au SCSP
- si une carte Video CD est présente, l’audio compressé peut être décodé par la carte puis transmis au SCSP
- Grâce à l’adoption du CD-ROM et à la capacité de traitement PCM, les studios ont pu enregistrer et produire leurs bandes-son eux-mêmes puis les intégrer au jeu sans réarrangement
Démarrage, IPL et shell intégré
- À la mise sous tension, c’est d’abord le SMPC (System Management and Peripheral Control) qui entre en action
- Le SMPC est un microcontrôleur 4 bits chargé d’initialiser les puces périphériques, notamment en alimentant les deux SH-2 et en les configurant en mode maître-esclave
- Ensuite, le vecteur de reset du SH-2 maître est fixé à
0x00000000, adresse qui pointe vers l’Initial Program Loader (IPL) situé dans une ROM de 512 KB - Après l’initialisation matérielle, l’IPL vérifie les cibles de démarrage dans l’ordre suivant
- s’il y a une cartouche contenant du code exécutable, le démarrage continue depuis celle-ci
- s’il y a une carte Video CD, elle est démarrée
- s’il y a un disque, son authenticité est vérifiée
- s’il est authentique, le jeu démarre
- s’il ne l’est pas ou s’il n’y a pas de disque, le shell interactif est lancé
- En dehors des jeux, la Saturn intègre un lecteur musical nommé Multiplayer
- il permet d’accéder au gestionnaire de données de sauvegarde
- s’il y a une carte Video CD, il peut aussi lire la vidéo MPEG décodée par celle-ci
- La ROM de la Saturn n’est pas principalement utilisée comme ensemble d’API pour développeurs à la manière du BIOS de la PlayStation : on la désigne surtout comme l’IPL
- La ROM IPL inclut néanmoins des services de System program comme la gestion des sauvegardes, le contrôle de l’alimentation et des sémaphores pour la synchronisation multiprocesseur
Support des jeux et environnement de développement
- Les jeux Saturn officiels sont chargés depuis un lecteur CD-ROM 2x
- Le support est une variante personnalisée du Compact Disc, avec une capacité de 650 MB et conforme au standard ISO 9660
- De nombreux jeux incluent des pistes audio à côté des pistes de données afin de diffuser de l’audio non compressé pendant le jeu
- Le CD enregistre l’information dans de minuscules pit et land à la surface en polycarbonate, puis reconstitue les données à partir de la réflexion infrarouge
- Le CD emploie diverses techniques d’encodage et de correction d’erreurs pour la densité de stockage et la synchronisation
- NRZI enregistre un
1lors d’une transition pit-land - EFM convertit une combinaison de 8 bits en une séquence de 14 bits adaptée aux contraintes des lecteurs CD
- CIRC répartit les données sur l’ensemble du disque et ajoute de la redondance pour permettre de restaurer les zones endommagées
- NRZI enregistre un
- La Saturn adopte le format CD-ROM XA
- il permet de stocker données, audio non compressé et tracks multimédia entrelacées
- c’est essentiel pour diffuser audio et images à une vitesse raisonnable même avec un lecteur lent
- la décompression vidéo pour la lecture nécessite une carte Video CD séparée
- L’environnement de développement était lourd au départ, même s’il s’est amélioré ensuite
- Sega ne fournissait ni bibliothèques logicielles ni outils de développement suffisamment complets, et la documentation initiale comportait aussi des inexactitudes
- pour obtenir des performances acceptables, la programmation en assembleur était importante au début
- plus tard, Sega a fourni un SDK, des kits matériels et des bibliothèques de support pour l’I/O et les graphismes
- les jeux Saturn étaient écrits en combinant du C et plusieurs langages assembleur selon les composants
- La gestion de l’I/O et du RTC est assurée par le SMPC, contrôlé par l’envoi de commandes depuis les SH-2
Interfaces d’extension
- La Saturn dispose de plusieurs connecteurs et interfaces externes
- Le cartridge slot à l’arrière du lecteur est officiellement utilisé pour du stockage supplémentaire destiné aux sauvegardes ou pour de l’extra RAM
- au Japon et aux États-Unis, un modem a aussi été proposé pour la connexion en ligne
- À l’arrière se trouve un emplacement pour la Video CD Card
- il sert à la décompression MPEG pour les logiciels ou jeux compatibles
- Le Communication Connector à l’arrière est une interface dont Sega n’a pas publié la documentation développeur
- le reverse engineering a montré qu’il est relié aux broches MIDI du SCSP et à l’interface série (SCI) des deux SH-2
- Sega a commercialisé un floppy drive utilisant cette interface
Protection anti-copie et exécution homebrew
- Comme les CD étaient faciles à copier, Sega a mis en place une protection anti-copie et un region locking pour contrôler la distribution des jeux
- La protection anti-copie de la Saturn repose sur un écart volontaire par rapport au format CD standard
- un graveur CD classique ne peut pas produire une copie parfaite d’un jeu Saturn
- lors de la vérification, le lecteur de disque Saturn recherche des caractéristiques non standard
- Sur le bord extérieur du disque Saturn, un motif de données anormal est pressé
- ce motif forme un anneau visible portant le label de la marque
- cet anneau se situe hors de la zone de données standard, au-delà de la Program Area et du Lead-out
- un lecteur standard ne peut ni accéder à cette zone ni la copier
- À l’intérieur du lecteur CD de la Saturn se trouve un processeur SH-1 dédié, qui vérifie indépendamment de l’CPU principal la présence de cet anneau
- Cette vérification n’est effectuée qu’une seule fois
- Les méthodes de contournement traditionnelles se concentraient sur la tromperie de la procédure de vérification du disque
- installation d’une mod chip pour tromper le lecteur CD quel que soit le disque inséré
- swap trick consistant à remplacer le disque par une copie gravée juste après la vérification d’un disque authentique
- Par la suite, des méthodes plus sophistiquées d’exécution homebrew sont apparues
- PseudoSaturn exploite une faille du mécanisme anti-copie pour démarrer des jeux sur disque sans vérification
- en 2022, le fork plus récent Pseudo Saturn Kai est celui qui est utilisé
- en 2016, une autre méthode a exploité le fait que l’add-on Video CD pouvait contourner le lecteur CD et injecter du code non chiffré dans le sous-système CD
- cet exploit Video CD a été commercialisé sous le nom Satiator
- un Optical Drive Emulator (ODE) remplace le lecteur CD par un adaptateur SD ou SATA et donne à la Saturn l’impression de lire un CD, alors qu’elle lit en réalité une image disque
1 commentaires
Commentaires Hacker News
L’article présente la conception comme surprenante, avec beaucoup de puces, mais il faut regarder le contexte : il n’y avait aucune synergie entre l’équipe japonaise et l’équipe américaine, et il y avait une lutte de pouvoir
SEGA JP concevait une console 2D, SEGA US concevait une console 3D, et au moment où l’équipe japonaise était sur le point de gagner cette bataille, la PSX est arrivée, ce qui a en quelque sorte fusionné les deux
Résultat : une console 2D contenant des composants d’une console 3D inachevée, une conception qui n’a pas vraiment de sens
Pour les passionnés de technique ou les amateurs de rétrospectives de développement, c’est spectaculaire ; pour ceux qui aiment les conceptions propres, c’est une source d’irritation sans fin
Pour le grand public des joueurs de l’époque, l’essentiel était « l’arcade dans le salon », et la Saturn a déçu ; le fait que SEGA ne sache pas sur quoi se concentrer n’a absolument pas aidé
L’article Wikipédia contient plus de détails : https://en.wikipedia.org/wiki/Sega_Saturn
Une interview du concepteur matériel de la Saturn (https://mdshock.com/2020/06/16/hideki-sato-discussing-the-se...) donne son point de vue sur les raisons de cette configuration matérielle
En gros, il a compris, en voyant la réaction à la PSX, que la 3D était l’avenir, mais en interne, à l’exception de l’équipe AM2 de SEGA qui créait des jeux d’arcade 3D comme Virtua Fighter ou Daytona USA, l’expertise portait sur les jeux 2D traditionnels à base de sprites
Il estimait donc que le meilleur compromis était une console excellente en 2D et aussi capable d’un peu de 3D
À mon avis, la plus grosse erreur a été de sous-estimer la vitesse à laquelle l’industrie allait basculer vers la 3D
Le véritable résultat des luttes internes chez SEGA a été encore plus stupide. Sega of America voulait une conception plus conservatrice que la Saturn, utilisant le Motorola 68020, successeur du 68000 de la Genesis : moins performante, mais avec un matériel qui aurait été plus familier aux développeurs
Après avoir perdu cette bataille, SOA a jugé que la Saturn était trop chère pour bien se vendre aux États-Unis, et a conçu le 32X, un add-on à 200 dollars pour la Genesis
Le 32X utilisait le même processeur SH2 que la Saturn, mais rendait tous les graphismes en logiciel et les superposait aux graphismes de la Genesis
Le plan initial était de garder la Saturn exclusivement au Japon pendant 2 à 3 ans et de vendre le 32X à l’étranger
Sega of America a dépensé énormément d’argent pour susciter l’intérêt autour du 32X, et son développement interne s’est concentré uniquement sur le 32X, mais les développeurs comme les médias ne s’y intéressaient presque pas par rapport à la Saturn
Lorsqu’il est devenu évident que le 32X ne tiendrait pas sur le marché, Sega of America a lancé la Saturn dans la précipitation pour détourner l’attention du 32X ; mais comme l’année précédente avait été consacrée au développement de titres 32X, il a fallu s’appuyer uniquement sur les jeux japonais, dont beaucoup n’étaient pas adaptés au marché américain
Le 32X a eu plus de jeux annulés que de jeux sortis, et tout cela a semé la confusion et la colère chez les développeurs comme chez les consommateurs
On cite souvent l’idée que le VDP2 aurait été ajouté plus tard pour prendre en charge la 3D, mais le VDP2 ne fait pas du tout de 3D : il gère des couches d’arrière-plan à la manière du Mode 7 de la SNES
Même en retirant le VDP2, si l’on met de côté le fait que le scanout vidéo est assuré par le VDP, la console restante peut toujours très bien faire de la 3D
En pratique, beaucoup de jeux 3D utilisent à peine le VDP2
Les jeux 2D devraient rendre les arrière-plans avec des centaines de sprites, ce qui coûterait en qualité, mais ce serait possible
À l’inverse, si l’on retire le VDP1, il ne reste que les couches d’arrière-plan 2D du VDP2
Il n’y aurait alors ni 3D ni possibilité d’afficher des sprites à l’écran, ce qui rendrait la machine pratiquement inutile même pour des jeux 2D
À première vue, la Saturn semble avoir été pensée dès le départ avec à la fois le VDP1 et le VDP2, conçus pour fonctionner ensemble
L’intention de SEGA JP semble avoir été, comme le montre la conception finale, d’en faire une console monstre pour la 2D avec des capacités 3D limitées
Cela ne signifie pas qu’il n’y ait pas eu de débats entre SEGA JP et SEGA US ; les indices semblent assez nombreux
Mais je ne pense pas qu’ils aient mélangé au dernier moment une conception japonaise et une conception américaine
Comme la Saturn est sortie au Japon 12 jours avant la PSX, il est aussi difficile de considérer que la PSX ait influencé ce débat
Chaque société a donc proposé une solution différente, avec ses avantages et ses inconvénients, mais toutes sont intéressantes à analyser et à comparer
C’est aussi la raison pour laquelle cet article a été écrit
https://www.copetti.org/writings/consoles/playstation/
https://www.copetti.org/writings/consoles/nintendo-64/
Dans le genre shoot ’em up, la Saturn regorgeait de jeux de tir japonais, et beaucoup étaient des portages arcade parfaits ou presque parfaits
La Sega Saturn avait une architecture matérielle assez complexe.
Je comprends que répartir les « tâches » d’un jeu entre plusieurs CPU et processeurs dédiés puisse se justifier du point de vue du rapport coût/efficacité, mais cela a probablement contribué aux ventes relativement faibles de la Saturn.
Au final, beaucoup ont dit qu’il était difficile pour les studios de justifier l’investissement nécessaire pour tout maîtriser afin de créer des jeux exploitant correctement le matériel.
Ça me rappelle la phrase de Sid Meier : « ce n’est pas le développeur du jeu qui doit s’amuser, mais le joueur » ; dans ce cas, on peut se demander si les concepteurs du matériel ne se sont pas un peu trop amusés.
Ici, la Mega Drive, c’est-à-dire la Genesis, avait eu presque autant de succès que la SNES, même si un peu moins, et tout le monde avait une Mega Drive ou y jouait régulièrement chez des amis.
C’était vraiment un matériel populaire.
Mais à la génération suivante, tout le monde avait une PlayStation, et je ne connaissais qu’un seul gamin qui avait acheté une Saturn.
C’est vraiment bizarre quand on pense qu’ici, la Saturn était sortie quelques mois avant la PlayStation.
Je ne sais pas si c’était parce que la Saturn paraissait alors être le choix inférieur, à cause du prix ou de problèmes d’approvisionnement, ou pour d’autres raisons, mais la PlayStation l’a complètement écrasée.
Après ça, Sega a disparu.
La Saturn était la plus chère à fabriquer parmi les trois grands acteurs, et le fait de devoir s’aligner sur le prix de la PlayStation a été un désastre financier pour Sega.
Le passage disant que « le VDP1 a donc été conçu pour utiliser des quadrilatères comme primitives, et les modèles ne peuvent être constitués que de polygones à 4 sommets, autrement dit de sprites » faisait que les jeux 3D Sega Saturn donnaient une impression plus anguleuse que leurs équivalents PS1.
Comparer côte à côte les versions Saturn et PS1 de Resident Evil permet bien de voir la différence.
Globalement, les jeux Sega Saturn ont fini par avoir une esthétique particulière parmi les jeux 3D des années 90.
Il faut aussi noter que l’émulation de la Sega Saturn est restée assez en retard par rapport à d’autres plateformes.
Le faible succès en Occident et la complexité de l’architecture ont probablement joué ensemble.
Mais il est vrai qu’elle a longtemps été assez médiocre.
Pour les titres que j’aime vraiment, je peux aussi acheter l’original sur eBay et avoir l’impression de les soutenir.
Sortir le CD de son boîtier plastique avec des gants en caoutchouc pour préserver la valeur de l’original, puis le remettre à chaque fois, c’est bien trop pénible ; mais je n’ai pas non plus envie de remplacer l’expérience du jeu original par de l’émulation.
La Sega Saturn comptait pas mal de perles méconnues comme Panzer Dragoon Saga, Shining Force III, Burning Rangers, Dragon Force I & II, et, à ma connaissance, elles n’ont pas été portées ni remakées.
Bien sûr, il ne faut pas oublier Saturn Bomberman non plus.
La Saturn et sa successeure, la Dreamcast, étaient plutôt bonnes et méritaient davantage de succès.
En fait, à ma connaissance, les jeux existant à la fois sur Saturn et sur d’autres plateformes sont seulement des jeux portés vers la Saturn, et pas l’inverse.
Quelqu’un pourra me corriger si je me trompe.
D’après ce que j’ai compris, l’émulation Saturn reste encore aujourd’hui délicate, même s’il y a eu des progrès importants au cours des dix dernières années.
Voici ma vidéo préférée d’analyse technique / hacking de la Saturn :
https://www.youtube.com/watch?v=jOyfZex7B3E
La diversité des consoles m’a rappelé celle de l’époque où la gloire des ordinateurs domestiques touchait à sa fin, avant que le PC ne domine.
Certains des mêmes OEM et éditeurs ont survécu jusqu’à aujourd’hui.
J’aimerais voir ça sous forme d’infographie, et ça pourrait même me donner envie d’en créer une moi-même.
J’aime le travail de Copetti et je l’ai déjà cité par le passé, mais il m’a toujours semblé rester trop haut niveau.
Cela dit, sachant combien d’efforts demandent des articles comme celui-ci, j’ai toujours l’impression qu’en demander plus serait injuste.
Au final, la promotion et la puissance financière de Sony ont battu SEGA. C’est vraiment tout.
Bien sûr, SEGA a aussi commis beaucoup d’erreurs proches de l’autosabotage.
Côté jeux, qu’est-ce qui a vraiment bouleversé le monde sur PSX ? Resident Evil en 1996 et FFVII en 1997, peut-être ?
La Saturn avait aussi des killer games, surtout en 1996, donc personnellement je ne pense pas que le problème venait de la ludothèque.
Le fait qu’elle soit difficile à programmer non plus : une génération plus tard, les développeurs ont bien su maîtriser la PlayStation 2, et la Dreamcast était facile à exploiter, mais tout le monde l’a abandonnée quand SEGA l’a arrêtée.
Aux États-Unis, la base d’utilisateurs était correcte, et pour l’Europe je ne sais pas.
Il y avait aussi un problème d’image des consommateurs envers SEGA, mais quand on voit les problèmes de fiabilité des systèmes Sony et MS, ce n’est pas forcément ça non plus.
La 360 en particulier était assez grave à ce niveau, mais cela n’a absolument pas nui à la survie à long terme de la console.
Le SEGA CD n’a pas été un échec, du moins aux États-Unis.
C’était toujours un produit haut de gamme, un peu superflu mais cool, avec de très bons jeux, même s’il n’avait pas de killer app.
Pour SEGA, c’était un succès.
Le 32X, en revanche, a bien été une énorme bourde pour toutes les personnes impliquées, mais je ne pense pas que sa brève existence ait suffi, à elle seule, à condamner la Saturn auprès du grand public.
Aux États-Unis, avec un bon marketing, les gens achètent n’importe quoi.
Le marketing américain de la Saturn était catastrophique.
SEGA n’a jamais repris ses esprits et a jeté par-dessus bord tout ce qui avait permis à la Genesis de mieux réussir que la SNES.
On peut parler de la technologie et des détails de ce qui a bien ou mal fonctionné sur la console, mais en réalité, ce sont l’échec marketing et l’absence d’un vrai Sonic au lancement comme par la suite qui ont condamné la Saturn.
1997 a été une année incroyable, avec FF7, FF Tactics, Tekken 3, Symphony of the Night, etc.
Bonne analyse. J’ai toujours ma Sega Saturn d’origine, que je possède depuis 1996, et je l’allume encore de temps en temps pour prendre une bonne dose de nostalgie.
Elle fonctionne encore parfaitement, comme le jour où je l’ai déballée.
L’architecture matérielle était peut-être devenue assez complexe, mais on ne peut qu’apprécier la fiabilité des anciennes consoles.
Les consoles plus modernes que j’ai utilisées ces dernières années ont surchauffé ou sont tombées en panne d’une autre manière, donc difficile d’en dire autant.
Avec l’arrivée de Sony et de Microsoft, la réduction des coûts avait déjà commencé à entamer la fiabilité des consoles, jusqu’à nous mener à la situation actuelle.
Les erreurs de lecture de disque sur la PSX et la PlayStation 2 étaient déjà très courantes et graves à l’époque.
Mais quand les gens s’en rendaient compte, ils possédaient déjà plein de jeux, alors ils rachetaient simplement une console.
Puisqu’on parle des architectures Sega un peu étranges, MattKC a aussi publié récemment une vidéo sur la 32X sur sa deuxième chaîne.
Si vous ne connaissez pas la 32X, c’était un module bizarre qui se branchait dans le port cartouche de la Genesis pour lancer une gamme distincte de jeux 32 bits.
En substance, deux consoles fonctionnaient ensemble, ce qui créait une autre situation où deux CPU coopéraient pour produire la sortie vidéo.
En raccordant lui-même des câbles vidéo, il a découvert que si l’on coupait le signal vidéo d’un des appareils, on pouvait obtenir uniquement la sortie rendue par l’autre.
La 32X elle-même produisait le rendu 3D, tandis que la Genesis fournissait les graphismes 2D comme les menus, le HUD et les sprites.
https://www.youtube.com/watch?v=rl9fjoolS2s