Gráficos en Consolas Antiguas (XV): Sega Saturn

Ahora le toca el turno a la 32 bits de Sega

sega_saturn_2s

La 32 bits de Sega no se pensó para competir contra la PlayStation de Sony en sus inicios sino contra la potencial amenaza que representaba 3DO y esto es importante para entender su hardware y como fue diseñado.

CPU

La CPU de Saturn es un doble Hitachi SH2 a 28Mhz aproximadamente, se trata del mismo procesador utilizado por la 32X pero a mayor velocidad y con una mayor cantidad de memoria RAM disponible, la potencia combinada de ambos chips es de 50 MIPS y al igual que ocurría con la 32X el segundo SH2 no hacía de CPU en conjunto con el primero sino que se utilizaba para la generación de la escena con la ventaja añadida de un sistema gráfico mucho más avanzado.

En comparación con la 3DO el SH2 maestro era el equivalente al ARM60 mientras que el segundo SH2 era el equivalente al co-procesador matemático. Ninguna de las dos consolas soportaba triangulos para componer las escenas 3D a tiempo real (por la forma en la que estaban diseñados sus Blitters) por lo que utilizaban Quads para componer las escenas en 3D a tiempo real, algo que se convertiría en una enorme desventaja para Saturn y un error de cálculo enorme para Sega. El caso es que Saturn es tomada como un mal hardware cuando salio al mercado, eso no es más que pura propaganda, comparada con lo que fue PlayStation si que era un hardware que se quedaba corto pero comparado con lo que Sega penso que sería su rival no se queda corta.

La consola de Sega era muy superior al estandar 3DO en lo que al 3D se refiere ya desde el principio.

Que si, que elDaytona USA de Saturn se ve horrible, lo se. Pero si miramos las cosas con perspectiva, el juego movía 60.000 pol/seg a una tasa de 20 fotogramas por segundo siendo un juego de lanzamiento de la consola, el original para Model 2 (un sistema mucho más capaz y pensado para el 3DO) movía 300.000 pol/seg a 60fps. Obviamente el juego se le quedaba muy grande a la Saturn pero… ¿Como es que a Sega le dio por presentar Saturn con este juego si la diferencia con el original era tan notable Pues por el hecho que esos 60.000 pol/seg era una cifra MUY SUPERIOR a lo que podían hacer Jaguar y 3DO, con las que Saturn limpiaba el suelo sin problemas.

El mayor handicap del doble Hitachi SH2 es que compartían bus directo hacía el SCU/DMA y por lo tanto no podían trabajar en paralelo, por lo que cuando los datos no se encontraban en la cache por lo que un procesador acababa por limitar al otro a la hora de procesar. Sí Sega hubiese mantenido un canal de memoria simultaneo para cada uno de los procesadores entonces hubieran sacado más rendimiento y menos dolores de cabeza en la programación de la consola.

SCU/DMA

No hace falta que os explique lo que es un DMA, de anteriores entradas lo sabéis. Dado que la memoria de la consola funcionaba a 14.3 Mhz, el SCU funcionaba a esa velocidad de reloj dado que era la velocidad de la RAM del sistema por lo que la comunicación entre los diferentes componentes del sistema se realiza a esa velocidad.

Saturn tiene tres buses internos distintos:

  • CPU Bus: Comunica directamente a los SH2 con la RAM principal sin pasar por el SCU.
  • Bus A: Utilizado para acceder al CD-ROM y el puerto de cartuchos, es controlado por el el SCU.
  • Bus B: Utilizado para comunicar la CPU con el VDP1, el VDP2 y el sistema de sonido de la consola.

La particularidad del SCU  es que contine un DSP por lo que se podía utilizar en paralelo a la CPU para operaciones matriciales, Existe la posibilidad de que el DSP dentro del SCU fuese originalmente el co-procesador matemático de la consola antes de colocar el segundo SH2 y ver que daba mejor rendimiento en ciertas tareas por lo que en la consola final el SCU quedo para gobernar los accesos a memoria y entre los diferentes elementos dejando el DSP interno en desuso y como legado de un diseño primigenio de la consola.

Expansión de memoria

Aunque no llegaron a occidente, Saturn tuvo una serie de cartuchos de expansión de memoria que fueron aprovechados por una serie de juegos.

KOF-95-Saturn-ROM-cartridge-1041428

El primero de 1MB y lanzado por SNK para su KOF95 añadía 1MB de ROM (no de RAM) que almacenaba en su interior los patrones/sprites más utilizados por el juego y aceleraba enormemente su carga, claro esta que la expansión de memoria más famosa fue la de Capcom:

SaturnExpansion4MB

 

Los 4MB adicionales no se sumaban a la memoria RAM principal sino que se accedían a través de un canal secundario, provocando que no hubiese contención con la CPU a la hora de acceder a la RAM principal.Como se puede ver en el siguiente diagrama de arriba del sistema el puerto de cartuchos se encuentra en un canal distinto a la RAM principal

VDP1

El VDP1 es un Blitter  de una naturaleza casi igual al subsistema gráfico de 3DO, con la diferencia que no tiene ningún tipo de contención con la CPU a la hora de acceder a la memoria RAM ya que la lista de comandos y los patrones/sprites/quads en pantalla se encuentran en una memoria de 512KB que el VDP1 lee para crear el búfer de imagen, el cual al igual que el 32X es doble solo que aquí el tamaño es de 256KB por cada uno de los búfers de imagen por lo que el total de memoria del VDP1 es de 1MB. Gracias al doble búfer y el hecho de no tener que leer de la RAM principal el nivel de contención de la memoria y el procesador gráfico era mucho menor, esto le daba una tasa de relleno mucho mayor.

No obstante el VDP1 tenia dos limitaciones muy grandes, el primero de ellos la falta de una cache de texturas, lo cual fue clave en el caso de PlayStation para alcanzar una alta tasa de relleno para los juegos, el segundo de ellos es la incapacidad para trabajar con triangulos para la generación de escenarios en 3D cuando el triangulo había sido siempre el estandar. El motivo de ello es que como he dicho antes la consola se diseño para competir contra 3DO y no contra la PlayStation de Sony por lo que el VDP1 estaba pensado para manipular patrones/sprites los cuales tienen cuatro vertices de referencia y no triangulos que es lo que se ha usado siempre como estandar en los gráficos en 3D a tiempo real.

Es por ello que los grafistas que hacían juegos para Saturn tenían que rascarse el coco para trabajar con modelados hechos por polígonos con cuatro vertices.

Esta particularidad no era muy bien vista por los desarrolladores que veían como todo el motor 3D que tenían desarrollado para otras consolas tenía que ser re-pensado en el caso de Saturn, así como los modelados de personajes en 3D y demás. Por otro lado hay que diferenciar entre los quads que son generados y polígonos que son dibujados, en el caso de Saturn (y en extensión 3DO) cuando las especificaciones de Saturn hablan de polígonos realmente se refieren a la cantidad de quads/patrones/sprites que el VDP1 puede plasmar en pantalla cada segundo. Cuando el VDP1 dibuja directamente sin tener que leer una textura de los 512KB, la parte de su memoria que es el búfer de imagen, entonces su tasa de dibujado es de 500K patrones/sprites/quads por segundo, cuando tiene que hacer una operación de lectura adicional para el mapeado de texturas la cosa baja a los 200K patrones/sprites/quads por segundo.

La configuración de memoria del VDP1 era de 16+16 bits (lectura+escritura) accediendo a los dos bancos al mismo tiempo, la memoria de cada uno de los bancos funcionaba a 14.3Mhz por lo que la tasa de relleno era de 14.3 Mpixeles/seg, algo que si miramos la siguiente tabla resulta un cuello de botella enorme ya que el VDP1 podía generar sobre su búfer de imagen un pixel por cada ciclo de reloj:

VDP12

 

¿Que hubiese pasado si el VDP1 hubiese tenido a su disposición una memoria a 28.6 Mhz? Pues claramente el rendimiento de la consola hubiera crecido enormemente de cara al 3D y aunque la limitación de los quads hubiese seguido existiendo la tasa de fotogramas por segundo de los juegos en 3D hubiese sido mucho mayor. El problema es que incluso con la memoria a la velocidad adecuada Saturn hubiese seguido con una ligera desventaja en cuanto a la velocidad de relleno respecto a la PlayStation de Sony y es que comparar la GPU de PSX con el VDP1 de Saturn (las dos piezas equivalentes en ambas consolas) hace que la consola de Sega palidezca pero es que esta no fue diseñada en principio para el 3D sino para ser una bestialidad en cuanto a 2D y todo ello gracias al segundo procesador gráfico, el VDP2.

VDP2

El VDP2 es llamado “Background Processor”, su trabajo es el de generar la pantalla final combinando los diferentes planos/fondos con el búfer de imagen generado por el VDP1, tiene a su disposición unos 512KB de memoria divididos en cuatro bancos de 128KB cada uno de ellos a los que puede acceder para leer o escribir.

  • Puede leer el búfer frontal (mientras el VDP1 genera el búfer trasero) del VDP1 y manipularlo como si fuese un patrón/sprite con muy pocas instrucciones al vuelo y sin intervención de la CPU. Por ejemplo puede rotar a tiempo real todo el búfer de imagen sin que la CPU y el VDP1 tengan que calcular y rotar uno por uno los patrones/sprites.
  • Puede generar cuatro planos de scroll y dos planos rotatorios en una misma imagen: VDP2
  • Si se utilizan dos planos de rotación al mismo tiempo entonces los planos de scroll normales no se pueden realizar.
  • El VDP2 puede aplicar efectos de transparencia sobre los diferentes elementos, eso si, la transparencia es del tipo aditiva y no multiplicativa por lo que su precisión es menor. Este truco es utilizado por juegos como Burning Rangers y Grandia para aplicar transparencias.
  • El VDP2 puede operar a nivel de pixel, patron/sprite/quad, búfer de imagen entero a la hora de realizar una manipulación.

La siguiente serie de videos demuestran las virguerias visuales a nivel de gráficos en 2D que se podían hacer gracias al VDP2.

Pese a que el VDP2 esta conectado al VDP1 es posible renderizar la escena prescindiendo por completo del VDP1 ya que el SCU/DMA da acceso directo al VDP2 hacía la CPU y la RAM principal. Algunos juegos renderizan directamente sobre el VDP2 sin tocar el VDP1 para aprovechar la enorme ventaja que tiene el VDP2 es su mayor ancho de banda y por tanto el hecho de poder dibujar la escena a 28.6 Mpixeles/seg de tasa de relleno. Sea cual sea el caso en Saturn el hecho que el VDP2 sea el que este conectado a la salida de video hace que no sea posible prescindir por completo del VDP2 en la composición de la escena.

Conclusión.

Saturn es una consola que si hubiese corregido algunos errores de diseño no habría tenido los problemas que tuvo. En primer lugar el hecho de darle al segundo SH2 un pozo de memoria propio para la geometría de la escena hubiese subido la tasa de polígonos en los gráficos en 3D, en segundo lugar el soporte para triangulos en el VDP1 hubiese sido un acierto, así como asignarle una memoria mucho más rápida y el hecho de poder dibujar en pantalla directamente sin intervención del VDP2, dejando el VDP2 eso si, para gráficos en 2D. Aunque lo mejor hubiese sido crear un SuperVDP de 1MB con las capacidades de ambos, pero Sega se obsesiono en que no quería chips únicos muy grandes sino muchos pequeños por el hecho que supuestamente le costaban más baratos, eso fue un error enorme ya que al final acabaron sobrecomplicando la consola y haciendo que esta fuese mucho más cara.

Eso es todo, nos vemos en la siguiente entrada.

Anuncios