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 Zilog Z-80 CPU.  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 Intel 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
Zilog  Z-80 assembly code, and utilizes all of the special Z-80 CPU  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 Zilog 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  referring 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 physical 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  Zilog Z-80 CPU (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 Intel 8088 and Motorola  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
Zilog  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 Zilog Z-80 CPUs 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-80 CPUs 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 not 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 Zilog Z80B CPU to each user. A  16-
bit  processor  (an  Intel  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  Intel  8080  /  Zilog  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  Zilog Z-80 CPU, as it is currently constituted (the  Zilog  Z-800
might  change this. (ROCHE> Zilog never managed to produce it. It was the  end
of  CP/M.))  For these applications, a Zilog 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 indescribably bad.

     2) Since the system was written entirely in Zilog 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 Zilog 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 Zilog  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

        Manufacturer and system integrator, very helpful.


     3) MuSYS 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.


Acknowledgments:
----------------

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 Zilog Z-80 CPU.

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 Zilog Z-80 CPU. The same author published a time  of  13.9
seconds,  again  on  a  4-MHz Z-80  CPU,  using  an  improved  implementation.
Implementation details (obviously) count.

Times  reported for the Intel 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 Zilog Z-80 CPU, 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 Intel 8088 systems  will  improve
with age.


EOF