- "Good Old TurboDOS"
  Ron Yuen
  "Journal" of the CP/M User Group (UK), Vol.2, No.7, December 1985, p.108

(Retyped by Emmanuel ROCHE.)

"...  about  the only operating system with any  serious  pretensions  towards
networking..." (Vol.2, No.5, p.26)

(ROCHE>  TurboDOS  is a multi-processor version of MP/M-II  with  CP/NET,  the
multi-user,  multi-tasking,  networking  version of  CP/M.  However,  as  this
article shows, most persons knew only CP/M 2.2, not MP/M-II. So, they did  not
realise, at the time, that a much more sophisticated version of CP/M  existed,
which was already networking with CP/NET, long before the IBM PC...)

Networking is a system for linking more-or-less stand-alone micros of more-or-
less varying types with bits of wires, brown paper and string, which is why so
many networks either don't work, are sooooo slow, or fall over every time  the
brown  paper  comes unstruck. However, help is at hand, in fact has  been  for
ages but not many people have noticed.

TurboDOS  is  a network operating system which  replaces  the  afore-mentioned
brown  paper and string with some fairly decent and robust software which,  on
the  right hardware, with a good implementation, can be made to do  some  very
impressive  things. Here are some of the main features of a  typical  TurboDOS
implementation (e.g., HM Systems 'Minstrel' computer):

      - Master/Slave configuration closely coupled in a single box on an S-100
      - Up to 16 printers, 16 queues, and 16 disc drives.
      - Indiscriminate mix/match of 8/16-bit masters/slaves.
      - Supports 32 CP/M-style 'User Areas'.
      - ARCnet interface to PCs and/or Apricots (and others).
      - Enables  one  copy of COM/CMD files to be globally  available  to  all
      - Enables almost any CP/M program to be run in a 'semi-multi-user'  mode
        (explanation later).
      - Provides MS-DOS/PC DOS emulation (could do better).
      - Can operate as a true multi-user computer, as well as a network.
      - Enables  files to be shared, exclusive, read-only, or 'permissive'  --
        normal default mode.
      - Large drive/file limits (1 GigaByte).
      - Provides for file and record locking at operating system level.
      - Provides reasonable security.
      - Provides  Relocating  Assembler (TASM), Linker (TLINK),  and  Debugger
        (TBUG) and other utilities.

It works, it has been around for a while (especially in 8-bit), it is  robust,
reliable and predictable. Which is not bad.

Masters and Slaves

A slave is a computer, either 8- or 16-bit, which sits in a slot on the  S-100
Bus  and is attached to a terminal (dumb) running at around  9600/19200  baud,
usually. Each user has a slave all to himself.

A  slave  can  do almost anything that a normal PC can do, except  it  has  no
direct  access to disc drives or network peripherals like printers (though  it
might have a local printer to itself). When a program running on a slave wants
to  access  a file, the slave passes the request automatically to  the  master
processor. The master is also a complete 8- or 16-bit computer sitting on  the
S-100  Bus, just waiting for slaves to send an interrupt and ask  for  service
but,  in  addition, it runs a host of background tasks  like  print  spooling/
despooling  simultaneously to all the systems printers (3 of which are on  the

Security and privileged users

TurboDOS  has a reasonable level of security built into the operating  system.
Anything more elaborate requires additional software.

User  Area 31 is reserved for various system files (warm boot programs,  etc),
as well as the password and logon file called USERID.SYS. This is a text  file
which  contains  a list of ID's passwords, and start-up data  for  each  user,
including information on whether the user is privileged or not. The format  is

        ID, password, User Area {P}, Disc, List of Autoexec programs.

The {P}, if present, indicates that this is a Privileged user. Such users  are
allowed to change user areas and manipulate files across user area boundaries.
Non-privileged  users  are completely restricted to their own  user  area  and
access to global files on area zero. Privileged users can also 'attach'  their
slave  to the master processor and run programs directly in the  master.  Some
programs must be so run, for example floppy disc formatting, changing the size
of  the cache memory buffers, and so on. Such attachments are  logical  rather
than  physical,  and are performed at the keyboard. Non-privileged  users  who
attempt  to  perform a reserved task will get an error  message  telling  them
(more or less politely) to p*ss off.

It follows that, if you are a privileged user, you can access the data in area
31  and look at passwords. The security system thus requires  that  privileged
users treat their logon password seriously.

System utilities

These fall into several groups:

        Control/Security:       MASTER, LOGON, LOGOFF
        System configuration:   BAUD, BAUDVDU, DATE, AUTOLOAD, BOOT
        Disc control:           FORMAT, DISK, FIXDIR, FIXMAP, LABEL
        File maintenance:       DELETE, RENAME, COPY, BACKUP, DIR, SET
        Memory maintenance:     BANK, BUFFERS
        Printer control:        PRINT, PRINTER, QUEUE
        Programming:            TASM, TLINK, TBUG, MONITOR, DUMP
        Batch processing:       DO, BATCH
        FIFO files:             FIFO, SEND, RECEIVE

The  syntax of these commands is much improved over CP/M 2.2 and owes much  to
the  influence  of  MS-DOS. Error messages are clear and  to  the  point,  and
several of the commands support switches at the command line, e.g.:

        COPY 0A:*.COM 12B: ;AEY

will  copy all COM files from user area 0 on drive A to user area 12 on  drive
B, but it will only copy files due to be archived (switch=A), will erase  them
from 0A when copied (switch=E), but will ask for Yes/No confirmation on  every
matched  filename  before  doing anything  (switch=Y).  Other  commands  allow
similar techniques.

File opening modes

Typically, TurboDOS will default to opening files in 'permissive' mode,  i.e.,
unlimited access by all users on a Read/Write basis, with the proviso that the
first  user to signal a write to the FCB maintained in the MASTER will  write-
lock the file.

A programmer can, however, simply by setting various FCB bits, open a file  in
'exclusive'  mode  -- no one else can access it (their calling  program  will,
usually, think that the file does not exist); 'shared mode' -- where  explicit
record  locking is honoured and multiple writes are allowed;  finally,  'read-
only' mode. However, the normal default mode is 'permissive'.

Permissive  mode enables unlimited simultaneous read access to the  file,  but
the  first attempt to write to the file will 'write-lock' the file.  Only  the
user  who has already written to the file can continue to do so,  attempts  by
all  other  users to write will fail and will, usually,  crash  a  single-user
applications program (SuperCalc is a notable exception).

Shared  mode enables simultaneous read/write access, and is the only  mode  in
which  record  locking  is  honoured. This mode  is  only  useful  really  for
programmers  or  for  those  (rare) applications  which  have  record  locking
programmed in.

Exclusive  mode will only allow one user access whilst the file is  open,  and
can  be  useful as part of a scheme for massaging  single-user  programs  into
multi-user file-locked programs.

Running single-user CP/M programs

I have yet to find the generic CP/M program that will not run under  TurboDOS.
Each  slave/user  would normally be logged in automatically at start-up  to  a
User  Area in which the user would maintain all local files. Files  which  are
common to all users, e.g., most program files and main databases, etc, are put
in  User Area Zero and declared (by the system manager) to be  'global'.  This
involves a utility that sets a high bit in the FCB filename, and then  enables
anyone  from any User Area to access any global file on area zero,  simply  by
asking for it. A typical session might go like this:

Come in. Switch on. Enter and 'ID code' -- usually your name (nor designed for
security)  followed, if required, by your password. Optionally, you  can  then
enter a text description of the activity to be undertaken. If the system is so
configured, then run a predefined list of programs; otherwise, you are  logged
into  your predefined User Area on your preassigned disc, and can now do  some

If you are privileged, you can change your user area; otherwise, you can  only
change logged disc drive. What faces you is something very similar to the CP/M
2.2 system prompt, but with the addition of the user number: 0A, 12B, 3C, etc.
Suppose  4 of you are logged on, 3 as non-privileged, 1 as privileged, and  on
areas  1A,  2A,  3A, and 4A (privileged), with all COM/CMD  files  in  0A  and
'global',  including  WordStar, SuperCalc, dBase, and a  multi-user  database,
e.g., DataFlex. Additionally, all database files are in 0A.

Users  1  and 2 type WS [CR] and the master processor loads a copy  of  WS.COM
into  the  2 slaves, takes a lot less time with an 8-bit master  and  4  users
active  than loading from floppies (much quicker with a 16-bit master  because
of  big cache memory, etc). Users 1 and 2 can then run WS just as though  they
were  using a stand-alone computer. The file display will reflect each  user's
own area only. However, if you have a text file on area zero 'global', then WS
will find it and can edit it from any user area. Meanwhile, in area 3 and 3, 2
users  are using dBase on a global file in area zero. Now, dBase is a  single-
user  package,  so  it is not possible, for an operating system,  to  make  it
magically  multi-user. However, TurboDOS normally defaults to  an  intelligent
method  of  handling this situation, by normally opening  files  in  so-called
'permissive' mode.

Suppose  that  the user in area 3 writes to the file: he will then  acquire  a
write-lock on the file till it is closed. Attempts by user 4 to overwrite will
fail,  and an error will be signaled back to dBase, which will be  interpreted
as  a 'disc is full' error. dBase in user area 4 will crash back to  the  'dot
prompt',  whereas  the dBase in area 3 will carry on,  undeterred.  Meanwhile,
users 1 and 2 are busy WordStarring away like mad. Master-to-slave transfer is
quick  on the 8-bit systems, *VERY* quick on the 16-bit. The slowest  mode  is
when loading whole programs into the slave, when it may take from 2-5  seconds
for  a typical CP/M application program. Once in the slave, the  program  runs
almost  as it normally would on a stand-alone hard-disc machine. Small  chunks
of data move across the bus quickly, so calling up random database records  is
very speedy.

Integration to LANs with TurboDOS

Because  TurboDOS  is  a network operating system, this is no  big  deal.  The
authors of TurboDOS (Software 2000) have chosen ARCnet as the LAN protocol  to
use.  (ROCHE>  Hahem! All the network cards and drivers ever made  by  Digital
Research  used  ARCnet,  rather than Ethernet...) ARCnet  is  a  token-passing
network, a proprietary package from DataPoint which operates at a raw rate  of
2.5  megabits/second  in a 'don't care' configuration (bus, star, ring,  or  a

To  use  ARCNET,  you need hardware cards, one in  each  network  'node',  and
additional  TurboDOS software for each node which is,  usually,  automatically
run  at  boot time. Cabling is by standard coaxial, and nodes can  be  several
thousand metres apart.

My  own  system  (the Minstrel) can currently support ARCnet  links  to  other
Minstrels, to the IBM PC and Apricot families, and I have such links in my own
setup.  The  network  is  self-configuring at boot  time,  assuming  that  the
hardware  is correctly installed and the software is automatically run. It  is
so transparent that users need not be aware that they are on a LAN.

My  own  Apricot,  for  example, has 2 floppies.  These  are  local,  and  not
available to other nodes on the LAN. My Minstrel has 4 drives: A, B, C, and  E
to  the Minstrel slaves, but C, D, E and F to the Apricot. The Apricot  simply
thinks that it has got 6 disc drives, and I use them *EXACTLY* as though  that
is what it actually has. Similarly, with printers. The Apricot can access  the
very powerful print environment of the Minstrel simply by declaring in advance
(or  using  a boot time default) which spool drive/queue/printer to  use.  The
best  thing  of  all is that *IT WORKS*. (ROCHE> Hahaha! But  it  was  already
working,  several  years earlier, under MP/M-II! Those ignorant  fans  are  so
funny!)  Transfer  times  across the ARCnet are pretty  quick.  Programs  load
faster  from the network than from a local floppy with several  nodes  active.
That  may not sound impressive but, believe me, it is. You should try some  of
the other networks, if you don't believe me.

The TurboDOS print environment

Many micro systems make claims to having 'spooling' facilities. Usually,  they
are  rather primitive and very limited in scope. Spooling is a very  old  idea
which  stands for Simultaneous Peripheral Operation On Line, which is  a  very
accurate  description  of  what  it  is,  although  the  actual   simultaneous
peripheral operation is usually thought of as the despooling end of things.

When  you 'spool' a file, what you are doing is 'printing' the file under  the
control  of an applications program (e.g., a word processor), but you are  not
printing  it  directly  to  a  printer.  Instead,  the  operating  system   is
intercepting  every  single character that you are printing and  storing  them
sequentially in a disc file. This is *MUCH* quicker, especially if you have  a
hard  disc,  and lets you 'print' even when the physical printer  is  busy  on
someone else's work.

When  you  want  the hard copy, you have to 'despool', which  may  require  an
explicit  instruction or may be automatic when the printer becomes  available.
The 'printed file' is then taken off the disc, and sent to the actual printer.
What  makes  all  this interesting and actually useful, though,  is  that  the
despool activity takes place in the background, while you are doing  something
else on the systems which may be completely unrelated. For example, you  could
spool print from WordStar an enormous document, which would be *MUCH*  quicker
than printing it direct and, when finished, you could initiate the  despooling
by  typing  a  couple  of keys at the keyboard.  Then,  while  the  system  is
automatically  despooling and spending the next hour printing your hard  copy,
you are free to run SuperCalc, play games, use the database, or do  absolutely
anything  else  at  the  terminal. (ROCHE> Note  that  all  this  was  already
available under CP/M 1.4, with SPOOL...)

TurboDOS,  naturally, has spooling facilities. Actually, it  has  impressively
comprehensive  ones,  which are controlled by the PRINT,  PRINTER,  and  QUEUE

PRINT  defines which print routing you wish to use, and you can choose  direct
printing  to a (named) printer, or spool printing to a (named) disc.  You  can
break  down spooling even further, by spooling to up to 16  different  (named)
queues  on  a  given disc, which feature can assist  with  some  tricky  print
management problems that commonly arise in business. Suppose that, during  the
day,  you routinely print letters (letterhead), memos (plain  paper),  program
listings  (sprocket  hole listing paper), invoices  (pre-printed  forms),  and
address  labels. TurboDOS allows you to do this with only one printer  without
too  much  fuss,  quite simply. What you do is assign each  type  of  paper  a
different  print  queue,  and then spool to the  appropriate  queue.  Sometime
later, when you want to run off the hard copy, you load letterhead and despool
the  letters' queue, then load invoice forms and despool the invoices'  queue,
and  so on. (ROCHE> Well, personally, in practice, I found it easier  to  have
printers specialised for one given type of paper/form.)

It  is  a  simple matter to take this a stage further and  have  a  number  of
printers  each assigned to appropriate queues which you 'attach' to the  queue
using the PRINTER command.

QUEUE  simply  queue  a file for immediate despooling via  which  ever  PRINT/
PRINTER routing is currently set.

Lots of switches are available to enable files to be deleted/saved/not queued/
auto  queued,  and  so  on, as well as methods  of  stopping,  restarting,  or
aborting print runs.

The standard Minstrel system, for example, has 3 printer ports on the  Master,
so simultaneous despooling by all 3 printers is quite normal.

The mechanics of TurboDOS

There  is  no  such thing as a fixed TurboDOS operating system:  each  one  is
different and made up of different parts.

Basically,  you  have a large collection of relocatable  assembled  code  (REL
files  for 8-bit, O files for 16-bit), each module of which performs  a  small
task. Here are a few modules which will exist on almost every TurboDOS system:

Disk drivers:   DSKHW   Winchester driver
                DSKHWF  5" & 8" floppy drivers
                DST58F  5" & 8" floppy type specifications

Circuit drivers: MCDSPM Master Circuit Driver
                SCDD86  Slave Circuit Driver

I/O drivers:    CONDRV  Console Driver
                LSTXON  Serial printer driver
                LSTPAR  Parallel printer driver
                etc, etc

The  various  operating systems are simply collections  of  these  relocatable
modules, all linked into a run-time operating system. Typically, there will be
3 main groups in the operating system:

        OSLOAD  This  is  a  program  which  automatically  loads  the   other
                operating modules, and is called by a ROM-resident loader.

       OSMASTER This is the master operating system, which is loaded by OSLOAD
                into   the  master  processor.  OSMASTER  will  be  a   linked
                collection  of  relocatable modules  covering  file  handling,
                memory  management, spooling, network activity, disc  drivers,
                and so on.

       OSSLAVE? These  are  all  the various slave systems. Each  one  can  be
                different and targeted for a specific hardware slave, and each
                will be loaded by OSMASTER into the correct slave for which it
                is targeted. For example, you might have 2 16-bit slaves,  one
                with  128K and another with 256, one with a local printer  and
                one with a global printer. Additionally, you may have 2  8-bit
                slaves, one an old Z80A CPU with nothing special and another a
                modern  Z80H CPU with bank-switched memory. This will  need  4
                different  slave systems, each of which will be loaded to  the
                correct slave by OSMASTER at boot time.

The  beauty of all this is that, if you change your hardware, e.g., put  in  a
new  disc drive, all you need is a relocatable driver routine for it, and  you
can immediately link it into your system. (ROCHE> Yes, this is sooooo  simple!
Er...  Where do I find the source code of a driver, since the source  code  of
TurboDOS is not available?...)

Programming under TurboDOS

It  is a snap for CP/Mers. The full list of CP/M primitives is available,  and
is  considerably extended over the basic CP/M 2.2 to include those  from  MP/M
and CP/M Plus. (ROCHE> Hahaha! Actually, CP/M Plus is a single-user version of
MP/M-II...) These are what TurboDOS calls the 'C-functions', i.e., you put the
number  for the function you want in register C, maybe a location in  register
D, and CALL 0005H (8-bit) or INT 0E0h (16-bit). Just like CP/M.

There  are also a load of similar 'T-functions', which are accessed by a  CALL
to  0050h (8-bit) or an INT 0DFh (16-bit). T-functions give you access to  the
special network features and other TurboDOS-specific goodies.

Miscellaneous bit & pieces

It has been well said that the heart of CP/M is the disk directory. If you can
handle  that  as a programmer, you can do most things that are  likely  to  be
necessary,  at least as far as applications work with files is  concerned.  If
anything, TurboDOS is a bit easier than CP/M. For a start, TurboDOS can handle
disks  in  CP/M format, i.e., with a track or two reserved for  the  operating
system, followed by a few more tracks for the directory, or it can do its  own

TurboDOS  maintains a directory in a special reserved file called $.DIR.  This
can  be thought of as a 'dump' listing of 32-byte CP/M FCBs. It contains  FCBs
that  are exactly the same as those from CP/M, complete with extent folds  and
all the works. However, the directory is a file, like any other file, and  can
be  used  as  such.  Because TurboDOS can handle *VERY* big  files  (up  to  1
GigaByte),  a  special directory search technique is used. (Imagine  a  serial
search of an optical disk directory with tens of thousands of extents to  look
up (even with 16x folding)). Just not on. Instead, TurboDOS performs a hashing
calculation  on the filename before a search, and uses this as an  index  into
the directory. Speeds things up quite a bit. However, this 'hashed'  directory
is  not  CP/M-compatible  (ROCHE> ??? MP/M-II and CP/M Plus  both  use  hashed
directories!!!),  so it is not appropriate for floppies that might have to  be
read  by other standard CP/M machines. It is, of course, in the best  TurboDOS
Mix'n match tradition, perfectly standard procedure to use linear  directories
on the floppy drives, and hashed on the Winchesters, side by side.

TurboDOS maintains another special sort of file, one called a FIFO, that is to
say: a First In, First Out file. FIFOs can be created in RAM or on disc by the
FIFO  program, and carry a flag bit in the FCB to identify them. They  can  be
very  useful.  For example, a simple electronic mail facility is  possible  on
standard  TurboDOS hardware, which any user can set up. Firstly, you create  a
number of FIFO files on disk, each one named for a user of the system, declare
them  all to be 'Global', and put them in User Zero. When you want to  send  a
user a message, you use the SEND program by typing:

        SEND (fifo filename) (message text)

and  TurboDOS  will reply to the effect: 'Message sent to FIFO file'.  If  you
TYPE (fifo filename), you will display the contents (if any) of the FIFO,  and
the  contents  will then be lost, i.e., they went in first and have  come  out
first, if you see what I mean. I use mine in such a way that, at log-on  time,
the users' FIFO (identified by the ID they typed) is automatically typed  onto
their  console.  FIFOs can be used for much more  sophisticated  things,  like
inter-process messages and queues (ROCHE> Which exist under MP/M-II...), which
can be awkward to do in other ways.

Real Soon Now

It  is rumoured that MS-DOS 3.0 (i.e., networked MS-DOS) has finally  arrived.
(ROCHE>  MicroSoft  was  the  specialist  of  "VapourWare",  often  announcing
products 2 or 3 years before delivering them. Of course, meanwhile, the market
was not buying competing products...) Sometime, maybe someone will write  some
good  multi-user  software for it. When they do, I can run it on  my  existing
setup  under TurboDOS, which already has the MS-DOS 3.x hooks built  into  it.
Why do people insist on reinventing the wheel?


You  will  gather  that I like it. You are right. How did  I  ever  live  with
single-user micros?

If it is all so easy, why can't other people do it, too?

Well, they can after a fashion. The problem is they keep insisting in  belting
square  pegs like MS-DOS and PC DOS into round holes that they simply  weren't
designed for (were they actually designed at all, I ask myself). The resulting
problems  can  only be overcome with extra layers of software,  hardware,  and

They  should  swallow their pride and use TurboDOS. The  authors  of  TurboDOS
claim that more licenses have been sold for TurboDOS than for all the variants
of Unix put together. It is time the hype machine started to look at the world
a little more objectively.

So, what's it all cost, I hear you ask?

A  2-screen  20MB  COMPLETE  system  can be  bought  for  around  L6.25k,  and
additional users from about L2.5k per 2 (16-bit 8086 slaves). Makes you think.