| 1 |
199 |
simons |
\title{PLIP: The Parallel Line Internet Protocol Device}
|
| 2 |
|
|
|
| 3 |
|
|
\author{ Donald Becker (becker@super.org)}
|
| 4 |
|
|
\affiliation{I.D.A. Supercomputing Research Center, Bowie MD 20715}
|
| 5 |
|
|
|
| 6 |
|
|
%% At some point T. Thorn will probably contribute text,
|
| 7 |
|
|
%% \author{ Tommy Thorn (tthorn@daimi.aau.dk)}
|
| 8 |
|
|
|
| 9 |
|
|
\section{PLIP Introduction}
|
| 10 |
|
|
This document describes the parallel port packet pusher for Net/LGX.
|
| 11 |
|
|
This device interface allows a point-to-point connection between two
|
| 12 |
|
|
parallel ports to appear as a IP network interface.
|
| 13 |
|
|
|
| 14 |
|
|
\chapter{PLIP hardware interconnection}
|
| 15 |
|
|
PLIP uses several different data transfer methods. The first (and the
|
| 16 |
|
|
only one implemented in the early version of the code) uses a standard
|
| 17 |
|
|
printer "null" cable to transfers data four bits at a time using
|
| 18 |
|
|
data bit outputs connected to status bit inputs.
|
| 19 |
|
|
|
| 20 |
|
|
The second data transfer method relies on both machines having
|
| 21 |
|
|
bi-directional parallel ports, rather than output-only ``printer''
|
| 22 |
|
|
ports. This allows byte-wide transfers and avoids reconstructing
|
| 23 |
|
|
nibbles into bytes, leading to much faster transfers.
|
| 24 |
|
|
|
| 25 |
|
|
\section{Parallel Transfer Mode 0 Cable}
|
| 26 |
|
|
The cable for the first transfer mode is a standard
|
| 27 |
|
|
printer "null" cable which transfers data four bits at a time using
|
| 28 |
|
|
data bit outputs of the first port (machine T) connected to the
|
| 29 |
|
|
status bit inputs of the second port (machine R). There are five
|
| 30 |
|
|
status inputs, and they are used as four data inputs and a clock (data
|
| 31 |
|
|
strobe) input, arranged so that the data input bits appear as contiguous
|
| 32 |
|
|
bits with standard status register implementation.
|
| 33 |
|
|
|
| 34 |
|
|
A cable that implements this protocol is available commercially as a
|
| 35 |
|
|
"Null Printer" or "Turbo Laplink" cable. It can be constructed with
|
| 36 |
|
|
two DB-25 male connectors symmetrically connected as follows:
|
| 37 |
|
|
|
| 38 |
|
|
STROBE output 1*
|
| 39 |
|
|
D0->ERROR 2 - 15 15 - 2
|
| 40 |
|
|
D1->SLCT 3 - 13 13 - 3
|
| 41 |
|
|
D2->PAPOUT 4 - 12 12 - 4
|
| 42 |
|
|
D3->ACK 5 - 10 10 - 5
|
| 43 |
|
|
D4->BUSY 6 - 11 11 - 6
|
| 44 |
|
|
D5,D6,D7 are 7*, 8*, 9*
|
| 45 |
|
|
AUTOFD output 14*
|
| 46 |
|
|
INIT output 16*
|
| 47 |
|
|
SLCTIN 17 - 17
|
| 48 |
|
|
extra grounds are 18*,19*,20*,21*,22*,23*,24*
|
| 49 |
|
|
GROUND 25 - 25
|
| 50 |
|
|
* Do not connect these pins on either end
|
| 51 |
|
|
|
| 52 |
|
|
If the cable you are using has a metallic shield it should be
|
| 53 |
|
|
connected to the metallic DB-25 shell at one end only.
|
| 54 |
|
|
|
| 55 |
|
|
\section{Parallel Transfer Mode 1}
|
| 56 |
|
|
The second data transfer method relies on both machines having
|
| 57 |
|
|
bi-directional parallel ports, rather than output-only ``printer''
|
| 58 |
|
|
ports. This allows byte-wide transfers, and avoids reconstructing
|
| 59 |
|
|
nibbles into bytes. This cable should not be used on unidirectional
|
| 60 |
|
|
``printer'' (as opposed to ``parallel'') ports or when the machine
|
| 61 |
|
|
isn't configured for PLIP, as it will result in output driver
|
| 62 |
|
|
conflicts and the (unlikely) possibility of damage.
|
| 63 |
|
|
|
| 64 |
|
|
The cable for this transfer mode should be constructed as follows:
|
| 65 |
|
|
|
| 66 |
|
|
STROBE->BUSY 1 - 11
|
| 67 |
|
|
D0->D0 2 - 2
|
| 68 |
|
|
D1->D1 3 - 3
|
| 69 |
|
|
D2->D2 4 - 4
|
| 70 |
|
|
D3->D3 5 - 5
|
| 71 |
|
|
D4->D4 6 - 6
|
| 72 |
|
|
D5->D5 7 - 7
|
| 73 |
|
|
D6->D6 8 - 8
|
| 74 |
|
|
D7->D7 9 - 9
|
| 75 |
|
|
INIT -> ACK 16 - 10
|
| 76 |
|
|
AUTOFD->PAPOUT 14 - 12
|
| 77 |
|
|
SLCT->SLCTIN 13 - 17
|
| 78 |
|
|
GND->ERROR 18 - 15
|
| 79 |
|
|
extra grounds are 19*,20*,21*,22*,23*,24*
|
| 80 |
|
|
GROUND 25 - 25
|
| 81 |
|
|
* Do not connect these pins on either end
|
| 82 |
|
|
|
| 83 |
|
|
Once again, if the cable you are using has a metallic shield it should
|
| 84 |
|
|
be connected to the metallic DB-25 shell at one end only.
|
| 85 |
|
|
|
| 86 |
|
|
\section{PLIP Mode 0 transfer protocol}
|
| 87 |
|
|
The PLIP driver is compatible with the "Crynwr" parallel port transfer
|
| 88 |
|
|
standard in Mode 0. That standard specifies the following protocol:
|
| 89 |
|
|
|
| 90 |
|
|
send header nibble '8'
|
| 91 |
|
|
count-low octet
|
| 92 |
|
|
count-high octet
|
| 93 |
|
|
... data octets
|
| 94 |
|
|
checksum octet
|
| 95 |
|
|
|
| 96 |
|
|
Each octet is sent as
|
| 97 |
|
|
|
| 98 |
|
|
>4)&0x0F)>
|
| 99 |
|
|
|
| 100 |
|
|
To start a transfer the transmitting machine outputs a nibble 0x08.
|
| 101 |
|
|
The raises the ACK line, triggering an interrupt in the receiving
|
| 102 |
|
|
machine. The receiving machine disables
|
| 103 |
|
|
|
| 104 |
|
|
Restated:
|
| 105 |
|
|
|
| 106 |
|
|
(OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
|
| 107 |
|
|
Send_Byte:
|
| 108 |
|
|
OUT := low nibble, OUT.4 := 1
|
| 109 |
|
|
WAIT FOR IN.4 = 1
|
| 110 |
|
|
OUT := high nibble, OUT.4 := 0
|
| 111 |
|
|
WAIT FOR IN.4 = 0
|
| 112 |
|
|
|
| 113 |
|
|
|
