Comentario Original:

Disculpa urian no se si te llego mi pregunta te dejo aquí lo que te escribí,espero que tengas tiempo de tanta preguntas que de seguro tienes

Quisiera preguntarte si conocías los planes de texas instruments a fines de los 80 de ofrecer a sega o nintendo un chip 3d,creo que era el gpu TMS34010 y si crees que hubiera sido algo mejor que el super fx o el svp de sega
saludos

Personalmente pienso que es un bulo y no se cual es su origen, en especial cuando Sega y Nintendo lo que hicieron fue el «descaro» de modificar el TMS9918A lo suficiente en cada caso para no tener que pagarle regalías por el uso de la tecnología a Texas Instruments. Anque el caso de la familia TMS 340xx es completamente distinto y aunque es cierto que se merece un post por si mismo porque tiene una historia hoy en día tan fascinante como desconocida el problema es que hacer una entrada de este tipo y hacerlo que no sea un galimatías (sobretodo por el aspecto técnico) ininteligible es una tarea cuanto menos que requiere un esfuerzo intelectual arduo.

El TMS34010 es un chip fascinante por un motivo, es único en su especie, no deja de ser una CPU que puede utilizarse también como co-procesador gráfico o co-procesador matemático de otros procesadores. El segundo caso que es el que nos interesa es porque Texas Instruments añadió una serie de registros e instrucciones que tienen su útilidad a la hora de generar gráficos sin necesidad de un adaptador, pero su mayor capacidad es que se trata de una CPU convencional también , no en vano era posible programarla en ANSI C y fue la CPU de diversas máquinas recreativas.

Estas máquinas recreativas carecían de la clásica combinación CPU+VDP/PPU como ocurría en otros sistemas de la época sino que todo el apartado gráfico corría de manos del TMS34010 a la misma vez que la lógica del juego. Es decir, el TMS34010 servía de chico para todo.

Pero no solo en sus funciones como CPU era útil, Atari le encontro una utilidad, por un lado como procesador gráfico y por el otro para generar escenas poligonales a tiempo real en una recreativa. No se llegaba aún a lo niveles del Model 1 de Sega siquiera y tampoco el System21 de Namco, pero lo que hacía el TMS34010 para la época era impresionante.

El TMS34010 recibió una revisión llamada TMS34020 cuya mayor novedad era la capacidad de comunicarse con el TMS 34082, un co-procesador de coma flotante que era era hacer de Motor Geometrico para el renderizado de escenas en 3D (Aunque sin texturizado), aunque dicha tecnología no se llego a implementar jamás a nivel de videojuegos y aunque el hardware era impresionante para el año en que se lanzo (1992) rapidamente se vio desfasado con tal de formar parte de lo que sería la siguiente generación de consolas. Obviamente el TMS34020 era superior al TMS34010 en lo que a capacidad visual se refiere pero lo mejor es empezar las cosas por el principio.

Es por ello que he decidido plantear en esta entrada como sería una consola de videojuegos movida por el TMS34010 como procesador principal para la era de los 16 bits. El chip al fin y al cabo fue lanzado en 1986 por lo que hubiese sido posible que alguien se lo planteara como procesador único de una consola de videojuegos capaz de mover tanto la lógica del juego como los gráficos y como habréis podido observar en los videos de arriba estaba más que preparado para ello a nivel de potencia aunque… no podemos olvidar uno de los problemas que acompañaban a los sistemas domésticos que era la falta de memoria, mienras que en recreativas los juego tenían disponibles decenas y decenas de chips de memoria RAM y ROM. En consolas nos teníamos que conformar con un puñado que se contaba con los dedos de las manos.

La primera recreativa en basarse en dicha configuración fue NARC (he puesto el video del juego más arriba) que fue lanzado en 1988, la única cosa que no hace el TMS34010 es el sonido del juego. Es por ello que estudiar el hardware de dicha recreativa para realizar una consola doméstica es muy importante.

La voy a tomar como referencia para ver como podemos construir una consola con ella a finales de los 80 y la viabilidad que habría de ello.

CPU BOARD

La placa de la CPU incorpora una MPU (Unidad de Microprocesador), la inteligencia del sistema. La MPU controla el sistema de acuerdo al programa (lista de instrucciones). El sistema Z- Unit emplea un tipo especial de MPU llamado Graphic System Processor o GSP. La circuiteria del gSP esta optimizada para aplicaciones de video. Por ejemplo el GSP produce la sincronización horizontal, vertical y el blanking para el monitor. El GSP también provee las señales de RAS y CAS para la RAM de Video. Además, el GSP puede trazar la posición  del cursor (carácter) en pantalla. Los antiguos juegos de Williams conseguían estas capaciades con lógica (chips) fuera del procesador.

¿GSP? En efecto, es como llamaba TI al TMS34010.

El segundo punto que es el hecho de poder trazar los carácteres algo que era revolucionario en su epoca, para empezar implicaba el hecho de que hubiese un búfer e imagen pero especialmente que se pudiese leer ese búfer de imagen con tal de hacer una serie de manipulaciones sobre el mismo. Sobre este tema en concreto ya lo hablare más adelante en la entrada cuando toque hablar del tema de los gráficos, por el momento continuemos mirando como era la recreativa de NARC.

Otros notables componentes de la CPU Board incluyen la circuitería de control y la memoria de video en forma de RAM. La memoria de video almacena una representacion en forma de bitmaps de cada imagen que el GSP muestra. Una unidad DMA carga los datos de imagen en la RAM de Video. 8 bits de la RAM están orientados al objeto (se refiere a la definición del patrón). Lo segundos 8 bits están orientados al color. Los resultantes 16 bits están conectados a un latch. Después del latch, 1 bit es descartado y se utilizan los 15 bits para la Color RAM. La Color RAM saca un paralelo datos a señales digitales que van a la entrada RGB del monitor de video.

Para entender el funcionamiento del GSP/TMS34010 necesitamos tener en cuenta su pinout.

TMS34010GeneralSpecs

Como se puede ver tenemos unos dos buses con unos 16 bits cada uno, uno va del LAD0 al LAD15 y el otro va del HD0 al HD1. Uno es para comunicarse con la RAM del sistema y el otro para comunicarse con la VRAM/Bufer de Imagen, en el caso concreto de la recreativa del juego NARC la interconexión es la siguiente.

ZUnit

El diagrama esta simplificado respecto a las descripciones que hay en el documento, por lo que voy a empezar por la ROM.

PROGRAM ROM

Los 512K x 1 byte de la PROGRAM ROM residen en la placa de ROM. La PROGRAM ROM contiene unos 8 chips. Mientras el DMA accede a la IMAGE ROM, el GSP accede simultaneamente a la ROM de programa.

Las máquinas recreativas solían tener una placa con multitud de chips de memoria ROM donde almacenaban los datos del programa, no dejaba de ser el mismo mecanismo que el de un cartucho glorificado y en este caso era muy similar el del CHR-ROM de NES donde se separaba acceso a los datos gráficos y el programa.

La documentación no obstante tiene una contradicción, no son 8 chips de 512K x 8 bits sino que:

NARCMemory

Sino que son 128K x 16 bits y tiene mucho más sentido desde el momento en que el bus para la memoria del sistema es de 16 bits. Simplemente la ROM se encuentra cableada a dicho bus, de la misma manera que los 64KB de Scratchpad RAM.

Scratchpad RAM

El GSP utiliza la RAM Scratchpad para el almacenamiento temporal de datos y cálculos. El Scratchpad RAM utiliza un direccionamiento y buses diferentes. El GSP puede escribir unas 65,536 palabras de 16 bits de longitud long en el Scratchpad RAM. Esta gran memoria esta compuesta por 4 chips de memoria. Mientras que el DMA accede a la RAM de Video, el GSP puede acceder a la RAM Scratchpad. Diferentes buses del sistema y búfers de bus tri-estado permiten esta actividad simultanea.

Dado que tenemos un solo bus de 16 bits y dos pozos de memoria distintos… ¿Como lo hace el procesador para elegir? Pues haciendo uso de un Multiplexor.

Los multiplexores son circuitos combinacionales con varias entradas y una única salida de datos. Están dotados de entradas de control capaces de seleccionar una, y sólo una, de las entradas de datos para permitir su transmisión desde la entrada seleccionada hacia dicha salida.

En el campo de la electrónica el multiplexor se utiliza como dispositivo que puede recibir varias entradas y transmitirlas por un medio de transmisión compartido. Para ello lo que hace es dividir el medio de transmisión en múltiples canales, para que varios nodos puedan comunicarse al mismo tiempo.

Era muy común en las maquinas recreativas ver multiplexores para comunicar los diversos chips pero no era común verlos en sistemas domésticos donde los datos del nivel actual se cargaban sobre la RAM del sistema y no se accedía más al cartucho o simplemente se leía directamente del cartucho y no había RAM en el sistema.

IMAGE ROM

La ROM de Imagen consisen en 1 millon de palabras de 32 bits (32 Mbits, 4MB). Este bloque de memoria esta compuesto por 64 chips que se colocan en la placa de la ROM. La Image ROM es accesible a través de los buses y direccionamiento de imagen. Tanto el GSP como el DMA puedan acceder a esta. Por supuesto no pueden acceder a esta de manera simultanea.

¡Ni más ni menos que 64 chips! Eso si, tenemos un bus de 32 bits por lo que de nuevo tenemos un multiplexor… ¿No es más que lo que el GSP puede asumir ya que tiene un bus de 16 bits? Bueno, el acceso a la Image ROM no lo hace el GSP sino la unidad DMA como se puede ver en el siguiente camino de datos.

NARCArcadeDetailedPipeline

Por lo que el DMA es una pieza importante:

DMA

Las funciones de comunicación de imagen en el Sistema Z-Unit están coordinadas con un DMA especifico de aplicación. El funcionamiento exacto de este chip es propietario. Sin embargo, en terminos básicos controla varios buses para el GSP. Este cede el control de los buses por excelentes razones. Primero, el DMA puede utilizar un bus de 32 bits para transferir los mapas de bits mientras que el GSP utilizaria un bus de 16 bits. Segundo, la arquitectura del sistema permite al GSP procesar datos mientras que el DMA lo esta transmitieno. Tercero, el DMA puede leer los datos de origen y escribirlos en el chip de destino. El GSP no puede realizar lectura y escritura simultanea

Esto tiene varias ventajas, entre ellas la composición de la imagen final a partir del volcado de los bitmaps como si fuesen patrones/sprites sobre el búfer de imagen en cualquier momento, sin que la CPU lo tenga que hacer y sin tener que esperar al periodo de VBlank ni tener que utilizar el bus de memoria principal (lo que provocaría una contención en la memoria y por tanto una perdida de rendimiento). El uso de las unidades DMA fue clasica en las consolas de 16 bits y como veremos posteriormente una unidad DMA en el sistema doméstico va a ser necesaria.

Por otro lado ya sabemos ahora ya sabemos porque la Image ROM tiene un bus de 32 bits, por cierto, dicho bus es llamado Video Data Bus y lo que hace es volcar información sobre la Palette RAM

SystemZVRAM

Las Paletas se encuentran almacenadas en la Image ROM. Cada paleta corresponde a a un mapa de bits. (Por ejemplo una paleta especifica los colores necesaros para reproducir un arbol. Otra paleta esta asociada con el mapa de bits de un edificio. Bajo instrucciones del GSP, el Latch de paleta carga una paleta en la RAM de Paleta, el Latch/Biestable esta controlado por el GSP. Sin embargo el direccionamiento de la RAM de Paleta esta controlada por el DMA.

El otro bus que vemos es el Object Palette Bus y aquí… ¿Que es lo que carga? Los patrones/sprites pero en formato de un solo bit. Donde 1 representa el color de fondo y 0 representa el color de frente.

appleiiformatcharacterbinary

El Object Palette Bus por otro lado es accesible no por el DMA sino por el GSP de manera directa. ¿Y a que es debido esto? Pues al hecho que tiene sentido para efectos de manipulación de los patrones/sprites utilizando las capacidades de procesamiento del TMS34010 (recordemos que no deja de ser una CPU) por ejemplo puede servir para realizar una operación de rotación, de un mapa de bits gracias a ello.

La RAM de Paleta ocupa el mismo espacio de direccionamiento que la bit Map RAM. Eso es que, cuando la RAM de Paleta esta siendo direccionada. La GSP escoge un solo color de paleta (un valor constante) desde la ROM del programa, mientras que el DMA carga la Ram de Mapa de Bits, el GSP simultaneamente carga de la RAM de Paleta. El GSP se guarda a simismo algo de tiempo para dar el número de paleta al latch de paleta. Este se carga en la RAM de Paleta.

El resultado son direcciones correspondientes a un mapa de bits y la paleta correspondiente a dicho mapa de bits. Utlizando la misma dirección de manera simultanea en dos dispositivos salva tiempo y hardware. ¿Y que hay de la confusion? No los hay, el motivo es la separación de tareas. El DMA solo carga la paleta y el latch de Paleta solo carga la Paleta.

Es decir, cada mapa de bits tiene la misma dirección de memoria en dos memorias distintas que va a servir para construir el mapa de bits. Ambas memorias están conectadas a un biestable/flip flop… que une ambos datos (8 bits por cada uno) y los envia directamente a la Color RAM para generar la imagen final.

La Color RAM contiene más de 32.000 códigos color, cada uno de ellos se expresa en 16 bits.

El ultimo bit se descarta.

Mientras 32.768 colores son direccionables, los juegos actuales solo muestran 8.192 colores al mismo tiempo.

El Biestable/Flip Flop de paleta lo que hace es seleccionar una paleta de un total de 128 (2^7 y de nuevo la paleta se descarta), dado que el biestable mantiene el dato hasta que no se cambie la Color RAM recibe de cada pixel que ha de dibujar en pantalla la posición dentro de la paleta (2^8= 256 colores) y cual de las 128 paletas es utilizada. Un juego puede utilizar una o varias paletas por pantalla y es el GSP el que controla la información del biestable FLIP/FLOP.

Una vez hemos visto el proceso hemos de tener en cuenta que tanto la Bit Map RAM como la Palette RAM son el búfer de imagen y son directamente accesibles por el bus de 16 bits para la VRAM. Unos 8 bits para uno y unos 8 bits para el otro, el GSP puede acceder directamente a dicha memoria y tiene dos maneras de generar una imagen, una de ellas es la que estoy explicando, la otra es generar un mapa de bits de manera procedural. Curiosamente la mitad de los bits corresponden a los 8 primeros patrones/sprites y no es que el sistema este limitado a 1 color cada 8 pixeles, es que el GSP no genera el búfer de imagen de la manera convencional y esto lo hace algo confuso.

Tanto los Mapas de Bits como la RAM de Paleta  se encuentran en el Video Address Bus, el cual es accesible tanto por el GSP como por el DMA. El DMA que tiene un bus de 32 bits transmite estos 32 bits en unos 166 ns, transmitiendo unos 8 bits en unos 41,5 ns cada uno a la Palette RAM de manera secuencial. Esto significa que cada 41.5 se puede cambiar el valor de cada pixel.

Tenemos unos 8 chips para el mapa de bits y 8 chips para los chips de la RAM de Paleta. Juntos tiene un output de 64 bits (16 chips y 4 bits por chip). Sin embargo, el bus de datos en serie (del GSP) es solo de unos 16 bits. Por lo que la multiplexación es necesario. De hecho, los chips de la RAM de video están multiplexados

Cada uno de los 4461 forman parte de la RAM de video tiene cuatro pines entradas/salidas que funcionan a tiempo diferente. (es decir, cada pin envia/recibe un dato por ciclo de reloj)-

ZSystemVRAMAlignament

Pero algo realmente interesante es la capacidad que tiene el GSP de manipular tanto el mapa de bits…

BooleanOps2

… como el contenido en la RAM de Paleta.BooleanOps

Para ello necesita una dato de origen que es el que procesa en ese momento y un dato de destino que se encuentra en la RAM, esto permite hacer efectos gráficos de post-procesado entre dos bitmaps aplicando operaciones de Algebra de Boole. Esta función avanzada requiere obviamente un búfer de imagen completo y que este se pueda mantener en memoria y es un aprovechamiento de las capacidades del TMS34010, en concreto es un aprovechamiento del Pixel Block Transfer (PixBLT) que no es otra cosa que una función Blitter integrada en el TMS34010, la máquina arcade de la que estamos hablando no utiliza dicha función para generar los gráficos sino que hace uso de un mecanismo DMA, es entendible por un motivo. El Commodore Amiga por ejemplo también podía hacer este tipo de operaciones pero lo hacía en un chip aparte de la CPU.

En el caso que nos ocupa el acceso al búfer de imagen por parte del GPS no es para la funcionalidad de Blitter desde que de ello se encarga el DMA (y no soporta las operaciones Booleanas) sino para la manipulacion de los mapas de bits. En realidad el System-Z esta pensado para que el GPS solo acceda a los 8 bits correspondientes al mapa de bits.

El siguiente paso es la producción de la imagen final, la cual es tipicamente arcade.

La Williams Z-Unit poduce una imagen de 512×400 pixeles. La pantalla es un monitor RGB de alta resolucion que completa un fotograma cada 16.67 ms, esto corresponde a una tasa de escaneo vertical del estandar NTSC de 60hz. Pero la tasa horizontal es de 40 microsegundos. Esto correesponde a unos 25 Khz, considerablemente más rapido que los 15,734 Hz de tasa de linea del NTSC. El sistema no produce fotogramas entrelazados.

En primer lugar, normalmente el tiempo de HBlank suele ser el 20% del tiempo de fotograma, por lo que estaríamos en la generación de unos 500 pixeles en 32 microsegundos realmente por lo que nos encontramos con que el sistema tiene la suficiente velocidad como para asignar un color distinto a cada pixel. En todo caso en un televisor de finales de los años 80 una resolución de 512×400 no sería posible. Por cierto, en la composición final de la imagen se combinan los datos de color con el del biestable de paleta para generar el color final que se va a mostrar en la imagen de cada pixel.

Y bueno, con esta larga explicacion ya tenemos el proceso de generación de imagen de dicha máquina recreativa… ¿Que nos queda? La construcción del sistema doméstico.

Diseñando una Consola Derivada.

El concepto para la simplificación de entrada es el mismo que hizo Sega para pasar del System16…

aliensyndrome_mobo_pcb_partside.jpg

… a la Genesis/Mega Drive.

Genesis_pal_model1_M5

En realidad voy a tomar muchos elementos de la Genesis/Mega Drive por el hecho de que era una consola contemporanea de la época y nos sirve para hacernos una idea de lo que había disponible en esa época. Pero principalmente el objetivo sería la eliminación en lo máximo posible de los multiplexores del sistema, siendo el primer cambio el hecho de que la CPU no pueda acceder directamente a la ROM, de esta manera eliminamos un multiplexor del sistema. Los datos de programa de cada nivel se cargarían a través de un bus de 16 bits sobre la RAM principal que sería de 64KB incluyendo los mapas de bits del fotograma/escena.. La CPU por tanto tendría unos dos bancos de memoria asignados:

  • En uno (32KB) guardaría los datos de programa del nivel.
  • En el otro (32KB) guardaría los mapas de bits del nivel antes de ser pre-procesados por el GSP (efectos especiales) para almacenar.

Al primer banco la CPU accede mientras el DAC lee la RAM de video para generar la imagen, en ese tiempo se calcula la lógica del juego y se genera una lista de pantalla, donde se dice que patrones/sprites aparecerán en pantalla. Dicha lista se transmite de manera simultanea que los valores de color de los mapas de bits que se encuentran en el cartucho, de lo que se encargaría la unidad DMA, en dicha lista nos marcaría cual es el orden de los patrones/sprites a representar y si estos requieren una transformacion. En total podemos almacenar hasta unos 512 patrones/sprites en dicha memoria. En cuanto a la resolución de pantalla creo que lo ideal serían los 320×224 pixeles, esto son 40×28 bloques de 8×8 pixeles y por tanto la lista de pantalla será de unos 1260 Bytes de información.

El otro elemento es la unidad DMA y la Palette RAM. Aquí no tendríamos un bus de 32 bits funcionando a 6 Mhz con la ROM para transmitir a 24Mhz y un bus de 4 bits que es el caso de la máquina recreativa. El motivo es ahorrarnos los multiplexores en la consola para acceder a los datos en el cartucho con tal de ahorrarnos los costes en el sistema. La unidad DMA va transmitiendo la información de los pixeles desde el cartucho a la VRAM en el periodo de VBlank, lo hace con un bus de 4 bits por lado y a una velocidad de reloj 8.75 Mhz. Es decir, lee 4 bits del cartucho y al mismo tiempo los transmite en otro bus de 4 bits hacía la VRAM,el uso de 4 bits de color supondría reducir la cantidad de colores por bitmap a solo 16 colores pero desde el momento en que ninguna consola de 16 bits supera esa cifra no sería un problema.

En cuanto al mapa de bits también se transmitiría bajo un bus de 4 bits por lo que tendríamos que 8 de los pines para la VRAM no se utilizarían en este caso por motivos de coste. ¿Que nos queda? Pues el biestable de paleta y la Color RAM, el biestable de paleta lo vamos a dejar en unos 8 bits con tal de alcanzar los 4096 colores de muchas maquinas recreativas de la época. Esto son unos 12 bits por lo que el tamaño de la Color RAM pasaría a ser de unos 6KB en total.

El diagrama final por lo tanto nos quedaría de la siguiente manera:

TMS34010Console.png

Elementos a Considerar

La pregunta clave es… ¿Tiene utilidad la programabilidad del TMS34010 en una consola de la época? En la máquina arcade de Williams/Midway las operaciones gráficas tipo Blitter no se utilizaban en ningún momento para generar las escenas. No es que hacerlo en una consola sea una mala idea sino que es una función que en la generación de los 16 bits no tiene mucho sentido que este implementada… Eso si, el TMS34010 moviendo la lógica de los juegos y los gráficos es más rapido que la dupla 68K+VDP de Genesis/Mega Drive, no obstante el hecho de depender de un búfer de imagen hace que sea contraproducente su uso en una consola de 16 bits.

Si es verdad que Texas Instruments se lo ofreció a Sega, entonces su reacción debio ser la misma que cuando SGI les pico a la puerta años después. Se encontraron con un chip enormemente grande y vieron que para conseguir lo que querían conseguir les bastaba utilizando una serie de chips más pequeños y lo mismo ocurre con Nintendo a la hora de diseñar su SNES. Es decir, el sistema hubiese sido muy posiblemente mucho más potente y con más posibilidades pero nadie querría colocar un chip tan complejo en su consola de serie y más si esta estuviese dirigida al mercado infantil que es como ocurría por aquel entonces.

Una consola hubiese sido posible pero para ello debería haber habido un fabricante con la motivación de construirla y personalmente no creo que hubiese sido cara.

Por el momento termino, sobre la TMS34020 ya hablare en otra entrada.