{pwd}	OS-9 versus OS-9000
	home action appnotes consultants history links os-9 al systems vendors

OS-9 versus OS-9000 by OS-9 Al

Note: This article was written several years ago. I believe it was intended to be published in the now-defunct OS-9 Users Group newsletter. While I believe the "history" elements are still as accurate today as they were then, other things are not. For instance, Microware no longer calls a product "OS-9000". Instead, all versions of the operating system are known as "OS-9". There have also been many more ports of OS-9 done than this article implies. So, treat it like it is: an old article. :-)

Historically, OS-9 has roots as far back as 1977. The environment we are now familiar with originated around 1980. Originally conceived as an operating system for the “next generation” Motorola 6809 processor, OS-9 has evolved to the 680X0 family of processors giving capabilities never possible under the 8-bit architecture of the original chip.

In an attempt to make OS-9 more portable, it was recoded in ‘C’ and named OS-9000. This was made available for the Intel 386 and Motorola 68020 and above processors. (ed note: the ‘020 version is no longer produced.)

With the creation of the PowerPC family of processors, Microware wanted OS-9 to run on them as well. Instead of porting assembly to the new RISC chips, Microware took a more flexible approach and ported OS-9000. This gives us OS-9, generally referring to the 68K version, and OS-9000 which can either be Intel or PPC. Actually, the current naming convention seems to be “OS-9 for 386” or “OS-9 for PPC”. Don’t let the name change confuse you though - OS-9000 is not OS-9. While externally very similar, internal differences do exist.

NOTE: The comments in this article are based on experience with the 386 version of OS-9000 v1.4. Version 2.0 (the first version for PowerPC) has not been used by this author so there may be changes not mentioned here.

OS-9000, since it was being rewritten and didn’t have any existing platforms to maintain compatibility with, added enhancements. Simple things like moving the bitmap location of the file structure (the RBF file manager) to improve performance, and adding extra fields to show file modification down to the second (OS-9 only tracks hours and minutes). Also, OS-9 has a limit for file attributes where only two sets exist: public and group/owner. This means any user in the same group as yourself can still read or write any file you create. The only way to prevent this is make each user in his own group. Under OS-9000, public, group, and owner have their own sets of attributes (read, write, execute) eliminating this. Also, directories have a “searchable” attribute allowing users to search a directory for files they may access, without actually being able to read or write to the directory itself (similar to Unix). These many improvements have the side effect of making OS-9000 disk formats incompatible with native OS-9. Fortunately, Microware provides two methods of transferring files over - utilities that run under OS-9000 which will read OS-9 disks, or the PCF PC-DOS file manager, allowing the use of PC disk formats which between any OS-9(000) system, PCs, Macintosh, Atari ST, Amigas, and other systems that support it.

Another interesting addition to OS-9000 is an extra “state” a process can be in. Modes such as ACTIVE (currently running), SLEEPING (waiting for a time to elapse or signal to come in), and WAITING (for a child process to terminate) are familiar, but OS-9000 allows you to SUSPEND any process temporarily, removing it from the active process queues, then resume it later on. Commands are provided to do this from the shell.

Speaking of the shell, OS-9000’s stock shell has some enhancements of it’s own, like the ability to not only pipe standard out of one program to the standard in of another ( $prog1 ! prog2 ), but standard error as well ( $prog1 !! prog2). Several other enhancements also exist to make recalling previous commands easier. Command line editing is also fancier thanks to additions to other i/o components such as the SCF sequential character file manager.

Instead of just being able to reprint or delete a previously typed line, OS-9000 allows you to do many things such as delete left word, delete right word, delete to end of line, insert/overstrike, and others. These features are automatically available when using the “readln” system call making fancy input routines a snap. All features can be disabled or toggled using a much more powerful version of the tmode utility.

Some performance enhancements have also been made. When OS-9 performs a “read”, it calls the driver for each character. Thus, reading 80 bytes from a serial port invokes the driver 80 times. Under OS-9000, SCF maintains both input and output buffers so system level reads and writes are taken directly from that buffer. The driver simply stores incoming data in the SCF buffers, usually from within an interrupt service routine. This seems to offer performance improvements as well as simplifying driver creation.

Since OS-9000 was written in ‘C’, it makes it much easier to talk to the kernel. With OS-9, you are expected to return certain status flags set in various registers when returning to the kernel (from a driver or interrupt service routine, for example). This requires you to either write your code entirely in assembly, or use “glue code” which takes something like “return SUCCESS” in C then sets the appropriate carry bit of the status register and issues an RTS back to the kernel. Under OS-9000, drivers can be created without this glue code, making them much easier to put together from scratch.

Speaking of the C language, many have said OS-9000 must be much larger and slower since it is written in a high level language. This is not entirely true. The OS-9000 kernel for 386 is about 50K, which, while it’s nearly twice the size of the OS-9 kernel, is still very small. Even PC-DOS’ COMMAND.COM is larger. Also, since OS-9000 is targeted on higher end processors such as 486/Pentium or PowerPC, optimizations at the chip level make it incredibly fast, needing something like a high-end 68040 or 060 to see similar performance from OS-9. Certainly a native assembly version of OS-9 for PPC would be very nice, but the extra convenience of being able to talk to the kernel directly in C (without extra glue code) is an easy tradeoff. Besides, how many people do you know who code PowerPC RISC assembly? (The architecture was designed to be more compiler friendly than hand-assembler friendly.)

OS-9000 also can address larger hard drives than the 4-gig “limit” of OS-9. Perhaps not entirely important today, but certainly significant in the near future when these drives become commonplace.

There are many more internal differences between OS-9 and OS-9000, yet from the C source code level most applications can be recompiled without any problems. Thanks to compatibility libraries, standard source code can be maintained without requiring significant recoding. Careful programming allows common sources to be compiled under OS-9 Level 2 (6809, pre-ANSI compiler), OS-9/68000 2.4 (K&R 3.2 compiler), as well as OS-9000/386 1.4 (Ultra-C).

Some system calls are different though and do require changes (most of the time having to do with OS-9000 allowing many extra parameters or options). For instance, under OS-9 the _os9_sleep() call for Ultra-C takes one parameter - the pointer to an integer containing the amount of time to sleep for. Under OS-9000, there is an _os_sleep() that works similarly, but contains an extra pointer to a signal code which will contain the signal that wakes you from the sleep, if any occur. Many other “blocking” wait type calls also contain signal references. Another large difference is that OS-9000 allows you much greater control over what regions (“colors”) of memory you allocate processes, events, modules, etc., from. Most all OS-9 calls, by comparison, are taken from general User Ram (primary system memory).

Another improvement, which is great for multi-user systems, is the improved module directory structure. Under OS-9, all modules go in a flat directory meaning there can be only one copy of a module of any given name in memory at a time. OS-9000 allows module sub-directories. This allows different modules to exist with the same name as long as they are in different module directories. There are utilities provided to make and delete module directories, and also a module PATH environment variable so different mdirs can be searched for commands.

Many system utilities now work differently or have more options. The format command lets you customize virtually any setting of the disk you are about to format without needing to reconfigure the drive descriptor. Xmode also seems to work quite differently under OS-9000 which may cause confusion to OS-9 users migrating over. Some other useful utilities, such as moded are not available for OS-9000, but several others not for OS-9 are, such as a command that print out system information (from the init module).

Many existing companies also provide OS-9000 support. Gespac makes tiny 386 boards with graphics that also run their 386 version of G-Windows, a GUI also available for OS-9/68K. The public domain market has also provided ports of utilities such as LHA (compression) and the popular dEd (disk editor). Ftp sites such as os9archive.rtsi.com include subdirectories containing extra resources, and the OS-9 Users Group is currently compiling a library of shareware software for distribution to club members as well.

A major upgrade for OS-9000 was also recently announced. Version 2.0 includes even more enhancements as well as the introduction of the PowerPC version. It has been reported that the x86 version has been upgraded as well to be as similar as possible to the PPC. At the time this article as written, no further details of this were known (though Microware would probably make a great source to ask).

When it comes to product maturity, OS-9000 is still about half as old as it’s older brother. It seems that in the past OS-9000 was more of a side product for Microware, but this is with all the new energy being directed towards the PowerPC platform. However, if support or stability has been an issue with not using OS-9000 in the past, it may be time to look again. There are some exciting things going on. Also, a desktop PC makes a very low cost but powerful development system for code, including a great way to compile and test OS-9 programs. Let engineers use the computers they already work with, then use a target resident compiler on the 68K machine to recompile the sources that were created on the PCs (or use Ultra-C’s optional cross compiler to make the 68K executables directly under OS-9000).

In summary, OS-9000 is much more than just “OS-9 in C”. It is enhanced internally while still allowing external operations to be functionally the same as OS-9. With more high end processors becoming available, and memory becoming cheaper, the days of the small assembly 28K kernels may no longer be necessary.

References:

• .

Comments:

• Did you find this article useful?

home action appnotes consultants history links os-9 al systems vendors

Site contents © 2001-2002 by Allen Huffman. OS-9 and all related trademarks belong to Microware Systems Corporation (or, I guess, RadiSys since they now own Microware). This site has no affiliation with Microware (or RadiSys). While I would like to think that every bit of information on this site is accurate, most likely there are many errors. If you need official information about anything discussed here, go to the manufacturer. I'm just an end user who enjoys the product. Peace.