Editing KERNAL

{{short description|Commodore operating system}}
{{Distinguish|Kernel (disambiguation)}}

'''KERNAL'''<ref>''Commodore 64 Programmer's Reference Guide''. Commodore Business Machines, Inc., 1982, p. 268</ref> is [[Commodore International|Commodore]]'s name for the [[read-only memory|ROM]]-resident [[operating system]] core in its [[8-bit]] [[home computer]]s; from the original [[Commodore PET|PET]] of 1977, followed by the extended but related versions used in its successors: the [[VIC-20]], [[Commodore 64]], [[Commodore Plus/4|Plus/4]], [[Commodore 16]], and [[Commodore 128]].

==Description==
The Commodore 8-bit machines' KERNAL consists of the low-level, close-to-the-hardware OS routines roughly equivalent to the [[BIOS]] in IBM PC compatibles (in contrast to the [[Commodore BASIC|BASIC interpreter]] routines, also located in ROM) as well as higher-level, device-independent I/O functionality. It is user-callable via a [[Branch table|jump table]] in RAM whose central (oldest) part, for reasons of [[backwards compatibility]],<ref>The KERNAL jump table, used to access all the [[subroutine]]s 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.</ref> remains largely identical throughout the whole 8-bit series. The KERNAL ROM occupies the last 8 [[Kilobyte|KB]] of the 8-bit CPU's 64 KB address space ($E000–$FFFF). 

The jump table can be modified to point to user-written routines, for example, to integrate a [[fast loader]] so that its fast replacement routines are used system-wide or to replace the system text output routine with one that works in bitmapped mode rather than character mode. This use of a jump table was novel in small computers at the time.<ref>{{cite web|url=https://archive.org/stream/byte-magazine-1983-01-rescan/1983_01_BYTE_08-01_Looking_Ahead#page/n239/mode/2up|title=Exploring the VIC-20|date=January 1983}}</ref>

The [[Adventure International]] games published for the VIC-20 on the [[ROM cartridge|cartridge]] are an example of software that uses the KERNAL. Because they only use the jump table, the games can be [[memory dump]]ed to disk, loaded into a Commodore 64, and run without modification.<ref name="kevelson198601">{{cite news | url=https://archive.org/stream/Ahoy_Issue_25_1986-01_Ion_International_US#page/n31/mode/2up |title=Speech Synthesizers for the Commodore Computers / Part II | work=Ahoy! | date=January 1986 |author=Kevelson, Morton |pages=32 |accessdate=17 July 2014}}</ref>

The KERNAL was initially written for the Commodore PET by John Feagans, who introduced the idea of separating the BASIC routines from the operating system. It was further developed by several people, notably Robert Russell, who added many of the features for the VIC-20 and the C64.

==Example==
A simple, yet characteristic, example of using the KERNAL is given by the following [[MOS Technology 6502|6502]] [[assembly language]] subroutine<ref>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.</ref> (written in [[cc65|ca65]] assembler format/syntax):

    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:
            lda message,x    ; load byte from address message+x into the [[Accumulator (computing)|accumulator]]
            beq done         ; if the accumulator holds zero, we're done and want to branch out of the loop
            jsr CHROUT       ; call CHROUT to output char to current output device (defaults to screen)
            inx              ; increment x to move to the next character
            bne next         ; loop back while the last character is not zero (max string length 255 bytes)
    done:
            rts              ; return from subroutine
    ;
    message:
            .byte "[[Hello world program#Accumulator + index register machine: MOS Technology 6502, CBM KERNAL, ca65 assembler|Hello, world!]]"
            .byte CR, 0      ; Carriage Return and zero marking end of string

This code stub employs the <code>CHROUT</code> routine, whose address is found at address <code>[[hexadecimal|$]]FFD2</code> (65490), to send a text string to the default output device (e.g., the display screen).

==The name==
The KERNAL was known as ''kernel''<ref>The [[kernel (operating system)|kernel]] is 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</ref> inside of Commodore since the PET days, but in 1980 Robert Russell misspelled the word as ''kernal'' in his notebooks. When Commodore technical writers Neil Harris and Andy Finkel collected Russell's notes and used them as the basis for the VIC-20 programmer's manual, the misspelling followed them along and stuck.<ref>''On The Edge: The Spectacular Rise and Fall of Commodore'', page 202.</ref>

According to early Commodore myth, and reported by writer/programmer [[Jim Butterfield]] among others, the "word" KERNAL is an acronym (or, more likely, a [[backronym]]) standing for '''''K'''eyboard '''E'''ntry '''R'''ead, '''N'''etwork, '''A'''nd '''L'''ink'', which in fact makes good sense considering its role. [[Berkeley Softworks]] later used it when naming the core routines of its [[GUI]] OS for 8-bit home computers: the [[GEOS (8-bit operating system)|GEOS]] KERNAL.

== On device-independent I/O ==

Surprisingly, the KERNAL implemented a device-independent I/O API not entirely dissimilar from that of [[Unix]] or [[Plan 9 from Bell Labs|Plan-9]], which nobody actually exploited, as far as is publicly known. Whereas one could reasonably argue that "everything is a file" in these latter systems, others could easily claim that "everything is a [[GPIB]]-device" in the former.

Due to limitations with the 6502 architecture at the time, opening an I/O channel requires three [[system call]]s. The first typically sets the logical filename through the <code>SETNAM</code> system call. The second call, <code>SETLFS</code>, establishes the GPIB/[[IEEE-488]] "device" address to communicate with. Finally <code>OPEN</code> is called to perform the actual transaction. The application then used <code>CHKIN</code> and <code>CHKOUT</code> system calls to set the application's current input and output channels, respectively. Applications may have any number of concurrently open files (up to some system-dependent limit; e.g., the C64 allows for ten files to be opened at once). Thereafter, <code>CHRIN</code> and <code>CHROUT</code> prove useful for actually conducting input and output, respectively. <code>CLOSE</code> then closes a channel.

Observe that no system call exists to "create" an I/O channel, for devices cannot be created or destroyed dynamically under normal circumstances.  Likewise, no means exists for seeking, nor for performing "I/O control" functions such as [[ioctl]]() in Unix.  Indeed, the KERNAL proves much closer to the Plan-9 philosophy here, where an application would open a special "command" channel to the indicated device to conduct such "meta" or "out-of-band" transactions.  For example, to delete ("scratch") a file from a disk, the user typically will "open" the resource called <code>S0:THE-FILE-TO-RMV</code> on device 8 or 9, channel 15.  Per established convention in the Commodore 8-bit world, channel 15 represents the "command channel" for peripherals, relying on message-passing techniques to communicate both commands and results, including exceptional cases.  For example, in [[Commodore BASIC]], they might find software not unlike the following:
<syntaxhighlight lang="cbmbas">
    70 ...
    80 REM ROTATE LOGS CURRENTLY OPENED ON LOGICAL CHANNEL #1.
    90 CLOSE 1
    100 OPEN 15,8,15,"R0:ERROR.1=0:ERROR.0":REM RENAME FILE ERROR.0 TO ERROR.1
    110 INPUT# 15,A,B$,C,D:REM READ ERROR CHANNEL
    120 CLOSE 15
    130 IF A=0 THEN GOTO 200
    140 PRINT "ERROR RENAMING LOG FILE:"
    150 PRINT "  CODE: "+A
    160 PRINT "  MSG : "+B$
    170 END
    200 REM CONTINUE PROCESSING HERE, CREATING NEW LOG FILE AS WE GO...
    210 OPEN 1,8,1,"0:ERROR.0,S,W"
    220 ...
</syntaxhighlight>
Device numbers, per established documentation, are restricted to the range [0,16]. However, this limitation came from the specific adaptation of the IEEE-488 protocol and, in effect, applies only to external peripherals. With all relevant KERNAL system calls vectored, programmers can intercept system calls to implement virtual devices with any address in the range of [32,256]. Conceivably, one can load a [[device driver]] binary into memory, patch the KERNAL I/O vectors, and from that moment forward, a new (virtual) device could be addressed. So far, this capability has never been publicly known as utilized, presumably for two reasons: (1) The KERNAL provides no means for dynamically allocating device IDs, and (2) the KERNAL provides no means for loading a relocatable binary image. Thus, the burden of collisions both in I/O space and in memory space falls upon the user, while platform compatibility across a wide range of machines falls upon the software author. Nonetheless, support software for these functions could easily be implemented if desired.

Logical filename formats tends to depend upon the specific device addressed. The most common device used, of course, is the floppy disk system, which uses a format similar to <code>MD:NAME,ATTRS</code>, where M is a flag of sorts ($ for directory listing, @ for indicating a desire to overwrite a file if it already exists, unused otherwise.), D is the (optional) physical disk unit number (0: or 1: for dual-drive systems, just 0: for single-disk units like the 1541, et al., which defaults to 0: if left unspecified), <code>NAME</code> is a resource name up to 16 characters in length (most characters allowed except for certain special characters), and <code>ATTRS</code> is an optional comma-separated list of attributes or flags. For example, if the user wants to overwrite a program file called <code>PRGFILE</code>, they might see a filename like <code>@0:PRGFILE,P</code> used in conjunction with device 8 or 9. Meanwhile, a filename for the [[RS-232]] driver (device 2) consists simply of four characters, encoded in binary format.<ref>''Commodore 128 Programmers Reference Guide'', Commodore Business Machines, Inc., 1986, p. 382</ref>

Other devices, such as the keyboard (device 0), cassette (device 1), the display interface (device 3), and printer (device 4 and 5), require no filenames to function, either assuming reasonable defaults or simply not needing them at all.

==Notes==
{{Reflist}}

==External links==
*[https://github.com/mist64/cbmsrc Original KERNAL Source Code for all Commodore machines] 
*[https://www.pagetable.com/?p=926 Commodore KERNAL History]
*[https://github.com/davervw/c64-io_monitor Commodore 64 KERNAL I/O Monitor Utility]

{{Operating system}}

[[Category:Operating system kernels]]
[[Category:Commodore 64]]
[[Category:Nonstandard spelling]]
[[Category:1977 software]]