Microsystems, Vol.5, No.10, October 1984
´╗┐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

Local printer configuration
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.

Local printer configuration
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)

Remote printer networking
Figure 3. Remote printer networking

EOF