Print
TDOS8.WS4
---------
- "For Networks and Multi-user Systems -- TurboDOS"
  Ron Fowler
  "Microsystems", Vol.5, No.8, August 1984, p.58
(Retyped by Emmanuel ROCHE.)

Gone  are the days when simple operating systems satisfied the needs  of  most
small-system  users. Once written primarily to satisfy the  relatively  modest
requirements  of hobbyists and experimenters, microcomputer operating  systems
are  now designed for performance, with special concern for providing  maximum
versatility to the user.
One  such  operating  system is TurboDOS, a product  of  Software  2000,  Inc. 
Written  originally for the Zilog Z-80 (and recently converted for  the  Intel
8088/8086  family), this package offers a high degree of  CP/M  compatibility,
multi-tasking background processing, powerful networking capability,  built-in
communications facilities, print spooling, and much more.
This article will take an in-depth look at this powerful system: what you  can 
expect  to  gain by using TurboDOS, and what (if anything) you might  lose  by
giving  up CP/M in favor of TurboDOS. We will examine the  TurboDOS  operating
system  and its utilities in detail, and conclude with a section addressed  to
the   programmer   or  system  developer  interested   in   writing   TurboDOS
applications.
(ROCHE> Unfortunately, when I read this article, 30 years later, it is obvious 
that  Ron  Fowler  had no experience of MP/M,  the  multi-tasking,  multi-user
version  of  CP/M...  By  the way, each time that he  says  "CP/M",  you  must
understand:  "CP/M  2.2". TurboDOS is, in fact, a multi-processor  version  of
MP/M.  That's why it is more compatible with MP/M than with CP/M  (2.2)!  Poor
Ron  Fowler,  not  knowing  MP/M, is often ecstatic  by  the  capabilities  of
TurboDOS, which are exactly (except multiple processors) those of MP/M...)

Background
----------
Much   of  the  information  presented  here  is  based  on  my   own   custom 
implementation  of TurboDOS Release 1.3. The evaluation copy of  the  software
was provided courtesy of North Star Computers, Inc. North Star provides a full
implementation for their own hardware, and offers it bundled with  Turbo-Plus,
a TurboDOS enhancement package (which I hope to review in a future article).
While  the  1.3 Release of TurboDOS provides Intel  8088  compatibility,  this 
discussion  is limited to the Zilog Z-80 version. The evaluation system  is  a
networked  version,  interconnecting  a Z-80-based S-100  Bus  system  with  a
disk-less  single-board  Z-80 computer, through Intel 8255 PIO chips  in  each
computer.  Figure 4 is a schematic of the circuit used to interconnect  the  2
systems.
The  S-100  Bus  system consists of an Integrand  mainframe  housing  a  Delta 
Products 4-MHz Z-80 CPU, 128K of CompuPro memory, and various I/O boards.

Overview
--------
TurboDOS  is  structured in a 2/3 arrangement: the main body of  the  TurboDOS 
operating system is analogous to CP/M's CCP and BDOS. This portion is machine-
independent,  and is supplied as a group of Microsoft-format REL  (relocatable
machine  code) files. The remainder of the system is similar to  CP/M's  BIOS,
and  consists  of a collection of *DEVICE DRIVERS* (for such  things  as  disk
drives,  printers,  and  network communications).  These  driver  modules  are
written  by  the system integrator; if you purchase a packaged  system,  these
drivers are already written for you.
The modular design of the TurboDOS operating system allows it to be configured 
in  an  almost infinite variety of forms. Table 1 lists a number of  the  more
commonly-used modules.
Table 1. Common TurboDOS modules
(NOTE: Modules denoted by an asterisk (*) after the module names are  resident 
processes.)
Name    Function
----    --------
LCLUSR* Supports the Transient Program Area
LCLMSG  Contains the system error messages
CMDINT  Command line interpreter, similar to CP/M's CCP
AUTLOG  Supports COLDSTRT.AUT and WARMSTRT.AUT files
NETSVC* Services  network requests. Necessary only in processors that  provide
        facilities to the network (servers)
NETREQ  Makes requests of the network
NETTBL  Defines network topology from viewpoint of the local node
DSPOOL* Printer de-spooler (background print)
FLUSHR* Periodically flushes disk buffers
OSNTRY  Decodes system calls (C-functions and T-functions)
FILMGR  Handles the local file system.
        Nodes without disk storage do not require this module.
FILLOK  Handles file interlocks
FFOMGR  Handles the special FIFO files
FASLOD  Fast program-load optimizer
BUFMGR  Manages the disk buffers
DSKTBL  Defines the available disk drives (local and remote)
CPMSUP  Special support for CP/M.
        Makes TurboDOS operating system more CP/M-compatible.
CONMGR  Handles all console I/O
CONTBL  Connects CONMGR to hardware console driver module(s)
DOMGR   Handles batch commands
LSTMGR  Handles printer output
SPOOLR  Handles background spooled-print functions, as well as routine printer
        output over the network
RTCMGR  Maintains system date and time (real-time clock)
BNKMGR  Banked memory support
DSPCHR  Multi-tasking  kernel;  controls  CPU  dispatching  between  competing
        processes, as well as synchronization and inter-process communications
DSPSGL  Special "null" dispatcher; allows a non-multi-task version of TurboDOS
        to be created
MEMMGR  Controls dynamic allocation of memory
OSLOAD  Special module used to create a loader program
COMSUB  Common subroutines needed in all versions of TurboDOS
Each major function is isolated in its own module, many of which can be  added 
to  and  deleted from the TurboDOS operating system by the user  (ROCHE>  ?  A
*USER*  fine tuning a Disk Operating System?), thus providing the  ability  to
add  or  subtract functionality. For example, the SPOOLR module  contains  the
necessary  code to implement the TurboDOS print spooling  function  (described
later). By deleting this module in systems that do not require print  spooling
(e.g.,  single-user  systems),  the  TurboDOS operating  system  can  be  made
smaller, allowing more room for disk buffers and transient programs.
Flexible as this assortment of modules may be, it would be demanding a lot  to 
ask  all  users to build their own TurboDOS operating system. To  avoid  this,
TurboDOS  is  packaged with a number of "standard" versions  (Table  2),  each
providing a commonly-required configuration.
Table 2. Standard TurboDOS configuration packages
Name      Function
----      --------
STDLOADR  Cold-start system loader
STDSINGL  Single-user version, no spooling
STDSPOOL  Single-user version with spooling
STDMASTR  Network master
STDSLAVE  Network slave without local disks
STDSLAVX  Network slave with local disks
(ROCHE>  So, The first 3 versions correspond to CP/M, and the last 3  versions 
to MP/M. Note the emphasis on spooling. In fact, Digital Research was  selling
one  DESPOOL  program for CP/M Versions 1 and 2, but it only ran  reliably  on
DRI's Intel MDS-800 microcomputers...)
The system may be configured (and reconfigured) conveniently by using GEN.COM, 
the  supplied  system  generation  utility.  This  program  is,  in  fact,   a
sophisticated  linkage  editor  that  takes  its  commands  from  disk  files,
providing  a  high degree of automation in the system generation  process.  An
additional file (called a PAR file) can be specified to GEN.COM. The PAR  file
references, *BY NAME*, parameters within the system. It is a powerful concept:
you  can  restructure  major  portions of the  system  (such  as  the  network
definition  tables,  disk assignment tables, command-search  paths,  and  many
others) merely by editing the PAR file and regenerating the system.
Most implementations of TurboDOS provide for a boot PROM, allowing the  system 
to start up automatically at power-on. The boot PROM contains just enough code
to  load a file named OSLOAD.COM into the program area. OSLOAD then brings  in
the  rest of the TurboDOS operating system. My own implementation  boots  from
CP/M,  running  OSLOAD as a CP/M transient program. This suits  my  particular
needs better than setting up a boot PROM -- and, incidentally, illustrates the
versatility of TurboDOS.
When  the  TurboDOS operating system start up, it prints  a  sign-on  message, 
followed  by the system prompt. This is where TurboDOS begins to  differ  from
standard CP/M: the prompt contains the user number, as well as the drive name.
(TurboDOS supports 32 user numbers -- twice as many as CP/M; and the  familiar
angle  bracket  prompt  character of CP/M is replaced with  a  curly  bracket:
"A}".)
Depending on how the system is set up, it may be necessary to *LOG IN*  before 
any useful work can begin. A utility, LOGON.COM, is provided for this purpose,
and  another,  LOGOFF.COM,  is used to terminate the  session.  TurboDOS  may,
optionally,  be  instructed  to maintain a file of  logons  and  logoffs,  and
require  that a password be specified at login. Passwords are maintained in  a
special user accounts file maintained with a text editor. Additional  security
allows  logon  to  be retricted to a single user  area  (this  restriction  is
specified  in  the  user accounts file). Another  login  option  provides  for
privileged  logins  (non-privileged  logins may not  change  user  areas,  and
several of the supplied utilities will function only for privileged logins).
The  rhythm of this system is a bit different from that of CP/M. For  example, 
there  is no warm boot, since the entire TurboDOS operating system remains  in
memory  at  all  times.  (CP/M 2.2, of  course,  allows  the  Console  Command
Processor  to be overwritten by a user program, thus requiring that a  portion
of  the  CP/M 2.2 operating system be read back in from disk  when  a  program
terminates) (ROCHE> CP/M Plus ("CP/M Version 3" in the USA), launched in  1983
(so,  one year before this article), is a single-user version of  MP/M...  So,
since it supports "banked memory", the CCP is reloaded instantly from  memory.
Each  time CP/M Version 2 was spending too much time reading the floppy  disk,
the  data was stored in memory. 2 examples: the CCP and the directory.  That's
why CP/M Plus, in a good implementation, is much faster than CP/M 2.2  running
on the same hardware.)
Additionally,  there  are  no built-in commands; all commands  are  loaded  as 
transient  programs from the disk. Hence, functions such as ERASE  and  RENAME
take  a bit longer to complete than their CP/M 2.2 counterparts, because  time
is  needed to load them. Most of the utilities, however, make up for  this  in
expanded  power and versatility, as we shall see. In any case, if a hard  disk
is used, the extra time is so small as to be unnoticeable.
From the command level, TurboDOS works similarly to CP/M in that commands  are 
typed  into  the  system, and the specified files are  executed  as  transient
programs.  If, however, your TurboDOS is part of a network, the  programs  and
files  that  you use are not necessarily located on your  local  computer  (in
fact,  your  local  computer may not even have any  storage  facilities  (disk
drives) at all!). This networking capability is one of the strongest  features
of TurboDOS, and we will examine that aspect of the system in detail later.

CP/M compatibility
------------------
TurboDOS  is  compatible with almost all CP/M programs. There are only  a  few 
CP/M  programs  that I have seen that do not work properly under  TurboDOS  --
mostly  public  domain  utilities that access some of the  more  obscure  BDOS
system  calls  (7, 8, 24, 28, 29, 31, and 100-107). However, TurboDOS  may  be
installed  with  an  optional CP/M-support module  that  will  simulate  these
missing functions.
Another  incompatibility  involves  CP/M's SUBMIT processing: I  am  aware  of 
several  commercial packages that make use of CP/M 2.2's special $$$.SUB  file
for batch-command processing, and that do not work under TurboDOS because  the
$$$.SUB  file  is  not processed. Another optional module  is  supplied,  that
modifies the TurboDOS batch function to emulate CP/M 2.2 more closely (but  at
the  expense  of slowing down DO file processing). The packages  mentioned  do
work properly under TurboDOS if this module is installed.

Multi-tasking the CPU
---------------------
Beginning  a more detailed study of TurboDOS, one of the first things that  we 
should  note  is  that  it can execute more than one  task  at  a  time;  this
capability  is usually referred to as *MULTI-TASKING*. (ROCHE> And  MP/M,  the
multi-user,  multi-tasking version of CP/M, had done it for at least  5  years
when this article was written...)
Integral to the concept of multi-tasking is the *RESIDENT PROCESS*. A resident 
process is a program that executes within the system; under TurboDOS, resident
processes  are  physically  attached to the operating  system,  but  logically
maintained  outside  of  it.  (That is to say:  they  perform  their  task  by
executing  operating system calls, in the same way that user programs do.  The
difference  is  that  user programs are transient in  nature,  while  resident
processes are always present.)
At  any  given time, a process may be in any of 3 states:  ready,  running  or 
suspended. A running process is one that is currently executing on the CPU;  a
ready  process  is  one that is waiting to execute (but  otherwise  ready).  A
suspended  process (sometimes referred to as "blocked") is a process  that  is
waiting  for some event to happen, or waiting for a period of time to  expire.
(TurboDOS provides a system call that allows a process to delay execution  for
a fixed time interval.)
The  suspended  state  is  perhaps the most significant.  A  process  that  is 
suspended  is  "stacked"  on  one  of  a  number  of  special  lists   (called
"semaphores"), and thus does not slow down the system by consuming CPU cycles.
At any given time, most processes will be in this suspended state. Hence, user
programs  that  are CPU-intensive (i.e., spend most of their  time  processing
data rather than waiting on I/O devices) run nearly as fast as they would on a
single-task system.
A  number  of "background" processes, present in each  CPU  running  TurboDOS, 
perform  such actions as monitoring the network, flushing disk  drive  buffers
periodically,   etc.   Additionally,  user-written  resident   processes   are
supported;  any  such  process is physically part of  the  TurboDOS  operating
system, and must be added to TurboDOS when the operating system is generated.

Banking the system
------------------
TurboDOS makes good use of bank-selectable memory. When more than one bank  is 
available,  most  of  TurboDOS resides in Bank  0,  while  transient  programs
execute  from Bank 1. (ROCHE> Exactly like CP/M Plus, the single-user  version
of  MP/M,  launched  one year before this article...)  Since  a  full-featured
network-master version of TurboDOS exceeds 24K in size, this frees up a lot of
program  area.  (ROCHE> That's why MP/M used banked memory, since MP/M  was  a
multi-user version of CP/M. So, each user wanted to have its own TPA, and most
CP/M program wanted as much RAM as possible... So, the only technical solution
was to provide "banks" of memory to each user.)
Banked  systems are often measured by the amount of *COMMON MEMORY* that  they 
consume.  Common memory is a section of memory (usually located physically  at
the top of the address space) that is always present within the CPU's  address
space,  regardless of which memory bank is switched in. Since the  Zilog  Z-80
CPU  is limited to 64K of total address space, it is obvious that the  common-
memory  requirement increases at the expense of the banked segments, and  thus
at  the  expense  of  memory available to  transient  programs  (in  the  case
of TurboDOS, at the expense of the allowable size of the operating system).
The  only portion of TurboDOS that *MUST* remain in common memory is  a  small 
inter-bank communications module, plus some portions of the  interrupt-service
routines.  (ROCHE>  Exactly like MP/M and CP/M Plus...) Thus,  the  amount  of
transient program area (TPA) available is 63K, even if banked memory  hardware
allows  bank  switching only on 4K or 16K boundaries.  (ROCHE>  Nothing  news,
here.  There is even a version of CP/M 2.2 for the Epson QX-10 having a  63.5K
TPA!...)
A  utility  program,  BANK.COM, allows the TurboDOS  operating  system  to  be 
switched between banked and non-banked mode. When non-banked mode is selected,
programs must share Bank 0 with the operating system.

Disk drives and files
---------------------
TurboDOS  supports file sizes of up to 32MB (ROCHE> Like CP/M Plus...)  and  a 
disk  drive  capacity of up to 134MB (ROCHE> CP/M Plus:  512MB...  Of  course,
compared to the 8MB of CP/M 2.2, this appeared to be an improvement...  Except
that  CP/M  Plus had been launched by Digital Research one  year  earlier!...)
Obviously, such large drives will have a lot of files, and will need a lot  of
seek  time  during  such operations as file opens,  directory  searches,  etc.
(ROCHE>  That's  why  directories are cached in CP/M Plus.) In  an  effort  to
decrease  this  time, TurboDOS supports a special directory  format  called  a
*HASHED  DIRECTORY*. (ROCHE> MP/M and CP/M Plus did not go this way.)  A  disk
directory  may, at any time, be restructured as a hashed  directory  (although
the opposite is not true) by running a program named FIXDIR. (ROCHE> CP/M Plus
has  something roughly similar, INITDIR.COM, which restructures the  directory
to  add date and time stamping of files.) Although hashing the directory  made
little difference on my small-capacity floppy disks, a hardware dealer I  have
worked  with  (who  sells TurboDOS on IMS systems) reports  a  dramatic  speed
increase  on his 40MB hard disk systems. (ROCHE> I am not surprised. Me,  from
experience, I only use INITDIR on floppy disks, since it consumes 1/4th of the
directory.  On the hard disk, I simply type the date and time at the  head  of
the files.)
Another technique used by TurboDOS to increase performance is disk  buffering. 
(ROCHE>  Called "disk caching" in CP/M Plus.) The system contains  a  built-in
buffer  manager;  moreover,  a  utility program  supplied  with  the  TurboDOS
operating  system, BUFFERS.COM, lets you change the size of each  disk  buffer
and  the number of buffers *WHILE THE SYSTEM IS RUNNING*. (ROCHE>  Under  CP/M
Plus,  this  is  done at system generation time, with GENCPM,  by  the  system
implementer.)  These buffers are taken "off the top" of the transient  program
area (TPA) (in unbanked versions of TurboDOS). If you are going to run  small,
disk-bound  programs, you can set up a large number of buffers,  and  increase
disk  access  speed.  Conversely, memory-hungry programs  (such  as  WordStar)
should  be  run with a small number of buffers, to provide as much  memory  as
possible.  (ROCHE> Well, with "banks" of memory, each user has its own 64K  of
memory...)
(I  should  point out that, while directory hashing  made  little  performance 
difference  in my system, increasing the number of disk buffers in the  system
increased  disk  throughput dramatically.) (ROCHE> That's  why,  after  tests,
Digital Research added disk caching to CP/M Plus.)
Systems  using banked memory may set up most of the unused part of Bank  0  as 
disk buffer space, and not affect program memory space at all.
A  fast file-load function supplies yet a 3rd performance increase:  generally 
used by the Command Interpreter (the portion of the TurboDOS operating  system
that processes user command lines), this module allows a section of memory  to
be  loaded  in  the fastest manner possible. It works  by  scanning  the  disk
allocation  map, detecting sequentially-allocated segments, and loading  these
segments  at the fastest transfer rate of the disk controller.  (ROCHE>  Under
CP/M  Plus,  the CCP is reloaded from a system Bank, so it is  just  a  memory
transfer,  and  using  the  "Multi-Sector Count", allowing up  to  16K  to  be
read/written in one shot...)

File attributes
---------------
TurboDOS  expands  on the file attributes employed by CP/M. (ROCHE>  ???)  The 
CP/M "SYSTEM" attribute is replaced by the "GLOBAL" attribute. Files  resident
in  User area 0 and tagged as GLOBAL are accessible from any user  area,  thus
circumventing the need to duplicate frequently-used files in each user area of
the  disk. (ROCHE> Under CP/M 2.2! But MP/M had been available for at least  5
years  when  this article was written, and CP/M Plus one  year!)  This  global
access  applies  equally to files that are accessed  by  application  programs
(such as WordStar's overlay files), or chained BASIC programs.
ARCHIVE  is another (ROCHE> CP/M...) file attribute that saves time and  space 
when  backing up files. New files are created with the ARCHIVE attribute  off.
When a file is backed up using the COPY program, the ARCHIVE bit is set;  when
a  file  is changed (extended, or written to with a  random  write),  TurboDOS
resets  the ARCHIVE attribute. COPY can be instructed not to copy  files  that
have  been archived and have not been modified since. This process  is  called
"incremental backup". (ROCHE> And is provided by CP/M Plus' PIP...)
The final "new" file attribute is FIFO (ROCHE> This is specific to TurboDOS.); 
it  defines  a  special type of file accessed using  a  "first-in,  first-out"
(FIFO)  technique. FIFO files are accessed from programs like any other  file,
except that sequentially-written records are appended at the end of the  file,
and  sequential reads are taken from the beginning. Moreover, a FIFO file  may
be  declared as an in-memory file (accessed much faster, since it really  does
not  exist  on  disk at all; this limits the size of  the  file,  however,  to
available  memory.) (ROCHE> Most CP/M Plus implementations have a RAMdisk,  so
the  limit  is 32MB, in this case.) This whole scheme provides  a  very  handy
technique for passing data between background processes, and between  programs
executing on different processors. Since a FIFO file can be made to  "suspend"
(deactivate)  a process reading the FIFO file when it is empty, it is easy  to
visualize a background process that only "comes alive" when a program posts  a
record to a file monitored by the background process.
Two special utilities are provided to work with FIFO files: SEND and  RECEIVE. 
SEND  is invoked with a FIFO filename and a text string to place in the  FIFO.
RECEIVE  takes  only a FIFO filename; it reads one record from the  FIFO  file
(thus deleting the record) and displays it. Together, these 2 utilities may be
used to form a rudimentary mail facility between users. (ROCHE> Better to  use
CP/NET, which has been available for years...)

File interlocks
---------------
TurboDOS  features  file  and record lockouts, since  it  supports  background 
processes  that may access files at the same time as foreground processes.  In
fact,  network support for shared files requires at least one such process  in
each  file system offering file resources to the network. Interlocks are  used
to coordinate file accessing by multiple simultaneous processes and necessary,
for example, when an update program must replace an inventory item's wholesale
and  retail price fields. With no coordination, a querying program might  read
the  record sometime after the update program has begun writing new data,  but
before  the write is complete. Hence, the querying program reads  inconsistent
data.  With record locking capability, however, the update program can  obtain
exclusive  access to the record, "locking out" any other process that  may  be
attempting to access the same record.
File lockouts under TurboDOS may be configured for strict MP/M  compatibility; 
thus,  existing programs written for MP/M's record-locking techniques  (ROCHE>
Like Digital Research's Access Manager...) will work correctly under  TurboDOS
(ROCHE>  Fortunately,  since TurboDOS is a multi-processor  version  of  MP/M.
Hence the need to be compatible with its parent. It is the classical  "chicken
and  egg" problem.) Alternatively, a set of compatibility flags  is  available
(during system generation) to change certain rules, providing a number of  new
modes  not  previously available under MP/M. (ROCHE> Modes  which  disappeared
with TurboDOS, while CP/M is still alive, 30 years later...)

Networking
----------
TurboDOS  provides a plethora of features, facilities, and utilities, but,  to 
me,  the  single most outstanding one is its built-in  networking  capability.
(ROCHE>  Never  heard of MP/M, launched 5 years earlier by  Digital  Research?
Never  seen  the advertisements for CP/NET in computer magazines? Why  do  you
think that TurboDOS is compatible with MP/M? For pleasure?) Multiple computers
running  TurboDOS  may be interconnected and share such  relatively  expensive
peripherals as disk drives, printers, plotters, etc.
In  this  discussion,  I  will use  the  terms  "node","CPU"  and  "processor" 
interchangeably.  (ROCHE>  Not a good thing. It shows that the  concept  of  a
network  is  still  a novelty for you. You should have read  the  MP/M  guides
published  several years earlier...) Generally, a node can be thought of as  a
workstation containing a CPU, memory, a network interface, and (optionally)  a
terminal, disk drives, and printers. A node is attached to the network via one
or  more  connection  points. It usually has some peripherals,  but  does  not
*REQUIRE* any.
Two  other terms will be used to refer to processors on the network:  *MASTER* 
(or  *SERVER*)  and *SLAVE* (or *SATELLITE*). Generally,  a  server  processor
provides  resources  to the network (such as disk  storage  and/or  printers),
while  satellites  do not. If satellites have local disks, these can  also  be
available to the network if the satellite contains the network service  module
(NETSVC).
First,  it is important to note that TurboDOS does not support multiple  users 
on  a single CPU. (ROCHE> Yes, since TurboDOS is a multi-processor version  of
MP/M.)  The  philosophy,  here,  is that,  since  processors  and  memory  are
relatively  cheap, why attempt to split up a hundred dollars or so in CPU  and
memory  hardware  when each user can have his own CPU and memory,  and  suffer
none of the processing delays that are so severe in such operating systems  as
MP/M  and  OASIS?  (ROCHE>  Good  question.  By  the  way,  why  did  TurboDOS
disappear,  while  MP/M  and OASIS are still running, 30  years  later,  under
emulators on the Internet?)
This concept works, and works well. (ROCHE> You should tell Intel, which never 
managed  to  make  its 8086 works this way. I  cannot  resist  mentioning  the
following, taken from "Chapter 1: Introduction" of the "Intel 8088/8086 Family
User's Manual", October 1979 (Yes, 5 years *EARLIER*!), page 1-1:
        "The 8086 family architecture is characterized by 2 major principles:
     1. System functions are distributed among specialized components.
     2. Multi-processing capabilities are inherent in the hardware.
     3. A  hierarchical bus organization provides for the complex  data  flows 
        required by high-performance systems without burdening simpler systems
        with unneeded capabilities."
This was written in 1979, for a CPU running at 4-MHZ. Today, *45 YEARS LATER*, 
Intel  has  not  been  able to produce even  a  single  computer  using  those
"principles"...  So, why did Intel, the richest microcomputer company  in  the
world, never managed to do it, while Software 2000, Inc. (e.g., Mike Busch and
Ron Raikes), did it? Was the Zilog Z-80 CPU so much better than the Intel 8088
of the IBM Clown?)
Each  user has full use of his own CPU; delays are generally  noticeable  only 
when shared disk drives are simultaneously accessed by multiple network users.
(Even   these  delays  can  be  abated  by  using  faster  drives  with   more
sophisticated seek mechanisms -- a cost that can be justified more easily with
TurboDOS,  since these expensive peripherals are more easily shared among  all
the users.)
TurboDOS  supports just about any kind of local network, ranging  from  simple 
implementation involving 2 computers (liked through,say, an RS-232-C channel),
to sophisticated structures with many processors sharing resources over  high-
speed  data  channels. The actual network structure is defined by  the  system
designer,  and  implemented  in  the network  driver  modules.  These  modules
constitute  what is known in network vernacular as the "physical layer";  they
control the hardware that interconnects the computers.
TurboDOS  defines  the network as being composed of *CIRCUITS* (which  can  be 
better  visualized as a cluster of nodes). A circuit may be composed of up  to
255  nodes. Further, there may be up to 255 interconnected circuits in a  full
TurboDOS system, allowing for a total of up to 65,535 total workstations in  a
TurboDOS network.
The unit of information exchange among network nodes in the *NETWORK MESSAGE*. 
This  message  is  a packet of data, containing source  and  destination  node
addresses,  byte length and other overhead, as well as the actual data  itself
(which may be a disk record, a file control block (FCB), or perhaps a block of
characters to be sent to a printer).
A  "forwarding" table may be specified in each node, allowing messages  to  be 
sent between network nodes that are not, themselves, directly connected.
One of the most common techniques that I have seen for implementing a  network 
with  TurboDOS  involves  S-100 Bus  single-board  computers.  Generally,  one
"master"  CPU is provided (to control access to disk drives, printers,  etc.),
and  one  or more "slave" processors are placed on the same S-100 Bus  as  the
master  (often these slaves have no local storage of their own  but,  instead,
rely  on  the master to provide storage. The user will see the  master's  disk
drives  as  if  they were connected to his  own  CPU.)  Typically,  high-speed
parallel-port  channels  are provided to allow network transfers  at  near-bus
speeds.  One  such system will, generally, be a circuit  in  itself;  multiple
systems may, then, be interconnected, forming a multiple-circuit network.
        Figure 1. A typical network
An  example should help tie this all together. In Figure 1, we have 2  network 
circuits  that  are  relatively independent. Each circuit  has  a  master  and
several  slaves,  as  well  as disk  drives  and  a  printer.  Master-to-slave
communication   is  through  a  high-speed  parallel   bus.   Master-to-master
communication is through a Local Area Network (LAN) interface and cable.  Note
that  slave  nodes do not have any local disk storage but,  instead,  use  the
master's  disk  drive (this will likely be a large-capacity hard  disk  drive,
segmented  into  several smaller drives, and apportioned  among  the  slaves).
Circuit 1 consists of 4 nodes: the master and the 3 slaves. Similarly, Circuit
2  consists of 5 nodes: the master and 4 slaves, 3 of which are connected  via
modems to dial-in phone lines.
Each  of the 2 masters are actually "known" on 2 circuits (their own, and  the 
other  master's)  and,  thus, have 2 circuit  drivers  within  their  TurboDOS
operating systems (and 2 network addresses, as a matter of fact).
This  system  might be part of an overall data-gathering  system  where  field 
agents phone in information to the nodes connected to modems (Nodes 2-2,  2-3,
and  2-4);  the  high-speed dot-matrix printer might be  used  to  maintain  a
"running  log"  of  these transactions. This raw  information  is  sorted  and
formatted  by programs entered by an operator at the terminal located at  Node
2-1 (the only "on-site" terminal in Circuit 2) and made available periodically
to Circuit 1 through the RS-232-C link between circuits, where service  clerks
work  at  terminals,  filling these orders. The  finished  orders  are,  then,
printed  up in the form of invoices on the letter-quality printer  located  on
Circuit 1.
Thus, most information flow between the 2 circuits will take place between the 
2  masters  (perhaps under the control of a resident process in each).  It  is
possible,  however,  to  allow  communications  between  slaves  on  different
circuits, using forwarding tables contained in each slave's operating  system.
This  might  be necessary, for example, to allow field salesmen  calling  into
Circuit  2 to make an inquiry about an order to a clerk working in Circuit  1.
Proper setup of the forwarding tables will allow this (in fact, the Turbo-Plus
enhancement  package  provides  special system functions  and  utilities  that
simplify this kind of communication).

Reconfiguring the network
-------------------------
Although  the physical network is defined in network driver modules,  TurboDOS 
provides  a lot of latitude in reallocating resources, using  the  previously-
mentioned  GEN  program.  Although  these  resources  are  not   *DYNAMICALLY*
changeable  (that  is  to  say: you cannot make  changes  while  the  TurboDOS
operating  system is running), it is a relatively simple matter to  patch  the
tables, and regenerate the system.
        Figure 2. Drive allocation example
An  example  should  help to clarify this. Referring to Figure  2,  we  see  2 
processors, named P1 and P2, each with local drives A and B. From the diagram,
you  can  see  that  each  processor has a drive  C,  which  is  the  opposite
processor's B drive. (These assignments are made in a table contained in  each
node's  copy of TurboDOS; this table is called the Disk Assignment Table,  and
is usually set up in a PAR file.)
        Figure 3. Allocation after regeneration
Now,  let  us consider changing that. Let us say that we want to  delete  P2's 
ability  to  reference P1's B drive, and increase P1's  available  storage  to
include P2's drive as P1's D. We simply make a few changes in each node's  PAR
file,  regenerate  each TurboDOS operating system, and we have  the  structure
shown  in Figure 3. This concept applies to other resources, such as  printers
and print queues.

Printers and spooling
---------------------
Flexibility is apparent throughout the design of TurboDOS, but nowhere is this 
more evident that in the facilities available to produce printed output.
Each  processor  may have up to 16 printers defined in its  tables,  and  each 
printer  may  be accessed either locally or over the network.  Since  TurboDOS
provides a CP/M-like environment, only one of these printers may be  "current"
at  any  one  time for any one user. A utility program,  PRINT.COM,  lets  you
change the routing of your logical printer output, using syntax such as:
        PRINT PRINTER=E   (or PRINT P=E)
which selects Printer E in your local printer table. In addition, this utility 
allows  you  to  select  a  much more  flexible  form  of  printing:  *SPOOLED
PRINTING*.  (ROCHE>  Ever  heard of the "DESPOOL  (background  print  utility)
Operator's Guide", Digital Research, 1979? No? It was frequently found in CP/M
Version 1.4 and Version 2.2 advertisements...)
Spooled  printing reroutes your printer output: instead of going  directly  to 
the  printer, the output is routed to one of 16 *PRINT QUEUES*. A print  queue
is  implemented  as a set of disk files, using filenames of the  form:  PRINT-
x.nnn,  where  x  is  the queue name (A-P, corresponding to  each  of  the  16
possible queues) and nnn is a 3-digit number used to separate different  print
jobs within a queue.
Another  utility, PRINTER.COM, controls despooling of these print queues.  Any 
physical  printer may be assigned to any of the queues with a command such  as
PRINTER  E  QUEUE=C  (to  assign Printer E to the C  Queue).  A  3rd  utility,
QUEUE.COM, allows files to be manually entered into any of the various queues.
Let us tie this all together with an example: suppose your TurboDOS  operating 
system has 2 printers: Printer 1 is a fast dot-matrix printer, while Printer 2
is a slower letter-quality model (remember, either printer may be attached  to
our local network node, or to a remote node -- it does not matter *WHERE*  the
printer to be used is actually located). Assume that we have to print  several
program listings, a couple of letters, and a long report.
First,  we  will tackle the letters, since they will likely  use  single-sheet 
paper, requiring a good deal of manual intervention. The command:
        PRINT PRINTER=B
gives  up  direct access to the letter-quality printer (we  must  be  careful, 
here, to coordinate access with any other network users, since direct printing
by  more  than one user will result in interspersed characters in  the  actual
printout). Now, we fire up the word-processor program, and print each  letter.
Not  so  different  from  CP/M,  so far (except  for  the  ability  to  switch
printers).
Now,  let  us tackle the program listings. We can begin to make use  of  print 
queues, here, by entering the following commands:
        PRINTER A QUEUE=A
        PRINTER B QUEUE=B
Now,  we have established Queue A as the queue associated with the  dot-matrix 
printer,  and  Queue B with the letter-quality printer. Now, we are  ready  to
print some listings. The command:
        PRINT QUEUE=A
routes our printer output to Queue A; now, we can run our language  translator 
and  begin producing the program listings. Since our output is now going to  a
relatively  high-speed disk file (as opposed to a slow printer), the  language
translator finishes long before the first printout is complete.
In  fact, the first output file does not begin printing until  its  associated 
queue  file  is  closed (either by the  language  translator  terminating  and
returning to the TurboDOS operating system, or by a special end-print  control
sequence  from  the  console).  While  the first  file  is  printing  (in  the
background), we can run our language translator once more, to generate the 2nd
and 3rd listings. We might also decide to queue some existing disk files:
        QUEUE MYPROG.PRN ;Q=A
        QUEUE MANUAL.DOC ;Q=A
        QUEUE *.UPC ;DYQ=A
(Note  that the Q=A options specify which queue to send the file to.  The  3rd 
example illustrates queuing multiple files by specifying a wildcard  filename.
Additionally,  the ;DY portion specifies options. In this case, D causes  each
file to be Deleted after printing, and Y causes the QUEUE program to displa(Y)
the name of each file to be queued, allowing the operator to select  specified
files.)
Now, we are ready to print the letter-quality documents. The command:
        PRINT QUEUE=B
switches  our printer output to the queue we have previously  associated  with 
the  letter-quality printer. (It does not matter that the files that  we  have
already  queued are still printing; they are now destined for  the  dot-matrix
printer, and changing the destination of our printer output no longer has  any
effect  on the previously-queued files.) Now, we can use  our  word-processor,
and  send  the letters and the report to the B Queue, similar to the  way  our
language translator output went to the A Queue.
At  this point, we have 2 printers running a number of print jobs entirely  in 
the background, and our console is free for new work. In addition, any  number
of network users can simultaneously queue files on the same printers,  without
intermixing printer output.
To  conclude  the discussion, I must mention that there are  many  more  print 
options  and  features  than those mentioned here; to  review  each  of  them,
however, is beyond the scope of this article.

Batch files
-----------
TurboDOS  allows  the  execution of batch-command files in a  way  similar  to 
CP/M's  SUBMIT facility, but with enhanced capabilities. The TurboDOS  version
of SUBMIT is named DO.COM; specifying DO with a filename will cause the system
to begin reading its input from the file.
DO  files  may  be  nested (ROCHE> Like SUBMIT under  CP/M  Plus...),  to  any 
reasonable depth (ROCHE> 128 levels under CP/M Plus.), merely by placing a  DO
statement within a DO file. After the subservient DO file is executed, control
returns to the superior file at the point where processing left off.
Command-line parameters may be specified in a manner similar to CP/M's SUBMIT. 
However, the parameters are referred to, in the DO file, by enclosing them  in
curly  brackets,  rather  than the dollar sign notation  of  CP/M.  Also,  the
parameters  in the DO command line may be made to contain embedded  spaces  by
enclosing them in quotes.
A handy option within the DO file allows default parameters to be filled in by 
adding  a  comma and a default value within the curly brackets.  Consider  the
following line within a DO file:
        L80 {1} {2,SYSLIB}
If  this  DO file is invoked only with Argument 1, then the  value  SYSLIB  is 
automatically supplied as the 2nd Argument.
Another  important characteristic of DO files is that they can  provide  input 
for  more than just system commands. Programs that require  interactive  input
will  receive that input from the DO file (thus, DO combines the  features  of
both  the  CP/M 2.2 programs SUBMIT and XSUB). (ROCHE> CP/M Plus  has  a  much
better and more powerful SUBMIT utility.)
DO  is somewhat faster than CP/M 2.2's SUBMIT when no command-line  parameters 
are  specified. Since there is no need to rewrite the DO file with  parameters
filled in, DO simply informs TurboDOS to begin executing the file (SUBMIT must
always write a $$$.SUB file).

Utilities
---------
TurboDOS  is  supplied with a large number of utilities, some  of  which  have 
already been described. The major remaining utilities are as follows:
AUTOLOAD  allows a user to set up command lines that automatically execute  on 
either  cold  or warm boot. COLDSTRT.AUT, the cold boot  file,  executes  only
once, when the TurboDOS operating system is first started up. WARMSTRT.AUT  is
executed at the completion of each transient program.
BACKUP  performs  a  fast disk copy. It is usable only  when  the  source  and 
destination diskettes are of the same format.
BATCH  is useful in network environments, and uses a special FIFO file  (named 
BATCH.DO)  to send a command line to a remote processor for execution.  Remote
processors  that use this facility (i.e., those which are to be available  for
batch  jobs) must execute the command DO BATCH via an AUToload file at  system
startup.
BOOT allows the system tracks of a diskette to be copied to another  diskette. 
Note  that TurboDOS allows 100% of the floppy disk space to be used  for  file
storage; however, in some implementations, the hardware demands  cold-starting
from reserved system tracks.
CHANGE  is used to safely allow removable disks (i.e., floppies  or  removable 
cartridges)  to be changed in a network environment. CHANGE.COM takes  one  or
more  drive  letters  as arguments, and aborts with an error  message  if  any
process has open files on the requested drive. If the requested drive is free,
CHANGE locks the drive until the user indicates that the disk has been changed
(any  user trying to access the drive while it is locked will receive  a  disk
error message).
COPY,  which was previously mentioned, allows files to be copied between  disk 
drives.  A  large  number  of command-line  options  make  this  an  extremely
versatile file copy and archiving program.
DELETE performs the same functions as CP/M's ERA. A command-line option causes 
DELETE  to  present each filename to be erased, and requests the  operator  to
confirm  before  deleting. (ROCHE> "The CONFIRM option informs the  CP/M  Plus
operating  system  to prompt (the user) for verification before  erasing  each
file  that matches the filespec." CP/M Plus User's Guide, Section  5:  Command
Summary, "The ERASE command".)
DIR prints a sorted directory on the screen (or, optionally, on the  printer). 
The  display  contains  a lot of the information  available  under  CP/M  only
through the CP/M 2.2 STAT command (such as filesizes and disk free space).  It
also  includes  time of day and combined size of files displayed, as  well  as
user-number specification.
DRIVE  displays information about the disk format (similar to CP/M 2.2's  STAT 
DSK:).
FIFO is used to create and delete the previously-described FIFO files.
FIXDIR  is a handy utility that reorganizes a disk directory. This  is  useful 
when  frequent file creations and deletions occur (especially on hard  disks).
FIXDIR  compacts  the directory, eliminates "holes", and makes  file  searches
faster. Also used to convert a directory to the hashed format, or  vice-versa.
(ROCHE>  ???  Ron  wrote "the opposite is not true" in the  "Disk  drives  and
files" paragraph...)
FORMAT  allows  a  diskette to be formatted in single density or  in  CP/M  or 
TurboDOS double-density format. It automatically calls VERIFY after formatting
is complete. (ROCHE> VERIFY marks all the "bad spots" of a disk. That's why it
is used after formatting the disk.)
MONITOR  is  the  TurboDOS replacement for CP/M 2.2's  DDT  program.  Intended 
mainly  for program patching, etc., it contains a save function as well  as  a
load  function  (this  is necessary because TurboDOS  lacks  CP/M  2.2's  SAVE
command). A number of other commands not found in DDT are present in  MONITOR.
(ROCHE> ASM and DDT were provided with CP/M 2.2. MAC and SID were professional
versions that were available separately, at a cost.)
Noticeably  lacking,  however,  are DDT's opcode  assembler  and  disassembler 
(ROCHE>  The A and L commands.), and single-step trace functions  (ROCHE>  The
TRACE  utility  of  SID.).  For program  debugging,  DEBUG  (Phoenix  Software
Associates (ROCHE> Software 2000, Inc., used their PASM to assemble TurboDOS.)
or  ZSID (Digital Research, Inc.) both work well under TurboDOS. (ROCHE>  This
is no surprise...)
RENAME  is  used  to  change the names of files. This  utility  has  a  syntax 
backward from that of CP/M. (Most people who have worked with other  operating
systems  claim that it is CP/M that has it backward. I am inclined to  agree.)
(ROCHE>  You (and them) are wrong. Demonstration: How work the opcodes of  the
(real, physical) processor? You write MNEMONIC DESTINATION,SOURCE... There  is
no  exception  to  this  rule!  So,  is  the  CPU  behaving  crazily?  Another
demonstration:  When you send dozens of different files to the same place.  If
the  destination  is at the beginning of the command line, you just  edit  the
source  specification, conveniently located at the end of the command  line...
which can be reached with one single control char!) This utility has the handy
option  of renaming by using wildcards. For example, the command RENAME  *.BAK
*.ASM renames all BAK files to ASM (a command-line option allows you to verify
any  rename  that  would  cause  an existing file  of  the  same  name  to  be
overwritten). (ROCHE> "If the file given by NEWNAME is already present in  the
directory,  RENAME displays the following message on the screen: Not  renamed:
FILENAME.TYP  file  already  exists, delete (Y/N)?" CP/M  Plus  User's  Guide,
Section 5: Command Summary, "The RENAME command".)
SERVER  has been renamed by North Star. The standard TurboDOS  distributed  by 
most vendors refers to this utility as MASTER.COM. In any case, its purpose is
to allow a slave console to act as a terminal to the master, a function useful
for running programs in the master processor.
SET is used to set and clear file attributes; SHOW displays them. (ROCHE> Just 
like MP/M and CP/M Plus...)
TYPE displays ASCII files on the console or (optionally) on the printer.
USER allows privileged logins to change the currently-logged user number. This 
is one command that I wish had been built into the TurboDOS operating  system.
(ROCHE>  Ron  ported  TurboDOS  Release 1.3. As far as  I  know,  the  Command
Interpreter of TurboDOS Release 1.4 recognizes the small form of changing user
numbers (1:), without the need of running the transient program USER.COM.)
VERIFY scans a disk for bad blocks, and locks them out.

Program interface
-----------------
As you would expect, TurboDOS provides a good many additional system calls for 
the  programmer.  (ROCHE> Well, TurboDOS being a  multi-processor  version  of
MP/M,  most of them have been existing under MP/M for about 5  years...)  Non-
programmers may want to skip this section.
First of all, CP/M-compatible system calls are vectored through location 5 (as 
you would expect); versions of TurboDOS prior to Release 1.3 included extended
system  calls  vectored  in the same way. (ROCHE>  Like  MP/M...)  Recent  re-
releases  of CP/M and MP/M, however, have caused some conflicts with  TurboDOS
extended functions. (ROCHE> ???)
To  correct  this problem, TurboDOS Release 1.3 moved  all  TurboDOS  extended 
system calls to location 80 (0050H). CP/M-compatible (ROCHE> Which version  of
CP/M?  2 or 3?) system calls are now referred to as C-functions, and  TurboDOS
extended system calls as T-functions.
Resident  processes must often make system calls; they cannot call location  5 
or  50H.  (ROCHE>  ??? Why?) Two special entry points are  provided  for  this
purpose,  and must be called symbolically. They are: OCNTRY (C-functions)  and
OTNTRY (T-functions). (ROCHE> So, O means Operating system, C means CP/M,  and
T  means TurboDOS.) The calling conventions are, otherwise, strictly the  same
as  they would be for a transient program. For example, to set the DMA  buffer
address, you would use the following code:
        MVI     C,SetDMA
        LXI     D,Buffer
        CALL    OCNTRY#
A  wide range of T-functions is provided (see Table 1) for such varied  things 
as  creating  and deleting resident processes,  allocating  and  de-allocating
memory,  inter-process communications, date/time functions, extended file  and
disk  drive  requests, and more. A few of the more interesting  functions  are
described here.
Communications  channel  support  (T-functions 34-40): A  full  complement  of 
functions  allows  complete  access  to  the  optional  communications  system
(generally  implemented  in  the  form  of  RS-232-C  drivers  by  the  system
implementer).  These functions allow such actions as  send/receive  character,
read  status, get/set baud rate, and get/set modem controls. They  also  allow
the  creation  of system-independent communications software for  TurboDOS  --
something  that  is impossible with CP/M. (ROCHE> ??? And CP/NET, what  is  it
doing? It is not tied to any protocol or hardware!)
Delay  process (T-function 2) circumvents the need for software timing  loops. 
This function allows a program (or resident process) to delay by increments as
fine as the system "tick" time (generally 1/60th of a second). (ROCHE> In  the
USA. 1/50th of a second in Europe.)
Return serial number (T-function 12) returns the complete serial number of the 
TurboDOS operating system. (This function can be used to discourage piracy  by
keying the purchaser's TurboDOS operating system to your software package.)
Load file (T-function 15) uses the previously-described Load Optimizer to load 
code segments into the program area. Handy for loading overlays.
Activate DO file (T-function 16) allows a program to begin a batch  processing 
job.  (Compared  to  writing  the old backward $$$.SUB  file  with  CP/M  2.2,
starting batch jobs under TurboDOS is simple with this system call.)
Send  Command  Line (T-function 18) allows creation of  applications  such  as 
menus from assembly language programs. It does not work quite the same way  as
MP/M's similarly-named function (ROCHE> This must be a coincidence?), however,
in that the passed Command Line is not executed immediately (as it is in MP/M)
but  is,  instead,  deferred until the calling  program  terminates.  You  may
"stack" command lines by calling this function more than one.
Printer  control  functions  T-functions 27-30)  allow  complete  programmatic 
access of the printer spooling and despooling mechanisms. Function 28  (signal
end-of-print)  is  especially  handy, since it allows a queued  print  job  to
actually begin printing.
User-defined  function  (T-function 41) belongs to the user, for  any  purpose 
that  he desires to write code for. It can take full advantage of the  network
for  communications between processors. To implement this function,  you  must
write  your  function  in  a module that defines  the  public  symbol  USRFCN;
register-passing  conventions are described in the "TurboDOS Release  1.4  Z80
Programmer's Guide". Once the function is in place, your applications  program
may communicate with it simply by calling T-function 41.

Documentation
-------------
No  software  evaluation  can be considered complete without  a  look  at  the 
documentation  supplied with the package. In the case of TurboDOS, I  have  to
rate  the documentation effort outstanding! (ROCHE>  Interesting.  Apparently,
not everyone thinks like you. "Many features of TurboDOS go underutilized  (or
totally  ignored) due to the difficulty in deciphering the manuals." and  "the
manuals  are  indescridably bad." This opinion was published in  nothing  less
than  the  "ACM SIGSMALL Newsletter"! Reference: Vol.10,  No.3,  August  1984,
p.24, "The TurboDOS Operating System", Keith Bierman.)
Three  manuals are provided with the Z80 TurboDOS operating system:  a  User's 
Guide, a Z80 Programmer's Guide, and the Z80 System Implementer's Guide.  Each
includes  a  table  of contents; the System Implementer's Guide  is  the  only
manual lacking an index.
The  User's  Guide  begins  with basics, and  takes  the  reader  through  the 
gradually  more  complex subjects of files, disks, printing,  and  processing,
concluding  with  a  summary of the entire set of 35-odd  utilities  that  are
provided with the TurboDOS operating system. The language is "gentle" and very
readable.
The  Programmer's  and Implementer's Guides are understandably  more  complex, 
since they deal with subjects that are technical in nature. They are complete,
and  provide  sufficient information to enable the programmer to do  his  job.
(ROCHE> Again, Ron implemented TurboDOS Release 1.3. Release 1.4 adds the 8086
programmer's Guide and the 8086 Implementer's Guide. TurboDOS thrived when  it
was  written in Z-80 assembly language for S-100 Bus systems, and  disappeared
when it was rewritten in the C language for the IBM PC...)

Conclusion
----------
As  you see, TurboDOS provides powerful facilities for both the user  and  the 
programmer.  After more than 3 years on the market (it was first  released  in
April  1981)  (ROCHE>  So, MP/M had already been existing  for  2  years  when
TurboDOS appeared... Guess which is the chicken? Which is the egg?),  TurboDOS
is  still being continually refined. (By the time you read this,  Release  1.4
should  be  available.  This new release will  feature  full  Intel  8088/8086
compatibility  at both the slave *AND* the master level, as well as a  PC  DOS
emulator.)  (ROCHE> Emulating MS-DOS Version 1 under TurboDOS on a  S-100  Bus
system? Vade Retro, Satanas!)
I  have recently obtained a Mega Z-80 system, featuring  512K  bank-selectable 
RAM  and  27 *MEGABYTE* Winchester hard disk drive, for which I plan to  do  a
full  master-to-master implementation of TurboDOS (complete with RAMdisk).  As
"Microsystems"  magazine  expands its TurboDOS coverage, I hope to  provide  a
follow-up article on this project, as well as a review of Turbo-Plus, and  (if
there  is  sufficient  interest) a tutorial  on  TurboDOS  implementation  and
programming  technique. (ROCHE> This article was the last one written  by  Ron
Fowler...)

EOF
Hits: 5406