

                            TURBODOS

            A Networking Operating System for the Z80

                          by Ron Fowler

This article is intended to acquaint the reader with a relatively 
new  disk operating system for the Z80:  Turbodos.   It is not  a 
review  in the strictest sense (although I'll pass on my opinions 
where  appropriate),  but  will  instead  stress  the  functional 
characteristics of the system that will, hopefully, be helpful in 
making a decision when selecting an operating system.

I'll begin with a chronicle of events that led to my own involve-
ment  with  Turbodos,  and continue with a short overview of  the 
system and its capabilities.  From there, I'll discuss the system 
in  more detail,  touching on each major feature incorporated  in 
Turbodos,  along  with  a  look  at each  of  the  majort  system 
utilities provided.   A short discussion about potential problems 
that may be encountered will follow,  along with a look at  long-
range  plans for the operating system revealed in a  conversation 
with  the  auther  of the system.   I'll conclude  with  a  short 
description for programmers.




                           BACKGROUND

When  I began work for my present employer  (Willens-Michigan,  a 
Detroit-based  typesetting firm),  the only software  development 
system available for my use was a Z80-based S-100 machine,  which 
had  been purchased originally to automate the company  invoicing 
process.   At  the time I began using the machine,  it was  being 
used  more  and more for secretarial word processing  needs,  and 
available machine time was diminishing.   Within a few months, it 
became  obvious to my employer that,  in order to make  effective 
use of my time,  another computer would have to be purchased just 
for  software development.   Further,  there was the  probability 
that the applications programs I was developing would require yet 
another machine.

In  order to make best use of the already sizeable investment  in 
equipment,  the  company  assigned me the task  of  investigating 
currently  available multi-user systems,  with the  objective  of 
making  as much use as possible of the existing Z80 system.   The 
proposed  system  would  have to accomodate a  minimum  of  three 
users,  with  possible expansion to as many as five or  more.   A 
high  priority  was given to assuring a relatively  low  per-user 
expansion  cost,   after  the  initial  investment.  Yet  another 
consideration  was  the need to run our  existing  CP/M  software 
(Wordstar,  our invoicing program, and a number of others) on the 
new  system.   All  in all,  this was a rather formidable set  of 
requirements to build around an 8-bit processor!

We initially investigated several multi-user systems,  among them 
MP/M,  Oasis,  and Altos. For software compatibility reasons, the 
field  was  narrowed  down  to  MP/M  only.   We  ordered  system 
documentation,  and  made arrangements to visit some  local  MP/M 
sites.   Our  findings were rather disappointing;  we found  that 
MP/M  response  time  suffered  greatly with only  a  few  users. 
Printer  spooling  (1)  ran  at  a  low  priority,  which  caused 
background  printing to stop entirely for long periods  of  time.  
There  were  (at that time) no provisions for  file-lockout  (2). 
Finally,  it  seemed  we would also have to spend a  considerable 
amount of development time extending our CP/M BIOS for use  under 
MP/M.

It   was   around  this  time   that  an  article   in   KILOBAUD 
MICROCOMPUTING  (3)  caught  my  eye:  it  was  a  comparison  of 
multitasking versus multi-processor systems.   An important point 
of  the  article  was that complete single-board  computers  were 
being manufactured that plugged into the S100 bus.   These boards 
were  not bus masters,  in that they appeared on the bus only  as 
I/O  ports (although an expansion board would allow one of  these 
slave  computers  to  become the  master  processor,  allowing  a 
complete system to be built around this hardware).   The hardware 
could  be  purchased either as a complete system,  or  as  single 
circuit boards (the latter being more suited to our needs).

We  then began making inquiries of various manufacturers of  this 
type  of  hardware.  The system mentioned in  the  MICROCOMPUTING 
article suffered from what I considered a glaring deficiency: the 
operating  system  provided  was standard  CP/M  itself,  with  a 
special  program  running  in the  master  processor  to  provide 
support  to the slaves.   I strongly felt that this new  hardware 
concept  should  have an operating system that was designed  with 
networking  in mind,  although I doubted that such  an  operating 
system, if it existed, would be at all CP/M compatible (4).

During  our research,  we found a company in  Tustin,  California 
(MuSys  Corp.) selling a similar system,  running a real network-
oriented  operating system which it called MuDos.   It turned out 
that  MuDos  was  being offered by  a  number  of  manufacturers, 
Industrial  Micro-Systems  among them,  under the name  Turbodos.  
The  operating  system itself was produced by  a  company  called 
Software 2000, based in Los Alamitos, California.

The  slave  CPU  boards  sold by MuSys contained a  full  64K  of 
memory,  a  serial port for the console terminal,  and a  network 
port for communications with the S100 master CPU.

We  again  ordered  documentation,   and  called  several   MuSys 
customers,  all  of  which responded favorably when  asked  their 
opinions of the system.  Since MuSys Corp. would provide the disk 
drivers  for the Morrows M26 (which we already had on order),  we 
decided we had found our system, and placed an order for the full 
networking version of the operating system.   We also ordered two 
slave microcomputers,  one of which was the newly-developed  Net-
82,  providing  an  extra 64K of memory (two banks),  a  vectored 
interrupt  controller,   and  an  optional  floating  point  math 
processor.

I  should  point out that,  since we had to  interface  this  new 
equipment  to  our  existing hardware,  there was  some  software 
development work necessary to bring the system up.   For example, 
the  system had to read and write our DJ2D floppies,  as well  as 
communicate  with an IBM card punch,  a PMMI modem,  and our  NEC 
daisy-wheel  printer.    Thankfully,  driver  specifications  are 
provided  with  the system documentation,  and I had most of  the 
necessary  drivers  written  by the time all  of  our  components 
arrived.   After a couple of evenings of debugging,  we were able 
to put Turbodos "on the air", with a master operating system that 
communicated  with our peripherals,  the network,  and  our  M26, 
slave  operatings systems for each of the slave CPU's,  and an OS 
loader  program (provided with TurboDos,  and configured  by  the 
user) to bring the system up.

We  have  had the system running for about six  months  now,  and 
we're  pleased  with  its capability.   We've had  no  reliablity 
problems,  aside from a slight problem with the Net-82 CPU (which 
was quickly replaced by MuSys;  they shipped a new Net-82 as soon 
as  we  notified them of the problem and BEFORE we sent  the  old 
board back).   Further,  the software is well-supported,  both by 
MuSys and Software 2000 (5). 

-------------

The  remainder  of  this article will be devoted  to  a  detailed 
overview of the TurboDos operating system.

                        TURBODOS FEATURES


Turbodos  supports  up to 16 disk drives,  ranging  from  single-
density  floppies to hard disks in excess of 1000  megabytes  per 
drive.  Files may range up to 134 megabytes in length.

Additionally,  the system supports up to 16 printers per CPU, and 
utility  programs  are  provided  for  manipulating  the  various 
printers and printer modes.

Networking  versions  of Turbodos may be  configured,  as  either 
network  master  or network slave.   As many as 16 slaves may  be 
serviced by one master.

Full  printer spooling and despooling is supported for up  to  16 
printers, both through utility programs, and extended BDOS calls. 
Sixteen  communications  channels  are also  supported  for  such 
things as modems,  inter-system channels, and links to peripheral 
devices.

No  system  tracks are required on any TurboDos disk,  since  the 
operating system is loaded once (from a disk file on the  boot-up 
disk)  and remains resident until the next cold  start-up.  Also, 
since  disk  buffer  sizes may be specified by the  user,  it  is 
possible  to read the disk without the need of  interleaving  the 
sectors, resulting in a vast speed improvement.

The  amount of disk buffer space may be changed dynamically using 
a  system utility,  allowing free memory to be  used  efficiently 
while  speeding up disk operations.   Also supported is a program 
load optimizer,  which scans the disk allocation map to determine 
which  sections  of a program are contiguous on  the  disk,  then 
loads these sections in the most efficient order.

Turbodos  may be configured as multi-tasking (in  fact,  this  is 
necessary  in  the network master) allowing many functions to  be 
performed in the background.  Although the documentation makes no 
mention  of  how to do this,  the information is  available  from 
Software 2000, and should be in the next documentation update.

The  system  supports  logon and  logoff  utilities,  with  usage 
logging  to a disk file.   Passwords may also be specified  as  a 
login parameter.

Among  the file attributes supported are the SHARED and EXCLUSIVE 
attributes, to control simultaneous access by more than one user.  
A file may also have a FIFO attribute (I'll explain that one more 
fully  a  little later),  a GLOBAL  attribute,  and  an  ARCHIVED 
attribute  (this  is  supported by the  COPY  utility,  to  allow 
flexibility  in  backing up large disk systems).   The only  CP/M 
compatible attribute is the read-only attribute.  All  attributes 
may  be  set  or  reset from high-level  languages  supporting  a 
rename-file  function,  using  special characters in  the  rename 
fields.
 
Turbodos  supports  file interlocks at both the file  and  record 
levels.    A  unique  record-locking  capability  allows  locking 
declaration from any high-level language that can manipulate disk 
files.

The system includes a batch processor similar to the CP/M  SUBMIT 
utility,  but with enhanced capability.  In addition, the console 
command  processor  allows multiple commands to be entered  on  a 
command  line,  seperated by backslant characters.   System calls 
support the command line processor, and allow command lines to be 
passed from a running program (6).

User  numbers  are displayed in the system prompt,  and  32  user 
areas  are  supported.   The copy utility provides  full  support 
between user areas.   Also,  users logged in as  "non-privileged" 
may not change the current user number by any means.

Other  features include attaching the slave console to the master 
processor,  the ability to manually queue files for  printing,  a 
rudimentary  mailbox  facility using FIFO files,  a  disk  verify 
utility, and automatic reset-and-download for a "crashed" slave.

All  of  these  features will be detailed in  the  paragraphs  to 
follow.


                          DOCUMENTATION

Turbodos  comes  with two typeset manuals,  a User's Guide and  a 
Configuration  Guide.   The  User's Guide  documents  all  system 
features  and utilities,  contrasts the use of Turbodos with that 
of CP/M,  and contains an extensive theory of operations section.  
This  guide  also  contains specifications for all  of  the  BDOS 
system  calls  (there  are about 87 of  them,  including  47  not 
available with CP/M).

The Configuration Guide provides complete instructions for  using 
the  system  generation  tools,   in  addition  to  providing  an 
informative  section  describing the modular construction of  the 
operating system.  Additionally, the specifications for any user-
supplied device drivers are contained here, along with a tutorial 
on data structures used by Turbodos drivers, such as linked lists 
and semaphores.  A set of sample driver listings is also included.

The  basic manual set was written for revision 1.0  of  Turbodos; 
the additional system revisions (1.14 is the current version) are 
documented  in  the form of supplements to the original  manuals.  
Software  2000 is in the process of re-writing the  manuals,  and 
should  have  them  available  with  the  1.2  release  (expected 
sometime in May).


                        SYSTEM GENERATION

I  should  preface  this discussion by  noting  that  an  initial 
implementation  of Turbodos will require CP/M (or some compatible 
derivative) in order to run the development tools used for system 
generation.   This,  of course,  does not apply when the hardware 
and  software  is  purchased  from  a  dealer  as  a   completely 
integrated package.

Turbodos  is  a modularly-constructed operating system with  each 
system  function  contained within  a  relocatable  module.   For 
example,  there  are  modules for such things as file  management 
(called FILMGR),  disk management (a module "closer" to the  disk 
than  the  file manager,  called DSKMGR),  a disk buffer  manager 
(BUFMGR), a program loading optimizer (FASLOD), a console manager 
(CONMGR),  and others.   These are examples of what Software 2000 
calls "kernel-level" modules,  meaning they are within the bounds 
of the operating system.   In addition there are  "process-level" 
modules,  which are outside of the operating system (meaning that 
they are concurrent processes,  and run simultaneously with other 
programs,  competing  for CPU time).   Among these are the LCLUSR 
module  (which supports a transient program area in a  networking 
master  processor),  the NETSVC module (which handles network I/O 
requests from slave processors), the DSPOOL module (which handles 
printer despooling).   Finally,  there are driver-level  modules, 
which are hardware-specific sections, such as CONDR (which is the 
lowest-level  console I/O handler) and DSKDR (the driver for  the 
disk).   These  are collectively similar in function to the  CP/M 
BIOS.

The   kernel   and  process  level  modules  are   not   supplied 
independently, but are grouped into several different relocatable 
files,  each  of which is a functionally distinct version of  the 
operating system.   There is a version called STDMASTR,  which is 
the master networking system, another called STDSINGL, which is a 
single-user  system,  and one called STDSPOOL,  which is a single 
user version with spooling.  There are also groups of modules for 
slave operating systems, and boot loaders. 

The driver level modules exist independently (i.e.,  they are not 
grouped  into  a single "library" file,  as are  the  kernel  and 
process  level routines),  and are supplied also in source  form.  
They  can  be  freely modified by the user and  linked  into  the 
system  at system generation time,  allowing complete flexibility 
there is a wide selection of assemblers from which to choose.

Curiously,  the  supplied  source modules require  the  TDL/XITAN 
series of assemblers (now available from CDL Corp.,  and  Phoenix 
Associates),  one  of  the few relocating assemblers for the  Z80 
that  does NOT produce Microsoft-compatible relocatable  modules.  
For  this reason,  a utility program is provided (RELCVT.COM)  to 
translate the TDL-format modules to Microsoft format.

Once  all  the necessary modules are present  on  the  disk,  the 
physical  operating  system is generated using a  program  called 
GEN.COM,  which  is  in fact a linkage editor.   The GEN  program 
takes command-line arguments specifying a file that contains  the 
system generation instructions (a ".GEN" file, and optionally a
".PAR"  file,  which allows modifying individual operating system 
parameters),  the name of the output file (which will contain the 
configured operating system), and any options, such as "M", which 
produces a load map, and "S", which produces a symbol table.

GEN.COM  must be used to produce at least two files to bring  the 
system up: OSLOADER.COM and OSMASTER.SYS, which are the operating 
system   loader  program,   and  the  master  operating   system, 
respectively.   Additionally, one slave operating system for each 
TYPE of slave must also be present at load time.  For example, if 
all slaves are identical,  the file OSSLAVE.SYS should be present 
on the disk.   If different slaves receive different versions  of 
the   slave   operating   system,   slave   "A"   would   receive 
"OSSLAVEA.SYS",  slave  "B" would receive "OSSLAVEB.SYS",  and so 
on.   A table within the master operating system may be  modified 
to specify which slave gets which operating system.

This  technique  provides  for  very easy  modification  and  re-
configuration  of the system,  since the included modules can  be 
re-defined  by modifying the associated ".GEN" file with  a  text 
editor.  Operating system parameters, such
as number of printers (up to 16 printers are supported),  buffer-
flush  delay time,  drive step-speed,  etc.,  can be specified by 
editing the associated ".PAR" file.   In fact,  the .PAR file can 
be used to modify ANY global symbol in any of the system modules.


                             NETWORKING

One  of the key features of Turbodos is its  networking  support.  
Up to 16 slaves may be associated with one master,  allowing full 
access from each slave to all of the facilities (disk,  printers, 
communications channels, etc) of the master.

The  network interface drivers are supplied with the system,  but 
can be used only with the slave hardware supplied by the  dealer.  
If  you want to interconnect various computers you already  have, 
be ready to write some drivers.   This is difficult,  because the 
network  requirements  are not specified in the manuals  (network 
specifications  are  promised  from Software 2000  for  the  next 
release).   It should be possible,  however,  to use the supplied 
drivers as a guide in writing customized network drivers.

A utility program (MASTER.COM) is provided to allow any slave  to 
attach its console to the master over the network.  This allows a 
rudimentary multi-programming capability,  since it's possible to 
start a job in the master processor, detach from the master, then 
run programs simultaneously in the local slave.

Currently, slave-to-slave communication is not supported, nor is
master-to-master.   Word  from  Software  2000 is that  the  next 
release of the operating system (scheduled for May of 1982)  will 
have  this  capability,  provided  that it is  supported  in  the 
hardware.

                        PRINTER SPOOLING

Turbodos  supports  a very versatile printer  spooling/despooling 
scheme.  As many as 16 printers are supported, and flexibility in 
printer  options is provided via three system  utilities:  PRINT, 
PRINTER, and QUEUE.

The  PRINT  utility  allows  you to control the  routing  of  the 
printer output (that is, WHERE the print characters are sent to).  
The normal,  and most efficient, routing is to a "printer queue", 
which  is a numbered disk file.   These files are  scheduled  for 
printing on a first-in first-out basis,  and are normally deleted 
at the completion of printing.  Queues are designated "A" through 
"P",  and  may  be  associated with a  particular  printer.   For 
example,  the queue file "-PRINT-A.001" is the name of the  first 
file in the "A" queue,  while "-PRINT-B.003" is the third file in 
the  "B" queue.   While this may seem confusing,  it allows  full 
flexibility  in assignment of queues to printers,  and provides a 
means  of distinguishing different kinds of output (for  example, 
output  requiring  a special invoice form may be  separated  from 
output requiring a form for shipping,  and each may be queued  to 
any printer at a later time).

The PRINT utility also allows print output to be sent directly to 
any  printer (locally,  to a printer connected to the slave,,  or 
remotely,  to one connected to the master),  to the console, to a 
"null" printer (i.e.,  print output is discarded),  or to a  disk 
file (without queueing).  The program may also be used to display 
the current print routing.

The PRINTER utility controls the print destination.  This program 
provides  the  means  of assigning  queues  to  printers,  taking 
printers offline, temporarily halting a print job, or permanently 
terminating  one.   For  example,  the command "PRINT B  QUEUE=C" 
assigns local printer "B" to queue "C".

A  good  illustration of the use of these utilites is  a  typical 
inventory system,  where one clerk is handling  requisitons,  and 
another  inventory  reports.   Further,  let's say there are  two 
printers,  "A" (a draft-quality printer,  suitable only for rough 
work)  and "B" (a letter-quality printer).   Both clerks  require 
letter-quality  output  for  their  respective  reports,   but  a 
secretary  is currently using the leter-quality printer  for  de-
spooling  form  letters.   In this case,  the system manager  has 
permanently  assigned  (via  a  system  generation  option)   the 
requisitions clerk (or more accurately,  his slave processor) the 
"A"  queue,  the inventory reports clerk the "B" queue,  and  the 
secretary the "C" queue.  Each employee may perform his function, 
without worrying about what kind of form is currently loaded into 
the  printer,  since the output of each is being saved in a  disk 
queue.   When  the secretary has completed the form letters,  the 
requisitions  clerk can then load the requisition forms into  the 
printer,  assign  the printer to his queue ("PRINT QUEUE=A")  and 
his accumulated output will then be taken from the disk queue and 
printed  out.   The  clerk doing inventory reports  may  sometime 
later load his report forms into the printer and assign his queue 
to be printed ("PRINT QUEUE=B").   During this time,  any kind of 
printing  may  simulataneously take place on the  draft  printer, 
with no conflict.

The third utility,  called "QUEUE",  allows files to be  manually 
marked  for de-spooled printing,  and command line options may be 
used  to specify queue assignments,  confirmation  of  individual 
files  (for  use  with  wild-card  filename  specifications)  and 
automatic  deletion after printing.   For example,  "QUEUE  *.PRN 
;YDQ=C"  will  post all of the files with the filetype  "PRN"  to 
queue  "C";  each file will be presented for confirmation  before 
posting, and each will be deleted after printing.

It  should  be  noted  that all of these  printer  functions  are 
available  for programmatic access through BDOS  calls,  allowing 
the  programmer  complete access to any of the spooling  and  de-
spooling modes.


                     COMMUNICATIONS CHANNELS

Turbodos supports the concept of communications channels  through 
BDOS  calls.   These  channels  may be used for  such  things  as 
modems,  serial  ports to various peripherals,  or data  channels 
between systems.  There may be up to 16 channels in each slave or 
master.   These  channels are defined by device drivers contained 
within the operating system, and are completely definable by the
user.

Slaves may access the communications channels of the master  over 
the  network.   This permits a very convenient means of  communi-
cation between the master and the slaves.

BDOS  calls  for use with communications channel  access  include 
functions  to set baud rate,  return channel  status,  set  modem 
controls, and read modem status.


                        BATCH PROCESSING
                                                                               
Turbodos comes with a batch processing utility (similar to SUBMIT 
of  CP/M)  that  allows system commands to be taken from  a  disk 
file.    This  program  is  called  DO.COM,   and  provides  some 
interesting features.

First  of all,  command-line substition arguments  are  specified 
within  the  DO file by number,  in a fashion similar to that  of 
CP/M's SUBMIT utility.   Unlike SUBMIT, the argument is specified 
in the DO file by enclosing it in braces.   Further, command line 
arguments  may  contain embedded spaces,  as long as  the  entire 
argument is enclosed in quotes.

Another difference between DO.COM and CP/M's SUBMIT.COM is that a 
temporary  disk file is only created if arguments  are  specified 
within the DO file.  If none are specified, Turbodos reads the DO 
file directly.   Also, a default argument may be specified within 
the  DO  file,  for  use if no argument is  provided  within  the 
command line.   For example, the DO file line "L80 {1} {2,MYLIB}" 
defaults  the file "MYLIB" if no argument #2 is specified in  the 
DO command line.

A  running  DO  file  supplies input for more  than  just  system 
commands;  in fact,  the DO file specifies ALL console input with 
the exception of direct console I/O (using BDOS function 6).  For 
example, the following is a valid DO file:

                DDT
                D0,7F
                ^C
                ED FOO.BAR
                ICALL FIMP^ZQ

One  problem results from this capability:  if a running  program 
polls  console  status  to determine if  an  abort  character  is 
waiting  at the keyboard,  the entire do file will be diverted to 
the  program,  since,  when  console status is  found  TRUE,  the 
program must consume the waiting character to determine if it  is 
the  break  character.   A  notable example of this  is  the  TDL 
assembler.   A  possible  improvement,  therefore,  might be  the 
ability  to return console status false via a  special  character 
within the DO file.

DO  files  may be nested to any depth (7);  this means that a  DO 
file may contain any number of imbedded DO commands.

DO  files may be activated by a user program using a  BDOS  call, 
with a pointer to the DO file name as an argument. 

                         FILE INTERLOCKS

An  important requirement of a multi-user operating system is the 
need to synchronize access to certain files via a lockout  scheme 
(2).  Turbodos provides this capability in two ways:

1)  Write interlock:  Any user writing to a file gains  exclusive 
write-access to that file; attempts by any other user to write to 
that file returns an error code.  This technique provides for one 
(and only one) "updating" process, with many "inquiry" processes.  
This  means of interlock is automatic,  and requires no  explicit 
action on the part of the user or the programmer.

2)  Record-level interlock:  This feature is applicable to  files 
with the "shared" attribute SET.   A process gains a record-level 
interlock by opening (or creating) the pseudo-file "$.LOK" (which 
is  really not a file at all,  but rather a signaling mechanism).  
Subsequently,  any  records read by that process  become  locked, 
until that record is re-written.  Any other process attempting to 
write a locked record fails in either of two ways:

        A. If  the  conflicting  process  has not  itself  opened 
           $.LOK,  then  it is blocked (removed from  the  system 
           ready list) until the record becomes available.

        B. If the  conflicting process has opened $.LOK,  then an 
           error message is returned.

Any  number of records in any number of files (all must have  the 
shared attribute SET) may be locked concurrently.   A process may 
release all locked records at once by closing $.LOK

One  thing to note about record-level interlocks is that they may 
be  specified by ANY EXISTING high-level language,  providing  it 
has the ability to mainipulate disk files.   Note that while MP/M 
II provides for file interlocks,  this feature is available  only 
to  the assembly language programmer,  at least until all systems 
languages  are  updated  to  take  advantage  of  the   interlock 
features.


                           FIFO FILES

Turbodos  provides a special type of file called "FIFO"  ("first-
in-first-out").  This is type of file is useful for communicating 
between  processes  and  between users,  and is created  using  a 
utility called FIFO.

The primary significance of a FIFO file is in the way  sequential 
reads and writes act on the file: a record written to a FIFO file 
is  always  appended  to the end of the file,  while a  record  a 
record  read is taken from the beginning (and then  removed  from 
the  FIFO  entirely).   Random reads and writes work exactly  the 
same with FIFO files as they do with regular files.

A  FIFO file may be resident either on disk or in main memory  of 
the master processor.   Naturally,  the memory-resident FIFO file 
can  be  accessed at speeds far in excess  of  the  disk-resident 
FIFO.   The type of the FIFO is specified by answering a query by 
the  FIFO  utility.   An  additional specification  to  the  FIFO 
utility  is the size of the FIFO:  disk resident FIFOs may be any 
size  up to the capacity of the disk;  memory-resident FIFOs  are 
limited by the available memory space in the master processor.
 
Two  other  utility programs provide a  rudimentary  mail  system 
using FIFO files.   The SEND utility posts a message contained in 
its  command line to a specified FIFO file;  the RECEIVE  program 
reads a message from a FIFO and displays it on the console.

The SEND utility may be used in combination with the AUTOLOAD and 
DO  facilities  to force command lines to idle slave  processors.  
The actual implementation is a little awkward,  but does  provide 
an effective means of sending jobs out to slave CPUs as a kind of 
background processing.

An  interesting  (and quite useful) feature of FIFOs occurs  when 
the FIFO file has the "shared" file attribute set:  if a  process 
attempts to read such a FIFO,  and the FIFO is empty, the reading 
process is blocked until until a record is available at the FIFO.  
Similarly,  a  process writing to a full FIFO is blocked until  a 
record  is taken (read) from the FIFO.  If the "shared" attribute 
is  NOT set,  then reading an empty FIFO returns  an  end-of-file 
condition,  while  writing  to  a full FIFO returns a  disk  full 
condition.

Applications  for FIFOs can best be illustrated by the  following 
example,  which is taken from a real situation encountered in  my 
work with Turbodos.

We  have a serial source of input that must occasionally be  read 
by  our microcomputer;  the device is connected to a spare serial 
port  in one of the slave processors in  our  system.   Normally, 
files  from this source do not exceed 25 or 30 Kbytes,  so  we've 
always  been able to buffer the incoming data in memory until the 
input  is  exhausted,  then  write the  memory  buffer  to  disk.  
Recently,  a  customer requested that we process a large job  (in 
excess of 200 Kbytes) with this device. 

This  presents  a problem typical of non-real-time  microcomputer 
operating systems:  namely, how to write a buffer to disk without 
losing incoming serial data.  From a slave CPU, disk writes (even 
though  they take place over the network,  and are  not  actually 
performed  by the slave processor) stop the slave processor until 
the  write has actually taken place,  and a result (error or  no-
error) can be returned to the slave processor.   Further,  at the 
speed  at  which our transfer must take place,  this  required  a 
delay amounting to between 10 and 20 characters times per  sector 
(i.e.,  10  or 20 characters would be lost each time a sector was 
flushed to disk).

We  found the solution to the problem using a background  process 
in  the master processor.   This process loops reading  the  FIFO 
file  "LOGGER.FIL",  which is a memory-resident (high-speed) FIFO 
with  the shared attribute set;  when there is nothing posted  to 
LOGGER.FIL, the process is blocked from execution.  When a record 
is  written  to LOGGER.FIL,  Turbodos "wakes up"  the  background 
process,  and sends it the FIFO record.   The first record posted 
to LOGGER.FIL contains the filename,  disk drive, and user number 
of  a  file  to create to post  the  incoming  records  to.   The 
background  process  reads  this  header  record,   sets  up  the 
requested file,  then loops, reading records from LOGGER.FIL, and 
subsequently posting the records to the requested file,  until an 
end-of-file  mark  is encountered,  at which time it  closes  the 
created file, and begins the process all over again.

The slave processor,  meantime,  writes the incoming data record-
by-record  (after posting the intial header record with filename, 
disk drive and user number,  as specified in the program  command 
line) to the FIFO.  This is in fact a network transfer, using the 
high-speed Z80 block moves of our network drivers,  and occurs in 
somewhat  less  than one character time.   Since the  destination 
FIFO is ram-resident,  the error-return from the master processor 
is done with no disk access necessary, yielding an extremely high 
rate of transfer.

The  result  of this is that we now have the  ability  to  record 
incoming data from our serial device,  at a relatively high speed 
(about  1800 baud),  with a capacity limited only by the capacity 
of the disk


                         SYSTEM SECURITY

Turbodos  may be configured at system generation time to  require 
users  to  log in before using the  system.   Two  utilities  are 
provided to support this feature, LOGON and LOGOUT.

The  LOGON program must exist in the logged-out user area of  the 
disk  (an  area specified at system generation  time),  and,  for 
proper security,  should be the only executable file in this area 
on any drive.  LOGON prompts for a user id and password, which it 
validates against a system file named  "USERID.SYS".   USERID.SYS 
is created with a text editor, and contains entries of the form

              USERID,[PASSWORD],USERNO["P"],[DRIVE]

where items in brackets are optional.  The "P" option specifies a 
"privileged"  user,  who  may,  among other things,  change  user 
areas,  and reset slaves.   The P option also sets a flag in  the 
operating system that can be queried via a system call,  to allow 
a program to determine whether a user is privileged.

If  the LOGON program finds the file "SYSLOG.SYS" in the  logged-
out  user  area,  it will record usage information  (name,  date, 
time, etc) in a random-access disk file.

The  LOGOFF utility changes the current user area to the  logged-
out user area,  and posts a "logged-out" entry to USERID.SYS  (if 
it exists).

Logon and logoff functions are also supported by BDOS calls.   In 
fact,  any  system  process  that requires access  to  privileged 
functions (such as set user, etc) must log in via this BDOS call, 
whether or not it is associated with a console.

                        SYSTEM UTILITIES

Beside  the utilities already mentioned,  there are a  number  of 
other utilities provided, which I'll describe now.

COPY  - this is the Turbodos replacement for CP/Ms PIP.COM,  and, 
while  lacking  the text formatting  capabilities  of  PIP,  does 
provide  a  number of new features.   COPY will  accept  wildcard 
filename  specifications  (as do most  Turbodos  utilities),  and 
allows  command-line  options to specify source  and  destination 
user  number,  select  non-archived files only  (Turbodos  always 
resets  the "archived" attributes of files when they are  written 
to),  delete  each  file from the source disk/user  after  it  is 
copied,  and allow a destination disk to be changed if it becomes 
full.   Another   feature  of the copy program is its ability  to 
rename files (when  wildcards are specified) as they are  copied.  
For  example,  the command "COPY *.BAS B:*.001" will copy all the 
files  with type BAS to the B drive,  and rename them  with  type 
"001" at the destination.

AUTOLOAD  - this utility writes its command tail to a file  named 
"AUTOSTRT.AUT"  in a special format that allows the command  line 
to  be  executed  at initial cold-start and/or  warm  start.   By 
renaming AUTOSTRT.AUT to WARMSTRT.AUT, the user will be forced to 
execute  the  specified command line at each  warm  start  (which 
occurs  whenever a transient program completes  execution).   The 
corresponding  action  for initial system cold start is  done  by 
naming the file COLDSTRT.AUT.

DIR  - Similar  to the resident DIR command of CP/M.   Prints  an 
alphabetically sorted listing;  displays amount of free space  on 
the disk,  and reports the size of each file.   Also displays the 
disk label, which may be created using the LABEL utility

RENAME - A utility to rename files.  Similar to REN of CP/M, with 
a couple of major differences: First, the syntax is reversed; the 
CP/M  syntax is "REN NEWFILE.NAM=OLDFILE.NAM" while RENAME syntax 
is  "RENAME OLDFILE.NAM NEWFILE.NAM".   Secondly,  RENAME  allows 
wildcard  file specifications on BOTH the source and  destination 
names.   When used in this way,  wildcard characters used in  the 
NEWFILE  argument  indicate that the corresponding characters  of 
each  old file name are to be used in renaming  each  file.   For 
example,  the commmand "RENAME *.BAS *.OLD" will rename all files 
of type BAS to type OLD.

SET,   SHOW   - These  utilities  are  used  to  manipulate  file 
attributes.   The  SET utility allows any or all  supported  file 
attributes to be set using a mnemonic letter.   Show displays the 
attributes. Both allow wild-card file specifications.

In  addition,  utilities are provided for setting and  displaying 
time  and date,  dynamically altering disk buffering  parameters, 
displaying drive characteristics, initializing and copying disks, 
resetting  slaves,  typeing out ascii files,  testing disks,  and 
dumping files in combined hex and ascii format.



                            PITFALLS

As you've probably guessed, I'm very enthusiastic about Turbodos; 
I've used it daily for several months,  and am impressed with its 
power  and reliability.   Yet there are a few potential  problems 
that an informed buyer should beware of.



CP/M INCOMPATIBILITIES

Turbodos does not maintain an in-memory disk allocation  map,  as 
CP/M  does.   For  that reason,  programs using 27 ("return  disk 
allocation address") will not run correctly under Turbodos.   The 
only programs I know of that use this function are the CP/M  STAT 
utility  and the public domain "SD.COM",  both of which use  this 
function  to  report  free disk space (both of  which  also  fail 
miserably  when executed under Turbodos).   The Turbodos function 
27 DOES return the number of free disk blocks,  but programs must 
be modified at the source level to take advantage of this (I  was 
able to make the necessary changes to SD in a few hours).

A  more serious problem occurs with programs that make use of the 
CP/M  disk  parameter  block  to  determine  the  physical   disk 
characteristics.    Turbodos  does  not  support  the  CP/M  disk 
parameter  block,  and  the  associated system call  (number  31) 
returns  the  Turbodos-compatible  disk  information  (again,   a 
competant systems hacker CAN modify a program at the source level 
to use the Turbodos format).   The programs I know of that do not 
work  properly because of this problem are the public domain  DU, 
SAPX and FINDBAD disk utilities,  and the commercial  diagnostics 
package RECLAIM.

Another  potential problem occurs when Turbodos disk drivers  are 
set  up with reserved tracks (I do this to maintain CP/M compati-
bility).  Although a complete BIOS jump table is simulated by the 
system,  the "set track" subroutine CANNOT set a track within the 
reserved  track  area.   This caused a  particularly  frustrating 
problem with my own IBM disk-reader program;  those tracks within 
the CP/M reserved track area were just not available.   The  only 
solution  was  to  add two "pseudo-drives" ("G" and "H")  to  the 
system,  which  are,  in fact,  the same PHYSICAL drives  as  our 
floppy "E" and "F", but with NO reserved tracks.

The  only  commercial  package  that I know  of  that  would  not 
function   because   of  this  reserved  track  problem  is   the 
REFORMATTER package (a disk utility for IBM-format disks).


OPERATING SYSTEM OVERHEAD

A  problem related to system overhead occurs with programs  (such 
as  Wordstar)  that  make frequent BIOS  calls  to  test  console 
status.   This  test,  under CP/M,  involves perhaps a half-dozen 
machine instructions.  Turbodos, however, converts these calls to 
system  calls,  which carry the overhead of hundreds  of  machine 
instructions.   The  result is that such programs run much slower 
under Turbodos.

In  the particular case of Wordstar,  the rate of console  status 
checking  can  be adjusted by the user (this is detailed  in  the 
Wordstar manual).   A documentation supplement for Turbodos  from 
Software 2000 points this out, and provides details for adjusting 
Wordstar to fit Turbodos.




                     THE FUTURE OF TURBODOS

I recently spoke with one of the two Turbodos architects,  Ronald 
Raikes of Software 2000, about his firms plans for the continuing 
development of the operating system.

A full master-to-master networking system, supporting slaves with 
local  disk storage,  should be available sometime in May.   This 
will be revision 1.2 of Turbodos,  and is currently in the  final 
testing  stages.   Additionally,  many of the utilities will have 
enhanced features.

Another  major release of the operating system (revision 1.3)  is 
planned for mid-summer of 1982.   This version will support bank-
selectable memory, and an additional console per CPU.  Mr. Raikes 
stressed  that while he WILL support multiple  consoles,  a  more 
important goal is based around a single console with two banks of 
memory, using one bank of memory for a "deluxe" operating system, 
and  allowing  a large (63 Kbyte) transient program area  in  the 
other.

Release 1.4 of Turbodos (tentatively planned for release near the 
end  of 1982) will support a nested directory structure,  similar 
to that of Unix.  


-----------------

                      TECHNICAL INFORMATION

The following section contains information that may be useful  to 
programmers desiring to implement the operating system,  or write 
transient programs that run under it.

EXTENDED BDOS CALLS

In addition to the system calls provided with CP/M 2.2,  a number 
of other useful functions are designed into Turbodos.  Aside from 
those  I've already mentioned elsewhere in this  article,  system 
calls  are available to set and return the date and time (using a 
binary  rather  than  BCD format),  set and  return  disk  buffer 
parameters  (both  the  size and the number  of  buffers  may  be 
specified),  disable  or  enable  the AUTOLOAD  feature,  load  a 
program  into memory (starting at the current DMA  address;  this 
allows  overlays  to  be  directly  supported  by  the  operating 
system), rebuild the disk allocation map, flush the disk buffers, 
lock and unlock drives, and lock and unlock printers.

The following system calls exist,  and are listed in the  manual, 
but  are  not (yet) available for use without help from  Software 
2000:  reset network,  send message to network,  receive  message 
from  network,   allocate  memory  segment,   de-allocate  memory 
segment,  send and receive inter-process message,  delay process, 
create process, and terminate process.

DISK ALLOCATION

The  disk  allocation  map  is maintained on  the  disk  (not  in 
memory),  providing a high degree of file integrity when compared 
to systems that maintain this information in memory.   I've found 
that,  under  Turbodos,  if I forget to close a file (or,  if  my 
program dies before it reaches the file close subroutine) no data 
is lost.



DISPATCHING

Turbodos  employs an interrupt-driven dispatcher to perform task-
swapping  in  real-time.   As far as I can  tell,  all  processes 
receive  the  same priority,  and are switched in  a  round-robin 
fashion.   The  dispatcher may be accessed from within any  user-
supplied modules via the WAIT and SIGNAL routines (also known  as 
P and V in concurrent programming).  These routines may be called 
by  name within driver code (they must be declared as externals), 
and  are  passed EVENT SEMAPHORES as  arguments.   When  WAIT  is 
called,  the semaphore counter is decremented,  and, if the count 
is  negative,  the calling process is removed from the ready list 
until  some other process calls SIGNAL with the  same  semaphore.  
Generally,  the  dispatcher  overhead is such that a  significant 
speed  improvement  is  realized in slave CPUs  by  omitting  the 
dispatcher   altogether  (this  is  done  by  selecting  a   non-
multitasking STDSLAVE at system generation time).

DEVICE DRIVERS

Complete  programming  specifications are provided in  the  docu-
mentation set.   I've found them to be relatively  complete,  and 
have  had no trouble writing device drivers for such things as an 
IBM card punch,  a NEC printer,  a PMMI modem, DJ2D floppy disks, 
and a Godbout System Support I clock/interrupt  system,  entirely 
from  the detailed specifications (along with a little help  from 
the supplied sample driver listings).

An interesting (but as yet undocumented) capability of the system 
is  the  ability to make recursive system calls from  within  the 
system  itself (at the driver level).   A recursive entry  point, 
"XECFCN",  is  available  for this purpose,  and can be  used  to 
access any of the sytem calls.  It should be possible, using this 
entry  point,  to  do such things as disk reads and  writes  from 
within console drivers.  Extreme care must be taken to avoid such 
things  as  mutual  lockout (calling disk functions  within  disk 
drivers  at  certain  critical points will  effectively  block  a 
process  because  of built-in mutual  exclusion  mechanisms)  and 
changing  the  calling  programs  DMA address  and  user  number, 
without restoring them.

BACKGROUND PROCESSES

User-written  background processes are supported under  Turbodos, 
but the documentation as yet provides little information in their 
use.  Since I had a need for using a background process, I had to 
contact  my  dealer (Musys Corp.).   He in turn  referred  me  to 
Software 2000,  who provided all the information (and then some!) 
I needed.

Background  processes must be linked into the operating system at 
system generation time.  An explicit call to the operating system 
"create  process"  function must be made in  the  user-changeable 
hardware  initialization  module,  with the process  entry  point 
passed in the DE register pair.   The new process will then begin 
life with a 48-level stack,  and its own set of registers,  which 
are maintained between task swaps by the dispatcher.

All processes have access to the system as if they were the  only 
running  program in the system.   System information such as  the 
current DMA address,  default drive,  and current user number are 
maintained within the process descriptor of each process, and can 
be  freely  changed  without affecting any other process  in  the 
system.   System  calls  must  be  made  by  calling  the  global 
"OSNTRY",   following  the   parameter  passing  conventions   of 
"normal"  transient programs.   The only restriction is that  all 
processes must NOT make use of the X index register. (8)


                           References
                           ----------
1)  Printer spooling generally refers to the technique of sending 
printer output to a disk file (or other storage medium) for later 
"de-spooling",  which  usually  takes the form  of  a  background 
process  in the master processor that selects the spooled  files, 
one  by one,  for output to the printer.   This technique  allows 
orderly access to system printers,  and is usually transparent to 
the  user (de-spooling takes place concurrently with other system 
operations).

2)  File lockout refers to the ability of an operating system  to 
allow exclusive access to a file for certain programs (or users), 
and deny all others.  This is usually necessary when a program is 
updating a random record; until the update is complete, all other 
users must be denied access, to avoid reading inconsistent data.

3) June, 1981 issue.

4) CP/NET,  a  networking system for MP/M,  was available at  the 
time from Digital Research,  but the preliminary system  informa-
tion we were able to obtain at the time was sketchy; we could not 
get enough details to allow a reasonable evaluation.

5)  I  should note here that Software 2000 requests end users  to 
report problems to the dealer from whom they purchased the system 
(MuSys in our case); if for some reason the dealer cannot resolve 
the problem,  it then is the dealers responsiblity to put the end 
user in contact with Software 2000.

6)  There is a fundamental difference between Turbodos  and  MP/M 
with  respect to the "pass command line" system call that  should 
be  noted  here.   While  MP/M immediately  executes  the  passed 
command line, Turbodos "stacks" the line, and will not execute it 
until the calling program terminates.

7)  A similar capability now exists for CP/M,  using my  SUPERSUB 
program (see the January, 1981 issus of Lifelines).

8)   This  is  a  system-wide  requirement  in  all  drivers  and 
processes.   Transient  programs,  however,  are controlled by  a 
module  called  "LOCUSR",  which  supports  "private"  X-register 
usage, as well as a simulated BIOS jump table.


                 - Copyright acknowledgements -

TURBODOS is a copyright of Software 2000.
NET-82 and MUDOS are copyrights of MuSys Corp.
Z80 is a copyright of Zilog, Inc.
CP/M, MP/M and CP/NET are copyrights of Digital Research.
WORDSTAR is a copyright of MicroPro International.
REFORMATTER is a copyright of Microtech Exports
RECLAIM is a copyright of Lifeboat Associates.
KILOBAUD  MICROCOMPUTING  is a copyright of Wayne  Greene  Publi-
cations
