Commodore DOS

Commodore DOS, también conocido como CBM DOS, es el sistema operativo de disco utilizado con computadoras de 8 bits de Commodore. A diferencia de la mayoría de los otros DOS, que se cargan desde el disco en la propia RAM de la computadora y se ejecutan allí, CBM DOS se ejecuta internamente en la unidad: el DOS reside en la ROM dentro de la unidad, y es ejecutado allí por uno o más CPU de la familia MOS 6502.

Versiones CBM DOS 

Se sabe que existen al menos siete versiones numeradas de Commodore DOS; la siguiente lista proporciona los números de versión y las unidades de disco relacionadas. A menos que se indique lo contrario, las unidades tienen un formato de 5¼ pulgadas. El código «lp» designa unidades de «perfil bajo» («low profile»). Las unidades cuyo número de modelo comienza con 15 se conectan a través de los protocolos exclusivos bus IEEE-488 (bus IEC) serie (TALK/LISTEN) de Commodore; todos los demás usan el paralelo IEEE-488.

 1.0: se encuentra en las unidades de disquete 2040 y 3040
 2.0: se encuentra en las unidades de disquete 4040 y 3040
 2.5: se encuentra en las unidades de disquete 8050
 2.6: se encuentra en las unidades de disquete 1540, 1541 incluido el integrado en el SX-64, 1551, 2031 (+ «lp») y 4031
 2.7: se encuentra en las unidades de disquete 8050, 8250 (+ «lp») y  SFD-1001
 3.0: se encuentra en las unidades de disquete 1570, 1571 externa y 8280 (8280: 8 pulgadas), así como en los discos duros  9060 y 9090.
 3.1: se encuentra en la unidad 1571 incorporada de las computadoras C128DCR
 10.0: se encuentra en la unidad de disquete  1581 (3½ pulgadas)

La versión 2.6 fue, con mucho, la versión más utilizada y más conocida, debido a su uso en la 1541 como parte de los sistemas C64.

Nota: El firmware revisado para el 1571 que solucionó el error del archivo relativo también se identificó como V3.0. Por tanto, no es posible diferenciar las dos versiones utilizando solo el número de versión.

Descripción general

1541 tipos de archivos y directorios 

El disquete Commdore 1541 puede contener hasta 144 archivos en un espacio de nombres plano (sin subdirectorios); el directorio se almacena en la pista reservada 18, que se encuentra a mitad de camino desde el centro hasta el borde de un disco de una cara de 35 pistas. Un nombre de archivo puede tener hasta 16 bytes de longitud y es teóricamente único; Al utilizar métodos de acceso directo en la estructura de directorios, es posible cambiar el nombre de un archivo al de otro, aunque el acceso a dicho archivo puede ser difícil o imposible. Los archivos con nombres idénticos generalmente no tienen ningún propósito, excepto informar o administrar visualmente los archivos. Un truco popular, utilizado, por ejemplo, por The Final Cartridge III, era agregar archivos llamados "----------------" de tipo DEL< en el directorio, y los archivos podían reorganizarse alrededor de esas líneas para formar grupos. Muchos desarrolladores de juegos, miembros del grupo warez y piratas informáticos de la demoscene también utilizaron algunas entradas de directorio personalizadas más ingeniosas.

Los nombres de archivo pueden contener un carácter de espacio desplazado ($A0), y si la lista del directorio se ve desde BASIC, la parte del nombre del archivo más allá del carácter $A0 parecerá haber sido separado de la primera parte del nombre del archivo por una comilla, haciendo que BASIC no lo considere parte del nombre completo del archivo. Esta función se puede utilizar para crear entradas de directorio como , que luego aparecerá en la lista del directorio como, por ejemplo, . Cuando el usuario mueve el cursor al principio de la línea, escribe la palabra LOAD sobre el tamaño del archivo y presiona , BASIC interpreta eso como , lo que hace que el programa se cargue en la memoria. Cualquier cosa después de los dos puntos o la dirección secundaria no se ejecutará, ya que la computadora ignora cualquier comando después de un LOAD. Alternativamente, el usuario puede presionar  para  y , es decir, cargar y correr el programa automáticamente.

Un byte nulo incrustado en un nombre de archivo interrumpirá el listado después de cargarlo por BASIC. Si hay tres bytes nulos, eso dificulta la lista mediante BASIC. Muchos programadores de lenguaje de máquina experimentarían con bytes nulos en un intento de hacer más difícil para los programadores de BASIC acceder a su código y manipularlo.

En BASIC, se puede acceder al directorio como un programa pseudo-BASIC no ejecutable con  (o  en el caso de una unidad dual) seguido de LIST. La primera línea tiene un número de línea de 0 o 1 (indicando el número de la unidad), mostrando en video inverso el nombre e ID del disco y un código abreviado para la versión de DOS con la que fue creado (los códigos varían solo en la medida en que las versiones de DOS utilizan formatos de disco incompatibles: «2A» es utilizado por la mayoría de las versiones de DOS de 5,25 pulgadas, «3D» por el 1581 de 3,5 pulgadas). Las líneas posteriores tienen el tamaño de un archivo (en bloques de disco) como su pseudo «número de línea», seguido del nombre del archivo entre comillas y el código de tipo de tres letras. La última línea muestra el número de bloques no asignados en el disco (nuevamente como un pseudo «número de línea»), seguido de las palabras «BLOCKS FREE».

En el Commodore 64, ingresar  inundará la pantalla con basura en lugar de cargar el directorio en la BASIC RAM. Esto se debe a que la unidad asigna al directorio una dirección de carga de $0401 (1025), que es equivalente al inicio de BASIC para el Commodore PET, pero corresponde a la memoria de pantalla predeterminada en el C64 (comenzando con el segundo carácter en la primera línea de la pantalla).

Ver el directorio con un comando  sobrescribe el programa BASIC en la memoria. El DOS Wedge y varios cartuchos y extensores de terceros como Epyx Fast Load, Action Replay y The Final Cartridge III permiten ver el directorio del disco mediante comandos especiales que cargan el directorio en la memoria de la pantalla sin destruir el programa BASIC actual. Algunas versiones de Commodore BASIC incluyen un comando DIRECTORIO o CATALOG que realiza la misma función.

Se admiten los siguientes tipos de archivos:

SEQ
Un archivo secuencial es un archivo de datos que se puede leer linealmente de principio a fin. Los archivos SEQ se utilizan comúnmente para almacenar documentos o archivos de texto creados por un procesador de texto u otro editor similar. Un archivo secuencial es análogo a un archivo plano en Linux o UNIX, ya que no tiene una estructura interna especializada. No es posible colocar una ubicación arbitraria en un archivo secuencial, ya que no hay un análogo de la llamada al núcleo lseek encontrada en los sistemas operativos tipo UNIX.
PRG
Los archivos PRG normalmente contienen código de programa ejecutable, aunque también se pueden usar para archivos de datos. Los primeros dos bytes del PRG son leídos por la rutina kernal «load file» y se utilizan para determinar la dirección de carga (se almacenan en un formato little endian).
REL
Un archivo relativo es una variación del tipo de archivo secuencial, en el que está presente un mecanismo de indexación denominado sectores laterales para permitir el acceso orientado a registros. Los registros pueden tener un tamaño máximo de 254 bytes y se direccionan mediante un número cardinal basado en uno, lo que permite un verdadero acceso aleatorio a cualquier parte del archivo.
USR
Un archivo especificado por el usuario tiene una estructura interna idéntica a la de un archivo secuencial. El propósito original de Commodore para este tipo de archivo era facilitar el desarrollo de DOS, ya que el contenido del archivo se podía copiar en un búfer de la unidad para que lo ejecutara el microprocesador de la unidad. Muy pocos programas han hecho uso de este tipo de archivo. Algunas aplicaciones que utilizan estructuras de disco de bajo nivel no estándar guardan datos en formato USR, que llegó a ser considerado una especie de indicación de «déjame en paz, no intentes copiar o eliminar» para el usuario. En particular, los archivos «VLIR» del GEOS se muestran como archivos USR.
DEL
Un tipo de archivo indocumentado utilizado internamente similar en estructura a un archivo secuencial. La creación de este tipo de archivo debe realizarse mediante la manipulación directa del directorio del disco.

La presencia de un asterisco (*) antepuesto al tipo de archivo en una lista de directorio (por ejemplo, *SEQ) indica que el archivo no se cerró correctamente después de la escritura. Cuando se ordena a la unidad que cierre un archivo que se ha abierto para escritura, el búfer asociado se vacía en el disco y el mapa de disponibilidad de bloques (BAM) se actualiza para reflejar con precisión qué bloques se han utilizado. Si un programa falla u otro problema (como que el usuario quita el disco mientras un archivo está abierto) da como resultado un «archivo huérfano», también conocido como archivo «venenoso» o «splat», los búferes no se vacían y el BAM no reflejará con precisión el uso del disco, lo que pone al disco en riesgo de corrupción. Por lo general, no se puede acceder a un archivo envenenado (pero se puede abrir en modo «modificar»), y un intento de usar el comando DOS scratch para eliminar el archivo puede dañar el sistema de archivos, como la reticulación. El único método práctico para eliminar uno de estos archivos es abriendo el archivo en modo «modificar» (y reparándolo), o validando el disco (vea el comando de DOS validate a continuación), este último reconstruye la BAM y elimina las referencias a archivos venenosos del directorio. El infame save-with-replace bug podía resultar en la creación de archivos splat.

*DEL es un tipo especial escrito en la entrada del directorio de los archivos que se han eliminado. Dichos archivos no se muestran en una lista de directorios normal y sus bloques de datos y entradas de directorio serán reutilizados por archivos que se creen posteriormente. Algunos programas utilitarios permiten la «recuperación» de dichos archivos si sus bloques de datos y entradas de directorio aún no han sido sobrescritos por otros archivos. Los archivos DEL se utilizan comúnmente para insertar anuncios o secciones de comentarios en una listado de directorios.

Los tipos de archivo con < después de ellos (por ejemplo, PRG<) están «bloqueados» y no se pueden eliminar; sin embargo, se pueden abrir para leer. No existe un comando Commodore DOS que pueda establecer o borrar explícitamente este estado, pero se escribieron muchas utilidades de terceros para permitir que esto se haga. Estas utilidades generalmente leen el directorio usando comandos de acceso directo, realizan las modificaciones necesarias a los datos sin procesar y luego escriben los cambios en el disco.

Acceso a archivos 

El acceso a los archivos es principalmente un problema para la computadora anfitrionna. La ROM kernal en la computadora contiene las rutinas primitivas necesarias para acceder a los archivos, y la BASIC ROM contiene una abstracción de nivel superior para el acceso a archivos utilizando la sintaxis BASIC. Los componentes que conciernen al propio DOS son el análisis del nombre de archivo y la dirección secundaria. Esta sección le dará una descripción general de los comandos BASIC necesarios en aras de la integridad.

La apertura de un archivo en una unidad de disco Commodore implica el procesamiento de una serie de parámetros que son vagamente análogos a los procedimientos de apertura de archivos en otros entornos. Dado que el DOS se está ejecutando en el controlador de la unidad, la secuencia de apertura del archivo debe pasar suficiente información a la unidad para asegurar una interpretación inequívoca. Una declaración típica en BASIC para escribir en un archivo secuencial sería la siguiente:

Los parámetros que siguen a la orden OPEN son los siguientes:

3
Este parámetro, el número de archivo, identifica lógicamente el archivo abierto dentro del sistema operativo de la computadora y es análogo a un descriptor de archivo en los sistemas operativos tipo UNIX. Nunca se envía a la unidad y, por lo tanto, el sistema operativo de la unidad no la conoce ni la utiliza. El número de archivo puede estar en el rango de 1 a 254 inclusive, lo asigna el programador y debe ser único si se abre más de un archivo simultáneamente. Una vez que se ha abierto el archivo, todos los procedimientos de entrada y salida del programa utilizan el número de archivo. En los programas de lenguaje ensamblador, este valor a menudo se conoce como LA (dirección lógica), la abreviatura proviene del mnemónico que se refiere a la ubicación de la memoria donde se almacena el número de archivo. Los números de archivo superiores a 127 hacen que el sistema escriba un salto de línea adicional después de cada retorno de carro (útil para el doble espacio de un documento, por ejemplo).
8
Este parámetro, el número de dispositivo, identifica un periférico específico conectado a la computadora. Los dispositivos 0 a 3 se dirigen al teclado, casete de cinta, interfaz RS-232 y pantalla de video, respectivamente, todos los cuales están controlados directamente por la ROM del núcleo. Los dispositivos números 4 y superiores direccionan los dispositivos conectados al bus de periféricos, como impresoras o unidades de disco. En el caso de una unidad de disco, el número de dispositivo se refiere al controlador de la unidad, no a los mecanismos de la unidad dentro de la unidad. Por convención, la primera unidad de la unidad de disco en un sistema tiene el número de dispositivo 8, la segunda unidad, si está presente, 9, etc., hasta un número máximo de 15 (cuando hay ocho unidades de disco conectadas). El esquema de número de dispositivo se derivó del bus IEEE-488 (o interfaz de propósito general GPIB) que se utilizó con los modelos Commodore PET/CBM. En los programas de lenguaje ensamblador, este valor a menudo se conoce como FA o PA (dirección física), nuevamente del mnemónico para la ubicación de la memoria donde se almacena el número de dispositivo.
4
Este parámetro, la  dirección secundaria , que puede variar de 0 a 15 inclusive, se refiere a un canal de comunicación específico establecido con el controlador del dispositivo y se pasa al dispositivo cuando se le ordena «hablar» o «escuchar» en el bus de periféricos. Al igual que con el número de archivo, la dirección secundaria la determina el programador y debe ser única para el dispositivo en cuestión. El rango de 0 a 14 inclusive se usa para pasar datos hacia o desde el dispositivo, mientras que 15, denominado «canal de comando», se usa para emitir comandos al controlador del dispositivo (como para cambiar el nombre de un archivo de disco), si el dispositivo es capaz de soportar dicha operación. En las unidades de disco, las direcciones secundarias 0 a 14 inclusive se asignan a búferes dentro del controlador, estableciendo así comunicación con un archivo específico en un disco específico; dado que, como se mencionó anteriormente, la unidad no conoce el número de archivo, solo puede usar la dirección secundaria para marcar la diferencia entre varios archivos que están abiertos al mismo tiempo. Por otro lado, el sistema operativo del anfitrión es independiente de la dirección secundaria; se transmite a la unidad en cada acceso al archivo, pero el anfitrión no lo utiliza de otra manera. En los programas de lenguaje ensamblador, este valor a menudo se denomina SA (dirección secundaria).

CADENA DE COMANDOS
El parámetro "0:DIRECCIONES,S, W" se conoce oficialmente en la documentación de Commodore como la «cadena de comando» y es interpretado por el controlador del dispositivo al que se accede. En el caso de una unidad de disco, la estructura de la cadena de comando formal consiste en el número de mecanismo de la unidad (0:, que no debe confundirse con el número de dispositivo), nombre de archivo (DIRECCIONES), tipo de archivo (S, secuencial en este ejemplo) y modo de acceso (W, abierto para escritura en este ejemplo). En la práctica, algunos de estos parámetros pueden omitirse. Como mínimo, solo se requiere el nombre del archivo si el archivo se va a abrir para su lectura.

El número de unidad identifica un mecanismo individual conectado al controlador de una unidad de disco doble y es análogo a un número de unidad lógica en un controlador SCSI, que es capaz de controlar múltiples mecanismos (por ejemplo, los controladores SASI OMTI, que fueron desarrollados para trabajar con discos duros ST-412/ST-506 en la década de 1980). En las unidades de disquete, el primer mecanismo es la unidad 0: y el segundo es 1:. Es una práctica bastante común omitir el número de unidad cuando se comunica con una sola unidad de disquete, ya que 0: es el valor predeterminado en dichas unidades, pero como omitir el número puede desencadenar algunos errores oscuros en el DOS, no es una práctica recomendada (dos puntos por sí solos equivalen a 0: y es suficiente para evitar esos errores). Una excepción a esta convención es con el subsistema de disco duro Lt. Kernal, en el que el número de unidad se refiere a «unidades lógicas» (unidades virtuales creadas en una sola unidad física), que hacía que una sintaxis como 4: o 10: fuera necesaria si el archivo a ser abierto no estaba en la unidad lógica cero (equivalente al mecanismo de unidad cero de accionamiento en una unidad de disquete doble).

Los archivos también se pueden cargar y guardar con los comandos LOAD y SAVE. Los especificadores de nombre de archivo también se pueden usar aquí, por ejemplo,  guarda el programa BASIC en un archivo PRG (programa) y  guarda el programa BASIC en un archivo secuencial. Si la dirección secundaria no se especifica o se especifica como 0 (por ejemplo, ), el archivo se guarda/carga desde el área de memoria BASIC (que, en el C64 , comienza por defecto en $ 0801). Si la dirección secundaria se especifica como un valor distinto de cero (por ejemplo, ), el programa se carga comenzando desde la dirección especificada por el archivo en sí (el encabezado PRG, que son los dos primeros bytes del archivo); esta forma de comando es más común cuando se cargan programas de código de máquina.

La reubicación de carga se introdujo por primera vez en el VIC-20 porque esta máquina podía iniciar el BASIC RAM en varias ubicaciones diferentes, dependiendo de la expansión de memoria que tenía instalada. La serie anterior del Commodore PET no admitía la reubicación, por lo que  y  tendría el mismo efecto: el archivo se cargaría en la misma región de memoria desde la que se guardó. La reubicación de carga ocurre en el equipo anfitrión, siendo una excepción a lo que se dijo anteriormente acerca de que la dirección secundaria se usa solo internamente en el dispositivo. Dado que el PET no puede reubicar archivos, los programas BASIC escritos en máquinas Commodore posteriores deben modificarse utilizando un editor de sector para cambiar los bytes de encabezado. También es posible utilizar el monitor de lenguaje de máquina integrado en el PET para cambiar la dirección de enlace del programa BASIC después de cargarlo.

El comando  cargará el primer programa en el disco comenzando desde la ubicación de memoria especificada por el archivo. Este es uno de los comandos de carga más populares de las plataformas, el método para iniciar la mayoría del software comercial, por ejemplo. Es de destacar el hecho de que la expansión comodín solo seleccionará el primer nombre del directorio cuando no se haya accedido antes a ningún otro archivo en ese disco; el nombre del último archivo utilizado se guarda en la memoria, y los comandos  posteriores cargarán ese archivo en lugar del primero (sin embargo,  o  siempre cargará el primer archivo en el disco).

Se accede a los directorios de disco en unidades dobles como  y . "0:$" y "1:$" no acceden al directorio, sino a los archivos reales en una unidad u otra que simplemente se llaman "$". Los directorios parciales se pueden cargar agregando dos puntos y una plantilla: por ejemplo,  cargaría un directorio parcial que muestra solo el archivos cuyo nombre comience con la letra K y que sean de tipo PRG; todos estos directorios parciales todavía contienen la línea del nombre del disco inicial y la línea final "BLOCKS FREE".

El error de guardar-y-reemplazar 

Commodore DOS también ofrece un comando «Guardar y reemplazar», que permite guardar un archivo sobre un archivo existente sin la necesidad de primero SCRATCH el archivo existente. Esto se hace anteponiendo un símbolo @ al nombre del archivo durante la operación OPEN o SAVE, por ejemplo, . Durante años se difundieron rumores, comenzando con la unidad 4040, de un error en la implementación del comando. Al principio, algunos comentaristas lo negaron. Se ofrecieron premios para probar la existencia del error. A principios de 1985, la revista Compute! aconsejaba a los lectores que evitaran usar el comando. Ese año varios autores publicaron artículos de forma independiente demostrando que el error de Guardar y Reemplazar era real e incluye métodos por los cuales podría activarse.

Los dispositivos afectados incluyeron el 1541 de una sola unidad y la 4040 de doble unidad; el 8050 y el 8250 no presentaron el problema. Algunos comentaristas sugirieron que el error podría evitarse especificando siempre explícitamente el número de unidad 0: al guardar, aunque más tarde se demostró que cualquier operación de disco sin un número de unidad era suficiente para provocar el error. El error se debió al hecho de que las implementaciones de DOS afectadas eran versiones modificadas de DOS contenida en unidades de disco dobles del Commodore PET anteriores, como la 8050. Esto creó un «disco fantasma 1:» en sistemas de un solo disco, lo que resultó en la asignación de un búfer innecesario en algunas condiciones. Dado que el comando Grabar-y-Reemplazar utilizó los cinco búferes de unidad, y debido a que el método por el cual se asignó el búfer «fantasma» no cumplía con las especificaciones, esto provocó que se escribieran datos corruptos en el disco en algunas condiciones.

En septiembre de 1986, Philip A. Slaymaker publicó un artículo describiendo con gran detalle la causa del error y proporcionando parches para las ROM de la unidad 1541; los lectores con una grabadora EPROM podían producir sus propias ROM parcheadas que podían reeemplazar a la de la unidad. Commodore se enteró de los hallazgos de Slaymaker, y aunque nunca emitieron una actualización oficial para las ROM originales de 1541, solucionaron el error en la Revisión 5 de las ROM 1571, y también en las ROM de las unidades 1541c y 1541-II. Aunque no es soportado por Commodore, se sabe que el firmware 1541-II (pero no el del 1541c) también se puede utilizar en una unidad 1541 original mediante EPROM, que solucionarán el error de esa unidad también.

Canal de comandos 

Como se señaló anteriormente, se accede al Commodore DOS a través del «canal de comandos», utilizando una sintaxis como la que se usa para acceder a los archivos. La emisión de comandos al DOS y la recuperación de mensajes de error y estado, generados en respuesta a los comandos, se logra abriendo un archivo en el dispositivo usando 15 como dirección secundaria, por ejemplo:

Para recuperar y mostrar el estado del dispositivo, se puede codificar:

En el ejemplo anterior, E contendrá el número de error (si lo hay, será cero si no existe ningún error), E$ será un texto con la descripción concisa del error, T representará la pista del disco donde ocurrió el error, y S será el sector en la pista T al que se refiere el error. Si no existe ningún error, se devolverá el equivalente de  en las cuatro variables. Tenga en cuenta que INPUT# es un comando solo en modo de ejecución. Además, en los programas que emiten muchos comandos de disco, es habitual abrir un archivo en el canal de comando del dispositivo al inicio del programa y no cerrarlo hasta que el programa haya finalizado.

Las versiones 4.0 y posteriores de Commodore BASIC proporcionan una pseudovariable denominada DS$ que puede usarse para recuperar el estado de la unidad en lugar del código anterior. Esta variable reservada no está disponible en versiones anteriores de BASIC, en éstas el canal de comando debe leerse manualmente como se mostró anteriormente. Tenga en cuenta que inmediatamente después del encendido o reinicio, se devolverá la revisión de DOS. Por ejemplo, un 1541 devolverá . El código de error 73 es común a todos los modelos de unidad y se puede utilizar para determinar si la unidad se ha restablecido a su estado de encendido.

Referencias 

Notas

Immers, Richard; Neufeld, Gerald G. (1984). Inside Commodore DOS. The Complete Guide to the 1541 Disk Operating System. DATAMOST, Inc & Reston Publishing Company, Inc. (Prentice-Hall). .
Englisch, Lothar; Szczepanowski, Norbert (1984). The Anatomy of the 1541 Disk Drive. Grand Rapids, MI: Abacus Software (translated from the original 1983 German edition, Düsseldorf: Data Becker GmbH). .
Lundahl, Reijo (1986). 1541-Levyasema. Amersoft.  (en finés).

Enlaces externos 

Sistemas operativos de disco
Commodore 64
Commodore VIC-20