SEGA 32X: Análisis /técnico de consola y juegos

32X fue el add-on para Megadrive que pretendía ser una forma barata de añadir capacidades poligonales y mejores gráficos y sonido. Tuve la megadrive y nunca tuve 32X, así que siempre tuve curiosidad por ver lo que era capaz de hacer.
Lo cierto es que es un HW muy curioso y voy a tratar de mostrar su funcionamiento interno de una forma sencilla. No voy a entrar en detalles de bajo nivel, no se pretende, simplemente a ver el funcionamiento genérico.

La idea, como siempre, aprender algo nuevo, por Internet hay bastante información confusa. Así podremos contestar a la preguntas típicas con un poco de conocimiento:
¿Es un add-on que depende de la MD o es casi un sistema completo?
¿Era un sistema difícil de programar?
¿Acertaron al cancelar 32X?
¿Sus juegos representan el techo del HW o hay espacio para la mejora?

32X Especificaciones

• CPUs: Dual SH2 RISC, aprox a 23MHz
• RAM principal: 256KB
• VRAM (vídeo RAM): 256KB (2x128)
• Resolución: 320x224px o 320x240px (PAL)
• Profundidad de color: 256 colores / 32768 colores.
• Sonido: PWM de 2 canales (estéreo)

Antes de ver como funciona vamos a ver el esquema general del 32X:



Para el que no lo ha visto nunca, una explicación rápida:

- La 32X se conecta por el puerto de cartucho a la MD y a su vez tiene un puerto de cartucho propio, donde poder conectar cartuchos de MD o de 32x.
- La salida de vídeo de la MD se conecta como entrada a la 32X y ésta tiene su propia salida de vídeo.


Obviamos, para simplificar:
Fuentes de alimentación.
El estéreo de la MD.
Mega CD.

Veamos internamente el 32X:

Cartucho 32X

Es un cartucho ROM “normal”, similar a los de MD, no tiene chips tipo SVP.

El contenido del cartucho puede ser leído tanto por el 32X como por la Megadrive (68000 y Z80) pero la 32X tiene prioridad en caso de que ambas lo intenten a la vez. Eso sí, si la MD accede y está leyendo el cartucho, si el 32X quiere acceder al cartucho, debe esperar a que termine la MD.

Al insertar el cartucho y encender la consola, lo usual es copiar del cartucho (usualmente llamado ROM) los recursos (sprites, tiles, música,etc) que vayamos a necesitar en la RAM del 32X (en el diagrama pone SDRAM), para que el 32X tenga acceso rápido a ellos. Esto es así porque el acceso a la RAM es mucho más rápido que el acceso a la ROM.

Lo mismo se puede decir con respecto a la MD. La MD tiene 64KB de RAM propia, donde puede almacenar lo que necesite para no acceder continuamente a la ROM. Dependiendo de cómo esté diseñado el juego, puede que la MD acceda a menudo al cartucho, esto si no está bien hecho podría penalizar a 32X.
La megadrive no puede acceder directamente a la memoria principal. Tampoco “sabe” que hay 1 o 2 procesadores, simplemente sabe que hay un periférico, el 32X. Afortunadamente la MD se diseñó para ello y entre ambos aparatos hay una serie de registros que permiten a la MD y al 32X intercambiar datos.
Como la ROM puede ser mucho más grande que la RAM, iremos copiando los recursos cuando lo necesitemos (esto es así tanto para 32X como para MD). Por ejemplo, antes de empezar un nivel, copiamos en RAM los tiles y gráficos de ese nivel.

HITACHI SH2

fuente: http://www.datasheetcatalog.com/datashe ... SH-2.shtml


Tenemos 2 procesadores Hitachi SH2 como CPU del 32X. Ambos comparten memoria RAM(SDRAM), es así porque se conectan ambos a través del mismo bus. Cada uno de ellos es MUCHO más potente que el Motorola 68000:

MD: CPU: Motorola 68000 MIPS: 1.3
32X: CPU: Hitachi   1xSH2 MIPS: 25
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 SH2 maestro es el que decide cuándo y cómo va a trabajar el SH2 esclavo, que no puede acceder al bus (y por ende a la memoria principal del 32X) sin su autorización.

Esto es así porque ambas tienen acceso al exterior por un mismo bus, que es común tanto para acceder a la memoria como a otras partes del 32X (p.e. al VDP).

A diferencia de las CPUs multi-núcleo actuales, el trabajo no se va repartiendo si no que es la CPU maestra la que va “encargando” tareas a la CPU esclava. Esta última no puede acceder al bus hasta que la maestra la autorice. Una vez termine una tarea el SH2 esclavo, o si necesita acceder a la memoria principal, avisará primero a la CPU maestra y ésta le dará acceso al bus. La CPU esclava puede hacer lo mismo que la maestra, por ejemplo, acceder al VDP. No está “encerrada”. Pero ambas están conectadas por un sólo bus a todo.

¿Cual es el inconveniente de tener un sólo bus? A menudo un SH2 tiene que esperar a que el otro termine y ceda su turno de acceso al bus, quedándose “a la espera de su turno”. Para evitar esto, en la medida de lo posible, el doble SH2 tiene una pequeña memoria propia, llamada caché, de 4 Kbytes de tamaño, para poder trabajar internamente.

Es curioso pero Hitachi “vende” el SH2 en sus hojas de especificaciones como una CPU de bajo consumo y barata. No como un chip potente. 32X y Saturn salen a la venta en 1994, pero en 1992 este era el roadmap de Hitachi:

Disponibles SH1 y SH2 (SH2 tenía previsto empezar su producción en Octubre de 1993).

En preparación SH3 y SH4 (SH4 fue el procesador de la Dreamcast).

De nuevo, según Hitachi, el SH2 destaca, entre otras cosas, por:

• Capacidad para multiplicaciones/divisiones (ideal para el el cálculo de coordenadas/transformaciones 3D)
• Se puede adquirir con configuración dual (la de 32X y Saturn, precisamente).

Este diagrama es muy curioso, veamos potencia vs consumo en SH2 y chips populares como el Intel 486 y Pentium:

SH2 no era un chip potente, de hecho en el diagrama aparece la versión nominal del SH2 a 28.7MHz (32X iría a 23MHz aprox, Saturn a 28.7MHz), Pentium y 486 obtienen más rendimiento pero consumen bastante más. Y eso implica disipadores y ventiladores, 32X no tenía ventilación activa y por tanto necesitaba un consumo contenido.

32X se vende como consola de 32 bits, pero ¿lo es? Dice Wikipedia que “Los SH2 usan un conjunto de instrucciones de 16 bits, aunque la longitud de los registros y de los buses de datos son de 32 bits, lo que da una excelente densidad de código. Durante su desarrollo, la memoria era bastante cara.”

Lo primero sería preguntarse qué significa que una consola es de "8 bits","16 bits","32 bits",etc.
Normalmente decimos que una consola es de "x" bits si su microprocesador principal trabaja con "x" bits. Nos referimos que ese microprocesador trabaja con registros, instrucciones, buses de direcciones y buses de datos de 16 bits.
Dicho esto parece intuitivo pensar que una consola o un micro ordenador de 16 bits, tenían buses de 16 bits, instrucciones de 16 bits, etc. Todo igual. Sin embargo esto no tiene porqué ser así.

Una consola de 16 bits no tiene porqué trabajar sólo a 16 bits, podría trabajar a 8 bits por ejemplo. Y al revés.

El procesador principal de la MD, el motorola 68000, es considerado comúnmente como procesador de 16 bits ya que sus buses son de 16 bits, pero internamente trabaja con registros de 32 bits (!) y sus instrucciones son de 32bits. ¿Es entonces de 16 o de 32bits? La respuesta os la dejo a vosotros, pero es más la época (la época de los 16bits) que las especificaciones.

Los SH2 hemos dicho que usa instrucciones de 16 bits, sus buses externos son de 16 bits también (pero los internos son de 32bits), pero los registros son de 32bits, y su ALU (la parte del chip que hace sumas,restas, multiplicaciones, etc puede operar a 16 o 32 bits).

Por tanto desde cierto punto de vista podríamos decir que 32X es un addon de 32bits, pero igualmente podríamos decir que es de 16bits.

No obstante, en el contexto de la época, lo que podía hacer 32X está por encima de lo que podían hacer, en general, las consolas de 16bits (con alguna excepción claro).

¿Por qué a 23Mhz y no a 28.7Mhz? Es decir, ¿por qué no poner al máximo el chip y perder potencia? 32X debe funcionar a un múltiplo de la velocidad de MD para que ambas se puedan sincronizar y comunicarse. Veamos porque esto es un poco raro de explicar:

La megadrive parte de un master clock (un oscilador) de 53Mhz (53.6931 NTCS, 53.203 PAL), dividiendo esa frecuencia por 7 obtenemos:

53.6931/7 = 7.67 MHz (Genesis)
53.203/7 = 7.61 MHz (Megadrive)

Por eso el Motorola va a 7.6MHz.

Si ahora multiplicamos la frecuencia del procesador de MD por 3, obtenemos la velocidad a la que va 32X: 23.01136 MHz (NTSC), 22.801467 MHz (PAL)
Si quisiéramos ir un poco más allá, multiplicaríamos la frecuencia del procesador de MD por 4, pero eso nos da 30Mhz, pasándonos de la frecuencia máx de funcionamiento que Hitachi garantizaba.

LA RAM

La memoria RAM aparece en el diagrama como SDRAM. Son un total de 2 Mbits.

Como curiosidad decir que 2 Mbits son 256 KB (kilobytes) (en consola las compañías siempre se daban el tamaño en Mbits por marketing,“más grande mejor”). Hoy día 256 KB nos pueden parecer ridículos, cualquier PC de gama lleva 4 u 8 GB. La MD tenía 64KB y vaya maravillas se hicieron.

La RAM de 32X sólo puede ser accedida por los SH2 del 32X (la MD no puede usar esa RAM).

Interface General (I/F& PWM)

Es el encargado de conectarlo todo.

Desde el punto de vista del 32X, este componente permite a los SH2 leer del cartucho, acceder al VDP y controlar el chip de sonido. Pero además permite a 32X comunicarse con la MD.

Gracias a este componente la MD puede acceder al cartucho, comunicarse con los SH2 e incluso al VDP del 32X.

No he encontrado un diagrama donde ver los diferentes buses que conectan todo, así como su capacidad y velocidad. En algunas webs hay algo de información pero es diferente en cada una así que si alguien postea un diagrama lo añado aquí.

VDP

Es la “tarjeta gráfica” del 32X. Por un lado “dibuja” las imágenes del juego, generadas por los SH2, en los framebuffers (lo explico en el siguiente punto).

Por otro lado este chip controla cómo se combina la imagen generada por la megadrive con la imagen generada por el 32X. Puede poner la de megadrive “por detrás” y la de 32X delante o bien al revés, a gusto del programador. Internamente se dice que 32X “tiene prioridad” si su imagen aparece por delante de la de MD, y viceversa.

Lo habitual y lo recomendado por Sega era que la MD cree el fondo (y gestione su scroll), y la 32X gráficos poligonales delante. Es lo que pasa p.e. con Virtua Fighter 32x

Veamos un diagrama bastante esclarecedor:

Para el que no lo entienda, MD tiene por HW varios planos sobre los que dibujar (Scroll B, Scroll A, Windows, Sprite), cada uno ideado para una cosa determinada. MD crea la imagen y se la manda a 32X.

32X, a su vez, tiene 2 framebuffers (lo veremos en el siguiente punto), elige uno de los dos y combina dicha imagen con recibida de MD, una de las dos tendrá “prioridad” y se pintará por encima de la otra.

La resolución es la misma que la MD, cosa lógica ya que la idea es que ambas colaboren al crear la imagen. La 32X es capaz de sacar 320x224px (NTSC) o 320x240px (PAL).

Si en un determinado momento la 32X no está generando imagen, podemos utilizar cualquier resolución soportada por la MD (que tiene otras además de la anteriores mencionadas). Es lo que ocurre cuando metemos un juego de MD en la 32X, en ese caso solo trabaja la MD pero como la salida de imagen es a través de 32X, la imagen de MD debe respetarse.

32X y su VDP tiene 3 modos de funcionamiento que permiten hasta 32.768 colores por pixel, aunque la mayor parte de los juegos suelen funcionar a 256 colores.

• Modo Packed Pixel: 256 colores. Para cada pixel de la pantalla se guarda un índice que luego buscaremos en una paleta de colores. Puede usarse a pantalla completa. Este sería el modo a usar equivalente en una consola tradicional 16bits.
• Modo Direct Color: Se reservan 16 bits por pixel, 15 de ellos indican el color de cada pixel de la pantalla (hasta 32.768 colores), el bit restante se reserva para indicar la prioridad respecto a la imagen de megadrive. No se puede usar a pantalla completa por temas de restricciones de memoria, lo veremos a continuación.
• Modo Run Length: 256 colores. Partiendo de la esquina izq-sup de la pantalla (lo que vendría a ser la coordenada (0,0) se indica un color y cuanto pixels se van a pintar con ese color, y se pintan del tirón. Y así con cada cambio de color y línea a línea. Es como la compresión RLE (de ahí el nombre del modo), si hay pocos cambios de color con pocas instrucciones podremos representar toda la pantalla, ideal para dibujar polígonos planos, en cambio si hay muchos cambios (como cuando se dibujan muchos sprites y tiles), es contraproducente. No se puede usar a pantalla completa igual que en Direct Color, ya que se usan también 16bpp (8 para indicar cuántos píxeles pintar y 8 bits para el color).

Además una cosa curiosa, podemos empezar a dibujar con un modo y en el momento que queramos, cambiarlo. Esto será efectivo a partir de la siguiente línea. Todavía no he averiguado si fue usado en algún juego, pero permite p.e. dibujar parte de la escena en un modo determinado (por ejemplo la ventana del juego) y otra con otro más adecuado (por ejemplo un inventario).

¿Por qué Direct Color y Run Lenght tienen limitaciones?

Bueno, veamos qué necesitamos en modo direct color (32.768 colores) a la máxima resolución (320x240px):

320px x 240px x 16 bits/px = 1.228.800 bits.

Es decir, cada pantalla (cada frame) generado necesita al menos 1.228.800 bits de información a guardar en el framebuffer. Pero el framebuffer no tiene tanta capacidad al ser de 1Mbit (1.048.576 bits)

Así que no podemos hacerlo a no ser que bajemos resolución o no pintemos parte de la pantalla (franjas negras). Si bajamos a 320x224…

320px x 224px x 16 bits/px = 1.146.880 bits ... Ahora tampoco!!

Ahí tenemos el motivo, la memoria de framebuffer no es suficiente para crear una imagen a pantalla completa a 16 bits de color. Colocar memorias de más capacidad encarecería más la consola. Recordemos que en la época de los 16/32bits la memoria era todavía carísima. La solución es crear la imagen a menor resolución. A 320x204px como máximo. (320x204x16=1.044.480 bits, cabe en el framebuffer!!)

Así creamos la imagen del juego de 32X con una resolución menor a la máxima para que nos quepa en el framebuffer, y luego con la MD creamos una imagen a resolución “normal”, podemos poner un borde negro o un marcador bien grande. El VDP mezcla ambas imágenes y… tachán! Magia!

Bueno, magia no, porque desde el Spectrum se ha venido haciendo algo parecido. Si no te llega para dibujar toda la pantalla, por restricciones de memoria o porque la CPU no da más de sí… pues no dibujes toda la pantalla!

Doom de 32X es un claro ejemplo. Sólo parte de la pantalla es dibujada en 3D, que es la parte que más ciclo de computación consume. Luego tenemos los marcos (que siempre son los mismos), por lo cual se gestionan más o menos rápidamente. Y finalmente el marcador inferior, que lo hace la MD:

¿Es el VDP sofisticado? Lo cierto es que es bastante simple. El VDP no permite rotar, escalar ni realizar sofisticados efectos gráficos. Es, probablemente, el mayor defecto que se puede achacar a 32X, el VDP no está diseñado para realizar efectos por HW, al fin y al cabo no se puede maximizar un sprite ya que, para 32X, ¡los sprites no existen!

Para eso está la MD claro, pero entonces dependemos de tecnología anticuada.

Esto fue solucionado en la Saturn con un VDP “de verdad”, que permitía hacer efectos de toda la imagen o de parte de ella, gestionar scrolls, realizar transparencias, etc. Por supuesto, el precio era mucho mayor.

Resumiendo, cualquier efecto, gráfico, scroll,etc debe ser calculado por los SH2 antes de enviar el resultado al VDP. Es el principal talón de aquiles de 32X porque implica que todo se debe hacer programando y al mismo tiempo es su mayor virtud, porque su simpleza debería hacer barato el addon.

COMO DIBUJA 32X

32X no tiene nada que ver con la MD (y con el resto de consolas de 8/16 bits) en cuanto a “generación de gráficos”. Esto es bastante curioso.

Las consolas tradicionales de 16 bits, como la MD, trabajan con sprites, tiles, planos de scrolls, etc teniendo diversos límites en cuanto a su número, tamaño y número de colores.

Es por eso que dibujar en 3D en una consola tradicional era tremendamente costoso pues su HW no estaba pensado para ello. Poder se podía, pero con grandes dificultades.

El 32X, al contrario que la MD, no tiene un VDP que le permita hacer “cosas” con los sprites, gestionar planos de scroll, etc. La 32X está pensada para dibujar “de otra forma”. Son los SH2 los que van a trabajar para “dibujar” la imagen, dibujan directamente en el framebuffer.

Hacer un scroll parallax, rotar un sprite… Nada de esto puede hacer el VDP de 32X.

Si queremos hacer esto, hay que hacerlo “a mano” con los SH2.

Además hay que tener otra cosa en cuenta. Al ser el VDP de 32X tremendamente simple, no podemos hacer un scroll parallax, ni rotar sprites, ni escalarlos… todo debe hacerse a mano desde los SH2, y esto consume ciclos de computación. Esto es una desventaja, ya que perdemos ciclos de los SH2 en tareas gráficas cuando podían estar con otras cosas.

Pero para eso tenemos la MD y esta era la idea de Sega.

Los SH2 son mucho más potentes que el Motorola, pero para no desperdiciar ciclos de computación nos podemos apoyar la MD. Así la MD puede gestionar p.e. un scroll de fondo y el resto, como los sprites principales y todas las otras tareas (como gestionar la IA de los enemigos), lo hacemos desde el 32X.

Con ello mantenemos la 32X haciendo lo que sabe por un lado, la MD lo que sabe por otro, y el VDP de 32X lo junta todo.

El VDP del 32x gestiona que framebuffer “pinta” la TV (lo veremos a continuación) y según el modo de vídeo seleccionado gestiona las paletas de colores.

Al contrario de lo que podemos leer en algunos foros y webs por internet, por HW el VDP del 32X no puede hacer Gouraud shading ni texture mapping, todo se hace por software con los SH2, con el coste de procesador que eso implica.

Según el modo de vídeo seleccionado el VDP puede pintar en la pantalla de determinadas formas siguiendo las instrucciones de los SH2. Generalmente es el SH2 esclavo el que accede al VDP para “dibujar” la pantalla.

Pongamos un ejemplo para ver como trabaja el 32X.

En el modo RLE, 32X le dice al VDP, en una sola instrucción, cuantos pixeles consecutivos pintar de un color determinado. Por ejemplo que pinte 30 pixels consecutivos con un color determinado. Luego otro color para pintar hasta el final de la línea. Saltamos a la siguiente línea y vuelta a empezar. Es decir, para imágenes poligonales “planas”, donde hay normalmente pocos cambios entre pixels, la forma de trabajar es ideal.

Como ejemplo. VF 32X:

El fondo lo dibuja la MD, además del marcador. También mueve el scroll:

32X pinta los personajes, el suelo y. Si nos fijamos, solo polígonos planos, cada polígono tiene un solo color, si miramos una línea, hay pocos cambios dentro de cada línea:

Si lo juntamos todo:



Si bien esta forma de dibujar es buena para polígonos, es lenta para dibujar un Sonic, con cantidad de sprites/colores diferentes en pantalla.

FRAME BUFFER

Se trata de la memoria a partir de la cual se pinta la pantalla. Recordemos que tiene una capacidad de 256KB (2x128). Hay dos porque mientras se muestra un fotograma (“frame”) por la TV, se está creando el siguiente en el otro.

Vamos a explicar esto con más detalle. Cuando la TV nos muestra una imagen, lo que la consola hace es mandarle una señal con la imagen según el contenido de uno de los framebuffers. Las TVs de “tubo” tradicionales dibujan de izq a dcha y de arriba a abajo. Por tanto dibujar una imagen o frame no es instantáneo, tarda un tiempo determinado (aunque es muy rápido y el ojo humano no puede verlo).

Mientras esto ocurre, la consola va ejecutando instrucciones y escribiendo en el otro framebuffer. Al terminar la TV de mostrar la imagen, hay un tiempo durante el cual la TV no pinta, la consola aprovecha para cambiar de framebuffer y, entonces, la TV vuelve a pintar la imagen usando el nuevo contenido.

Hemos visto que no tenemos espacio suficiente en la memoria del FB para almacenar una imagen a 32K colores, pero en cambio tenemos espacio más que suficiente para una imagen a 256 colores. Esto se puede aprovechar para crear un scroll sin tener HW dedicado. En vez de dibujar sólo la pantalla visible, pintamos tanto como podamos (podemos dibujar hasta 408 líneas, mostramos 320). En cada frame, el VDP le manda a la TV una imagen desplazada 1px adicional en sentido horizontal, como si una cámara “avanzara”. Esto es fácil de hacer porque el VDP tiene una tabla donde guarda que mostrar del FB, se va cambiando a mano y, tachán, un scroll.

También podemos darle otro uso, y es dibujar en el área visible la pantalla del juego y dejar, en la parte no visible, datos que necesitemos (como tiles o sprites), ya que acceder a ellos desde los SH2 es más rápido que acceder al cartucho. Parece una tontería pero he leído que hay desarrolladores de la scene que han usado esta memoria para pasar datos a la MD.

SONIDO

32X recoge el sonido generado por la MD, lo mezcla con el que ella misma puede crear y lo manda a la TV.

Los juegos de MD normalmente usan el Z80 como apoyo para crear sonidos, esto es lógico ya que aunque el Motorola 68000 también puede usarse para procesar sonidos, normalmente dejamos esa tarea al Z80 para liberar un poco de faena al 68000. 

Con respecto al sonido, la mayoría de títulos de 32X son juegos “tipo megadrive” que corren desde el Motorola 68000/Z80 y usan los SH2 como apoyo para generar efectos de sonido puntuales. Como 32X apenas tuvo vida muchos devs simplemente hicieron lo que venían haciendo en MD, es lógico y normal que se hiciese así.

Hay excepciones a esta forma de trabajar. Knuckles Chaotix es el mejor ejemplo, tanto 32X como MD crean parte de la melodía (cada una unos instrumentos), que se mezclan para crear la melodía completa.

Tal y como está hecho 32X, tiene todo el sentido del mundo NO darle el peso del procesamiento de sonido a los SH2, que bastante tienen con gestionar la ROM y procesar todo lo que tenga que ver con gráficos 3D.

Un programador homebrew comentaba en sega16 que el peor escenario era que los SH2 tuviesen que acceder a la ROM (porque necesitaran datos que no estuviesen en su memoria) y, en ese momento, la MD estuviese accediendo al cartucho para cargar datos para generar sonidos. En ese momento tienes a los SH2 parados (ya que el bus está ocupado). La forma de evitar esto es llevar a la memoria de 32X lo que necesites en una fase determinada, y desde la MD ir accediendo al cartucho ocasionalmente para cargar datos (como la música o algún efecto), intentando no molestar a los SH2.

¿CÓMO FUNCIONA TODO JUNTO?

Dicho esto… ¿cómo funciona el 32X? Pues depende. Básicamente hay 2 posibilidades:

1. La mayoría de juegos de 1a gen de 32X corren el juego como si fuese un juego de megadrive y usan el 32X como co-procesador gráfico, como si fuese un potente SVP.
   En estos juegos tenemos gran carga de sprites+scrolls, esta parte la ejecutaría el motorola 68000 (+ Z80) mientras que el 32X podría hacer pequeñas tareas como rotar sprites, hacer algun efecto de sonido, mostrar gráficos vectoriales o poligonales. Tampoco hemos de extrañarnos, no podemos esperar sacar un HW nuevo como 32X y que los programadores lo aprovechen al 100%, es normal que hagan lo que saben (programar para MD) e ir mejorando poco a poco. Knucles Chaotic es un ejemplo en sus fases 2D.
   
   La forma de usar 32X como “co-procesador” es sencilla de entender:
   
   Primero dejamos en los SH2 de 32X un programa que “no hace nada” pero que tiene todas las funciones que vamos a necesitar (como rotaciones o escalados).
   
   Cargamos en MD todo lo que necesitemos (tiles, sprites).
   
   Cuando necesitamos hacer algo que se salga de las capacidades de MD, le enviamos un aviso a los SH2, y le pasamos lo que queremos modificar y cómo, por ejemplo, hacer una rotación de un sprite determinado de “x” grados, y dibujarlo en la posición (x,y).
   
   32X entonces carga el sprite en su memoria y lo rota, y tal cual lo transfiere al FB, para que se vea en pantalla.
2. La segunda posibilidad es que podemos correr el juego desde el 32X para hacer cosas que la MD no puede, y dejarle pequeñas tareas a la megadrive para liberar un poco a los SH2, como por ejemplo la música, los efectos o dibujar el marcador. Los Virtua Fighter y Racingfuncionan de esta manera.
   
   Realmente no es necesario usar la MD más que para recoger el input de los mandos, si así lo queremos. Tampoco hace falta usar el SH2 esclavo necesariamente, pero no hacerlo es desperdiciar recursos porque al fin y al cabo ambos SH2 son igual de capaces.

JUEGOS DE PRIMERA GENERACIÓN (año 1994)

Vamos a ver algunos juegos para ilustrar todo lo anterior, veremos algunos de los mejores juegos de lanzamiento (Doom, Virtua Racing Deluxe, Star Wars Arcade) y luego algunos de los mejores lanzados al año siguiente.

DOOM 32x

Título de lanzamiento del 32X. Fue desarrollado por el propio Carmack, que hizo al mismo tiempo la versión para Atari Jaguar. Además se hizo a toda ostia para el lanzamiento de la consola, un par de meses tardaron, así que tenemos el primer problema en el poco tiempo de desarrollo del juego.
Era una buena versión pero tenía pegas: no va a pantalla completa, faltan algunos mapas, el sonido es regulero, falta 1 arma (que se puede conseguir con un truco) y faltan algunos enemigos. Mantiene, hasta cierto punto, el frenetismo y suavidad del PC.

Carmack decidió que el programa principal correría en la 32X y de la música se encarga la MD, lo cual siempre ha sido la explicación de su mala calidad. No obstante creo que fue demérito del compositor que no supo aprovechar bien el chip Yamaha de la MD.

¿Por qué no aprovecharon mejor las capacidades sonoras del 32X? Posiblemente el desarrollo atropellado de 2 meses tenga que ver con esto. Al fin y al cabo el chip de la MD ya era conocido y estaba documentado.

La MD también se encarga de dibujar la barra de estatus, además del menú, es decir, la MD se dibuja con prioridad sobre la 32X (por encima). Curiosamente los números del marcador (munición, vida, etc) son sprites.

El primer mandamiento del programador de 32X es copiar de la ROM los recursos que necesitemos a la RAM. De esa forma los SH2 trabajan directamente con los datos. Como la RAM es pequeña comparada con la ROM, habrá que copiar tantos como puedas y evitar acceder a la ROM durante el juego, intentando hacerlo en los momentos de “pausa”, cambios de fase y cosas así.

Pero Doom accede constantemente a la ROM mientras jugamos. El juego ocupa 3MB, aunque algunos prototipos eran más grandes, finalmente el cartucho se lanza con esa capacidad. En PC los requisitos mínimos eran 4MB de RAM (4096KB) pero la 32X tiene 256Kbytes de RAM (!).

Pasar de un PC con “mucha” RAM a un sistema limitado como es una consola es un cambio bastante grande. Posiblemente por eso Carmack y compañía decidieron leer directamente la ROM en vez de cargar solo lo que se necesitaba en cada momento.

A pesar de penalizar los tiempos de acceso, el framerate del juego es aceptable (siempre en el contexto de la época).

Para comparar un poco con el mundo PC, yo tuve en su época un 386DX40 (un clon de 386 de AMD a 40Mhz) y tenía que jugar con un marco (como el de 32x), si quería que se moviera de manera aceptable a baja calidad. Jugando en alta calidad o jugabas con un 486 o iba a pedales, aun haciendo el marco enorme y la ventana de juego pequeña. Es decir, el port de 32X es similar en prestaciones al de un “caro” PC con un 386 y 4MB RAM, no está mal ciertamente.

El caso de la falta de mapas, sprites de animación y armas del original, ya es cosa del tamaño del cartucho. Que BFG no esté accesible al faltar el nivel donde se consigue (solo se puede conseguir con un truco) es un detalle hasta cierto punto feo, pero ahí se mezclan varias cosas, un cartucho mayor implica royalties más caros y menos beneficios para el editor que publica el juego, por otro lado meter más contenido no hace sino agravar el problema la falta de memoria de la consola comparado con el PC.

Curiosamente los primeros prototipos del port de 32x funcionaban a pantalla completa y mantenían la geometría original de los mapas de PC, pero hay demasiados slowdowns, motivo por el que se puso un marco y se simplificaron los mapas.

Aquí tenéis un enlace de uno de esos prototipos (la música NO es del juego obviamente):

https://www.youtube.com/watch?v=dcHoZ45bG-w

Muchos devs actuales de la scene de Sega opinan que el port es mejorable sobre todo por el tema del acceso continuo a la ROM, pero para nada fue un mal port.

VIRTUA RACING DELUXE

Juego de lanzamiento y fantástica conversión del arcade. Para ponernos en contexto:


VR en Arcade (placa model 1): Hasta 180.000 polígonos planos
VR en MD SVP: Hasta 6500 polígonos planos con 16 colores
VR en 32x: Hasta 50.000 polígonos

Al igual que en VF, MD se usa para el fondo 2D y para casi todos los sonidos, pero a diferencia del VF, 32X dibuja todo lo demás, la MD no usa su otra capa ni usa sprites para dibujar nada:

Como decía, 32X se usa para todo lo demás, 3d, los marcadores, y algunas melodías, como la melodía de inicio y la de los menús:

Claramente mejora el port de MD, más colores, mejor sonido, más polígonos en pantalla, tiene 2 coches y 2 circuitos adicionales:

Por supuesto, no llega al nivel del arcade pero no está nada mal para una consola doméstica, se nota sobretodo en la resolución:

El juego está ciertamente simplificado no solo por la carga poligonal, la detección de colisiones es mucho peor y otras (como al golpear señales de tráfico) directamente no existe.

La versión de VR de MD usa 15 colores (4 bits) mientras que la VR Deluxe de 32X (no está muy claro) parece usar el modo “direct color”. De ahí que no sea necesario tanto usar tramas, en la MD se abusa mucho de ellas (no había otra), en VR se usa para las sombras y algún efecto.

STAR WARS ARCADE

Juego de lanzamiento, conversión del arcade de Sega.
Utiliza polígonos planos (sin texturas). Se mueve entre 20 y 30 fps, es decir, bastante bien.

El juego tiene varios modos e incluso cooperativo (uno maneja la nave y otro es el artillero).

Para lograr el máximo rendimiento, el motor del juego da prioridad a los polígonos respecto al resto de cosas en pantalla, para ello actualiza con mayor frecuencia los polígonos que otros elementos como los disparos, el marcador, o “el viento” espacial.
Es decir, todo lo que dibuje la MD se actualizará más lentamente que lo dibujado por el 32X.

32x dibujas las estrellas (puntitos), las naves, los asteroides, los rayos láser y las explosiones (todo son polígonos).

La MD dibuja el cockpit, los marcadores, las marcas de las naves a derribar
MD hace la música, 32X los efectos.
Lo dibujado por MD se dibuja SOBRE lo dibujado por 32X.

JUEGOS DE SEGUNDA GENERACIÓN (año 1995)

Algunos de los juegos que aparecieron en 1995 eran mejores que los lanzados el año anterior, los desarrolladores habían mejorado sus motores y habilidades para sacarle más rendimiento al 32X.

VIRTUA FIGHTER 32X

Fantástica conversión del arcade hecha por AM2.

Los modelos 3D están claramente simplificados respecto al arcade y a la conversión de Saturn (que incluso salió un poco antes), pero en cambio no hay baile de polígonos como en la Saturn, todo parece más estable y se mueve igual de bien.

Aquí la MD se usa para los fondos 2d, las letras del ranking, el logo de Sega en el inicio

La 32X para el 3d, el sonido, el fondo del ranking y el logo de AM2, curioso.

Comparamos Arcade (model 1) vs 32x vs Saturn

32x vs Saturn

La MD dibuja las barras de vida en una capa, el fondo de nubes y arena en otra, el tiempo y las “marcas” de victoria son sprites.

Jugadores, sombras y suelo, dibujado por 32X.

La 32X dibuja con prioridad sobre la MD, es decir, dibuja por encima.

MORTAL KOMBAT 2

Interesante conversión del arcade, hay mejoras respecto a la versión de MD, pero hay detalles que dan que pensar sobre la dificultad técnica de hacer ciertas cosas con el tandem 32X-MD, ya que la mejora es muy ligera, en mi opinión podía haberse hecho más.

La MD dibuja los fondos:

Por otro lado, la 32x se usa para dibujar el marcador, los personajes y los elementos que están delante de estos, como la cadena que se ve en la siguiente captura:

Al no dibujar sprites, todos los colores que la MD puede manejar se destinan a dibujar los fondos, que son ligeramente mejores que el port de MD. ¿Cómo que todos los colores van al fondo?

Técnicamente la MD puede tener 64 colores en pantalla, bueno, no exactamente.

El VDP de MD soporta 4 paletas de 16 colores (4x16=64), pero cada paleta uno de los colores se reserva para representar el fondo del sprite (que será tratado como transparente para los sprites pero puede ser usado como color de fondo en background), así que al final tenemos 4x15=60+1=61 colores.

Esas paletas podemos aplicarlas a sprites, tiles y planos con ciertas restricciones. Por ejemplo un plano solo puede tener 1 paleta (16 colores). Un sprite solo puede tener los colores de 1 paleta, por tanto no puede tener más de 16 colores. Y así.

Sin entrar mucho en detalle, digamos que se solía reserva 1 paleta para el personaje principal, 1 para el fondo y las otras multiuso. Por tanto la elección de colores era vital y eso hacía que a veces los fondos fueran un poco sosos.

Pero en MK2 32X, la MD puede dedicar todas las paletas a los fondos, así que eso que hemos ganado. No obstante visualmente tampoco se aprecia mucho, por lo menos yo no lo aprecio mucho:

Varios desarrolladores se quejaron de que los drivers para el sonido y la documentación de 32x respecto a este era muy deficiente y escasa en su momento.

¿Por qué no rehicieron todo el sonido para que sonara mejor? Posiblemente el ahorro de costes y maximizar beneficios hizo mella en la programación de este juego. La MD se usa incluso para algunas voces digitalizadas (sabemos que no es su fuerte).

KNUCKLES CHAOTIX

El 2D plataformas de 32X.
La MD dibuja los fondos, fondo parallax en una capa, escenario (suelo, palmera) en otra

MD también hace parte de la melodía principal e incluso los anillos (capa de sprites). Es decir, no se limita a dibujar los fondos:

Por otro lado, 32X dibuja los personajes, algunos elementos como los power ups y el HUD. Es curioso que en algunos juegos el HUD sea dibujado por la MD y en otros no.

En esta captura se ve uno de los personajes con efectos de escalado en el sprite hecho por el 32X. No lo mencionamos en el MK2 pero igual que en Chaotix, al manejar el 32X a los personajes (en vez de hacerlo la MD), se aprovecha para que éstos sean más coloridos, al poder poner más colores la 32X.

En muchos juegos de MD encontramos que los sprites de personajes y fondos (e incluso el marcador) comparten algún color.

Las fases de bonus son son una versión mejorada de las fases del Sonic 2, esta vez con el “tubo” en 3D. Ciertamente son atractivas pero petardean un poco:

En cuanto al sonido, MD crea parte de la melodía principal, 32x añade instrumentos y efectos y los junta para crear la melodía que podemos escuchar por los altavoces.

Es decir, MD y 32X colaboran para crear los gráficos y el sonido.

TEMPO

Un título peculiar. Es un 2D plataformas, como Knuckles Chaotix, pero funciona de forma totalmente distinta.

En las fases “normales” la MD dibuja los personajes, el escenario y HUD, 32X dibuja los fondos que están animados y con efectos de scalings.

En esta captura se puede ver bien, en el fondo tenemos un degradado de colores imposible en “circunstancias normales” para la MD. Imposible porque si lo hacemos tal cual en la MD, comprometemos las paletas de colores y pocos colores diferentes quedarían para la mega. los sprites. No se aprecia en la captura pero los colores van rotando rápidamente (naranjas, rojos, verdes, azules, etc), por lo que de intentar hacerlo en la MD, o ponemos sprites pobres en color, o al final los sprites también “rotarian” dichos colores.

Luego tenemos el mensaje “x 2 PTS” que tiene efectos de escalado.
Otro ejemplo, en el fondo tenemos, además del scroll de fondo, muchos objetos moviéndose por el fondo (no se aprecia en la captura):

En la MD, hacer esto implica bien usar sprites para simular fondos y el límite de sprites en pantalla y por línea haría difícil hacer algo así sin los parpadeos habituales. No es así en este juego gracias a que 32X no tiene esos “límites”.

Las fases de “jefes”, al revés. La MD dibuja los fondos y 32X los jefes, que se agrandan y reducen de tamaño, se escala su tamaño, rotan y tienen una profundidad de color y degradados muy suave:

La secuencia de inicio del juego la hace 32x exclusivamente.

Como Knuckles, el sonido se hace con la colaboración de MD y 32x.

KOLIBRI

Un shooter donde la nave es un.. colibrí!!

Es muy colorido, posiblemente el más bonito de 32X. El juego..bueno.. lo hicieron el mismo equipo que Ecco the Dolphin, así que la jugabilidad es muy particular. Pero ¿y desde el punto de vista técnico?

Totalmente en 2D, corre a 60fps pero tiene truco, además del colibrí y de los enemigos, no hay complicados efectos raster o parallax, no hay enemigos gigantes, poco en el escenario con lo que chocarse, es decir, es bastante simple en ese sentido.

Los fondos “lejanos” son de MD, fijaros en las tramas (puntitos) en las nubes, los árboles o en el terreno. En cambio el fondo “cercano” y los sprites los genera la 32X, no hay más que ver el cesped y las flores. Este juego muestra el máximo colorido de los juegos lanzados en 32X.

STELLAR ASSAULT (SHADOW SCUADRON)

Un matamarcianos 3d que se mueve increíblemente suave, utiliza polígonos planos (sin texturas). Se mueve a unos 20 fps.

Es uno de los pocos juegos que usan el modo de 15 bits direct color, 32.768 colores. Para ello reduce la parte dibujada a 228x224px para que los framebuffers no se peten.

La MD dibuja el cockpit y la 32X todo lo demás.

DARXAID

Un matamarcianos 3d con polígonos texturados.
Ojo, y en Español, menudo detallazo traducirlo a varios idiomas. Sólo fue lanzado en Europa.

Atractivo y toda una demostración tecnológica. Como hemos explicado antes, 32x no tiene nada HW para ayudar a texturizar polígonos, es por tanto el motor software del juego el que usa los SH2 para ello. Durante el juego va bastante bien, pero en las partes de aterrizaje y despegue 32x se queda un poco corto, pero claro tenemos texturas y parece que incluso iluminación. La MD solo se usa para la música.

Todo lo dibuja la 32X. Todo.

METAL HEAD

Otro juego 3d con polígonos texturados. Lamentablemente se mueve muy lento y tosco, aunque en la época era la leche.

La MD crea el Cockpit y el fondo, la 32x el 3D.

Mucha gente ve este juego como el techo de 32X, al menos con respecto a los juegos que se lanzaron. Muy posiblemente lo sea, pero el juego es repetitivo hasta la saciedad, un juego muy top en la técnica pero no en lo jugable.

FIFA 96

Título sólo lanzado en Europa. EA sacó, a diferencia de lo hecho en las consolas de 16bits, un FIFA en “medio” 3D. Porque no todo está hecho en 3 dimensiones.

Los jugadores son sprites creados por la MD, el estadio está hecho en 3d por el 32x.
El resultado es muy bueno (recordemos que hablamos de otra época) en lo visual.

La cámara no es fija como el típico FIFA isométrico 2D, podemos cambiarla, y en ciertos eventos que lo requieran hace zoom in-out, como en un saque de banda por ejemplo.

La cámara es un problema pues es bastante lenta, muchas veces la pelota se sale de la visión y tarda un segundo o dos en centrar el juego. Esto ya pasaba en las versiones isométricas realmente. No es muy distinto jugablemente respecto a esas versiones.

El sonido y la música simplemente pasables en cuanto a la aportación que podía dar 32X.

Parece un juego sin terminar de pulir.

PROTOTIPO: XMEN MIND GAMES

Este juego nunca fue lanzado al mercado, fue cancelado en 1996. Es más una demo técnica que un juego.

Los enemigos, objetos del escenario y el protagonista son hechos en 2D, todo se escala según nos acercamos o alejamos. El personaje es inmortal en este prototipo, ya que no muere ni en la típica lava.

Las paredes y el suelo sí parecen estar hechos en “3D” con texturas, tipo Wolfestein. Hay cierta “niebla” N64 style. Podemos movernos en todas las direcciones, recorrer el escenario, disparar a los enemigos e interactuar con algún objeto.

Los sprites son toscos pero enormes, no hay ralentizaciones pero sí que se queda el personaje atascado en muchas partes. No parece muy jugable pero el manejo de sprites y 3D texturado es notable, de seguir desarrollándose quizá hubiese sido un buen juego.

Desde luego una mejora enorme en cuanto a polígonos texturados.

No va desde el emulador, por lo que veo solo desde la máquina original (que yo no poseo), por tanto no puedo ver si la MD colabora, pero intuyo que todo funciona desde 32X, ya que lo 2D se escala constantemente según nos movemos.

PROTOTIPO: Zyrinx 32X Demo Tape

Zyring fue una desarrolladora Danesa. Citando a Wikipedia:

“El primer juego desarrollado por Zyrinx fue Subterrania para la Mega Drive de Sega. Durante el desarrollo el equipo se trasladó a Boston. Más tarde, el equipo desarrolló los juegos Red Zone y Scorcher. La tecnología de renderización 3D Zyrinx fue mostrada en un video promocional de Sega 32X. El equipo se disolvió en 1998 porque su editora Scavenger quebró…

Un hecho interesante acerca de la compañía es que estaba compuesta exclusivamente por personas que habían participado activamente en la demoscene del Amiga a finales de 1980 y principios de 1990”.

Esta demo puede verse en youtube, hay ejemplos de flat shaded polygons, texture mapping, gouraud shading, iluminación. No es un juego, así que no me extenderé mucho.

Enlace (es un ripeo de un vhs, calidad lamentable lamentablemente)

https://www.youtube.com/watch?v=4r3Cb4zr9Kc

Como curiosidad, hay otros vídeos de prototipos para el 32X en youtube, por ejemplo de Sonic, pero son tan lamentables que no vale la pena comentarlos.

CONCLUSIONES

Obviemos el hecho de que fue un fracaso comercial, que fue lanzado a destiempo y abandonado, eso está claro.

Centrándonos sólo en el HW, Sega hace un add-on que aprovecha la MD tratando de simplificarlo lo máximo posible, de forma que sea barato y simple.

Comercialmente se trata de vender que la MD todavía está al día y el plus lo dará 32X. Para ello lo 2D clásico lo hará la MD y el 3D será tarea del 32X. Cada aparato, MD y 32X, tiene sus fortalezas y sus debilidades y la idea es aunar lo mejor de cada una.

No es mala idea, pero es rocambolesca, es puro Sega de antaño.

Porque programar para dos aparatos totalmente diferentes (cpu risc vs cpu cisc, sprites/tiles vs polígonos), mezclando video y sonido, es una pequeña locura.


Por ello veo totalmente normal los ñordos que sacaron para la 32X, al fin y al cabo si el programador medio no estaba acostumbrado al mundo poligonal y a la programación multi-núcleo y multi-dispositivo, este add-on no lo ponía fácil.

¿Podría haberse hecho mejor? Desde luego a toro pasado… desde un punto de vista técnico y después de ver las opiniones de muchos devs de varios foros de desarrollo indie, en general la opinión más extendida es que el hardware de 32X hubiese sido mejor de la siguiente manera:

CPU: Deberían haber metido 1 sólo SH2 como procesador, más barato y no más dolores de cabeza con el multi-núcleo.  Como hemos visto antes, no podemos ponerlo a más frecuencia. Así que 23MHz es el tope.

RAM: Meter mas RAM para evitar acceder al cartucho lo más posible, pero quizá mejor un bus de 32bits en vez de 16, puedes mover el doble de datos a la misma frecuencia, y es más barato probablemente el bus que meter ram de más capacidad.

Framebuffer: De más capacidad, porque si no el modo de 32K colores lo tienes seriamente limitado de partida. No obstante poco importante, en esa época 256 colores estaban más que bien. Pero la RAM es cara, por tanto difícil elección.

VDP: Y sobre todo y por encima de todo, un VDP de verdad, que pudiese hacer cosas, por simples que fuesen, hubiese ahorrado muchos ciclos al SH2. Obviamente esto no iba a ser barato pero lo cierto es que Sega tenía los VDP de Saturn hechos, podían haber adaptado uno de ellos, simplificando y mutilando un poco el chip.





En fin, espero que os haya gustado este análisis, seguro que me dejo muchas cosas por comentar y muchos errores por subsanar.


Gracias por vuestra atención.