La Atari XE Game System era una versión consolizada de la gama de ordenadores Atari XE cuyo hardware se basaba principalmente en el hardware de la gama de ordenadores de 8 bits de Atari.

El sistema fue un fiasco como otros parecidos como el Amstrad GX4000, y el Commodore 64GS. Todos ellos basados en ordenadores de 8 bits de la época sin mayores cambios pero Atari a finales de los 80 tenía una consola de videojuegos en desarrollo, bueno, en realidad tenía dos… Por un lado tuvo la cancelada Atari Panther y por otro lado la Atari Super XEGS que nunca se llego a completar pero por el timing podría ser la llamada Atari Mirai.

Durante años se dijo que Mirai era una versión consolizada del Atari ST, una Atari Neo-Geo o incluso se llego a especular que era la Atari Panther. Pues bien, no era ninguna de estas opciones sino algo completamente distinto y lo sabemos desde que el creador del Atari Museum, Curt Vendel, llego a liberar la documentación de lo que iba a ser la Atari Super XEGS, una consola que de haber salido le hubiese plantado cara a las 16 bits y hubiese sido una mejor opción para Atari.

Lo primero que llama la atención es el hecho que la CPU sea un 65816 que es la versión de 16 bits del 6502, seguramente colocada para compatibilidad hacía atrás con la gama de 8 bits de Atari, llama también poderosamente la atención como el sistema de sonido iba a estar integrado dentro de la misma CPU, un caso muy parecido al de la Famicom/NES. Curiosamente al final del documento podemos encontrar la firma de Shiraz Shivji, uno de los ingenieros del Commodore64 y creador del Atari ST junto a la de un ingeniero de Ricoh, el proveedor de la CPU de la NES y la de SNES, aunque en el último caso la consola de 16 bits de Nintendo tuvo un sistema de audio dedicado.

Sin salirnos de la CPU, resulta que esta tiene unos 512 bytes de memoria interna, no confundir con una cache. Y la velocidad de reloj de la CPU depende por tanto de la velocidad de reloj a la que funcione la memoria en ese momento.

En el documento hay contradicción de especificaciones, en otra parte del documento hablan de que la velocidad es el doble que la del 6502 en los sistemas de 8 bits de Atari, unos 3.58 Mhz, aunque no indican la cifra sabemos que es esa, fijaos en la correccion de 4X en cuanto a la velocidad, de haber salido este sistema su CPU hubiese sido el doble de rápida que la de SFC/SNES.

Las incoherencias entre las velocidades y su motivo las veremos cuando lleguemos a la DRAM del sistema. Por otro lado, operaciones matemáticas complejas como es la rotación de los patrones/sprites y la manipulación de los mismos iban a ir a manos de la CPU, incluyendo la rotación del escenario entero.

Tened en cuenta que en el caso de Super Famicom/SNES se acabo necesitando un chip de apoyo para este tipo de operaciones, pero esto fue debido a que muchas veces la velocidad de la ROM utilizada para ahorrar costes era sumamente baja, colocando la CPU de la consola de Nintendo a unos 2.86 e incluso 1.79Mhz.

En cuanto al sonido¿Le ofreció Ricoh a Atari una versión del 65816 descartada por Nintendo a Atari? En todo caso el audio del sistema es impresionante y diría que de haberse implementado este hubiese sido muy superior al de la Sega Genesis y al del Commodore Amiga, al nivel curiosamente del de SNES/SFC si miramos sus especificaciones

Buscando especificaciones me he encontrado referencias a un chip de sonido de la misma Ricoh y del mismo año, el llamado Ricoh RF5C68A, que paradojicamente es el chip de sonido del Sega MegaCD.

Es decir, estamos hablando de que la Atari Super XEGS iba a tener la CPU de SNES por un lado y por el otro el chip de sonido del Sega MegaCD, eso si, dado que la memoria como veremos más adelante es unificada, el sistema de sonido tiene un mecanismo DMA con la RAM principal o con algún banco de la ROM, cuyo acceso compartiría con la CPU.

¿Que es el siguiente componente que vemos? Nos aparece un chip llamado Keri, por lo visto Keri no era otra cosa que el nombre en clave para el chip CGIA que era la combinación del ANTIC y el GTIA de los ordenadores de 8 bits de Atari en un solo chip. Según Curt Vendel en su sitio web Atari Museum, dicho chip estaba siendo desarrollado e incluso se llego a completar, a finales de la época Warner en 1984, es decir en pleno crash.

El chip era el chip dorado y estuvo tan completado que Atari termino por incluso hacer la documentación. Pero la tortuosa situación de Atari lo dejaron apartado por completo, cancelando una serie de productos quelo iban a llevar. El Keri mencionado en el documento del Super XE parece que no solo integra el ANTIC y el GTIA en un chip sino que va más allá e integraría también el POKEY y el PIA (6520) para hacer las funciones de E/S del sistema por lo que no solo serviría para la compatibilidad hacía atrás en cuanto a lo gráficos sino también para los perifericos, lo cuales serían los mismos que los de la gama Atari de 8 bits, aparte de los del XEGS, pero es que la XEGS ya era compatible con los primeros.

Por lo que esto lo convertiría en el equivalente a la gama Atari de 8 bits a lo que fue el Apple IIGS, que era un Apple II con un 65816 de CPU para la compatibilidad hacía atrás y que tenía toda la circuitería de apoyo a excepción de la memoria y la CPU obviamente en un solo chip. El motivo por el cual sabemos que Keri se encargaría de la E/S es porque nos lo dice el propio documento.

Si tiramos a la izquierda del diagrama principal tenemos dos ROMS, en principio la lógica es pensar que estamos ante una consola pero no es así, el XEGS tenía la ROM de 8KB con el Atari Basic que se activaba en el inicio o no según si conectábamos o no el teclado, la segunda ROM hemos de entender que hace referencia al slot de cartuchos, hemos de tener en cuenta que la base es el XEGS, el cual a través del chip PIA podemos controlar el acceso a la ROM a través de un registro, el cual esta desglosado de la siguiente manera:

  • Bit 0: Accede al Sistema Operativo (BIOS), incluido en la ROM del sistema. Dado que es utilizado para ciertas tareas comunes siempre es accedido.
  • Bit 1: Accede al Interprete de BASIC, incluido en la ROM del sistema.
  • Bits 2 y 3: Selección de banco, en la gama Atari 8 bits podemos tenemos hasta 4 bancos distintos de 16KB cada uno.
  • Bit 4: Nos indica que parte de los 64KB de memoria es accedida por la CPU.
  • Bit 5: Nos indica que parte de los 64KB de memoria es accedida por el ANTIC o el generador gráfico del Super XE (ver más adelante)
  • Bit 6: –
  • Bit 7: Inicia el autodiagnostico, includo en la ROM de serie en el sistema.

Es decir, gracias al registro del PIA podemos colocar unos 4 bancos de memoria en total en cada cartucho pero estos no pueden superar los 16KB de tamaño y unos 64KB es una cantidad muy irrisoria para una consola de 16 bits, pero existe el truco de activar el bit 6 y permitir hasta unos 8 bancos haciendo que el sistema se vaya a los 128KB, sigue siendo insuficiente para un sistema de 16 bits.

Tened en cuenta que en 1988, lo primeros juegos de Genesis/Mega Drive que aparecieron eran de 512KB y Atari no podía permitirse un sistema que soportase como mucho 128KB cuando la competencia podía llegar en cuanto a cartuchos hasta varios MB sin problemas, era un fallo de diseño bastante gordo. Esto significa que Atari tenía que inventar una clase nueva de cartucho para el Super XE, con una cantidad de pines mucho mayor. Pensad que el 65816 puede direccionar hasta unos 24 bits (16MB) por lo que cada banco de ROM en modo Super Xe no estaría limitado en cuanto a tamaño, pero en el documento no nos hablan de los cartuchos por lo que… Dejemos esto de lado por el momento.

Lo siguiente que nos aparece es un componente llamado New Freddie que es la interfaz de los diferentes chips con la RAM, el sistema utiliza por lo visto un mecanismo de RAM unificada con tiempos de RAM compartida como ocurre en el caso del Atari ST, pero para entender dicha referencia hemos de mirar como funciona la RAM del sistema, en el documento nos encontramos con la siguiente referencia:

Esto nos da unos 128KB de memoria, la cual estaría dividida en unos dos pozos de 64KB, por lo que podemos asignar un pozo de 64KB a lo que es la CPU y el sonido y otros 64KB al generador de gráficos, lo cual es una configuración muy parecida (descontando a como funciona el audio) a la de Genesis/Mega Drive con una configuración de 64KB+64KB, lo cual es viable para una consola de 1988, eso si, es menos que la memoria de la gama ST.

Aunque lo veremos con detalle más adelante, el modo bitmap tiene dos resoluciones:

  • 320*192*4= 32KB
  • 640*192*2= 32KB

Aunque esto lo contare más abajo, digamos que el búfer final ha de incluir el matiz y la luminancia, por compatibilidad hacía atrás con la gama 8 bits de Atari lo más seguro es que la cosa quede en 8 bits por pixel (matiz+luminancia) llegando a los 64KB exactos para el modo bitmap.

Sin salirnos de la RAM, la velocidad indica nos da también pistas sobre lo que podría ser el «New Fredie» ¿Cuanto de rápida es la RAM? Pues a unos 280ns… 250ns

¿El motivo de tachar? 280ns son unos 3.58Mhz, que es una velocidad multiple del colorburst de tal manera que el tempo de la RAM correspondiente queda desacoplado del tiempo del escaneo de linea. ¿Pero que tienen de especial los 250ns? Dos cosas, la primera de ellas es que Freddie es un chip que Atari añadió en algunos modelos posteriores de su gama de ordenadores de 8 bits que permitía acceder al ANTIC y al GTIA al mismo tiempo haciendo que la memoria funcionase al doble de velocidad de lo que lo hacía anteriormente (¿A cuanto?) a 250ns que es justamente la velocidad en la que funciona esta memoria.

La velocidad de acceso a la memoria de los sistemas de 8 bits de Atari es de 500ns (2Mhz). Pero en el caso que nos ocupa los 4Mhz de velocidad no se comparten… ¿Entonces? Utilizando los bits del registro del PIA que he comentado antes podemos hacer que por ejemplo la CPU apunte a la memoria de vídeo para escribir datos de la tabla de caracteres o generar el bitmap.

Lo que se ha de entender es que gracias al New Freddie, la CPU y el Generador Gráfico pueden acceder a bancos diferentes de la memoria sin llegar a molestarse el uno al otro.

Super XE Graphics.

Lo primero que nos deja claro el documento es que la forma de generar los gráficos del nuevo sistema poco o nada tiene que ver con la gama de 8 bits de Atari pese a su compatibilidad hacía atrás. Nos lo deja claro al tachar que la imagen se genera por listas de pantalla (ANTIC).

Lo de descartar por completo la salida de color por Luminancia+Crominancia hace referencia a la forma en la que el TIA y sus derivados gestionan el color. Nos marcan que la generación de color es externa al chip gráfico, pero no nos indican en todo el documento como piensan conseguirlo, aunque a ello ya llegaremos.

El sistema parece funcionar con dos modos de dibujar en pantalla, un modo basado en búfers de linea y por tanto que va al compás de la linea de escaneo del televisor y otro modo basado en un búfer de imagen que es un modo bitmap/bitplane.

Los modos 1 y 2 no es que estén repetidos sino que hacen mención al modo bitmap, por motivos de compatibilidad con la gama de 8 bits de Atari, el mecanismo del VSync, VBlank esta implementado para contar 192 lineas de escaneo. El modo bitmap no es descrito pero sabemos por el documento que existe.

Recordemos que generadores de patrones/sprites como el TMS9918 tienen un modo bitmap, pero no suelen tener mucha resolución debido a que reemplazan carácteres enteros por pixeles, haciendo que la resolución en modo bitmap sea muy pobre. Pero Atari en 1988 tenía su propio sistema gráfico basado en bitmaps que Shiraz Shivji había desarrollado para el Atari ST llamado Shifter, el cual funcionaba de una manera muy parecida al del clásico 6845CRT pero ampliando sus capacidades, permitiendo una resolución (en el ST) de 640×200 con 4 colores, casi la misma que vemos aquí, la cual se vería reducida a 192 lineas por la compatibilidad con la gama de 8 bits de Atari.

Con lo que no tendría compatibilidad es con el modo de 640×400 en monocromo, más que nada porque no estaría pensada para utilizarse con un monitor SM124, aparte que el sistema parece estar pensado para utilizar una salida RGB en exclusiva.

En realidad el que genera el búfer de imagen en los modos 2 y 3 (y la tabla en el modo 1) es el 65816, es decir, la propia CPU, que utiizaría la instrucción de transmisión de bloques de datos para escribir en la RAM asignada al generador gráfico. En realidad lo que hace un CRTC (es como esta marcado en el diagrama) es leer un búfer de imagen ya previamente generado.

El modo 1 en cambio esta descrito como un Búfer de Linea del siguiente tamaño:

Los 5 bits por pixel nos indican una paleta de 32 colores, lo más seguro es que esos 5 bits sean solo el matiz y falte la luminancia de cada pixel. Por cierto, la mención de lo Line Buffers nos indica que podría ser una evolución del chip Maria incluido en la Atari 7800, pero es solo una posibilidad. El caso es que pienso que Atari tenía planeado que al igual que en Maria que el Line Buffer estuviese dentro del mismo chip en vez de la memoria principal para que no hubiese conflicto entre el DAC de video y el generador de imagen en cuanto al acceso a la memoria.

En cuanto a la forma de organizar los gráficos ya hemos visto que no utiliza el metodo de los ordenadores de 8 bits de Atari, sino que estaríamos ante el clásico generador de patrones/sprites como el del TMS9918A y su multitud de derivados y el VIC-II (C64), uno esperaría encontrarse un mecanismo del tipo Blitter aquí dado que Atari estaba trabajando en uno por aquel entonces para recortar distancias con el Amiga.

  • 64 objetos por fotograma es decepcionante, y más cuando la Atari 7800 era muy burra en eso colocando más de 100 objetos gracias a la velocidad del Line Buffer
  • El sistema renderiza la imagen utilizando una lista de objetos/caracteres por lo que estaríamos realmente ante un generador de caracteres.
  • 16 objetos/caracteres/patrones/sprites por linea de escaneo, recordad que eso no incluye los objetos del fondo.
  • 16 colores por objeto (4 bits) de un total de 32 colores. ¿Colores diferentes para fondo y primer plano?
  • Tamaño de los carácteres de 8×8, pero posibilidad de magnificarlos en x2 y x4… (8×8, 8×16, 8×32, 16×8, 16×16, 16×32, 32×8, 32×16 y 32×32).
  • Hablan de una posible paleta de 4096 colores (2^12).
  • Hay que tener en cuenta que estos sistemas diferencias los gráficos de fondo de lo que son el plano de objetos/patrones/sprites.

Sorprende mucho la limitación de 64 patrones/sprites que lo dejaría el nivel del modo H32 de Genesis/Mega Drive, la Mark III/SMS y la Nintendo Famicom/NES.

Es posible que el sistema sea capaz de cambiar dicha lista cada x lineas de escaneo, pero no lo sabemos desde el momento en que esto no esta documentado. Lo que sabemos es que como lo generadores de patrones/sprites utiliza una tabla de patrones/sprites de 4 bytes por patrón/sprite, si la tabla se encuentra en la RAM entonces sería fácil cambiar el contenido de la misma el vuelo o cargar incluso una completamente nueva cada x lineas de escaneo. Dado que el tamaño máximo de cada patrón/sprite serie de 32 pixeles en vertical, esto significa que de poder hacerlo el mínimo sería cada 32 lineas y por tanto de poder trabajar con ello podríamos trabajar con hasta 192 conjuntos de patrones/sprites. Otro método sería el clásico de dividir la pantalla en tercios, pero eso es algo que no sabremos jamás ya que no sabemos si el sistema se desarrollo más allá de eso.

En cuanto a las tablas de los objetos:

La cual no es diferente a las tablas SAT/OAM de los derivados del TMS9918A.

Pero obviamente con una organización un poco diferente, os paso a desglosar que significa cada parte de la tabla del generador de patrones/sprites del Super Xe.

  • El bit 0 del primer byte no se utiliza sino los otros 6, lo que nos indica que hay una lista de 128 carácteres distintos por chip de memoria.
  • El segundo byte nos indica la posición vertical en la pantalla en la que se encuentra el objeto, esto significa que la resolución vertical no es mayor de 256.
  • El bit 0 del tercer byte junto a todo el cuarto byte nos indican la posición horizontal en pantalla, en total 9 bits por lo que la resolución horizontal nunca es mayor de 512 pixeles.
  • Los bits 1 y 2 nos sirven para indicar cuanto de grande queremos magnificar el patron/sprite en vertical.
  • El bit 3 nos permite cambiar que conjunto de colores, teniendo en cuenta que muestra 16 colores por objeto de 32 posibles en pantalla… pues tiene sentido que sea un bit.
  • Bit 4 voltea horizontalmente el patrón/sprite.
  • Bit 5 voltea verticalmente el patrón/sprite
  • Los bits 6 y 7 nos sirven para indicar cuanto de grande queremos magnificar el patron/sprite en vertical.

Si cada patrón/sprite es de 8×8 pixeles y 16 colores entonces cada mide unos 32 bytes, si hay unos 128 en total entonces… ¡4KB por banco! Hemos visto como cada banco puede tener unos 64KB de tamaño y que tenemos varios bancos distintos. Esto significa que podemos tener 16 bancos distintos de patrones/sprites pero no vemos implementado en ningún momento la selección de banco desde el propio sistema gráfico por lo que tiene sentido que esto se haga desde el mecanismo de la MMU como he explicado antes.

El siguiente punto son los fondos, los cuales tienen una configuración un poco distinta a los objetos.

Se nos confirma la resolución de 320×192 pixeles de nuevo para este modo (40×24 caracteres de 8×8 pixeles) pero la definición de color es un poco baja. Por otro lado es decepcionante que haya una sola capa de fondo, teniendo en cuenta que otros sistemas contra los que iba a competir podían colocar más capas de fondos. Por otro lado, los fondos tienen una tabla distinta a la de los objetos.

No tenemos el limite de la cantidad de patrones/sprites como ocurre con los objetos y solo tenemos unos 2 bytes por patrón/sprite, esto significan en teoría un total de 1920 bytes siendo ocupados en teória, pero el documento nos habla de una Name Table en total (para incluir las pantallas adyacentes de cara al scroll) de 64*32 patrones de fondo (512×256 pixeles), lo cual tiene sentido si miramos la anterior table de los objetos.

Si hacemos el calculo veremos que:

64*32*2(bytes de la tabla de fondo)= 4096 bytes = 4KB

El segundo byte es el Character Code que nos indica en que posición de 256 posibles se encuentra el patrón/sprite utilizado para los fondos. esto significa que la memoria para los fondo ocuparía otros 4KB por escenario que sumados a los 4KB de patrones/sprites hacen un total de 8KB.

El primer byte de la table empieza empieza por el bit TR (0), nos indica la prioridad que tendrían la capa de fondo respecto a la capa de objetos.

El sistema solo tendría dos planos en total, como he dicho antes es decepcionante teniendo en cuenta que las consolas de la competencia tendrían 3 e incluso 4 planos. No son dos dos planos de fondo+ uno de patrones/sprite porque el dibujo nos marca que tenemos la posibilidad de colocar los objetos de «fondo» en primer plano, esto junto a los 32 colores ya pinta bastante mal en cuanto a la calidad de imagen.

Los bits 1, 2 y 3 nos indican el color code, esto no es otra cosa que la selección de la paleta y tenemos un total de 8 paletas y dado que cada objeto soporta 4 colores pues nos da los 32 colores de marras pero no tenemos ninguna forma de seleccionar que paleta de colores queremos utilizar y eso que supuestamente hubiésemos tenido una de 4096 colores, pero claro, la propia documentación nos habla de que esto se hace a través de un chip externo.

Pero en el diagrama el último chip es el codificador de video, el MC1377, un codificador bastante estándar y no hay mención alguna de la codificación del color. Es más, esta ha de ser compatible con la utilizada en los ordenadores de 8 bits de Atari, la cual utiliza unos 16 matices de color con unos 8 o 16 niveles de luminancia por cada color.

La paleta estándar del Atari ST es RGB9, esto signfica que tenemos unos 512 colores (como Genesis/Mega Drive y PC-Engine/Turbografx) y dado que muestra unos 16 colores en pantalla podemos suponer que son 16 matices con unos 32 niveles distintos de luminancia. ¿Y de donde saldrían los 4096 colores? Pues utilizando una paleta RGB12, pero hemos de tener en cuenta que en el caso del Super XE, Atari no podría utilizar los matices de la paleta del ST.

Por lo que los juegos portados desde el ST se tendrían que recolorear por el hecho de utilizar una paleta de colores distinta. En todo caso la paleta de colores no podría ir más abajo de los 256 colores que necesita el GTIA para funcionar.

Ya par terminar en cuanto a lo gráficos y siguiendo con la tabla, tenemos el HREF y el VREF de los bits 4 y 5 hacen lo mismo que en la otra tabla, por lo que no merecen más explicación. El resto de la tabla no referencia a nada y con esto tendríamos ya suficiente como para saber como funciona el sistema a nivel visual.

¿Que le ocurrió al Super Xe/Mirai?

Atari nunca llego a terminar el chip Keri por lo que la compatibilidad hacía atrás se vio descartada y con ello hubo un cambio de CPU a la ya utilizada en la gama ST, un 68K de Motorola. Además en 1988 Atari había terminado el chip Blitter que Atari lanzo para la gama STe, el cual era mucho más eficiente que un simple generador de patrones/sprites y mucho más adecuado y avanzado. Pero lo más seguro es que Mirai evolucionase a la tampoco lanzada Atari Panther, de la cual hice una entrada en su día.

Pero Panther ya no fue un trabajo de Shiraz Shivji y aparte que llegado a un punto Atari tenía 3 consolas al mismo tiempo (Lynx, Panther y Mirai/Super Xe) de la que sabemos que descartaron la tercera para re-asignar a Shiraz Shivji al proyecto Atari TT.

De haber sido lanzada hubiese competido muy dignamente contra las consolas de Nintendo y Sega en occidente, hubiese sido un movimiento mucho más inteligente por parte de la directiva de Atari y ahora su marca no estaría relacionada con una estafa de crowdfunding de la que es mejor ni hablar.

Esto es todo, como siempre tenéis el Discord y los comentarios de la misma entrada para comentar el contenido de la misma.