Files posted on USENET by Emmanuel Roche

As of 20 December 2006, well known Herb Johnson have posted an "official" request on comp.os.cpm for CP/M archiving sites to store and publish documents posted on USENET by E. Roche. Herb already solicited for this to happen and has also collected Roche's files in a single place to easy submission on web sites.
Quoting his request on comp.os.cpm:

"Roche (aka French Luser) has posted many documents and CP/M software over the years, as emails to this newsgroup comp.os.cpm. Whatever one thinks of this practice, there is nonetheless a good amount of this material of his in comp.os.cpm archives. But it's relatively inaccessable, and many think it should be put in various Web archives of such stuff."

I'm more than happy to pick that material and made it available here, hoping to add soon more documents from Emmanuel Roche.

Please note that the following content has been copied from Herb's page so any credit for the work of grouping, sorting and commenting documents goes to him, i have just modified comments to reflect local archiving.

Updates:
Herb's original archives are now unsupported on his site and will be probably removed. Please refer to this page as the main distribution point for Roche's documents.


Files posted to comp.os.cpm.amethyst by Roche

I believe this is complete. There are few files and very few posts in this newsgroup, so I've just listed date of post. As of Sept 12 2006, this newsgroup has been removed from the Usenet "active" list for new posts. Any archives of old posts will persist until the archive's owner removes them.- Herb

DrLogo_Ref_App.txt
Posted 08 Apr 2005. Dr. Logo Reference Manual, appendixes.

DrLogo_Ref_Sec1_5
Posted 18 Apr 2005. Dr. Logo Reference manual, sections 1-5.

DrLogo_Ref_Sec_6
Posted 1 Apr 2005. Dr. Logo Reference manual, section 6.

IBM_ sys32_ drive
Posted 07 May 2005. Chapter 8 of the "IBM System/32 Functions Reference Manual", IBM Document GA21-9176-1 Second Edition: May 1975. This document was a standard reference for 8-inch single sided single density formats.

IBM_GA21_9182_4
"The IBM Diskette General Information Manual" IBM Document GA21-9182-4 Fifth Edition: August 1979. Another IBM diskette manual used for general reference Posted 26 May 2006.

SID86_User_Guide
Second Edition: August 1982, edits by Roche. Posted 18 Apr 2005.

Lawrence Livermore Labs Floating Point & BASIC

Not posted completely by Roche, this is the PDF of a document as follows:

UCRL-51940, "Floating-Point Package for Intel 8008 and 8080 Microprocessors"
by Michael D. Maples
Lawrence Livermore Laboratory,
University of California/Livermore, California 94550,
October 24, 1975


Roche posted the text but not the code of the document. Later, he provided to Herb his version of the source code, with square root and more commentary. Herb Johnson has made some correction to Roche's posted code. Quoted: "His text is at this link; his code LLLFPODT.ASM is at this link. My corrections to the floating point code based on the LLL document above are at this link. For some reason, the SQUARE ROOT subroutine was not included with the CPMUG submissions! It's in my "corrections" document. An earlier version of the code was also offered on CPMUG disks #2 and disk #10; as part of LLL "floating point BASIC". Images of those disks can be obtained from the retroarchive Web site as CPMUG010.ARK and CPMUG002.ARK. They should also be on the Walnut Creek CP/M CD-ROM, copies of which are on many Web archive sites. I've extracted out the floating point source code as LLLFP10.ASM and LLLFP02.ASM. Also the docs from the disk are at LLLBASIC10.TXT."

Note that retroarchive web site is also mirrored locally.

Falconer Floating Point 8080 code

This code was requested recently in Sept 2006 on comp.os.cpm. It was originally published in Dr. Dobb's Journal in 1979, and other places later. Apparently the author, Chuck/Charles Falconer, has lost his hard-drive archives of various versions of this code. If other people have a "digital" version they might contact him, or Herb (see below) or me. Roche posted one version of this in March 2001; Chuck Falconer says it's a "much improved version" of the DDJ code. In Oct 2006, Roche sent to Herb his copies of what he posted; they include the tab stops not in the comp.os.cpm. Here are the ORIGINAL files Roche posted; some responses by Mr. Falconer; and another posted comment on the DDJ docs by Mr. Falconer.

part 1 of 5 of the code INTARITH.ASM;
part 2 of 5 of the code FLTARITH.ASM;
part 3 of 5 of the code FLTINPUT.ASM;
part 4 of 5 of the code FLTOUT.ASM;
part 5 of 5 of the code FUNCTION.ASM;
the text of the DDJ article;
the text of the DDJ article in WordStar format;
improved multiply, posted by Falconer;
docs from DDJ article, posted by Falconer;
comments on docs, posted by Falconer.

Other documents

"DR Logo Reference Manual"

cpm80_86.txt
"CP/M-86 Compatibility Guide For CP/M-80 Users" 1980 Digital Research IN30 Posted in comp.os.cpm in 2003.

entcom.txt
Posted Aug 2006, subject "ENT-to-COM File Converter". for SOL computer, ENT file format to COM converter in BASIC, with commentary, by Roche

todata.txt
Posted Aug 30 2006, subject "To add or to remove line numbers...". As described. In BASIC, with commentary, by Rocheas of Dec 2006

as of December 2006

The following was provided by Tomas Karlsson in Dec 2006. Thanks!

AFTER8A.TXT - Looking after 8 segments, again...
AFTER8B.TXT - Looking after 8 segments: a demo, at last!
AFTER8C.TXT - The more you play with AFTER8 ComManD files
ASM86.TXT - How to disassemble ASM86.COM Ver 1.0
BYTESTAT.TXT - A solution in search of a problem...
CCGFCU.WS4 - CP/M-86 Compatibility Guide For CP/M-80 Users by Digital Research
COMALANG.TXT - COMAL - The programming language by David Stidolph
COMALERR.ASM - File ERROR.TXT of COMAL 2.1 interpreter
WHATSCML.TXT - What is COMAL? by COMAL Users Group USA Ltd
DRGDOC.TXT - DR Graph with GSX-86 by Digital Research
DUMPASC.TXT - Displaying the ASCII contents of files (hex files 8080 & 8086)
FILTER.TXT - WordStar 4.0 to HTML converter program (in BASIC)
GSX13ART.TXT - Digital Research's GSX: Graphics Portability by William G. Wong in "MicroSystems", July 1984,
HEADER.TXT - Everything you wanted to know about the CP/M-86 Header Record
MINUET.TXT - Minuet (Minnesota INternet User's Essential Tool) --- Minuet is an integrated package of TCP/IP network tools for the IBM PC and compatibles.
PCWPATB.TXT - PCC's Palo Alto Tiny BASIC Version Three
QXFONT.TXT - Better font for CP/M-86 Plus, hex dump
SAL80.TXT - Review of our SAL/80 package -- Letters to the Editor in "Microsystems", May 1984 by Steve Newberry
SCB.BAS - SCB field 3Ah in CP/M Plus
VALDOCS.TXT - PX-8 Valdocs reference by Bill Stoebig
VCOMP.TXT - Visual Compare, program description
Z80LIB.TXT - To count one's Z-80.LIB files (before they are assembled)
Z80OPS.TXT- Z80 to 8080 translation recommendations

As of March 2007

ACCESS10.TXT posted March 27 2007. A note on DR Access from Digital Research News vol 1 no 1 1984.
DNADV.TXT posted March 27 2007. "DR-Net -- Getting nets to work" "Digital Research European Review", No.7, April 1984, p.3

Unposted documents provided directly by Roche

BEEP.ASM
unposted, "the smallest CP/M Plus utility known to have been produced by DRI."

GENGRAF.ASM
unposted, "the program used, under CP/M 2.2, to "append" a loader at the front of any CP/M 8-bit COMmand file, loading the GDOS and the first GSX driver mentioned in the ASSIGN.SYS file into the TPA (and taking, unfortunately, about 25% of the TPA of an 8-bit system!!! But it works...)."

GSX.ASM
unposted, "my old uncommented disassembly of the GDOS of GSX-80"

NCRGRAF.ASM
unposted, "everything needed to produce graphics on an 8-bit system having a NEC uPD 7220 GDC. Probably written by DRI."


Contacts

Again: all credits for this work goes to Herb Johnson, i have simply "stolen" his comments on Roche's documents. To add more to this page or for any explanation you can contact This email address is being protected from spambots. You need JavaScript enabled to view it.. Herb Johnson's address is available at this Web page.

MTBASIC Revived

Some months ago i was surfing the net, searching for the sources (in C language) of a basic compiler capable to produce code for the Z80. I have not found what I tried, but instead i found a page that mentioned the existence of a BASIC compiler with multitasking ability developed initially on CP/M for the Z80.
I did not know the existence of this compiler and a specific search on the net has not given any result.
So i decided to contact the author of the software, the versatile Jack Gannsle (see http://www.ganssle.com).
Mr. Ganssle very kindly has explained to me not to have good news: its “old” company, SoftAid, had been sold to Avocet Systems therefore enclosed the MTBASIC compiler and all the relative documentation.
Avocet however was only interested on SoftAid's line of emulators and so it had not saved anything relative to MTBASIC.
A bit discouraged i have written a post on comp.os.cpm having explained the things… and oplà a copy of the compiler has appeared.
Paul A. MacDiarmid (thanks Paul!!) not only has sended to me “a recent” version of the compiler, but he has also generously scannerized a complete copy of the original handbook, assembling a perfect document in PDF format.
Obviously the minimum i could do was to publish the received material.
MTBASIC has been revived!


Downloads:

 

TDOS5.WS4
---------

- "The Networking Capabilities of TurboDOS"
  Michel Simon and William Poole (Commercial Dynamics)
  "Microsystems", August 1984, Vol.5, No.8, p.78

(Retyped by Emmanuel ROCHE.)


By  now,  most people in the CP/M world are, at least vaguely,  familiar  with
TurboDOS.  It is fairly well known that TurboDOS runs most off-the-shelf  CP/M
software,  and  that it can be found on S-100  Bus-based,  multi-user,  multi-
processor systems (networks). Less well known is the fact that a multitude  of
network configurations are possible with TurboDOS. Some manufacturers are  now
experimenting   with  different  network  architectures,  and  a   number   of
interesting products already exist. Given the availability of TurboDOS on  16-
bit processors and the growing list of manufacturers integrating TurboDOS with
their  hardware,  we should see the use of TurboDOS networks increase  in  the
days to come.

TurboDOS  is  truly a network operating system. This article  focuses  on  the
networking aspects of TurboDOS, including its capabilities and uses. First, we
will  describe  the  features of TurboDOS that distinguish  it  as  a  network
operating  system.  Second, we will discuss the  various  possible  networking
configurations.  Next,  we  will  address  the  limitations  of  TurboDOS   in
configuring  larger  networks.  The remainder of this  article  contains  some
general  guidelines for choosing a TurboDOS network, followed by a  review  of
TurboDOS networking products currently available. Detailed descriptions of the
network  architectures of 3 different manufacturers' products are included  as
examples.


What makes TurboDOS a network operating system?
-----------------------------------------------

The  single  most  important  characteristics of TurboDOS  --  one  which,  in
essence,  distinguishes  a network operating system  from  a  single-processor
operating  system  -- is that it permits transparent message  routing  between
physically-connected processors. This feature allows a request for a  *DEVICE*
(TurboDOS  devices are disk drives, printers, and queues) to be  automatically
routed,  in  logical form (see below), to the processor on  the  network  that
controls the device. Routing takes place between nodes on a circuit and, in  a
multi-circuit network, between circuits via common nodes.

TurboDOS  recognizes a 'world' that consists of 1 to 255  network  *CIRCUITS*,
each  of  which can have from 1 to 255 *NODES* connected to it. A  node  is  a
microcomputer (single-board, standalone, diskless, etc.), and a circuit is the
means  (hardware and software) by which nodes are connected. The S-100 Bus  is
currently the most widely-used transmission facility (hardware) for a TurboDOS
circuit,  although  there is a rapid growth in the use of Local  Area  Network
(LAN) circuits (RS-422/SDLC, ARCnet, Omninet, Ethernet, etc.) with TurboDOS. A
node can be connected to, and thus can transfer information between, more than
one circuit.

In  order  to illustrate and clarify what makes TurboDOS a  network  operating
system,  let us compare the way CP/M handles a resource request with  the  way
TurboDOS  handles  the same request. When the operator of a  single-user  CP/M
system makes a request for a resource, such as:

        A>DIR C:

the chain of events is as follows:

     1. CP/M's   command  line  interpreter  sees  a  request  for   directory
        information  from the C drive, and makes a *LOGICAL FUNCTION  REQUEST*
        (in CP/M, a BDOS system call) requesting this information.

     2. The BDOS makes the appropriate calls to the BIOS, which contains  disk
        drivers   and   has  access  to  information  about   the   particular
        characteristics of drive C.

     3. The  BDOS retrieves the information from the BIOS, and passes it  back
        to  the command line interpreter, which then displays the  information
        on the console.

All  along,  CP/M  assumes  that  the drive  is  attached  to  the  requesting
processor,  since  CP/M  does not recognize the existence  of  more  than  one
processor.

Under TurboDOS, however, the chain of events is quite different:

     1. The  TurboDOS  command line interpreter sees a request  for  directory
        information from the C drive, and makes a logical function request  to
        the TurboDOS file system, asking for this information.

     2. TurboDOS checks an internal table to see if drive C is attached to the
        requesting  processor  (i.e.,  is  a "Local" resource)  or  if  it  is
        attached to some other processor on the network (i.e., is a non-local,
        "Remote" resource).

     3. If  drive C is a local resource, the procedure followed is similar  to
        that followed by CP/M.

     4. If drive C is not a local resource, TurboDOS gets a *NETWORK  ADDRESS*
        from  its internal table. The address indicates the circuit  and  node
        numbers of the processor to which the resource is attached.

     5. TurboDOS  forms a *MESSAGE PACKET* consisting of the logical  function
        request,  the data, and the network address, and passes it on  to  the
        *CIRCUIT DRIVER* of the circuit indicated in the network address.

     6. The  circuit driver has access to all the information it  needs  about
        the  hardware characteristics of its physical  transmission  facility,
        and  transmits  the message packet to the processor indicated  in  the
        network address.

     7. At  the receiving processor, the same cycle is repeated: the  TurboDOS
        system  on  that processor checks to see if the resource is  local  or
        non-local (remote). If the resource is local, the receiving  processor
        carries out the request; if non-local (remote), the processor forwards
        the  message  packet. The requested information is returned,  via  the
        same  path,  to the originating processor. This processor  passes  the
        information to the command line interpreter, which displays it on  the
        console.

The  internal  tables mentioned in Events 2 and 4, which  are  called  *DEVICE
ASSIGNMENT TABLES*, are configured when the TurboDOS operating system on  each
processor  is  generated. Thus, the message-forwarding process  is  completely
transparent to the user, who enters a DIR command to get a directory listing.

In  the above scenario, it is important to note that messages are  transmitted
over  the network in the form of logical function requests, enabling  TurboDOS
to  meet  one of the fundamental requirements of a network  operating  system:
that  only  one processor recognizes the hardware characteristics of  a  given
device. For example, it is imperative that only one processor maintain a  disk
drive's  allocation  vector  or storage-used list;  otherwise,  assuring  data
integrity  in  a  multi-user environment would be impractical.  To  meet  this
requirement, TurboDOS messages are transmitted in a device-independent  format
until they arrive at their final destination.

Print spooling is accomplished through a network in the same manner as  drives
are  accessed: printer and queue requests are forwarded to the processor  that
controls the resource, just as drive requests are forwarded.


Other features
--------------

An  important  and related feature of TurboDOS is  its  modular  construction.
Networking hardware dependencies are isolated in circuit driver modules, while
peripheral hardware dependencies are isolated in device driver modules. Device
drivers  and  circuit  drivers  take  hardware-independent  instructions  from
TurboDOS,  and  execute them on the specific device or network  hardware  that
they control. In addition, modules of the operating system and device  drivers
are easily linked by the TurboDOS GEN command. Therefore, individual  versions
of the operating system can be configured to contain only those modules needed
to control the resources attached to a given processor on the network.

A  notable  consequence  of TurboDOS's modularity is that a  wide  variety  of
peripheral  devices  and  network hardware can  be  integrated  into  TurboDOS
systems  by  EOMs and system integrators. Device drivers can  be  replaced  or
updated as new disk and networking hardware becomes available.

Another feature of TurboDOS that deserves note is its support of network file-
and  record-locking. The processor that controls a given device keeps an  open
file  and  record list locally. When a logical function request for  a  locked
file  or  record is received, access to that file or record is denied,  and  a
return code indicating the error is sent back over the network.

TurboDOS's network file and record locking allows almost all single-user  CP/M
and   multi-user  MP/M  software  to  run  on  a  TurboDOS   network   without
modification. File lockout prevents single-user programs from corrupting files
when  they are simultaneously accessed by more than one user.  Record  lockout
allows simultaneous multi-user access to data files in an organized fashion.

The  above features combine to make TurboDOS a versatile operating system  for
configuring  a  wide  variety  of  networks  with  different  topologies   and
transmission  facilities.  We  will now classify and describe  some  of  these
network configurations.


Tightly-coupled networks
------------------------

As we mentioned earlier, the most common TurboDOS networks currently available
are  on  multi-user, multi-processor S-100 Bus-based systems,  including  IMS,
North  Star,  MuSYS,  and  Advanced Digital, to name but a  few;  for  a  more
complete list, refer to Table 1.

Table 1. TurboDOS networking products

Format: Manufacturers
        Tightly-coupled architecture
          Loosely-coupled architecture:
          Server-to-server
          Satellite-to-satellite
          Topology
          Maximum distance (feet)

(NOTE: In this table, K = kiloBAUDS, M = megaBAUDS.)

Advanced Computer Technology
S-100 Bus star
  (In development)

Advanced Digital
S-100 Bus star
  (In development)

Alspa
RS-422 800K bus, 2000 ft
  No
  No

Business Operating Systems
Parallel star, 10 ft
  RS-232 19.2K
  RS-232 19.2K
  Point-to-point
  300

California Computer Systems
S-100 Bus star
  No
  RS-232 9.6K
  Point-to-point
  300

Commercial Dynamics
S-100 Bus star
  No
  Differential 300K
  Bus
  1000

HM Systems, Ltd. (UK)
S-100 Bus star
  2.5M ARCnet
  No
  Ring
  2000

Intercontinental Micro Systems
S-100 Bus star
  2.5M ARCnet
  No
  Ring
  2000

Independent Business Systems
S-100 Bus star
  No
  RS-422 800K / RS-232 38.4K
  Point-to-point
  600 / 5000

Industrial Micro Systems
S-100 Bus star
  No
  Differential 307K
  Bus
  1000

JC Systems
2.4M Parallel bus, 600 ft
  No
  Parallel 2.4M
  Bus
  600

Litton Industries (Sweda Int'l.)
2M Token-passing LAN
  2M Token-passing LAN
  2M Token-passing LAN
  Ring
  2000

MuSYS
S-100 Bus star
  10M Ethernet
  RS-422 500K / RS-232 9.6K
  Ethernet bus / Point-to-point
  9000 / 900 / 300

NCR Corp.
No
  2M Omninet
  No
  Bus
  2000

North Star
S-100 Bus star
  No
  No

Philips (Netherlands)
Euro-Bus star
  2M Token-passing LAN
  No
  Ring
  2000

QDP Computer Systems
S-100 Bus star
  No
  No

Sierra Data Sciences
S-100 Bus star
  No
  No

Teletek
S-100 Bus star
  No
  No

Televideo
RS-422 800K star, 300 ft
  RS-422 800K
  No
  Point-to-point
  300


Networks  of  this type are referred to as *TIGHTLY-COUPLED*  networks.  In  a
tightly-coupled networks, disk resources are largely centralized, and all  the
processors are booted from one disk.

The  master processor is called a "server" because it services  requests  from
the satellites for access to the (many or all) global resources attached to it
(disks, printers, etc.). Slave processors are called "satellites" because this
is  a  more  accurate description of their function as part  of  the  network.
Although  their  primary function is to execute user programs,  and  they  are
booted  by the server and dependent on it for most operations, satellites  are
independent  processors  and,  in some cases, possess local  disk  or  printer
resources.

In  a  discussion of network configurations, it is  important  to  distinguish
between the hardware architecture of the transmission facility and the logical
topology.  For  example, in a typical S-100 Bus implementation of  a  TurboDOS
network,  the  S-100 Bus is the transmission facility, but the network  has  a
star  topology (see Figure 1). That is to say: even though all the  processors
are  physically  connected on the S-100 Bus, the  satellites  cannot  directly
communicate  with each other; all communication on the tightly-coupled,  S-100
Bus-based  network  is  controlled by  the  server.  Although  tightly-coupled
networks   are   predominantly   S-100   Bus-based,   other    tightly-coupled
architectures  have been implemented. Examples include Alspa, JC Systems,  and
Televideo (see Table 1).

        Figure 1. Tightly-coupled network, star topology


Loosely-coupled networks
------------------------

Networks  having  processors  that are independent of  each  other  for  basic
operations,  and disk resources that are distributed throughout  the  network,
are  referred to as *LOOSELY-COUPLED* networks. Loosely-coupled  networks  can
connect standalone, single-user systems or tightly-coupled networks.

Loosely-coupled networks of tightly-coupled systems require that at least  one
processor on each tightly-coupled network belong to both its internal  circuit
and  the  loosely-coupled  circuit (see Figure 2). Either the  server  of  the
tightly-coupled  circuit  or a satellite can be  the  dual-purpose  processor,
providing,  of  course,  that it has a physical means  to  transmit  messages.
Server-to-server  networks  typically require additional  hardware;  they  are
generally  considered desirable when the loosely-coupled network will be  used
for  high-volume  disk  access  and/or  chassis  expansion  (e.g.,  MuSYS  and
Intercontinental Micro Systems). Satellite-to-satellite networks use  hardware
already  on  satellite boards, and run at low-to-medium speeds  for  file  and
peripheral sharing (e.g., Commercial Dynamics, MuSYS and IBS).

Eight-bit single-user personal computers have not been widely networked  using
TurboDOS  because of memory considerations. Until recently, TurboDOS  did  not
support  more than 64K of memory, and a fully-configured  TurboDOS  (including
file  system and disk drivers) leaves only a 43K-to-45K TPA on a  64K  system.
With  TurboDOS now available on the Intel 8088/8086 family of  processors,  we
can  expect  to  see TurboDOS become a popular  environment  for  implementing
networks of 16-bit single-user machines, such as the IBM PC.

        Figure 2. Loosely-coupled networks


Gateways
--------

As  TurboDOS  networks  become available for a  wide  variety  of  processors,
*GATEWAYS*  will  become  increasingly important. Since  a  processor  can  be
connected to as many TurboDOS network circuits as it has circuit drivers  (and
corresponding transmission facilities), a gateway processor that has different
types  of  network  interfaces  can  interconnect  networks  using  dissimilar
hardware (see Figure 3). (ROCHE> "Internet" means "interconnected networks"...
This  article, describing it using 8-bit microcomputers, was written 12  years
before  Bill  Gates reluctantly provided "Internet Explorer"  under  Microsoft
Windows...)

Because  of the TurboDOS network's forwarding mechanism, each network  circuit
connected  by  a  gateway processor can be accessed by  nodes  throughout  the
entire network. If a processor is not itself connected to a given circuit, its
internal *NETWORK FORWARDING TABLE* tells it how to access the other circuits.
Network  forwarding  is part of the general  message-forwarding  mechanism  of
TurboDOS described earlier, and is transparent to the user.

As  TurboDOS  networks for IBM PC and PC-compatibles begin to appear,  we  can
expect  to  see  gateways implemented to connect  them  to  existing  TurboDOS
networks.  The introduction of banked memory support in Z80 TurboDOS  1.3  has
made  it both feasible and desirable to network 8-bit, as well as 16-bit,  PCs
together.

        Figure 3. Multiple networks linked by a gateway processor


TurboDOS limitations
--------------------

Any  TurboDOS  network  that  has fewer than 16 devices of  any  type  can  be
configured  to emulate a large computer system; no matter how the hardware  is
physically distributed, users have access to all network devices at all times.
However,  since  TurboDOS uses the CP/M device-naming  convention  (letters  A
through P), when there are more than 16 devices on a network, users may access
only  a  subset  of the network at any one time. While  16  devices  may  seem
sufficient,  it  is  easy to imagine a network that has  more  than  16  drive
volumes  (or  printers); it is also reasonable for network users  to  want  to
access most, if not all, of them.

This  situation can be handled in 3 different ways. First, the network can  be
restricted  to a maximum of 16 of each device. This limitation  is  reasonable
for small point-to-point systems (e.g., 2 systems communicating directly  over
a  dedicated wire) but is prohibitive for larger networks. Second,  one  might
change the device assignments of one or more processors. This has the  serious
disadvantage that TurboDOS has no mechanism for changing device assignments in
a  running  system;  device assignments can be made only when  the  system  is
generated. Thus, this scheme would entail generation of a separate version  of
the system for each set of device assignments; to change the assignments,  the
user would have to shut down the current system and reboot it with a different
version.  Since few end-users generate their own systems, this is not  a  very
practical  solution. Last, TurboDOS networking products can be  provided  with
utilities  that  allow device assignments to be edited and patched  while  the
system  is running, without reSYSGENing the operating system or  rebooting  it
(see the Commercial Dynamics example, below).


Choosing a TurboDOS network
---------------------------

If  you  already  owns a TurboDOS tightly-coupled  network,  your  choice  for
further  networking  products  will probably be limited  to  whatever  network
hardware  your manufacturer or dealer supports. However, if you have  not  yet
purchased  a system or are in a position to choose between different types  of
networks,  an  analysis of your applications is important to  determine  which
type  of  tightly-coupled and/or loosely-coupled network will best  suit  your
needs.

All  of  the  currently-available  tightly-coupled  networks  provide  similar
network performance. Tightly-coupled networks that use an RS-422  transmission
facility have a somewhat slower network transfer rate and, therefore, will not
perform  as  well  as  S-100 and Parallel Bus  systems,  especially  in  disk-
intensive  operations. The costs of most tightly-coupled systems are  similar,
so  your  choice will depend primarily on the other features of  the  TurboDOS
system, including disk storage, application software, dealer support, etc.

Loosely-coupled networks, on the other hand, differ significantly in price and
performance.  A  low-speed  network  can  cost less  than  $100  per  node  to
implement, while the highest speed system currently available costs more  than
$2000   per  node.  Loosely-coupled  network  transmission  rates  also   vary
significantly, anywhere from 9.6 Kbaud to 10 Mbaud per second.

Low-speed networks (9.6 Kbaud to 40 Kbaud) are primarily useful for occasional
file  transfers, low-volume printer sharing, and the transmission of  user-to-
user  mail and messages. They are generally unacceptable in  situations  where
large  volumes  of data must be transferred or more than a few nodes  use  the
network at the same time.

Medium-speed networks (100 Kbaud to 500 Kbaud) provide adequate throughput for
all  but the most intensive networking speeds. A network in this  speed  range
should  be able to load executable files, transfer large amounts of data,  and
have multi-user access over the network. Medium-speed networks are most  often
used in situations where network nodes use primarily local disk resources  and
only  go  to  the network for access  to  globally-shared  resources.  Sharing
printers  and  file transfers between a loosely-coupled network  of  otherwise
independent, tightly-coupled systems is an excellent application for a medium-
speed network.

High-speed networks (500 Kbaud and higher) are needed for good performance  in
situations  where  network  nodes make their primary disk  requests  over  the
network. A common use of high-speed networks is for chassis expansion; e.g., 2
separate tightly-coupled S-100 Bus networks sharing a single large hard  disk.
In  this  case, the system without the hard disk uses only a floppy  or  small
hard  disk to boot its processors and, from that point on, all  disk  requests
are transmitted over the high-speed network to the system with the large  hard
disk.

To determine whether a given network speed suits your specific needs, you must
first calculate, in bits, the average and maximum amounts of data that will be
transferred over the network simultaneously. Divide each of these figures into
the effective transfer rate of the network (which is usually 10 to 50  percent
of  the  manufacturer's  stated  transfer rate...)  to  determine  the  actual
transmission   time  under  average  and  maximum  conditions.   This   simple
calculation  should give you a reasonable estimate of how well a network  will
perform.


Trends
------

Given  the increasing availability of lower-cost networking hardware  and  the
decreasing  price  of hard disks, we expect to see large  multi-user  TurboDOS
networks configured somewhat differently than they are at present. S-100  Bus-
based  systems are usually loaded with as many users as they can hold  (10  to
20).  To  add more users, another S-100 Bus system is networked to  the  first
(provided  there is a networking product available), and the second system  is
loaded to its fullest potential. The major advantage of this approach is  that
it  offers the lowest cost per user; the disadvantage is that  contention  for
shared  network resources slows down all users on the system. In  most  common
applications,  better overall performance can be obtained by distributing  the
users  throughout  several smaller (4- to 8-user) systems. These  systems  can
then  be  networked together to provide all users with access to  all  network
resources.

The  arrival  of  inexpensive hard disks and  networking  products  will  make
distributed networks more common. The distributed approach also provides  more
protection against system failure: if one small network goes down, all  others
can still continue to operate. In a large, centralized system, a system  crash
can disable all users.


Sample architectures
--------------------

The  MuSYS product line provides examples of all of the most  common  TurboDOS
network  configurations.  Their  tightly-coupled  network  includes  satellite
processors with an S-100 Bus star topology. They also offer an Ethernet  board
set  that  connects tightly-coupled S-100 Bus star networks  into  a  loosely-
coupled  high-speed master-to-master bus network. A user will see very  little
difference in response time between making a disk request over this high-speed
master-to-master  network  and making the same request on a  local  disk.  For
lower-volume  applications, MuSYS provides both a medium-speed (RS-422) and  a
low-speed (RS-232) point-to-point, satellite-to-satellite network that uses  a
dedicated  satellite  processor board as a controller. It would not  be  cost-
effective  to  connect  more than 2 or 3 tightly-coupled  systems  with  these
latter 2 networks, since each system must contain one dedicated satellite  for
each of the other systems to which it is connected.

The  Televideo  808/816 network architecture is significantly  different  from
other  TurboDOS  networks. At the center of Televideo's  tightly-coupled  star
network  is a dedicated server processor that controls hard and floppy  disks,
printers,  and either 8 or 16 RS-422 ports. Each RS-422 port may be  connected
point-to-point  to a workstation, which is a terminal with  processor,  memory
and, optionally, a local floppy disk. Although the workstations can have local
disk  storage,  they  are  not  capable of booting  off  the  local  disk  and
connecting  to  the network at the same time; thus, the system is  a  tightly-
coupled network, even though the processors are physically distributed.

The Televideo network also allows point-to-point, master-to-master  networking
through the same RS-422 ports. As with MuSYS, an RS-422 port must be dedicated
to  each system that is networked. But, since the ports are provided with  the
initial purchase of the system, 2 Televideo 816 systems can be networked for a
very small incremental cost.

Commercial  Dynamics  provides  a  workable  solution  to  the  network   size
limitations  imposed  by  TurboDOS. They introduce the concept  of  a  network
*ENVIRONMENT*,  which  is  a  particular view of  a  network.  An  environment
consists of a set of logical-to-physical device assignments that specify which
physical  devices (disk drives, printers, queues) are accessed when a  logical
device is requested. Commercial Dynamics supplies utility programs to  create,
store, modify and activate the environments desired by the users.

Each  user  on a network can define any number of environments  by  running  a
menu-driven,  environment-editing utility. Environment definitions are  stored
in  files,  to  be  activated when they are needed  by  running  the  ACTIVATE
command,  and  specifying the environment to be activated. Although  only  one
environment  can be active at a time, a new environment can be activated  with
one command. Thus, a given user's view of the network can easily be  redefined
and  activated  without affecting any of the other users on the  network,  and
without regenerating the TurboDOS operating system. These utility programs are
supplied  with Commercial Dynamics' satellite processor and TurboNET  network,
and can also be obtained for any TurboDOS network.

Commercial  Dynamics  also  produces a satellite  processor  with  an  onboard
network  interface.  As  many as 16 tightly-coupled S-100  Bus  networks  that
contain at least one Commercial Dynamics satellite can be connected at  medium
speed  over  a S-100 Bus network. The Commercial Dynamics satellite can  be  a
user processor and a network interface at the same time; thus, loosely-coupled
networks  can  be  configured for a very low  cost.  The  Commercial  Dynamics
satellite  can  be  integrated into any S-100 Bus  TurboDOS  network,  and  is
currently running on IMS systems.


Summary
-------

A  wide  variety  of networking options are  available  with  TurboDOS,  using
different network topologies and networking hardware. TurboDOS's (ROCHE>  ????
Missing Text ???)


EOF

TDOS5.WS4
---------

- "The Networking Capabilities of TurboDOS"
  Michel Simon and William Poole (Commercial Dynamics)
  "Microsystems", August 1984, Vol.5, No.8, p.78

(Retyped by Emmanuel ROCHE.)


By  now,  most people in the CP/M world are, at least vaguely,  familiar  with
TurboDOS.  It is fairly well known that TurboDOS runs most off-the-shelf  CP/M
software,  and  that it can be found on S-100  Bus-based,  multi-user,  multi-
processor systems (networks). Less well known is the fact that a multitude  of
network configurations are possible with TurboDOS. Some manufacturers are  now
experimenting   with  different  network  architectures,  and  a   number   of
interesting products already exist. Given the availability of TurboDOS on  16-
bit processors and the growing list of manufacturers integrating TurboDOS with
their  hardware,  we should see the use of TurboDOS networks increase  in  the
days to come.

TurboDOS  is  truly a network operating system. This article  focuses  on  the
networking aspects of TurboDOS, including its capabilities and uses. First, we
will  describe  the  features of TurboDOS that distinguish  it  as  a  network
operating  system.  Second, we will discuss the  various  possible  networking
configurations.  Next,  we  will  address  the  limitations  of  TurboDOS   in
configuring  larger  networks.  The remainder of this  article  contains  some
general  guidelines for choosing a TurboDOS network, followed by a  review  of
TurboDOS networking products currently available. Detailed descriptions of the
network  architectures of 3 different manufacturers' products are included  as
examples.


What makes TurboDOS a network operating system?
-----------------------------------------------

The  single  most  important  characteristics of TurboDOS  --  one  which,  in
essence,  distinguishes  a network operating system  from  a  single-processor
operating  system  -- is that it permits transparent message  routing  between
physically-connected processors. This feature allows a request for a  *DEVICE*
(TurboDOS  devices are disk drives, printers, and queues) to be  automatically
routed,  in  logical form (see below), to the processor on  the  network  that
controls the device. Routing takes place between nodes on a circuit and, in  a
multi-circuit network, between circuits via common nodes.

TurboDOS  recognizes a 'world' that consists of 1 to 255  network  *CIRCUITS*,
each  of  which can have from 1 to 255 *NODES* connected to it. A  node  is  a
microcomputer (single-board, standalone, diskless, etc.), and a circuit is the
means  (hardware and software) by which nodes are connected. The S-100 Bus  is
currently the most widely-used transmission facility (hardware) for a TurboDOS
circuit,  although  there is a rapid growth in the use of Local  Area  Network
(LAN) circuits (RS-422/SDLC, ARCnet, Omninet, Ethernet, etc.) with TurboDOS. A
node can be connected to, and thus can transfer information between, more than
one circuit.

In  order  to illustrate and clarify what makes TurboDOS a  network  operating
system,  let us compare the way CP/M handles a resource request with  the  way
TurboDOS  handles  the same request. When the operator of a  single-user  CP/M
system makes a request for a resource, such as:

        A>DIR C:

the chain of events is as follows:

     1. CP/M's   command  line  interpreter  sees  a  request  for   directory
        information  from the C drive, and makes a *LOGICAL FUNCTION  REQUEST*
        (in CP/M, a BDOS system call) requesting this information.

     2. The BDOS makes the appropriate calls to the BIOS, which contains  disk
        drivers   and   has  access  to  information  about   the   particular
        characteristics of drive C.

     3. The  BDOS retrieves the information from the BIOS, and passes it  back
        to  the command line interpreter, which then displays the  information
        on the console.

All  along,  CP/M  assumes  that  the drive  is  attached  to  the  requesting
processor,  since  CP/M  does not recognize the existence  of  more  than  one
processor.

Under TurboDOS, however, the chain of events is quite different:

     1. The  TurboDOS  command line interpreter sees a request  for  directory
        information from the C drive, and makes a logical function request  to
        the TurboDOS file system, asking for this information.

     2. TurboDOS checks an internal table to see if drive C is attached to the
        requesting  processor  (i.e.,  is  a "Local" resource)  or  if  it  is
        attached to some other processor on the network (i.e., is a non-local,
        "Remote" resource).

     3. If  drive C is a local resource, the procedure followed is similar  to
        that followed by CP/M.

     4. If drive C is not a local resource, TurboDOS gets a *NETWORK  ADDRESS*
        from  its internal table. The address indicates the circuit  and  node
        numbers of the processor to which the resource is attached.

     5. TurboDOS  forms a *MESSAGE PACKET* consisting of the logical  function
        request,  the data, and the network address, and passes it on  to  the
        *CIRCUIT DRIVER* of the circuit indicated in the network address.

     6. The  circuit driver has access to all the information it  needs  about
        the  hardware characteristics of its physical  transmission  facility,
        and  transmits  the message packet to the processor indicated  in  the
        network address.

     7. At  the receiving processor, the same cycle is repeated: the  TurboDOS
        system  on  that processor checks to see if the resource is  local  or
        non-local (remote). If the resource is local, the receiving  processor
        carries out the request; if non-local (remote), the processor forwards
        the  message  packet. The requested information is returned,  via  the
        same  path,  to the originating processor. This processor  passes  the
        information to the command line interpreter, which displays it on  the
        console.

The  internal  tables mentioned in Events 2 and 4, which  are  called  *DEVICE
ASSIGNMENT TABLES*, are configured when the TurboDOS operating system on  each
processor  is  generated. Thus, the message-forwarding process  is  completely
transparent to the user, who enters a DIR command to get a directory listing.

In  the above scenario, it is important to note that messages are  transmitted
over  the network in the form of logical function requests, enabling  TurboDOS
to  meet  one of the fundamental requirements of a network  operating  system:
that  only  one processor recognizes the hardware characteristics of  a  given
device. For example, it is imperative that only one processor maintain a  disk
drive's  allocation  vector  or storage-used list;  otherwise,  assuring  data
integrity  in  a  multi-user environment would be impractical.  To  meet  this
requirement, TurboDOS messages are transmitted in a device-independent  format
until they arrive at their final destination.

Print spooling is accomplished through a network in the same manner as  drives
are  accessed: printer and queue requests are forwarded to the processor  that
controls the resource, just as drive requests are forwarded.


Other features
--------------

An  important  and related feature of TurboDOS is  its  modular  construction.
Networking hardware dependencies are isolated in circuit driver modules, while
peripheral hardware dependencies are isolated in device driver modules. Device
drivers  and  circuit  drivers  take  hardware-independent  instructions  from
TurboDOS,  and  execute them on the specific device or network  hardware  that
they control. In addition, modules of the operating system and device  drivers
are easily linked by the TurboDOS GEN command. Therefore, individual  versions
of the operating system can be configured to contain only those modules needed
to control the resources attached to a given processor on the network.

A  notable  consequence  of TurboDOS's modularity is that a  wide  variety  of
peripheral  devices  and  network hardware can  be  integrated  into  TurboDOS
systems  by  EOMs and system integrators. Device drivers can  be  replaced  or
updated as new disk and networking hardware becomes available.

Another feature of TurboDOS that deserves note is its support of network file-
and  record-locking. The processor that controls a given device keeps an  open
file  and  record list locally. When a logical function request for  a  locked
file  or  record is received, access to that file or record is denied,  and  a
return code indicating the error is sent back over the network.

TurboDOS's network file and record locking allows almost all single-user  CP/M
and   multi-user  MP/M  software  to  run  on  a  TurboDOS   network   without
modification. File lockout prevents single-user programs from corrupting files
when  they are simultaneously accessed by more than one user.  Record  lockout
allows simultaneous multi-user access to data files in an organized fashion.

The  above features combine to make TurboDOS a versatile operating system  for
configuring  a  wide  variety  of  networks  with  different  topologies   and
transmission  facilities.  We  will now classify and describe  some  of  these
network configurations.


Tightly-coupled networks
------------------------

As we mentioned earlier, the most common TurboDOS networks currently available
are  on  multi-user, multi-processor S-100 Bus-based systems,  including  IMS,
North  Star,  MuSYS,  and  Advanced Digital, to name but a  few;  for  a  more
complete list, refer to Table 1.

Table 1. TurboDOS networking products

Format: Manufacturers
        Tightly-coupled architecture
          Loosely-coupled architecture:
          Server-to-server
          Satellite-to-satellite
          Topology
          Maximum distance (feet)

(NOTE: In this table, K = kiloBAUDS, M = megaBAUDS.)

Advanced Computer Technology
S-100 Bus star
  (In development)

Advanced Digital
S-100 Bus star
  (In development)

Alspa
RS-422 800K bus, 2000 ft
  No
  No

Business Operating Systems
Parallel star, 10 ft
  RS-232 19.2K
  RS-232 19.2K
  Point-to-point
  300

California Computer Systems
S-100 Bus star
  No
  RS-232 9.6K
  Point-to-point
  300

Commercial Dynamics
S-100 Bus star
  No
  Differential 300K
  Bus
  1000

HM Systems, Ltd. (UK)
S-100 Bus star
  2.5M ARCnet
  No
  Ring
  2000

Intercontinental Micro Systems
S-100 Bus star
  2.5M ARCnet
  No
  Ring
  2000

Independent Business Systems
S-100 Bus star
  No
  RS-422 800K / RS-232 38.4K
  Point-to-point
  600 / 5000

Industrial Micro Systems
S-100 Bus star
  No
  Differential 307K
  Bus
  1000

JC Systems
2.4M Parallel bus, 600 ft
  No
  Parallel 2.4M
  Bus
  600

Litton Industries (Sweda Int'l.)
2M Token-passing LAN
  2M Token-passing LAN
  2M Token-passing LAN
  Ring
  2000

MuSYS
S-100 Bus star
  10M Ethernet
  RS-422 500K / RS-232 9.6K
  Ethernet bus / Point-to-point
  9000 / 900 / 300

NCR Corp.
No
  2M Omninet
  No
  Bus
  2000

North Star
S-100 Bus star
  No
  No

Philips (Netherlands)
Euro-Bus star
  2M Token-passing LAN
  No
  Ring
  2000

QDP Computer Systems
S-100 Bus star
  No
  No

Sierra Data Sciences
S-100 Bus star
  No
  No

Teletek
S-100 Bus star
  No
  No

Televideo
RS-422 800K star, 300 ft
  RS-422 800K
  No
  Point-to-point
  300


Networks  of  this type are referred to as *TIGHTLY-COUPLED*  networks.  In  a
tightly-coupled networks, disk resources are largely centralized, and all  the
processors are booted from one disk.

The  master processor is called a "server" because it services  requests  from
the satellites for access to the (many or all) global resources attached to it
(disks, printers, etc.). Slave processors are called "satellites" because this
is  a  more  accurate description of their function as part  of  the  network.
Although  their  primary function is to execute user programs,  and  they  are
booted  by the server and dependent on it for most operations, satellites  are
independent  processors  and,  in some cases, possess local  disk  or  printer
resources.

In  a  discussion of network configurations, it is  important  to  distinguish
between the hardware architecture of the transmission facility and the logical
topology.  For  example, in a typical S-100 Bus implementation of  a  TurboDOS
network,  the  S-100 Bus is the transmission facility, but the network  has  a
star  topology (see Figure 1). That is to say: even though all the  processors
are  physically  connected on the S-100 Bus, the  satellites  cannot  directly
communicate  with each other; all communication on the tightly-coupled,  S-100
Bus-based  network  is  controlled by  the  server.  Although  tightly-coupled
networks   are   predominantly   S-100   Bus-based,   other    tightly-coupled
architectures  have been implemented. Examples include Alspa, JC Systems,  and
Televideo (see Table 1).

        Figure 1. Tightly-coupled network, star topology


Loosely-coupled networks
------------------------

Networks  having  processors  that are independent of  each  other  for  basic
operations,  and disk resources that are distributed throughout  the  network,
are  referred to as *LOOSELY-COUPLED* networks. Loosely-coupled  networks  can
connect standalone, single-user systems or tightly-coupled networks.

Loosely-coupled networks of tightly-coupled systems require that at least  one
processor on each tightly-coupled network belong to both its internal  circuit
and  the  loosely-coupled  circuit (see Figure 2). Either the  server  of  the
tightly-coupled  circuit  or a satellite can be  the  dual-purpose  processor,
providing,  of  course,  that it has a physical means  to  transmit  messages.
Server-to-server  networks  typically require additional  hardware;  they  are
generally  considered desirable when the loosely-coupled network will be  used
for  high-volume  disk  access  and/or  chassis  expansion  (e.g.,  MuSYS  and
Intercontinental Micro Systems). Satellite-to-satellite networks use  hardware
already  on  satellite boards, and run at low-to-medium speeds  for  file  and
peripheral sharing (e.g., Commercial Dynamics, MuSYS and IBS).

Eight-bit single-user personal computers have not been widely networked  using
TurboDOS  because of memory considerations. Until recently, TurboDOS  did  not
support  more than 64K of memory, and a fully-configured  TurboDOS  (including
file  system and disk drivers) leaves only a 43K-to-45K TPA on a  64K  system.
With  TurboDOS now available on the Intel 8088/8086 family of  processors,  we
can  expect  to  see TurboDOS become a popular  environment  for  implementing
networks of 16-bit single-user machines, such as the IBM PC.

        Figure 2. Loosely-coupled networks


Gateways
--------

As  TurboDOS  networks  become available for a  wide  variety  of  processors,
*GATEWAYS*  will  become  increasingly important. Since  a  processor  can  be
connected to as many TurboDOS network circuits as it has circuit drivers  (and
corresponding transmission facilities), a gateway processor that has different
types  of  network  interfaces  can  interconnect  networks  using  dissimilar
hardware (see Figure 3). (ROCHE> "Internet" means "interconnected networks"...
This  article, describing it using 8-bit microcomputers, was written 12  years
before  Bill  Gates reluctantly provided "Internet Explorer"  under  Microsoft
Windows...)

Because  of the TurboDOS network's forwarding mechanism, each network  circuit
connected  by  a  gateway processor can be accessed by  nodes  throughout  the
entire network. If a processor is not itself connected to a given circuit, its
internal *NETWORK FORWARDING TABLE* tells it how to access the other circuits.
Network  forwarding  is part of the general  message-forwarding  mechanism  of
TurboDOS described earlier, and is transparent to the user.

As  TurboDOS  networks for IBM PC and PC-compatibles begin to appear,  we  can
expect  to  see  gateways implemented to connect  them  to  existing  TurboDOS
networks.  The introduction of banked memory support in Z80 TurboDOS  1.3  has
made  it both feasible and desirable to network 8-bit, as well as 16-bit,  PCs
together.

        Figure 3. Multiple networks linked by a gateway processor


TurboDOS limitations
--------------------

Any  TurboDOS  network  that  has fewer than 16 devices of  any  type  can  be
configured  to emulate a large computer system; no matter how the hardware  is
physically distributed, users have access to all network devices at all times.
However,  since  TurboDOS uses the CP/M device-naming  convention  (letters  A
through P), when there are more than 16 devices on a network, users may access
only  a  subset  of the network at any one time. While  16  devices  may  seem
sufficient,  it  is  easy to imagine a network that has  more  than  16  drive
volumes  (or  printers); it is also reasonable for network users  to  want  to
access most, if not all, of them.

This  situation can be handled in 3 different ways. First, the network can  be
restricted  to a maximum of 16 of each device. This limitation  is  reasonable
for small point-to-point systems (e.g., 2 systems communicating directly  over
a  dedicated wire) but is prohibitive for larger networks. Second,  one  might
change the device assignments of one or more processors. This has the  serious
disadvantage that TurboDOS has no mechanism for changing device assignments in
a  running  system;  device assignments can be made only when  the  system  is
generated. Thus, this scheme would entail generation of a separate version  of
the system for each set of device assignments; to change the assignments,  the
user would have to shut down the current system and reboot it with a different
version.  Since few end-users generate their own systems, this is not  a  very
practical  solution. Last, TurboDOS networking products can be  provided  with
utilities  that  allow device assignments to be edited and patched  while  the
system  is running, without reSYSGENing the operating system or  rebooting  it
(see the Commercial Dynamics example, below).


Choosing a TurboDOS network
---------------------------

If  you  already  owns a TurboDOS tightly-coupled  network,  your  choice  for
further  networking  products  will probably be limited  to  whatever  network
hardware  your manufacturer or dealer supports. However, if you have  not  yet
purchased  a system or are in a position to choose between different types  of
networks,  an  analysis of your applications is important to  determine  which
type  of  tightly-coupled and/or loosely-coupled network will best  suit  your
needs.

All  of  the  currently-available  tightly-coupled  networks  provide  similar
network performance. Tightly-coupled networks that use an RS-422  transmission
facility have a somewhat slower network transfer rate and, therefore, will not
perform  as  well  as  S-100 and Parallel Bus  systems,  especially  in  disk-
intensive  operations. The costs of most tightly-coupled systems are  similar,
so  your  choice will depend primarily on the other features of  the  TurboDOS
system, including disk storage, application software, dealer support, etc.

Loosely-coupled networks, on the other hand, differ significantly in price and
performance.  A  low-speed  network  can  cost less  than  $100  per  node  to
implement, while the highest speed system currently available costs more  than
$2000   per  node.  Loosely-coupled  network  transmission  rates  also   vary
significantly, anywhere from 9.6 Kbaud to 10 Mbaud per second.

Low-speed networks (9.6 Kbaud to 40 Kbaud) are primarily useful for occasional
file  transfers, low-volume printer sharing, and the transmission of  user-to-
user  mail and messages. They are generally unacceptable in  situations  where
large  volumes  of data must be transferred or more than a few nodes  use  the
network at the same time.

Medium-speed networks (100 Kbaud to 500 Kbaud) provide adequate throughput for
all  but the most intensive networking speeds. A network in this  speed  range
should  be able to load executable files, transfer large amounts of data,  and
have multi-user access over the network. Medium-speed networks are most  often
used in situations where network nodes use primarily local disk resources  and
only  go  to  the network for access  to  globally-shared  resources.  Sharing
printers  and  file transfers between a loosely-coupled network  of  otherwise
independent, tightly-coupled systems is an excellent application for a medium-
speed network.

High-speed networks (500 Kbaud and higher) are needed for good performance  in
situations  where  network  nodes make their primary disk  requests  over  the
network. A common use of high-speed networks is for chassis expansion; e.g., 2
separate tightly-coupled S-100 Bus networks sharing a single large hard  disk.
In  this  case, the system without the hard disk uses only a floppy  or  small
hard  disk to boot its processors and, from that point on, all  disk  requests
are transmitted over the high-speed network to the system with the large  hard
disk.

To determine whether a given network speed suits your specific needs, you must
first calculate, in bits, the average and maximum amounts of data that will be
transferred over the network simultaneously. Divide each of these figures into
the effective transfer rate of the network (which is usually 10 to 50  percent
of  the  manufacturer's  stated  transfer rate...)  to  determine  the  actual
transmission   time  under  average  and  maximum  conditions.   This   simple
calculation  should give you a reasonable estimate of how well a network  will
perform.


Trends
------

Given  the increasing availability of lower-cost networking hardware  and  the
decreasing  price  of hard disks, we expect to see large  multi-user  TurboDOS
networks configured somewhat differently than they are at present. S-100  Bus-
based  systems are usually loaded with as many users as they can hold  (10  to
20).  To  add more users, another S-100 Bus system is networked to  the  first
(provided  there is a networking product available), and the second system  is
loaded to its fullest potential. The major advantage of this approach is  that
it  offers the lowest cost per user; the disadvantage is that  contention  for
shared  network resources slows down all users on the system. In  most  common
applications,  better overall performance can be obtained by distributing  the
users  throughout  several smaller (4- to 8-user) systems. These  systems  can
then  be  networked together to provide all users with access to  all  network
resources.

The  arrival  of  inexpensive hard disks and  networking  products  will  make
distributed networks more common. The distributed approach also provides  more
protection against system failure: if one small network goes down, all  others
can still continue to operate. In a large, centralized system, a system  crash
can disable all users.


Sample architectures
--------------------

The  MuSYS product line provides examples of all of the most  common  TurboDOS
network  configurations.  Their  tightly-coupled  network  includes  satellite
processors with an S-100 Bus star topology. They also offer an Ethernet  board
set  that  connects tightly-coupled S-100 Bus star networks  into  a  loosely-
coupled  high-speed master-to-master bus network. A user will see very  little
difference in response time between making a disk request over this high-speed
master-to-master  network  and making the same request on a  local  disk.  For
lower-volume  applications, MuSYS provides both a medium-speed (RS-422) and  a
low-speed (RS-232) point-to-point, satellite-to-satellite network that uses  a
dedicated  satellite  processor board as a controller. It would not  be  cost-
effective  to  connect  more than 2 or 3 tightly-coupled  systems  with  these
latter 2 networks, since each system must contain one dedicated satellite  for
each of the other systems to which it is connected.

The  Televideo  808/816 network architecture is significantly  different  from
other  TurboDOS  networks. At the center of Televideo's  tightly-coupled  star
network  is a dedicated server processor that controls hard and floppy  disks,
printers,  and either 8 or 16 RS-422 ports. Each RS-422 port may be  connected
point-to-point  to a workstation, which is a terminal with  processor,  memory
and, optionally, a local floppy disk. Although the workstations can have local
disk  storage,  they  are  not  capable of booting  off  the  local  disk  and
connecting  to  the network at the same time; thus, the system is  a  tightly-
coupled network, even though the processors are physically distributed.

The Televideo network also allows point-to-point, master-to-master  networking
through the same RS-422 ports. As with MuSYS, an RS-422 port must be dedicated
to  each system that is networked. But, since the ports are provided with  the
initial purchase of the system, 2 Televideo 816 systems can be networked for a
very small incremental cost.

Commercial  Dynamics  provides  a  workable  solution  to  the  network   size
limitations  imposed  by  TurboDOS. They introduce the concept  of  a  network
*ENVIRONMENT*,  which  is  a  particular view of  a  network.  An  environment
consists of a set of logical-to-physical device assignments that specify which
physical  devices (disk drives, printers, queues) are accessed when a  logical
device is requested. Commercial Dynamics supplies utility programs to  create,
store, modify and activate the environments desired by the users.

Each  user  on a network can define any number of environments  by  running  a
menu-driven,  environment-editing utility. Environment definitions are  stored
in  files,  to  be  activated when they are needed  by  running  the  ACTIVATE
command,  and  specifying the environment to be activated. Although  only  one
environment  can be active at a time, a new environment can be activated  with
one command. Thus, a given user's view of the network can easily be  redefined
and  activated  without affecting any of the other users on the  network,  and
without regenerating the TurboDOS operating system. These utility programs are
supplied  with Commercial Dynamics' satellite processor and TurboNET  network,
and can also be obtained for any TurboDOS network.

Commercial  Dynamics  also  produces a satellite  processor  with  an  onboard
network  interface.  As  many as 16 tightly-coupled S-100  Bus  networks  that
contain at least one Commercial Dynamics satellite can be connected at  medium
speed  over  a S-100 Bus network. The Commercial Dynamics satellite can  be  a
user processor and a network interface at the same time; thus, loosely-coupled
networks  can  be  configured for a very low  cost.  The  Commercial  Dynamics
satellite  can  be  integrated into any S-100 Bus  TurboDOS  network,  and  is
currently running on IMS systems.


Summary
-------

A  wide  variety  of networking options are  available  with  TurboDOS,  using
different network topologies and networking hardware. TurboDOS's (ROCHE>  ????
Missing Text ???)


EOF

 
TDOS4.WS4
---------

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

(Retyped by Emmanuel ROCHE.)


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

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

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

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

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

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


Masters and Slaves
------------------

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

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


Security and privileged users
-----------------------------

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

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

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

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

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


System utilities
----------------

These fall into several groups:

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

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

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

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


File opening modes
------------------

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

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

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

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

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


Running single-user CP/M programs
---------------------------------

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

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

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

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

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


Integration to LANs with TurboDOS
---------------------------------

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

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

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

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


The TurboDOS print environment
------------------------------

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

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

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

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

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

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

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

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

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


The mechanics of TurboDOS
-------------------------

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

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

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

Circuit drivers: MCDSPM Master Circuit Driver
SCDD86 Slave Circuit Driver

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

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

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

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

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

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


Programming under TurboDOS
--------------------------

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

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


Miscellaneous bit & pieces
--------------------------

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

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

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

SEND (fifo filename) (message text)

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


Real Soon Now
-------------

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


Conclusions
-----------

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

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

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

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

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

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


EOF
TDOS6.WS4
---------
- "TurboDOS spans the Horizon"
  Karl Sterne, North Star Computers, Inc.
  "Microsystems", August 1984, Vol.5, No.8, p.114
(Retyped by Emmanuel ROCHE.)

The  North  Star  Horizon,  now  6 years old,  is  one  of  the  few  pre-1980
microcomputers still in demand. However, the Horizon, as it is built in 1984,
is a very different system from its 1978 ancestor. Today's Horizon is a multi-
user  multi-processor  that uses North Star's version  of  TurboDOS  operating
system  from  Software  2000, Inc., for both 8-bit  CP/M  and  16-bit  CP/M-86
applications.
By  the end of 1982, it was apparent that the Horizon's lifespan would be  far 
longer  than  had  been forecast. Its chief limitation  was  its  time-sharing
operating  system. To replace it, North Star evaluated a number  of  operating
systems before choosing TurboDOS. Among the reasons for the decision were:
     1. TurboDOS  has  a multi-processor networking  architecture.  (In  fact, 
        North   Star's  latest  computer,  the  Dimension,  uses   a   similar
        architecture. The Dimension, however, incorporates a multiple-user IBM
        XT-compatible  operating system rather than TurboDOS, as well  as  the
        Intel  80186  processor rather than the Zilog Z-80, and  the  IBM  bus
        rather than the S-100 Bus.)
     2. TurboDOS  provides true multi-user operation, including  file  sharing 
        and record lockout.
     3. TurboDOS   permits   simultaneous  operation  of  8-bit   and   16-bit 
        applications.
     4. TurboDOS outperforms many other operating systems in timed benchmarks.
     5. TurboDOS  has  powerful networking facilities,  including  support  of 
        multiple circuits, node-to-node communications, and the ability of any
        node to be a server. This allows, for example, direct access to the S-
        100 Bus for control of special boards.
     6. TurboDOS comes as close to being a minicomputer operating system as is 
        practical on a microcomputer.
Given  all its advantages, TurboDOS can still be improved. This  article  will 
discuss some of the improvements made by North Star.

16-bit operation
----------------
North Star's principal problem with TurboDOS was that Release 1.22, the latest 
available  in  1983,  emulated  only  8-bit CP/M,  and  did  not  have  16-bit
capabilities.  Software  2000's assurance, that a  new  release  incorporating
CP/M-86  emulation  was  imminent,  allowed North Star  to  proceed  with  the
development  of  new hardware: an 8-bit Zilog Z-80 satellite board,  a  16-bit
Intel  8088-2 satellite board, and a memory expansion board to give the  Intel
8088-2 as much as 512K of RAM. The existing Horizon hardware was used  without
modification  for the server (master). Although both the 16-bit  hardware  and
the  new  TurboDOS release took longer than expected, they have  been  in  use
since April 1984, and have had excellent acceptance.

Installation and configuration
------------------------------
TurboDOS  runs  on  a  large  variety of  hardware,  and  one  result  of  its 
versatility is that it tends to be difficult to install. Having once succeeded
in  installing the "vanilla" system, the user is confronted with the  task  of
tailoring  it  to  that particular hardware. This  usually  requires  a  word-
processor to create lists of operating system functions and other  parameters.
This  process is a radical departure from the straightforward installation  of
other North Star operating systems.
The  North  Star  approach  was  to  split  the  process  into  2   functions: 
configuration  and  installation.  The configuration  program  asks  the  user
questions  in English, and does not require a word-processor; installation  is
automated, using the operator's responses.
The  North Star TurboDOS operating system is distributed as a 4-diskette  set. 
Each  diskette  is  named  for its particular  function  in  the  installation
process:  SYSTEM  DISK, CONFIG DISK, HELP DISK, and SYSCON  DISK.  The  SYSTEM
DISKette  is  a  bootable TurboDOS operating system that  contains  a  maximum
hardware  configuration.  Some  users  will never  need  to  generate  another
operating system.
Two  manuals come with North Star TurboDOS: the TurboDOS User's Guide and  the 
TurboDOS  Reference Manual. The preface to the TurboDOS User's Guide  contains
step-by-step instructions for helping the system install itself. Three  simple
commands are entered from any user's console. The rest of the process requires
only a few Carriage Returns and diskette changes.
The  installation process uses the TurboDOS command file batch utility  --  an 
enhancement   of  the  CP/M  SUBMIT  facility  --  and  performs  the   system
initialization  tasks  such  as  verifying  the  hard  disk  data  tracks  and
formatting  the TurboDOS directory area. The user is then asked to insert  one
of  the 4 distribution diskettes. The proper user areas of the hard  disk  are
loaded with the appropriate files. This process is repeated for each of the  4
diskettes.
At this point, the installation creates a bootable diskette for daily use. The 
distribution  diskette  set  can  be set aside,  and  the  computer  is  fully
operational.  If  customizing  of the operating system is  not  desired,  this
completes the process.
The  operating  system  on the SYSTEM DISK contains  software  drivers  for  a 
maximum  system.  It includes hard disk drivers for both types of  North  Star
hard  disks, and 2 different kinds of printer drivers. Should the user wish  a
different configuration, the CONFIG program is run.
CONFIG  asks the user questions in simple English about the  desired  hardware 
configuration. It builds the TurboDOS GENeration and PARameter files  required
by  the TurboDOS GEN command. No other programs are required. After  the  user
finishes  answering  all the questions, a system summary is displayed  on  the
screen.  This can be accepted or aborted, and the user can change any  desired
parameters.
At the end of the session, the user can opt not to have the TurboDOS operating 
system  actually  generated.  In this mode, CONFIG acts as  a  teaching  tool,
allowing  the user to see how different configurations change the form of  the
GEN and PAR files.
If  additional  TurboDOS operating systems are desired, another  command  file 
batch  is  executed.  This  file, created by  CONFIG,  performs  the  TurboDOS
operating  system generation and copies the new TurboDOS operating systems  to
the proper area of the hard disk. The old TurboDOS operating system files  are
saved with an ORG filetype. Should any problems occur with the newly-generated
TurboDOS operating systems, the old ones can be recovered.

Bad spot de-allocation
----------------------
All  hard disk systems must deal with the question of how to detect and  avoid 
defects (known as bad spots) on the hard disk medium. Typically, a disk  drive
will  be shipped by the manufacturer with a few bad spots already on  it,  and
additional bad spots will "grow" as the result of vibration (especially during
shipping), power failures, or aging of the machine.
A  good  hard  disk system must, therefore, deal with  2  different  bad  spot 
scenarios:
        1. A hard disk arrives with bad spots already on it.
        2. A hard disk grows bad spots while it is in use.
Hard disk systems must also deal with 2 kinds of bad spots: "hard" (permanent) 
bad spots and "soft" (intermittent) ones. It is good practice to recognize and
avoid the soft ones as well as the hard ones (even though you can often  retry
enough  times to get past the soft ones) because they tend to get  worse  with
age.
The  issue  is complicated by the fact that the location of the bad  spot  can 
make a big difference in how bad it really is. A bad spot in an unused part of
the disk is not a problem, as long as one can tell the operating system how to
avoid it. A bad spot in a data area is a problem, because data has very likely
been lost. A bad spot in the directory can be fatal.
Generic  TurboDOS comes with a program, VERIFY, which de-allocates bad  spots; 
i.e.,  it  removes them from the pool of available disk space.  VERIFY  has  2
deficiencies, however. First, it finds only hard errors, because it is  forced
to  do  read-only  tests via the normal hard disk drivers,  which  are  fault-
tolerant by design. Soft errors will trigger retries at the driver level,  but
these  retries  are  not reported to VERIFY unless  many  successive  failures
occur.  Second, it can be run only at startup -- the directory must  be  empty
for  it  to work properly. Therefore, it does not help at all with  bad  spots
that grow during use.
North Star's answer was to create a program named MARKBAD. MARKBAD is  similar 
to  VERIFY  in  that it de-allocates disk blocks that contain  bad  spots.  It
differs from VERIFY in 2 important ways. First, it accepts manual input of bad
spots. This allows identification of both soft and hard spots, which are taken
from  the  manufacturer's disk label, from a hard disk test program,  or  from
disk  error messages put out by TurboDOS itself. Second, it can be run at  any
time,  so  that  a  bad spot that grows during use can  be  removed  from  the
available pool.
VERIFY  and MARKBAD both deal with bad spots in the disk's data area.  Neither 
can help if the bad spot is in the directory, because directory blocks  cannot
be  de-allocated.  TurboDOS  requires the  entire  directory  area  (including
allocation  table) to be free of defects. On a 30MB hard disk with a 2K  block
size,  for example, this area occupies 30 tracks, or about 240K.  (ROCHE>  The
size of a standard IBM 3740 8" floppy disk...)
To  alleviate  this situation, North Star developed a means  of  swapping  bad 
directory  tracks with good data tracks in a manner invisible to TurboDOS,  so
that the bad blocks end up in the data area (where they can be de-allocated by
MARKBAD)  and  the  good blocks end up in the directory.  This  preserves  the
maximum  amount of good disk space possible. Another approach would have  been
to  slide  the beginning of the directory out into the first clear  space  big
enough  to  hold it, but a potentially large amount of good disk  space  might
have to be skipped, and that space would be lost.
The swapping of tracks takes place on power up, when a special section of  the 
hard  disk driver reads the North Star bad-spot table from a reserved  portion
of the disk. This bad-spot table is initially written in the factory, and  can
be updated in the field by running the hard disk test-and-format program.
When a disk is shipped with a bad spot in the directory, the first system boot 
will  swap the bad track out into the data area, and MARKBAD will be  told  to
de-allocate  the  affected data blocks. The system will then appear  like  any
other North Star TurboDOS system.
If  a bad spot grows in the directory later, some or all of the disk  will  be 
unreadable.  The procedure is to recover what can be read, then run  the  hard
disk  test-and-format program, and tell it where the new bad spot is.  On  the
next  boot,  the new bad track will be swapped out of the directory,  and  the
system will again be usable. Any lost data has to be recovered from the backup
media.

User interface
--------------
Even though TurboDOS provides a considerably more pleasant user interface than 
CP/M,  it  is designed for computer professionals rather than  for  the  small
businesses that are North Star's principal customers. To present a more easily
understood  set of screens, North Star has bundled Turbo-Plus into North  Star
TurboDOS.  This  is an enhancement package that provides  powerful  additional
facilities  for  TurboDOS. The utilities included are:  DIRDUMP  displays  the
master  directory of any disk; WHO displays a list of all the  current  users;
LOCATE searches any or all drives for a file; BB (Background Batch)  schedules
jobs  to  the  background queue; STATUS monitors the  activity  of  users  and
peripherals;  HELP provides on-line help menus that users may  customize;  TWX
(ROCHE> TeletypeWriter eXchange. An old US and Canadian dial-up communications
service that became part of Telex.) sends messages to other users immediately;
MAIL is an electronic mail facility.
Turbo-Plus is a set of utilities developed by Microserve Inc. for TurboDOS. It 
was  chosen primarily for its extensive on-line HELP messages, as well as  for
its  versatile  electronic mail facility. In addition, Turbo-Plus  contains  a
group of commands that allows the network manager to track utilization, keep a
log of user time, and control other users.
Besides  these  aids  for  less sophisticated users,  Turbo-Plus  also  has  a 
powerful  Background  Batch utility, BB, that allows users  to  schedule  low-
priority  non-interactive  jobs for execution in background mode or  at  times
when the system is lightly used.

Conclusion
----------
By  adding TurboDOS and the new multi-processor hardware developed for  it  to 
the  Horizon, North Star has extended the usage of this popular  computer  for
years to come. And North Star's implementation of TurboDOS brings the power of
a  sophisticated operating system to non-professional users who need  only  to
follow a step-by-step procedure for successful installation and operation.

EOF