Move lp.4 to man4. It is not i386 dependent.

Fix ppbus and lpt declaration ('0' forgotten). Add info about retrieving
printer status with 'cat /dev/lpt0'.

1 files changed, 229 insertions, 0 deletions

diff --git a/share/man/man4/lp.4 b/share/man/man4/lp.4
new file mode 100644
index 0000000..f8be0f6
--- /dev/null
+++ b/share/man/man4/lp.4
@@ -0,0 +1,229 @@
+.\" -*- nroff -*-
+.\"
+.\" Copyright (c) 1996 A.R.Gordon, andrew.gordon@net-tel.co.uk
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	Id: man4.i386/lp.4,v 1.9 1999/02/14 12:06:16 nsouch Exp
+.\"	$Id$
+.\"
+.Dd March 4, 1996
+.Os
+.Dt LP 4
+.Sh NAME
+.Nm lp
+.Nd printer port Internet Protocol driver
+.Sh SYNOPSIS
+.Nm ifconfig lp0
+.Ar myaddress hisaddress
+.Op Fl link0
+.Pp
+.Cd "controller ppbus0"
+.Cd "device plip0 at ppbus?"
+.Cd "controller ppc0 at isa? port? net irq 7
+.Sh DESCRIPTION
+The
+.Nm
+driver allows a PC parallel printer port to be used as a
+point-to-point network interface between two similarly configured systems.
+Data is transferred 4 bits at a time, using the printer status lines for
+input: hence there is no requirement for special bidirectional hardware
+and any standard AT-compatible printer port with working interrupts may be used.
+.Pp
+During the boot process, for each
+.Nm plip
+device which is probed and has an interrupt assigned, a corresponding
+.Nm network
+device is created.
+.Pp
+Configuring an
+.Nm lp
+device with
+.Xr ifconfig 8
+causes the corresponding
+.Nm parallel port bus
+to be reserved for PLIP until the network interface is configured 'down'.
+.Pp
+The communication protocol is selected by the
+.Cm link0
+flag:
+.Bl -tag -width Fl
+.It Fl link0
+(default) Use FreeBSD mode (LPIP).  This is the simpler of the two modes
+and therefore slightly more efficient.
+.It Cm link0
+Use Crynwr/Linux compatible mode (CLPIP).  This mode has a simulated ethernet
+packet header, and is easier to interface to other types of equipment.
+.El
+.Pp
+The interface MTU defaults to 1500, but may be set to any value.  Both ends
+of the link must be configured with the same MTU.
+.Ss Cable Connections
+The cable connecting the two parallel ports should be wired as follows:
+.Bd -literal
+	Pin	Pin	Description
+	2	15	Data0 -> ERROR*
+	3	13	Data1 -> SLCT
+	4	12	Data2 -> PE
+	5	10	Data3 -> ACK*
+	6	11	Data4 -> BUSY
+	15	2	ERROR* -> Data0
+	13	3	SLCT   -> Data1
+	12	4	PE     -> Data2
+	10	5	ACK*   -> Data3
+	11	6	BUSY   -> Data4
+	18-25	18-25	Ground
+.Ed
+.Pp
+Cables with this wiring are widely available as 'Laplink' cables, and
+are often coloured yellow.
+.Pp
+The connections are symmetric, and provide 5 lines in each direction (four
+data plus one handshake).  The two modes use the same wiring, but make a
+different choice of which line to use as handshake.
+.Ss FreeBSD LPIP mode
+The signal lines are used as follows:
+.Bl -tag -width dataxxxx(Pinxx)
+.It Em Data0 (Pin 2)
+Data out, bit 0.
+.It Em Data1 (Pin 3)
+Data out, bit 1.
+.It Em Data2 (Pin 4)
+Data out, bit 2.
+.It Em Data3 (Pin 5)
+Handshake out.
+.It Em Data4 (Pin 6)
+Data out, bit 3.
+.It Em ERROR* (pin 15)
+Data in, bit 0.
+.It Em SLCT (pin 13)
+Data in, bit 1.
+.It Em PE (pin 12)
+Data in, bit 2.
+.It Em BUSY (pin 11)
+Data in, bit 3.
+.It Em ACK* (pin 10)
+Handshake in.
+.El
+.Pp
+When idle, all data lines are at zero.  Each byte is signalled in four steps:
+sender writes the 4 most significant bits and raises the handshake line;
+receiver reads the 4 bits and raises its handshake to acknowledge;
+sender places the 4 least significant bits on the data lines and lowers
+the handshake; receiver reads the data and lowers its handshake.
+.Pp
+The packet format has a two-byte header, comprising the fixed values 0x08,
+0x00, immediately followed by the IP header and data.
+.Pp
+The start of a packet is indicated by simply signalling the first byte
+of the header.  The end of the packet is indicated by inverting
+the data lines (ie. writing the ones-complement of the previous nibble
+to be transmitted) without changing the state of the handshake.
+.Pp
+Note that the end-of-packet marker assumes that the handshake signal and
+the data-out bits can be written in a single instruction - otherwise
+certain byte values in the packet data would falsely be interpreted
+as end-of-packet.  This is not a problem for the PC printer port,
+but requires care when implementing this protocol on other equipment.
+
+.Ss Crynwr/Linux CLPIP mode
+The signal lines are used as follows:
+.Bl -tag -width dataxxxx(Pinxx)
+.It Em Data0 (Pin 2)
+Data out, bit 0.
+.It Em Data1 (Pin 3)
+Data out, bit 1.
+.It Em Data2 (Pin 4)
+Data out, bit 2.
+.It Em Data3 (Pin 5)
+Data out, bit 3.
+.It Em Data4 (Pin 6)
+Handshake out.
+.It Em ERROR* (pin 15)
+Data in, bit 0.
+.It Em SLCT (pin 13)
+Data in, bit 1.
+.It Em PE (pin 12)
+Data in, bit 2.
+.It Em ACK* (pin 10)
+Data in, bit 3.
+.It Em BUSY (pin 11)
+Handshake in.
+.El
+.Pp
+When idle, all data lines are at zero.  Each byte is signalled in four steps:
+sender writes the 4 least significant bits and raises the handshake line;
+receiver reads the 4 bits and raises its handshake to acknowledge;
+sender places the 4 most significant bits on the data lines and lowers
+the handshake; receiver reads the data and lowers its handshake.
+[Note that this is the opposite nibble order to LPIP mode].
+.Pp
+Packet format is:
+.Bd -literal
+Length (least significant byte)
+Length (most significant byte)
+12 bytes of supposed MAC addresses (ignored by FreeBSD).
+Fixed byte 0x08
+Fixed byte 0x00
+<IP datagram>
+Checksum byte.
+.Ed
+.Pp
+The length includes the 14 header bytes, but not the length bytes themselves
+nor the checksum byte.
+.Pp
+The checksum is a simple arithmetic sum of all the bytes (again, including
+the header but not checksum or length bytes).  FreeBSD calculates
+outgoing checksums, but does not validate incoming ones.
+.Pp
+The start of packet has to be signalled specially, since the line chosen
+for handshake-in cannot be used to generate an interrupt.  The sender
+writes the value 0x08 to the data lines, and waits for the receiver
+to respond by writing 0x01 to its data lines.  The sender then starts
+signalling the first byte of the packet (the length byte).
+.Pp
+End of packet is deduced from the packet length and is not signalled
+specially (although the data lines are restored to the zero, idle
+state to avoid spuriously indicating the start of the next packet).
+.Sh SEE ALSO
+.Xr ppbus 4 ,
+.Xr ppc 4 ,
+.Xr ifconfig 8 .
+.Sh BUGS
+Busy-waiting loops are used while handshaking bytes, (and worse still when
+waiting for the receiving system to respond to an interrupt for the start
+of a packet).  Hence a fast system talking to a slow one will consume
+excessive amounts of CPU.  This is unavoidable in the case of CLPIP mode
+due to the choice of handshake lines; it could theoretically be improved
+in the case of LPIP mode.
+.Pp
+Polling timeouts are controlled by counting loop iterations rather than
+timers, and so are dependent on CPU speed.  This is somewhat stabilised
+by the need to perform (slow) ISA bus cycles to actually read the port.