Gráficos Retro: Genesis/Mega Drive

El desarrollo de la Sega Mega Drive/Genesis empezó a dentro de Sega a mediados de 1986 para ser terminado a inicios de 1988 bajo la tutela de Masami Ishikawa en un equipo de solo 5 personas donde el miembro más destacado entre los diseñadores terminaría siendo Hideki Sato que tomaría la antorcha de Ishikawa a la hora de diseñar los sistemas de Sega después de la Mega Drive/Genesis.

A estas alturas y después de varias entradas de Gráficos Retro entenderéis ya varios conceptos y os haréis más o menos una idea de como funcionaban las consolas de la era de los 8 y de los 16 bits por lo que esta entrada en lo que a la Genesis/Mega Drive respecta será un poco más corta que las otras.

La CPU es un clon del Motorola 68K fabricado por Hitachi funcionando a 7.67 Mhz, si os habéis fijado es la primera vez que hablamos de una CPU con una velocidad de reloj que no es multiple o una fracción exactos del Colorburst, el motivo de ello lo veréis luego más adelante. El 68K fue una elección por parte de Sega si tenemos en cuenta que se había convertido en el procesador estandar de los sistemas de 16 bits, tanto ordenadores (Amiga, Atari ST, X68000…) como en las placas recreativas incluyendo las de la propia Sega y en especial su placa insignia de ese momento, el System16.

En Mega Drive/Genesis el 68000 era responsable de varios efectos realizados por software sobre los gráficos como la rotación de sprites:

Esto es destacable porque sus rivales que eran tanto la PC-Engine como la Super Famicom/SNES utilizaban CPUs menos potentes aunque en el caso de la consola de Nintendo esto se paliaba utilizando CPUs alternativas colocadas en el slot de cartuchos en PC-Engine esto no se podía hacer.

La segunda CPU del sistema es un Z80 funcionando a 3.58 Mhz que sirve para la compatibilidad hacía atrás con la Mark III/SMS, en realidad dentro del hardware de la Genesis/Mega Drive esta todo el hardware de la Mark III/SMS incluyendo los 8KB de RAM de la SMS que en modo Genesis/Mega Drive no se utilizan. En dicho modo el Z80 se utiliza para controlar el SN76489 que es el Generador de Sonidos Programable, en este caso Sega lo ha integrado dentro del VDP y es el mismo procesador de sonido que la SMS/Mark III. Como curiosidad en los primeros modelos de la Genesis/Mega Drive era posible acceder a los 64KB de RAM principal con el Z80.

Dado que el 68K puede direccionar hasta 24 bits en teoría debería poder direccionar hasta 16MB/128 Mbits de memoria pero la memoria esta asignada de una manera en concreto.

Los cartuchos por ejemplo tienen asignado un total de 4MB en el direccionamiento de memoria (32 Mbits) por lo que los juegos que utilizaban más de esa cifra utilizaban mecanismos multibanco como las consolas de 8 bits. La parte donde pone Sega Reserved esta reservada para la comunicación con el 32X y el MegaCD. Aunque cuando la consola fue diseñada ninguno de los dos periféricos-consola estaban planeados.

Los perífericos, por cierto nunca lanzados, de la Disquetera y el Teclado junto a las areas de memoria reservadas me hacen sospechar que muy preliminarmente la Mega Drive/Genesis se llego a plantear como un ordenador de 16 bits hecho por Sega pero no tenemos ninguna fuente primaria que nos lo demuestre y no he encontrado referencias de ello en ningún sitio.

Fuera del VDP, el último chip que nos queda es el Yamaha YM2612 que es el verdadero chip de sonido de la Genesis/Mega Drive pero como en estas entradas no trato el sonido pues no lo vamos a comentar en una entrada sobre gráficos retro.

#2 Gráficos en la Genesis/Mega Drive

Diseñado por Hideki Sato, el VDP de Genesis/Mega Drive (Video Display Processor) al que vamos a llamar Sato VDP al contrario de lo que muchos piensan no es una evolución del VDP de SMS/Mark III sino que integra el VDP de SMS/Mark III para la compatibilidad hacia atrás pero el Sato VDP es un generador de patrones/sprites completamente nuevo y aunque utiliza ciertos fundamentos de los derivados del TMS9918A/TMS9928A en muchos casos rompe en buena parte con la forma de funcionar de este en muchos aspectos hasta el punto de que se debe considerar algo más que una simple evolución del VDP de SMS.

Las Especificaciones Generales del Sato VDP son:

• Dos modos de funcionamiento: Modo H32 y Modo H40.
• Modo H32: 32*28 Celdas (256*224 Pixeles en pantalla)
• Velocidad del VDP en modo H32: 5.37 Mhz.
• Sprites en Pantalla en Modo H32: 64 (SAT de 512 Bytes)
• Sprites por linea de escaneo en Modo H32: 16
• Modo H40: 40*28 Celdas (320*224 Pixeles en pantalla)
• Velocidad del VDP en modo H40: 7.16 Mhz
• Sprites en Pantalla en Modo H40: 80 (SAT de 640 Bytes)
• Sprites por linea de escaneo en Modo H32: 20

Hay que tener en cuenta que el VDP entiende las referencias base en Celdas que son 8×8 pixeles, esto es importante por el hecho que los Patrones/Sprites utilizados en los juegos están compuestos por varias celdas distintas.

#2.1 Planos

El Sato VDP puede generar una imagen compuesta por 4 planos:

• Background: El plano de menos prioridad, solo pinta en pantalla el color asignado como color de fondo.
• Scroll B.
• Scroll A/Window
• Sprites.

#2.1 Sprite Attribute Table

La Tabla de Atributos de Patron/Sprite ha cambiado respecto a la SMS/Mark III y ha pasado de ser de 4 bytes por Patrón/Sprite a ser de 8 Bytes permitiendo muchos más parametros por patrón/sprite que en las consolas de 8 bits y la de PC-Engine.

• Byte 0 y Byte 1 (bit 0): Posición vertical
• Byte 1 (bits 1-7): No tienen utilidad.
• Byte 2 (bits 0-6): Estos 7 bits nos sirven para marcar el nivel de prioridad del patrón/sprite sobre el resto. Fijaos que en el modo H32 tenemos un máximo de 64 patrones/sprites y en modo H40 por lo que resulta curioso que hayan 7 bits para escoger la prioridad del patrón/sprite. ¿Pistas de un descartado modo H64/512 pixeles?
• Byte 2 (bit 7): No tiene utilidad.
• Byte 3 (bits 0-1): Tamaño horizontal, hay que tener en cuenta que que el VDP interpreta los patrones/sprites como celdas (8×8), este registro nos marca que celdas en horizontal se han de tomar del banco de celdas, permitiendo patrones/sprites de 8, 16, 24 y 32 pixeles en horizontal.
• Byte 3 (bits 2-3): Tamaño vertical, hay que tener en cuenta que que el VDP interpreta los patrones/sprites como celdas (8×8), este registro nos marca que celdas en vertical se han de tomar del banco de celdas, permitiendo patrones/sprites de 8, 16, 24 y 32 pixeles en vertical.
• Byte 3 (bits 4-7): No tienen utilidad.
• Byte 4 +Byte 5 (Bits 0-1): Celda a utilizar como Patrón/Sprite. En la VRAM hay un total de 1024 celdas de 8×8 pixeles con 4 bits de color que son patrones/sprites o fragmentos de patrones/sprite. Esto significa que 32KB de la VRAM almacenan la lista de patrones/sprites.
• Byte 5 (Bit 2): En la Genesis/Mega Drive no tiene utilidad, es una reminiscencia del diseño con 128KB de memoria ya que se puede tener una lista de 2048 celdas de  8×8 pixeles con 4 bits de color en este caso pero moviendo la mitad de los patrones/sprites a la segunda memoria.
• Byte 5 (Bit 3): El Patrón/Sprite horizontalmente se dibuja a la inversa.
•  Byte 5 (Bit 4): El Patrón/Sprite verticalmente se dibuja a la inversa.
• Byte 5 (Bits 5-6): Cambio de Paleta, esto significa que hay hasta unas 4 paletas en pantalla (64 colores en pantalla).
• Byte 5 (Bit 7): Bit de Prioridad. Los patrones/sprites con el bit de prioridad 0 solo activaran la detección de colisiones con los que tengan el bit de prioridad 0 y se mostrarán en el plano «Sprite». Los patrones/sprites con el bit de prioridad 1 no activaran la detección de colisiones y serán movidos al plano directamente posterior..
• Byte 6 y Byte 7 (bit 0): Posición Horizontal

Esto solo afecta a configuración del plano Sprite y nos sirve para configurar como se dibuja el fotograma. En cada fotograma la CPU genera una nueva la lista de SATs. En modo H32 esta lista ocupa unos 512 bytes, en modo H40 unos 640 bytes.

#2.2 Plano Window

El Plano Window y el Plano Scroll A no se muestran al mismo tiempo, Si el Plano Window se muestra no lo har el plano Scroll A, El Window Plane carece por completo de Scroll y de movimiento de cualquier tipo, es un plano completamente estático. Pero podemos escoger que parte de la pantalla corresponde al Window Plane (donde empieza y donde termina). La selección de prioridad entre el Plano Scroll y el Plano Window se hace a través de un bit de prioridad en los registros del VDP.

#2.3 Scroll (A y B)

El Sato VDP puede hacer scroll horizontal de los dos planos de fondo respecto al plano de patrones y sprites y entre ellos a diferentes velocidades.

• Horizontalmente se puede desplazar el plano entero, una fila de celdas, una linea de escaneo, un pixel.
• Verticalmente se puede desplazar el plano entero, una columna de celdas, una linea de escaneo, un pixel.

Como se puede ver las capacidades de scroll son muy superiores a las consolas que hemos tratado hasta ahora en esta serie de entradas.

#2.4 Name Tables

Hay 3 Name Tables almacenadas en la VRAM, al contrario de las consolas de 8 bits donde la Name Table tiene referencias de 8 bits, aquí es de 16 bits.

• Bits 0-10: Selecciona el Patrón/Sprite de la lista de Patrones/Sprites en la VRAM
• Bit 11: El Patrón/Sprite horizontalmente se dibuja a la inversa.
• Bit 12: El Patrón/Sprite vertical se dibuja a la inversa.
• Bit 13-14: Selección de Paleta.
• Bit 15: Bit de Prioridad.

Las Name Tables para los Planos de Scroll tienen ambas las mismas dimensiones, los tamaños de la Name Table para Scroll A y Scroll B son:

Tamaño (Celdas de 8×8)	Bytes
32×32	2048
32×64	4096
32×96	6144
32×128	8192
64×32	4096
64×64	8192
96×32	6144
128×32	8192

Estas Name Tables se generan al inicio de cada nivel y no por fotograma, son el fondo visual del nivel. Ninguna de ellas puede superar un tamaño de 8KB, con la configuración (recordemos que inedita en el modelo final) de 128KB la Name Table de Scroll A se almacena en la primera VRAM junto a Window, la lista de SAT y la Name Table del Plano Window mientras que la Name Table del Plano B se genera en la segunda VRAM.

En cuanto al Plano Window su Name Table es la siguiente.

Tamaño	Bytes
32×32 (Modo H32)	2048
64×32 (Modo H40)	4096

Al contrario de las Name Table Scroll A y Scroll B esta se genera en cada fotograma.

#2.5 Color

En Genesis/Mega Drive solamente se pueden utilizar 4 paletas siendo cada una de ellas de 15 colores+transparten y por tanto de 4 bits de color por pixel. El tema del color es de las cosas más negativas que tiene la consola de Sega.

El Color se selecciona a través de un registro de 8 bits que nos permite seleccionar el color de la paleta (primeros 4 bits), la paleta en concreto que queremos escoger de las activas en pantalla (2 bits) y luego nos deja unos 2 bits que están conmutados entre si que sirven para seleccionar levemente la luminosidad del color.

Seguro que os estaréis preguntando… ¿Por qué no se utilizan esos 2 bits para poder elegir hasta 16 paletas distintas? Porque la CRAM esta limitada a unos 64 colores realmente no porque el VDP no pueda mostrar más simultaneamente. En realidad es posible mostrar más y el truco esta en que en los periodos de HBlank y de VBlank cambiar la Color RAM, pero en los periodos de pantalla activa solo se puede hacer cada 32 pixeles.

No obstante el VDP tiene la posibilidad de soportar Color RAM externa y tener una paleta de colores más extensa. Se lanzo una placa recreativa en 1990 con el mismo VDP que la Genesis/Mega Drive pero con el chip externo para la Color RAM.

Pero en la Genesis/Mega Drive no solo se tendría que haber añadido la Color RAM externa sino cambiar el DAC de video que es solo de 4 bits por pixel (16 colores) por el de las placas arcade de Sega que era de 5 bits (32 colores por pixel).

#2.6 Blast Processing (DMA) y VRAM

En los sistemas anteriores basados en el TMS9918A/TMS9928A que hemos comentado la única manera de acceder a la VRAM era a través de los puertos en el propio generador de patrones/sprites dado que la CPU no tenía acceso directo a la VRAM. En el caso de Genesis/Mega Drive sigue siendo así para el acceso a ciertos registros con tal de acceder a la memoria interna del VDP pero una de las grandes novedades de Genesis/Mega Drive fue la adopción de RAM de doble puerto y con ello la posibilidad de esta tuviese dos clientes que son:

• El VDP en si mismo
• La unidad DMA dentro del propio VDP

La unidad DMA le da acceso al VDP a todo el espacio de memoria del 68K y tambien tiene acceso a todo el espacio de memoria de la VRAM. Cuando accede a la VRAM del sistema lo que hace es paralizar por completo el acceso a esta al 68K y lo deja inactivo, por lo que es recomendable utilizar solamente la unidad DMA (para copiar las Name Tables correspondientes) durante el periodo inactivo de pantalla (lineas 224 a 255).

Dada la velocidad en la que genera la Name Table gracias a esta técnica Sega llamo a esto bajo el nombre de Blast Processing en su marketing.

 

Las velocidades de transferencia por fotograma eran las siguientes:

Operación	Modo	Scanline	Vblank
RAM→VRAM	H32	3584	6346
RAM→VRAM	H40	4032	7790
Cartucho→VRAM	H32	3360	6308
Cartucho→VRAM	H40	3808	7752
VRAM→VRAM	H32	1792	3154
VRAM→VRAM	H40	2016	3876

La unidad DMA puede transmitir hasta 2^16*16 bits (128KB) desde cualquier lugar del espacio de memoria del 68K hacía la VRAM, esta cifra es de cuando se planeo el sistema con 128KB de VRAM en total, pero al final como ya sabemos se quedaron en solo 64KB. Pero la velocidad de transferencia es debido a la RAM a 5Mhz/200ns con un bus de 16 bits pero el enorme problema es que la VRAM tiene solo un bus de 4 bits por lo que las transferencias se hacen a 1/4 de la velocidad. Este es uno de los motivos por el cual pese a que con 64KB al menos hay suficiente espacio para un búffer a 256×224 con 4 bits de color no se utilice, eso y que la generación de dicho búfer en la CPU al no tener el Sato VDP un modo bitmap pues lo ha de hacer la CPU en su RAM y luego copiar el resultado, eso son 42KB de memoria ocupada en total de la RAM solo para el búfer de imagen.

En la hipotetica Genesis/Mega Drive de 128KB de VRAM se duplica el ancho de banda, por lo que hubiese sido posible generar un búfer de imagen a 30fps pero el problema de la cantidad de memoria ocupada en la RAM principal continuaría estando presente.

#2.7 Screen Overlay

Hay que tener en cuenta que Sega baso el diseño de la Genesis/Mega Drive en el hardware de sus recreativas, no en cuento a los chips adoptados sino en cuanto a su funcionamiento. Existe un pin que que es utilizado por el 32X que activa el Screen Overlay, con ese pin activo podemos enviar a una fuente externa la pantalla generada por el VDP a una fuente externa a través del slot de expansión o el de cartuchos, en el caso del 32X servía para generar los fondos de los juegos utilizando el VDP de Genesis/Mega Drive ymientras que los primeros planos eran enviados por el 32X.

#3 Sega VSP

El Sega VSP fue un chip dedicado incluido en el cartucho de Virtua Racing.

El SVP tenía su propia RAM y se comunica con el resto del sistema a través del slot de cartuchos y la unidad DMA en el Sato VDP pero se prescinde del Sato VDP para generar la escena. La cual se hace utilizando un framebuffer convencional (de ahi la propia RAM del SVP) que luego es copiado a la VRAM. Por las diferencias en ancho de banda entre la VRAM y el slot de cartuchos los juegos con el SVP no pueden ir a más de 15fps pero si existiese la configuracion con doble VRAM (128KB) en la Genesis/Mega Drive es posible que hubiesemos Virtua Racing a 30fps.

#4 SegaCD/Giga DriveAunque el Sega CD no fue conocido como Giga Drive si que empezo su desarrollo de Sega como una consola sustituta de la 16 bits de Sega hasta que al final se convirtió en un add-on para la 16 bits de Sega.

• CPU Motorola 68K a 12.5 Mhz.
• 768KB de memoria RAM, mapeados en el espacio de memoria de la Genesis/Mega Drive en el area reservada. Tienen acceso al mismo el 68K de la Genesis/Mega Drive, el 68K del Sega CD y el Sega «ASIC» del Sega CD.
• >Sega ASIC como procesador  “gráfico” a 12.5 Mhz con una memoria asignada de 256KB.

Al contrario del PC-Engine CD-ROM, el Sega CD aumentaba las capacidades técnicas de la la Genesis/Mega Drive de manera considerable aunque el sistema fue mal utilizado debido a la enorme cantidad de «juegos» FMV que salieron para el sistema en aquellos tiempos y que le dieron muy mala fama al add-on.

¿Pero que relación tiene el Sega CD con la rumoreada por aquellos tiempos Giga Drive? Bueno, la prensa continuo utilizando Giga Drive para referirse a lo que acabo siendo Saturn por el hecho que lo anunciaron como una consola de 32 bits. En realidad Giga Drive nació con el objetivo de tener un sistema capaz de reproducir las recreativas de Sega y otras empresas tal cual en los hogares pero… ¿Cual era el mayor handicap para ello? El precio de las ROMS y la cantidad de ellas necesaria, de ahí a que Sega se plantease un sistema con CDs que funcionase en conjunto con Genesis/Mega Drive.

El Sega CD carece por completo de una salida de video pero tiene un procesador que no es otra cosa que un Blitter de la propia Sega o un Casi Blitter porque su funcionalidad esta capada. ¿El motivo? Los 768KB de memoria son compartidos y no tiene una VRAM propia en la que copiar directamente los patrones/sprites en un Búfer de Imagen. Recordad que un Blitter lo que hace es generar una pantalla copiando datos en un búfer de imagen y manipulando los datos de entrada al vuelo. El ASIC puede tomar bloques de memoria (pueden ser un pixel o un bloque de ellos) y realizar las siguientes operaciones:

• Escalado
• Rotación
• Texturizado Afín.

Esta funcionalidad se encontraba en las placas recreativas de Sega utilizando un chip especializado  Tiene un bus de salida de unos 8 bits que no se utiliza y que hubiese servido para poder conectarle una VRAM de doble puerto. Esto en conjunto con un chip capaz de leer dicha VRAM le hubiese dado la posibilidad al SegaCD de mostrar gráficos mucho mejor que como los mostraba el Sega CD y hubiesemos disfrutado a principios de los 90 con una consola capaz de reproducir versiones Pixel Perfect de las recreativas.

Pero en vez de ello el ASIC se limita a Escalar, Rotar y aplicar Texturizado Afín a los patrones/sprites que el Sato VDP dibujara en pantalla, limitando enormemente las capacidades de este.

Me pregunto que hubiese ocurrido si en 1992 hubiesemos tenido una máquina basada en el Sega CD pero sin necesidad de una Genesis/Mega Drive. Una maquina capaz de reproducir versiones perfectas de las recreativas de la época por $299 de la época si pero con un formato mucho más barato (el CD). Los rumores de Giga Drive son de 1991,de antes justo de la presentación del Sega CD por lo que es posible que Sega se plantease el hecho de lanzar una nueva consola en ese momento pero el éxito de Genesis/Mega Drive en el mercado occidental lo convirtió en un add-on de la misma que acabo teniendo muy poco éxito.

Sega 32X

Según cierta gente, El 32X nacio inicialmente bajo la idea de crear una Genesis/Mega Drive mejorada compatible hacía atrás pero con el VDP mejorado respecto a lo que habia en la Genesis/Mega Drive original. A principios de los 90 la memoria era ya lo suficientemente barata como para plantearse el uso de un framebuffer completo en los juegos y prescindir un generador de patrones/sprites por lo que la historia que cuenta Sam Pettus en su lubro es cuanto menos…

El 32X realmente reemplaza a la Sega Genesis/Mega Drive y le hace bypass a la salida de video de esta al tener la suya propia. Solo utiliza el VDP para generar los fondos (ver sección Screen Overlay más arriba) y el sistema de audio de Mega Drive/Genesis con tal de ahorrar costes, su especificaciones eran las siguientes:

• 2 Hitachi SH2 a 23Mhz (40 MIPS en total), el salto desde el 68000 (1 MIPS) era realmente brutal en ese aspecto.
• 256 KB de Memoria RAM.
• Al ser un sistema de cartuchos Sega se pudo ahorrar el coste de una unidad CD-ROM y al mismo tiempo ahorrar en memoria RAM para el sistema, esto les permitió lanzar el periférico a un precio muy bajo en comparación con el MegaCD, ya que de haber utilizado CD-ROM entonces la cantidad de RAM necesaria para el sistema hubiese sido mucho mayor.
• Super VDP.
• 256KB de memoria de video dividida en dos búfers de imagen distintos de 128KB cada uno. Sobre el doble búfer hice una entrada en su día explicando su definición.
• Paleta de colores de 15 bits (32.768 colores) , podía utilizar hasta 15 bits por pixel con resolución reducida u 8 bits por pixel (256 colores) a resolución completa.

Lo único que hacía el Super VDP era escribir en el búfer de imagen trasero y no realizaba ninguna operación de manipulación de los patrones/sprites sino que todas ellas iban a parar a manos del segundo SH2. Yo tengo la hipotesis que el SuperVDP era el chip que tenia que haber acompañado al ASIC del Sega CD en la cancelada en el último momento Giga Drive. Esto tiene sentido si tenemos en cuenta que el El Super VDP era mucho más simple que el del Sega CD, no pudiendo realizar siquiera no escalado ni rotación patrones/sprites. En el 32X se utiliza el segundo SH2 pero en la hipotética Giga Drive se hubiese utilizado el ASIC del Sega CD para este tipo de operaciones.

¿Se podía combinar el ASIC del Sega CD con el del 32X en un sistema combinado? Si, pero la latencia era horrible por lo que era inutilizable. Esto era porque los datos tenian que seguir un largo camino de datos.

Y con esto termino la entrada sobre la 16 bits de Sega y sus add-on… Bueno, nos falta una cosa…

No deja de ser una Genesis/Mega Drive portátil y tuvo una presencia tan efimera en el mercado como la que va a tener en esta entrada. Y con esto si que termino esta larga entrada.