Arquitectura de Sega Saturn – análisis práctico (2021)
(copetti.org)- Sega Saturn es una consola de la transición al 3D, pero en vez de un solo acelerador 3D fue diseñada con una estructura paralela que combinaba dos CPU SH-2, la SCU, VDP1·VDP2 y subsistemas independientes de audio y CD
- La CPU colocaba dos Hitachi SH-2 de aprox. 28.63MHz en una configuración master-slave, pero como compartían el bus externo el rendimiento no se duplicaba de forma simple y el desarrollo era difícil
- En gráficos, VDP1 dibujaba sprites basados en cuadriláteros en el frame buffer y VDP2 se encargaba de los fondos, planos y la composición de capas; era muy fuerte en 2D, pero en 3D tenía grandes limitaciones en la determinación de superficies visibles y el manejo de semitransparencias
- El audio era casi como una computadora separada, compuesta por SCSP/Yamaha YMF292, Motorola 68EC000 y 512KB de sound RAM, y gracias al CD-ROM podía aprovechar muestras PCM y soundtracks de alta calidad basados en CD-DA
- Para enfrentar la copia de CD, Sega usó un anillo fuera del área estándar del CD y una verificación SH-1 dentro de la unidad, pero después aparecieron métodos de bypass y ejecución homebrew como mod chip, swap trick, PseudoSaturn, Satiator y ODE
Diseño complejo de una consola de transición al 3D
- Después de Mega Drive, Sega Saturn fue una consola que, más que imponer solo el 3D, combinó varios elementos de hardware para poder soportar dibujo de polígonos cuando fuera necesario
- El circuito completo se divide en múltiples procesadores y cuatro subsistemas principales
- Subsistema de CPU: aquí se ubican la CPU principal, la memoria y la SCU
- Subsistema de video: aquí se ubican los aceleradores gráficos
- Subsistema de audio: tiene una estructura de procesamiento de audio casi como la de una computadora separada
- Subsistema de CD-ROM: tiene una estructura cerrada por su mecanismo antipiratería
- Cada subsistema está conectado a un bus dedicado, y los subsistemas de video y audio comparten un mismo bus
CPU: dos SH-2 y la SCU
- Sega eligió CPUs de la familia SuperH de Hitachi para los juegos de nueva generación y las funciones 3D
- SuperH era una CPU pensada para usos embebidos, pero incluía elementos de diseño de tipo RISC de esa época
- Separaba operaciones de memoria y de registros con una arquitectura load-store
- Ofrecía un bus de datos de 32 bits y una ALU de 32 bits
- Ofrecía 16 registros de propósito general de 32 bits
- Con un bus de direcciones de 32 bits podía direccionar hasta 4GB de memoria
- Usaba un pipeline de 5 etapas para procesar múltiples instrucciones por fases
- Los primeros SuperH incluían una unidad de multiplicación de 16 bits
- La ISA de SuperH, aunque era de diseño RISC, usaba instrucciones de 16 bits de ancho
- Como la CPU obtiene instrucciones en unidades de 32 bits, puede traer dos instrucciones por ciclo
- Este enfoque reducía el problema de densidad de código típico de las arquitecturas RISC
- También se mantenían limitaciones propias del diseño RISC
- Por los hazards de control, los programas debían considerar el branch delay slot
- SuperH ofrecía delayed branch instructions que incluían delay slot
- En los hazards de datos, la CPU detenía automáticamente el pipeline cuando era necesario
Elección del SH-2 y estructura de doble CPU
- Sega consideró que el multiplicador de 16 bits podía convertirse en un cuello de botella al procesar grandes volúmenes de datos en juegos 3D, así que pidió mejoras a Hitachi
- Hitachi amplió la unidad de multiplicación y creó el SH-2 reflejando los requisitos de Sega
- Sega, atenta a la elección de CPU de las consolas rivales, también quería subir la frecuencia, pero aumentar el clock en un chip ya en fase de fabricación no era posible
- Hitachi había añadido un mínimo de circuitería durante la etapa de investigación de SH para permitir que varios SH funcionaran al mismo tiempo en un mismo sistema, y Sega adoptó una configuración de 2 chips para Saturn
- La configuración final de CPU incluía tanto posibilidades de paralelismo como cuellos de botella
- Dos Hitachi SH-2 funcionaban cada uno a unos 28.63MHz
- Las dos CPU eran físicamente iguales, pero estaban dispuestas en estado master-slave
- La CPU master podía enviar instrucciones a la CPU slave
- Como compartían el mismo bus externo, podía haber congestión de bus
- El chip SH7604 incluía funciones para reforzar el rendimiento de ejecución
- Pipeline de 5 etapas y una ISA SuperH ampliada
- Unidad de multiplicación de 32 bits
- Bus de datos externo compartido de 32 bits
- Caché de 4KB
- Unidad de división de 32 bits
- Controlador DMA interno
- Soporte para little endian
- Tener dos CPU no significaba que los juegos corrieran al doble de velocidad; para un paralelismo eficiente se necesitaba programación compleja considerando el bus compartido y el uso de caché
Memoria y SCU
- El subsistema de CPU tiene 2MB de Work RAM de propósito general
- La Work RAM se divide en dos bloques
- WRAM-H: 1MB de SDRAM con acceso más rápido, y su bus es compartido con otros componentes
- WRAM-L: 1MB de DRAM más lenta, pero con un bus dedicado a la CPU principal
- Además de los dos SH-2, el grupo de CPU también incluye la Saturn Control Unit (SCU)
- La SCU está compuesta por dos módulos encargados de mover datos y asistir en cálculos
- Controlador DMA: arbitra el acceso a WRAM-L entre tres subsistemas sin intervención de la CPU
- DSP: se usa como una unidad geométrica de punto fijo y realiza más rápido que el SH-2 cálculos de matrices y vectores como transformaciones 3D e iluminación
- El DSP de la SCU funciona a media velocidad, tiene un conjunto de instrucciones más complejo y usa la WRAM-L lenta y DMA para fetch y store de datos
- La SCU incluye 32KB de SRAM para uso local
Estructura gráfica: VDP1 y VDP2
- Saturn usa dos GPU propietarias con funciones distintas que trabajan al mismo tiempo: VDP1 y VDP2
- En el diseño gráfico de la generación 3D, el frame buffer pasó a ser importante
- La GPU dibuja un bitmap de la escena en una parte de la VRAM y luego el codificador de video lo saca en pantalla
- El tamaño del frame buffer es proporcional a la resolución y a la profundidad de color
- Como ejemplo, 600KB de VRAM pueden contener un frame buffer de 640×480, 32K colores, 16bpp
- En Saturn, la aceleración de operaciones vectoriales no la hace el SH-2 en sí, sino la SCU
VDP1: sprites basados en cuadriláteros y frame buffer
- VDP1 dibuja sprites con transformaciones geométricas, escribe el resultado en el frame buffer y luego lo entrega a VDP2 para mostrarlo
- La programación se hace emitiendo drawing commands
- Usa 512KB de RAM dedicada para guardar comandos, texturas·tiles, tablas de consulta de color y demás
- La forma básica es únicamente el quadrilateral
- Los modelos están compuestos por polígonos de cuatro vértices, es decir, sprites
- Usa Forward Texture Mapping para asociar puntos de textura al cuadrilátero
- Como no hay filtrado ni interpolación, el renderizado presenta aliasing
- Entre los efectos disponibles están Flat·Gouraud shading, anti-aliasing, clipping y transparency
- Usa dos chips de frame buffer de 256KB para dibujar la siguiente escena en un buffer mientras muestra el otro
- Cuando termina el renderizado del segundo buffer, usa page flipping para cambiar el buffer mostrado
VDP2: planos de fondo, composición de capas y corrección de perspectiva
- VDP2 está especializado en renderizar grandes planos de hasta 4096×4096 píxeles aplicando transformaciones de rotación, escalado y desplazamiento
- Renderiza on the fly siguiendo el avance del haz del CRT, sin usar frame buffer
- Soporta color de 24 bits con hasta 16.7 millones de colores
- También muestra el buffer de salida de VDP1 y puede transformarlo y mezclarlo con sus propias capas
- La composición del frame elige una de las siguientes opciones
- Hasta cuatro planos 2D y un plano 3D
- O bien dos planos 3D
- VDP2 construye los planos con tile-map y aplica perspective correction al texture mapping 3D
- Entre los efectos disponibles están multi-texturing y shadowing
- Puede bajar el brillo de los sprites recibidos de VDP1 y mezclarlos de manera semitransparente
- Pero como solo recibe un stream de sprites ajustado a la velocidad del haz CRT, la codificación y operación son complicadas
- VDP2 incluye 4KB de CRAM para convertir los valores de indexed colour de VDP1 a RGB de 24 bits
- Los planos 3D están limitados a dos, pero la CPU puede usar la VRAM de VDP2 como frame buffer por software para dibujar gráficos 2D·3D adicionales
Una máquina gráfica fuerte en 2D y complicada en 3D
- La capacidad de Saturn para manejar escenas 2D era mucho más amplia que la de Mega Drive o SNES, aunque no era el principal argumento de venta de la consola
- En juegos 2D, VDP1 dibuja los sprites tradicionales, VDP2 dibuja los planos de fondo y luego los compone automáticamente para formar la escena final
- En Mega Man X4, VDP1 se encarga del plano de sprites y VDP2 construye varios planos de fondo
- Aprovechando las funciones de VDP2 se podían crear efectos de escena como distorsiones de calor mediante escalado
- En 3D se veían al mismo tiempo sus fortalezas y sus dificultades
- Había margen para aprovechar 8 procesadores, pero los desarrolladores tenían que aprender sus funciones y lanzar juegos dentro de una vida comercial corta
- La calidad de los juegos variaba mucho según el enfoque de cada título y estudio
- Saturn define distorted sprites, que son cuadriláteros de cuatro puntos con ángulos arbitrarios, y rellena la superficie con texture mapping
- Cuando la CPU y la SCU construyen el mundo 3D y lo proyectan al espacio 2D, los VDP lo renderizan, aplican efectos y lo envían a la TV
- Qué VDP se encargaba del renderizado principal dependía de cada juego
- Algunos desarrolladores dejaban los polígonos cercanos a VDP1 y los fondos lejanos a VDP2
- Otros crearon técnicas de bypass para que VDP2 dibujara incluso polígonos cercanos
Determinación de superficies visibles y límites de la semitransparencia
- Al proyectar polígonos 3D al espacio 2D, hay que distinguir entre los polígonos visibles para la cámara y los que quedan ocultos
- Este problema se conoce como Visible Surface Determination (VSD) y afecta la precisión al mostrar modelos, los efectos de transparencia y el uso de recursos de hardware
- El VDP1 de Saturn no implementa funciones de VSD
- Si la geometría no se entrega en el orden correcto, la imagen puede romperse
- La biblioteca gráfica de Sega, SGL, implementa por software Z-sort, o el algoritmo del pintor
- Ordena los polígonos de los más lejanos a los más cercanos según su distancia a la cámara
- Después emite los comandos de VDP1 en ese orden
- El valor de Z-order del Z-sort es aproximado, así que aun así pueden aparecer fallas gráficas en entornos 3D
- Algunos programadores implementaron sus propios algoritmos en lugar de SGL
- Saturn puede renderizar gráficos semitransparentes, pero con muchas restricciones
- Solo VDP2 puede encargarse de la mezcla de píxeles semitransparentes
- Como VDP1 saca un buffer ya renderizado sin distinguir sprites superpuestos, un sprite semitransparente tapa al sprite que está debajo
- El forward texture mapping de VDP1 causa problemas al aplicar semitransparencia a distorted sprites
- Dibujar píxeles semitransparentes tarda seis veces más
- Los juegos 2D podían esquivar esto usando la propiedad mesh de la textura para volver totalmente transparentes ciertas coordenadas
- En una señal de video compuesto, el patrón mesh se difumina y produce un efecto parecido a la semitransparencia
- Aun así, el problema de que las partes opacas tapen otros sprites seguía presente
- Daytona desactiva la semitransparencia y por eso se nota que el fondo aparece de golpe, mientras que Sonic R implementa semitransparencia y efectos de fading con el registro mix ratio de VDP2 y cambios de nivel de iluminación
Audio: subsistema de sonido independiente
- Las funciones de audio de Saturn forman parte de la transición digital de la época, combinando CD-ROM y sintetizadores por muestras
- El subsistema de sonido está compuesto por SCSP/Yamaha YMF292, Motorola 68EC000 y 512KB de sound RAM
- El SCSP se divide en dos módulos
- Generador de sonido multifunción: maneja hasta 32 canales como muestras PCM o canales FM
- DSP: aplica efectos de audio como echo, reverb y chorus
- PCM soporta muestras de calidad CD de hasta 16 bits y 44.1kHz
- El Motorola 68EC000 controla los componentes de audio y hace interfaz con la CPU principal
- En Saturn, el 68EC000 funciona a 11.3MHz y está conectado por un bus de 16 bits
- Ejecuta el sound driver para operar los módulos periféricos
- Los 512KB de sound RAM almacenan datos de audio como el sound driver y las muestras PCM, y también sirven como área de trabajo para el DSP
- La tubería de audio se reparte entre la CPU principal, el 68EC000, la SCU y el subsistema de CD
- La CPU principal inicializa los componentes de audio y carga el sound driver en la sound RAM
- Después activa el Motorola 68EC000
- Durante el juego, la SCU puede transferir muestras PCM desde el CD hacia la sound RAM
- El subsistema de CD puede enviar audio CD-DA sin comprimir directamente al SCSP
- Si hay una tarjeta Video CD, el audio comprimido puede decodificarse en la tarjeta y luego enviarse al SCSP
- Gracias a la adopción del CD-ROM y a su capacidad para procesar PCM, los estudios pudieron grabar y producir sus soundtracks por cuenta propia e incluirlos en el juego sin tener que reacomodarlos
Arranque, IPL y shell integrada
- Al encender, primero entra en funcionamiento el SMPC (System Management and Peripheral Control)
- El SMPC es un microcontrolador de 4 bits y se encarga de inicializar chips periféricos, como encender los dos SH-2 y configurarlos en modo master-slave
- Después, el reset vector del SH-2 master se fija en
0x00000000, y esa dirección apunta al Initial Program Loader (IPL) en una ROM de 512KB - Tras inicializar el hardware, el IPL revisa en orden el objetivo de arranque
- Si hay un cartucho con código ejecutable, continúa el arranque desde ahí
- Si hay una tarjeta Video CD, la arranca
- Si hay un disco, verifica si es original
- Si es original, arranca el juego
- Si no es original o no hay disco, ejecuta el shell interactivo
- Además de los juegos, Saturn incluye un reproductor de música integrado llamado Multiplayer
- Desde ahí se puede acceder al administrador de datos guardados
- Si hay una tarjeta Video CD, también puede reproducir video MPEG decodificado por la tarjeta
- La ROM de Saturn no suele usarse principalmente como un conjunto de API para desarrolladores, como el BIOS de PlayStation, sino que se la llama IPL
- Aun así, la ROM del IPL también incluye servicios de System program para gestión de datos guardados, control de energía y semaphores para sincronización multiprocesador
Medio de juego y entorno de desarrollo
- Los juegos oficiales de Saturn cargan desde una unidad de CD-ROM 2x
- El medio es una variante personalizada del Compact Disc, con una capacidad de 650MB y compatible con el estándar ISO 9660
- Muchos juegos incluyen pistas de audio junto a la pista de datos para transmitir audio sin comprimir durante la partida
- El CD graba información en pequeños pit y land sobre una superficie de policarbonato, y reconstruye los datos leyendo la reflexión infrarroja
- El CD usa varias técnicas de codificación y corrección de errores para densidad de almacenamiento y sincronización
- NRZI registra un
1cuando hay una transición pit-land - EFM convierte combinaciones de 8 bits en secuencias de 14 bits ajustadas a las limitaciones del lector de CD
- CIRC distribuye los datos por todo el disco y añade redundancia para poder recuperar zonas dañadas
- NRZI registra un
- Saturn adopta el formato CD-ROM XA
- Permite almacenar datos, audio sin comprimir e interleaved multimedia tracks
- Es importante para transmitir audio e imágenes a una velocidad razonable incluso en unidades lentas
- La descompresión para reproducir video requiere una tarjeta Video CD separada
- El entorno de desarrollo al principio era exigente, aunque luego las herramientas mejoraron
- Sega no proporcionó suficientes bibliotecas de software ni herramientas de desarrollo, y la documentación inicial también tenía partes inexactas
- Para obtener un rendimiento aceptable, al inicio era importante programar en ensamblador
- Más adelante Sega ofreció SDK, hardware kits y bibliotecas de apoyo para I/O y gráficos
- Los juegos de Saturn se escribían combinando C y varios lenguajes ensamblador según el componente
- La gestión de I/O y del RTC recae en el SMPC, que es controlado por el SH-2 mediante comandos
Interfaces de expansión
- Saturn tiene varios conectores e interfaces externos
- El cartridge slot detrás de la unidad se usa oficialmente como almacenamiento adicional para datos guardados o como extra RAM
- En Japón y Estados Unidos también se ofreció un modem para conexión en línea
- En la parte trasera hay una ranura para Video CD Card
- Realiza la descompresión MPEG para programas o juegos compatibles
- El Communication Connector trasero es una interfaz sobre la que Sega no publicó documentación para desarrolladores
- La ingeniería inversa confirmó que está conectado a los pines MIDI del SCSP y a la Serial Interface (SCI) de los dos SH-2
- Sega lanzó una floppy drive que usa esta interfaz
Antipiratería y ejecución homebrew
- Como copiar CD era fácil, Sega implementó antipiratería y region locking para controlar la distribución de juegos
- La protección antipiratería de Saturn se aparta deliberadamente del formato estándar de CD
- Una grabadora de CD común no puede hacer una copia perfecta de un juego de Saturn
- El lector de discos de Saturn busca características no estándar durante el proceso de verificación
- En el borde exterior del disco de Saturn se prensa un patrón de datos anómalo
- Ese patrón crea un anillo visible con la etiqueta de la marca
- El anillo está fuera del Program Area y del Lead-out, que son el área de datos estándar
- Una unidad común no puede acceder ni copiar esa zona
- Dentro de la unidad de CD de Saturn hay un procesador SH-1 dedicado que verifica la presencia del anillo de forma independiente de la CPU principal
- Esta comprobación se realiza solo una vez
- Los métodos tradicionales de bypass se centraban en engañar el proceso de verificación del disco
- Se instala un mod chip para engañar al lector de CD sin importar qué disco se inserte
- El swap trick cambia a un disco grabado justo después de la verificación de un disco original
- Después aparecieron métodos más sofisticados para ejecutar homebrew
- PseudoSaturn aprovecha un exploit del mecanismo antipiratería para arrancar juegos en disco sin verificación
- Desde 2022 se usa el fork más nuevo, Pseudo Saturn Kai
- En 2016 apareció un método que aprovechaba que el add-on Video CD podía inyectar código sin cifrar en el subsistema de CD saltándose la unidad
- Ese exploit de Video CD se comercializó como Satiator
- Un Optical Drive Emulator (ODE) reemplaza el lector de CD por un adaptador SD o SATA, y hace que Saturn crea que está leyendo un CD cuando en realidad lee una imagen de disco
1 comentarios
Comentarios de Hacker News
El artículo lo presenta como si el diseño fuera asombroso por la cantidad de chips, pero hay que verlo en contexto: no había ninguna sinergia entre el equipo de Japón y el de Estados Unidos, y había una lucha por el control.
SEGA JP estaba haciendo una consola 2D y SEGA US estaba haciendo una consola 3D, y justo cuando el equipo japonés iba a ganar esa disputa apareció la PSX y, en la práctica, terminó fusionando ambas ideas.
El resultado fue una consola 2D con piezas de una consola 3D inconclusa, y desde el punto de vista del diseño no tenía mucho sentido.
Para los entusiastas de la tecnología o para quienes disfrutan leer retrospectivas de desarrollo, es un espectáculo; para quienes prefieren diseños limpios, resulta interminablemente irritante.
Para el jugador masivo de esa época, lo importante era tener “arcade en la sala”, y Saturn fue decepcionante; tampoco ayudó en nada que SEGA no supiera en cuál dirección enfocarse.
El artículo de Wikipedia tiene más detalles: https://en.wikipedia.org/wiki/Sega_Saturn
En una entrevista con el diseñador del hardware de Saturn (https://mdshock.com/2020/06/16/hideki-sato-discussing-the-se...) se explica la perspectiva de por qué eligieron esa configuración de hardware.
Básicamente, él vio la reacción ante la PSX y entendió que el 3D era el futuro, pero salvo el equipo AM2 de SEGA, que hacía juegos arcade 3D como Virtua Fighter y Daytona USA, la experiencia interna estaba en los juegos tradicionales basados en sprites 2D.
Por eso consideró que el mejor compromiso era una consola excelente para juegos 2D y razonablemente capaz en 3D.
Creo que el mayor error fue subestimar qué tan rápido la industria iba a girar hacia un enfoque centrado en el 3D.
El verdadero resultado de las peleas internas en SEGA fue mucho más tonto. Sega of America quería un diseño más conservador que Saturn, usando el Motorola 68020, sucesor del 68000 de Genesis; tendría menos rendimiento, pero los desarrolladores habrían estado más familiarizados con el hardware.
Tras perder esa disputa, SOA concluyó que Saturn era demasiado cara y difícil de vender en Estados Unidos, así que diseñó el 32X, un add-on de 200 dólares para Genesis.
El 32X usa los mismos procesadores SH2 que Saturn, pero dibujaba todos los gráficos por software y los superponía sobre los gráficos de Genesis.
El plan inicial era dejar Saturn como producto exclusivo de Japón por 2 o 3 años y vender el 32X en el extranjero.
Sega of America gastó muchísimo dinero para generar interés en el 32X y concentró su desarrollo interno solo en esa plataforma, pero ni los desarrolladores ni los medios mostraron casi interés por el 32X frente a Saturn.
Cuando quedó claro que el 32X no iba a sostenerse en el mercado, Sega of America lanzó Saturn a las apuradas para desviar la atención del 32X, pero como había pasado el año anterior desarrollando títulos para 32X, tuvo que depender solo de juegos japoneses, y muchos de ellos no encajaban con el mercado estadounidense.
El 32X tuvo más juegos cancelados que lanzamientos, y todo esto terminó confundiendo y enfureciendo tanto a desarrolladores como a consumidores.
Suele citarse que VDP2 fue añadido más tarde para dar soporte 3D, pero VDP2 no hace 3D en absoluto; se encarga de capas de fondo tipo Mode 7 del SNES.
Incluso si quitaras VDP2, dejando de lado que el escaneo de video depende del VDP, la consola restante seguiría pudiendo hacer 3D bastante bien.
De hecho, muchos juegos 3D casi no usan VDP2.
Los juegos 2D perderían calidad porque tendrían que renderizar los fondos con cientos de sprites, pero sería posible.
En cambio, si quitaras VDP1, solo quedarían las capas de fondo 2D de VDP2.
Entonces no habría 3D y ni siquiera podrías poner sprites en pantalla, así que sería prácticamente inútil también para juegos 2D.
A mi parecer, Saturn fue concebida desde el inicio para tener tanto VDP1 como VDP2, y para que ambos trabajaran juntos.
La intención de SEGA JP parece haber sido, como muestra el diseño final, una consola monstruo para 2D con capacidades 3D limitadas.
Eso no significa que no hubiera discusiones entre SEGA JP y SEGA US; parece haber bastante evidencia de ello.
Pero no creo que en el último momento mezclaran un diseño japonés con uno estadounidense.
Como Saturn salió en Japón 12 días antes que la PSX, también es difícil pensar que la PSX haya influido en esa discusión.
Por eso cada empresa presentó soluciones distintas, con ventajas y desventajas diferentes, pero todas interesantes de analizar y comparar.
Esa es también la razón por la que se escribió este artículo.
https://www.copetti.org/writings/consoles/playstation/
https://www.copetti.org/writings/consoles/nintendo-64/
En el género de los shoot 'em up, Saturn estuvo repleta de juegos de disparos japoneses, y muchos eran conversiones arcade perfectas o casi perfectas.
La Sega Saturn tenía una arquitectura de hardware bastante compleja
Entiendo que, desde la perspectiva de costo-beneficio, tenía sentido repartir el “trabajo” de los juegos entre varios CPU y procesadores dedicados para escalar capacidades, pero probablemente eso influyó en las ventas relativamente bajas de la Saturn
Al final, muchas compañías decían que era difícil justificar la inversión de aprender todo lo necesario para hacer juegos que aprovecharan bien el hardware
Me hace pensar en la frase de Sid Meier: “quien debe divertirse no es el desarrollador del juego, sino el jugador”, y en este caso da la impresión de que quienes se divirtieron demasiado fueron los diseñadores del hardware
Aquí, la Mega Drive, o Genesis, fue casi tan exitosa como la SNES, si no igual, y todo el mundo tenía una Mega Drive o jugaba regularmente en la casa de un amigo
Era un hardware realmente popular
Pero en la siguiente generación todos tenían una PlayStation, y solo conocí a un niño que compró una Saturn
Es especialmente raro si se piensa que aquí la Saturn salió unos meses antes que la PlayStation
No sé si fue porque la Saturn parecía una opción inferior en ese momento, por precio, problemas de suministro u otros factores, pero la PlayStation la aplastó por completo
Después de eso, Sega desapareció
La Saturn tenía el costo de fabricación más alto de las tres grandes, y tener que igualar el precio de la PlayStation fue un desastre financiero para Sega
La parte de “por lo tanto, el VDP1 fue diseñado para usar cuadriláteros como forma básica, y los modelos solo pueden construirse con polígonos de cuatro vértices, es decir, sprites” hacía que los juegos 3D de Sega Saturn se vieran más angulosos que sus equivalentes en PS1
Si comparas lado a lado Resident Evil en Saturn y en PS1, se nota bien la diferencia
En general, los juegos de Sega Saturn terminaron teniendo una estética particular dentro de los juegos 3D de los 90
También vale la pena señalar que la emulación de Sega Saturn estuvo bastante rezagada frente a la de otras plataformas
Parece que se combinaron su bajo éxito en Occidente y su estructura compleja
Aunque sí es cierto que durante mucho tiempo fue bastante floja
Y con los títulos que de verdad me encantan, todavía puedes sentir que apoyas algo comprando el juego original en eBay
Ponerse guantes de goma para sacar el CD de la caja plástica y luego volver a guardarlo cada vez, solo para preservar el valor del original, es demasiado engorroso, pero tampoco quiero reemplazar la experiencia del juego original con emulación
La Sega Saturn tenía bastantes joyas ocultas como Panzer Dragoon Saga, Shining Force III, Burning Rangers y Dragon Force I & II, y hasta donde sé no han tenido ports ni remakes
Claro, tampoco se puede dejar fuera Saturn Bomberman
La Saturn y la Dreamcast que vino después eran bastante buenas y merecían haber tenido más éxito
De hecho, hasta donde yo sé, los únicos juegos que existían tanto en Saturn como en otras plataformas eran juegos porteados a Saturn, nunca al revés
Pero si estoy equivocado, seguro alguien me corregirá
Según entiendo, la emulación de Saturn sigue siendo complicada incluso hoy, aunque ha avanzado bastante en los últimos 10 años
Mi video favorito de análisis técnico/hacking de la Saturn es este
https://www.youtube.com/watch?v=jOyfZex7B3E
Ver la variedad de consolas me recordó la diversidad de la era en que se apagaba la gloria de las computadoras domésticas, antes de que la PC dominara todo
Algunos de los mismos OEM y publishers sobrevivieron hasta hoy
Me gustaría verlo en una infografía, y hasta podría animarme a hacerla yo mismo
Me gusta el trabajo de Copetti y hasta lo he citado antes, pero siempre se siente demasiado de alto nivel
Aun así, como sé cuánto esfuerzo requiere escribir algo así, siempre me parece injusto pedir más
Al final, la publicidad y el poder financiero de Sony fueron lo que derrotó a SEGA. De verdad, eso fue todo
Claro que SEGA también cometió muchos errores casi autodestructivos
Si hablamos de juegos, ¿cuáles fueron los títulos de PSX que realmente sacudieron al mundo? ¿Resident Evil en 1996 y FFVII en 1997, quizá?
La Saturn también tuvo killer apps, sobre todo en 1996, así que personalmente no creo que haya sido un problema de catálogo
Tampoco lo de que fuera difícil programar, porque una generación después los desarrolladores manejaron bien la PlayStation 2, y la Dreamcast era fácil de aprovechar, pero cuando SEGA la descontinuó todos la abandonaron
En Estados Unidos, la base de usuarios tampoco estaba mal; de Europa no sé
También se habla de un problema de simpatía del consumidor hacia SEGA, pero viendo los problemas de fiabilidad de los sistemas de Sony y Microsoft, tampoco parece que eso lo explique todo
La 360 en particular fue bastante grave, pero no afectó en nada la supervivencia a largo plazo de la consola
Al menos en Estados Unidos, el SEGA CD no fue un fracaso
Siempre fue un producto premium, algo innecesario pero genial, y tuvo juegos excelentes, aunque sin una killer app
Para SEGA fue un éxito
Es cierto que el 32X fue una metida de pata monumental para todos los involucrados, pero no creo que su existencia tan breve, al nivel del consumidor masivo, por sí sola haya arruinado a la Saturn
En Estados Unidos, si el marketing es bueno, la gente compra lo que sea
El marketing de la Saturn en Estados Unidos fue pésimo
SEGA perdió por completo el rumbo y tiró por la borda todo lo que había hecho que la Genesis tuviera más éxito que la SNES
Podemos hablar de tecnología y detalles sobre qué funcionó y qué no en la consola, pero en realidad fueron el fracaso del marketing y la ausencia de un Sonic de verdad tanto en el lanzamiento como después lo que hundió a la Saturn
1997 fue un año increíble: FF7, FF Tactics, Tekken 3, Symphony of the Night y más
Buen análisis. Todavía tengo el Sega Saturn original que tengo desde 1996, y a veces lo enciendo para darme un golpe de nostalgia
Sigue funcionando perfectamente, igual que el día en que lo saqué de la caja
Puede que la arquitectura de hardware se haya vuelto bastante compleja, pero es imposible no apreciar la fiabilidad de las consolas de antes
Las consolas más modernas que he usado en los últimos años se han sobrecalentado o se han descompuesto de otras maneras, y no puedo decir lo mismo de ellas
Con la entrada de Sony y MS ya empezó el recorte de costos en la fiabilidad de las consolas, y así llegamos a como están hoy
Los errores de lectura de disco de la PSX y la Playstation 2 ya eran muy comunes y graves en esa época
Pero cuando la gente se dio cuenta, ya tenía un montón de juegos, así que simplemente compró otra consola
Ya que salió el tema de las estructuras extrañas de Sega, también está el video de 32X que MattKC subió hace poco a su segundo canal
Si no conoces el 32X, era un módulo raro que se conectaba a la ranura de cartuchos de la Genesis para ejecutar una línea separada de juegos de 32 bits
En esencia era otra situación en la que dos consolas funcionaban juntas, con dos CPU colaborando para generar la salida de video
Él probó a conectar personalmente el cable de video y descubrió que, si se corta la señal de video de uno de los dispositivos, se puede obtener solo la salida renderizada por el otro
El 32X por sí solo enviaba el renderizado 3D, y la Genesis aportaba los gráficos 2D como los menús, el HUD y los sprites
https://www.youtube.com/watch?v=rl9fjoolS2s