BSD 4_1_snap development
authorCSRG <csrg@ucbvax.Berkeley.EDU>
Wed, 10 Feb 1982 09:57:49 +0000 (01:57 -0800)
committerCSRG <csrg@ucbvax.Berkeley.EDU>
Wed, 10 Feb 1982 09:57:49 +0000 (01:57 -0800)
Work on file usr/man/man4/bk.4
Work on file usr/man/man4/dh.4
Work on file usr/man/man4/ht.4

Synthesized-from: CSRG/cd1/4.1.snap

usr/man/man4/bk.4 [new file with mode: 0644]
usr/man/man4/dh.4 [new file with mode: 0644]
usr/man/man4/ht.4 [new file with mode: 0644]

diff --git a/usr/man/man4/bk.4 b/usr/man/man4/bk.4
new file mode 100644 (file)
index 0000000..a3a998a
--- /dev/null
@@ -0,0 +1,85 @@
+.TH BK 4 5/11/81
+.UC 4
+.SH NAME
+bk \- line discipline for machine-machine communication
+.SH SYNOPSIS
+pseudo-device bk
+.SH DESCRIPTION
+This line discipline provides a replacement for the old and new
+tty drivers described in
+.IR tty (4)
+when high speed output to
+and especially input from another machine is to be transmitted
+over a asynchronous communications line.  The discipline
+was designed for use by the Berkeley network
+.IR net (1).
+It may be suitable for uploading of data from microprocessors into
+the system.  If you are going to send data over asynchronous
+communications lines at high speed into the system, you must
+use this discipline, as the system otherwise may detect high
+input data rates on terminal lines and disables the lines;
+in any case the processing of such data when normal terminal
+mechanisms are involved saturates the system.
+.PP
+The line discipline is enabled by a sequence:
+.PP
+.nf
+.ft B
+       #include <sgtty.h>
+       int ldisc = NETLDISC, fildes; ...
+       ioctl(fildes, TIOCSETD, &ldisc);
+.fi
+.ft R
+.PP
+A typical application program then reads a sequence of lines from
+the terminal port, checking header and sequencing information on each
+line and acknowledging receipt of each line to the sender, who then
+transmits another line of data.  Typically several hundred bytes of
+data and a smaller amount of control information will be received on
+each handshake.
+.PP
+The old standard teletype discipline can be restored by doing:
+.PP
+.nf
+.ft B
+       ldisc = OTTYDISC;
+       ioctl(fildes, TIOCSETD, &ldisc);
+.fi
+.ft R
+.PP
+While in networked mode, normal teletype output functions take place.
+Thus, if an 8 bit output data path is desired, it is necessary
+to prepare the output line by putting it into RAW mode using
+.IR ioctl (2).
+This must be done
+.B before
+changing the discipline with TIOCSETD, as most
+.IR ioctl (2)
+calls are disabled while in network line-discipline mode.
+.PP
+When in network mode, input processing is very limited to reduce overhead.
+Currently the input path is only 7 bits wide, with newline the only
+recognized character, terminating an input record.
+Each input record must be read and acknowledged before the next input
+is read as the system refuses to accept any new data when there
+is a record in the buffer.  The buffer is limited in length, but the
+system guarantees to always be willing to accept input resulting in
+512 data characters and then the terminating newline.
+.PP
+User level programs should provide sequencing and checksums on the
+information to guarantee accurate data transfer.
+.SH "SEE ALSO"
+tty(4)
+.SH DIAGNOSTICS
+None.
+.SH BUGS
+The Purdue uploading line discipline, which provides 8 bits and uses
+timeout's to terminate uploading should be incorporated into the standard
+system, as it is much more suitable for microprocessor connections.
+.PP
+Inclusion of this line discipline causes the system to use the input
+silos on dz's and dh's.  This causes problems with some terminals, which
+require ^S/^Q handshaking to operate but have inadequate buffering to
+tolerate even a small number of characters transmitted after they send
+a ^S.  In particular this problem existed on early VT100's
+(where, however, an ECO exists to fix this problem.)
diff --git a/usr/man/man4/dh.4 b/usr/man/man4/dh.4
new file mode 100644 (file)
index 0000000..94897d9
--- /dev/null
@@ -0,0 +1,59 @@
+.TH DH 4 4/1/81
+.UC 4
+.SH NAME
+dh, dm \- DH-11/DM-11 communications multiplexer
+.SH SYNOPSIS
+device dh0 at uba0 csr 0160020 vector dhrint dhxint
+.br
+device dm0 at uba0 csr 0170500 vector dmintr
+.SH DESCRIPTION
+A dh-11 provides 16 communication lines; dm-11's may be optionally
+paired with dh-11's to provide modem control for the lines.
+.PP
+Each line attached to the DH-11 communications multiplexer
+behaves as described in
+.IR tty (4).
+Input and output for each line may independently
+be set to run at any of 16 speeds;
+see
+.IR tty (4)
+for the encoding.
+.PP
+Bit
+.I i
+of flags may be specified for a dh to say that a line is not properly
+connected, and that the line should be treated as hard-wired with carrier
+always present.  Thus specifying ``flags 0x0004'' in the specification of dh0
+would cause line ttyh2 to be treated in this way.
+.PP
+If the Berknet line driver
+.IR bk (4)
+is included in the system, then the dh driver will use its input silos
+and poll for input at each clock tick (normally 1/50'th or 1/60'th of a
+second) rather than taking an interrupt on each input character.
+.SH FILES
+/dev/tty[hi][0-9a-f]
+.br
+/dev/ttyd[0-9a-f]
+.SH "SEE ALSO"
+tty(4)
+.SH DIAGNOSTICS
+\fBdh%d: NXM\fR.  No response from UNIBUS on a dma transfer
+within a timeout period.  This is often followed by a UNIBUS adapter
+error.  This occurs most frequently when the UNIBUS is heavily loaded
+and when devices which hog the bus (such as rk07's) are present.
+It is not serious.
+.PP
+\fBdh%d: silo overflow\fR.  The 64 character input silo overflowed
+before it could be serviced.  This can happen if a hard error occurs
+when the CPU is running with elevated priority, as the system will
+then print a message on the console with interrupts disabled.  If the
+Berknet
+.IR net (1)
+is running on a
+.I dh
+line at high speed (e.g. 9600 baud), there is only 1/15th of a second of
+buffering capacity in the silo, and overrun is possible.  This may
+cause a few input characters to be lost to users and a network
+packet is likely to be corrupted, but the network will recover.
+It is not serious.
diff --git a/usr/man/man4/ht.4 b/usr/man/man4/ht.4
new file mode 100644 (file)
index 0000000..fafda94
--- /dev/null
@@ -0,0 +1,41 @@
+.TH HT 4 4/1/81
+.UC 4
+.SH NAME
+ht \- TM-03/TE-16,TU-45,TU-77 MASSBUS magtape interface
+.SH SYNOPSIS
+formatter ht0 at mba? drive ?
+.br
+tape tu0 at ht0 slave 0
+.SH DESCRIPTION
+The tm-03/transport combination provides a standard tape drive
+interface as described in
+.IR mt (4).
+All drives provide both 800 and 1600 bpi; the TE-16 runs at 45 ips,
+the TU-45 at 75 ips, while the TU-77 runs at 125 ips and autoloads tapes.
+.SH "SEE ALSO"
+mt(1), tar(1), tp(1), mtop(4), mt(4), tm(4), ts(4)
+.SH DIAGNOSTICS
+\fBtu%d: no write ring\fR.  An attempt was made to write on the tape drive
+when no write ring was present; this message is written on the terminal of
+the user who tried to access the tape.
+.PP
+\fBtu%d: not online\fR.  An attempt was made to access the tape while it
+was offline; this message is written on the terminal of the user
+who tried to access the tape.
+.PP
+\fBtu%d: can't switch density in mid-tape\fR.  An attempt was made to write
+on a tape at a different density than is already recorded on the tape.
+This message is written on the terminal of the user who tried to switch
+the density.
+.PP
+\fBtu%d: hard error bn%d mbsr=%b er=%b ds=%b\fR.   A tape error occurred
+at block \fIbn\fR; the ht error register and drive status register are
+printed in octal with the bits symbolically decoded.  Any error is
+fatal on non-raw tape; when possible the driver will have retried
+the operation which failed several times before reporting the error.
+.SH BUGS
+If any non-data error is encountered on non-raw tape, it refuses to do anything
+more until closed.
+.PP
+The system should remember which controlling terminal has the tape drive
+open and write error messages to that terminal rather than on the console.