A Unix-Like Operating System for 6809 Microprocessors

by Stephen L. Childress

from the June 1983 issue of Micro magazine

Unless you’ve been on sabbatical to Siberia of late you will have noticed the swell of interest in the Unix operating system software. Most new and all the old popular 16-bit computers are supporting Unix or one of the numerous look-alikes. Why all the furor? It seems at last we’ve begun to rethink computer programming and usage. Recognizing that software development is expensive and timeconsuming, we must exploit the falling cost of today’s hardware. In this article, I explain how a new operating system software philosphy is being applied to small microcomputers capable of supporting a MC6809 processor. This software is called “OS-9” and is a good example of the rewards of rethinking system software.

This article is not so much to sing the praises of OS-9 as it is to point out the disappointing fact that most new computers being introduced today are a rehash of the disk operating systems of the 1970’s (CP/M, PC-DOS, Apple DOS, etc.) There is a real catch-22 here exemplified by the IBM PC, which has a large memory space; it is running an improved but non-the-less CP/M derivative and therefore does not take advantage of the memory size to make the system more cost-effective. Another good example is Apple DOS, which, when outfitted with a new inexpensive hard disk, must resort to treating it in BASIC with some 72 independent floppy disks.

To date, the 6809 has not found the success of the Z-80, et. al., not because it is inferior, but because it was introduced too near in time to the 16-bit chips. The 8086 and 8088 are used in systems that are not much better, faster, or cheaper than good Z-80 systems. But for the hundreds of thousands of byte-wide (8-bit) computers, OS-9 and the 6809 can be retrofitted to bolster the capabilities of existing systems. OS-9 is, at the time this is written, some two years mature and running on all of the “SS 50” computers, the Apple II, and several European computers. But lacking marketing giants like Tandy and IBM, the machines remain in the fringe areas and have a limited collection of off-theshelf applications software. Rumor has it that Tandy is developing OS-9 for the Color Computer.

Time for Change

The Unix supporters favor a switch from yesterday’s system software philosophies, which have evolved into stubborn, unwiedly enemies of the programmer and, consequently, the enduser. Bell Labs launched the Unix philosophy, the bottom line which might be described as: “Since software is increasingly expensive to develop, let’s change the priorities from frugality in hardware and to abstraction in software design.”

The Unix philosophy is reflected in the jargon: “Shell,” “Kernal,” “Filter,” “Pipe,” “Tee,” and “Socket” - each suggests a simple abstract idea about data processing. For example, Kernal and Shell simply refer to parts of the operating system that can be compared to layers. The concepts Filter, Pipe, and Tee deal with problems such as data base management more easily than the older “query, sort, merge, and report.” General abstraction does cost more in terms of hardware, but in today’s systems where hardware is a small part of a complete systern price, the new priorities are encouraging.

OS-9 Evolution

While Unix was finding its way from DEC PDP-ll/45’s and 70’s to other minicomputers, Motorla and Microware Systems Corporation teamed to produce software that would exploit the capabilities of the new MC6809 “pseudo 16-bit” microprocessor chip, which has all the memory addressing mode power of the minicomputers. The feature that distinguishes micros originally intended for use in industrial controllers from computers for general use is strength in addressing modes. The idea these two companies had was to develop an extremely modular set of reusable software. The benefits of modular software has been known for some time; but it has been realized only in limited terms, requiring the programmer to use monolithic compilers, assemblers, and linkers to effect a merger of modules. Although this works well, it is time consuming and far from ideal. Motorola wanted modularization to the extent of massproduced “software-on-silicon” (ROMs). Before processors of the 6809’s power, such an idea was impractical because of the lack of addressing power.

What is the ideal format for modularization? Here is a wish list, with the scientific name of the species in brackets:

1. Software modules that can be placed anywhere in memory without reassembly or linkloading — just copy it to memory verbatim from some media such as a disk. [Position-independence]

2. Modules that reside in EPROM or ROM already plugged into the address space of the machine. This would be good for modules that are used often. [ROM-able, Reentrant]

3. Modules that intercommunicate in a standard fashion without subtle sneak-paths that can get fouled up. Forbid fragile, spider-web arrangements of software interaction. [Stack-oriented]

4. The modules should contain “pure code” only and the variables used by a module should be in RAM supplied by the modules’ parent (caller).

5. Allow programmer to “activate” modules coming from the software toolbox. These should have all the flexibility of old, stable modules. [Loadable]

6. For non-ROM modules (RAM), allow those not needed for the job at hand to be removed from memory, making more space for other modules.

7. Since requirements change and mistakes do happen, allow a new module to temporarily supercede an old one without hassle. [Precedence]

8. Allow modules to be shared among several users. [Reentrancy]

9. The system software should worry about which language is being used in a particular module — assembly, BASIC, etc..

10. The modules should be able to perform I/O without any knowledge of who/what/how regarding the I/O devices.

11. And last but not least, KISS! That’s “Keep It Simple, Stupid.” Simple means small, and don’t forget that modularization is supposed to mean that a non-Ph.D. can understand the overall system by concentrating on one piece at a time.

This is a tall order. What would the user’s benefit be? The idea is to eliminate the aggravations caused by the older system philosophy. Consider this list of nuisances the computerist must face every day:

1. He needs to run Program B while in A, but A is incompatible with B because they both use the same memory region for their code.

2. A jury-rigged version of program B is made up to let B hide from A, say in high memory.

3. But A and B still fight over the same memory cells for variables. The hide and seek continues with some successes, some hoakey fixes, and a few subtle disasters.

4. The programmer would like to swap A and B but he needs fast (expensive) disks.

5. Multiple users on a micro? There’s not enough memory for two copies of the 20K-byte language program, let alone the 8K or so for the programs.

6. The operating system doesn’t support multiple terminals.

7. The operating system is too complex and will not allow changing I/O conditions without surgery, hacking, patching, and kludging.

8. A change to the I/O would require adjustments to almost all software. But much of it is copy-protected and cannot be modified.

9. Why should the user have to spend $400 for a “print spooler” hardware box? Why can’t the computer take 2% of its time to copy a disk file to the printer port without hassle? These gripes go a long way back in

time and remain today, even in improved operating systems like PC-DOS for the IBM. If you look, you’ll see that the module wish list covers all of these headaches. Now let’s look at what Motorola and Microware did to achieve these goals.

The OS-9 Big Picture

The OS-9 operating system is constructed from modules of machine code, each of which has:

• A string of ASCII characters that gives the module a name

• A module “header” that gives the module type, size, etc.

• Module’s revision nutnber

• Distance to the module’s first instiTJCtion

• For program modules (as opposed to subroutines), the memory storage (RAM) required by the module

• A CRC module checksum to prevent bogus disk files (text) or improper ROMs from being treated as modules

Programs consist of one or more modules and may call subroutines or programs located in other modules. Compilers and interpreters (e.g., BASIC] are merely program modules. If a module is invoked by some program and that module is not in memory, OS-9 will automatically retrieve the module from disk. When no program needs use of a certain module, OS-9 removes it from memory and returns that memory to the pool of uncommitted memory. Though the users really need not be concerned with where modules are in memory, the “MDIR” utility shows a directory of in-memory modules as shown in figure 1.

The module directory shows each module’s name, address in memory, size, attributes (program, subroutine, language, etc.), revision, and “use” count. The I/O drivers and the peripherals (device modules) are each handled by independent modules subordinate to modules RBF or SCF, which are, in turn, subordinate to IOMAN. In keeping with the module concept, device drivers and their device modules (e.g., WD1OOO and HO) are loadable from disk. Thus, to add another disk drive, one merely prepares a new device module (a 5-minute job). To add a new type of peripheral, you merely write a new device driver (actually, paraphrase a similar old one), a one-day task. Note that these new modules do not affect the code within the existing modules in any manner whatsoever. Note also the small size of the peripheral drivers, which hints at their simplicity. Score one for the modular I/O goals in the wish list.

Now look at these modules from their kinship perspective rather than from the memory-map view (see figure 2). From this view these modules’ functions are:

KERNAL — allocates and manages memory, time shares CPU among programs, coordinates inter-program signals, accepts and hands off jobs to appropriate I/O chiefs.

CLOCK — handles 60-per-second (power line) clock interrupts and keeps time of day and time-sharing slice intervals.

IOMAN — responsible for all requests for I/O, regardless of device. Interfaces programs in a uniform way to the various classes of I/O.

RBF — I/O control of random blockoriented devices such as disks. Takes care of directories, files, media allocation, etc. Calls upon various device drivers for physical I/O. Knows nothing about tracks or sectors; works with 32-bit “logical” block numbers.

SCF — I/O control of sequential character-oriented devices like CRTs, which are, to the user programs, files that may be read or written exactly as RBF (disk) files [except for lack of random access). Knows nothing of the device characteristics, leaving that to a subordinate driver such as ACIA.

DC3 and WDIOOO — Device drivers for specific hardware. Converts RBF’s logical block number to track, sector, cylinder, or whatever is appropriate for the device. Talks to the device’s I/O registers using either polled or interrupt-driven methods. Knows nothing of file structures. Declares that RBF manages I/O for the driver.

DO — A device (descriptor) module for a mini-floppy. Supplies details of device; e.g., I/O register locations, number of tracks, sectors per track, drive number, seek time, double/single density/sided, etc. Contains data only, no code. DO is the name programs use to refer to the peripheral for I/O activities on files on that device. This module states that its device is handled by the driver named DC3.

HO — Identical to DO, except values unique to the hard disk. Defines WDIOOO as the driver for device HO. ACIA — Driver for RS-232 UART peripherals. Handles the characters from/ to serial channels. Buffers incoming data for type-ahead. Buffers outgoing data to allow calling program to get on with concurrent work. Allows editing of typos, recall of last line entered, etc. Using device modules, it adapts to the terminal for upper/lower case, auto-line feed, nulls, etc. Declares that SCF manages the I/O for the driver.

TERM and Tl — Like DO and HO, these device descriptor modules define the driver name for the TERM and Tl peripherals (CRTs) as ACIA, and the terminals’ unique needs.

To perform I/O to a certain device, a program (in some language) says in effect: “READ from DO” or “WRITE to TERM” or whatever. If, for example, the desired device is HO (the hard disk) the KERNAL catches the program’s request and, since it is I/O, calls upon lOMAN. This module then looks for the device name (HO) in the module directory and finds the name of the driver (WDIOOO) within the HO module. Within the WDIOOO module is the name of the driver, RBF. Then lOM AN merely sends the programs I/O desires to the I/O chief, RBF, along with the addresses of the driver (WDIOOO) and device (HO) modules. From here, RBF takes care of the rest, with help from the driver WDIOOO.

Although it’s not obvious, this maze-running has one simple advantage. The user’s program requested I/O to some device HO, and OS-9 figured out that HO with WDIOOO and RBF could do the job. The beauty of the scheme is that the system handled the device I/O despite the fact that the device “HO” was unknown at the time the main system was written, assembled, and configured (and no “hacking and patching” was done). Indeed, WDIOOO and HO were merely loaded into memory just after booting from the floppy. The same is true for Tl, the second CRT and, though not shown, for a printer attached as device “P”, managed by ACIA and SCF. Clearly, more printers, say PI, or more CRTs, say T2, or more disks, say Dl or HI or X8580 may be added without affecting the rest of the system in any way whatsoever. Remember, these modules are just small pieces of data or code loaded from some disk into memory whenever a peripheral is added. Indeed, the printer module P is loaded only when that printer is being used!

This concludes part 1. See the July issue of MICRO for part 2.