Around the middle of Febuary, Frank Hogg asked me to do a "little something" on Level ~~Two OS9~~ for the CoCo-3. This is the result, a compilation of old and new notes I and others had made for ourselves.

Around the middle of Febuary, Frank Hogg asked me to do a "little something" on Level 2 OS-9 for the CoCo-3. This is the result, a compilation of old and new notes I and others had made for ourselves.

Organizing anything about OS-9 is tough, since each part of it interacts closely with the rest. In the end, I decided to simply present information as a series of essays and tables. Some of these are ones that I had made for ~~L-I~~, but apply equally well to ~~L-II~~. Maybe in a half year or so we'll come out with a second edition, but we really wanted to help people out NOW.

Organizing anything about OS-9 is tough, since each part of it interacts closely with the rest. In the end, I decided to simply present information as a series of essays and tables. Some of these are ones that I had made for Level 1, but apply equally well to Level 2. Maybe in a half year or so we'll come out with a second edition, but we really wanted to help people out NOW.

To me, at least, it is very like being blind not knowing exactly what occurs during the execution of a program that I have written. For that reason, I have taken a look at OS-9 on the CoCo from the inside out.

The idea is that if you can figure out what's happening on the inside, you have a better chance of knowing what to do from the user level. In essence, this whole collection is a reference work for myself and my friends out there like you.

Level~~-II~~ wasn't out yet at the beginning of this writing, and I had not seen the Tandy manual until the end, so please bear with me if things have changed somewhat.

Level 2 wasn't out yet at the beginning of this writing, and I had not seen the Tandy manual until the end, so please bear with me if things have changed somewhat.

In general, I will not duplicate explanations provided by the Tandy manuals, Microware manuals or the Rainbow Guide. Instead, my intention is to enhance them. You should get them, too. Dale Puckett and Peter Dibble are working now on a book about windows for the user. I will be doing more on drivers soon.

or the Rainbow Guide. Instead, my intention is to enhance them. You should get them, too. Dale Puckett and Peter Dibble are working now on a book about windows for the user. I will be doing more on drivers soon.

This reference work is the result of many hours of studying and probing by myself and others. Hopefully, it will save you at least some of the time and trouble that we have had. Since this is meant as part tutorial, part quick reference, some tables may occur more than once as I felt necessary.

Now, since we know that we can be processing code and sharing the 64K memory space with other programs, we can allow more than one program / user at more or less the same time by switching between the processes fast enough to appear to each user that he has his own computer.

How often is fast? In some other multi-tasking systems, each process is responsible for signaling to the operating system kernal that it was ready to give up some of its CPU time. The advantage of this method was that time-critical code wasn't interrupted. (~~OS9~~ users can simply shut off interrupts if this is necessary.) But this method depends on the user to write the switching signal into his code so that it was hit often enough to give other processes a chance to run.

How often is fast? In some other multi-tasking systems, each process is responsible for signaling to the operating system kernal that it was ready to give up some of its CPU time. The advantage of this method was that time-critical code wasn't interrupted. (OS-9 users can simply shut off interrupts if this is necessary.) But this method depends on the user to write the switching signal into his code so that it was hit often enough to give other processes a chance to run.

In ~~OS9~~, there is always a system clock' that interrupts the 6809 about 10 times a second, and causes the next process to be given a CPU time slice (Actually 60 times/second on the CoCo, but a process time slice is considered to be 6 'ticks', or 1/10th second). Other interrupts from any I/O devices needing service cause the system to execute the interrupt service routine in the driver for that device, and quickly resume the original process.

In OS-9, there is always a system clock' that interrupts the 6809 about 10 times a second, and causes the next process to be given a CPU time slice (Actually 60 times/second on the CoCo, but a process time slice is considered to be 6 'ticks', or 1/10th second). Other interrupts from any I/O devices needing service cause the system to execute the interrupt service routine in the driver for that device, and quickly resume the original process.

Switching between processes is the easy part. Each process has a process descriptor, holding information about it. When the 6809 is interrupted, the current address it is at in the program, and the CPU's registers are saved on the system stack in the process's data area. The stack pointer's value is saved in the current program's process descriptor for later retrieval.

* Suspend (%0000 1000) Continues to age in active queue, but is passed over for execution. Used in place of Sleep and Signal calls in some ~~L-II~~ drivers.

* Suspend (%0000 1000) Continues to age in active queue, but is passed over for execution. Used in place of Sleep and Signal calls in some Level 2 drivers.

* Conden (%0000 0010) Has received a deadly signal, dies by a forced FSExit call as soon as it is no longer in a system state.

* Dead (%0000 0001) Is already unexecutable, as its data and program areas have been relinquished by an F$Exit call. The process descriptor is kept so that the death signal code may be passed to the parent on F$Wait.

If two or more processes want to do input/output/status operations on the same device, all except the first will have to wait in line (queue). Under ~~OS9~~, IOMan and the file managers are responsible for this control.

If two or more processes want to do input/output/status operations on the same device, all except the first will have to wait in line (queue). Under OS-9, IOMan and the file managers are responsible for this control.

Each open path has a path descriptor associated with it. This is a 64-byte packet of information about the file. Because ~~OS9~~ allows a path that has been opened to a file or device to be duplicated, and used by another process, several programs may be talking about the same path (and path descriptor). Provision must be made to queue an I/O attempt using the same path. (The most common instance of this is with /TERM.)

Each open path has a path descriptor associated with it. This is a 64-byte packet of information about the file. Because OS-9 allows a path that has been opened to a file or device to be duplicated, and used by another process, several programs may be talking about the same path (and path descriptor). Provision must be made to queue an I/O attempt using the same path. (The most common instance of this is with /TERM.)

Since all I/O calls pass through the system module IOMAN, the I/O manager, it checks a path descriptor variable called PD.CPR to see if it is clear, or not in use. If it is in use, the process in inserted in a queue to await it's turn.

Commonly used signals include the Kill and the Wakeup codes. Wakeup is essential to let the next process in an I/O queue get its turn in line at a path or device.

~~OS9~~ has a signal-sending call, ~~FSSend~~, which sends a one byte signal to the process ID specified, and causes the recipient to be inserted in the active process queue. Any signal other than Kill or Wake is put in the PSSignal byte of its process descriptor.

OS-9 has a signal-sending call, F$Send, which sends a one byte signal to the process ID specified, and causes the recipient to be inserted in the active process queue. Any signal other than Kill or Wake is put in the PSSignal byte of its process descriptor.

If it was the Kill signal, the PSState byte in the process descriptor has the Condemned bit set to alert the kernal to kill that process. A Wake signal clears the PSSignal byte, since just making the destination an active process was enough.