TDOS8.WS4
---------
- "For Networks and Multi-user Systems -- TurboDOS"
Ron Fowler
"Microsystems", Vol.5, No.8, August 1984, p.58
(Retyped by Emmanuel ROCHE.)
Gone are the days when simple operating systems satisfied the needs of most
small-system users. Once written primarily to satisfy the relatively modest
requirements of hobbyists and experimenters, microcomputer operating systems
are now designed for performance, with special concern for providing maximum
versatility to the user.
One such operating system is TurboDOS, a product of Software 2000, Inc.
Written originally for the Zilog Z-80 (and recently converted for the Intel
8088/8086 family), this package offers a high degree of CP/M compatibility,
multi-tasking background processing, powerful networking capability, built-in
communications facilities, print spooling, and much more.
This article will take an in-depth look at this powerful system: what you can
expect to gain by using TurboDOS, and what (if anything) you might lose by
giving up CP/M in favor of TurboDOS. We will examine the TurboDOS operating
system and its utilities in detail, and conclude with a section addressed to
the programmer or system developer interested in writing TurboDOS
applications.
(ROCHE> Unfortunately, when I read this article, 30 years later, it is obvious
that Ron Fowler had no experience of MP/M, the multi-tasking, multi-user
version of CP/M... By the way, each time that he says "CP/M", you must
understand: "CP/M 2.2". TurboDOS is, in fact, a multi-processor version of
MP/M. That's why it is more compatible with MP/M than with CP/M (2.2)! Poor
Ron Fowler, not knowing MP/M, is often ecstatic by the capabilities of
TurboDOS, which are exactly (except multiple processors) those of MP/M...)
Background
----------
Much of the information presented here is based on my own custom
implementation of TurboDOS Release 1.3. The evaluation copy of the software
was provided courtesy of North Star Computers, Inc. North Star provides a full
implementation for their own hardware, and offers it bundled with Turbo-Plus,
a TurboDOS enhancement package (which I hope to review in a future article).
While the 1.3 Release of TurboDOS provides Intel 8088 compatibility, this
discussion is limited to the Zilog Z-80 version. The evaluation system is a
networked version, interconnecting a Z-80-based S-100 Bus system with a
disk-less single-board Z-80 computer, through Intel 8255 PIO chips in each
computer. Figure 4 is a schematic of the circuit used to interconnect the 2
systems.
The S-100 Bus system consists of an Integrand mainframe housing a Delta
Products 4-MHz Z-80 CPU, 128K of CompuPro memory, and various I/O boards.
Overview
--------
TurboDOS is structured in a 2/3 arrangement: the main body of the TurboDOS
operating system is analogous to CP/M's CCP and BDOS. This portion is machine-
independent, and is supplied as a group of Microsoft-format REL (relocatable
machine code) files. The remainder of the system is similar to CP/M's BIOS,
and consists of a collection of *DEVICE DRIVERS* (for such things as disk
drives, printers, and network communications). These driver modules are
written by the system integrator; if you purchase a packaged system, these
drivers are already written for you.
The modular design of the TurboDOS operating system allows it to be configured
in an almost infinite variety of forms. Table 1 lists a number of the more
commonly-used modules.
Table 1. Common TurboDOS modules
(NOTE: Modules denoted by an asterisk (*) after the module names are resident
processes.)
Name Function
---- --------
LCLUSR* Supports the Transient Program Area
LCLMSG Contains the system error messages
CMDINT Command line interpreter, similar to CP/M's CCP
AUTLOG Supports COLDSTRT.AUT and WARMSTRT.AUT files
NETSVC* Services network requests. Necessary only in processors that provide
facilities to the network (servers)
NETREQ Makes requests of the network
NETTBL Defines network topology from viewpoint of the local node
DSPOOL* Printer de-spooler (background print)
FLUSHR* Periodically flushes disk buffers
OSNTRY Decodes system calls (C-functions and T-functions)
FILMGR Handles the local file system.
Nodes without disk storage do not require this module.
FILLOK Handles file interlocks
FFOMGR Handles the special FIFO files
FASLOD Fast program-load optimizer
BUFMGR Manages the disk buffers
DSKTBL Defines the available disk drives (local and remote)
CPMSUP Special support for CP/M.
Makes TurboDOS operating system more CP/M-compatible.
CONMGR Handles all console I/O
CONTBL Connects CONMGR to hardware console driver module(s)
DOMGR Handles batch commands
LSTMGR Handles printer output
SPOOLR Handles background spooled-print functions, as well as routine printer
output over the network
RTCMGR Maintains system date and time (real-time clock)
BNKMGR Banked memory support
DSPCHR Multi-tasking kernel; controls CPU dispatching between competing
processes, as well as synchronization and inter-process communications
DSPSGL Special "null" dispatcher; allows a non-multi-task version of TurboDOS
to be created
MEMMGR Controls dynamic allocation of memory
OSLOAD Special module used to create a loader program
COMSUB Common subroutines needed in all versions of TurboDOS
Each major function is isolated in its own module, many of which can be added
to and deleted from the TurboDOS operating system by the user (ROCHE> ? A
*USER* fine tuning a Disk Operating System?), thus providing the ability to
add or subtract functionality. For example, the SPOOLR module contains the
necessary code to implement the TurboDOS print spooling function (described
later). By deleting this module in systems that do not require print spooling
(e.g., single-user systems), the TurboDOS operating system can be made
smaller, allowing more room for disk buffers and transient programs.
Flexible as this assortment of modules may be, it would be demanding a lot to
ask all users to build their own TurboDOS operating system. To avoid this,
TurboDOS is packaged with a number of "standard" versions (Table 2), each
providing a commonly-required configuration.
Table 2. Standard TurboDOS configuration packages
Name Function
---- --------
STDLOADR Cold-start system loader
STDSINGL Single-user version, no spooling
STDSPOOL Single-user version with spooling
STDMASTR Network master
STDSLAVE Network slave without local disks
STDSLAVX Network slave with local disks
(ROCHE> So, The first 3 versions correspond to CP/M, and the last 3 versions
to MP/M. Note the emphasis on spooling. In fact, Digital Research was selling
one DESPOOL program for CP/M Versions 1 and 2, but it only ran reliably on
DRI's Intel MDS-800 microcomputers...)
The system may be configured (and reconfigured) conveniently by using GEN.COM,
the supplied system generation utility. This program is, in fact, a
sophisticated linkage editor that takes its commands from disk files,
providing a high degree of automation in the system generation process. An
additional file (called a PAR file) can be specified to GEN.COM. The PAR file
references, *BY NAME*, parameters within the system. It is a powerful concept:
you can restructure major portions of the system (such as the network
definition tables, disk assignment tables, command-search paths, and many
others) merely by editing the PAR file and regenerating the system.
Most implementations of TurboDOS provide for a boot PROM, allowing the system
to start up automatically at power-on. The boot PROM contains just enough code
to load a file named OSLOAD.COM into the program area. OSLOAD then brings in
the rest of the TurboDOS operating system. My own implementation boots from
CP/M, running OSLOAD as a CP/M transient program. This suits my particular
needs better than setting up a boot PROM -- and, incidentally, illustrates the
versatility of TurboDOS.
When the TurboDOS operating system start up, it prints a sign-on message,
followed by the system prompt. This is where TurboDOS begins to differ from
standard CP/M: the prompt contains the user number, as well as the drive name.
(TurboDOS supports 32 user numbers -- twice as many as CP/M; and the familiar
angle bracket prompt character of CP/M is replaced with a curly bracket:
"A}".)
Depending on how the system is set up, it may be necessary to *LOG IN* before
any useful work can begin. A utility, LOGON.COM, is provided for this purpose,
and another, LOGOFF.COM, is used to terminate the session. TurboDOS may,
optionally, be instructed to maintain a file of logons and logoffs, and
require that a password be specified at login. Passwords are maintained in a
special user accounts file maintained with a text editor. Additional security
allows logon to be retricted to a single user area (this restriction is
specified in the user accounts file). Another login option provides for
privileged logins (non-privileged logins may not change user areas, and
several of the supplied utilities will function only for privileged logins).
The rhythm of this system is a bit different from that of CP/M. For example,
there is no warm boot, since the entire TurboDOS operating system remains in
memory at all times. (CP/M 2.2, of course, allows the Console Command
Processor to be overwritten by a user program, thus requiring that a portion
of the CP/M 2.2 operating system be read back in from disk when a program
terminates) (ROCHE> CP/M Plus ("CP/M Version 3" in the USA), launched in 1983
(so, one year before this article), is a single-user version of MP/M... So,
since it supports "banked memory", the CCP is reloaded instantly from memory.
Each time CP/M Version 2 was spending too much time reading the floppy disk,
the data was stored in memory. 2 examples: the CCP and the directory. That's
why CP/M Plus, in a good implementation, is much faster than CP/M 2.2 running
on the same hardware.)
Additionally, there are no built-in commands; all commands are loaded as
transient programs from the disk. Hence, functions such as ERASE and RENAME
take a bit longer to complete than their CP/M 2.2 counterparts, because time
is needed to load them. Most of the utilities, however, make up for this in
expanded power and versatility, as we shall see. In any case, if a hard disk
is used, the extra time is so small as to be unnoticeable.
From the command level, TurboDOS works similarly to CP/M in that commands are
typed into the system, and the specified files are executed as transient
programs. If, however, your TurboDOS is part of a network, the programs and
files that you use are not necessarily located on your local computer (in
fact, your local computer may not even have any storage facilities (disk
drives) at all!). This networking capability is one of the strongest features
of TurboDOS, and we will examine that aspect of the system in detail later.
CP/M compatibility
------------------
TurboDOS is compatible with almost all CP/M programs. There are only a few
CP/M programs that I have seen that do not work properly under TurboDOS --
mostly public domain utilities that access some of the more obscure BDOS
system calls (7, 8, 24, 28, 29, 31, and 100-107). However, TurboDOS may be
installed with an optional CP/M-support module that will simulate these
missing functions.
Another incompatibility involves CP/M's SUBMIT processing: I am aware of
several commercial packages that make use of CP/M 2.2's special $$$.SUB file
for batch-command processing, and that do not work under TurboDOS because the
$$$.SUB file is not processed. Another optional module is supplied, that
modifies the TurboDOS batch function to emulate CP/M 2.2 more closely (but at
the expense of slowing down DO file processing). The packages mentioned do
work properly under TurboDOS if this module is installed.
Multi-tasking the CPU
---------------------
Beginning a more detailed study of TurboDOS, one of the first things that we
should note is that it can execute more than one task at a time; this
capability is usually referred to as *MULTI-TASKING*. (ROCHE> And MP/M, the
multi-user, multi-tasking version of CP/M, had done it for at least 5 years
when this article was written...)
Integral to the concept of multi-tasking is the *RESIDENT PROCESS*. A resident
process is a program that executes within the system; under TurboDOS, resident
processes are physically attached to the operating system, but logically
maintained outside of it. (That is to say: they perform their task by
executing operating system calls, in the same way that user programs do. The
difference is that user programs are transient in nature, while resident
processes are always present.)
At any given time, a process may be in any of 3 states: ready, running or
suspended. A running process is one that is currently executing on the CPU; a
ready process is one that is waiting to execute (but otherwise ready). A
suspended process (sometimes referred to as "blocked") is a process that is
waiting for some event to happen, or waiting for a period of time to expire.
(TurboDOS provides a system call that allows a process to delay execution for
a fixed time interval.)
The suspended state is perhaps the most significant. A process that is
suspended is "stacked" on one of a number of special lists (called
"semaphores"), and thus does not slow down the system by consuming CPU cycles.
At any given time, most processes will be in this suspended state. Hence, user
programs that are CPU-intensive (i.e., spend most of their time processing
data rather than waiting on I/O devices) run nearly as fast as they would on a
single-task system.
A number of "background" processes, present in each CPU running TurboDOS,
perform such actions as monitoring the network, flushing disk drive buffers
periodically, etc. Additionally, user-written resident processes are
supported; any such process is physically part of the TurboDOS operating
system, and must be added to TurboDOS when the operating system is generated.
Banking the system
------------------
TurboDOS makes good use of bank-selectable memory. When more than one bank is
available, most of TurboDOS resides in Bank 0, while transient programs
execute from Bank 1. (ROCHE> Exactly like CP/M Plus, the single-user version
of MP/M, launched one year before this article...) Since a full-featured
network-master version of TurboDOS exceeds 24K in size, this frees up a lot of
program area. (ROCHE> That's why MP/M used banked memory, since MP/M was a
multi-user version of CP/M. So, each user wanted to have its own TPA, and most
CP/M program wanted as much RAM as possible... So, the only technical solution
was to provide "banks" of memory to each user.)
Banked systems are often measured by the amount of *COMMON MEMORY* that they
consume. Common memory is a section of memory (usually located physically at
the top of the address space) that is always present within the CPU's address
space, regardless of which memory bank is switched in. Since the Zilog Z-80
CPU is limited to 64K of total address space, it is obvious that the common-
memory requirement increases at the expense of the banked segments, and thus
at the expense of memory available to transient programs (in the case
of TurboDOS, at the expense of the allowable size of the operating system).
The only portion of TurboDOS that *MUST* remain in common memory is a small
inter-bank communications module, plus some portions of the interrupt-service
routines. (ROCHE> Exactly like MP/M and CP/M Plus...) Thus, the amount of
transient program area (TPA) available is 63K, even if banked memory hardware
allows bank switching only on 4K or 16K boundaries. (ROCHE> Nothing news,
here. There is even a version of CP/M 2.2 for the Epson QX-10 having a 63.5K
TPA!...)
A utility program, BANK.COM, allows the TurboDOS operating system to be
switched between banked and non-banked mode. When non-banked mode is selected,
programs must share Bank 0 with the operating system.
Disk drives and files
---------------------
TurboDOS supports file sizes of up to 32MB (ROCHE> Like CP/M Plus...) and a
disk drive capacity of up to 134MB (ROCHE> CP/M Plus: 512MB... Of course,
compared to the 8MB of CP/M 2.2, this appeared to be an improvement... Except
that CP/M Plus had been launched by Digital Research one year earlier!...)
Obviously, such large drives will have a lot of files, and will need a lot of
seek time during such operations as file opens, directory searches, etc.
(ROCHE> That's why directories are cached in CP/M Plus.) In an effort to
decrease this time, TurboDOS supports a special directory format called a
*HASHED DIRECTORY*. (ROCHE> MP/M and CP/M Plus did not go this way.) A disk
directory may, at any time, be restructured as a hashed directory (although
the opposite is not true) by running a program named FIXDIR. (ROCHE> CP/M Plus
has something roughly similar, INITDIR.COM, which restructures the directory
to add date and time stamping of files.) Although hashing the directory made
little difference on my small-capacity floppy disks, a hardware dealer I have
worked with (who sells TurboDOS on IMS systems) reports a dramatic speed
increase on his 40MB hard disk systems. (ROCHE> I am not surprised. Me, from
experience, I only use INITDIR on floppy disks, since it consumes 1/4th of the
directory. On the hard disk, I simply type the date and time at the head of
the files.)
Another technique used by TurboDOS to increase performance is disk buffering.
(ROCHE> Called "disk caching" in CP/M Plus.) The system contains a built-in
buffer manager; moreover, a utility program supplied with the TurboDOS
operating system, BUFFERS.COM, lets you change the size of each disk buffer
and the number of buffers *WHILE THE SYSTEM IS RUNNING*. (ROCHE> Under CP/M
Plus, this is done at system generation time, with GENCPM, by the system
implementer.) These buffers are taken "off the top" of the transient program
area (TPA) (in unbanked versions of TurboDOS). If you are going to run small,
disk-bound programs, you can set up a large number of buffers, and increase
disk access speed. Conversely, memory-hungry programs (such as WordStar)
should be run with a small number of buffers, to provide as much memory as
possible. (ROCHE> Well, with "banks" of memory, each user has its own 64K of
memory...)
(I should point out that, while directory hashing made little performance
difference in my system, increasing the number of disk buffers in the system
increased disk throughput dramatically.) (ROCHE> That's why, after tests,
Digital Research added disk caching to CP/M Plus.)
Systems using banked memory may set up most of the unused part of Bank 0 as
disk buffer space, and not affect program memory space at all.
A fast file-load function supplies yet a 3rd performance increase: generally
used by the Command Interpreter (the portion of the TurboDOS operating system
that processes user command lines), this module allows a section of memory to
be loaded in the fastest manner possible. It works by scanning the disk
allocation map, detecting sequentially-allocated segments, and loading these
segments at the fastest transfer rate of the disk controller. (ROCHE> Under
CP/M Plus, the CCP is reloaded from a system Bank, so it is just a memory
transfer, and using the "Multi-Sector Count", allowing up to 16K to be
read/written in one shot...)
File attributes
---------------
TurboDOS expands on the file attributes employed by CP/M. (ROCHE> ???) The
CP/M "SYSTEM" attribute is replaced by the "GLOBAL" attribute. Files resident
in User area 0 and tagged as GLOBAL are accessible from any user area, thus
circumventing the need to duplicate frequently-used files in each user area of
the disk. (ROCHE> Under CP/M 2.2! But MP/M had been available for at least 5
years when this article was written, and CP/M Plus one year!) This global
access applies equally to files that are accessed by application programs
(such as WordStar's overlay files), or chained BASIC programs.
ARCHIVE is another (ROCHE> CP/M...) file attribute that saves time and space
when backing up files. New files are created with the ARCHIVE attribute off.
When a file is backed up using the COPY program, the ARCHIVE bit is set; when
a file is changed (extended, or written to with a random write), TurboDOS
resets the ARCHIVE attribute. COPY can be instructed not to copy files that
have been archived and have not been modified since. This process is called
"incremental backup". (ROCHE> And is provided by CP/M Plus' PIP...)
The final "new" file attribute is FIFO (ROCHE> This is specific to TurboDOS.);
it defines a special type of file accessed using a "first-in, first-out"
(FIFO) technique. FIFO files are accessed from programs like any other file,
except that sequentially-written records are appended at the end of the file,
and sequential reads are taken from the beginning. Moreover, a FIFO file may
be declared as an in-memory file (accessed much faster, since it really does
not exist on disk at all; this limits the size of the file, however, to
available memory.) (ROCHE> Most CP/M Plus implementations have a RAMdisk, so
the limit is 32MB, in this case.) This whole scheme provides a very handy
technique for passing data between background processes, and between programs
executing on different processors. Since a FIFO file can be made to "suspend"
(deactivate) a process reading the FIFO file when it is empty, it is easy to
visualize a background process that only "comes alive" when a program posts a
record to a file monitored by the background process.
Two special utilities are provided to work with FIFO files: SEND and RECEIVE.
SEND is invoked with a FIFO filename and a text string to place in the FIFO.
RECEIVE takes only a FIFO filename; it reads one record from the FIFO file
(thus deleting the record) and displays it. Together, these 2 utilities may be
used to form a rudimentary mail facility between users. (ROCHE> Better to use
CP/NET, which has been available for years...)
File interlocks
---------------
TurboDOS features file and record lockouts, since it supports background
processes that may access files at the same time as foreground processes. In
fact, network support for shared files requires at least one such process in
each file system offering file resources to the network. Interlocks are used
to coordinate file accessing by multiple simultaneous processes and necessary,
for example, when an update program must replace an inventory item's wholesale
and retail price fields. With no coordination, a querying program might read
the record sometime after the update program has begun writing new data, but
before the write is complete. Hence, the querying program reads inconsistent
data. With record locking capability, however, the update program can obtain
exclusive access to the record, "locking out" any other process that may be
attempting to access the same record.
File lockouts under TurboDOS may be configured for strict MP/M compatibility;
thus, existing programs written for MP/M's record-locking techniques (ROCHE>
Like Digital Research's Access Manager...) will work correctly under TurboDOS
(ROCHE> Fortunately, since TurboDOS is a multi-processor version of MP/M.
Hence the need to be compatible with its parent. It is the classical "chicken
and egg" problem.) Alternatively, a set of compatibility flags is available
(during system generation) to change certain rules, providing a number of new
modes not previously available under MP/M. (ROCHE> Modes which disappeared
with TurboDOS, while CP/M is still alive, 30 years later...)
Networking
----------
TurboDOS provides a plethora of features, facilities, and utilities, but, to
me, the single most outstanding one is its built-in networking capability.
(ROCHE> Never heard of MP/M, launched 5 years earlier by Digital Research?
Never seen the advertisements for CP/NET in computer magazines? Why do you
think that TurboDOS is compatible with MP/M? For pleasure?) Multiple computers
running TurboDOS may be interconnected and share such relatively expensive
peripherals as disk drives, printers, plotters, etc.
In this discussion, I will use the terms "node","CPU" and "processor"
interchangeably. (ROCHE> Not a good thing. It shows that the concept of a
network is still a novelty for you. You should have read the MP/M guides
published several years earlier...) Generally, a node can be thought of as a
workstation containing a CPU, memory, a network interface, and (optionally) a
terminal, disk drives, and printers. A node is attached to the network via one
or more connection points. It usually has some peripherals, but does not
*REQUIRE* any.
Two other terms will be used to refer to processors on the network: *MASTER*
(or *SERVER*) and *SLAVE* (or *SATELLITE*). Generally, a server processor
provides resources to the network (such as disk storage and/or printers),
while satellites do not. If satellites have local disks, these can also be
available to the network if the satellite contains the network service module
(NETSVC).
First, it is important to note that TurboDOS does not support multiple users
on a single CPU. (ROCHE> Yes, since TurboDOS is a multi-processor version of
MP/M.) The philosophy, here, is that, since processors and memory are
relatively cheap, why attempt to split up a hundred dollars or so in CPU and
memory hardware when each user can have his own CPU and memory, and suffer
none of the processing delays that are so severe in such operating systems as
MP/M and OASIS? (ROCHE> Good question. By the way, why did TurboDOS
disappear, while MP/M and OASIS are still running, 30 years later, under
emulators on the Internet?)
This concept works, and works well. (ROCHE> You should tell Intel, which never
managed to make its 8086 works this way. I cannot resist mentioning the
following, taken from "Chapter 1: Introduction" of the "Intel 8088/8086 Family
User's Manual", October 1979 (Yes, 5 years *EARLIER*!), page 1-1:
"The 8086 family architecture is characterized by 2 major principles:
1. System functions are distributed among specialized components.
2. Multi-processing capabilities are inherent in the hardware.
3. A hierarchical bus organization provides for the complex data flows
required by high-performance systems without burdening simpler systems
with unneeded capabilities."
This was written in 1979, for a CPU running at 4-MHZ. Today, *45 YEARS LATER*,
Intel has not been able to produce even a single computer using those
"principles"... So, why did Intel, the richest microcomputer company in the
world, never managed to do it, while Software 2000, Inc. (e.g., Mike Busch and
Ron Raikes), did it? Was the Zilog Z-80 CPU so much better than the Intel 8088
of the IBM Clown?)
Each user has full use of his own CPU; delays are generally noticeable only
when shared disk drives are simultaneously accessed by multiple network users.
(Even these delays can be abated by using faster drives with more
sophisticated seek mechanisms -- a cost that can be justified more easily with
TurboDOS, since these expensive peripherals are more easily shared among all
the users.)
TurboDOS supports just about any kind of local network, ranging from simple
implementation involving 2 computers (liked through,say, an RS-232-C channel),
to sophisticated structures with many processors sharing resources over high-
speed data channels. The actual network structure is defined by the system
designer, and implemented in the network driver modules. These modules
constitute what is known in network vernacular as the "physical layer"; they
control the hardware that interconnects the computers.
TurboDOS defines the network as being composed of *CIRCUITS* (which can be
better visualized as a cluster of nodes). A circuit may be composed of up to
255 nodes. Further, there may be up to 255 interconnected circuits in a full
TurboDOS system, allowing for a total of up to 65,535 total workstations in a
TurboDOS network.
The unit of information exchange among network nodes in the *NETWORK MESSAGE*.
This message is a packet of data, containing source and destination node
addresses, byte length and other overhead, as well as the actual data itself
(which may be a disk record, a file control block (FCB), or perhaps a block of
characters to be sent to a printer).
A "forwarding" table may be specified in each node, allowing messages to be
sent between network nodes that are not, themselves, directly connected.
One of the most common techniques that I have seen for implementing a network
with TurboDOS involves S-100 Bus single-board computers. Generally, one
"master" CPU is provided (to control access to disk drives, printers, etc.),
and one or more "slave" processors are placed on the same S-100 Bus as the
master (often these slaves have no local storage of their own but, instead,
rely on the master to provide storage. The user will see the master's disk
drives as if they were connected to his own CPU.) Typically, high-speed
parallel-port channels are provided to allow network transfers at near-bus
speeds. One such system will, generally, be a circuit in itself; multiple
systems may, then, be interconnected, forming a multiple-circuit network.
Figure 1. A typical network
An example should help tie this all together. In Figure 1, we have 2 network
circuits that are relatively independent. Each circuit has a master and
several slaves, as well as disk drives and a printer. Master-to-slave
communication is through a high-speed parallel bus. Master-to-master
communication is through a Local Area Network (LAN) interface and cable. Note
that slave nodes do not have any local disk storage but, instead, use the
master's disk drive (this will likely be a large-capacity hard disk drive,
segmented into several smaller drives, and apportioned among the slaves).
Circuit 1 consists of 4 nodes: the master and the 3 slaves. Similarly, Circuit
2 consists of 5 nodes: the master and 4 slaves, 3 of which are connected via
modems to dial-in phone lines.
Each of the 2 masters are actually "known" on 2 circuits (their own, and the
other master's) and, thus, have 2 circuit drivers within their TurboDOS
operating systems (and 2 network addresses, as a matter of fact).
This system might be part of an overall data-gathering system where field
agents phone in information to the nodes connected to modems (Nodes 2-2, 2-3,
and 2-4); the high-speed dot-matrix printer might be used to maintain a
"running log" of these transactions. This raw information is sorted and
formatted by programs entered by an operator at the terminal located at Node
2-1 (the only "on-site" terminal in Circuit 2) and made available periodically
to Circuit 1 through the RS-232-C link between circuits, where service clerks
work at terminals, filling these orders. The finished orders are, then,
printed up in the form of invoices on the letter-quality printer located on
Circuit 1.
Thus, most information flow between the 2 circuits will take place between the
2 masters (perhaps under the control of a resident process in each). It is
possible, however, to allow communications between slaves on different
circuits, using forwarding tables contained in each slave's operating system.
This might be necessary, for example, to allow field salesmen calling into
Circuit 2 to make an inquiry about an order to a clerk working in Circuit 1.
Proper setup of the forwarding tables will allow this (in fact, the Turbo-Plus
enhancement package provides special system functions and utilities that
simplify this kind of communication).
Reconfiguring the network
-------------------------
Although the physical network is defined in network driver modules, TurboDOS
provides a lot of latitude in reallocating resources, using the previously-
mentioned GEN program. Although these resources are not *DYNAMICALLY*
changeable (that is to say: you cannot make changes while the TurboDOS
operating system is running), it is a relatively simple matter to patch the
tables, and regenerate the system.
Figure 2. Drive allocation example
An example should help to clarify this. Referring to Figure 2, we see 2
processors, named P1 and P2, each with local drives A and B. From the diagram,
you can see that each processor has a drive C, which is the opposite
processor's B drive. (These assignments are made in a table contained in each
node's copy of TurboDOS; this table is called the Disk Assignment Table, and
is usually set up in a PAR file.)
Figure 3. Allocation after regeneration
Now, let us consider changing that. Let us say that we want to delete P2's
ability to reference P1's B drive, and increase P1's available storage to
include P2's drive as P1's D. We simply make a few changes in each node's PAR
file, regenerate each TurboDOS operating system, and we have the structure
shown in Figure 3. This concept applies to other resources, such as printers
and print queues.
Printers and spooling
---------------------
Flexibility is apparent throughout the design of TurboDOS, but nowhere is this
more evident that in the facilities available to produce printed output.
Each processor may have up to 16 printers defined in its tables, and each
printer may be accessed either locally or over the network. Since TurboDOS
provides a CP/M-like environment, only one of these printers may be "current"
at any one time for any one user. A utility program, PRINT.COM, lets you
change the routing of your logical printer output, using syntax such as:
PRINT PRINTER=E (or PRINT P=E)
which selects Printer E in your local printer table. In addition, this utility
allows you to select a much more flexible form of printing: *SPOOLED
PRINTING*. (ROCHE> Ever heard of the "DESPOOL (background print utility)
Operator's Guide", Digital Research, 1979? No? It was frequently found in CP/M
Version 1.4 and Version 2.2 advertisements...)
Spooled printing reroutes your printer output: instead of going directly to
the printer, the output is routed to one of 16 *PRINT QUEUES*. A print queue
is implemented as a set of disk files, using filenames of the form: PRINT-
x.nnn, where x is the queue name (A-P, corresponding to each of the 16
possible queues) and nnn is a 3-digit number used to separate different print
jobs within a queue.
Another utility, PRINTER.COM, controls despooling of these print queues. Any
physical printer may be assigned to any of the queues with a command such as
PRINTER E QUEUE=C (to assign Printer E to the C Queue). A 3rd utility,
QUEUE.COM, allows files to be manually entered into any of the various queues.
Let us tie this all together with an example: suppose your TurboDOS operating
system has 2 printers: Printer 1 is a fast dot-matrix printer, while Printer 2
is a slower letter-quality model (remember, either printer may be attached to
our local network node, or to a remote node -- it does not matter *WHERE* the
printer to be used is actually located). Assume that we have to print several
program listings, a couple of letters, and a long report.
First, we will tackle the letters, since they will likely use single-sheet
paper, requiring a good deal of manual intervention. The command:
PRINT PRINTER=B
gives up direct access to the letter-quality printer (we must be careful,
here, to coordinate access with any other network users, since direct printing
by more than one user will result in interspersed characters in the actual
printout). Now, we fire up the word-processor program, and print each letter.
Not so different from CP/M, so far (except for the ability to switch
printers).
Now, let us tackle the program listings. We can begin to make use of print
queues, here, by entering the following commands:
PRINTER A QUEUE=A
PRINTER B QUEUE=B
Now, we have established Queue A as the queue associated with the dot-matrix
printer, and Queue B with the letter-quality printer. Now, we are ready to
print some listings. The command:
PRINT QUEUE=A
routes our printer output to Queue A; now, we can run our language translator
and begin producing the program listings. Since our output is now going to a
relatively high-speed disk file (as opposed to a slow printer), the language
translator finishes long before the first printout is complete.
In fact, the first output file does not begin printing until its associated
queue file is closed (either by the language translator terminating and
returning to the TurboDOS operating system, or by a special end-print control
sequence from the console). While the first file is printing (in the
background), we can run our language translator once more, to generate the 2nd
and 3rd listings. We might also decide to queue some existing disk files:
QUEUE MYPROG.PRN ;Q=A
QUEUE MANUAL.DOC ;Q=A
QUEUE *.UPC ;DYQ=A
(Note that the Q=A options specify which queue to send the file to. The 3rd
example illustrates queuing multiple files by specifying a wildcard filename.
Additionally, the ;DY portion specifies options. In this case, D causes each
file to be Deleted after printing, and Y causes the QUEUE program to displa(Y)
the name of each file to be queued, allowing the operator to select specified
files.)
Now, we are ready to print the letter-quality documents. The command:
PRINT QUEUE=B
switches our printer output to the queue we have previously associated with
the letter-quality printer. (It does not matter that the files that we have
already queued are still printing; they are now destined for the dot-matrix
printer, and changing the destination of our printer output no longer has any
effect on the previously-queued files.) Now, we can use our word-processor,
and send the letters and the report to the B Queue, similar to the way our
language translator output went to the A Queue.
At this point, we have 2 printers running a number of print jobs entirely in
the background, and our console is free for new work. In addition, any number
of network users can simultaneously queue files on the same printers, without
intermixing printer output.
To conclude the discussion, I must mention that there are many more print
options and features than those mentioned here; to review each of them,
however, is beyond the scope of this article.
Batch files
-----------
TurboDOS allows the execution of batch-command files in a way similar to
CP/M's SUBMIT facility, but with enhanced capabilities. The TurboDOS version
of SUBMIT is named DO.COM; specifying DO with a filename will cause the system
to begin reading its input from the file.
DO files may be nested (ROCHE> Like SUBMIT under CP/M Plus...), to any
reasonable depth (ROCHE> 128 levels under CP/M Plus.), merely by placing a DO
statement within a DO file. After the subservient DO file is executed, control
returns to the superior file at the point where processing left off.
Command-line parameters may be specified in a manner similar to CP/M's SUBMIT.
However, the parameters are referred to, in the DO file, by enclosing them in
curly brackets, rather than the dollar sign notation of CP/M. Also, the
parameters in the DO command line may be made to contain embedded spaces by
enclosing them in quotes.
A handy option within the DO file allows default parameters to be filled in by
adding a comma and a default value within the curly brackets. Consider the
following line within a DO file:
L80 {1} {2,SYSLIB}
If this DO file is invoked only with Argument 1, then the value SYSLIB is
automatically supplied as the 2nd Argument.
Another important characteristic of DO files is that they can provide input
for more than just system commands. Programs that require interactive input
will receive that input from the DO file (thus, DO combines the features of
both the CP/M 2.2 programs SUBMIT and XSUB). (ROCHE> CP/M Plus has a much
better and more powerful SUBMIT utility.)
DO is somewhat faster than CP/M 2.2's SUBMIT when no command-line parameters
are specified. Since there is no need to rewrite the DO file with parameters
filled in, DO simply informs TurboDOS to begin executing the file (SUBMIT must
always write a $$$.SUB file).
Utilities
---------
TurboDOS is supplied with a large number of utilities, some of which have
already been described. The major remaining utilities are as follows:
AUTOLOAD allows a user to set up command lines that automatically execute on
either cold or warm boot. COLDSTRT.AUT, the cold boot file, executes only
once, when the TurboDOS operating system is first started up. WARMSTRT.AUT is
executed at the completion of each transient program.
BACKUP performs a fast disk copy. It is usable only when the source and
destination diskettes are of the same format.
BATCH is useful in network environments, and uses a special FIFO file (named
BATCH.DO) to send a command line to a remote processor for execution. Remote
processors that use this facility (i.e., those which are to be available for
batch jobs) must execute the command DO BATCH via an AUToload file at system
startup.
BOOT allows the system tracks of a diskette to be copied to another diskette.
Note that TurboDOS allows 100% of the floppy disk space to be used for file
storage; however, in some implementations, the hardware demands cold-starting
from reserved system tracks.
CHANGE is used to safely allow removable disks (i.e., floppies or removable
cartridges) to be changed in a network environment. CHANGE.COM takes one or
more drive letters as arguments, and aborts with an error message if any
process has open files on the requested drive. If the requested drive is free,
CHANGE locks the drive until the user indicates that the disk has been changed
(any user trying to access the drive while it is locked will receive a disk
error message).
COPY, which was previously mentioned, allows files to be copied between disk
drives. A large number of command-line options make this an extremely
versatile file copy and archiving program.
DELETE performs the same functions as CP/M's ERA. A command-line option causes
DELETE to present each filename to be erased, and requests the operator to
confirm before deleting. (ROCHE> "The CONFIRM option informs the CP/M Plus
operating system to prompt (the user) for verification before erasing each
file that matches the filespec." CP/M Plus User's Guide, Section 5: Command
Summary, "The ERASE command".)
DIR prints a sorted directory on the screen (or, optionally, on the printer).
The display contains a lot of the information available under CP/M only
through the CP/M 2.2 STAT command (such as filesizes and disk free space). It
also includes time of day and combined size of files displayed, as well as
user-number specification.
DRIVE displays information about the disk format (similar to CP/M 2.2's STAT
DSK:).
FIFO is used to create and delete the previously-described FIFO files.
FIXDIR is a handy utility that reorganizes a disk directory. This is useful
when frequent file creations and deletions occur (especially on hard disks).
FIXDIR compacts the directory, eliminates "holes", and makes file searches
faster. Also used to convert a directory to the hashed format, or vice-versa.
(ROCHE> ??? Ron wrote "the opposite is not true" in the "Disk drives and
files" paragraph...)
FORMAT allows a diskette to be formatted in single density or in CP/M or
TurboDOS double-density format. It automatically calls VERIFY after formatting
is complete. (ROCHE> VERIFY marks all the "bad spots" of a disk. That's why it
is used after formatting the disk.)
MONITOR is the TurboDOS replacement for CP/M 2.2's DDT program. Intended
mainly for program patching, etc., it contains a save function as well as a
load function (this is necessary because TurboDOS lacks CP/M 2.2's SAVE
command). A number of other commands not found in DDT are present in MONITOR.
(ROCHE> ASM and DDT were provided with CP/M 2.2. MAC and SID were professional
versions that were available separately, at a cost.)
Noticeably lacking, however, are DDT's opcode assembler and disassembler
(ROCHE> The A and L commands.), and single-step trace functions (ROCHE> The
TRACE utility of SID.). For program debugging, DEBUG (Phoenix Software
Associates (ROCHE> Software 2000, Inc., used their PASM to assemble TurboDOS.)
or ZSID (Digital Research, Inc.) both work well under TurboDOS. (ROCHE> This
is no surprise...)
RENAME is used to change the names of files. This utility has a syntax
backward from that of CP/M. (Most people who have worked with other operating
systems claim that it is CP/M that has it backward. I am inclined to agree.)
(ROCHE> You (and them) are wrong. Demonstration: How work the opcodes of the
(real, physical) processor? You write MNEMONIC DESTINATION,SOURCE... There is
no exception to this rule! So, is the CPU behaving crazily? Another
demonstration: When you send dozens of different files to the same place. If
the destination is at the beginning of the command line, you just edit the
source specification, conveniently located at the end of the command line...
which can be reached with one single control char!) This utility has the handy
option of renaming by using wildcards. For example, the command RENAME *.BAK
*.ASM renames all BAK files to ASM (a command-line option allows you to verify
any rename that would cause an existing file of the same name to be
overwritten). (ROCHE> "If the file given by NEWNAME is already present in the
directory, RENAME displays the following message on the screen: Not renamed:
FILENAME.TYP file already exists, delete (Y/N)?" CP/M Plus User's Guide,
Section 5: Command Summary, "The RENAME command".)
SERVER has been renamed by North Star. The standard TurboDOS distributed by
most vendors refers to this utility as MASTER.COM. In any case, its purpose is
to allow a slave console to act as a terminal to the master, a function useful
for running programs in the master processor.
SET is used to set and clear file attributes; SHOW displays them. (ROCHE> Just
like MP/M and CP/M Plus...)
TYPE displays ASCII files on the console or (optionally) on the printer.
USER allows privileged logins to change the currently-logged user number. This
is one command that I wish had been built into the TurboDOS operating system.
(ROCHE> Ron ported TurboDOS Release 1.3. As far as I know, the Command
Interpreter of TurboDOS Release 1.4 recognizes the small form of changing user
numbers (1:), without the need of running the transient program USER.COM.)
VERIFY scans a disk for bad blocks, and locks them out.
Program interface
-----------------
As you would expect, TurboDOS provides a good many additional system calls for
the programmer. (ROCHE> Well, TurboDOS being a multi-processor version of
MP/M, most of them have been existing under MP/M for about 5 years...) Non-
programmers may want to skip this section.
First of all, CP/M-compatible system calls are vectored through location 5 (as
you would expect); versions of TurboDOS prior to Release 1.3 included extended
system calls vectored in the same way. (ROCHE> Like MP/M...) Recent re-
releases of CP/M and MP/M, however, have caused some conflicts with TurboDOS
extended functions. (ROCHE> ???)
To correct this problem, TurboDOS Release 1.3 moved all TurboDOS extended
system calls to location 80 (0050H). CP/M-compatible (ROCHE> Which version of
CP/M? 2 or 3?) system calls are now referred to as C-functions, and TurboDOS
extended system calls as T-functions.
Resident processes must often make system calls; they cannot call location 5
or 50H. (ROCHE> ??? Why?) Two special entry points are provided for this
purpose, and must be called symbolically. They are: OCNTRY (C-functions) and
OTNTRY (T-functions). (ROCHE> So, O means Operating system, C means CP/M, and
T means TurboDOS.) The calling conventions are, otherwise, strictly the same
as they would be for a transient program. For example, to set the DMA buffer
address, you would use the following code:
MVI C,SetDMA
LXI D,Buffer
CALL OCNTRY#
A wide range of T-functions is provided (see Table 1) for such varied things
as creating and deleting resident processes, allocating and de-allocating
memory, inter-process communications, date/time functions, extended file and
disk drive requests, and more. A few of the more interesting functions are
described here.
Communications channel support (T-functions 34-40): A full complement of
functions allows complete access to the optional communications system
(generally implemented in the form of RS-232-C drivers by the system
implementer). These functions allow such actions as send/receive character,
read status, get/set baud rate, and get/set modem controls. They also allow
the creation of system-independent communications software for TurboDOS --
something that is impossible with CP/M. (ROCHE> ??? And CP/NET, what is it
doing? It is not tied to any protocol or hardware!)
Delay process (T-function 2) circumvents the need for software timing loops.
This function allows a program (or resident process) to delay by increments as
fine as the system "tick" time (generally 1/60th of a second). (ROCHE> In the
USA. 1/50th of a second in Europe.)
Return serial number (T-function 12) returns the complete serial number of the
TurboDOS operating system. (This function can be used to discourage piracy by
keying the purchaser's TurboDOS operating system to your software package.)
Load file (T-function 15) uses the previously-described Load Optimizer to load
code segments into the program area. Handy for loading overlays.
Activate DO file (T-function 16) allows a program to begin a batch processing
job. (Compared to writing the old backward $$$.SUB file with CP/M 2.2,
starting batch jobs under TurboDOS is simple with this system call.)
Send Command Line (T-function 18) allows creation of applications such as
menus from assembly language programs. It does not work quite the same way as
MP/M's similarly-named function (ROCHE> This must be a coincidence?), however,
in that the passed Command Line is not executed immediately (as it is in MP/M)
but is, instead, deferred until the calling program terminates. You may
"stack" command lines by calling this function more than one.
Printer control functions T-functions 27-30) allow complete programmatic
access of the printer spooling and despooling mechanisms. Function 28 (signal
end-of-print) is especially handy, since it allows a queued print job to
actually begin printing.
User-defined function (T-function 41) belongs to the user, for any purpose
that he desires to write code for. It can take full advantage of the network
for communications between processors. To implement this function, you must
write your function in a module that defines the public symbol USRFCN;
register-passing conventions are described in the "TurboDOS Release 1.4 Z80
Programmer's Guide". Once the function is in place, your applications program
may communicate with it simply by calling T-function 41.
Documentation
-------------
No software evaluation can be considered complete without a look at the
documentation supplied with the package. In the case of TurboDOS, I have to
rate the documentation effort outstanding! (ROCHE> Interesting. Apparently,
not everyone thinks like you. "Many features of TurboDOS go underutilized (or
totally ignored) due to the difficulty in deciphering the manuals." and "the
manuals are indescridably bad." This opinion was published in nothing less
than the "ACM SIGSMALL Newsletter"! Reference: Vol.10, No.3, August 1984,
p.24, "The TurboDOS Operating System", Keith Bierman.)
Three manuals are provided with the Z80 TurboDOS operating system: a User's
Guide, a Z80 Programmer's Guide, and the Z80 System Implementer's Guide. Each
includes a table of contents; the System Implementer's Guide is the only
manual lacking an index.
The User's Guide begins with basics, and takes the reader through the
gradually more complex subjects of files, disks, printing, and processing,
concluding with a summary of the entire set of 35-odd utilities that are
provided with the TurboDOS operating system. The language is "gentle" and very
readable.
The Programmer's and Implementer's Guides are understandably more complex,
since they deal with subjects that are technical in nature. They are complete,
and provide sufficient information to enable the programmer to do his job.
(ROCHE> Again, Ron implemented TurboDOS Release 1.3. Release 1.4 adds the 8086
programmer's Guide and the 8086 Implementer's Guide. TurboDOS thrived when it
was written in Z-80 assembly language for S-100 Bus systems, and disappeared
when it was rewritten in the C language for the IBM PC...)
Conclusion
----------
As you see, TurboDOS provides powerful facilities for both the user and the
programmer. After more than 3 years on the market (it was first released in
April 1981) (ROCHE> So, MP/M had already been existing for 2 years when
TurboDOS appeared... Guess which is the chicken? Which is the egg?), TurboDOS
is still being continually refined. (By the time you read this, Release 1.4
should be available. This new release will feature full Intel 8088/8086
compatibility at both the slave *AND* the master level, as well as a PC DOS
emulator.) (ROCHE> Emulating MS-DOS Version 1 under TurboDOS on a S-100 Bus
system? Vade Retro, Satanas!)
I have recently obtained a Mega Z-80 system, featuring 512K bank-selectable
RAM and 27 *MEGABYTE* Winchester hard disk drive, for which I plan to do a
full master-to-master implementation of TurboDOS (complete with RAMdisk). As
"Microsystems" magazine expands its TurboDOS coverage, I hope to provide a
follow-up article on this project, as well as a review of Turbo-Plus, and (if
there is sufficient interest) a tutorial on TurboDOS implementation and
programming technique. (ROCHE> This article was the last one written by Ron
Fowler...)
EOF
- Details
- Hits: 5487
TDOS7.WS4
---------
- "Printer Networking with TurboDOS"
Tedd Kurts, MuSYS Corporation
"Microsystems", Vol.5, No.10, October 1984, p.106
(Retyped by Emmanuel ROCHE.)
In working with TurboDOS users on a daily basis, I have observed many of them
attempting printer configurations, only to find their efforts unsuccessful.
The problem appears to stem from a lack of understanding of the printer
networking concepts involved. This article will outline the steps necessary to
configure a TurboDOS operating system with one or more printers.
There is a radical difference between CP/M or MP/M operating systems and
TurboDOS. No printer drivers (or only skeletal examples) are supplied with a
CP/M or MP/M as purchased from Digital Research,Inc. The user must write his
own drivers, and integrate them into the I/O section of the operating system;
he must, therefore, be a competent assembly language programmer, and
understand the workings of the CP/M BIOS or MP/M XIOS. (ROCHE> I had the
curiosity of searching for "Printer" in the Index of "The CP/M Programmer's
Handbook", by Andy Johnson-Laird, Osborne/McGraw-Hill, 1983, the only book
ever written on the subject of writing a BIOS for CP/M. There are only 3
entries: "Printer echo", "Printer errors", and "Printer timeout error". This
is because printers are, fundamentally, outside the microcomputer running
CP/M. Hence, only CP/M programs dealing with printers (like WordStar) have
(their own) printer drivers.)
TurboDOS, on the other hand, comes with several printer drivers for various
methods of handshaking; these are assembled in Microsoft RELocatable format,
and need only be linked to the body of the TurboDOS operating system by means
of the GEN (system generation) utility (also supplied). For fine tuning,
PARameter files can be created or modified with a simple text editor. Thus,
the person who "generates" a bootable TurboDOS operating system from the
modules supplied in Microsoft REL form need not be an assembly language
programmer (ROCHE> ??? How many end users are familiar with Microsoft REL
files and linkers?), though he must understand what functions the printer
drivers and PARameter files perform, and how to modify them to suit his needs.
(ROCHE> Isn't it the job of the "System Implementer" to port/implement
TurboDOS on a particular hardware, so that the user can use the software?)
The procedure falls into the following steps:
- Determine the handshaking required by your printer(s), and select the
appropriate driver module(s).
- Determine the baud rate to be used, and create a corresponding patch
in a PARameter file.
- Assign the printer to a spooling queue by a patch in a PARameter file.
Exampes will be given, showing exactly how to perform theses steps.
1) Printer handshaking and cabling
----------------------------------
To determine what handshaking protocol should be used (and, consequently,
which printer driver module to select), consult your printer manual. The most
commonly-used methods are hardware handshake (sometimes called CTS (Clear To
Send) protocol); XON/XOFF protocol; ETX/ACK protocol; or a combination of
hardware handshake and one of the other two (ROCHE> Software handshakes.). All
of these can be used with serial printers; a special form of hardware
handshake, standardized by Centronics, is generally used for parallel
printers.
When hardware handshaking is used on an RS-232-C serial channel, only 3
conductors are required: the data line (from computer to printer); a control
signal line; and the signal ground line. The printer accepts characters until
its buffer is about 3/4 full; it then turns off the control signal. The
computer must be able to detect this signal, and stop sending, until the
printer turns the signal on again, when the buffer is nearly empty. The
control signal chosen is usually DTR (Data Terminal Ready, pin 20 of the 1969
RS-232-C standard) or RTS (Request To Send, pin 4), but some printers use
other signals. This is the industry-preferred protocol, for several reasons:
1) only one data channel is needed;
2) it is a hardware handshake and, therefore, the driver is simple and
takes less CPU time;
3) a cable disconnection during printing does not cause loss of data.
When the cable is reconnected, printing picks up where it left off.
When XON/XOFF protocol is used, 2 data channels are required: one from
computer to printer, the other from printer to computer. The printer accepts
characters until its buffer is nearly full, and then sends the XOFF code
(Transmit OFF, or "pause transmission", ASCII DC3, Control-S, 13H) to tell the
computer to stop sending; when the printer is ready to accept more characters,
it sends the XON code (Transmit ON, or "resume transmission", ASCII DC1,
Control-Q, 11H).
When ETX/ACK protocol is used, 2 channels are again required. The computer
sends a fixed number of characters to the printer (amounting to about 75% of
the buffer capacity) followed by an ASCII ETX (End-of-TeXt, Control-C, 03H)
character; it then waits until it receives an ASCII ACK (ACKnowledge, Control-
F, 06H) character from the printer.
Both XON/XOFF and ETX/ACK can lose data in the event of a cable disconnection.
For this reason, they are sometimes combined with a hardware handshake.
If the printer can use more than one of these protocols, selection is done by
setting switches or placing jumpers on the circuit board.
Care must be taken to see that the cable connects the correct pins of the RS-
232-C connectors at each end. Devices designated DTE (Data Terminal Equipment)
send data on pin 2 and receive it on pin 3; devices designated DCE (Data
Communications Equipment) receive on pin 2 and send on pin 3. Thus, the cable
connecting a DTE device to a DCE device has corresponding pin numbers
connected. If, however, both devices are DTE or both are DCE, then the cable
connecting them must have pins 2 and 3 at one end connected to pins 3 and 2 at
the other. Also, if the control signal appears on (say) pin 14 at the printer
but is required on pin 20 at the computer end, the cable must have this cross-
connection also.
Printer drivers
---------------
For each of the protocols described above, TurboDOS has a corresponding
driver. The most common ones are designated LSTCTS.REL (CTS hardware
handshaking); LSTXON.REL (XON/XOFF protocol); LSTETX.REL (ETX/ACK protocol);
and LSTCEN.REL (a Centronics parallel printer driver used mainly in Televideo
implementations). Less common are LSTPAR.REL, the driver for a standard
Centronics parallel printer; and LST300.REL, a simple, slow-speed, Teletype-
like serial driver. This has no provision for error detection, and relies on
the printer being able to keep up with the transmission rate. One or more of
these drivers is placed in the GEN file of the appropriate server or satellite
processor when the GEN (system generation) program is run to generate the
TurboDOS operating system.
2) Setting printer baud rates (BR)
-----------------------------
After determining handshaking and selecting the appropriate driver module, the
baud rate should be checked against the default value for that driver. If some
rate other than the default is desired, use a text editor to modify the
appropriate patch point in the PARameter file containing global symbolic
patches for the node. Examples of symbolic patch points are shown in Listing
1.
Listing 1
---------
Baud Rate patch point (PAR) Printer driver (GEN)
--------------------------- --------------------
CTSBR = hn ln Default=6E LSTCTS
XONBR = hn ln Default=07 LSTXON
ETXBR = hn ln Default=07 LSTETX
where hn represents the high-order 'nibble' (4 bits), which can have only 3
valid values in these particular patch points:
0 Represents the disabling of all hardware handshaking.
4 Represents hardware handshaking.
Bit 6 is set, and enables CTS.
Is used with XONBR and ETXBR drivers to enable the respective protocol
+ CTS.
6 Represents hardware handshaking for output only (input disabled).
Is used for all CTSBR patch points.
and ln represents the low-order nibble, which can have 16 valid values
representing the 16 baud rate values. The most common are:
5 = 300
7 = 1200
E = 9600
Example: CTSBR = 6E ;CTS handshaking at 9600 baud
XONBR = 47 ;XON/XOFF + CTS handshaking at 1200 baud
XONBR = 07 ;XON/XOFF handshaking at 1200 baud
ETXBR = 05 ;ETX/ACK handshaking at 300 baud
Print spooling
--------------
The 2 print modes are either spooled or direct. In most multi-user
applications, spooled printing is preferred over direct. When a file is
spooled, TurboDOS creates a print file on the disk. When the print job is
done, TurboDOS will queue the print files for de-spooling in a first-in first-
out (FIFO) manner. Print file de-spooling is a background process that is done
automatically.
The De-SPool Printer Assignment Table (DSPPAT), in the module LSTTBL, is an
array of 16 bytes (for printer A-P) that defines the queue assigned to each
printer. Positions 1 through 16 in the array correspond to printers A-P,
respectively. The hex value (01-10, corresponding to printers A-P) found at
each position in the array defines the queue to which that printer is
assigned. A value of 00H indicates that the printer is off-line. The default
value (01H) assigns all printers to queue A. A de-spool assignment table looks
like this:
DSPPAT = 01,01,02,02 ;Printer A to Queue A,
;printer B to Queue A,
;printer C to Queue B,
;printer D to Queue B, etc.
The files created by the spooler default to the system drive. To change the
default, you may patch the symbol SPLDRV in the module LCLTBL, as follows:
SPLDRV = 0FFH ;0FFH is default for system drive.
;Hex value of 0-F specify spool drive of A-P.
The print mode for a local user is determined by the symbol PRTMOD, located in
module LCLTBL. The default value is 1, which specifies spooling. To change the
default, patch PRTMOD as follows:
PRTMOD = 1 ;1 is default for spooling.
;Hex value of 0 for direct printing,
;and 2 for print to console.
Print queues
------------
A print queue is a list of print jobs awaiting de-spooling. The QUEue
ASsignment Table (QUEAST) defines which queues of A-P are local, remote, or
invalid. Also specified are the network addresses for each remote queue.
QUEAST = 00,(0000) ;Queue A local -- First 3 bytes zero
0FF,(0000) ;Queue B invalid -- First byte 0FFH
The patch symbol QUEPTR in module LCLTBL specifies initial queue or printer
assignments. If print mode is spooled, this symbol specifies a queue
assignment. If print mode is direct, this symbol specifies a printer
assignment.
QUEPTR = 1 ;1 is default.
;Hex values of 01-10 represent assignments of A-P.
;Zero signifies no queue, or printer off-line.
3) Printer assignment
---------------------
There are 2 classes of printers in a TurboDOS network: local and remote. The
PrinTeR ASsignment Table (PRTAST) contains, for each local or remote printer
in the system, one byte specifying the printer, and 2 bytes in parentheses
specifying the node address of the printer. In the printer designation byte,
the high-order nibble can only have 2 values: 0, signifying a local printer
physically attached to the node; or 8, signifying a remote printer attached to
some other node. The low-order nibble specifies the printer number (0-0FH,
corresponding to printers A-P). The following is an example of an entry:
PTRAST = 00,LSTDRA,0FF,(0000),01,LSTDRA,85,(0002)
where:
00,LSTDRA -- Local printer A to channel 0
0FF,(0000) -- Printer B is invalid
01,LSTDRA -- Local printer C to channel 1
85,(0002) -- Printer D is printer F on Remote node 2.
In looking at the first bytes (00, 0FF, and 01), we find 2 Local printers
attached to this node, and one Remote (85). The high-order nibbles (0 and 8)
indicate Local and Remote printers, respectively. The low-order nibbles
indicate that Printer A is attached to channel 0 (first serial port) and
Printer C is attached to channel 1 (second serial port).
Local printer configurations
----------------------------
Any node (whether server or a satellite) can be configured for up to 16
printers, designated A-P. These printers can all be in use simultaneously, and
have other print jobs waiting in the queue. Before attempting to work with
full networking, we will look at local printer configurations.
Listing 2
---------
NODE.GEN ;TurboDOS operating system GENeration file
LSTPAR ;Printer driver for Parallel (Centronics) interface
LSTCTS ;Printer driver for CTS hardware handshake
LSTETX ;Printer driver for ETX/ACK software handshake
DSPOOL ;Despooler for Local printer (only goes in satellites)
NODE.PAR ;TurboDOS operating system PAR(ameter) file
CONAST = 00,CONDRA ;First serial channel -- Console terminal
PTRAST = 00,LSTDRA ;Parallel port -- No serial channel used
01,LSTDRB ;Second serial channel -- Second printer driver
02,LSTDRC ;Third serial channel -- Third printer driver
DSPPAT = 00,01,02 ;No queue (Direct)
;Second printer Queue A
;Third printer Queue B
QUEAST = 00,(0000),00,(0000) ;Queues A and B are Local queues
CTSBR = 6E ;CTS with handshake at 9600 baud
XONBR = 07 ;XON without handshake at 1200 baud
Figure 1. Local printer configuration with parallel CTS and XON/XOFF
protocol
The example shown in Listing 2 has 3 printers on a node. The first printer is
Direct, and uses a parallel interface. The second printer is Spooled, with
hardware handshaking at 9600 baud. The third printer is Direct, with a
software handshake at 1200 baud. See Figure 1. Note that the assignment of
LSTDRA is a 2-byte value assigning a Local printer to the first printer driver
in the GEN file. The assignment of LSTDRB is for a Local printer using the
second printer driver in the GEN file, etc.
Note that the parallel driver (LSTPAR) does not use a serial channel for
communication with the printer, and this must be explicitly stated in the
PTRAST entry. Note, too, that the positions of the printer drivers in the GEN
file directly correlate to how printers are assigned in the table. The last
letter of LSTDR? tells the printer assignment table which driver to use in the
GEN -- i.e., LSTDR(A) uses the first printer driver in the GEN, LSTDR(B) uses
the second printer driver, and LSTDR(C) uses the third printer driver.
Listing 3
---------
NODE.GEN ;TurboDOS operating system GENeration file
LSTCTS ;Printer driver for CTS hardware handshake
LSTETX ;Printer driver for ETX/ACK software handshake
LSTXON ;Printer driver for XON/XOFF software handshake
DSPOOL ;Despooler for Local printer (only goes in satellites)
NODE.PAR ;TurboDOS operating system PARameter file
CONAST = 00,CONDRA ;First channel -- Console terminal
PTRAST = 01,LSTDRB ;Second channel -- Second printer driver
02,LSTDRC ;Third channel -- Third printer driver
03,LSTDRA ;Fourth channel -- First printer driver
DSPPAT = 01,02,03 ;Printer A to Queue A, B to B, etc.
QUEAST = 00,(0000),00,(0000) ;All Queues valid and Local
00,(0000)
CTSBR = 6E ;CTS printer at 9600 baud
ETXBR = 0C ;ETX/ACK at 4800 baud
XONBR = 67 ;XON/XOFF + CTS by setting high-order
;nibble to 6, at 1200 baud.
Figure 2. Local printer configuration with ETX/ACK, XON/XOFF plus CTS
and high-speed CTS
The example given in Listing 3 shows 3 printers on a single node. The first
printer is Spooled, with software handshaking (ETX/ACK) at 4800 baud. The
second printer is Spooled, with both a software and hardware handshake
(XON/XOFF and CTS) at 1200 baud. The third printer is Spooled, with a hardware
handshake at 9600 baud. See Figure 2.
Printer networking
------------------
TurboDOS, by its nature, is a networking operating system that networks via a
distributed processing architecture. A TurboDOS circuit is a network
communication path between individual processor nodes. In a single computer
system, there is a simple and closely-coupled connection between the nodes. An
area of confusion to TurboDOS users is printer networking, partly due to a
lack of detailed documentation. Listing 4 comprises some examples that will
illustrate networking applications.
Listing 4
---------
PTRAST = 00,LSTDRA,81,(0001)
where:
00 is one byte consisting of a high-order nibble (Local=0, Remote=8) and a
low-order nibble (Local=port or channel number, Remote=printer A-P in Hex
values of 0-F).
LSTDRA is a 2-byte assignment entry (global symbolic address of driver entry
point) for Local printers, in which the last substitution character points to
the printer driver to use in the GEN file, e.g., A = First Driver, B = Second,
C = Third.
81 is a Remote printer, which is Printer B in Remote's PTRAST.
(0001) is the Remote assignment entry in which the first byte of 00 refers to
the circuit, and the second byte of 01 refers to the node on that circuit
(Circuit 00 = server, Node 01 = First satellite).
For a remote printer, the first byte must have the Sign bit set. To set the
Sign bit, the high-order nibble of the first byte must have the Hex value of
8. This lets the Local Node know that this is a Remote printer, and is not
physically attached. The low-order nibble of the first byte specifies the
printer letter to be accessed on the Remote processor. The 'word' following
the first byte specifies the network address of the Remote processor,
consisting of a Circuit and a Node. When referring to hardware, a word for an
8-bit processor is 8 bits and, for a 16-bit processor, is 16 bits.
When referring to words in TurboDOS (on both 8- and 16-bit processors), a
single word is 2 bytes or 16 bits. A word is specified in the PARameter file
whenever a Hex value greater than 255 is entered, or when the value is
surrounded by parentheses.
Another printer assignment might be written this way:
PTRAST = 00,LSTDRA,0FF,(0000),01,LSTDRA,83,(0001),84,(0001)
This assignment defines 2 printers physically attached to a Remote satellite
node. Setting the high-order nibble of the first byte to 8 tells the Local
node (server) that 2 other printers are Remote. The Local node (server) "sees"
them as printers D and E, corresponding to the order of the printers in the
assignment table. The low-order nibbles of the first bytes, with values of 3
and 4, respectively, tell the Local system to look to the printer assignment
table of the Remote node for D and E. The 2-byte entry (Circuit 00, Node 01)
tells the Local processor that the Remote printers are attached to Node 1 of
the network (satellite 1).
Printer assignment of Remote node (satellite 1) would look like this:
PTRAST + 9 = 01,LSTDRA,02,LSTDRA
This assignment shows a 9-byte offset resulting from 3 printers being assigned
to the system defaults on Node 0. Each printer on Node 0 (A, B, C) takes up a
3-byte entry; thus, 3 bytes * 3 system printers = 9 byte offset in Remote
PTRAST. Printer D is Local, and physically attached to serial channel 1, while
printer E is Local and physically attached to serial channel 2.
A remote networking example is given in Listing 5; please, refer to Figure 3
for a diagramatic representation. When configuring a network, it helps to draw
diagramatic representations like the ones of Figures 1, 2, and 3, to aid in
visualizing the network.
Listing 5
---------
MASTER.GEN ;TurboDOS operating system Master GENeration file
NETREQ ;Network request module
MSGFMT ;Message format tables for NETREQ
LSTCTS ;Printer driver for CTS hardware handshake
LSTPAR ;Printer driver for Parallel handshake
MASTER.PAR ;TurboDOS operating system PARameter file
CONAST = 00,CONDRA ;First serial channel -- Console terminal
PTRAST = 01,LSTDRA ;Second serial channel -- First printer driver
00,LSTDRB ;Parallel channel -- Second printer driver
80,(0001) ;Printer C is printer A on R-node#1
80,(0002) ;Printer D is printer A on R-node #2
QUEAST = 0,(0),0,(0) ;Queues A and B are valid Local queues
80,(0001),80,(0002) ;Queues C and D are valid Remote queues
DSPPAT = 01,02,03,04 ;Printer A to Queue A, B to B, etc.
CTSBR = 6E ;CTS printer at 9600 baud
SLAVE1.GEN ;TurboDOS operating system Slave 1 GENeration file
NETSVC ;Network service local printer request
DSPOOL ;Print despooler for local printer
LSTETX ;Printer driver for ETX/ACK handshake
SLAVE1.PAR ;TurboDOS operating system Slave 1 PARameter file
PTRAST = 01,LSTDRA ;2nd serial channel -- 1st printer driver
0FF,(0),0FF,(0),0FF,(0) ;Printers B, C, D are Invalid
QUEAST = 0,(0) ;Local Queue A is Valid
0FF,(0),0FF,(0),0FF,(0) ;Queues B, C, and D are Invalid
ETXBR = 0C ;ETX/ACK handshaking at 4800 baud
SLAVE2.GEN ;TurboDOS operating system Slave 2 GENeration file
NETSVC ;Network service local printer request
DSPOOL ;Print despooler for local printer
LSTXON ;Printer driver for XON handshake
SLAVE2.PAR ;TurboDOS operating system Slave 2 PARameter file
PTRAST = 01,LSTDRA ;Second serial channel -- First printer driver
82,(0000) ;Printer B is printer C on R-node #0
0FF,(0),0FF,(0) ;Printers C and D are Invalid
QUEAST = O,(0) ;Local Queue A is valid
82,(0) ;Queue B is Queue C on R-node #0
0FF,(0),0FF,(0) ;Queues C and D are Invalid
DSPPAT = 01,02 ;Printer A to Queue A,B to B, etc.
SLAVE3.GEN ;TurboDOS operating system Slave 3 GENeration file
LST300 ;Serial driver default 300 baud
;NETSVC required because of no local printer
SLAVE3.PAR ;TurboDOS operating system Slave 3 PARameter file (Example 1)
PTRAST = 80,(0000) ;Printer A is printer A on R-node #0
81,(0000) ;Printer B is printer B on R-node #0
01,LSTDRA ;Printer C is a Local printer
0FF,(0000) ;Printer D is Invalid
QUEAST = 80,(0) ;Queue A is Queue A on R-node #0
81,(0) ;Queue B is Queue B on R-node #0
0FF,(0),OFF,(0) ;Queues C and D are Invalid
DSPPAT = 01,02 ;Printer A to Queue A, B to B
;No baud rate specified, so it goes to default
SLAVE3.PAR ;TurboDOS operating system Slave 3 PARameter file (Example 2)
PTRAST +6 = 01,LSTDRA,0FF,(0) ;Offset of 6 bytes for first 2 printers A and B
;Printers A and B default to the server PTRAST
QUEAST +6 = 0FF,(0) ;6-byte offset for the 2 system printers off
;the server.
0FF,(0) ;Queues C and D are Invalid
DSPPAT = 01,02 ;Queue A to Queue A, B to B
SLAVE4.PAR ;TurboDOS operating system Slave 4 PARameter file
This satellite does not require any printer drivers in the SLAVE4.GEN file. In
the SLAVE4.PAR file, it will require no printer or queue assignment. This
satellite defaults to the server, but a sample PAR file is shown below to
illustrate the defaults.
PTRAST = 80,(0),81,(0) ;Defaults for system printers
82,(0),83,(0)
QUEAST = 80,0),81,(0) ;Defaults Queues for system printers
82,(0),83,(0)
Figure 3. Remote printer networking
EOF
- Details
- Hits: 5355
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
- Details
- Hits: 5476
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
- Details
- Hits: 5615
Don Maslin's files archive
- Details
- Hits: 6528
- You are here:
-
Home
-
Roche Pages
-
Articles
- Archive