TDOS2.WS4
---------
- "The TurboDOS Operating System"
Keith Bierman
ACM SIGSMALL Newsletter, Vol.10, No.3, August 1984, p.24
(Retyped by Emmanuel ROCHE.)
Abstract
--------
A commercially available multi-microcomputer system is described. Facilities
and features are described from a user's standpoint. Several research problems
are proposed.
Description (User's viewpoint)
------------------------------
Aside from a few minor inconsistencies, TurboDOS is indistinguishable from
several implementations of CP/M. The user interface is nearly identical, and
most CP/M SVCs (SuperVisor Calls) are honored.
The differences may be summarized as follows:
1) There are NO "built-in" commands, i.e., all facilities are COM(mand)
files. There are no exceptions.
2) Analogues of the familiar CP/M utilities are provided (but their
syntax is somewhat different).
3) There are many more SVCs (approximately 100 system defined); most CP/M
and MP/M-II SVCs are simulated (although some serve no useful
purpose). The minor differences do preclude the usage of popular
public-domain disk utilities, like FINDBAD and DU. TurboDOS utilities
exist to provide most, but not all, of these services.
4) Although it is possible to run a single-user version of TurboDOS,
nearly all useful systems have more than one Z-80. TurboDOS was
designed to be a multi-user OS, each user having its own dedicated
processor.
5) (logical) Disk drives may be as large as 1,000 MB, but files (random
access) are limited to 134 MB. Many implementations do not rely on
"system tracks": these may then be used for regular data storage.
These implementations automatically detect (and reconfigure for) a
standard CP/M disk, thus full media compatibility is ensured.
6) LRU buffer techniques are employed (now available in CP/M Plus), and
hashed disk directories are optional.
7) TurboDOS is designed to handle 16 print queues, each of which may have
a printer attached.
8) Files in user area 0 may be declared "global": these may be accessed
from any user area. This feature extends to user area 0 on both the
default drive and on the system drive (whichever drive one booted up
on).
9) Users may be privileged. If a user is not privileged, several BDOS
functions will not operate (Set User Number, for example). In TurboDOS
terms, all CP/M users are privileged.
Description (system viewpoint)
------------------------------
TurboDOS is a networking replacement for CP/M 2.2-MP/M-II. Between 2 and 255
processors may be interconnected; in what TurboDOS denotes as nodes. Each node
may have its own circuit, with up to 255 processors. Nodes communicate with
each other; circuit elements communicate with their own node only (though
messages can be forwarded). No special requirements are placed on the
communications channel(s): it may take any form (however, code for it must be
supplied by the system integrator). Each processor may have its own I/O
devices, or rely on the network (this includes printers, mass storage devices,
modems, or whatever). System topology is not constrained, although most
current implementations are simple master/slave arrangements, provisions (are
said to) have been made for complex star, ring, and other hierarchical
networks.
The vast majority of (CP/M) application/development tools run without
modification. The only programs that do not port well are those that skip the
BDOS and dive right into the BIOS or, worse yet, overwrite parts of it. These
programs, though few in number, do include some of the best CP/M tools (like
Nick Hammond's SmartKey (allows arbitrary key redefinitions), SmartPrint
(applies the same to output routed to the printer), SPOOL (intercepts output
going to any CP/M logical device), and UNSPOOL (background print utility)).
Also, extended SUBMIT programs do not work (TurboDOS's equivalent, the DO
construct, is roughly the same as SUBMIT + XSUB, with the addition of
nesting). All other languages, packages, etc. work without (significant)
modification (although some, like database programs, are more effective with
record locking).
As mentioned before, most current implementations are simple master/slave set-
ups. The 8-bit restriction may be removed soon, a major TurboDOS OEM, MuSYS,
has announced an 8086 version. Our system (currently) consists of a Z80A,
2xZ80B, 2xDSDD 8" floppies, 1x256K PION ramdisk emulator (medium-speed RAM)
and a couple of printers and terminals. The system has proved to be quite
reliable. All of the boards were manufactured by Advanced Digital Corporation,
who configured TurboDOS for their boards. Our dealer, Ingrid's Computers, has
had great success with a Remote Telecommunications System based on a pair of
Z80Bs running TurboDOS. Competing products use much more powerful processors
(16- or 32-bit) and/or much custom hardware. This provides Ingrid's Computers
with a non-trivial cost advantage.
At the recent SIGPC/SIGSMALL conference, G. Clapp analyzed CP/NET, carefully
putting its structure in terms of the ISO reference model. It is with regret
that I cannot do the same for TurboDOS. (If anyone is clever enough to do
this, please send me a copy.) Contrary to a view stated at the conference,
TurboDOS source code is not available. It is claimed that it is all written in
Z-80 assembly code, and utilizes all of the special Z-80 features. What is
available is the source code for all of the interface modules. These, taken as
a group, are roughly equivalent to the BIOS and SNIOS of CP/NET fame. Thus,
even the end-user can transport the OS to a different Z-80 board, or
reconfigure an old one. In fact, this procedure is easier under TurboDOS than
CP/M. Perhaps this can best be explained via an illustration:
Suppose we want to add a new type of drive. First, we would examine one of the
provided drivers. We note that, aside from a few minor differences, it
resembles the logic that we would have had to install in CP/M, except that all
the logic refering to a type of drive goes into a single module (object-
oriented programming style). (Thus, some of the sneaky optimizations common in
some CP/M BIOSes are not possible (code sharing), but installation (and
debugging) are easier.) This module is then processed with a relocating
assembler, the output REL file must be in Microsoft format (a utility to
convert from Phoenix Software Associates (PSA) format to Microsoft's is
included.) All that remains is the fairly simple SYSGEN procedure.
To SYSGEN the system, two files are prepared: (1) a list of all relocatable
modules to include, and (2) a file consisting of symbolic patches. Then, a
SUBMIT job is run, and new system load modules are output.
Thus, TurboDOS has (in one sense) two parts: the physsical interface (supplied
by the hardware distributor or by the user), and the logical internals (whose
structure is not obvious).
The following research topics are suggested from reading (read: "decrypting,
deciphering, and translating") the TurboDOS manuals.
Research Topic #1
A useful user manual could/should be developed. Many features of TurboDOS go
underutilized (or totally ignored) due to the difficulty in deciphering the
manuals. Since much of the material for a manual would have to be obtained via
experimentation with the system, this would be a good class project.
Research Topic #2
TurboDOS should be able to handle a wide variety of network topologies,
several should be set up and analyzed. In theory, one could have 254 slaves
and one master in each circuit (and 255 circuits). It is rather obvious that a
conventional Z-80 (even running at 8-MHz) could not service such a large
number of processors! Based on our experience with 2 users, 3 processors, 8"
floppies, and a RAMdisk emulator, I would speculate that a 6-MHz master (with
a high-speed hard disk) could comfortably handle 4 disk-intensive users, or 8
less (disk) demanding users. Thus, a large network might optimally be built up
by interconnecting these clusters (up to 255 of them, in fact). Confirmation
of this hypothesis would be of interest. (This arrangement would have the
additional advantage of being very fault tolerant.)
Research Topic #3
TurboDOS is equipped with an (optional) LOGON/LOGOFF facility. When this
facility is enabled, a (potential) user is required to input both a user name
and password. These are checked against a file kept in user area 31.
Additional security is afforded by separating users into two categories:
privileged and non-privileged. Non-privileged users are not supposed to be
able to change user areas, thus the password file is kept safe. This system
would appear to be reasonably secure; but is it?
Note: Additional security can be arranged by clever network topology. Since
local processors (or clusters) may have their own drives, if these are not
installed in the rest of the network, they cannot be accessed at all! It would
appear that this system could be more secure than many mainframes.
Research Topic #4
For those interested in experimenting with parallel processing, TurboDOS may
offer an easy (and cheap) alternative to special dedicated hardware. TurboDOS
has a special file type, the FIFO (the contents of a FIFO may optionally
reside in RAM). If we allocate one processor per co-routine, they can
communicate via FIFOs. This allows a dynamically redefinable set of
relationships. Although it is conceivable that 255 such could be
interconnected, it would seem that a very high data transfer rate would be
required. Thus, a practical limit might be the number of processors that could
share the same bus (16 on the S-100). Since the system could be easily
reconfigured for "normal" operation, the cost would really be quite minimal.
Research Topic #5
There are several commercially available 8088 and 68000 "add on" boards for
the Z-80. These usually interface to CP/M. Some tinkering would be necessary
to run these under TurboDOS. (By this, I do NOT mean full integration, merely
give one user a co-processor (with its own OS) that will interface to the
world via TurboDOS. The other problem is much harder.)
Research Topic #6
At many sites, a large mini or a mainframe is already present. For these
sites, it might be handy to have the larger system emulate TurboDOS, providing
high-speed printers, large mass storage devices, etc.
A second stage would be the addition of user log on to the host system (could
be automated, but at the expense of some security). Some utility to convert
different file formats might be necessary.
A third stage would be the creation (or adaptation) of a commonly-used
compiler (Pascal, C, or ?) to run on both machines, but the output of the Z-80
version would (optionally) be object code for the host. It is generally felt
that system performance can be increased by removing as many tasks as
possible. By offloading compilation and editing, the host's performance should
be improved (especially in development environments, with many small
compilations).
Research Topic #7
There is much interest in concurrent processing (read "windows"). Most of the
systems that support this well (Xerox, Sun, Three Rivers, Lisa) are quite
expensive. If we were to restrict each user to a fixed number of windows, it
would be easy to tie several Z-80s together, one for each window. A graphics
board (some are now available for about $1,000 that have resolution of
1000x1000) and one of the Z-80s would be used to control the system (sounds
like one of the clusters from above, not?). Of course, this would mandate
special software but, aside from the graphics board (and monitor, and
mouse/joystick/trackball?), all of the hardware would be already present.
Unlike single CPU systems, no special effort would be needed to provide data
security, since none of the processors can access the memory of another (of
course, this does noe allow most efficient use of memory, but that has not
stopped Intel/IBM either).
Compared to other Multi-User (micro) OSes
-----------------------------------------
Compared to MP/M, TurboDOS is superior in nearly every respect. TurboDOS allow
many more users, provides much faster response, larger TPA (up to 63.5KB with
Version 1.3), and prevents any single user from crashing the system (a crashed
slave is automatically reset). However, there are some versions of MP/M that
might be worth considering, like the new CompuPro system. It is an integrated
hardware-software system that dedicates a Z80B to each user. A 16-bit
processor (an 8088) is available to any user. Intra-system communication is
very fast, due to the method: shared memory. TurboDOS is, however, far more
flexible, more extensible, and does not tie the user to any particular
hardware vendor.
TurboDOS also is superior to CP/NET. CP/NET does not allow the individual
processors to have their own local storage. Thus, the only possible topology
is a ring. Consequently, a fault-tolerant system would be much harder to
build. Also worth noting is the bottleneck that this implies, system expansion
(and performance) is tightly bound up with the capabilities of the server
(currently, MP/M seems to be the only existing server, a limited system at
best). It is rumored (I read it in Jerry Pournelle's column in Byte) that
Digital Research is not going to support CP/NET any longer, but will have a
successor "Real Soon Now". (ROCHE> DR-Net, which is compatible with CP/NET
Version 1.2, so that 8-bit and 16-bit computers can exchange files.)
Although every computer enthusiast wants to trade up to the latest, most
powerful chip, it is often not practical. Currently, there exists a large body
of high-quality 8080/Z-80 software. Furthermore, many applications are well
served by these devices. Given suitable mass storage facilities (RAMdisk
emulators for speed, and large Winchesters for size), there is no good reason,
for most applications, to be moved up to a larger (more expensive) processor.
When comparing costs, one should also note that many of the application
programs that are available on both 8- and 16-bit devices require more memory
(to provide the same functionality) than when in an 8-bit environment.
(WordStar on the IBM and on a Z-80, for example. On the IBM, 128K are
required. On a Z-80, less than 64K. Running a Z-80 at 6-MHz, we have noticed
little, if any, speed advantage when trying the PC, though we have not
performed any formal comparisons. Others have reported significantly slower
times on the PC. Appendix A contains some timing information that may be of
interest.) Another (common) argument for upgrading is the desire for multi-
tasking. While multi-tasking is a very good thing, it is not clear whether it
can best be achieved by multiple processors or by more powerful single
processors; only time will tell. Worse yet, the more powerful processor is
often drafted into use as a multi-user system (often to justify its higher
cost). All of us have known times (often most of the time) when our mainframe
facility offers poorer response time than a Apple! It is not that the Apple is
more powerful, but that the mainframe has too many users. Let us not rush
blindly ahead, just to retrace the development of the mainframe!
Recently, many papers (and commercial products) have described LANs for use
with (read: "requiring") 16-bit devices. While many of these systems are quite
powerful, it is not clear that they offer significantly more functionality
than a TurboDOS network. There are several currently available database
managers for the Z-80 that do not place many restrictions of the size of the
database (Sensible Solution, Qpro IV, etc.). Since TurboDOS allows single
files to be 134MB (larger than most of the current crop of disk drives), it
would appear that the class of problems that require a 16-bit processor may
not be quite as large as expected (though a more powerful machine is almost
always easier to program).
Clearly, there are applications (most "scientific" programming, for example)
that require large memory spaces, hardware arithmetic, etc. These tasks are
beyond the Z-80, as it is currently constituted (the Z-800 might change this.
(ROCHE> Zilog never managed to produce it. It was the end of CP/M.)) For these
applications, a Z-80-based LAN is certainly not indicated, systems
incorporating virtual memory, 64-bit arithmetic and the like would be more
appropriate. It is worth noting, however, that there are Z-80 products that
use virtual memory techniques (several of the better spreadsheets and an APL
interpreter spring to mind). Now, if someone would write a FORTRAN-77 (not the
subset) with virtual memory for the Z-80, we would really have a hot system,
programs up to 1,000MB!?!
Weak points
-----------
In the words of a great sage: TANSTAAFL (there ain't no such thing as a free
lunch). TurboDOS does have its problems:
1) As noted above, the manuals are indescridably bad.
2) Since the system was written entirely in Z-80 assembly language,
porting it to new processors is a big task, nearly as big as the
original program (and will entail just as long a debugging cycle).
Thus, (full) support for 16-bit processors is likely to be slow (and
may have to wait for the Z-800).
3) While the $750 licensing fee may seem trivial when spread over 255
users ($0.12 each), this is not the case. The licensing agreement
clearly states that "A separate license fee must be paid and a
separate license signed for each computer system on which TurboDOS is
used. Network slave computers which are also capable of stand-alone
operation under TurboDOS must each be licensed separately, but slave
computers which cannot be used stand-alone (e.g. because they have no
mass storage) do not." Despite this, TurboDOS is still cheaper than
most of the alternatives (especially writing a new system).
4) It does not appear to be possible to assign priorities to different
users. Output is spooled on a FIFO basis, so is disk access. This
means that background tasks demand more resources than might otherwise
be necessary.
5) There is no provision for spooling console output. This is a serious
omission, since the output of background processors will be lost. (A
rewrite of the console module could fix this).
6) There is no provision for time/date stamping of disk files. This
complicates life, more than a little.
7) Since there is no SAVE command, DDT, SID, ZSID, et al. are somewhat
crippled (make any changes you want, you just can't save them!).
(ROCHE> Under CP/M Plus, SID and ZSID have been provided with a SAVE
command.)
8) Since all TurboDOS functions are disk-resident, at least one disk must
be both fast and large. Although it is possible to run a system
exclusively with floppy disk drives, it is not recommended.
Conclusions
-----------
TurboDOS provides a good basis for both "simple" LAN applications, and for
advanced research topics, since TurboDOS requires only inexpensive Z-80
microprocessors, yet offers great flexibility. Thus, it is an obvious
candidate for both commercial and research applications.
For more information
--------------------
1) TurboDos User's Group
PO Box 27550
San Francisco, CA 94127
This group is forming, and has not yet published its first newsletter.
2) Ingrid's Computers
22458 Ventura Blvd., Suite E.
Woodland Hills, CA 91364
Manufacter and system integrator, very helpful.
3) MySYS Corp.
1752 Langley
Irvine, CA 92714
Largest TurboDOS distributor. Currently advertising bank-switched and
16-bit versions (slaves only).
4) Advanced Digital Corporation
5432 Production Drive
Huntington Beach, CA 92649
Manufacter of board-level computers.
Acknowledgements:
-----------------
Special thanks to Phil Ericson whose help has always been invaluable.
TurboDOS is a product of Software 2000, Inc.
MP/M, CP/M, and CP/NET are products of Digital Research, Inc.
SmartKey is a trademark of FBN Software, Inc.
Appendix A: TurboDOS timing information
---------------------------------------
Most microcomputer benchmarks rely on a variety of benchmark programs while,
in the mainframe community, timing information is (often) given on a per-
operation basis. It was not difficult to add some additional logic to the
TurboDOS clock module. This logic allowed times to be measured in 183th of a
second. The following times refer to Microsoft's FORTRAN-80.
4,409.638 +/sec (real+real)
2,846.034 -/sec (real-real)
1,620.903 */sec (real*real)
761.865 //sec (real/real)
117.912 sqrt/sec (sqrt(real))
455.450 **/sec (real**int)
59.495 **/sec (real**real)
Each operation was performed 10,000 times, via a DO loop, the loop overhead
(calculated first) was subtracted, and the result was converted to ops/sec
(from ops/183rd sec).
Double precision
----------------
2,259.2593 +/sec (double+double)
1,591.3044 -/sec (double-double)
476.5625 */sec (double*double)
74.9693 //sec (double/double)
10.1757 sqrt/sec (sqrt(double))
5.9215636 **/sec (double**int)
6.0236998 **/sec (double**double)
Each operation was performed 1,000 times, via a DO loop, the loop overhead
(calculated, above). It is interesting (and somewhat puzzling) that
double**double runs faster than double**int.
Sieve test (as published in Byte)
---------------------------------
TurboDOS running on a 6-MHz Z-80.
Timing done via the "traditional" method, checking Time of Day before and
after. I assumed (perhaps incorrectly) that the article times were obtained by
running some sort of TOD program after termination of the sieve. These times
represent the time to terminate (TOD), load (sieve), compute, print,
terminate, load the TOD program, execute the TOD, and finally print TOD.
C/80 3.0 18 sec
Software Toolworks RATFOR 17 sec
Neither of these were optimized in any way. The RATFOR version used only the
FOR construct, thus was operating under a handicap (DO loops are faster). A
FORTRAN version was run by Jim Gilbreath (author of the original Byte article,
"A High-Level Language Benchmark", Sept. 1981), who obtained a time of 17.0
seconds on a 4-MHz Z-80. The same author published a time of 13.9 seconds,
again on a 4-MHz Z-80, using an improved implementation. Implementation
details (obviously) count.
Times reported for the 8086/8088 family range from 205 seconds (BASIC) to 1.90
(8-MHz 8086 assembly). Most, however, run slower than the Z-80 times. Many
other benchmarks can (and should) be used for comparing different processors.
Informal testing (running the same package, like WordStar, on both machines)
indicates that a 6-MHz TurboDOS system runs roughly 20% faster than an IBM PC.
Such benchmarks seem to be a better test of a language (or application
program) implementation than raw machine power. Users who are only concerned
with how fast their favorite package can run should simply try both systems.
Interested readers should note that much of TurboDOS's performance is due to
sophisticated buffer management. There is no reason to believe that use of
such techniques would not speed up the PC considerably.
More work needs to be done, both in benchmarking the systems and improving
existing applications (and languages), to make full use of machine
architecture. The Z-80, having been around longer, has a more mature software
base, and such optimizations are already embedded in existing systems. Thus,
one can expect (hope?) that 8088 systems will improve with age.
EOF