Gráficos Retro: Atari Jaguar

Dado que Jaguar y 3DO realmente estuvieron en tierra de nadie he decidido añadir sus entradas correspondientes a la serie de «Gráficos Retro», más que nada por ser sistemas con una historia muy interesante detrás de cada una de ellas.

#1 Flare Technology

Flare Technology fue creada en 1986 por los por aquel entonces ingenieros de Sinclair Research  Martin Brennan, Ben Cheese, y John Mathieson. Su primer diseño fue el Flare One que inicialmente ofrecieron a Atari pero que acabo siendo la nunca lanzada Konix Multisystem, en la entrada acerca de la Atari Panther os hable de ello pero no esta mal refrescar la memoria.

Su segundo proyecto, la Flare II fue del interés de Atari y fue comprada por la compañía descartando por completo la propuesta de Dave Needle y RJ Mical que terminaría en convertirse en la 3DO. Al mismo tiempo Atari habia ido viendo evolucionar su consola de 16 bits, en ese momento llamada Atari Panther, la Flare II estaba tan avanzada que en 1991 tomaron la decisión de cancelar Panther y centrarse en la Flare II a la que renombraron como Jaguar.

La Atari Jaguar fue la última consola lanzada por Atari, la sucesora a nivel comercial de la Atari 7800 como consola de sobremesa y pese a tener nombre de felino no tiene la misma arquitectura que la Atari Lynx y pese a heredar algunas de las ideas de la cancelada Atari Panther su arquitectura era completamente distinta y tiene una naturaleza «exótica» que desde mi punto de vista merece repasar porque es el ejemplo de como no puedes desarrollar un sistema o simplemente de como tirar por la borda un sistema con procesadores con un enorme potencial que te hubiesen dado el mercado por completo.

Pensad que esto esto se ejecuta en un sistema que en 1993 se vendia por $249 en el mercado americano, muchas de las cosas mostradas en este video eran imposibles en Super Famicom/SNES, en Genesis/Mega Drive e incluso en 3DO, pero como ya he dicho una exótica arquitectura llevo este sistema al traste. ¿El mayor problema con el que se enfrento este sistema?  El funcionamiento adecuado de la consola era sumamente complicado dada la sobrecomplicación de su arquitectura.La mayoría de los desarrolladores prescindían por completo de las capacidades de la máquina y tomaban el camino que les era más fácil para desarrollar los juegos dada la enorme cantidad de procesadores que participaban en el proceso de la generación de gráficos en pantalla, pero su mayor cuello de botella era como estaba organizada la logistica entre los chips y con la memoria del sistema.

Por cierto, esteticamente la consola siempre me ha parecido preciosa en comparación con las de su época.

Dicho esto vamos a describir los componentes del hardware y el motivo por el cual Jaguar es tan «especial».

#1 Arquitectura y organización general del sistema 

La organización interna de Jaguar es la siguiente.

Como se puede ver tenemos un solo pozo de memoria para todo el sistema, esta tiene el el impresionante ancho de banda de 64 bits en total (aunque compartida por todos los procesadores) y una densidad de 2MB de memoria, ahora esto nos parece muy poco pero para una consola lanzada en 1993 con un precio de $249 estaba muy bien pero el problema añadido es que no podían acceder varios dispositivos simultaneamente a la RAM o mejor dicho el DMA no podia gestionar varios dispositivos por lo que estos…

Los dispositivos del sistema tienen acceso a la DRAM a través del controlador de memoria con la siguiente prioridad:

1. Acceso del J-RISC/DSP para realizar una operación del tipo DMA.
2. Acceso del J-RISC/GPU para realizar una operación del tipo DMA.
3. Blitter para realizar una operación del tipo DMA.
4. Object Processor
5. Acceso del J-RISC/DSP para realizar una operación convencional.
6. Interrupción del 68K
7. Acceso del J-RISC/GPU para realizar una operación convencional.
8. Blitter para realizar una operación convencional.
9. 68K

Ahora bien, hemos de tener en cuenta que el ideal de rendimiento es que los J-RISC trabajen solamente con su memoria local (SRAM) porque entonces el cuello de botella crece de mala manera dado que cada vez que un procesador accede a la DRAM el resto se para en seco por completo y la DRAM es accedida incluso para operaciones que no son de manipulación de memoria haciendo que el resto de componentes se pare, por suerte Jaguar tiene una cantidad de caminos alternativos que la mayoría de desarrolladores por desgracia no utilizaron por la sobrecomplicación que resultaba.

El problema es que Jaguar era un sistema esquizofrénico que no sabia ni él mismo si era un sistema basado en búfer de imagen completo o un sistema basado en un Line Buffer, sobre ello entrare cuando lleguemos a la parte de la generación de los gráficos más adelante en esta misma entrada.

 #1.2 J-RISC y 68K

Jaguar tiene un 68K como supuesta CPU central, pero su trabajo es el de hacer de manager, el trabajo de la CPU corresponde realmente a dos núcleos llamados J-RISC que se encuentran uno en Tom…

… Y el otro en Jerry.

En el que nos vamos a centrar de entrada es en Tom, el cual si mirais en el diagrama general esta compuesto por los siguientes elementos:

• Controlador de Memoria
• Object Processor
• GPU
• Blitter

La unidad que nos interesa es la marcada como GPU, se trata de un núcleo con un set de registros e instrucciones propio llamado J-RISC y con una potencia cuando se utiliza su SRAM local de unos 27 MIPS, el 68K tiene una potencia de poco más de 3 MIPS y es que el J-RISC/GPU es la verdadera CPU del sistema y no el 68K. ¿Pero si es la CPU como es que se le llama GPU? Esta muy basado en concepto en TMS340x0 que eran realmente procesadores de proposito general con extensiones para gráficos (incluyendo incluso un Blitter en su interior) pero no son un clon del TMS340x0 aunque su funcionalidad no es la misma.

El TMS340x0 fue un chip gráfico creado por Texas Instruments y que fue presentado en 1986.

El TMS34010 en realidad era un procesador de proposito general con extensiones para gráficos en su set de registros e instrucciones con instrucciones para gráficos y que tenía integrado un Blitter (llamado Pixblit en el video). Al TMS34010 le dedique un par de entradas (I, II). Pues bien, el nucleo J-Risc en TOM tiene la misma funcionalidad, aunque realmente utiliza el Blitter y/o el Object Processor para generar los gráficos en pantalla el propio J-RISC/GPU nos permite manipularlos con una gran versatilidad. Eso si, no es un TMS340x0 realmente aunque su funcionalidad es la misma y al igual que el TMS340x0 es posible utilizarse como CPU y en realidad es la verdadera CPU del sistema.

Ahora bien, tenemos otra unidad J-RISC en el Jerry con la misma capacidad, pero no esta conectado a un subsistema gráfico sino al DSP de Audio y tiene unos 8KB de memoria local en vez de 4KB. Ahora bien, ambos procesadores tienen acceso a la DRAM pero no funcionan con todo su potencial cuando acceden a la misma, la forma de utilizar ambos J-RISC es haciendo que el 68K haga de manager.  El trabajo del 68K en Jaguar no es hacer de CPU principal sino más bien de coordinador principal de los dos J-RISC, su trabajo es el mismo que el de un director de orquestra que se va encargando de asignar las tareas a los diferentes procesadores para que estos las vayan realizando en el orden adecuado.

Esto supone un cambio de paradigma y una sobrecomplicación, 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 pese a que ambos J-RISC tienen acceso a la DRAM por motivos de cuello de botella es recomendable que trabajen con su memoria local.

Personalmente a mi lo que me impresiona es el hecho de que Jerry no tenga una mayor memoria local, no suelo hablar del audio pero el J-RISC+DSP del mismo con la potencia que tenía y una memoria local hubiese hecho virguerias con el audio, lastima que el formato de los juegos que eran los cartuchos solo permitían juegos de solo 6MB donde el audio era escaso pero es un caso increible de sobre-ingeniería enorme. Algunos de los más expertos llegan a combinar ambos J-RISC en los juegos pero es una sobrecomplicación a la que pocos desarrolladores llegan. No obstante el uso de los J-RISC si se hubiese utilizado bien hubiese sido un salto generacional enorme respecto a lo disponible en ese momento incluida la 3DO y si, aunque la gente tiene a la 3DO como más potente en realidad Jaguar era mucho más potente que 3DO.

La complicada arquitectura hacía que la mayoría de desarrolladores tirase por lo fácil, utilizará el 68K como CPU de toda la vida y lo combinara con el Blitter y/o el Object Processor para generar la pantalla, generalmente el Blitter por ser un componente más común para los que habían desarrollado para ordenadores de 16 bits al igual que el 68K. Esto llevo a que muchos juegos de la consola fueran ports de los juegos de 16 bits y la consola se viese como una 16 bits realmente. Digamos que para los programadores era muy fácil saltarse el uso de ambos J-RISC en los juegos.

Lo normal hubiese sido que Tom por ejemplo hubiese sido planteado como los TMS 340×0 y fuese capaz de trabajar con dos pozos de memoria, uno para gráficos y otro para proposito general pero los arquitectos por motivos de coste lo simplificaron creando. No obstante Jaguar esta muy infravalorada por el hecho de ser un fiasco comercial, pero el motivo por el que lo fue fue por el error de Atari de colocar el 68K como manager, el cual era el que activaba la tentación a los desarrolladores de no utilizar la máquina como es debido. Tom y Jerry pueden interactuar con cualquier CPU/Manager sin problemas, pero la forma en la que el sistema había sido creado y lo éxito de su forma de desarrollar hacía que ni la propia Atari utilizara los J-RISC realmente. ¿Un ejemplo? La placa arcade Cojag donde el 68K era reemplazado por un MIPS R3000.

#1.3 Blitter

Tom dispone de una unidad Blitter, cuyo trabajo es trasladar bloques de datos de una memoria a otra y realizar una serie de operaciones de manipulación de datos por el medio, pero la naturaleza del Blitter de Jaguar va un poco más allá de los que hemos tratado anteriormente y es al mismo tiempo el cuello de botella de la consola.

¿Que puede hacer el Blitter?

1. Puede realizar simples copias de memoria de un punto a otro, por ejemplo podemos copiar patrones/sprites desde el cartucho a la DRAM del sistema.
2. Puede dibujar y rellenar rectángulos con un color determinado.
3. Puede dibujar lineas de pixeles
4. Puede escalar y rotar patrones/sprites

Muchos ahora diréis… ¿Y que tiene de especial? Ahora viene lo interesante:

1. Soporte para Gouraud Shading
2. Soporte para Z-Buffering
3. Soporte para Texture Mapping

En realidad el Blitter de Jaguar no se diferencia mucho del del VDP1 de Saturn pero con una capacidad mucho más limitada. ¿El motivo? El falta de una memoria local propia y si tuviese una cache y la capacidad de rellenar y genarar triangulos entonces tendría una capacidad cercana a  la de la primera PlayStation. No en vano de cara al re-diseño de la Jaguar para crear la nunca lanzada Jaguar II, Atari modifico levemente el Blitter eliminando sus cuellos de botella por completo.

¿Por qué es el Blitter un cuello de botella? Pues es simple… Es el chip encargado de trasladar los datos de una memoria a otra y por motivos de costes la mayoria de memorias carecen de un mecanismo DMA que permite parar el procesador principal a la que esta asignada y copiar los datos. No solo eso, sino que el Blitter carece de memoria de ningún tipo, esto hace que para realizar ciertas operaciones concretas tenga que copiar a la DRAM para poder realizarlas para luego recuperarlas. Eso añade una cantidad de ciclos enorme que reduce por completo la tasa de relleno del sistema pero que son utilizados por la mayoría de desarrolladores porque permiten utilizar la DRAM como un bufer de imagen tradicional.

El Blitter tiene un bus de 64 bits, el problema es que no puede por ejemplo escribir unos 4 pixeles de 16 bits por ciclo a la memoria y solo puede escribir un pixel por ciclo.  Esta limitación en combinación con el hecho de que la DRAM sea de un solo puerto y la falta de una memoria local en el Blitter es mortal. Con un bus de 64 bits se pueden escribir unos 8 pixeles de 8 bits por ciclo (256 colores) que ya es más que cualquier consola de 16 bits, 4 pixeles de 16 bits o 2 pixeles de 24 bits pero no se puede y el problema de una falta de una cache local o una memoria asignada hace que por ejemplo que realizar una simple operación como aplicar un mapeado de texturas requiera unos 7 ciclos por pixel, lo cual coloca las cosas a una tasa de relleno que es inutilizable.

Pero no es el Blitter el que genera la imagen final. No tenemos como en otros sistema con Blitter un mecanismo que lee una sección de la memoria y la interpreta como buffer de imagen realmente, el trabajo de ello depende del Object Processor, cuyo funcionamiento os paso a relatar a continuación.
#1.4 Object Processor
Si habéis observado el diagrama veréis que Jaguar carece de memoria dedicada para video, esto es debido a que dispone en Tom de un Object Processor, el cual lo podéis ver como una versión evolucionada del MARIA de la Atari 7800 aunque realmente deriva del Object Processor de la jamás lanzada Panther. No en vano, juegos como Cybermorphpor ejemplo se desarrollaron originalmente para Panther y fueron portados a Jaguar, por lo que utiliza solo el Object Processor

El Object Procesor se encuentra al final de la cadena a la hora de generar los gráficos y es por tanto el procesador al que esta conectada la señal de video, lee una lista de objetos/pantalla como su prededesor, MARIA, y con ello genera la siguiente linea de escaneo. Para ello hace uso de un Line Buffer de unos 1440 bytes en total, esto le permite dibujar una pantalla de hasta unos 720 pixeles con resoluciones de 2, 4, 8 y 16 bits de color y con la particularidad de soportar hasta 24 bits de color pero con la particularidad de reducir en ese caso la resolución máxima a 480 pixeles solamente. La velocidad del Line Buffer es de unos 40 Mhz con un bus de 32 bits, por lo que da un margen considerable al Object Processor y al resto del pipeline gráfico para realizar las operaciones correspondientes.

El Object Processor incluso cuando no es explicitamente invocado es implicitamente invocado al ser el único componente que genera el búfer de imagen. Ahora bien… ¿Como se entiende con el J-RISC y el Blitter? Y he aqui una nueva complicación de Jaguar, para empezar pese a que tiene memoria local si dicha memoria local no tiene nada en su interior entonces lo que hará será acceder a la DRAM para generar los gráficos. La idea es que sea el Blitter el que lea desde la DRAM y vaya llenando el Line Buffer del Object Processor, pero la idea maxima es que el Blitter traslade información desde la SRAM del J-RISC/GPU al Line Buffer realizando en el proceso el propio Blitter una serie de instrucciones, esto significa que no hay búfer de imagen completo pero no existe contención alguna con la DRAM del sistema entre estos procesadores. El problema de este paradigma es que la memoria local de cada uno de estos procesadores es muy limitada y aunque es un modelo ideal resultaba para los desarrolladores dolores de cabeza y meses de trabajo adicionales para conseguir unos resultados minimos.

#2 Jaguar CD
El gran error de Jaguar fue no lanzar la consola en 1993 con una unidad CD-ROM ya que el sistema ya tenia todo lo necesario y al contrario que otros sistema solo habría hecho falta el lector. El motivo por el cual 3DO se llevo buena parte del mercado era porque el cartucho empezaba a verse mal en la industria por aquel entonces y el CD-ROM era el futuro inmediato.

Atari podría haber capitalizado sin problemas del enorme fiasco en precio de la 3DO por aquel entonces y llevarse una enorme cantidad de gente hacia la Jaguar si hubiese incluido un lector de CD-ROM con la consola. ¿Hubiese disparado el coste? En realidad no, en realidad 3DO era cara porque los fabricantes colocaban unos margenes altisimos sobre el hardware. Atari podria haber lanzado una Jaguar con CD-ROM por unos $349 de venta al público por aquel entonces y con las capacidades de la consola comerse el mercado.

#3 John Carmack y Jaguar II

El programador de Wolfestein, Doom, Quake… Fue el encargado de realizar las conversiones de Wolfestein y Doom a Jaguar, precisamente ambas son la demostración de la superioridad de Jaguar respecto a la competencia y Carmack fue el que en una entrevista acabo por descubrir publicamente cuales fueron los cuellos de botella de Jaguar.

Os la dejo a continuación por el hecho de que es muy informativa sobre el sistema.

El caso es que los diseñadores de la Jaguar original le hicieron caso el Feedback de Carmack y a partir de los consejos del mismo y teniendo en cuenta los problemas económicos de Atari se pusieron a diseñar la Jaguar II tomando como partida el hardware de la propia Jaguar, añadiendo elementos que eran indispensables y que no tenía el hardware original y eliminando o reduciendo los cuellos de botella en lo maximo posible. Sobre Jaguar II ya hable en su día en una entrada por lo que podéis considerar esta parte de la entrada un «remake» de la misma.

El hardware nunca fue terminado, por ejemplo Atari cuando cayo en bancarrota aún no había elegido la CPU principal para el sistema, el cual tenia el nombre en clave Midsummer en honor a la obra «Sueño de una noche de Verano» no en vano, las versiones evolucionadas del Tom y del Jerry recibieron el nombre de los personajes de dicha obra, Titania y Oberon en medio del desarrollo. Curiosamente, el marketing de Atari llamaba “Jaguar II” a la unidad CD-ROM de Jaguar y a la unidad combinada que apareció en el mercado bajo el nombre de “Jaguar Duo”.

Pues bien, esto que veis no es la sucesora de la Jaguar sino una combinación de Jaguar+Unidad CD-ROM. La sucesora de Jaguar no tuvo el hardware terminado como para que se desarrollase un diseño industrial en consecuencia, es más, no tuvo todos los chips terminados y como he dicho ni tan siquiera tenían terminada la CPU del sistema o elegida cual iban a utilizar.

Al igual que su antecesora, Jaguar 2 fue una consola con una arquitectura UMA pero Atari se encargo de eliminar ciertos problemas de contención que tenía el hardware original en lo que al acceso a la memoria se refiere con ciertas optimizaciones en cada uno de los chips de apoyo.

La arquitectura general que tenían planeada para el hardware final se puede ver en el siguiente diagrama:

Los J-RISC de Jaguar siguen estando en la arquitectura, pero se han realizado las mejoras que Carmack pedia como es la inclusión de un cache para el Blitter asi como una serie de mejoras como es el hecho de poder dibujar triangulos y tener integrado un rasterizador de poligonos. Estos simples cambios en el hardware hubiesen hecho que el Blitter de la Jaguar II hubiese podido competir de tu a tu contra la Sony PlayStation e incluso ir un poco más allá.

Gracias a la cache de texturas el Blitter ahora puede hacer ciertas operaciones que antes se hacian en varios ciclos en un solo ciclo al no tener que consultar la memoria principal de manera continuada, no obstante dado que es una arquitectura UMA al estilo de la de N64 la cache de texturas sería solo de 8KB. Pero lo interesante es que el Blitter le da unas capacidades muy cercanas a Jaguar II a las de N64 y PSone con esta serie de cambios puntuales.

¿Su rendimiento de cara al 3D?

En realidad la etapa de la geometria en 3D podia ser realizada tanto por el J-RISC/RCPU como el J-RISC/GPU por el hecho que practicamente son el mismo procesador aunque tiene más sentido el J-RISC/GPU desde el momento en que tiene acceso directo al Blitter aunque la documentación de Jaguar II diga que ese trabajo es de la RCPU.

Ahora bien, lo normal sería pensar que Atari se planteo el uso de un J-RISC como CPU completa en sustitución del 68K. ¿El problema? Las especificaciones técnicas del RCPU coinciden demasiado con el MIPS R3000 utilizado también en la Sony Playstation, solo que esta vez como es obvió sin los co-procesadores dedicados de la consola de Sony. ¿Por qué suponemos que es un R3000? Pues porque Atari empezó a utilizarlos con la placa arcade Co-Jag, en todo caso este sistema para el renderizado de imagenes 3D a tiempo real se hubiese quedado corto frente a la Sony PlayStation, es por ello que hay una disparidad enorme entre las especificaciones planeadas y el hardware a medio acabar.

¿Que me hace pensar eso? Pues que Atari empezó a desarrollar la Jaguar II utilizando la placa base de la nunca lanzada Jaguar Duo, tenemos muy pocas imagenes de Midsummer pero hay detalles que nos hacen sospechar enormemente. Si miráis en la placa base…

… no lo encontraréis por el hecho que Atari no lo llego a colocar en el prototipo sino que tenemos el clasico 68K de la Jaguar original aunque la arquitectura permite reemplazarlo en cualquier momento. Por cierto dicha placa tiene el nombre en clave de COBWEB (Aunque no pienso especular en esta entrada sobre el nombre en clave).

¿Que tiene que ver con la CPU? Aqui las cosas se ponen interesantes, Jaguar tenía una versión de su hardware un poco más potente llamada COJAG (Coin-Op Jaguar) donde la CPU era un MIPS R3000 en vez del 68K. No se nos especifica la naturaleza de la CPU en todo el documento pero sus especificaciones coinciden con las de un MIPS R3000 y para una Atari con problemas económicos era mucho más fácil comprar un chip a terceros y pedir su fabricación que no desarrollar uno propio por aquel entonces.

Otra cosa que nos marca que es la placa de una Jaguar Duo es la inclusión del chip de control del Jaguar CD, Atari quería inicialmente que el CD-ROM fuese opcional pero al final se contradijo y decidio incluirlo en el sistema, la prueba esta en su presencia en la supuesta placa de la Jaguar II.

Esto es el chip de control del CD-ROM por lo que opcional ya no era… ¿Y que hay de la memoria? En la documentación de plantean unos 2MB pero se plantean dos bancos (RAM0 y RAM1) llegando cada uno de los bancos a 4MB.

El prototipo existente no tiene 2MB sino 4MB (es decir, toda la RAM0 llena) y Atari se llego a plantear la capacidad de que el sistema pudiese tener hasta 8MB, pero en la placa prototipo no estaban.

¿De que naturaleza es la RAM del prototipo? El 80 del final del código marca unos 80ns por lo que es RAM a 12.5 Mhz realmente la del prototipo. Precisamente la misma velocidad de reloj que el 68K de la Jaguar aún incluido en el sistema.

Aunque este modelo del Atari Jaguar puede llegar a los 16.67 Mhz en el prototipo por la RAM asignada va a 12.5 Mhz, en realidad la RAM que se ve en la fotografía no son 4MB en absoluto.

Tenemos cuatro chips con un bus de 16 bits, lo que cuadra con el bus de 64 bits que tendría el sistema al final. ¿De cuando es cada uno? de 216.144 x 16 por lo que normalizando esta información son de 524.288 cada chip y por tanto de 512KB… Es decir, es la memoria de la primera Jaguar. Atari jamás llego a montar la RAM esperada en el prototipo de desarrollo o más bien esto nos es el ejemplo de que estamos ante una Jaguar Duo.

¿Entonces Jaguar II no existio? Bueno, hay un chip que si terminaron que fue Tom II/Ober que si que se encuentra en dicha placa completamente terminado, el sistema tenia que tener su propia memoria local e incluso en el caso de un sistema de cartuchos su propio acceso a la ROM de Audio (por lo que hubise hecho falta otro tipo de cartucho), pero en el prototipo de la Jaguar II sus capacidades se veían igual de limitadas que en Jaguar. Tom II/Oberon si que fue terminado pero a nivel de prototipo local y no llego nunca a la fabricació. Ambos procesadores en modo Jaguar II tenían que funcionar a 54 Mhz (2X respecto a Jaguar) y por tanto 21 Mhz por encima de lo inicialmente planeado. Pero los ingenieros de Flare Technologies carecían de los recursos necesarios y del personal para terminar el chip a tiempo.

En Atari nunca entendieron la importancia de un software interesante que vendiese consolas, para ellos lo más importante era conseguir demostrar que podían tener el sistema más potente de todosy que mejor para demostrarle al público que su consola podia mover la consola el juego más exigente de todos en PC o mas bien satisfacer al estudio de desarrollo más puntero de todos en ese momento y si era de caracter nacional ya que Atari era una empresa profundamente americana pues mejor. Por eso diseñaron Midsummer/Jaguar II alrededor de las propuestas de Carmack para mejorar Jaguar y por eso Atari utilizo su propios medios para crear una demanda por el juego en aquel momento en desarrollo de Id, pero al mismo tiempo no querian reconocer que Jaguar estaba derrotada pese a estarlo por completo.

Seamos sinceros… Es imposible que Jaguar moviese Quake pero eso no le impedia a Atari sacar semejante Vaporware en su propaganda.

Pero este tipo de prácticas de intentar camuflar que Jaguar había sido un fiasco enorme formaban parte de las campanadas finales de Atari.

#4 El doloroso fin de Atari

En 1990 Jack Tramiel se retiro para dejarle las riendas de Atari a su hijo mayor, Sam Tramiel. Quien es visto como el verdadero culpable de la caida de Atari en desgracia por parte de la fanbase, la decisión de cancelar Panther que hubiese podido competir de tu a tu frente a las 16 bits de Sega y Nintendo se la debemos a Sam Tramiel, cuando en 1993 Jaguar fue lanzada todo el mercado estaba en manos de las japonesas que costaban una porción del precio y debido a la naturaleza de la arquitectura de Jaguar era vista como una 16 bits cara y sin carisma.

Una de las obsesiones de los Tramiel no era otra que veían muy negativamente la industria japonesa. El padre de familia, Jack Tramiel, habia fundado en los años 60 Commodore que se dedicaba a la construcción de maquinas de escribir pero la competencia feroz en precios de los japoneses dejaron casi hundida a Commodore quienes se tuvieron que ir moviendo progresivamente a otros mercados mientras Jack veía como los japoneses llegaban a un mercado tras otro y se lo comían todo por completo. En su día Jack Tramiel ante la inminente aparición del estandar MSX venido de Japón revento los precios de sus ordenadores en 1982-1983 lo que le supuso bajar los margenes hasta tal punto que fue expulsado de Commodore pero las ventas del C64 fueron tan grandes gracias a eso que Jack consiguio su objetivo.

El error de Atari con Jaguar es que quisieron que la manufactura de toda la tecnologia de Jaguar la llevase a cabo una empresa americana como era IBM. Flare Technology que la había diseñado era británica al provenir de Sinclair pero a Sam Tramiel que era el presidente de Atari le era igual mientras el diseño no terminase en manos de los japoneses. Atari habia visto como la tecnología desarrollada en los EEUU como el 6502, el 68K, el TMS9918A/TMS9928A había sido desarrollada en america y los japoneses la habian copiado. Al mismo tiempo terminaron viendo como el mercado basado en el 68K había pasado a mejor vida, ya no eran competitivos contra Intel, Commodore había hecho fallida definitva y solo quedaban ellos y Apple pero Apple había pactado junto a Motorola e IBM el PowerPC, Atari estaba fuera del acuerdo y lo unico con futuro en Atari era Jaguar que tampoco tenía futuro propiamente dicho.

Jaguar fue un fantasma a nivel mundial por el hecho que IBM no llego a fabricar la cantidad de chips suficientes para su lanzamiento en 1993 y Atari tuvo que retrasar el lanzamiento de la consola a 1994, sin unidades apenas y con toda la atención puesta en las nuevas consolas de Sony y Sega en Atari habian perdido la oportunidad. Atari en 1994 llego a demandar a Sega por el uso del puerto tipo Atari para joysticks utilizado en Genesis/Mega Drive, ganaron el juicio y se llevaron unos 70 millones de dólares que les sirvieron para mantenerse a flote y poder desarrollar Jaguar II/Midsummer, pero la desesperación de Sam Tramiel con tal de mantener viva a Atari era tal que no sabían hacía donde tirar.

En el E3 de 1995, Sony anuncio la PlayStation a $299 y con ello las posibilidades de Atari de un retorno como Dios manda se disiparon por completo, Sony tenía una consola con una potencia muy similar a Jaguar II ya terminada, a punto de ser lanzada y siendo el centro de atención del sector. Atari en cambio lo que tenía era Jaguar, un fracaso sonado que la propia Atari se negaba a reconocer como tal. El motivo por el cual la Fanbase considera a Sam Tramiel como el destructor de Atari es la infame entrevista que concedio a la revista Next Generation donde lo que tenía que ser un publireportaje de Jaguar…

… acabo por convertirse en una de las entrevistas a un directivo del sector más infames de todas y las consecuencias fueron la muerte política de Atari.

No voy a comentarla porque merece la pena ser leida para poder palpar la desesperación y el nivel de estrés dentro de la Atari de por aquel entonces. Al poco de que esta entrevista se publicara Sam Tramiel tuvo un infarto que le dejo secuelas en forma de una enfermedad coronaria que le retiraría de Atari. Su padre Jack Tramiel retomaría la empresa para sustituirle pero la suerte estaba echada. En Febrero de 1996 Atari que tenía dinero en la caja del juicio contra Sega pero sin la capacidad de ser operativa se fusiono con JTS, un fabricante de Discos Duros para PC, Atari no tenia productos y sabían que el capital que tenian disponible para subsistir pronto terminaría. JTS en cambio tenia productos pero carecía de capital, fueron el hambre y las ganas de comer lo que unieron a estas dos empresas pero sobrerodo que el patrimonio de los Tramiel no se hundiese. La Jaguar era tan querida y tan popular que les costo liquidarla por completo, tenían almacenes enteros con la consola, Atari habia pasado a ser un nombre maldito ya que JTS cayo por completo en 1998 y la marca Atari fue comprada por Hasbro por 5 millones de dólares. Hasbro la revendio a Infogrames que se convirtio en Atari Games para hundirse poco después, actualmente la marca esta en manos de unos estafadores que han creado un producto de vaporware llamado VCS del que ya he hablado en el blog.

Eso es todo, espero que os haya gustado la entrada. ¿La siguiente? 3DO.