Introduction: why need an Operating System?
There are also functions (or in the Operating System context, called tasks) that are only for the support of
special (possibly complex) things that can operate fairly stand-alone. The DOM (Degrees Of Movement) meter is
a good example. The DOM task handles the 3 buttons and the meter position and update. It would be cumbersome to
implement such stand-alone functionality as part of something else, making everything more complex (and more
difficult to debug ...).
A last type of functions are those functions that need only to be active when an event occurs. Examples of
these tasks are the velocity update task (only needed when you change the velocity, or impulse / warp engine drive),
and the missile update task. Obvious, the missile task is needed only when a torpedo or an anti-matter probe is
launched.
The StarShip contains a complex set of functions, and many of those functions have relations with other functions.
For example, one function is to enter a course. An other function takes the current position of the StarShip and
the course information to calculate the position update information. This in turn needs the information from the
Engineering (speed of the impulse / warp engines).
The tasks of the StarShip's Operating System
Well, this is a very simple description of the basic functions of an OS. There is more, just check out the
"heavy" books on Operating Systems Architecture / Design / Trade offs, etc.
The Operating System (OS) implemented in the StarShip is not quite like for example Windows -whatever-.
The OS you need for real-time control is different from the basic development on; the criteria are just different.
What you need is good response to events and fast task re-scheduling. In my implementation of the OS, I needed the
following functionality.
Remember, you have a lot of tasks that run the complete system. So waiting for 100 mSec, or waiting for a bit
in some memory location to turn to "1" can NOT be done with a so-called "busy-loop".
When you use "busy-loop" programming you lock the CPU to the stupid waiting in the loop. Nothing else runs.
In a real-time application that is something you really do not want!
So, instead of a busy-loop, the task asks the OS to do the busy-loop. But the OS is a bit more clever. Since
the OS knows that the current task that made the request is blocked (can not proceed), the task is put
in a wait queue, and the OS takes the next task that is ready to run.
After some time, the OS checks the reason why a task is blocked, and if that reason no longer exists, the task
gets the CPU to proceed.