KERNAL [1] es el nombre que da Commodore al núcleo del sistema operativo residente en ROM en sus computadoras domésticas de 8 bits ; del PET original de 1977, seguido de las versiones extendidas pero relacionadas utilizadas en sus sucesores: el VIC-20 , Commodore 64 , Plus/4 , Commodore 16 y Commodore 128 .
El KERNAL de las máquinas Commodore de 8 bits consta de rutinas de sistema operativo de bajo nivel, cercanas al hardware, aproximadamente equivalentes al BIOS en PC compatibles con IBM (a diferencia de las rutinas de intérprete BÁSICA , también ubicadas en ROM), así como funcionalidad de E/S de nivel superior, independiente del dispositivo. El usuario puede invocarlo a través de una tabla de salto en la RAM cuya parte central (la más antigua), por razones de compatibilidad con versiones anteriores , [2] permanece en gran medida idéntica en toda la serie de 8 bits. La ROM KERNAL ocupa los últimos 8 KB del espacio de direcciones de 64 KB de la CPU de 8 bits ($E000–$FFFF).
La tabla de salto se puede modificar para que apunte a rutinas escritas por el usuario, por ejemplo, para integrar un cargador rápido de modo que sus rutinas de reemplazo rápido se utilicen en todo el sistema o para reemplazar la rutina de salida de texto del sistema por una que funcione en modo de mapa de bits en lugar de Modo personaje. Este uso de una mesa de salto era entonces nuevo para las computadoras pequeñas. [3]
Los juegos de Adventure International publicados para el VIC-20 en el cartucho son un ejemplo de software que utiliza KERNAL. Debido a que solo usan la tabla de salto, los juegos se pueden volcar en memoria al disco, cargar en un Commodore 64 y ejecutar sin modificaciones. [4]
El KERNAL fue escrito inicialmente para Commodore PET por John Feagans, quien introdujo la idea de separar las rutinas BÁSICAS del sistema operativo. Fue desarrollado aún más por varias personas, en particular Robert Russell, quien agregó muchas de las características del VIC-20 y el C64.
Un ejemplo simple, pero característico, del uso de KERNAL lo proporciona la siguiente subrutina en lenguaje ensamblador 6502 [5] (escrita en formato/sintaxis ensamblador ca65 ):
CROUT = $ffd2 ; CHROUT es la dirección de la rutina de salida de caracteres. CR = $0d ; Código PETSCII para retorno de carro ; Hola: lx #0; comience con el carácter 0 cargando 0 en el registro de índice x próximo: mensaje lda,x; cargar byte desde la dirección mensaje+x en el acumulador beq hecho; Si el acumulador tiene cero, hemos terminado y queremos salir del bucle. jsr CROUT ; llame a CHROUT para enviar caracteres al dispositivo de salida actual (el valor predeterminado es la pantalla) inx; incrementa x para pasar al siguiente carácter bne siguiente; bucle hacia atrás mientras el último carácter no sea cero (longitud máxima de cadena 255 bytes) hecho: rts; regresar de la subrutina ; mensaje: .byte " ¡Hola mundo! " .byte CR, 0; Retorno de carro y marca cero al final de la cadena
Este código auxiliar emplea la CHROUTrutina, cuya dirección se encuentra en la dirección $FFD2(65490), para enviar una cadena de texto al dispositivo de salida predeterminado (por ejemplo, la pantalla de visualización).
El KERNAL era conocido como kernel [6] dentro de Commodore desde los días del PET, pero en 1980 Robert Russell escribió mal la palabra kernal en sus cuadernos. Cuando los escritores técnicos del comodoro Neil Harris y Andy Finkel recopilaron las notas de Russell y las usaron como base para el manual del programador del VIC-20, el error ortográfico las siguió y se quedó. [7]
Según el antiguo mito de Commodore, e informado por el escritor y programador Jim Butterfield, entre otros , la "palabra" KERNAL es un acrónimo (o, más probablemente, un backronym ) que significa Keyboard Entry L ead , Network , And Link . , lo que de hecho tiene sentido teniendo en cuenta su función. Berkeley Softworks lo utilizó más tarde para nombrar las rutinas principales de su sistema operativo GUI para computadoras domésticas de 8 bits: GEOS KERNAL.
Sorprendentemente, KERNAL implementó una API de E/S independiente del dispositivo no del todo diferente a la de Unix o Plan-9 , que nadie explotó, hasta donde se sabe públicamente. Mientras que uno podría argumentar razonablemente que "todo es un archivo" en estos últimos sistemas, otros podrían fácilmente afirmar que "todo es un dispositivo GPIB " en el primero.
Debido a las limitaciones de la arquitectura 6502 en ese momento, abrir un canal de E/S requiere tres llamadas al sistema . El primero normalmente establece el nombre de archivo lógico a través de la SETNAMllamada al sistema. La segunda llamada, SETLFSestablece la dirección del "dispositivo" GPIB/ IEEE-488 con el que comunicarse. Finalmente OPENse llama para realizar la transacción real. Luego, la aplicación utilizó llamadas CHKINal CHKOUTsistema para configurar los canales de entrada y salida actuales de la aplicación, respectivamente. Las aplicaciones pueden tener cualquier número de archivos abiertos simultáneamente (hasta cierto límite que depende del sistema; por ejemplo, el C64 permite abrir diez archivos a la vez). A partir de entonces, CHRINresultan CHROUTútiles para realizar entradas y salidas, respectivamente. CLOSEluego cierra un canal.
Observe que no existe ninguna llamada al sistema para "crear" un canal de E/S, ya que los dispositivos no se pueden crear ni destruir dinámicamente en circunstancias normales. Asimismo, no existe ningún medio para buscar ni realizar funciones de "control de E/S" como ioctl () en Unix. De hecho, KERNAL se acerca mucho más a la filosofía del Plan-9, donde una aplicación abriría un canal de "comando" especial al dispositivo indicado para realizar tales transacciones "meta" o "fuera de banda". Por ejemplo, para eliminar ("raspar") un archivo de un disco, el usuario normalmente "abrirá" el recurso llamado S0:THE-FILE-TO-RMVen el dispositivo 8 o 9, canal 15. Según la convención establecida en el mundo Commodore de 8 bits, el canal 15 representa el "canal de comando" para periféricos, que se basa en técnicas de transmisión de mensajes para comunicar tanto comandos como resultados, incluidos casos excepcionales. Por ejemplo, en Commodore BASIC , podrían encontrar software similar al siguiente:
70 ... 80 ROTACIÓN REM DE REGISTROS ABIERTOS ACTUALMENTE EN EL CANAL LÓGICO #1. 90 CERRAR 1 100 ABRIR 15 , 8 , 15 , "R0:ERROR.1=0:ERROR.0" : REM RENOMBRAR ARCHIVO ERROR.0 A ERROR.1 110 ENTRADA# 15 , A , B$ , C , D : REM LEER CANAL DE ERROR 120 CERRAR 15 130 SI A = 0 ENTONCES IR A 200 140 IMPRIMIR "ERROR RENOMBRAR ARCHIVO DE REGISTRO:" 150 IMPRIMIR " CÓDIGO: " + A 160 IMPRIMIR " MENSAJE : " + B$ 170 FINALIZAR 200 REM CONTINUAR PROCESANDO AQUÍ, CREANDO NUEVO ARCHIVO DE REGISTRO A MEDIDA QUE AVANZAMOS... 210 ABRIR 1 , 8 , 1 , "0:ERROR.0,S,W" 220 ... Los números de dispositivo, según la documentación establecida, están restringidos al rango [0,16]. Sin embargo, esta limitación surgió de la adaptación específica del protocolo IEEE-488 y, de hecho, se aplica únicamente a los periféricos externos. Con todas las llamadas relevantes al sistema KERNAL vectorizadas, los programadores pueden interceptar llamadas al sistema para implementar dispositivos virtuales con cualquier dirección en el rango de [32,256]. Posiblemente, se pueda cargar un controlador binario de dispositivo en la memoria, parchear los vectores de E/S de KERNAL y, a partir de ese momento, se podría direccionar un nuevo dispositivo (virtual). Hasta ahora, esta capacidad nunca se ha conocido públicamente como utilizada, presumiblemente por dos razones: (1) KERNAL no proporciona medios para asignar dinámicamente ID de dispositivos, y (2) KERNAL no proporciona medios para cargar una imagen binaria reubicable. Por lo tanto, la carga de las colisiones tanto en el espacio de E/S como en el espacio de memoria recae sobre el usuario, mientras que la compatibilidad de plataformas en una amplia gama de máquinas recae sobre el autor del software. No obstante, si se desea, se podría implementar fácilmente un software de soporte para estas funciones.
Los formatos lógicos de nombres de archivos tienden a depender del dispositivo específico al que se dirige. El dispositivo más común utilizado, por supuesto, es el sistema de disquete, que utiliza un formato similar a MD:NAME,ATTRS, donde M es una especie de indicador ($ para listar directorios, @ para indicar el deseo de sobrescribir un archivo si ya existe, sin usar). de lo contrario), D es el número de unidad de disco físico (opcional) (0: o 1: para sistemas de dos unidades, solo 0: para unidades de disco único como 1541, et al., cuyo valor predeterminado es 0: si no se especifica ), NAMEes un nombre de recurso de hasta 16 caracteres de longitud (se permiten la mayoría de los caracteres excepto ciertos caracteres especiales) y ATTRSes una lista opcional de atributos o indicadores separados por comas. Por ejemplo, si el usuario desea sobrescribir un archivo de programa llamado PRGFILE, es posible que vea un nombre de archivo como el @0:PRGFILE,Pque se usa junto con el dispositivo 8 o 9. Mientras tanto, un nombre de archivo para el controlador RS-232 (dispositivo 2) consta simplemente de cuatro caracteres, codificados. en formato binario. [8]
Otros dispositivos, como el teclado (dispositivo 0), el casete (dispositivo 1), la interfaz de pantalla (dispositivo 3) y la impresora (dispositivo 4 y 5), no requieren nombres de archivo para funcionar, ya sea asumiendo valores predeterminados razonables o simplemente no necesitándolos. en absoluto.