Commodore BASIC , también conocido como PET BASIC o CBM-BASIC , es el dialecto del lenguaje de programación BASIC utilizado en la línea de computadoras domésticas de 8 bits de Commodore International , desde el PET (1977) hasta el Commodore 128 (1985).
El núcleo está basado en el BASIC 6502 de Microsoft y, como tal, comparte muchas características con otros BASIC 6502 de la época, como el BASIC de Applesoft . Commodore licenció BASIC a Microsoft en 1977 con la idea de "pagar una vez, sin regalías " después de que Jack Tramiel rechazara la oferta de Bill Gates de una tarifa de 3 dólares por unidad, afirmando: "Ya estoy casado" y no pagaría más de 25.000 dólares por una licencia perpetua. [1]
La versión original de PET era muy similar a la implementación original de Microsoft con pocas modificaciones. BASIC 2.0 en el C64 también era similar, y también se vio en los C128 (en modo C64) y otros modelos. Los PET posteriores incluyeron BASIC 4.0, similar al original pero agregando una serie de comandos para trabajar con disquetes .
BASIC 3.5 fue el primero en realmente desviarse, añadiendo una serie de comandos para gráficos y soporte de sonido en el C16 y Plus/4 . BASIC 7.0 se incluyó con el Commodore 128 e incluía comandos de programación estructurada del BASIC 3.5 del Plus/4, así como palabras clave diseñadas específicamente para aprovechar las nuevas capacidades de la máquina. Se añadieron un editor de sprites y un monitor de lenguaje de máquina . El último, BASIC 10.0, fue parte del inédito Commodore 65 .
Commodore tomó el código fuente del BASIC de tarifa plana y lo desarrolló internamente para todos sus otros ordenadores domésticos de 8 bits. No fue hasta el Commodore 128 (con V7.0) que apareció un aviso de copyright de Microsoft. Sin embargo, Microsoft había incorporado un easter egg en la versión 2 o "actualización" de Commodore Basic que demostraba su procedencia: al escribir el comando WAIT 6502, 1
aparecía Microsoft!
en la pantalla. (El easter egg estaba bien ofuscado: el mensaje no aparecía en ningún desmontaje del intérprete.) [2]
El popular Commodore 64 venía con BASIC v2.0 en ROM, a pesar de que el ordenador se lanzó después de la serie PET/CBM que tenía la versión 4.0, ya que el 64 estaba pensado para ser un ordenador doméstico, mientras que la serie PET/CBM estaba destinada a un uso comercial y educativo, donde se suponía que su lenguaje de programación incorporado se utilizaría más intensamente. Esto permitió ahorrar costes de fabricación, ya que la V2 encajaba en ROM más pequeñas.
Una característica conveniente del intérprete de BASIC residente en ROM de Commodore y del KERNAL era el editor de pantalla completa . [3] [4] Aunque los teclados de Commodore solo tienen dos teclas de cursor que invierten la dirección cuando se mantiene presionada la tecla Shift, el editor de pantalla permite a los usuarios ingresar comandos directos o ingresar y editar líneas de programa desde cualquier lugar de la pantalla. Si una línea tenía como prefijo un número de línea, se tokenizaba y almacenaba en la memoria del programa. Las líneas que no comenzaban con un número se ejecutaban presionando la tecla siempre que el cursor estuviera en la línea. Esto marcó una mejora significativa en las interfaces de entrada de programas en comparación con otros BASIC de computadora hogareña comunes en ese momento, que generalmente usaban editores de línea , invocados por un comando separado , o un "cursor de copia" que truncaba la línea en la posición del cursor.RETURNEDIT
También tenía la capacidad de guardar archivos con nombre en cualquier dispositivo, incluido el casete , un dispositivo de almacenamiento popular en los días del PET, y que se mantuvo en uso durante la vida útil de los Commodore de 8 bits como una forma económica de almacenamiento masivo. La mayoría de los sistemas solo admitían nombres de archivo en disquetes , lo que dificultaba guardar varios archivos en otros dispositivos. El usuario de uno de estos otros sistemas tenía que observar el contador de la grabadora en la ubicación del archivo, pero esto era inexacto y propenso a errores. Con el PET (y BASIC 2.0), los archivos de los casetes se podían solicitar por nombre. El dispositivo buscaría el nombre del archivo leyendo los datos secuencialmente, ignorando cualquier nombre de archivo que no coincidiera. El sistema de archivos también estaba respaldado por una poderosa estructura de grabación que se podía cargar o guardar en archivos. Los datos de los casetes de Commodore se grababan digitalmente, en lugar de los métodos analógicos menos costosos (y menos confiables) utilizados por otros fabricantes. Por lo tanto, se requería el Datasette especializado en lugar de una grabadora de cinta estándar. Había adaptadores disponibles que utilizaban un convertidor analógico a digital para permitir el uso de una grabadora estándar, pero costaban sólo un poco menos que el Datasette.
El comando LOAD puede utilizarse con el parámetro opcional ,1 , que cargará un programa en la dirección de memoria contenida en los dos primeros bytes del archivo (estos bytes se descartan y no se conservan en la memoria). Si no se utiliza el parámetro ,1 , el programa se cargará en el inicio del área de programa BASIC, que difiere ampliamente entre máquinas. Algunas variantes de Commodore BASIC suministraban comandos que funcionaban como sus contrapartes en Applesoft BASIC , cargando o guardando mapas de bits desde ubicaciones de memoria específicas.BLOAD
BSAVE
El PET no admite programas reubicables y el comando LOAD siempre cargará en los dos primeros bytes contenidos en el archivo de programa. Esto creó un problema al intentar cargar programas BASIC guardados en otras máquinas Commodore, ya que se cargarían en una dirección más alta que la que el BASIC del PET esperaba que estuviera el programa. Había soluciones alternativas para "mover" los programas a la ubicación adecuada. Si un programa se guardaba en una máquina CBM-II , la única forma de cargarlo en un PET era modificando los dos primeros bytes con un editor de sectores de disco, ya que la serie CBM-II tenía su área de programa BASIC en $0, lo que haría que un PET intentara cargar en la página cero y se bloqueara.
Las palabras clave de Commodore BASIC se podían abreviar ingresando primero una pulsación de tecla sin mayúsculas y luego una pulsación de tecla con mayúsculas de la siguiente letra. Esto activaba el bit alto , lo que hacía que el intérprete dejara de leer y analizara la instrucción de acuerdo con una tabla de búsqueda. Esto significaba que la instrucción hasta donde se activaba el bit alto se aceptaba como un sustituto de escribir el comando completo. Sin embargo, dado que todas las palabras clave de BASIC se almacenaban en la memoria como tokens de un solo byte, esto era una conveniencia para la entrada de instrucciones en lugar de una optimización.
En el conjunto de caracteres predeterminado, que solo admite mayúsculas, los caracteres con mayúsculas aparecen como un símbolo gráfico; por ejemplo, el comando, GOTO
, se puede abreviar G{Shift-O}
(lo que se asemeja a lo que se ve en la pantalla). La mayoría de estos comandos tenían dos letras, pero en algunos casos eran más largos. En casos como este, había una ambigüedad, por lo que se necesitaban más letras del comando sin mayúsculas, como ( ) que se requiere para . Algunos comandos no tenían una forma abreviada, ya sea por brevedad o por ambigüedad con otros comandos. Por ejemplo, el comando, no tenía abreviatura porque su ortografía colisionaba con la palabra clave separada, que se encontraba más cerca del comienzo de la tabla de búsqueda de palabras clave . El comando muy utilizado tenía un solo atajo, como era común en la mayoría de los dialectos de Microsoft BASIC. Abreviar comandos con letras con mayúsculas es exclusivo de Commodore BASIC.GΓ
GO{Shift-S}
GO♥
GOSUB
INPUT
INPUT#
PRINT
?
Este método de tokenización tenía un problema técnico: si se incluía una REM
(declaración BASIC para agregar un comentario al código) seguida de un {Shift-L}
, al intentar ver la lista del programa, el intérprete BASIC abortaba inmediatamente la lista, mostraba un ?SYNTAX ERROR
y volvía al READY.
indicador. Este problema técnico fue utilizado con cierto efecto por los programadores que querían intentar proteger su trabajo, aunque era bastante fácil de evitar.
Al abreviar las palabras clave, era posible incluir más código en una sola línea de programa (que podía ocupar dos líneas de pantalla en pantallas de 40 columnas, es decir, C64 o PET, o cuatro líneas en la pantalla de 22 columnas del VIC-20). Esto permitía un ligero ahorro en la sobrecarga para almacenar líneas de programa adicionales que de otro modo serían necesarias, pero nada más. Todos los comandos BASIC se tokenizaban y ocupaban 1 byte (o dos, en el caso de varios comandos de BASIC 7 o BASIC 10) en la memoria sin importar de qué manera se ingresaran. Esas líneas tan largas eran una molestia para editar. El LIST
comando mostraba la palabra clave del comando completa, extendiendo la línea de programa más allá de las 2 o 4 líneas de pantalla que se podían ingresar en la memoria del programa.
Al igual que el intérprete BASIC original de Microsoft, Commodore BASIC es más lento que el código máquina nativo . Los resultados de las pruebas han demostrado que copiar 16 kilobytes de ROM a RAM lleva menos de un segundo en código máquina, en comparación con más de un minuto en BASIC. [ cita requerida ] Para ejecutar más rápido que el intérprete, los programadores comenzaron a usar varias técnicas para acelerar la ejecución. Una era almacenar valores de punto flotante de uso frecuente en variables en lugar de usar valores literales, ya que interpretar un nombre de variable era más rápido que interpretar un número literal. Dado que el punto flotante es el tipo predeterminado para todos los comandos, es más rápido usar números de punto flotante como argumentos, en lugar de números enteros. Cuando la velocidad era importante, algunos programadores convertían secciones de programas BASIC al lenguaje ensamblador 6502 o 6510 que se cargaba por separado desde un archivo o se introducía en la memoria desde declaraciones DATA al final del programa BASIC, y se ejecutaba desde BASIC usando el comando, ya sea desde el modo directo o desde el programa mismo . Cuando la velocidad de ejecución del lenguaje de máquina era demasiado grande, como para un juego o cuando se esperaba una entrada del usuario, los programadores podían sondear leyendo ubicaciones de memoria seleccionadas (como [5] para el 64, o [6] para el 128, que indican el tamaño de la cola del teclado) para retrasar o detener la ejecución.SYS
$C6
$D0
Una característica única de Commodore BASIC es el uso de códigos de control para realizar tareas como limpiar la pantalla o posicionar el cursor dentro de un programa; estos pueden invocarse ya sea emitiendo un comando donde X corresponde al código de control que se emitirá (por ejemplo, es el código de control para limpiar la pantalla) o presionando la tecla en cuestión entre comillas, por lo tanto, al presionar + después de una comilla hará que BASIC muestre la representación visual del código de control (en este caso, un corazón invertido) que luego se activa en la ejecución del programa (imprimir directamente los códigos de control usa menos memoria y se ejecuta más rápido que invocar una función CHR$ ). Esto es en comparación con otras implementaciones de BASIC que normalmente tienen comandos dedicados para limpiar la pantalla o mover el cursor.PRINT CHR$(X)
PRINT CHR$(147)
⇧ ShiftCLR HOME
BASIC 3.5 y versiones superiores tienen comandos adecuados para limpiar la pantalla y mover el cursor.
Las líneas de programa en Commodore BASIC no requieren espacios en ninguna parte (pero el comando LIST siempre mostrará uno entre el número de línea y la declaración), por ejemplo, y era común escribir programas sin espacios. Esta característica se agregó para conservar la memoria ya que el tokenizador nunca elimina ningún espacio insertado entre palabras clave: la presencia de espacios da como resultado bytes adicionales en el programa tokenizado que simplemente se omiten durante la ejecución. Los espacios entre el número de línea y la declaración del programa son eliminados por el tokenizador.100 IFA=5THENPRINT"YES":GOTO160
0x20
Las líneas de programa pueden tener 80 caracteres en total en la mayoría de las máquinas, pero las máquinas con texto de 40 columnas harían que la línea se ajustara a la siguiente línea en la pantalla, y en el VIC-20, que tenía una pantalla de 22 columnas, las líneas de programa podían ocupar hasta cuatro. BASIC 7.0 en el Commodore 128 aumentó el límite de una línea de programa a 160 caracteres (cuatro líneas de 40 columnas o dos líneas de 80 columnas). Al usar abreviaturas como ?
en lugar de PRINT
, es posible colocar incluso más en una línea. BASIC 7.0 muestra una?CADENA DEMASIADO LARGAError si el usuario ingresa una línea de programa con más de 160 caracteres de longitud. Las versiones anteriores no producían un error y simplemente mostraban el mensaje READY dos líneas más abajo si se superaba la longitud de línea. El número de línea se contabiliza en la cantidad de caracteres de la línea de programa, por lo que un número de línea de cinco dígitos dará como resultado cuatro caracteres menos permitidos que un número de un dígito.
El orden de ejecución de las líneas de Commodore BASIC no estaba determinado por la numeración de las líneas, sino que seguía el orden en el que las líneas estaban enlazadas en la memoria. [7] Las líneas de programa se almacenaban en la memoria como una lista enlazada simple con un puntero (que contenía la dirección del comienzo de la siguiente línea de programa), un número de línea y luego el código tokenizado para la línea. Mientras se introducía un programa, BASIC reordenaba constantemente las líneas de programa en la memoria de modo que los números de línea y los punteros estuvieran todos en orden ascendente. Sin embargo, después de introducir un programa, alterar manualmente los números de línea y los punteros con los comandos POKE podía permitir una ejecución fuera de orden o incluso dar a cada línea el mismo número de línea. En los primeros días, cuando BASIC se utilizaba comercialmente, esta era una técnica de protección de software para desalentar la modificación casual del programa.
Los números de línea pueden variar de 0 a 65520 y se necesitan cinco bytes para almacenarlos, independientemente de cuántos dígitos tenga el número de línea, aunque la ejecución es más rápida cuanto menos dígitos tenga. Poner varias instrucciones en una línea utilizará menos memoria y se ejecutará más rápido.
Las instrucciones GOTO y GOSUB buscarán hacia abajo desde la línea actual para encontrar un número de línea si se realiza un salto hacia adelante; en caso de un salto hacia atrás, volverán al inicio del programa para comenzar la búsqueda. Esto ralentizará los programas más grandes, por lo que es preferible colocar las subrutinas de uso común cerca del inicio de un programa.
Los nombres de variables solo son significativos para 2 caracteres; por lo tanto, los nombres de variable VARIABLE1
, VARIABLE2
y VA
todos se refieren a la misma variable.
Commodore BASIC también admite operadores bit a bit: AND, OR y XOR . Aunque esta característica era parte del código central de Microsoft 6502 BASIC, generalmente se omitía en otras implementaciones como Applesoft BASIC .
El formato de número nativo de Commodore BASIC, al igual que el de su padre MS BASIC , era de punto flotante . La mayoría de las implementaciones contemporáneas de BASIC usaban un byte para la característica ( exponente ) y tres bytes para la mantisa . La precisión de un número de punto flotante usando una mantisa de tres bytes es de solo unos 6,5 dígitos decimales, y el error de redondeo es común. Las implementaciones 6502 de Microsoft BASIC utilizaban aritmética de punto flotante de 40 bits, lo que significa que las variables necesitaban cinco bytes para almacenarse (mantisa de cuatro bytes y un byte para el exponente) a diferencia del punto flotante de 32 bits que se encuentra en BASIC-80.
Mientras que las implementaciones 8080/Z80 de Microsoft BASIC admitían variables de precisión doble y entera, las implementaciones 6502 sólo eran de punto flotante.
Aunque Commodore BASIC admite variables enteras con signo (indicadas con un signo de porcentaje) en el rango de -32768 a 32767, en la práctica sólo se utilizan para variables de matriz y cumplen la función de conservar memoria al limitar los elementos de la matriz a dos bytes cada uno (una matriz de 2000 elementos ocupará 10 000 bytes si se declara como una matriz de punto flotante, pero sólo 4000 si se declara como una matriz de enteros). Denotar cualquier variable como un entero simplemente hace que BASIC la convierta de nuevo a punto flotante, lo que ralentiza la ejecución del programa y desperdicia memoria ya que cada signo de porcentaje ocupa un byte adicional para almacenarse (ya que esto también se aplica a las matrices de enteros, el programador debe evitar su uso a menos que se utilicen matrices muy grandes que excederían la memoria disponible si se almacenaran como punto flotante). Además, no es posible hacer POKE o PEEK en ubicaciones de memoria superiores a 32767 con una dirección definida como un entero con signo.
Se puede utilizar un punto (.) en lugar del número 0 (es decir, en lugar de o en lugar de ), esto se ejecutará un poco más rápido.10 A=.
10 A=0
10 FOR A=. TO 100
10 FOR A=0 to 100
La instrucción SYS , utilizada para iniciar programas en lenguaje de máquina, fue agregada por Commodore y no estaba en el código original de Microsoft BASIC, que solo incluía la función USR para invocar rutinas en lenguaje de máquina. Carga automáticamente los registros de la CPU con los valores en (C64, varía en otras máquinas); esto se puede utilizar para pasar datos a rutinas en lenguaje de máquina o como un medio para llamar a funciones del núcleo desde BASIC (por ejemplo, limpia la pantalla).$30C-$30F
POKE 780,147:SYS 65490
Dado que las máquinas Commodore de 8 bits que no sean la C128 no pueden arrancar automáticamente el software de disco, la técnica habitual es incluir un stub de BASIC como para comenzar la ejecución del programa. Es posible iniciar automáticamente el software después de la carga y no requerir que el usuario escriba una declaración RUN , esto se hace con un fragmento de código que engancha el vector "listo" de BASIC en .10 SYS 2048
$0302
Al igual que con la mayoría de las otras versiones de Microsoft BASIC , si una matriz no se declara con una instrucción DIM , se establece automáticamente en diez elementos (en la práctica, 11, ya que los elementos de la matriz se cuentan desde 0). Las matrices más grandes deben declararse o BASIC mostrará un error cuando se ejecute el programa y una matriz no se puede redimensionar en un programa a menos que se borren todas las variables mediante una instrucción CLR. Las matrices numéricas se rellenan automáticamente con ceros cuando se crean; puede haber un retraso momentáneo en la ejecución del programa si se dimensiona una matriz grande.
Las variables de cadena se representan etiquetando el nombre de la variable con un signo de dólar. Por lo tanto, las variables AA$
, AA
y AA%
se entenderían como distintas. Las variables de matriz también se consideran distintas de las variables simples, por lo que A y A(1) no hacen referencia a la misma variable. El tamaño de una matriz de cadenas simplemente se refiere a cuántas cadenas se almacenan en la matriz, no al tamaño de cada elemento, que se asigna dinámicamente. A diferencia de otras implementaciones de Microsoft BASIC, Commodore BASIC no requiere que se reserve espacio para cadenas al comienzo de un programa.
A diferencia de otras máquinas de 8 bits, como la Apple II, todas las máquinas de Commodore tienen un reloj incorporado que se inicializa a 0 al encenderse y se actualiza con cada tic del temporizador PIA/VIA/TED/CIA, es decir, 60 veces por segundo. Se le asignan dos variables de sistema en BASIC, TI y TI$ , que contienen la hora actual. TI es de sólo lectura y no se puede modificar; al hacerlo, se generará un mensaje de error de sintaxis. TI$ se puede utilizar para establecer la hora mediante una cadena de seis números (se produce un error al utilizar una cadena que no sea de seis números). El reloj no es un método muy fiable para medir el tiempo, ya que se detiene siempre que se desactivan las interrupciones (algo que hacen algunas rutinas del núcleo) y el acceso al puerto IEC (o al puerto IEEE en el PET) ralentizará la actualización del reloj unos pocos tics.
La función RND en Commodore BASIC puede usar el reloj para generar números aleatorios; esto se logra mediante , sin embargo, es de uso relativamente limitado ya que solo se devuelven números entre 0 y 255. De lo contrario, RND funciona de la misma manera que otras implementaciones de Microsoft BASIC en el sentido de que se usa una secuencia pseudoaleatoria a través de un valor de semilla fijo de 5 bytes almacenado al encender el sistema en ubicaciones de memoria en el C64 (la ubicación difiere en otras máquinas). RND con cualquier número mayor que 0 generará un número aleatorio amalgamado a partir del valor incluido con la función RND y el valor de semilla, que se actualiza en 1 cada vez que se ejecuta una función RND. RND con un número negativo va a un punto en la secuencia del valor de semilla actual especificado por el número.RND(0)
$8B-$8F
Dado que la generación de números aleatorios reales es imposible con la declaración RND , es más típico en el C64 y el C128 utilizar el canal de ruido blanco del chip SID para números aleatorios.
BASIC 2.0 era conocido por su lentitud en la recolección de basura de cadenas. La recolección de basura se invoca automáticamente cada vez que se ejecuta una función FRE y, si hay muchas variables de cadena y matrices que se han manipulado a lo largo de un programa, su limpieza puede llevar más de una hora en las peores condiciones. Tampoco es posible abortar la recolección de basura, ya que BASIC no escanea la tecla RUN/STOP mientras realiza esta rutina. BASIC 4.0 introdujo un sistema de recolección de basura mejorado con punteros hacia atrás y todas las implementaciones posteriores de Commodore BASIC también lo tienen.
La función FRE en BASIC 2.0 adolecía de otro defecto técnico, ya que no podía manejar números con signo superiores a 32768, por lo que si se invocaba la función en un C64 (memoria BASIC de 38k), se mostraría una cantidad negativa de memoria BASIC libre (sumando 65535 al número informado se obtendría la cantidad correcta de memoria libre). El PET y el VIC-20 nunca tuvieron más de 32k de memoria total disponible para BASIC, por lo que esta limitación no se hizo evidente hasta que se desarrolló el C64. La función FRE en BASIC 3.5 y 7.0 corrigió este problema y FRE en BASIC 7.0 también se "dividió" en dos funciones, una para mostrar la memoria de texto de programa BASIC libre y la otra para mostrar la memoria variable libre.
Se lanzaron muchas extensiones de BASIC para Commodore 64, debido a las capacidades relativamente limitadas de su BASIC 2.0 nativo. Una de las extensiones más populares fue DOS Wedge , que se incluyó en el disco de prueba/demostración de Commodore 1541. Esta extensión de 1 KB a BASIC agregó una serie de comandos relacionados con el disco, incluida la capacidad de leer un directorio de disco sin destruir el programa en la memoria. Sus características se incorporaron posteriormente en varias extensiones de terceros, como el popular cartucho Epyx FastLoad . Otras extensiones de BASIC agregaron palabras clave adicionales para facilitar la codificación de sprites, sonido y gráficos de alta resolución como Simons' BASIC (1983) y Vision BASIC (2022).
Aunque la falta de funciones de sonido o gráficos de BASIC 2.0 fue frustrante para muchos usuarios, algunos críticos [¿ quiénes? ] argumentaron que en última instancia era beneficioso ya que obligaba al usuario a aprender lenguaje de máquina.
Las limitaciones de BASIC 2.0 en el C64 llevaron al uso del lenguaje de máquina ROM incorporado de BASIC. Para cargar un archivo en una ubicación de memoria designada, se leían el nombre del archivo, la unidad y el número de dispositivo mediante una llamada: ; [8] la ubicación se especificaba en los registros X e Y: ; [9] y se llamaba a la rutina de carga: . [10]SYS57812"filename",8
POKE780,0:POKE781,0:POKE782,192
SYS65493
Loadstar , un repositorio de discos para el C64 , era un lugar para programadores aficionados que compartían colecciones de protocomandos para BASIC, llamados con el SYS address + offset
comando . [ cita requerida ]
Desde un punto de vista de programación moderna, las versiones anteriores de Commodore BASIC presentaban una serie de trampas de programación malas para el programador. Como la mayoría de estos problemas se derivaban de Microsoft BASIC , prácticamente todos los BASIC de computadora hogareña de la época sufrían de deficiencias similares. [11] Cada línea de un programa Microsoft BASIC tenía asignado un número de línea por el programador. Era una práctica común incrementar los números en algún valor (5, 10 o 100) para facilitar la inserción de líneas durante la edición o depuración del programa, pero una mala planificación significaba que insertar secciones grandes en un programa a menudo requería reestructurar todo el código. Una técnica común era comenzar un programa en un número de línea bajo con una tabla de saltos ON...GOSUB , con el cuerpo del programa estructurado en secciones que comenzaban en un número de línea designado como 1000, 2000, etc. Si era necesario agregar una sección grande, simplemente se le podía asignar el siguiente número de línea principal disponible e insertarla en la tabla de saltos.
Además, todas las variables se tratan como variables globales. Los bucles claramente definidos más allá de la construcción FOR...NEXT son difíciles de crear, lo que a menudo hace que el programador dependa del comando GOTO (esto se corrigió más tarde en BASIC 3.5 con la incorporación de los comandos DO, LOOP, WHILE, UNTIL y EXIT ). A menudo era necesario crear variables de bandera para realizar ciertas tareas.
Las versiones posteriores de BASIC en Commodore y otras plataformas incluían un comando DELETE y RENUMBER , así como un comando de numeración de línea AUTO que seleccionaba e insertaba automáticamente números de línea según un incremento seleccionado. Los BASIC anteriores de Commodore también carecen de comandos de depuración, lo que significa que los errores y las variables no utilizadas son difíciles de detectar. Las estructuras IF...THEN...ELSE , una parte estándar de los BASIC de Microsoft Z80, se agregaron a BASIC 3.5 después de no estar disponibles en versiones anteriores de Commodore BASIC.
Al igual que otros ordenadores domésticos , las máquinas Commodore arrancaban directamente en el intérprete BASIC. Los comandos de programación y archivos de BASIC se podían introducir en modo directo para cargar y ejecutar software. Si se detenía la ejecución del programa utilizando la tecla RUN/STOP, los valores de las variables se conservaban en la RAM y se podían IMPRIMIR para su depuración. El 128 incluso dedicó su segundo banco de 64k al almacenamiento de variables, lo que permitía que los valores persistieran hasta que se emitiera un comando NEW
o . Esto, junto con el editor de pantalla avanzado incluido con Commodore BASIC, dio al entorno de programación una sensación similar a REPL ; los programadores podían insertar y editar líneas de programa en cualquier ubicación de la pantalla, construyendo el programa de forma interactiva. [12] Esto contrasta con los sistemas operativos orientados a los negocios de la época, como CP/M o MS-DOS , que normalmente arrancaban en una interfaz de línea de comandos . Si se requería un lenguaje de programación en estas plataformas, tenía que cargarse por separado.RUN
DLOAD
Aunque algunas versiones de Commodore BASIC incluían comandos específicos para discos DSAVE
, la versión incorporada en Commodore 64 carecía de ellos, lo que obligaba al usuario a especificar el número de dispositivo de la unidad de disco (normalmente 8 o 9) en el LOAD
comando estándar, que de otro modo era el de cinta por defecto. Otra omisión del BASIC 2.0 de Commodore 64 era un DIRECTORY
comando para mostrar el contenido de un disco sin borrar la memoria principal. En el 64, la visualización de archivos en un disco se implementaba como la carga de un "programa" que, cuando se enumeraba, mostraba el directorio como un pseudoprograma BASIC, con el tamaño de bloque del archivo como número de línea. Esto tenía el efecto de sobrescribir el programa cargado en ese momento. Los complementos como DOS Wedge solucionaron este problema mostrando el listado de directorios directamente en la memoria de la pantalla.
Una lista de versiones de CBM BASIC en orden cronológico, con características agregadas sucesivamente:
RESTORE [line number]