Historicamente el Atari ST es visto como el ordenador que rivalizo con el Commodore Amiga, aunque realmente fue ideado inicialmente para ser un competidor directo del Apple Macintosh lo que afecto a su arquitectura de base, no en vano Atari en los primeros tiempos del Atari ST atacaba con su marketing no al Commodore Amiga 1000 que se acababa de lanzar sino al Apple Macintosh que había aparecido unos meses antes. ¿El motivo? El ST se presento meses antes de que oficialmente se presentará el Commodore Amiga.

1985-atari-america

Y las puyitas contra el Macintosh eran continuas.

El primer modelo que lanzaron del ST tuvo dos submodelos, el 520ST tenía unos 512KB de RAM de serie, el 1040ST 1MB de serie, por lo demás eran completamente iguales el uno con el otro en lo que a sus entrañas se refiere, pero hemos de tener en cuenta un elemento clave antes de hablar sobre este ordenador, su diseño fue como si los ingenieros de Atari de la época hubiesen cogido el Macintosh y lo hubiesen mejorado para abaratar su fabricación y cubrir los flecos que tenía el Apple Macintosh, en especial en el tema del sonido que era muy pero que muy superior que en el Macintosh pero en esta entrada no tratare el sonido sino los gráficos, pero para entender como se generan los gráficos se ha de entender toda la arquitectura al completo.

El Atari ST estaba compuesto por 5 chips principales y lo mejor es ir al grano y describirlos uno por uno.

#1 CPU Motorola 68K a 8Mhz, Memoria del Sistema y MMU.

El 68K dentro del Atari ST no presenta cambios algunos respecto al modelo estándar, no obstante es el más rapida de los tres ordenadores de 16 bits de mitad de los 80 por ir a unos 8Mhz en vez de los poco más de 7 Mhz de los otros dos. No es que sea una diferencia sustancial y veremos como en el Amiga los chips de apoyo hacen mucho liberando a la CPU de ciertos trabajos pesados y no podemos olvidar que el rendimiento de la CPU del ST era variable dependiendo del tipo de memoria que se colocase en el sistema.

La RAM del Atari ST  por lo general no estaba soldada, no olvidemos que hubo modelos que para ahorrar costes tenían directamente la memoria soldada a la placa y esta no se podia cambiar. Pero en los modelos donde si que se podía,  la memoria se encontraba en módulos SIMM de 30 contactos y de 8 bits de ancho de banda, dado que el 68K tenía un bus de unos 16 bits era necesario tener dos módulos de memoria conectados. Los modelos iniciales tenían montada memoria de 150ns (6.67 Mhz) pero era posible colocar modulos de 120ns (8.33 Mhz) e incluso de 100ns (10 Mhz) e incluso la propia Atari monto RAM más rapida en las revisiones al hardware, pero como he dicho antes lo bueno era que la RAM no estaba soldada por lo que era posible comprar un 520ST y ampliar la RAM del sistema e incluso cambiarla pero en configuraciones de 256KB o de 1MB por modulo solamente, por lo que es posible colocar hasta 4MB de memoria en el sistema, aunque pese al direccionamiento del 68K sería posible colocar hasta los 16MB el ST no soporta modulos de 2MB y 4MB.

La otra memoria del sistema era la ROM, el modelo original soportaba hasta 320KB de memoria ROM en el sistema pero incluía de serie unos 192 KB de ROM, esos eran utilizados sobretodo para ciertas rutinas del SO del ordenador (¿os suena de algo?) y se podía ampliar la ROM a través del puerto de cartuchos. Siendo una de las expansiones más curiosas el del Magic Sac+ que colocaba la ROM del Macintosh y permitía ejecutar los programas en el ST, aunque solo los programas compatibles con el Mac de 64KB, es decir, los primeros modelos.

7273457d843fc3cc6227c1821cf27bcb

Pero al contrario de lo que ocurría con el Macintosh, el 68K no accedía directamente a la memoria sino que había un elemento entre este y la RAM, que era la unidad MMU. Aunque posteriores CPUs de la familia 68K acabaron añadiendo dicha unidad y el 80286 ya lo tenía de serie, en el caso del ST Atari añadio un chip haciendo las funciones de MMU al que la CPU estaba conectado. La MMU es el chip encargado de controlar el direccionamiento de la memoria de los diferentes chips al que esta conectado y tiene la capacidad de direccionar unos 24 bits de memoria, pero dado que utiliza 2 bits para marcar que procesador le realiza la petición a memoria se limita a unos 22 bits solamente y de ahí que el ST solo pueda llegar a los 4MB de RAM. La MMU esta en el ST para evitar conflictos en el acceso a la memoria, la CPU y cualquiera de los otros 3 chips de apoyo envían una petición en forma de dirección a la MMU que les traslada y esta accede a memoria buscando el dato y lo envía de vuelta a los diferentes procesadores del sistema, pero a la hora de generar los gráficos la MMU es sumamente necesaria dado que el SHIFTER necesita acceder a la RAM del sistema para poder acceder al búfer de imagen donde este es almacenado en un espacio de 32KB de memoria dentro de la memoria principal.

 #2 La pantalla del ST, el GLUE y el SHIFTER

La diferencia principal entre el Apple Macintosh y el ST es que mientras el ordenador de Apple tiene un mecanismo clásico de dibujado al compas del haz de electrones (por la falta de memoria del primer modelo) el ST no tenía ese problema por lo que fue diseñado para leer del búfer de imagen y generar dicha información a partir de lo que obtiene, las especificaciones de la pantalla del ST son:

  • 508 ciclos de reloj por linea (320 ciclos en la imagen visible y 188 ciclos de HBlank).
  • 315 lineas de escaneo, de las cuales solo 200 son visibles. El resto son VBlank y Overscan.
  • 70hz de velocidad de refresco.

El monitor venía de serie con el ordenador al igual que el del Apple Macintosh, pero no formaba parte del mismo cuerpo.

ruxs9v

Pero para entender como la pantalla del ST generaba los gráficos hemos de tener en cuenta dos chips de apoyo que son el GLUE y el SHIFTER. En el caso concreto del GLUE su trabajo es cuanto menos curioso, su trabajo en el sistema es comunicarse con varios de los controladores de E/S del sistema por lo que podríamos decir que es un Southbridge pero con un matiz, es el encargado de controlar la señal del monitor y por tanto es el encargado de controlar la velocidad del haz de electrones y el número de lineas y es que el ST puede trabajar con 3 resoluciones distintas.

  • 640×400 con 1 bit de color. graphics_leap9
  • 640×200 con 2 bits de color (4 colores):graphics_leap10
  • 320×200 con 4 bits de color (16 colores):graphics_leap11

Pero los colores no los obtenía directamente del GLUE sino a través del Shifter que es el que tenía acceso a los 32KB de memoria principal y accedía a los datos en el búfer de imagen a través del MMU, recordemos que el búfer de imagen en el Atari ST se encontraba en la RAM principal del sistema pero el SHIFTER solo le leía de manera lineal por lo que la velocidad del haz de electrones y cada cuanto se producía un salto de linea eso era llevado a cabo por el GLUE, pero el proceso completo del SHIFTER se puede ver en el siguiente diagrama:

stbuffer

En realidad los tres modos ocupaban lo mismo en la RAM y era posible generar el búfer de imagen en cualquier lado de la RAM e incluso generar dos búfers de imagen si se quería, solo se tenía que enviar al SHIFTER desde la CPU y pasando por el MMU una instrucción en una dirección de memoria concreta para marcarle en que posición de la memoria empezaba el bufer de imagen en el programa actual y el SHIFTER leía continuamente de dicho espacio de memoria cuando recibía el permiso para hacerlo. Es decir, para evitar aberraciones en la imagen por la lectura continua, por lo que la MMU le cerraba el paso hasta la memoria al SHIFTER hasta que la imagen no estuviese preparada, por lo que estamos ante un sistema donde la tasa de fotogramas no estaba fijada a la velocidad de la pantalla y era variable según la complejidad del programa y la carga gráfica del mismo.

El SHIFTER independientemente de la resolución siempre tenía que leer la misma cantidad de datos, unos 32KB de memoria.

  • 320*200*4= 256.000 = 32KB.
  • 640*200*2= 256.000 = 32KB.
  • 640*200*1= 256.000 = 32KB.

Pero como he comentado la tasa de fotogramas es variable, un juego o una aplicación que vaya a 60fps le hará una petición de 1920 KB/s, uno que vaya a 25 fps le hará una petición de 800KB/seg y si tenemos en cuenta las diferentes velocidades de RAM posibles esto era un problema para los programadores porque habían modelos del ST donde los juegos iban

#3 Generando Gráficos en el Atari ST

Bien, hemos visto como funciona el sistema de lectura del búfer de imagen para su posterior transformación en imagenes pero… ¿Como se generaban las imagenes? ¿Que procesador dedicado lo hacía?

tumblr_inline_mgv01qbwpt1r5c8sb

 

Todo el trabajo de la generación de imagen se hacía a través del 68K, ahora bien, en el caso concreto de los videojuegos los gráficos obviamente estaban generados ya en el mismo programa en forma de patrones y sprites pero los modelos originales del ST al tener que competir contra el Apple Macintosh no tenían ningún hardware dedicado a sprites.

PanicRon

Pe…. pero… Urian. Si el ST tuvo juegos basados en sprites, existieron. No puede ser que no tuviese hardware dedicado a ello.

Es cierto, pero el ST original no tenía hardware dedicado a los sprites por lo que la imagen era generado por la CPU o mejor dicho, era la CPU la que escogía que patrones eran necesarios en cada momento de la composición de la escena y esto era un cuello de botella brutal. ¿El motivo? Cada fotograma requería unos 32KB de memoria, dado que el 68K tenía un bus de 16 bits uno puede pensar que con unos 16000 ciclos era suficiente para generar una imagen, pero resulta que el 68K necesitaba unos 4 ciclos de reloj para acceder a memoria y escribir 2 bytes, por lo que la cosa se transformaba en 64.000 ciclos de unos 8.000.000 de la CPU por fotograma, imaginaos ahora un juego a 60fps en el modelo original del ST.

64.000*60= 3.840.000 ciclos.

Esto es un 48% de la potencia de la CPU que se iba para generar los gráficos en el ST original, obviamente si hablamos de un dispositivo pensado para competir contra el Apple Macintosh el ST original estaba muy bien y era mucho mejor, pero pese al precio del ordenador de Apple este se volvía más popular y no hablemos de los Compatibles PC que se estaban comiendo el mercado, esto forzo a Atari a renovar el hardware de su ordenador y hacerlo más adecuado para videojuegos.

#4 El Atari STe (1989)

La arquitectura general a la hora de generar gráficos del ST era la siguiente:

starchitecture

Con tal de mejorar el rendimiento de cara a los patrones/sprites y poder competir contra el Amiga en ese aspecto Atari se vio obligada a añadir un BLITTER en el hardware quedando al arquitectura del STE de la siguiente manera.

stearchitecture

El motivo de ello es que el Blitter del Amiga era el punto fuerte para los gráficos y le daba una enorme ventaja no solo en videojuegos sino también en otro tipo de aplicaciones. Pero el Blitter no es un procesador gráfico, la raiz de su nombre es Blit por el hecho de que lo que «genera» son bloques de bits aunque su trabajo es desplazar bloques de bits a gran velocidad de una memoria origen a una memoria destino, da igual si es fisicamene la misma memoria o no, pero esto era ideal para ir moviendo bloques de pixeles de un lado a otro… ¿Y que es un bloque de pixeles? Pues un bloque de bits en el fondo.

El BLITTER en el STe movía bloques de 16×16 pixeles sin intervención de la CPU fuera de decirle en que dirección de memoria se encontraba el bloque de datos a desplazar y cual era la dirección de destino. Dado que la CPU necesitaba 4 ciclos para transmitir un dato de 16 bits y 5 para transmitir uno de 32 bits y el BLITTER requería origen y destino entonces era necesario unos 10 ciclos de reloj de la CPU pero para trasmitir un bloque de 16×16 pixeles, pero la magia del BLITTER es que el traslado de datos lo hacía sumamente rápido en solo un ciclo de reloj por byte, por lo que para componer un fotograma completo de 32KB, dado que el bus del BLITTER era de unos 16 bits/2 bytes hacía el trabajo no en 64.000 ciclos sino en 16.000 ciclos solo por fotograma.

A esto le hemos de añadir que cada bloque de 16×16 (cada 256 pixeles) requería unos 10 ciclos de reloj de la CPU y el rendimiento siempre era el mismo independientemente de la resolución.

(640*400)/(16*16*1 byte)= 1000 bloques*10 ciclos por bloque= 10.000 ciclos de CPU por fotograma.

(640*200)/(16*16*2 bytes)= 1000 bloques*10 ciclos por bloque= 10.000 ciclos de CPU por fotograma.

(320*200)/(16*16*4 bytes)= 1000 bloques*10 ciclos por bloque= 10.000 ciclos de CPU por fotograma.

Total a 60 fps= 600.000 ciclos de la CPU

Comparad esto con los  3.840.000 ciclos sin la participación del BLITTER y empezaréis a ver la mejora que supuso el añadido de esta pieza. El resto del sistema en el caso del STe funcionaba igual que en el ST pero lo que se veía afectado era el código de los juegos ya que se tenían que programar de nuevo los juegos para adaptarlos al uso del BLITTER pero había un problema añadido de incompatibilidad entre modelos dada la existencia del STfm, un modelo de bajo coste que prescindia por completo del monitor convencional a base de tener un modulador RF para conectarlo al televisor, pero dicho modelo tenía un problema y es que en realidad era un ST a secas con la capacidad de poder instalarle el BLITTER en la placa y el problema es que era un modelo muy popular de los ST por lo que los desarrolladores tenían problemas porque no había una configuracion estándar del sistema y es por ello que para muchos era mejor el Amiga.

No obstante pese al añadido del BLITER la capacidad visual del Amiga continuaba siendo algo superior la del Atari ST pero los motivos de ello ya los comentare en la entrada sobre el Commodore Amiga.

#5 El Atari TT y el Atari Falcon

El Atari TT fue una mejora del Atari ST que inicialmente se penso como estación Unix pero que por la incapacidad de Atari de hacer una versión de Unix acabo siendo un sustituto fallido del ST donde todos sus componentes se vieron renovados, es interesante comentar su arquitectura.

atari_tt030

La CPU era un 68030, una versión avanzada del 68K con unidad de coma flotante, cache L1 y direccionamiento y bus de 32 bits. La velocidad de reloj era de unos 32Mhz pero el bus era de unos 16Mhz, eso si, de 32 bits por lo que el ancho de banda respecto al modelo original se cuadriplicaba, pero lo más importante era que dicha CPU llevaba una unidad MMU de serie por lo que era necesario renombrar la «MMU» del ST a «MCU» y de paso renovar el resto de componentes.

ttarchitecture

El TT era 100% compatible hacía atrás con el STe, pero hay que tener en cuenta que añadía una serie de modos gráficos adicionales. Uno de ellos era el modo VGA de 640×480 a 16 colores gracias a que se podía conectar un monitor VGA. El sistema disponía de 2MB de memoria y los modos de video podían ser los mismos que en el ST original (32KB de memoria reservados) o los modos TT donde el búfer de imagen era de 154KB.

640*480*4= 1.228.800= 153.6 KB

320*480*8 (256 colores)=  1.228.800= 153.6 KB

Como curiosidad la paleta había pasado de los 512 colores a los 4096 colores.

En realidad el TT no era más que un STe vitaminado y si os preguntáis donde se encuentra el TT BLITTER este fue integrado junto al GLUE y actualizado para funcionar a unos 16Mhz de velocidad de reloj en vez de los 8 Mhz, desgraciadamente el TT por su alto precio no llego jamás a tener una base lo suficientemente grande como para poder competir y en 1990 cuando fue lanzado no pudo competir por precio con el resto por lo que Atari decidió lanzar una nueva generación del ST, el Atari Falcon, el cual si que fue ideado desde el principio como un sustituto del STe

#6 Atari Falcon

atari_falcon_030_white_bg

El Falcon fue el último intento de Atari de poder tener presencia en el mercado de los ordenadores domésticos, al igual que el TT tenía un 68K30 pero con la diferencia de que este funcionaba a 16Mhz en el Falcon y estaba acompañado del modelo base de 1MB aunque era ampliable a 16MB de RAM en total.

En cuanto a la arquitectura del sistema el Falcon no tiene mucho secreto, Atari unifico el TT GLU y el TT SHIFTER en un mismo chip llamado VIDEL para recortar costes de fabricación, pero curiosamente dejo el BLITTER fuera del VIDEL para conbinarlo con el MCU y crear un chip llamado COMBEL.

FalconArchitecture.png

 

No obstante el VIDEL tenia ciertas mejoras al ser un chip renovado respecto al TT GLU y al TT SHIFTER, entre ellos modos de video completamente nuevos y una paleta de colores de 16 bits por lo que si el TT era capaz de soportar hasta 8 bit planes en el caso del Falcon la cosa subía a 16, por otro lado la cantidad de resoluciones soportadas por el Falcon respecto al ST y al TT aumento considerablemente.

Resolución BitPlanes Colores Memoria en KB
320×200 2 4 16
320×200 4 16 32
320×200 8 256 64
320×200 16 65536 128
320×400 2 4 32
320×400 4 16 64
320×400 8 256 128
320×400 16 65536 256
320×240 2 4 19,2
320×240 4 16 38,4
320×240 8 256 76,8
320×240 16 65536 153,6
320×480 2 4 38,4
320×480 4 16 76,8
320×480 8 256 153,6
320×480 16 65536 307,2
640×200 1 2 16
640×200 2 4 32
640×200 4 16 64
640×200 8 256 128
640×200 16 65536 256
640×400 1 2 32
640×400 2 4 64
640×400 4 16 128
640×400 8 256 256
640×400 16 65536 512
640×240 2 4 38,4
640×240 4 16 76,8
640×240 8 256 153,6
640×480 2 4 76,8
640×480 4 16 153,6
640×480 8 256 307,2

Pero las pocas ventas de la familia ST y el hecho de que el Falcon fuese un fiasco comercial enorme hizo apenás se escribiesen juegos para el Falcon por lo que acabo siendo un STE glorificado a sobreprecio porque en el momento en que el Falcon llego al mercado el interés por el STE se había esfumado y los pocos interesados tenían uno disponible a bajo precio. En cuantoa  las aplicaciones no lúdicas estaba claro en ese momento que el futuro se encontraba en el PC realmente y en mucha pero qe mucha menor medida en el Macintosh.

No obstante el Falcon de haber aparecido en el momento justo y no tan tarde hubiese sido una máquina interesante para juegos y quizas la historia hubiese sido diferente.

Y con este termino esta entrada sobre el Atari ST.