david@bdt.UUCP (David Beckemeyer) (03/06/88)
A BRIEF DESCRIPTION OF MICRO RTX
In response to all the requests for information about Micro RTX,
I began working on a document for eventual posting. Before I
finished it, I realized that it was rapidly becoming a very large
book. I therefore have prepared this summary.
There is a lot to RTX and there is a lot of general Atari ST knowledge
and multitasking operating system knowledge that has to be aquiried
before one can even begin to learn RTX in detail.
This document describes only briefly the Atari ST system architecture
and it barely scratches the surface of RTX and multitasking on the ST.
Unfortunately, it just isn't possible to fully describe it in a net
posting.
INTRODUCTION
RTX is a Real-Time Executive. RTX is accessed with system calls,
like the standard TOS/GEMDOS/BIOS services. It is not a command shell
and it doesn't have any "commands" or user interface intrinsic to the
kernel. It is a system call handler.
Atari ST programs make use of the TOS operating system via "system calls".
The whole TOS operating system has GEM calls (several different types),
GEMDOS calls, BIOS calls, XBIOS calls, and LINE-A (graphics) calls.
After Micro RTX is installed, it intercepts and interprets the GEMDOS,
BIOS, and XBIOS calls for all programs. Micro RTX also implements
several RTX-only calls and GEMDOS extensions.
PROGRAMMING OVERVIEW
Programs can call TOS directly. In C, this is done with the "osbind.h"
macros like Fopen, Dgetdrv, and Rwabs. These macros actually produce code
that cause a software interrupt, or trap, which jumps into the ROM code.
The application can also use library routines provided by the compiler
manufacturer (e.g. fopen, or printf). These library routines then perform
the TOS system calls on behalf of the calling program. For example, the
fopen C library routine will eventually use the Fopen system call to open
a file.
It must be understood that there are important differences between
library routines and system calls. The code that implements a library
routine is contained within the application program (it is linked in).
There is a separate copy of the printf handler linked into every C
program that uses printf. These library routines may also "cook" the
programmer's input arguments (e.g. fopen might treat certain file names
as a special case), before they call the actual operating system. It
depends on the compiler manufacture's particular idea of "correct"
implementation.
In contrast, the code that implements system calls is normally in the
TOS ROMs. There is only one Fopen handler; all programs use the same one.
When RTX loads, it replaces the system call handlers with RTX RAM
resident versions. Therefore, there are no changes to the application.
The only difference is a new system call handler. This is one of
the really nice things about RTX. While RTX does add new system
calls, it is optional whether a program wants to use them or not.
Programs using only standard TOS calls operate as usual. Programs
that require special functions that are only available with the RTX
system calls, (e.g. interprocess comminucation, or multi-tasking)
can implement only the RTX calls that are needed.
This means that there are far fewer new operating system calls to
learn. Only the extended features that were not built into TOS need
to be learned; all the features you already know work substantially
the same, with only perhaps some new options added.
It also means that standard program development practices can be
used to develop RTX applications. The applications can even be
developed with compile-time or run-time options, to run with or
without RTX installed. Any language capable of producing system
calls can be used to develop RTX programs: C, Pascal, Modula, or
Assembler.
In C, RTX calls look like regular function calls. In assembler,
they are trap instructions (just like the GEMDOS, BIOS, and XBIOS
calls).
OVERVIEW OF RTX SYSTEM CALLS
RTX implements two separate types of system calls:
- stand-alone Real-Time services
- TOS compatible services and TOS extensions
Both types of system calls may be used in the same application.
The RTX Real-Time kernel provides Real-Time multitasking services
similar to many popular Real-Time systems, such as VRTX, pSOS, etc.
These commercial systems sell for thousands of dollars. Micro RTX
compares very well with these systems even at its low price. There's
no way to give a complete description of what a real-time operating
system is, and what one is used for here. For those that know what it
is, little more needs to be said; for those that don't know what it is,
don't worry about it. For those interested, we have lot's of nice color
brochures that describe the real-time properties of Micro RTX for
commercial Real-time applications that we'd be happy to send you.
RTX is designed to be easy to use. The calls are simple and general.
The calling conventions are consistent and the chance for errors and
confusion has been reduced.
The basic philosophy is that a few very general building blocks can
be put together lot's of different ways to accomplish lot's of
different goals.
This has the drawback that the application developer must have the
vision to know how to put the pieces together effectively. When
a developer needs function X, and RTX has no X, the developer
needs to be able to build X from what RTX does have. It's analogous
to UNIX users who know what you can do with pipes and those that
don't (so somebody has to write them a shell script that does exactly
what they want with no pipes).
Configuration relies on a small number of passive declarations; RTX
is mostly self-configuring.
THE PROCESS
A process is an entity in the system. The terms process and program
are NOT the same thing. A program is a file that contains code and
data that can be loaded into memory and executed. A process is a
running entity, or "being" in the system. The code loaded in from
one program can become a process when it's executed; a single program
may even become several processes when it executes.
In RTX, a process is the atomic unit of CPU execution. While several
processes may be "running" in the system, the CPU can only execute one
process at any one instant of time. The processes appear to execute at
the same time becuase of process switching. A process switch can
occur for several reasons. Each process has a state associated with it.
The basic states are running, sleeping, and ready-to-run.
With RTX, the running state means the CPU is executing the process.
There is only one running process in the system. A sleeping process
is one that is waiting for something other than the CPU (e.g a message,
or event). A sleeping process consumes no CPU resources until it
"wakes up". A ready-to-run process is one that is waiting its turn to
use the CPU (it has work to and is ready to become the running process).
There may be any number of sleeping and ready-to-run processes.
Each process has several types of memory associated with it. Each
type is called a segment. All RTX processes must have all their memory
segments resident at all times. A process needs a code (or text)
segment and a stack segment. A process may also have a (static) data
segment and a (dynamic) heap segment. These segments need not be
contiguous.
Any location in memory containing executable 68000 CPU instructions
can become an RTX process' text segment. Each process has a parent.
A process' parent is the process that created (or spawned) the child.
SCHEDULING
RTX uses two types of CPU scheduling: priority pre-emtive and time-slice.
Each process has a priority associated with it. The RTX kernel uses
a very simple scheduling algroithm. It simply selects the process with
the highest priority from those in the running or ready-to-run states.
When more than one process occupies the same priority level, time-slicing
is used to split up CPU time between the processes. Each process has
a quantum (length of time) associated with it. When this quantum is
used up, RTX schedules the next process. This repeats as long as
several processes are at same priority (and that they are the highest
priority processes that are ready-to-run). This is also sometimes
called "round-robin" scheduling.
PROCESS CREATION
Once a process' memory segments are loaded into memory (at least
the code segment), a new process may be created. Process creation
simply is the way a process is made known to RTX. RTX creates
a stack segment for the process, and places it on the ready-to-run
list. The caller (the process creating the new process) provides
the priority, time-slice, load address, input arguments, and stack-size.
The priority and time-slice quantum may be altered at run-time.
A pid in RTX is actually the 32-bit address of the proces control
block (an internal RTX data structure) for the process.
The Pexec GEMDOS call also performs a process creation indirectly.
A direct call to the RTX p_create service will spawn and run a loaded
process (i.e. it runs a subroutine as a concurrent process). A call
to Pexec loads a GEMDOS formatted executable file, and spawns it as
an RTX process. RTX also provides a Pexec option that allows the caller
to continue processing while the child runs (like fork/exec).
PROCESS CONTROL
The RTX process control system cals are:
p_create - create and execute a new process
p_delete - delete (kill) a process
p_priority - get/set process priority
p_slice - get/set time-slice quantum
p_suspend - suspend (stop) a process
p_resume - resume (re-start) a process
p_lookup - convert process name to a PID
p_info - get the state of a process
In RTX, priorities range from 0 to 255; 255 is used for "real-time"
processes and 0 is reserved for the idle deamon. A process running
at priority 255 never gets time-sliced and will never lose the CPU
until it voluntarilly blocks (waits for something) or lowers its
priority.
INTERPROCESS COMMUNICATION - THE MESSAGE QUEUE
Processes in RTX can communicate by sending messages. The RTX message
queue is a many-to-many queue, sort of a named mailbox. The idea is
like UNIX creat/open/read/write/close. Each message queue has a name
and QID. If a process knows the name of the queue, it can determine
the QID (like UNIX open). Messages are 4 long-words (16 bytes) fixed
size. The first long word (4 bytes) is reserved for RTX. The
remaining 3 long-words (12 bytes) are completely user dependent. The
messages may contain data, or pointers to data located elsewhere.
Any process may send (write) or request (read) a message from any queue
for which it has a QID (like a handle to a file).
Each message queue may be set up as a simple FIFO where waiting
processes are queued in the order that they request messages, or
it can be set up such that processes are queued in priority order.
With a FIFO queue, messages are received (read) in the order that
they were sent. With a priority queue, the process with the highest
priority that is waiting for a message will receive one first.
RTX message queues can be used for many differnt kinds of
interprocess communication/synchronization facilities, including
simple FIFO non-interlocked (simple one-way channel), fully
inter-locked (using two queues), and semaphores.
An example of many-to-many usage might be a print spool system where
several processes make print requests and several printers are available.
One incarnation of a print-spool handler exists for each printer (one
print process per printer). There is one RTX message queue which is
used for print requests. Each print-spool process requests a message
from the print request queue. A process wishing to print something
sends a message to the print request queue. The first print-spool
process that requested a message receives the print request and starts
printing the job. If another process makes a print request, the next
print-spool process will print it, until all the printers are busy and
there are no more print-spool processes waiting for a message, in
which case further print requests will be queued on the message queue
and printed by the next available print process when it requests a
message from the print queue again.
The RTX message queue services are:
q_create - create a message queue
q_delete - delete (close/remove) a message queue
q_send - send (write) a message
q_req - request (read) a message (wait or no-wait)
q_jam - jam a message at the head of the queue
q_lookup - convert queue name to QID (open)
q_info - get the status of a message queue
A maximum wait interval (timeout) option may be specified when
requesting messages. In this case the caller is awaken when either
a message is available or the wait time has expired.
The q_send and q_jam system calls may be made from interrupt service
(ISP) handlers. A special RTX trap is used upon exit from the ISP
to force a pre-emtive reschedule (if necessary).
RTX EVENTS
UNIX programmers beware: RTX events are not anything like UNIX signals.
The RTX event system is a many-to-one synchronization facility. Each
process has associated with it a set of seven user events and seven
system (reserved) events. A process can signal a single or a group
of events to another process with a single call and it can wait for
the occurance of one or more of its own events.
What event is used for what is completely up to the application developer.
RTX places no restrictions on the use of the seven user events. The
primary limitation of events is that, unlike messages, events are not
queued. Where overrun is impossible or can be handled, the event system
does offer the advantage of specifying multiple events.
The event system calls are:
e_signal - signal a group of events
e_wait - wait for one or more events
A process may wait for any of a group of events, in which case it will
be awakened when any of the specified events is signaled, or it can
wait for all events, in which case it will not be awakened until all
the events are signaled. As with messages, a maximum wait interval
may be specified to handle timeout situations.
The e_signal system call may be used in ISP routines for real-time
pre-emptive applications.
RTX MEMORY MANAGEMENT
RTX uses a first-fit memory allocation algorithm. Memory segments
are allocated from system heaps. The RTX kernel splits the first
section large enough to meet a users request, returning any remainder
back to the free pool. When a segment is released back to RTX, it is
merged with its neighboring segments, if one or both of these segments
are free.
The RTX memory management calls are:
m_alloc - allocate a memory segment
m_free - free a segment
m_assign - transfer a segment to another process
The GEMDOS Malloc system call uses the RTX m_alloc system call to
allocate memory when RTX is installed (this solves some TOS memory
management problems).
REAL-TIME PAUSING
RTX provides a call that allows a process to schedule itself at a
regular interval, or sleep for a duration of time:
p_pause - pause (sleep) for a specified time interval
The time interval is specified in miliseconds.
TOS GEMDOS AND BIOS EXTENSIONS
As stated elsewhere, the Micro RTX kernel processes all GEMDOS and BIOS
system calls. All Device and File I/O system calls are handled by the
RTX kernel.
In addition to providing compatibility, RTX also implements several
extended GEMDOS and BIOS services. The GEMDOS system calls are:
Pexec - supports "execute concurrently" mode
Popen - Pipes using GEMDOS file handles
Ftype - Determine if handle is file/pipe/device
Flock - File record locking
Fcntrl - GEMDOS-level character device control
Psettpa - control the startup TPA (stack) size
Mquota - limit the Malloc(-1) maximum
The Popen service combined with GEMDOS I/O redirection allows any
TOS program using GEMDOS STDIN/STDOUT to be used in pipelines (i.e.
the programs do not need to be recompiled to work with pipes).
The Flock call provides file locking for multiuser file access. Any
region of a file may be locked (even beyond the end-of-file). When
another process attempts to read or write the locked region, the
operation will fail, in which case the application may take appropriate
actions (i.e. pause and try again). For application developers that wish
to implement file record locking in their applications, but do not wish
to purchase the Micro RTX Developer's Kit, contact Beckemeyer Development
at the address below for details.
The Fcntrl function alters the behavior of character (tty) devices for
GEMDOS I/O operations. In the normal case, I/O to terminal devices is
"cooked". Using Fcntrl, a program can force NOECHO and/or RAWIO modes.
The BIOS-level RTX extensions are:
d_install - install a custom device driver
d_cntrl - BIOS-level device control
The installable device driver mechanism allows the developer to
install or replace BIOS devices. The devices are accessed with
the Bconxxx BIOS calls, using the device number field. The
standard BIOS devices are:
0 - PRN - Printer
1 - AUX - RS-232 port
2 - CON - System console (screen/keyboard)
3 - MIDI - Midi port
4 - KBD - Intelligent keyboard
From GEMDOS these devices may be opened by name (the standard names
work with or without RTX installed). For example:
fd = Fopen("aux:", 2);
Will return a handle that will read/write charcters using the RS-232
port. Under RTX, devices may be installed with a BIOS number and GEMDOS
name. The device may then be accessed just like any other device in
the system. For example, say we have installed a driver for our custom
high-speed I/O board as BIOS device 10, and GEMDOS name "fio", then:
Bconout(10, c);
would send a character to the device, and
fd = Fopen("fio:", 2);
opens the device for read/write, and returns a GEMDOS handle in fd
that can be used in any GEMDOS I/O call that uses handles:
Fread(fd, count, buf);
Reads 'count' bytes (normally using a line editing mechanism but this
can be changed by using the Fcntrl call). Likewise:
Fwrite(fd, count, buf);
writes to the port. The following calls would redirect the standard I/O
handles to the special device and then execute a program:
Fforce(0, fd);
Fforce(1, fd);
Pexec(0, "shell.prg", tail, env);
This would cause the program "shell.prg" to send it's output to the special
device and read its input from the special device without recompiling.
A device driver may itself use BIOS calls; so one driver can access another
driver to as many levels as needed.
As can be seen, the installable device driver facility is one of the most
powerful and flexible features of Micro RTX.
SUMMARY
Micro RTX is the result of more than two years of reasearch and development.
This is not a fly-by-night "hack" to standard TOS. It isn't a simple
scheduler on top of TOS like some of the systems I have seen are.
When looking at multitasking kernels that work with TOS programs,
remember there's more to it than just adding a time-slicer. The regular
GEMDOS/BIOS handlers are NOT reentrant. The GEMDOS loader doesn't
know how to deal with more than one process family (tree). It holds
the running PID in a static variable. The multitasking kernel must
perform all program loading, exec'ing, and memory allocation, otherwise
TOS will get very confused, usually resulting in crashes and/or trashed
files.
MICRO RTX DEVELOPER KIT $250
Includes:
- Master copy of Micro RTX on diskette
- Micro RTX binary license
- Programmer's Manual
- One year warranty including: bug fixes, minor upgrades,
and telephone support
BECKEMEYER DEVELOPMENT TOOLS
478 Santa Clara Ave.
Oakland, CA 94610
(415) 452-1129
BBS: (415) 452-4792 (login as 'bbs')
CIS: 74236,625
BIX: join beckemeyer
UUCP: ...!ihnp4!hoptoad!bdt!david
Disclaimer: I have to be biased or my wife hollers at me!
--
David Beckemeyer | "To understand ranch lingo all yuh
Beckemeyer Development Tools | have to do is to know in advance what
478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay
UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"ttims@watdcsu.waterloo.edu (Tracy Tims) (03/08/88)
Your RTX system sounds really, really nice. (I wrote my own mini message passing kernel for the Atari, but it has only a small fraction of the power of yours.) So, considering that it exists, and that it sounds like it's in good taste, technically speaking: Why isn't Atari licensing it from you and distributing it with all their machines? It sounds like a better software system than they will ever be able to design and distribute. Are they holding out because they think they can do better? Is their management unable to appreciate the future marketing value of a message passing multitasking operating system (especially in a networked environment)? Are they simply unaware of it? Do they take the point of view (regrettably common) that they can do economically better by producing a poor product for less money? Would you accept a binary licensing fee of say, 15 dollars (US) per copy for distribution with every Atari ST? If Atari was willing to simply pass this fee onto each consumer by raising the system cost by 15 dollars would this impact hardware sales in a meaningful way? (What would be a more optimal licensing fee?) Consumers, would you pay 15 dollars more for an Atari with RTX built in? If it was distributed (and became the new Atari operating system standard) would this encourage more sophisticated software development for the machine, and would this increase the market for the hardware (and for the RTX)? Is it possible that RTX could add more reliability to stock TOS? *If* your RTX would port nicely to a system with an MMU, I'd say it sounds like it could be the software salvation of TOS and the whole ST line. I don't think there are any medium term prospects for personal computers that are not addressing the memory protection/multitasking/software reliability problems. The only primitive operating system that will survive will be MSDOS. The workstation manufacturers are showing cheaper and cheaper products that have worlds more functionality and reliability that current personal computers. More and more people are coming to understand the value of these types of machines and (like me) will demand that value in their personal computers. There will be two choices for decent operating systems: UNIX, and anything else that implements the minimum technical niceties. I'm not saying that UNIX is the best, or even desirable. It exists, and it can be ported and it can work. The biggest obstacle to the popular acceptance of UNIX systems (with windowing) is the high, high cost of the application and system software. There is good application software out there for workstations: it would never sell in the mass market unless the prices dropped by a factor of 10. It's in this niche that "other decent operating systems" will fit. With foresight and planning, cheaper operating systems and software could be highly competitive (in terms of price/(functionality+reliability)) with more sophisticated workstations. Apple seems to have no problem understanding this. Foresight and planning means the development of RELIABLE and SECURE hardware and software. I think there is a better chance (technically) that the Atari could evolve into the budget workstation that the Apple. The Atari hardware and software is less crufty and cast-in-concrete than Mac hardware and software. (This is mostly because the software is more loosely organized, and because the hardware is cleaner.) It think it would be very difficult to produce a Mac which one could leave turned on for large periods of time, and do useful work on, without being worried about memory corruption. I think that with intelligence and taste, TOS (with RTX?) could be made to operate reliably in a memory protected environment. Reliability and functionality are the two things which sell machines. A user needs *both* to get work done. Tracy Tims
hase@netmbx.UUCP (Hartmut Semken) (03/11/88)
In article <4518@watdcsu.waterloo.edu> ttims@watdcsu.waterloo.edu (Tracy Tims) writes: >Your RTX system sounds really, really nice. (I wrote my own mini message It is, I think. David: is MTCShell based on RTX in some way? A friend of mine is using MTC Shell and likes it. > Why isn't Atari licensing it from you and distributing it > with all their machines? I don't know. I would like it. I would really like it if it would be komfortable. Komforteble is something when you can switch it off. > >It sounds like a better software system than they will ever be able to design >and distribute. Are they holding out because they think they can do better? I think, they could do better; But software development is expensive in both, time and money. Support of software is even more expensive. Right? hase -- Hartmut Semken, Berlin (West) (*east of West-Germany :-) hase@netmbx.UUCP I think, you may be right in what I think you're thinking. (Douglas Adams)
david@bdt.UUCP (David Beckemeyer) (03/15/88)
In article <4518@watdcsu.waterloo.edu> ttims@watdcsu.waterloo.edu (Tracy Tims) writes: >Your RTX system sounds really, really nice. (I wrote my own mini message >passing kernel for the Atari, but it has only a small fraction of the power >of yours.) > >So, considering that it exists, and that it sounds like it's in good taste, >technically speaking: > > Why isn't Atari licensing it from you and distributing it > with all their machines? Good question. I'm sorry but I don't have the answer. It seems to make perfectly goo dbusiness sense to me. >Would you accept a binary licensing fee of say, 15 dollars (US) per copy for >distribution with every Atari ST? If Atari was willing to simply pass this >fee onto each consumer by raising the system cost by 15 dollars would this >impact hardware sales in a meaningful way? (What would be a more optimal >licensing fee?) Consumers, would you pay 15 dollars more for an Atari with >RTX built in? Guess what. The offical published binary re-distribution fee for Micro RTX is even less - just $10 per copy! This is supposed to be per-product, but theoretically (and legitimately) Atari could develop a simple application that used RTX (hello world for that matter) and distribute it with every ST for just $10 per copy royalty! >If it was distributed (and became the new Atari operating system standard) >would this encourage more sophisticated software development for the machine, >and would this increase the market for the hardware (and for the RTX)? Is >it possible that RTX could add more reliability to stock TOS? Well we have developed large multi-user business applications based on RTX. These systems run multi-user 24 hrs. a day. The internal architecture of these systems is pretty sophisticated: several communicating processes, network and file-system servers, multiplexing device drivers, protocol drivers, hundreds of files open simultaneousaly (try that with plain old TOS!). Once the software is debugged, they simply don't crash, even with hundreds of messages flying around between CPUs, and lot's of disk activity. It is possible to crash a system that has no hardware protection if you try; but it is also possible to develop highly robust, reliable, sophisticated software applications with RTX. I know becuase I have done it! It works. Anybody that says that it cannot be done is either inept or lying. With regular TOS we can't even run our system single-user, becuase TOS has problems handling the number of files, and has memory allocation problems. When we run under RTX the problems go away. RTX can, of course, present new problems to programs that were poorly designed. For example, sometimes programs "over-ride" TOS to overcome bugs, and these types of programs may have problems with RTX. But with RTX the system calls work, and there's more of them, so you can produce "clean" reliable applications. -- David Beckemeyer | "To understand ranch lingo all yuh Beckemeyer Development Tools | have to do is to know in advance what 478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"
rosenkra@Alliant.COM (Bill Rosenkranz) (03/16/88)
--------- why couldn't atari add RTX to what they are already planning to do (which sounds to me like a reasonably radical change to the roms [radical for atari, anyway])? just how serious is atari in actually soliciting their user's input in s/w upgrades? though incorporating rtx would probably be non-trivial, it certainly would be nice and guess what? no more amiga multitasking flames! email request to atari. -bill (amiga readers: please don't flame out. i like your machine, too. this issue is dead)