Citar:

Las generaciones del 3D (SegaSaturn)
General 27 Abril, 2010

Este artículo es único y exclusivamente sobre la arquitectura de Saturn respecto al 3D.

Arquitectura General del sistema

Geometry Engine
Saturn no tiene lo que se llama un hardware específico que haga el trabajo de un Geometry Engine, es por ello que siempre se ha dicho que Saturn esta pensada para el 2D y no para el 3D, en este caso comparte las mismas limitaciones que la 3DO pero con la diferencia de hacer el trabajo con procesadores mucho más potentes para ello por lo que los resultados son mejores.
El primer modo es el uso del SH2 Dual (la CPU de Saturn) para hacer dicho trabajo, el resultado en este modo no es mejor que el del 32X con mayor calidad de imagen gracias a los VDP de Saturn, se ha de tener en cuenta que el 32X y Saturn comparten la misma CPU pero a velocidades de reloj distintas, dicho modo fue el usado en la primera generación de juegos para Saturn con resultados que fueron altamente criticados.

Sega decidió buscar una solución al problema del 3D usando un procesador que no estaba pensado para dichas tareas, el del controlador de memoria. En el control de las direcciones de memoria siempre se acaba sumando, (restando) y multiplicando pero jamás dividiendo. El caso es que Sega decidió usar dicho procesador como Geometry Engine pero de una forma muy curiosa, este no podía dividir por lo que para dividir se necesitaba el uso combinado del SCU con el SH2 y usando ensamblador, lo que resultaba un tedio para los desarrolladores que veían que tanto el PC como PlayStation y el hecho de que ambos sistemas se pudieran programar en C.
Los primeros juegos de segunda generación estuvieron marcados por la triada Virtua Cop, Virtua Fighter 2 y Sega Rally, a partir de ese punto las capacidades 3D de Saturn no mejoraron para nada, se comento durante mucho tiempo que Sega inauguraría la tercera generación de juegos a nivel técnico con el lanzamiento de Virtua Fighter 3 para la consola, pero jamás llegamos a ver dicho juego ni la información sobre la tercera generación técnica de la consola.
Los datos son realmente confusos en ese periodo, las fuentes venidas de Japón hablaban de que los juegos de tercera generación iban a correr en una Saturn sin modificaciones mientras que Sega America afirmaba que existía un Add-On al estilo 32X pero el fiasco reciente de los add-on de Saturn cancelo completamente el proyecto y Sega se acabo centrando en una nueva máquina. Lo más seguro es que dicho Add-On no fuera más que un chip+Memoria que se colocaría en el slot de cartuchos de Saturn, dicho chip se trataba de un Geometry Engine+Triangle Setup que descargaba completamente al SCU de dicha tarea y era mucho más facil de manejar para los programadores.
No se sabe que títulos estaban siendo desarrollados que tuvieran como elemento mandatorio el add-on para poder jugar, solo se comenta que una versión de Virtua Fighter 3 (por lo visto hubo dos en desarrollo, la primera para el add-on y la segunda para una Saturn pelada) y Tomb Raider II, que al final fue cancelado, se hicieron para dicho add-on.
CPU
La CPU de Saturn son dos Hitachi SH2 que no funcionan en paralelo sino en modo maestro-esclavo, esto significa que:
Solo un procesador tiene acceso a la memoria principal y se comunica con otros periféricos
Existe una comunicación directa entre ambos procesadores
El segundo procesador pese a ser de caracteristicas iguales acaba funcionando como un co-procesador del primero
La arquitectura SuperH es una arquitectura RISC que diseño Hitachi originalmente para ser usada como microcontrolador, su bajo coste es lo que hizo que Sega se decantara por dicho procesador para el 32X y para Saturn en vez del 68030 que era el plan inicial, la elección de los procesadores de Hitachi no se hizo por rendimiento sino por coste, no obstante la elección de dichos procesadores llevo consigo ciertas limitaciones.
Pese a que el Program Counter y com ello el Memory Acces Register y el Memory Buffer Register eran de 32 bits, el registro de instrucciones era solo de 16 bits. la mayoría de instrucciones eran del tipo Instrucción(16 bits)+Dirección de Memoria. Esto era debido a que el procesador se diseño inicialmente para funcionar como microcontrolador y unicamente soportaba 2^16 bits de redireccionamiento que son 64K.
Falta de una MMU para el manejo de memoria, cosa que si que tienen todos los procesadores de la serie 68K, esa fue la mayor perdida respecto a la elección del SH2 en vez del 68030
En la parte buena estaba el hecho de que el rendimiento de la CPU era el doble por cada ciclo de reloj respecto al 68030.
Memoria
El Saturn Control Unit no se diseño para encargarse de facilitar el calculo geométrico en las escenas 3D a tiempo real sino que hace el trabajo de comunicar a los diferentes procesadores entre si con la memoria del sistema, aunque en las especificaciones técnicas se relata a la memoria de forma separada la realidad es que se encuentra de forma unificada y es el SCU el encargado de ir manejando los diferentes accesos que tienen los diferentes procesadores.
La distribución de memoria es como sigue:
2MB de memoria para el código principal del programa. De estos se usan 512K como cache para el CD-ROM
1MB para el VDP1 repartidos en 512K y 2 bloques de 256K.
512K para el VDP2
512K para el subsistema de sonido
La memoria RAM es ampliable a través del slot de cartuchos que tiene la consola, aparecieron durante la vida de la consola dos expansiones distintas, la primera de ellas de 1MB creada por SNK y la segunda por parte de Capcom con una capacidad de 4MB. Dichos cartuchos se usaban para conseguir mayores resoluciones en pantalla para los juegos en 2D debido a que internamente Saturn podía trabajar con resoluciones mayores pero se veía completamente limitada por el tamaño de su framebuffer.
Los VDP
Los VDP son 2 coprocesadores gemelos funcionando a 7.2Mhz cada uno de ellos encargados de generar los gráficos de la consola. Estos me servirán para explicar como funciona un sistema de video en una consola basada en una unidad óptica puesto que la forma de acceder a los datos y manejarlos es completamente diferente que en los sistemas de cartuchos.
Mientras en los sistemas de cartuchos la única memoria necesaria en el sistema es el framebuffer, en el caso de los sistemas basados en unidades ópticas debido a la lentitud del medio de almacenamiento se acaba necesitando una mayor cantidad de memoria disponible en el sistema para manipular los datos relacionados con el video. Dicha memoria de video se divide en los siguientes elementos:
Una lista de comandos FIFO (First In/First Out) que funciona en formato pila que marca lo que tiene que hacer el procesador, los comandos estan en formato instrucción propia del procesador gráfico+dirección de memoria del dato a manipular.
Unos datos de entrada para ser manipulados, estos pueden ser sprites ya procesados, sprites pre-procesados como geometría 3D ya transformada a sistema cartesiano para su rasterizado.
Una porción de memoria que se reserva al buffer de la imagen final, cuando la porción de memoria se llena es enviada directamente a la pantalla/monitor a través del RAMDAC para generar la imagen final, en algunos sistemas se puede retrasar el tiempo de envió de la imagen final para poder manipularla.
VDP1
El VDP1 es lo que podríamos llamar un Blitter, su trabajo es la manipulación a tiempo real de los sprites que forman parte de la escena pero que no forman parte de los fondos. El VDP1 soporta mapeado de texturas pero no lo soporta aplicado a triángulos sino a sprites por lo que es necesario que en los juegos de Saturn se usen cuadrados para definir la geometría de la escena 3D en vez de triángulos.
El VDP1 funciona de manera pasiva y no tiene controlador de memoria asignado, esto significa que la gestión de memoria tiene que hacerse siempre de manos del programador, esto resulta enormemente tedioso ya que esto hace que el programador tenga que borrar manualmente el framebuffer al final de cada ciclo de reloj gastando de forma estúpida ciclos de procesamiento de la CPU y el SCU.
En los primeros 512K asignados al VDP1 se almacena por un lado la lista de comandos a hacer como también los datos a manipular, esto pueden ser sprites pre-generados que han sido cargados desde el CD-ROM a esta memoria como direcciones de memoria a la principal como quads previamente transformados al sistema cartesiano y enviados al VDP1 para su texturizado y manipulación a tiempo real.
Los últimos 512K estan divididos en dos modulos de 256K, el primero de ellos es accedido por el VDP1 para colocar los sprites resultantes tras la manipulación/generación de estos, el segundo es accedido por el VDP2 para dibujar la escena en pantalla. Cuando el VDP1 ha dibujado un frame es necesario saltar al otro banco de memoria y decirle al VDP2 que lea el ya generado, cuando un frame ha sido leido por el VDP2 es necesario vaciarlo completamente para ser usado por el VDP1.
VDP2
Se trata del rasterizador que existe dentro de Saturn y es el único de los 2 VDP que tiene acceso directo al DAC para dibujar la escena en pantalla, su trabajo es el de manipular los fondos y es por ello que tiene 512K divididos en 4 bloques de 128K, el VDP2 puede manipular los datos en sus direcciones de memoria asignadas y el framebuffer asignado el VDP1 lo trata como un buffer trasero al cual no puede manipular pero si leer.
El dibujado en pantalla en el caso de Saturn se produce de atrás hacía adelante (siendo los sprites generados por el VDP1 los últimos en ser dibujados en pantalla), el VDP2 tiene asignados 4K de memoria para almacenar los valores de color para ser mostrados en pantalla, cada 8 ciclos el VDP2 dibuja un pixel nuevo en pantalla a través de 3 direcciones de memoria especiales asignadas para las coordenadas cartesianas y el color en pantalla. Saturn carece completamente de buffer de profundidad por lo que es completamente incapaz de saber cuando un pixel se superpone a otro, simplemente los dibuja todos.
El VDP2 realmente dibuja de forma sistemática de arriba a abajo y de izquierda a derecha, su contador de programa doble siempre apunta al siguiente sprite en cuanto a la resolución, cualquier cambio en la posición del próximo pixel se traduce como un salto por lo que es necesario controlar dichos saltos para evitar que zonas de la imagen se queden sin dibujar.
¿Era impotente Saturn?
La verdad es que no, si comparabas los juegos de PC aparecidos contemporeaneamente a la salida de Saturn (1994-1995) entonces veías que la consola de Sega hacía un muy buen papel, los juegos de primera generación no eran menos complejos que Descent, el cual apareció por aquellas fechas, no obstante fue a partir de 1996 que se empezó a ver las limitaciones que tiene la consola en cuanto al 3D.
¿Era difícil de programar?
Saturn se programaba en C, curiosamente los programas a ejecutar por parte de los diferentes procesadores de apoyo eran enviados en forma de puntero a estructura que incluían dentro los diferentes comandos de cada uno de los procesadores de apoyo, inicialmente eran los desarrolladores los que tenían que controlar ciertos aspectos del hardware pero a medida que fue pasando el tiempo Sega fue descargando trabajo a los desarrolladores así como el permitir el uso de herramientas middleware como 3D Studio para la generación de escenas en 3D.
El único problema real que tenía Saturn era la combo SCU+SH2, en PlayStation existía un procesador para el calculo de la geometría 3D que es el GTE, en el caso de la consola de Sony solo era necesario enviar los datos de cada vertice para que fueran procesados de forma automática y a tiempo real, en el caso de Saturn se tenía que cargar un programa para el SCU.