Classic Computer Magazine Archive COMPUTE! ISSUE 10 / MARCH 1981 / PAGE 87


A Small Operating System: OS65D The Kernel

Part 3 of 3

Tom R. Berger
School of Math
University of Minnesota
Minneapolis, MN

Concluding Remarks

OS65D is a very small operating system. It is in no sense 'generalized' to run with a large variety of software or peripherals as, say, Digital Research's CP/M is for the Z80. If software and peripherals other than those supplied by OSI are to be used, then the operating system must be modified. There are advantages and disadvantages to such an operating system. Disadvantages result from its inherent inflexibility and lack of generalized commands. On the other hand, because the operating system is so very small and easy to understand, for those who choose to understand it, it is easy to modify to suit personal needs: a definite advantage.

Let's look now at some 'features' not available in OS65D. Essentially all the operating system is in memory at all times. This creates minor problems with peripherals and INPUT/OUTPUT. For example, the original conception by OSI of I/O leads to a sequence of routines exactly filling the I/O space.

Time has shown that OSI did not make the perfect choice for all situations. In particular, the real time version of OS65D requires that certain of the I/O routines be partially overlaid or omitted to make room for expansions of other I/O routines. The missing routines are not easily returned except by special allocation. A more generalized system would have an area of memory for I/O routines (just as OS65D does), but this area would not have fixed routines in it. I/O routines would be written to run at any location and would be loaded into the special space from the disk when they were needed, and where a niche was available. After they had served their purpose, the space they occupy would become available for other routines. This 'generalized' approach eases I/O problems, but requires much additional coding to handle all the loading and space allocation.

The disk handling routines could not be made much more compact. In particular, many user functions are left out. Thus the user must do a large amount of housekeeping not required on larger systems. The most glaring deficiency is the file creation process. You cannot create a file until you know its size. Usually, you cannot know its size until it is in memory; but the file creation utility occupies the same space as the file. As a result, a scratch file must be created in order to temporarily save programs while a permanent file of the correct size is created. The process becomes even more involved if you wish to expand a current file beyond its current size.

If you use BASIC programs which process many files, then the error recovery process of OS65D is far too simple. If BASIC calls an operating system command (say DISK!"blah blah") and an error occurs, this error is often nonrecoverable. That is, the stack is reset and return to BASIC occurs through the WARM START. This often means your program will bomb if you try to CONTINUE. If you have a large amount of information stored in BASIC strings and in the process of saving it encounter a disk error, then without a great deal of knowledge about the internal working of BASIC, your information is lost.

Most file handling is done with BASIC utilities. If you are programming in assembly language, this leads to endless shuffling back and forth from BASIC to the Assembler and back.

The operating system lacks an adequate editor. Thus the Assembler and BASIC must contain their own editors. As a consequence, all input must be acceptable to one of these two editors if it is to be processed. In particular, line numbers are needed. A BASIC program can be created to solve this numbering problem, but BASIC may be too slow. Solving this new problem leads to further complications which would not be necessary with a good operating system editor.

There are certain philosophical advantages to a small operating system. OS65D is small enough that its entire operation can be understood at once. This means hackers can modify and alter the system, not just by POKES and patches, but fundamentally, to suit their own needs. In my experience, most hobby OSI computer owners aspire to or already fall in this hacking category. The smallness of the system puts the user in direct contact with the most fundamental operating system commands and operations. Even though it is slightly more involved, this gives the user the very maximum of control over the system.

This article was written using disassemblies of OS65D V3.2 (NMHZ) Release November 1979. Future articles will cover: (1) the I/O routines; (2) the Disk routines; (3) the ROM, and (4) miscellaneous bits and pieces. The disassemblies I have made are fully annotated (by hand) and are available for those who would like to use them. Send a stamped, self-addressed postcard to me to determine availability.

Tom Berger
10670 Hollywood Blvd.
Coon Rapids, MN 55433