SATURN - SEGUNDA APROXIMACIÓN: Purgatorio
En este diagrama se ven nuevos detalles. Arriba el bloque de CPU, abajo vídeo y sonido, a la derecha el puerto de cartucho y la entrada del CD-ROM.
BLOQUE CPU
fuente: http://pdf.datasheetcatalog.com/datashe ... Xwuttu.pdf
Ampliemos lo que sabemos de los procesadores. Tenemos 2 procesadores Hitachi SH-2 como CPU de la Saturn. A diferencia de las CPUs que tenemos en ordenadores y móviles hoy día, no es una CPU dual, si no que ambos procesadores están montados siguiendo un esquema maestro-esclavo. El SH-2 maestro es el que decide cuándo y cómo va a trabajar el SH-2 esclavo. Ambos comparten la memoria RAM principal. Ambos se conectan a ella a través del mismo bus, llamado “bus de sistema” .
Por tanto tenemos un sólo bus que conecta CPUs, RAM, ROM, SMPC y SCU. Cuando cualquiera de estos elementos intente conectarse al bus, sí otro también lo intenta, se produce una colisión y se hará un arbitraje del cual saldrá un ganador que tendrá acceso al bus, los otros deberán esperar.
En el caso de los SH-2, será la CPU maestra siempre la que gane y consiga el acceso al bus. La esclava esperará. No obstante, sí es la esclava la que accede previamente a memoria, será la maestra la que tenga que esperar. Nótese que la CPU esclava es exactamente igual que la maestra y puede hacer lo mismo. No está limitada en absoluto.
Por tanto y debido a la forma en que ambas CPUs están conectadas, a menudo un SH-2 tiene que esperar a que el otro termine. Para evitar esto cada SH-2 tiene una pequeña memoria propia para poder trabajar internamente, llamada caché, de 4 Kbytes de tamaño. Es responsabilidad del programador que su programa se apoye en esos 4KB para trabajar y evitar colisiones, también debe pensar el programador en minimizar la espera.
Podéis encontrar más información sobre los SH-2 en el análisis no técnico de 32X, pues es la misma doble CPU a menor frecuencia.
No obstante ampliaremos lo dicho allí con una pincelada, y es que los SH-2 tienen una potente unidad aritmética interna, que se encarga de hacer operaciones matemáticas a gran velocidad. En concreto tenemos en cada chip 4 unidades de cálculo especializadas (2 multiplicadoras, 2 divisoras), además es capaz de hacer una operación compleja llamada MAC (multiplica y acumula) de forma muy rápida. Esta operación es muy útil para cálculos relacionados con el 3D.
Hablemos ahora de la RAM principal. Recordemos que tenemos 2MB, es decir, 2048KB.
La RAM principal está formada por chips de distinta tecnología. Los SH-2 pueden manejar varios tipos de memoria sin problemas así que SEGA decidió mezclar una memoria más moderna, cara y rápida (SDRAM) con otra más lenta y económica (FPM RAM).
De esta forma tenemos una memoria “alta” y una memoria “baja”, cada una con 1 MB en total. La idea es poner el código y los datos más críticos en la memoria “alta” y los otros datos en la memoria “baja”. Es el programador el que decide cómo usar la memoria “alta” y la “baja”, no es un proceso automático.
Hay que tener en cuenta que el sistema se reserva parte de esta memoria para sí mismo, por eso vemos “1.5MB work RAM” en el diagrama, en la práctica es lo que tiene el programador para su programa.
Vamos a ver ahora un elemento no comentado hasta ahora. El SCU (System Control Unit).
El SCU es un elemento que conecta los distintos bloques (CPU,VIDEO,SONIDO,otros) de forma transparente. De forma que se pueden comunicar a pesar de que cada uno de ellos funciona de manera distinta. Además posee un DSP y un controlador DMA.
El SCU le hace la vida más fácil al desarrollador y a los SH-2. Cuando un procesador tiene que comunicarse con un elemento “externo” al bloque CPU, no necesita hacer ninguna gestión extraña, hace exactamente lo mismo que si fuera interno. ¿Cómo? con un mapa de memoria unificado.
El mapa de memoria está dividido en bloques o tramos, cada elemento HW tiene un tramo reservado para sí mismo. Esto es, la memoria principal tendrá 2MB, habrá un bloque reservado para la RAM del VPD1, otro para la RAM del VDP2, un bloque para un framebuffer y un segundo bloque para el otro framebuffer, etc.
Imaginemos que un SH-2 quiere mandar un dato al VPD1. Lo que hace es ejecutar una instrucción con un dato y una dirección de memoria, en este caso de la zona reservada para el VPD1. El SCU transmitirá el dato al lugar adecuado a través de los distintos buses del sistema.
No es que tengamos una memoria real que lo agrupe todo, simplemente aprovechamos que tenemos la capacidad teórica de direccionar todas esas direcciones.
Así que el SH-2, al ejecutar la instrucción anterior, le dice al SCU que quiere escribir allí, y es el SCU el que “traduce” esa petición al elemento que corresponda.
Además, el SCU tiene un controlador DMA que tiene la capacidad de enviar datos entre distintos elementos sin intervención de los SH-2, y mucho más rápido. Por ejemplo podemos enviar datos de la memoria principal a la memoria del VDP1 mientras los SH-2 están efectuando otros trabajos.
Otro elemento presente en el bloque CPU es el SMPC.
Por tanto y debido a la forma en que ambas CPUs están conectadas, a menudo un SH-2 tiene que esperar a que el otro termine. Para evitar esto cada SH-2 tiene una pequeña memoria propia para poder trabajar internamente, llamada caché, de 4 Kbytes de tamaño. Es responsabilidad del programador que su programa se apoye en esos 4KB para trabajar y evitar colisiones, también debe pensar el programador en minimizar la espera.
Podéis encontrar más información sobre los SH-2 en el análisis no técnico de 32X, pues es la misma doble CPU a menor frecuencia.
No obstante ampliaremos lo dicho allí con una pincelada, y es que los SH-2 tienen una potente unidad aritmética interna, que se encarga de hacer operaciones matemáticas a gran velocidad. En concreto tenemos en cada chip 4 unidades de cálculo especializadas (2 multiplicadoras, 2 divisoras), además es capaz de hacer una operación compleja llamada MAC (multiplica y acumula) de forma muy rápida. Esta operación es muy útil para cálculos relacionados con el 3D.
Hablemos ahora de la RAM principal. Recordemos que tenemos 2MB, es decir, 2048KB.
La RAM principal está formada por chips de distinta tecnología. Los SH-2 pueden manejar varios tipos de memoria sin problemas así que SEGA decidió mezclar una memoria más moderna, cara y rápida (SDRAM) con otra más lenta y económica (FPM RAM).
De esta forma tenemos una memoria “alta” y una memoria “baja”, cada una con 1 MB en total. La idea es poner el código y los datos más críticos en la memoria “alta” y los otros datos en la memoria “baja”. Es el programador el que decide cómo usar la memoria “alta” y la “baja”, no es un proceso automático.
Hay que tener en cuenta que el sistema se reserva parte de esta memoria para sí mismo, por eso vemos “1.5MB work RAM” en el diagrama, en la práctica es lo que tiene el programador para su programa.
Vamos a ver ahora un elemento no comentado hasta ahora. El SCU (System Control Unit).
El SCU es un elemento que conecta los distintos bloques (CPU,VIDEO,SONIDO,otros) de forma transparente. De forma que se pueden comunicar a pesar de que cada uno de ellos funciona de manera distinta. Además posee un DSP y un controlador DMA.
El SCU le hace la vida más fácil al desarrollador y a los SH-2. Cuando un procesador tiene que comunicarse con un elemento “externo” al bloque CPU, no necesita hacer ninguna gestión extraña, hace exactamente lo mismo que si fuera interno. ¿Cómo? con un mapa de memoria unificado.
El mapa de memoria está dividido en bloques o tramos, cada elemento HW tiene un tramo reservado para sí mismo. Esto es, la memoria principal tendrá 2MB, habrá un bloque reservado para la RAM del VPD1, otro para la RAM del VDP2, un bloque para un framebuffer y un segundo bloque para el otro framebuffer, etc.
Imaginemos que un SH-2 quiere mandar un dato al VPD1. Lo que hace es ejecutar una instrucción con un dato y una dirección de memoria, en este caso de la zona reservada para el VPD1. El SCU transmitirá el dato al lugar adecuado a través de los distintos buses del sistema.
No es que tengamos una memoria real que lo agrupe todo, simplemente aprovechamos que tenemos la capacidad teórica de direccionar todas esas direcciones.
Así que el SH-2, al ejecutar la instrucción anterior, le dice al SCU que quiere escribir allí, y es el SCU el que “traduce” esa petición al elemento que corresponda.
Además, el SCU tiene un controlador DMA que tiene la capacidad de enviar datos entre distintos elementos sin intervención de los SH-2, y mucho más rápido. Por ejemplo podemos enviar datos de la memoria principal a la memoria del VDP1 mientras los SH-2 están efectuando otros trabajos.
Otro elemento presente en el bloque CPU es el SMPC.
Es el chip que “resetea” la consola al pulsar el botón adecuado. Es capaz de encender/apagar los distintos chips de la consola y establecer la frecuencia de trabajo de cada uno.
Este chip es el que recibe las entradas de los mandos y es el encargado de grabar partidas en la memoria interna de la consola.
Es capaz de guardar la fecha (gracias a la batería que tenemos en la placa como en los PCs), y dar la fecha como dato al sistema si el programador desea usarla en su juego.
VDP significa video digital processor, sabemos hasta ahora que el VDP1 dibuja los objetos y el VDP2 los fondos. Luego se combinan para la imagen final. Ampliemos.
El VDP1 (Hitachi) trabaja a 28MHz. Hasta 32768 colores (256 en alta resolución). Su memoria es de 512KB, además tiene acceso a los framebuffers, dos memorias de 256 KB cada una.
El VDP2 (Yamaha) trabaja a 28MHz. Hasta 16M de colores. Su memoria es de 512 KB (dividida en 4 bancos de 128KB).
La memoria de los VDPs se llama VRAM (vídeo RAM), es una memoria muy rápida.
Tenemos que entender que para un procesador dibujar es poner los datos adecuados en una memoria. Más tarde el HW leerá esa memoria y según los valores que lea, sacará, por cada pixel, un color. Ambos VDPs tienen varios “lienzos” donde “pintar”, combinándolos resultará un lienzo final que se llevará a la pantalla. Además de su memoria, los VPDs tienen ciertos registros que definen cómo se “pinta” en sus lienzos.
El VDP1 es un chip que puede trabajar, según reza la documentación oficial de SEGA, con patrones. Patrones son líneas, polilíneas, polígonos (planos) o polígonos texturados, a los que llamaremos sprites.
Se dice que Saturn trabaja con quads (“quadrangle”, cuadrilátero). Se utiliza erróneamente para definir todo lo que pinta la Saturn. SEGA define un polígono texturado como un sprite (similar al sprite de las consolas clásicas), no como un quad.
Sin embargo, cuando hablamos de cómo representar un entorno 3D, sí que vamos a usar “quad”. Se refiere al peculiar forma de trabajar de Saturn en 3D, usando cuadriláteros (sean texturados o no), en oposición al uso de triángulos, que es el estándar.
El VDP1 utiliza su propia memoria de 512KB, y por tanto es independiente del procesador, a diferencia del VDP de 32X que tenía poca autonomía.
El programador le pasa al VDP1 una lista de comandos, el VDP1 lee esa lista y escribe (dibuja) en el framebuffer. También guardamos los bitmaps que necesitemos en dicha memoria.
El VDP1 puede escalar, estirar, rotar, recortar y espejar un sprite. Es decir, tenemos un “motor” HW que no necesita del procesador principal (a diferencia de Megadrive o de 32X):
Cuando hacemos ampliaciones, rotaciones o estiramientos, VDP1 realiza un antialiasing o suavizado para evitar pixelaciones y rellenar los “huecos” que puedan generarse.
Por otro lado el VDP1 puede crear “gratis” tramas con el patrón que nosotros queramos. Es decir, le damos un patrón y al sprite en cuestión lo “marcamos” para aplicar la trama, Saturn “tramará“ dicho sprite automáticamente. El uso de las tramas lo veremos luego, resumiendo diremos que simulan transparencias.
Este chip es el que recibe las entradas de los mandos y es el encargado de grabar partidas en la memoria interna de la consola.
Es capaz de guardar la fecha (gracias a la batería que tenemos en la placa como en los PCs), y dar la fecha como dato al sistema si el programador desea usarla en su juego.
BLOQUE VIDEO
VDP significa video digital processor, sabemos hasta ahora que el VDP1 dibuja los objetos y el VDP2 los fondos. Luego se combinan para la imagen final. Ampliemos.
El VDP1 (Hitachi) trabaja a 28MHz. Hasta 32768 colores (256 en alta resolución). Su memoria es de 512KB, además tiene acceso a los framebuffers, dos memorias de 256 KB cada una.
El VDP2 (Yamaha) trabaja a 28MHz. Hasta 16M de colores. Su memoria es de 512 KB (dividida en 4 bancos de 128KB).
La memoria de los VDPs se llama VRAM (vídeo RAM), es una memoria muy rápida.
Tenemos que entender que para un procesador dibujar es poner los datos adecuados en una memoria. Más tarde el HW leerá esa memoria y según los valores que lea, sacará, por cada pixel, un color. Ambos VDPs tienen varios “lienzos” donde “pintar”, combinándolos resultará un lienzo final que se llevará a la pantalla. Además de su memoria, los VPDs tienen ciertos registros que definen cómo se “pinta” en sus lienzos.
VDP1
El VDP1 es un chip que puede trabajar, según reza la documentación oficial de SEGA, con patrones. Patrones son líneas, polilíneas, polígonos (planos) o polígonos texturados, a los que llamaremos sprites.
Se dice que Saturn trabaja con quads (“quadrangle”, cuadrilátero). Se utiliza erróneamente para definir todo lo que pinta la Saturn. SEGA define un polígono texturado como un sprite (similar al sprite de las consolas clásicas), no como un quad.
Sin embargo, cuando hablamos de cómo representar un entorno 3D, sí que vamos a usar “quad”. Se refiere al peculiar forma de trabajar de Saturn en 3D, usando cuadriláteros (sean texturados o no), en oposición al uso de triángulos, que es el estándar.
El VDP1 utiliza su propia memoria de 512KB, y por tanto es independiente del procesador, a diferencia del VDP de 32X que tenía poca autonomía.
El programador le pasa al VDP1 una lista de comandos, el VDP1 lee esa lista y escribe (dibuja) en el framebuffer. También guardamos los bitmaps que necesitemos en dicha memoria.
El VDP1 puede escalar, estirar, rotar, recortar y espejar un sprite. Es decir, tenemos un “motor” HW que no necesita del procesador principal (a diferencia de Megadrive o de 32X):
Cuando hacemos ampliaciones, rotaciones o estiramientos, VDP1 realiza un antialiasing o suavizado para evitar pixelaciones y rellenar los “huecos” que puedan generarse.
Por otro lado el VDP1 puede crear “gratis” tramas con el patrón que nosotros queramos. Es decir, le damos un patrón y al sprite en cuestión lo “marcamos” para aplicar la trama, Saturn “tramará“ dicho sprite automáticamente. El uso de las tramas lo veremos luego, resumiendo diremos que simulan transparencias.
Es posible aplicar algunos efectos sobre los sprites (como transparencias, iluminación, mezclas de colores) pero esto consume muchos ciclos del VDP1, por tanto hay que usarlo con cuidado.
También puede crear un sombreado Gouraud interpolando los colores en cada vértice de un polígono:
Este tipo de sombreado se usaba para disimular lo “toscos” que eran los modelos 3D de la época, también para simular iluminación. Bien usado daba gusto verlo.
El VDP1 tiene acceso a un doble framebuffer. Escribe en uno de ellos mientras el otro es leído por el VDP2. Cuando termina, cambia al otro framebuffer, de esta forma no necesita esperar y puede tener un gran rendimiento. Por defecto se muestran 60 imágenes por segundo, pero es posible cambiar manualmente este parámetro.
VPD2
El VDP2 es un chip muy versátil. La idea es que el VDP2 cree los fondos, pero además el VDP2 recoge el contenido de uno de los framebuffers y lo mezcla con su propio contenido para crear la imagen final. En su memoria guardará, además de los comandos, los tiles o bitmaps que necesite para crear sus capas.VDP2 soporta hasta 5 capas (los lienzos que mencionamos antes), 4 de ellas capas de scroll y la última es la capa de backplane, que se situaría siempre al “fondo del todo”.
Una capa de scroll puede tener varios tipos de scroll (horizontal, vertical, ambos a la vez), es capaz de moverlos, rotarlos y escalarlos, puede aplicar efectos sobre estos fondos como la transparencia, efectos de raster, blur, etc. Puede aplicar sobre una capa un escalado para tener un suelo “infinito” ya sea con texturas o tiles (tipo modo 7).
Como en el VDP1, el programador le pasa al VDP2 una serie de comandos para que trabaje independiente del resto del sistema.
Además de sus capas, el VDP2 trabaja con uno de los framebuffer como si fuese una capa más (aquella en la que el VDP1 no está trabajando), puede manipularla a su antojo (independientemente del VDP1 y de la CPU). Por ejemplo puede rotarlo. Esto parece una tontería, pero si tenemos una pantalla donde todo “gira”, nos ahorra tener que rotar cada uno de los sprites con el VDP1, el ahorro es tremendo.
VDP2 puede hacer diversos efectos sobre sus capas (transparencias, disolver una capa progresivamente, crear sombras, etc.) A diferencia del VDP1, el VDP2 puede hacer estos efectos de forma muy “barata”, es decir, es muy rápido haciéndolo, mucho más que el VPD1.
El VDP2 puede operar a nivel de pixel/patrón/búfer-de-imagen-entero a la hora de realizar una manipulación.
BLOQUE SONIDO
El SCSP (Saturn Custom Sound Processor) puede aplicar varios efectos (como reverberación, ecos, distorsiones, filtros,etc) a cada uno de sus 32 canales PCM o 8 FM.
Playstation sólo soportaba 24 canales PCM por ejemplo.
El Motorola 68EC000 funciona a 11.3MHz y es el encargado de todo lo relacionado con el MIDI. MIDI es un estándar para crear música, permite tocar varios instrumentos desde un solo dispositivo, gracias a esto un músico no necesita saber nada de programación (como sucedía con algunas consolas antecesoras a Saturn).
OTROS ELEMENTOS
Efectivamente podemos conectar un cartucho de memoria para ampliar la memoria principal de Saturn. Gracias al SCU los SH-2 no necesitan hacer nada extraño para usarla, (parte) de su contenido podrá accederse dentro del mapa de memoria (tiene reservados 32MB).
Pero hay que tener en cuenta que el acceso a esta memoria estará limitada primero por el bus “A” (que es de 16 bits) y luego porque el acceso a los datos estarán bajo arbitraje, ya que acceder al cartucho implica acceder al bus de Sistema y al bus A
La diferencia entre un cartucho y el CD-ROM es que el cartucho se puede tratar como una memoria (lenta) más mientras que el CD-ROM requiere volcar los datos a memoria.
¿Qué hay de las escenas de vídeos pre-renderizadas? Estamos en el punto álgido de los juegos con vídeos metidos de-cualquier-manera-porque-vende.
Aquí tenemos dos posibilidades. Una es usar el códec por defecto que es CINEPAK, que da un resultado bastante pobre pero para salir del paso nos vale. Otra es usar el cartucho MPEG para reproducir por HW vídeo codificado para este códec, con resultados muy superiores.
Inconveniente: El cartucho era MUY caro.
Independientemente del elegido, el vídeo lo vamos a tratar como una capa del VDP2, por lo que podemos combinar vídeo con imágenes de un juego sin problemas
Hay otras posibilidades, no dejéis de ver éste vídeo, que incluye otros códecs que fueron usados y ejemplos de juegos (poned los subtítulos)
https://www.youtube.com/watch?v=ev7x8MwLq2A
En esta segunda aproximación sí que hemos visto un salto importante respecto a los sistemas de 16 bits. Aunque algunas cosas ya existían en estos sistemas, ahora lo tenemos elevado al cubo, con muchas facilidades ya integradas en el sistema.
La forma de trabajar del sistema gráfico de Saturn, por etapas, es ideal para juegos 2D tradicionales, hasta ahora no hemos tocado el tema 3D en gráficos.
Hay que decir que para un juego tradicional 2D, el VDP1 va sobradísimo, en Megadrive tenemos unos 80 sprites en pantalla como máximo, en Saturn 16383 sin aplicar efectos (vamos, antes llenas la pantalla que superas el límite). El VDP2 hace cosas nunca vistas en una consola Sega.
Independientemente del elegido, el vídeo lo vamos a tratar como una capa del VDP2, por lo que podemos combinar vídeo con imágenes de un juego sin problemas
Hay otras posibilidades, no dejéis de ver éste vídeo, que incluye otros códecs que fueron usados y ejemplos de juegos (poned los subtítulos)
https://www.youtube.com/watch?v=ev7x8MwLq2A
CONCLUSIONES
En esta segunda aproximación sí que hemos visto un salto importante respecto a los sistemas de 16 bits. Aunque algunas cosas ya existían en estos sistemas, ahora lo tenemos elevado al cubo, con muchas facilidades ya integradas en el sistema.
La forma de trabajar del sistema gráfico de Saturn, por etapas, es ideal para juegos 2D tradicionales, hasta ahora no hemos tocado el tema 3D en gráficos.
Hay que decir que para un juego tradicional 2D, el VDP1 va sobradísimo, en Megadrive tenemos unos 80 sprites en pantalla como máximo, en Saturn 16383 sin aplicar efectos (vamos, antes llenas la pantalla que superas el límite). El VDP2 hace cosas nunca vistas en una consola Sega.
Leave a Comment