Ir al contenido

KERNAL

De Wikipedia, la enciclopedia libre
KERNAL
Información general
Tipo de programa núcleo
Desarrollador Commodore International
Modelo de desarrollo código cerrado
Estado actual discontinuo
Información técnica
Plataformas admitidas

KERNAL[1]​ es el nombre designado porCommodorepara elnúcleodelsistema operativoresidente enROMen suscomputadoras domésticasde8 bits;desde elPEToriginal de 1977, seguido de las versiones extendidas pero fuertemente relacionadas utilizadas en sus sucesores: elVIC-20,Commodore 64,Plus/4,C16yC128.

Descripción

[editar]

El KERNAL de las máquinas Commodore de 8 bits consta de rutinas del sistema operativo de bajo nivel, cercanas al hardware, más o menos equivalentes alBIOSen lasPC compatiblesconIBM(en contraste con las rutinas del intérprete BASIC, también ubicadas en ROM), así como funcionalidad de E/S independiente del dispositivo de nivel superior, y puede ser llamada por el usuario a través de unatabla de saltoscuya 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 8KBdel espacio de direcciones de los 64 KB de la CPU de 8 bits ($E000- $FFFF).

La tabla de salto se puede modificar para apuntar a rutinas escritas por el usuario, por ejemplo, reescribiendo las rutinas de visualización de pantalla para mostrar gráficos animados o copiando el conjunto de caracteres en la RAM. Este uso de una mesa de salto era nuevo para las computadoras pequeñas en ese momento.[3]

Los juegos deAdventure Internationalpublicados para el VIC-20 en cartucho son un ejemplo de software que utiliza KERNAL. Debido a que solo usan la tabla de salto, los juegos puedendescargarse en la memoriadel disco, cargarse en un Commodore 64 y ejecutarse sin modificaciones.[4]

El KERNAL fue escrito inicialmente para el Commodore PET por John Feagans, quien introdujo la idea de separar las rutinas de BASIC del sistema operativo. Fue desarrollado por varias personas, especialmente Robert Russell, quien agregó muchas de las características para el VIC-20 y el C64.

Ejemplo

[editar]

La siguiente subrutina delenguaje ensamblador6502[5]​ (escrita en formato/sintaxis de ensamblador ca65) proporciona un ejemplo simple pero característico del uso de KERNAL:

CHROUT=$ffd2;CHROUT is the address of the character output routine
CR=$0d;PETSCII code for Carriage Return
;
hello:
ldx#0;start with character 0 by loading 0 into the x index register
next:
ldamessage,x;load byte from address message+x into the accumulator
beqdone;if the accumulator holds zero, we're done and want to branch out of the loop
jsrCHROUT;call CHROUT to output char to current output device (defaults to screen)
inx;increment x to move to the next character
bnenext;loop back while the last character is not zero (max string length 255 bytes)
done:
rts;return from subroutine
;
message:
.byte"Hola mundo"
.byteCR,0;Carriage Return and zero marking end of string

Este código auxiliar emplea la rutinaCHROUT,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 nombre

[editar]

El KERNAL era conocido comokernel[6]​ dentro de Commodore desde los días de PET, pero en 1980 Robert Russell escribió mal la palabra comokernalen sus cuadernos. Cuando los escritores técnicos de Commodore Neil Harris y Andy Finkel recogieron las notas de Russell y las usaron como base para el manual del programador VIC-20, la falta de ortografía los siguió y quedó como estaba.[7]

Según el antiguo mito de Commodore, e informado por el escritor/programador Jim Butterfield, entre otros, la "palabra" KERNAL es un acrónimo (o quizás más probable, unretroacrónimo) que significaKeyboardEntryRead,Network,AndLink.,lo que de hecho tiene sentido teniendo en cuenta su papel.Berkeley Softworksmás tarde lo usó al nombrar las rutinas centrales de su sistema operativo GUI para computadoras hogareñas de 8 bits: elGEOSKERNAL.

En E/S independientes del dispositivo

[editar]

Sorprendentemente, el KERNAL implementó una API de E/S independiente del dispositivo que no es completamente diferente de la deUnixoPlan-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 afirmar fácilmente que "todo es un dispositivoGPIB"en el primero.

Debido a las limitaciones con la arquitectura 6502 en ese momento, abrir un canal de E/S requiere tres llamadas al sistema. El primero generalmente establece el nombre de archivo lógico a través de la llamadaSETNAM.La segunda llamada,SETLFS,establece la dirección del "dispositivo" GPIB/IEEE-488 para comunicarse. Finalmente se llama aOPENpara realizar la transacción real. Luego, la aplicación utiliza las llamadas al sistemaCHKINyCHKOUTpara configurar los canales de entrada y salida actuales de la aplicación, respectivamente. Las aplicaciones pueden tener cualquier cantidad de archivos abiertos simultáneamente (hasta cierto límite dependiente del sistema; por ejemplo, el C64 permite que se abran diez archivos a la vez). A partir de entonces,CHRINyCHROUTresultan útiles para realizar entradas y salidas, respectivamente.CLOSEluego cierra un canal.

Observe que no existe una llamada al sistema para "crear" un canal de E/S, ya que los dispositivos no pueden crearse ni destruirse dinámicamente en circunstancias normales. Del mismo modo, no existen medios para buscar, ni para realizar funciones de "control de E/S" comoioctl() en Unix. De hecho, el KERNAL demuestra mucho más cerca de la filosofía del Plan-9 aquí, donde una aplicación abriría un canal especial de "command"al dispositivo indicado para realizar tales transacciones"meta"o"out-of-band".Por ejemplo, para eliminar ("scratch") un archivo de un disco, el usuario normalmente" abrirá "el recurso llamadoS0: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 los periféricos, basándose en técnicas de transmisión de mensajes para comunicar comandos y resultados, incluidos casos excepcionales. Por ejemplo, enCommodore BASIC,pueden encontrar software similar al siguiente:

70...
80REM ROTATE LOGS CURRENTLY OPENED ON LOGICAL CHANNEL #1.
90CLOSE1
100OPEN15,8,15,"R0:ERROR.1=0:ERROR.0":REM RENAME FILE ERROR.0 TO ERROR.1
110INPUT#15,A,B$,C,D:REM READ ERROR CHANNEL
120CLOSE15
130IFA=0THENGOTO200
140PRINT"ERROR RENAMING LOG FILE:"
150PRINT"CODE:"+A
160PRINT"MSG:"+B$
170END
200REM CONTINUE PROCESSING HERE, CREATING NEW LOG FILE AS WE GO...
210OPEN1,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 proviene de la adaptación específica del protocolo IEEE-488 y, en efecto, se aplica solo a periféricos externos. Con todas las llamadas relevantes del sistema KERNAL vectorizadas, los programadores pueden interceptar llamadas del sistema para implementar dispositivos virtuales con cualquier dirección en el rango de 32,256). Posiblemente, uno puede cargar un controlador de dispositivo binario en la memoria, parchear los vectores de E/S KERNAL y, a partir de ese momento, se podría abordar 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 dispositivo, 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 en el usuario, mientras que la compatibilidad de la plataforma en una amplia gama de máquinas recae en el autor del software. No obstante, el software de soporte para estas funciones podría implementarse fácilmente si se desea.

Los formatos lógicos de nombre de archivo tienden a depender del dispositivo específico direccionado. El dispositivo más común utilizado, por supuesto, es el sistema de disquete, que usa un formato similar aMD:NAME,ATTRS,donde M es una especie de bandera ($ para el listado del directorio, @ para indicar el deseo de sobrescribir un archivo si ya existe, sin usar de otra manera), D es el número de unidad de disco físico (opcional) (0: o 1: para sistemas de doble unidad, solo 0: para unidades de disco único como el 1541, et al., que por defecto es 0: si no se especifica),NAMEes un nombre de recurso de hasta 16 caracteres de longitud (la mayoría de los caracteres permitidos, excepto ciertos caracteres especiales), yATTRSes una lista opcional de atributos o indicadores separados por comas. Por ejemplo, si el usuario desea sobrescribir un archivo de programa llamadoPRGFILE,podría ver un nombre de archivo como@0:PRGFILE,Pusado 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, suponiendo valores predeterminados razonables o simplemente no los necesitan. en absoluto.

Referencias

[editar]
  1. Commodore 64 Programmer's Reference Guide.Commodore Business Machines, Inc., 1982, p. 268
  2. The KERNAL jump table, used to access all the subroutines in the KERNAL, is an array of JMP (jump) instructions leading to the actual subroutines. This feature ensures compatibility with user-written software in the event that code within the KERNAL ROM needs to be relocated in a later revision.
  3. «Exploring the VIC-20».
  4. Kevelson, Morton (January 1986).«Speech Synthesizers for the Commodore Computers / Part II».p. 32.Consultado el 17 de julio de 2014.
  5. Many of the KERNAL subroutines (e.g., OPEN and CLOSE) were vectored through page three in RAM, allowing a programmer to intercept the associated KERNAL calls and add to or replace the original functions.
  6. Thekernelis the most fundamental part of a program, typically an operating system, that resides in memory at all times and provides the basic services. It is the part of the operating system that is closest to the machine and may activate the hardware directly or interface to another software layer that drives the hardware
  7. On The Edge: The Spectacular Rise and Fall of Commodore,page 202.
  8. Commodore 128 Programmers Reference Guide,Commodore Business Machines, Inc., 1986, p. 382

Véase también

[editar]
  • GEOS,sistema operativo gráfico para la Commodore 64 y 128.

Enlaces externos

[editar]