Gráficos en Consolas Antiguas (XVII): Atari Jaguar

La Atari Jaguar es cuando menos particular, con un diseño completamente único en cuanto a hardware y se podría escribir una buena entrada sobre su historia pero no me voy a centrar en ello en esta entrada, por cierto y como opinión personal a mi el diseño externo de esta consola siempre me ha encantado.

 

¿En que difiere Jaguar del resto de consolas? Pues en el hecho que no tiene una CPU propiamente dicha sino que lo que tiene es un “manager” que se va encargando de asignar las tareas a los diferentes procesadores para que estas las vayan realizando, dicho manager es un Motorola 68K a 13.5 Mhz. Sí no se conoce la arquitectura de Jaguar lo primero que se piensa es que es la CPU del sistema y que esta esta muy por debajo del resto, cuando en realidad a Jaguar la afectaron más otros cuellos de botella.

¿Entonces si el 68K no realiza el trabajo que es lo que lo realizaba? Jaguar contiene en su interior dos procesadores con una arquitectura J-RISC, dichos procesadores de proposito general funcionan a 27Mhz, tienen una potencia de 27 MIPS y por el hecho de se de propósito general sus resultados dependen directamente del código que se ejecute en ellos. Los dos chips en los que se encuentran se llaman Tom y Jerry, siendo Jerry el que se encarga de procesar la E/S y el sonido mientras que Tom se encarga de la parte gráfica, dejando al 68K el trabajo de Manager y el resto de la lógica del juego.

Y ahí es donde viene la particularidad de la arquitectura, antes he dicho que los dos procesadores J-RISC eran procesadores de proposito general y por tanto CPUs… ¿entonces si son CPUs como es que es necesario que haya un manager? No se si os acordaréis del CBEA, la CPU de PS3, donde había un procesador de propósito general con acceso a la memoria principal encargado de planificar las tareas y luego una serie de procesadores que solo pueden acceder a su propia memoria local por lo que el procesador de proposito general tiene que ir llenado listas de trabajos en la memoria local de cada uno de ellos. Pues bien, la idea de Jaguar es similar misma ya que ninguno de las dos CPU J-RISC de Jaguar (llamados DSP y GPU en el diagrama de arriba) podía ejecutar código desde la RAM del sistema y solo podían acceder a la SRAM.

Dado que estas entradas tratan sobre gráficos no voy a tocar la parte del Jerry dedicado al sonido y la E/S, por lo que me centraré en el Tom.

El camino de datos que seguía el sistema para generar los gráficos:  68K->Object Processor->J-RISC/GPU->Blitter.

El Object Processor era el procesador de comandos.  Por cada linea en pantalla procesa una lista de comandos, la lista de objetos, y la almacena en el Line Buffer. Los objetos pueden ser mapas de bits/patrones/sprites de diferentes resoluciones,n dichos comandos son copiados en la memoria local de la GPU y son procesados por esta.

La GPU por otro lado era completamente versatil al ser un procesador de proposito general, se podía ejecutar cualquier programa gráfico en ella ya que se trataba de una CPU y por tanto la potencia de Jaguar fuera de lo que son los cuellos de botella dependía de la habilidad del programador con el código que tenía que ejecutarse en la GPU, esto significa que se podía hacer cualquier cosa mientras el sistema tuviese potencia para ejecutarla. En esta cita de John Carmack, contemporánea a la consola,  nos explica muy bien cual es el punto fuerte del procesador gráfico de la consola y lo que lo diferencia del resto de sus rivales de la época:

Por qué la Jaguar es mejor que la 3DO (desde mi punto de vista): Solo cuesta $250. El grueso de su potencia de procesamiento es programable. la 3DO tiene una CPU muy capaz (unas cuantas veces más que el debil 68K en la Jaguar), pero la mayoría de su potencia esta en un hardware que tiene una funcionalidad muy limitada para transformaciones afines. La Jaguar tiene hardware estúpido para Z Buffering y Gouraud Shading, pero lo puedo ignorar y contarle a los dos procesadores RISC a 27 Mhz que hagan exactamente lo que yo quiera.

El hecho que dependiera de la habilidad de los programadores daba resultados muy dispares dentro de la misma consola:

No obstante con la GPU no termina la cosa ya que la última pieza del proceso gráfico era el Blitter, este funcionaba igual que cualquier otro Blitter anteriormente mencionado en esta seria y en teoría era incluso más potente que el VDP1 de Saturn… ¿entonces como es que no llego nunca al nivel de Saturn la consola?  Carecía de memoria local por lo que tenía que acceder a la RAM (la cual funcionaba a la mitad de la velocidad de reloj que el Blitter) por lo que solo podía acceder a la memoria en un sentido por cada transferencia. Esto significa que de la tasa de relleno que podía generar el Blitter de Jaguar por la configuración de memoria del sistema se quedaba reducida a 1/4 parte de lo que podía generar en teoría, así pues, un sistema gráfico con la capacidad de generar 27 Millones de Pixeles/seg quedaba reducido a poco menos de 7 millones y por debajo de 3DO y eso sin contar los accesos que podían hacer el resto de procesadores a la RAM.

Su mayor cuello de botella del sistema es su organización de memoria, esto se ve cuando se observa el diagrama general de la consola:

blockdiagJag

 

La RAM de la consola eran 2MB conectados a un bus de 64 bits a 13.5Mhz (13.5*8 bytes), esto a simple vista es mucho mejor que el bus de la 3DO que era de 32 bits a 12.5Mhz o incluso el bus de Saturn que funcionaba a 14Mhz y de 32 bits. Pero ahora fijaos en un detalle y veréis que ni los gráficos ni el sonido tienen un pozo de RAM propio e incluso el canal hasta los cartuchos es compartido, lo peor es que como hay un solo canal de acceso lo procesadores no pueden acceder a diferentes partes de la RAM al mismo tiempo a través de diversos canales, En Jaguar no se puede por ejemplo hacer una transferencia de 32 bits por un lado y una lectura de 32 bits por el otro sino que se puede hacer una sola transferencia que puede ser de 16, 32 o 64 bits pero solo una de ellas. Esto significa a simple vista que cuando un procesador este accediendo a la RAM o el cartucho entonces el resto no tendrá acceso a la misma y tendrá que esperar, este es el mayor cuello de botella que tiene el sistema.

El otro cuello de botella es el 68K, el problema de dicho procesador era que podía escribir en memoria cada 4 ciclos de reloj, esto significa que podía hacer una transferencia de datos hacía el Tom o el Jerry cada cuatro ciclos, dicha transferencia era de 32 bits y se enviaba a través del bus del sistema. En las versiones iniciales de la consola Atari tenía pensado sacarla con un 68030, luego probaron con un 68020 y terminaron con un 68000. El 68k es un cuello de botella porque si la Jaguar hubiese tenido un procesador decente entonces la GPU no hubiera tenido que encargarse de realizar tareas propias de una CPU y la consola hubiese sido mucho más competitiva de lo que fue realmente.

Anuncios