Files posted on USENET by Emmanuel Roche

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

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

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

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

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


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

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

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

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

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

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

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

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

Lawrence Livermore Labs Floating Point & BASIC

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

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


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

Note that retroarchive web site is also mirrored locally.

Falconer Floating Point 8080 code

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

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

Other documents

"DR Logo Reference Manual"

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

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

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

as of December 2006

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

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

As of March 2007

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

Unposted documents provided directly by Roche

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

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

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

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


Contacts

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

MTBASIC Revived

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


Downloads:

 

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

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

(Retyped by Emmanuel ROCHE.)


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

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

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

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

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

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


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

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

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


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

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

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

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

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

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


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

These fall into several groups:

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

Circuit drivers: MCDSPM Master Circuit Driver
SCDD86 Slave Circuit Driver

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

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

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

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

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

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


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

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

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


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

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

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

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

SEND (fifo filename) (message text)

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


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

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


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

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

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

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

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

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

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


EOF
 
TDOSVERS.WS4
------------

- "Versions"
R. Roger Breton
TurboDOS Users' Group Newsletter (TUG'N), Vol.3, No.1, (Month? 1986)
p.1

(Retyped by Emmanuel ROCHE.)


There has been considerable confusion about the various TurboDOS versions:
what the differences are, and whether or not a system should be updated. I
hope, in this very short article, to dispell at least some of the myths that
have arisen.

TurboDOS has been presented in the following versions: 1.00-1.16, 1.20-1.22,
1.30, 1.40-1.43. The last version in each range was the "stable" bebugged
issue of that version (though there may be a series of patches required to fix
the bugs). The current version is 1.43.

Versions 1.00 through 1.16 were the earliest versions of TurboDOS, created and
issued when MP/M did not work and MP/M-II was a dream. As a result, a
proprietary form of file locking, via the $.LOK pseudo- file, was used, and
record locking was not possible.

Versions 1.20 through 1.22 were the first MP/M-compatible versions as regards
file and record locking. They still used extended BDOS functions numbers to
perform TurboDOS-only functions, however, and many of the newer CP/M and MP/M
programs will not work because of this.

Version 1.30 eliminated the BDOS/TurboDOS function conflict, greatly improved
overall performance, and introduced the ability to use 16-bit slaves.

Versions 1.40 and 1.41 introduced 16-bit masters, allowing a significant leap
in performance, and the ability to network with IBM PCs.

Version 1.42 greatly improved the networking capabilities of 1.41, and added
several new functions.

Version 1.43 again improved networking capabilities, added more functions, and
increased the number of files that may be opened from a few hundred to well
over a thousand, allowing increased power with
database programs.

A system should always be upgraded to the most recent version, unless there
has been a considerable investment in software that will not work under the
newer version.


EOF