TDOS4.WS4
---------
- "Good Old TurboDOS"
Ron Yuen
"Journal" of the CP/M User Group (UK), Vol.2, No.7, December 1985, p.108
(Retyped by Emmanuel ROCHE.)
"... about the only operating system with any serious pretensions towards
networking..." (Vol.2, No.5, p.26)
(ROCHE> TurboDOS is a multi-processor version of MP/M-II with CP/NET, the
multi-user, multi-tasking, networking version of CP/M. However, as this
article shows, most persons knew only CP/M 2.2, not MP/M-II. So, they did not
realise, at the time, that a much more sophisticated version of CP/M existed,
which was already networking with CP/NET, long before the IBM PC...)
Networking is a system for linking more-or-less stand-alone micros of more-or-
less varying types with bits of wires, brown paper and string, which is why so
many networks either don't work, are sooooo slow, or fall over every time the
brown paper comes unstruck. However, help is at hand, in fact has been for
ages but not many people have noticed.
TurboDOS is a network operating system which replaces the afore-mentioned
brown paper and string with some fairly decent and robust software which, on
the right hardware, with a good implementation, can be made to do some very
impressive things. Here are some of the main features of a typical TurboDOS
implementation (e.g., HM Systems 'Minstrel' computer):
- Master/Slave configuration closely coupled in a single box on an S-100
Bus.
- Up to 16 printers, 16 queues, and 16 disc drives.
- Indiscriminate mix/match of 8/16-bit masters/slaves.
- Supports 32 CP/M-style 'User Areas'.
- ARCnet interface to PCs and/or Apricots (and others).
- Enables one copy of COM/CMD files to be globally available to all
users.
- Enables almost any CP/M program to be run in a 'semi-multi-user' mode
(explanation later).
- Provides MS-DOS/PC DOS emulation (could do better).
- Can operate as a true multi-user computer, as well as a network.
- Enables files to be shared, exclusive, read-only, or 'permissive' --
normal default mode.
- Large drive/file limits (1 GigaByte).
- Provides for file and record locking at operating system level.
- Provides reasonable security.
- Provides Relocating Assembler (TASM), Linker (TLINK), and Debugger
(TBUG) and other utilities.
It works, it has been around for a while (especially in 8-bit), it is robust,
reliable and predictable. Which is not bad.
Masters and Slaves
------------------
A slave is a computer, either 8- or 16-bit, which sits in a slot on the S-100
Bus and is attached to a terminal (dumb) running at around 9600/19200 baud,
usually. Each user has a slave all to himself.
A slave can do almost anything that a normal PC can do, except it has no
direct access to disc drives or network peripherals like printers (though it
might have a local printer to itself). When a program running on a slave wants
to access a file, the slave passes the request automatically to the master
processor. The master is also a complete 8- or 16-bit computer sitting on the
S-100 Bus, just waiting for slaves to send an interrupt and ask for service
but, in addition, it runs a host of background tasks like print spooling/
despooling simultaneously to all the systems printers (3 of which are on the
master).
Security and privileged users
-----------------------------
TurboDOS has a reasonable level of security built into the operating system.
Anything more elaborate requires additional software.
User Area 31 is reserved for various system files (warm boot programs, etc),
as well as the password and logon file called USERID.SYS. This is a text file
which contains a list of ID's passwords, and start-up data for each user,
including information on whether the user is privileged or not. The format is
simply:
ID, password, User Area {P}, Disc, List of Autoexec programs.
The {P}, if present, indicates that this is a Privileged user. Such users are
allowed to change user areas and manipulate files across user area boundaries.
Non-privileged users are completely restricted to their own user area and
access to global files on area zero. Privileged users can also 'attach' their
slave to the master processor and run programs directly in the master. Some
programs must be so run, for example floppy disc formatting, changing the size
of the cache memory buffers, and so on. Such attachments are logical rather
than physical, and are performed at the keyboard. Non-privileged users who
attempt to perform a reserved task will get an error message telling them
(more or less politely) to p*ss off.
It follows that, if you are a privileged user, you can access the data in area
31 and look at passwords. The security system thus requires that privileged
users treat their logon password seriously.
System utilities
----------------
These fall into several groups:
Control/Security: MASTER, LOGON, LOGOFF
System configuration: BAUD, BAUDVDU, DATE, AUTOLOAD, BOOT
Disc control: FORMAT, DISK, FIXDIR, FIXMAP, LABEL
File maintenance: DELETE, RENAME, COPY, BACKUP, DIR, SET
Memory maintenance: BANK, BUFFERS
Printer control: PRINT, PRINTER, QUEUE
Programming: TASM, TLINK, TBUG, MONITOR, DUMP
Batch processing: DO, BATCH
FIFO files: FIFO, SEND, RECEIVE
The syntax of these commands is much improved over CP/M 2.2 and owes much to
the influence of MS-DOS. Error messages are clear and to the point, and
several of the commands support switches at the command line, e.g.:
COPY 0A:*.COM 12B: ;AEY
will copy all COM files from user area 0 on drive A to user area 12 on drive
B, but it will only copy files due to be archived (switch=A), will erase them
from 0A when copied (switch=E), but will ask for Yes/No confirmation on every
matched filename before doing anything (switch=Y). Other commands allow
similar techniques.
File opening modes
------------------
Typically, TurboDOS will default to opening files in 'permissive' mode, i.e.,
unlimited access by all users on a Read/Write basis, with the proviso that the
first user to signal a write to the FCB maintained in the MASTER will write-
lock the file.
A programmer can, however, simply by setting various FCB bits, open a file in
'exclusive' mode -- no one else can access it (their calling program will,
usually, think that the file does not exist); 'shared mode' -- where explicit
record locking is honoured and multiple writes are allowed; finally, 'read-
only' mode. However, the normal default mode is 'permissive'.
Permissive mode enables unlimited simultaneous read access to the file, but
the first attempt to write to the file will 'write-lock' the file. Only the
user who has already written to the file can continue to do so, attempts by
all other users to write will fail and will, usually, crash a single-user
applications program (SuperCalc is a notable exception).
Shared mode enables simultaneous read/write access, and is the only mode in
which record locking is honoured. This mode is only useful really for
programmers or for those (rare) applications which have record locking
programmed in.
Exclusive mode will only allow one user access whilst the file is open, and
can be useful as part of a scheme for massaging single-user programs into
multi-user file-locked programs.
Running single-user CP/M programs
---------------------------------
I have yet to find the generic CP/M program that will not run under TurboDOS.
Each slave/user would normally be logged in automatically at start-up to a
User Area in which the user would maintain all local files. Files which are
common to all users, e.g., most program files and main databases, etc, are put
in User Area Zero and declared (by the system manager) to be 'global'. This
involves a utility that sets a high bit in the FCB filename, and then enables
anyone from any User Area to access any global file on area zero, simply by
asking for it. A typical session might go like this:
Come in. Switch on. Enter and 'ID code' -- usually your name (nor designed for
security) followed, if required, by your password. Optionally, you can then
enter a text description of the activity to be undertaken. If the system is so
configured, then run a predefined list of programs; otherwise, you are logged
into your predefined User Area on your preassigned disc, and can now do some
work.
If you are privileged, you can change your user area; otherwise, you can only
change logged disc drive. What faces you is something very similar to the CP/M
2.2 system prompt, but with the addition of the user number: 0A, 12B, 3C, etc.
Suppose 4 of you are logged on, 3 as non-privileged, 1 as privileged, and on
areas 1A, 2A, 3A, and 4A (privileged), with all COM/CMD files in 0A and
'global', including WordStar, SuperCalc, dBase, and a multi-user database,
e.g., DataFlex. Additionally, all database files are in 0A.
Users 1 and 2 type WS [CR] and the master processor loads a copy of WS.COM
into the 2 slaves, takes a lot less time with an 8-bit master and 4 users
active than loading from floppies (much quicker with a 16-bit master because
of big cache memory, etc). Users 1 and 2 can then run WS just as though they
were using a stand-alone computer. The file display will reflect each user's
own area only. However, if you have a text file on area zero 'global', then WS
will find it and can edit it from any user area. Meanwhile, in area 3 and 3, 2
users are using dBase on a global file in area zero. Now, dBase is a single-
user package, so it is not possible, for an operating system, to make it
magically multi-user. However, TurboDOS normally defaults to an intelligent
method of handling this situation, by normally opening files in so-called
'permissive' mode.
Suppose that the user in area 3 writes to the file: he will then acquire a
write-lock on the file till it is closed. Attempts by user 4 to overwrite will
fail, and an error will be signaled back to dBase, which will be interpreted
as a 'disc is full' error. dBase in user area 4 will crash back to the 'dot
prompt', whereas the dBase in area 3 will carry on, undeterred. Meanwhile,
users 1 and 2 are busy WordStarring away like mad. Master-to-slave transfer is
quick on the 8-bit systems, *VERY* quick on the 16-bit. The slowest mode is
when loading whole programs into the slave, when it may take from 2-5 seconds
for a typical CP/M application program. Once in the slave, the program runs
almost as it normally would on a stand-alone hard-disc machine. Small chunks
of data move across the bus quickly, so calling up random database records is
very speedy.
Integration to LANs with TurboDOS
---------------------------------
Because TurboDOS is a network operating system, this is no big deal. The
authors of TurboDOS (Software 2000) have chosen ARCnet as the LAN protocol to
use. (ROCHE> Hahem! All the network cards and drivers ever made by Digital
Research used ARCnet, rather than Ethernet...) ARCnet is a token-passing
network, a proprietary package from DataPoint which operates at a raw rate of
2.5 megabits/second in a 'don't care' configuration (bus, star, ring, or a
mix).
To use ARCNET, you need hardware cards, one in each network 'node', and
additional TurboDOS software for each node which is, usually, automatically
run at boot time. Cabling is by standard coaxial, and nodes can be several
thousand metres apart.
My own system (the Minstrel) can currently support ARCnet links to other
Minstrels, to the IBM PC and Apricot families, and I have such links in my own
setup. The network is self-configuring at boot time, assuming that the
hardware is correctly installed and the software is automatically run. It is
so transparent that users need not be aware that they are on a LAN.
My own Apricot, for example, has 2 floppies. These are local, and not
available to other nodes on the LAN. My Minstrel has 4 drives: A, B, C, and E
to the Minstrel slaves, but C, D, E and F to the Apricot. The Apricot simply
thinks that it has got 6 disc drives, and I use them *EXACTLY* as though that
is what it actually has. Similarly, with printers. The Apricot can access the
very powerful print environment of the Minstrel simply by declaring in advance
(or using a boot time default) which spool drive/queue/printer to use. The
best thing of all is that *IT WORKS*. (ROCHE> Hahaha! But it was already
working, several years earlier, under MP/M-II! Those ignorant fans are so
funny!) Transfer times across the ARCnet are pretty quick. Programs load
faster from the network than from a local floppy with several nodes active.
That may not sound impressive but, believe me, it is. You should try some of
the other networks, if you don't believe me.
The TurboDOS print environment
------------------------------
Many micro systems make claims to having 'spooling' facilities. Usually, they
are rather primitive and very limited in scope. Spooling is a very old idea
which stands for Simultaneous Peripheral Operation On Line, which is a very
accurate description of what it is, although the actual simultaneous
peripheral operation is usually thought of as the despooling end of things.
When you 'spool' a file, what you are doing is 'printing' the file under the
control of an applications program (e.g., a word processor), but you are not
printing it directly to a printer. Instead, the operating system is
intercepting every single character that you are printing and storing them
sequentially in a disc file. This is *MUCH* quicker, especially if you have a
hard disc, and lets you 'print' even when the physical printer is busy on
someone else's work.
When you want the hard copy, you have to 'despool', which may require an
explicit instruction or may be automatic when the printer becomes available.
The 'printed file' is then taken off the disc, and sent to the actual printer.
What makes all this interesting and actually useful, though, is that the
despool activity takes place in the background, while you are doing something
else on the systems which may be completely unrelated. For example, you could
spool print from WordStar an enormous document, which would be *MUCH* quicker
than printing it direct and, when finished, you could initiate the despooling
by typing a couple of keys at the keyboard. Then, while the system is
automatically despooling and spending the next hour printing your hard copy,
you are free to run SuperCalc, play games, use the database, or do absolutely
anything else at the terminal. (ROCHE> Note that all this was already
available under CP/M 1.4, with SPOOL...)
TurboDOS, naturally, has spooling facilities. Actually, it has impressively
comprehensive ones, which are controlled by the PRINT, PRINTER, and QUEUE
commands.
PRINT defines which print routing you wish to use, and you can choose direct
printing to a (named) printer, or spool printing to a (named) disc. You can
break down spooling even further, by spooling to up to 16 different (named)
queues on a given disc, which feature can assist with some tricky print
management problems that commonly arise in business. Suppose that, during the
day, you routinely print letters (letterhead), memos (plain paper), program
listings (sprocket hole listing paper), invoices (pre-printed forms), and
address labels. TurboDOS allows you to do this with only one printer without
too much fuss, quite simply. What you do is assign each type of paper a
different print queue, and then spool to the appropriate queue. Sometime
later, when you want to run off the hard copy, you load letterhead and despool
the letters' queue, then load invoice forms and despool the invoices' queue,
and so on. (ROCHE> Well, personally, in practice, I found it easier to have
printers specialised for one given type of paper/form.)
It is a simple matter to take this a stage further and have a number of
printers each assigned to appropriate queues which you 'attach' to the queue
using the PRINTER command.
QUEUE simply queue a file for immediate despooling via which ever PRINT/
PRINTER routing is currently set.
Lots of switches are available to enable files to be deleted/saved/not queued/
auto queued, and so on, as well as methods of stopping, restarting, or
aborting print runs.
The standard Minstrel system, for example, has 3 printer ports on the Master,
so simultaneous despooling by all 3 printers is quite normal.
The mechanics of TurboDOS
-------------------------
There is no such thing as a fixed TurboDOS operating system: each one is
different and made up of different parts.
Basically, you have a large collection of relocatable assembled code (REL
files for 8-bit, O files for 16-bit), each module of which performs a small
task. Here are a few modules which will exist on almost every TurboDOS system:
Disk drivers: DSKHW Winchester driver
DSKHWF 5" & 8" floppy drivers
DST58F 5" & 8" floppy type specifications
Circuit drivers: MCDSPM Master Circuit Driver
SCDD86 Slave Circuit Driver
I/O drivers: CONDRV Console Driver
LSTXON Serial printer driver
LSTPAR Parallel printer driver
etc, etc
The various operating systems are simply collections of these relocatable
modules, all linked into a run-time operating system. Typically, there will be
3 main groups in the operating system:
OSLOAD This is a program which automatically loads the other
operating modules, and is called by a ROM-resident loader.
OSMASTER This is the master operating system, which is loaded by OSLOAD
into the master processor. OSMASTER will be a linked
collection of relocatable modules covering file handling,
memory management, spooling, network activity, disc drivers,
and so on.
OSSLAVE? These are all the various slave systems. Each one can be
different and targeted for a specific hardware slave, and each
will be loaded by OSMASTER into the correct slave for which it
is targeted. For example, you might have 2 16-bit slaves, one
with 128K and another with 256, one with a local printer and
one with a global printer. Additionally, you may have 2 8-bit
slaves, one an old Z80A CPU with nothing special and another a
modern Z80H CPU with bank-switched memory. This will need 4
different slave systems, each of which will be loaded to the
correct slave by OSMASTER at boot time.
The beauty of all this is that, if you change your hardware, e.g., put in a
new disc drive, all you need is a relocatable driver routine for it, and you
can immediately link it into your system. (ROCHE> Yes, this is sooooo simple!
Er... Where do I find the source code of a driver, since the source code of
TurboDOS is not available?...)
Programming under TurboDOS
--------------------------
It is a snap for CP/Mers. The full list of CP/M primitives is available, and
is considerably extended over the basic CP/M 2.2 to include those from MP/M
and CP/M Plus. (ROCHE> Hahaha! Actually, CP/M Plus is a single-user version of
MP/M-II...) These are what TurboDOS calls the 'C-functions', i.e., you put the
number for the function you want in register C, maybe a location in register
D, and CALL 0005H (8-bit) or INT 0E0h (16-bit). Just like CP/M.
There are also a load of similar 'T-functions', which are accessed by a CALL
to 0050h (8-bit) or an INT 0DFh (16-bit). T-functions give you access to the
special network features and other TurboDOS-specific goodies.
Miscellaneous bit & pieces
--------------------------
It has been well said that the heart of CP/M is the disk directory. If you can
handle that as a programmer, you can do most things that are likely to be
necessary, at least as far as applications work with files is concerned. If
anything, TurboDOS is a bit easier than CP/M. For a start, TurboDOS can handle
disks in CP/M format, i.e., with a track or two reserved for the operating
system, followed by a few more tracks for the directory, or it can do its own
thing.
TurboDOS maintains a directory in a special reserved file called $.DIR. This
can be thought of as a 'dump' listing of 32-byte CP/M FCBs. It contains FCBs
that are exactly the same as those from CP/M, complete with extent folds and
all the works. However, the directory is a file, like any other file, and can
be used as such. Because TurboDOS can handle *VERY* big files (up to 1
GigaByte), a special directory search technique is used. (Imagine a serial
search of an optical disk directory with tens of thousands of extents to look
up (even with 16x folding)). Just not on. Instead, TurboDOS performs a hashing
calculation on the filename before a search, and uses this as an index into
the directory. Speeds things up quite a bit. However, this 'hashed' directory
is not CP/M-compatible (ROCHE> ??? MP/M-II and CP/M Plus both use hashed
directories!!!), so it is not appropriate for floppies that might have to be
read by other standard CP/M machines. It is, of course, in the best TurboDOS
Mix'n match tradition, perfectly standard procedure to use linear directories
on the floppy drives, and hashed on the Winchesters, side by side.
TurboDOS maintains another special sort of file, one called a FIFO, that is to
say: a First In, First Out file. FIFOs can be created in RAM or on disc by the
FIFO program, and carry a flag bit in the FCB to identify them. They can be
very useful. For example, a simple electronic mail facility is possible on
standard TurboDOS hardware, which any user can set up. Firstly, you create a
number of FIFO files on disk, each one named for a user of the system, declare
them all to be 'Global', and put them in User Zero. When you want to send a
user a message, you use the SEND program by typing:
SEND (fifo filename) (message text)
and TurboDOS will reply to the effect: 'Message sent to FIFO file'. If you
TYPE (fifo filename), you will display the contents (if any) of the FIFO, and
the contents will then be lost, i.e., they went in first and have come out
first, if you see what I mean. I use mine in such a way that, at log-on time,
the users' FIFO (identified by the ID they typed) is automatically typed onto
their console. FIFOs can be used for much more sophisticated things, like
inter-process messages and queues (ROCHE> Which exist under MP/M-II...), which
can be awkward to do in other ways.
Real Soon Now
-------------
It is rumoured that MS-DOS 3.0 (i.e., networked MS-DOS) has finally arrived.
(ROCHE> MicroSoft was the specialist of "VapourWare", often announcing
products 2 or 3 years before delivering them. Of course, meanwhile, the market
was not buying competing products...) Sometime, maybe someone will write some
good multi-user software for it. When they do, I can run it on my existing
setup under TurboDOS, which already has the MS-DOS 3.x hooks built into it.
Why do people insist on reinventing the wheel?
Conclusions
-----------
You will gather that I like it. You are right. How did I ever live with
single-user micros?
If it is all so easy, why can't other people do it, too?
Well, they can after a fashion. The problem is they keep insisting in belting
square pegs like MS-DOS and PC DOS into round holes that they simply weren't
designed for (were they actually designed at all, I ask myself). The resulting
problems can only be overcome with extra layers of software, hardware, and
difficulty.
They should swallow their pride and use TurboDOS. The authors of TurboDOS
claim that more licenses have been sold for TurboDOS than for all the variants
of Unix put together. It is time the hype machine started to look at the world
a little more objectively.
So, what's it all cost, I hear you ask?
A 2-screen 20MB COMPLETE system can be bought for around L6.25k, and
additional users from about L2.5k per 2 (16-bit 8086 slaves). Makes you think.
EOF