Atari BÁSICO

Atari BASIC es un intérprete para el lenguaje de programación BASIC que se envió con la familia Atari de 8 bits de computadoras domésticas basadas en 6502. A diferencia de la mayoría de los BASIC estadounidenses de la era de las computadoras domésticas, Atari BASIC no es un derivado de Microsoft BASIC y difiere de manera significativa. Incluye palabras clave para características específicas de Atari y carece de soporte para arreglos de cadenas, por ejemplo.

El idioma se distribuyó como un cartucho de ROM de 8 KB para usar con las computadoras Atari 400 y 800 de 1979. A partir de 600XL y 800XL en 1983, BASIC está integrado en el sistema.

A pesar de que las computadoras Atari de 8 bits funcionan a una velocidad más alta que la mayoría de sus contemporáneos, varias decisiones técnicas colocaron a Atari BASIC casi al final en los puntos de referencia de rendimiento. Los autores originales abordaron la mayoría de estos problemas en una serie de versiones mejoradas: BASIC A+ (1981), BASIC XL (1983) y BASIC XE (1985). También apareció una gran cantidad de intérpretes y compiladores de terceros como Turbo-Basic XL.

El código fuente completo y anotado y las especificaciones de diseño de Atari BASIC se publicaron como The Atari BASIC Source Book en 1983.

Desarrollo

Las máquinas que se convertirían en la familia Atari de 8 bits se desarrollaron originalmente como consolas de videojuegos de segunda generación destinadas a reemplazar a Atari VCS. Ray Kassar, el nuevo presidente de Atari, decidió desafiar a Apple Computer construyendo una computadora para el hogar.

Esto significaba que los diseños debían incluir el lenguaje de programación BASIC, el estándar para computadoras domésticas. A principios de 1978, Atari obtuvo la licencia del código fuente para la versión MOS 6502 de Microsoft BASIC. Se ofreció en dos versiones: una con un formato de coma flotante de 32 bits que ocupaba unos 7800 bytes cuando se compilaba y otra con un formato extendido de 40 bits que rondaba los 9 KB.

Incluso la versión de 32 bits apenas cabía en el tamaño de 8 KB del formato de cartucho ROM de la máquina. Atari también sintió que necesitaba expandir el lenguaje para admitir las funciones de hardware de sus computadoras, similar a lo que Apple había hecho con Applesoft BASIC. Esto aumentó el tamaño de la versión de Atari a alrededor de 11 KB; AppleSoft BASIC en Apple II+ tenía una longitud de 10.240 bytes. Después de seis meses, el código se redujo hasta casi caber en una ROM de 8 KB, pero Atari se enfrentaba a la fecha límite de enero de 1979 para el Consumer Electronics Show (CES), donde se demostrarían las máquinas. Decidieron pedir ayuda para tener una versión de BASIC lista a tiempo para el espectáculo.

Microsistemas Shepardson

Cartucho de 8K Atari BASIC

En septiembre de 1978, Shepardson Microsystems ganó la licitación para completar BASIC. En ese momento estaban terminando Cromemco 16K Structured BASIC para las máquinas de bus Cromemco S-100 basadas en Z80. Los desarrolladores Kathleen O'Brien y Paul Laughton usaron Data General Business Basic, una implementación de solo números enteros, como inspiración para su BASIC, dada la experiencia de Laughton con Data General en un sistema de tiempo compartido.

Cromemco BASIC incluyó una implementación extendida de punto flotante usando un formato decimal codificado en binario (BCD) de 14 dígitos que fue posible usando los 16 registros del procesador Zilog Z80. Como convirtió todos los datos al formato interno en el momento de la edición, pequeñas constantes como "1" consumiría una cantidad considerable de memoria, y esto podría ser un problema particular al almacenar matrices de números. Para abordar esto, el idioma también admitía un formato BCD de 6 dígitos. También incluía un formato entero de 16 bits separado para almacenar valores internos como números de línea y valores de sistema similares.

Incluso los BASIC más pequeños en el 6502 generalmente usaban alrededor de 10K, por ejemplo, Commodore BASIC usaba 9K pero también confiaba en el soporte de KERNAL, mientras que Applesoft BASIC usaba 10780 bytes. Para cumplir con el objetivo de encajar en una ROM de 8K, el nuevo BASIC se dividiría en dos partes, el idioma mismo en el cartucho y una biblioteca FP separada que usaría 2K en la ROM de 10K del sistema. Para caber dentro de 2k, el sistema de coma flotante admitía solo el formato de 6 dígitos.

Atari aceptó la propuesta y, cuando se finalizaron las especificaciones en octubre de 1978, Laughton y O'Brien comenzaron a trabajar en el nuevo lenguaje. El contrato especificaba la fecha de entrega el 6 de abril de 1979 o antes y esto también incluía un sistema de gestión de archivos (más tarde conocido como DOS 1.0). Los planes de Atari eran llevar una versión temprana de 8K de Microsoft BASIC al CES de 1979 y luego cambiar a Atari BASIC para la producción. El desarrollo avanzó rápidamente, ayudado por una cláusula de bonificación en el contrato, lo que llevó a que la versión inicial se entregara en octubre. Atari llevó una versión de cartucho de 8K a CES en lugar de la de Microsoft. Atari Microsoft BASIC más tarde estuvo disponible como un producto separado.

Lanzamientos

La versión que Shepardson le dio a Atari para la demostración de CES no pretendía ser definitiva, y Shepardson siguió corrigiendo errores. Desconocido para Shepardson, Atari ya había enviado la versión CES a la fabricación.

Esta versión se conoció más tarde como Revisión A. Contiene un error importante en una rutina que copia la memoria: eliminar líneas de código que tienen exactamente 256 bytes de largo provoca un bloqueo después de que se ingresa el siguiente comando. La tecla Restablecer no lo soluciona.

Revisión B intentó corregir los principales errores de la Revisión A y se lanzó en 1983 como una ROM integrada en los modelos 600XL y 800XL. Mientras solucionaba el error de copia de memoria, el programador notó el mismo patrón de código en la sección para insertar líneas y aplicó la misma solución. En cambio, esto introdujo el error original en este código. Insertar nuevas líneas es mucho más común que eliminar las antiguas, por lo que el cambio aumentó drásticamente la cantidad de bloqueos. La Revisión B también agrega 16 bytes a un programa cada vez que se SAVEd y LOADed, lo que eventualmente hace que la máquina se quede sin memoria incluso para los programas más pequeños. Mapping the Atari los describió como "errores asombrosos" y aconsejó a los propietarios de la Revisión B "No tonteen; obtener la nueva ROM, que está disponible en el cartucho" de Atari. El libro proporciona un programa de escritura para parchear la Revisión B a la Revisión C para aquellos que no tienen el cartucho.

Revisión C elimina las fugas de memoria de la Revisión B. Está integrada en versiones posteriores del 800XL y en todos los modelos XE, incluido el XEGS. La revisión C también estaba disponible como cartucho.

La versión se puede determinar escribiendo PRINT PEEK(43234) en el indicador READY. El resultado es 162 para la Revisión A, 96 para la Revisión B y 234 para la Revisión C.

Descripción

Edición de programas

Los errores de sintaxis se reportan inmediatamente después de que se introduce una línea.

Al igual que la mayoría de los BASIC de computadoras domésticas, Atari BASIC se basa en su editor de líneas. Las líneas de programa pueden ser hasta tres líneas de pantalla físicas de 40 caracteres, 120 caracteres en total. El cursor se puede mover libremente, y el editor rastrea automáticamente de qué línea de programa BASIC forma parte la línea de pantalla actual. Por ejemplo, si el cursor está posicionado actualmente en la línea 30 y el usuario usa el cursor hacia arriba en la línea 20, cualquier edición desde ese punto se llevará a cabo en la línea 20.

El editor de Atari BASIC detecta muchos errores que no se notarían en las versiones derivadas de MS. Si se encuentra un error, el editor vuelve a mostrar la línea, resaltando el texto cerca del error en video inverso. Los errores se muestran como códigos numéricos, con las descripciones impresas en el manual. Debido a la forma en que funciona el editor de líneas, el usuario puede corregir el error de inmediato. En el ejemplo que se muestra arriba (con PRUNT), el error se puede corregir moviendo el cursor sobre la U y escribiendo I (el editor solo tiene un modo de sobrescritura), y presionando RETURN.

Una línea ingresada con un número inicial, de 0 a 32767, se inserta en el programa actual o reemplaza una línea existente. Si no hay número de línea, el intérprete le asigna el número -1 (8000₁₆) y los comandos se ejecutan inmediatamente, en "modo inmediato". El comando RUN ejecuta el programa almacenado desde el número de línea más bajo. Atari BASIC permite ejecutar todos los comandos en ambos modos. Por ejemplo, LIST se puede usar dentro de un programa, mientras que en muchos intérpretes esto estaría disponible solo en modo inmediato.

Durante la entrada, las palabras clave se pueden abreviar utilizando el patrón establecido por Palo Alto Tiny BASIC, escribiendo un punto en cualquier punto de la palabra. Entonces L. se expande a LIST, al igual que LI.. Solo se deben escribir suficientes letras para que la abreviatura sea única, por lo que PLOT requiere PL. porque la única letra P no es única. Para expandir una abreviatura, el tokenizador busca en su lista de palabras reservadas para encontrar la primera que coincida con la porción suministrada. Los comandos de uso más común aparecen primero en la lista de palabras reservadas, con REM al principio (se puede escribir como .). Cuando el programa se LISTed más tarde, siempre escribirá las palabras completas con tres excepciones: PRINT tiene un sinónimo, ?; GOTO tiene un sinónimo, GO TO; y LET tiene un sinónimo que es la cadena vacía (entonces 10 LET A = 10 y 10 A = 10 significan lo mismo). Estos son tokens separados, por lo que permanecerán como tales en la lista de programas. MS BASIC también permitía ? como una forma abreviada de PRINT, pero esto usaba el mismo token, por lo que se expandió de nuevo a IMPRIMIR when LISTed, tratándolo como una abreviatura, no como un sinónimo.

Tokenizador

Cuando el usuario presiona RETURN mientras edita, la línea actual se copia en el búfer de línea de entrada BÁSICO en la memoria entre 580 y 5FF₁₆. El tokenizador de Atari BASIC escanea el texto, convirtiendo cada palabra clave en un token de un solo byte (por ejemplo, PRINT es 20₁₆), cada número a un valor de punto flotante de seis bytes, cada nombre de variable a un índice en una tabla, y así sucesivamente, hasta que la línea se convierta por completo en un formato fácil de interpretar. El resultado se almacena en un búfer de salida ubicado en los primeros 256 bytes de la memoria libre disponible más baja, señalado por el puntero LOMEM almacenado en 80, 81₁₆. Luego, la salida del tokenizador se reubica. El programa se almacena como un árbol de análisis.

Shepardson se refirió a este concepto de tokenización completa como un "intérprete de precompilación". El código tokenizado resultante elimina cualquier análisis durante el tiempo de ejecución, lo que lo hace más rápido. Tiene la desventaja de que las pequeñas constantes, como 0 o 1, son de seis bytes cada una, más largas que el texto original.

Un conjunto de punteros (direcciones) indica varios datos: los nombres de las variables se almacenan en la tabla de nombres de variables (VNTP – 82, 83₁₆) y sus valores se almacenan en la tabla de valores de variables (señalada en VVTP – 86, 87₁₆). Al desviar los nombres de las variables de esta manera, una referencia a una variable necesita solo un byte para direccionar su entrada en la tabla apropiada. Las variables de cadena tienen su propia área (apuntada a STARP – 8C, 8D₁₆) al igual que la pila de tiempo de ejecución (apuntada a RUNSTK – 8E, 8F₁₆) utilizada para almacenar los números de línea de las declaraciones en bucle (FOR...NEXT) y subrutinas (GOSUB...RETURN). Finalmente, el final del uso de la memoria BÁSICA se indica mediante una dirección almacenada en MEMTOP - puntero 90, 91₁₆).

Funciones matemáticas

Atari BASIC incluye tres funciones trigonométricas: seno, coseno y arco tangente. DEG y RAD establecen si estas funciones usan radianes o grados, por defecto en radianes. Ocho funciones adicionales incluyen redondeo, logaritmos y raíz cuadrada. La función aleatoria, RND, genera un número entre 0 y 1; el parámetro no se utiliza.

Manejo de cadenas

Atari BASIC copió el sistema de manejo de cadenas de Hewlett-Packard BASIC, donde el tipo de datos básico es un solo carácter y las cadenas son matrices de caracteres. Internamente, una cadena se representa mediante un puntero al primer carácter de la cadena y su longitud. Para inicializar una cadena, debe DIMensionarse con su longitud máxima. Por ejemplo:

10 DIM A$()20)20 PRINT "ENTER MESSAGE: ";30 INPUT A$40 PRINT A$

En este programa, se reserva una cadena de 20 caracteres y se truncarán los caracteres que excedan la longitud de la cadena. La longitud máxima de una cadena es de 32.768 caracteres. No hay soporte para matrices de cadenas.

Se accede a una cadena mediante funciones de indexación de matriz o división. A$(1,10) devuelve una cadena de los primeros 10 caracteres de A$. Las matrices están indexadas en 1, por lo que una cadena de longitud 10 comienza en 1 y termina en 10. Las funciones de corte simplemente establecen punteros a los puntos de inicio y final dentro de la memoria asignada existente.

Las matrices no se inicializan, por lo que una matriz o cadena numérica contiene los datos que había en la memoria cuando se asignó. El siguiente truco permite la inicialización rápida de cadenas y también es útil para limpiar grandes áreas de memoria de basura no deseada. Las matrices numéricas solo se pueden borrar con un bucle FOR...NEXT:

10 REM A$ con 1000 caracteres de X20 DIM A$()1000)30 A$="X":A$()1000)=A$:A$()2)=A$

La concatenación de cadenas funciona como en el siguiente ejemplo. La cadena de destino debe ser lo suficientemente grande para contener la cadena combinada o se producirá un error:

10 DIM A$()12),B$()6)20 A$="Hola":B$="¡Ahí!"30 A$()LEN()A$)+1)=B$40 PRINT A$

Los valores en declaraciones DATA están delimitados por comas y sin tipo. En consecuencia, las cadenas en las sentencias DATA no suelen estar entre comillas. Como resultado, no es posible que los elementos de datos contengan una coma, pero pueden incorporar comillas dobles. Los valores numéricos en las sentencias DATA se leen como cadenas o como números según el tipo de variable en la que se leen. La instrucción READ no se puede utilizar con variables de matriz.

Entrada/salida

El sistema operativo Atari incluye un subsistema para entrada/salida (E/S) de dispositivos periféricos conocido como CIO (entrada/salida central). La mayoría de los programas se pueden escribir independientemente del dispositivo que utilicen, ya que todos se ajustan a una interfaz común; esto era raro en las computadoras domésticas en ese momento. Los nuevos controladores de dispositivos podrían escribirse con bastante facilidad y estarían automáticamente disponibles para Atari BASIC y cualquier otro programa que use el sistema operativo Atari, y los controladores existentes podrían ser reemplazados o aumentados por otros nuevos. Un reemplazo E:, por ejemplo, podría desplazar el que está en la ROM para proporcionar una pantalla de 80 columnas, o aprovecharlo para generar una suma de verificación cada vez que se devuelve una línea (como se utiliza para verificar una lista de programas tecleados).

Atari BASIC admite el acceso CIO con palabras reservadas OPEN #, CLOSE #, PRINT #, INPUT #, GET #, PUT #, NOTE #, POINT # y XIO #. Hay rutinas en el sistema operativo para funciones de dibujo de gráficos simples, pero no todas están disponibles como palabras clave específicas de BASIC. PLOT y DRAWTO para dibujo de líneas son compatibles, mientras que un comando que proporciona relleno de área para formas geométricas lineales primitivas no lo es. La función de relleno se puede utilizar a través del punto de entrada general de CIO, que se llama mediante el comando BÁSICO XIO.

La instrucción BASIC OPEN # prepara un dispositivo para el acceso de E/S:

10 REM Abre el dispositivo de cassette en el canal 1 para leer en BASIC20 OPEN #1,4,0,"C:MYPROG.DAT"

Aquí, OPEN # significa "garantizar que el canal 1 sea gratuito," llame al controlador C: para preparar el dispositivo (esto pondrá los carretes de cinta de casete en tensión y hará avanzar los cabezales manteniendo el reproductor de cinta de casete "en pausa"). 4 significa "leer" (otros códigos son 8 para escribir y 12 = 8 + 4 para "lectura y escritura"). El tercer número es información auxiliar, establecida en 0 cuando no se necesita. El C:MYPROG.DAT es el nombre del dispositivo y el nombre del archivo; el nombre del archivo se ignora para el controlador del casete. Los dispositivos físicos pueden tener números (principalmente discos, impresoras y dispositivos serie), por lo que "P1:" podría ser el trazador y "P2:" la impresora de margarita, o "D1:" puede ser una unidad de disco y "D2:" y así sucesivamente Si no está presente, se asume 1.

La instrucción LPRINT envía una cadena a la impresora.

A se lee PEEKing ubicaciones de memoria mantenidas por el controlador de teclado o abriéndolo como un archivo (por ejemplo, OPEN 1,4,0,"K:":OBTENER #1,A$). Este último espera una pulsación de tecla.

Al escribir DOS desde BASIC sale al comando Atari DOS menú. Todos los programas no guardados se pierden a menos que se haya habilitado una función de archivo de intercambio de memoria en el disco actual. No hay ningún comando para mostrar un directorio de disco desde BASIC; esto debe hacerse saliendo a DOS.

Gráficos y sonido

Atari BASIC admite sonido (a través de la instrucción SOUND), gráficos (GRAPHICS, SETCOLOR, COLOR, PLOT, DRAWTO), y controladores (STICK, STRIG, PADDLE, PTRIG). La instrucción SOUND establece uno de los 4 canales de onda cuadrada del hardware con parámetros de volumen, tono y distorsión.

BASIC no admite capacidades avanzadas del hardware, como una resolución de tono más alta, filtros de paso alto, sonido y formas de onda digitalizados, gráficos de jugadores/misiles (sprites), conjuntos de caracteres redefinidos, desplazamiento y modos de gráficos personalizados; estos requerirán rutinas de lenguaje de máquina o declaraciones PEEK/POKE. No se puede acceder simplemente a algunos de los 17 modos básicos de caracteres/gráficos admitidos por el hardware desde BASIC en el Atari 400/800 ya que las ROM del sistema operativo no los admiten. Estos incluyen algunos modos de caracteres multicolores (antic modos 4 y 5), modo de caracteres descendentes (antic modo 3) y los modos de 2 y 4 colores de mayor resolución (antic modos C y E, 160x192 píxeles). La única forma de acceder a ellos es a través de PEEK/POKE o lenguaje de máquina, configurando los registros ANTIC y la Lista de visualización manualmente. Las ROM del sistema operativo en el XL/XE agregaron soporte para estos modos, excepto el modo ANTIC 3, que requiere un juego de caracteres redefinido en la RAM para funcionar correctamente.

Los modos de mapa de bits en BASIC normalmente están configurados para tener una ventana de texto que ocupa las últimas cuatro filas en la parte inferior de la pantalla para que el usuario pueda mostrar indicaciones e ingresar datos en un programa. Si se agrega un 16 al número de modo invocado a través de la instrucción GRAPHICS, toda la pantalla estará en modo de mapa de bits (por ejemplo, GRAPHICS 8+16). Si se invoca el modo de mapa de bits en pantalla completa, Atari BASIC volverá a cambiar con gracia al modo de texto cuando finalice la ejecución del programa, evitando dejar al usuario con una pantalla que no responde de la que debe escapar escribiendo un comando ciego o reiniciando la computadora.

Las coordenadas del mapa de bits están en el rango de 0 a la fila/columna máxima menos uno, por lo tanto, en el Modo 6 (160x192), las coordenadas máximas para un píxel pueden ser 159 y 191. Si Atari BASIC intenta trazar más allá de las coordenadas permitidas para el modo en que se produce un error de tiempo de ejecución.

Técnicas avanzadas

Etiquetas de línea

Atari BASIC permite el uso de variables y expresiones numéricas para proporcionar números de línea a los comandos GOTO y GOSUB. Por ejemplo, una subrutina que borra la pantalla se puede escribir como GOSUB CLEARSCREEN, que es más fácil de entender que GOSUB 10000.

Cuerdas como una forma de manipular la memoria

Las direcciones base de una cadena se almacenan en una tabla de variables. Las direcciones de cadena se pueden redirigir para que apunten a áreas arbitrarias de RAM. Esto permite que las rutinas de cambio rápido de memoria subyacentes a la asignación de cadenas y subcadenas se puedan aplicar desde BASIC a la memoria utilizada para la pantalla o los gráficos del reproductor/misil. Esto es particularmente útil para lograr un movimiento vertical rápido de imágenes de jugadores/misiles directamente desde Atari BASIC.

Acceso aleatorio a través de DATA/RESTORE

Las variables y expresiones numéricas se pueden usar como parámetro para la declaración RESTORE, lo que permite acceder aleatoriamente a las declaraciones DATA a través de código como RESTAURAR BASE DE HABITACIÓN+NÚMERO DE HABITACIÓN:LEER DESCRIPCIÓN$, TESORO$, SALIDAS. Esto también se puede usar para emular matrices de cadenas estáticas: RESTAURAR STRBASE+ÍNDICE:LEER A$ :IMPRIMIR A$.

Manejo de errores con TRAP

La declaración TRAP salta a un número de línea cuando ocurre un error, y esto reduce la necesidad de una verificación manual de errores. Por ejemplo, al dibujar gráficos en la pantalla, no es necesario verificar si las líneas van más allá de los límites de la pantalla del modo de gráficos actual. Este estado de error se puede atrapar y el error se puede manejar si es necesario.

Incluye

El comando ENTER lee el código fuente de un dispositivo y lo fusiona con el programa actual, como si el usuario lo hubiera escrito. Esto permite que los programas se guarden en secciones a través de LIST , leyéndolos usando ENTER para fusionar o reemplazar el código existente. Mediante el uso de bloques de números de línea que no se superponen, los programadores pueden crear bibliotecas de subrutinas y fusionarlas en nuevos programas según sea necesario.

Código auto modificable

El editor se puede configurar para leer repetidamente la entrada de la pantalla hasta que se alcance un EOF. Esto permite que un programa escriba un nuevo código de programa seguido de una instrucción CONT en la pantalla y luego, colocando el cursor de la pantalla al comienzo del nuevo código, STOP el programa en ejecución, haciendo que se lea el nuevo código y luego la ejecución continúe con la instrucción CONT.

Lenguaje de máquina integrado

Atari BASIC puede llamar a subrutinas de código de máquina almacenadas en cadenas o POKEed en la memoria. El área de 256 bytes que comienza en la dirección 1536₁₀ (600₁₆) se usa a menudo para este propósito.

El código de máquina se invoca con la función USR. El primer parámetro es la dirección de la subrutina y los siguientes valores son parámetros. Si el código se almacena en una cadena llamada ROUTINE$, se puede llamar con dos parámetros como RESPUESTA=USR (ADR(RUTINA$),VAR1,VAR2).

Los parámetros se insertan en la pila de hardware como enteros de 16 bits en el orden especificado en la llamada USR en orden de byte bajo, byte alto. Se empuja un byte final que indica el número de argumentos. El código de lenguaje de máquina debe eliminar estos valores antes de regresar a través de la instrucción RTS. Se puede devolver un valor de 16 bits a BASIC colocándolo en las direcciones 212₁₀ y 213₁₀ (D4₁₆ y D5₁₆ ).

Rendimiento

En teoría, Atari BASIC debería ejecutarse más rápido que los BASIC contemporáneos basados en el patrón MS. Debido a que el código fuente está completamente tokenizado cuando se ingresa, todos los pasos de tokenización y análisis ya están completos. Incluso las operaciones matemáticas complejas están listas para ejecutarse, con cualquier constante numérica ya convertida al formato interno de 40 bits, y los valores de las variables se buscan por dirección en lugar de tener que buscarlos. A pesar de estas ventajas teóricas, en la práctica, Atari BASIC es más lento que la mayoría de los otros BASIC de computadoras domésticas, a menudo por una gran cantidad.

En dos puntos de referencia ampliamente utilizados de la época, el tamiz de Eratóstenes de la revista Byte y la prueba de referencia Creative Computing escrita por David H. Ahl, Atari terminó casi al final de la lista. en términos de rendimiento, y era mucho más lento que el Apple II contemporáneo o el Commodore PET, a pesar de tener la misma CPU pero ejecutándolo aproximadamente al doble de velocidad que cualquiera. Terminó detrás de máquinas relativamente lentas como la Sinclair ZX81 e incluso algunas calculadoras programables.

La mayor parte de la lentitud del idioma se debe a tres problemas.

La primera es que las rutinas matemáticas de coma flotante están mal optimizadas. En el punto de referencia de Ahl, una operación de un solo exponente fue responsable de gran parte de la mala actuación de la máquina. La conversión entre enteros de punto flotante y de 16 bits también es particularmente lenta. Internamente, estos números enteros se usan para números de línea e indexación de matrices, junto con algunas otras tareas, pero los números en el programa tokenizado se almacenan en formato decimal codificado en binario (BCD). Siempre que se encuentre uno de estos, como el número de línea en GOTO 100 , el valor BCD se convierte en un número entero, lo que puede tardar hasta 3500 microsegundos.

Otra cuestión es cómo Atari BASIC implementa las sucursales. Para realizar una bifurcación en GOTO o GOSUB, el intérprete busca en todo el programa el número de línea coincidente. Por el contrario, las versiones contemporáneas de los BASIC derivados de MS buscarían hacia adelante desde la línea actual si el número de línea del objetivo de la sucursal fuera mayor, lo que mejoraría el rendimiento de la sucursal unas dos veces en promedio.

Un problema relacionado y más serio es la implementación de bucles FOR...NEXT. Cuando se ejecuta una instrucción FOR, Atari BASIC registra su número de línea. Cada vez que se alcanza el NEXT, busca en el programa esa línea, a pesar de estar en el mismo lugar que la última vez. En cambio, todos los demás BASIC registran la ubicación de memoria de la instrucción FOR y pueden regresar inmediatamente a ella sin tener que buscar.

La razón de este bajo rendimiento se ilustra mejor con una cita de uno de sus autores principales, Bill Wilkinson; en 1982 afirmó:

Personalmente, nunca he estado seguro de que es necesario que un lenguaje interpretado (por ejemplo, BASIC) sea rápido. Autores... han afirmado que Atari BASIC es el lenguaje más lento jamás creado. Mi primer impulso fue decir, "¿A quién le importa?"

Se puede contrastar esta filosofía con la del Apple BASIC de Steve Wozniak para el Apple I original, que fue diseñado específicamente para tener el rendimiento necesario para escribir juegos:

Después de diseñar juegos de arcade de hardware, sabía que ser capaz de programarlos en BASIC iba a cambiar el mundo.

Varios BASIC de terceros surgieron en la plataforma que abordaron algunos o todos estos problemas. Esto incluyó el BASIC XL de Wilkinson, que redujo el tiempo para el punto de referencia Byte de 194 a 58 segundos, más del triple de rápido. En el punto de referencia de Ahl, Atari BASIC requirió 405 segundos, mientras que exactamente el mismo código en Turbo-BASIC XL tomó 41,6 segundos, una mejora de orden de magnitud.

Diferencias con Microsoft BASIC

• Se comprueba sintaxis y los errores resaltados inmediatamente en la entrada de línea.
• Los nombres variables pueden ser de longitud arbitraria, y todos los caracteres son significativos.
• Las siguientes palabras clave no están en Atari BASIC: INKEY$, CLS,DEF FN, SPC, TAB, ELSE.
• Todos los arrays deben ser dimensionados antes de usar mientras que Microsoft BASIC predetermina un array a 10 elementos si no dimensionado.
• Las variables de cuerda se tratan como arrays de caracteres y deben ser dimensionadas antes del uso. MS BASIC almacena cadenas en el montón y a veces pausas para la recolección de basura.
• Funciones LEFT$, MID$, y RIGHT$ son reemplazados por indexación de cadenas.
• No hay un operador para la concatenación de cadenas.
• No hay arrays de cuerdas.
• No hay soporte para variables enteros.
• No hay operadores de bitwise.
• INPUT no permite un aviso.
• PRINT puede ser abreviado ? como en Microsoft BASIC, pero Atari BASIC no lo tokeniza PRINT. Sigue siendo una cuestión.
• El objetivo GOTO y GOSUB puede ser una variable o expresión.
• RESTORE puede tomar una constante numérica, variable o expresión como parámetro, causando el siguiente READ para comenzar desde el número de línea especificado
• FOR..NEXT bucles en Atari BASIC debe tener un nombre variable referenciado por el NEXT declaración mientras que Microsoft BASIC no lo requiere.
• No se permiten múltiples variables con NEXT declaraciones como están en Microsoft BASIC (por ejemplo, NEXT X,Y).
• LIST usa un coma para separar un rango en lugar de un signo menos.

Palabras clave