[Linux-parport] Connecting 2 PCs directly over an "8-wire Fast

Robert Heller heller at deepsoft.com
Tue Jun 29 09:07:35 EDT 2004 

  Daniel Tahin <daniel.t at a1.net>,
  In a message on Tue, 29 Jun 2004 13:07:35 +0200, wrote :

DT> Thank you for your detailed description!
DT> 
DT> If I correct understand you, the paralell port can function only in one 
DT> direction with the maximum bandwidth. From PC to device. But I found a 
DT> documentation, that describes the ECP mode of paralell port. In this 
DT> case the port can function in both direction (the device can send data 
DT> to PC as well). Put the documentation to the web site.
DT> I would like to use the port in ECP mode, and this means, the PC, that 
DT> receives the data, should reverse the direction of the port (to input).
DT> I seen in a Linux source, that there is a way to control each of the 
DT> lines of a port.

The data bits are bi-directional on modern PC parallel ports.  The
problem is that the *hardware* handshaking logic is not symmetrical.  It
could very well be that a true *slave* device can send data to a PC at
a reasonably high rate, but this is not the case for two PCs wired
back-to-back.

DT> Or is it not so easy:-))?

For the case of two PCs it is not easy.  "PC<=>PC" is not the same as
"PC<=>device".  The documentation you have seen most likely relates to
"PC<=>device", not "PC<=>PC".  The parallel port, unlike, for example
the RS232 port, is NOT a fully symmetrical I/O device.

DT> 
DT> Thank you for your answer, and patience.
DT> 
DT> 
DT> 
DT> 
DT> Robert Heller <heller at deepsoft.com> schrieb:
DT> 
DT>  >
DT>  >
DT>  > In message <20040628203552.A11569 at pc199.ben.tuwien.ac.at>, Daniel Tahin
DT>  > writes:
DT>  > >Thank you for the rash answer:-))
DT>  > >
DT>  > >No, of course not. Sorry I forgat to mention, that I don't need a really
DT>  > bi-di
DT>  > >rectional communication. What I need is to set PC A in output-mode 
DT> and PC B
DT>  > to
DT>  > > input-mode, and do a transfer from A to B (like sending data to an 
DT> external
DT>  > h
DT>  > >arddisk or printer, that you said). Or is it basically impossible to
DT>  > "simulate
DT>  > >" PC B as an paralell external device?
DT>  >
DT>  > The parallel ports on PC are *physically* wired as 'masters'.  All PC
DT>  > parallel ports are wired that way.  Just like the parallel ports on
DT>  > printers are wired as 'slaves'.  Esentually, what you really do want *is*
DT>  > bi-directional communication in a sense, just that it is output from one
DT>  > PC and input from the other.
DT>  >
DT>  > When I said that "The parallel port is a master-slave type of interface
DT>  > -- it is NOT a symetrical bi-directional device.", I was refering to how
DT>  > the control pins on the port are *wired*.  The *handshaking* pins on a PC
DT>  > are wired in the opposite sense from the *handshaking* pins on a typical
DT>  > 'slave' device (such as a printer).  The handshaking is not symetrical.
DT>  > You cannot wire one-to-one the handshaking pins of one PC to another --
DT>  > there is not a symetrical cross-wiring, like there is with RS232 ports
DT>  > -- that is there is no 'null-modem' type of wiring for a parallel port
DT>  > cable -- this is not what a Laplink cable is.  It is actually trivial to
DT>  > use a RS232 serial port as a PC-to-PC data transfer.  All you need is a
DT>  > null modem and the lz package installed.  You are just limited to the 
DT> max BPS
DT>  > setting (about 128Kbps with modern COM ports).  RS232 serial ports *are*
DT>  > symetrical bi-directional devices.
DT>  >
DT>  > You can "simulate" a PC as an external parallel device, but you have to
DT>  > 'fake' it.  You cannot use the normal hardware handshaking (which is
DT>  > what allows a 'normal' external parallel device to have higher 
DT> throughput),
DT>  > since it just does not exist in a bi-directional sense.  Note that
DT>  > although the parallel port on modern PC's does allow for bi-directional
DT>  > I/O, the hardware handshaking is not meant to work that way.  The
DT>  > *original* intent of the parallel port was for a printer.  Printers
DT>  > traditionally only sink data (data flows from computer to printer,
DT>  > never the other way around).  The handshaking is meant to allow the
DT>  > printer to say 'I'm ready to get another byte' and for the computer to
DT>  > say 'Here is a byte for you'.  There are soma additional pins for the
DT>  > printer to say 'Help! I have no more paper' or 'Help! I have a
DT>  > malfunction (eg a paper jam, out of ink, etc.)'. And that is it.  It is
DT>  > possible to use one (or more) of these aux error pins as a 'data
DT>  > available' pin, but this is a sort of hack and the I/O port hardware
DT>  > won't be optimized for this use (eg if there is anything like a FIFO,
DT>  > you won't be able to use it and the interupts are handled differently
DT>  > and the data latching works differently, etc.).
DT>  >
DT>  > The input function available with modern PCs does not really give the
DT>  > PC any good way to suck in a continious stream of data in any trivial
DT>  > way.  It can be used to read 8 random bits or something like that (such
DT>  > as a bank of toggle switches or code in a dongle or read back a vendor
DT>  > code from a printer).  Doing much more requires playing all sorts of
DT>  > games, which means you get lots of overhead, which means your
DT>  > 'bandwidth' is limited.
DT>  >
DT>  > >
DT>  > >
DT>  > >
DT>  > >
DT>  > >
DT>  > >Am 2004.06.28 20:15 schrieb(en) Robert Heller:
DT>  > >>
DT>  > >>
DT>  > >>In message <20040628200224.A11439 at pc199.ben.tuwien.ac.at>, Daniel Tahin
DT>  > write
DT>  > >s:
DT>  > >>>Hello Developers!
DT>  > >>>
DT>  > >>>Hopefully I'm here right. I would like to ask you about connecing 
DT> two PCs
DT>  > ov
DT>  > >er
DT>  > >>> a Laplink cable (on the paralell port). But this cable isn't a common
DT>  > Lapli
DT>  > >nk
DT>  > >>> cable that uses only 4 data lines; it uses each (8) data lines.
DT>  > Information
DT>  > > a
DT>  > >>>bout cross connecting the cable I put at 
DT> "http://members.a1.net/e0226781/".
DT>  > >>>It works well under Windows98, with 160-190Kbytes/sec (better than
DT>  > 50Kbytes/
DT>  > >se
DT>  > >>>c with the cable that uses only 4 data lines:-))). I would like to 
DT> ask you,
DT>  >
DT>  > >th
DT>  > >>>at is really the highest transfer rate, that could be reached with 
DT> it? (I
DT>  > as
DT>  > >k
DT>  > >>>you, because I think other paralell devices can do a higher 
DT> transfer-speed
DT>  > w
DT>  > >it
DT>  > >>>h 8 data lines? Or not?)
DT>  > >>>I set the port to ECP, and EPP mode before doing any transfers, but I
DT>  > couldn
DT>  > >'t
DT>  > >>> go over 190Kbytes/sec.
DT>  > >>
DT>  > >>The parallel port is a master-slave type of interface -- it is NOT a
DT>  > >>symetrical bi-directional device.  What happens with ALL of the
DT>  > >>'Laplink' parallel port hacks is some sort of hack to 'fake' a full
DT>  > >>duplex interface -- this by its very nature will reduce you effective
DT>  > >>throughput.  With a 'normal' paralell device (eg printer), there is a
DT>  > >>clear master (computer) and slave (printer) relationship and no need to
DT>  > >>fake anything.
DT>  > >>
DT>  > >>If you really need high-speed bi-directional data transfer, get 
DT> yourself
DT>  > >>a pair of EtherNet NICs (either PCI cards and/or PCMCIA cards,
DT>  > >>depending).  These cards are cheap enough and easy to get (Radio Shack
DT>  > >>sells them).  With a Cat-5 crossover cable you can skip the switch.
DT>  > >>
DT>  > >>It might also be possible to get better thn 190Kbytes/sec. thoughput
DT>  > >>with either FireWire or USB 2.0, but I don't know of any PC-to-PC data
DT>  > >>transfer software using either FireWire or USB 2.0.
DT>  > >>
DT>  > >>>
DT>  > >>>
DT>  > >>>Best regards, and thanx for your answer.
DT>  > >>>Daniel
DT>  > >>>
DT>  > >>>_______________________________________________
DT>  > >>>Linux-parport mailing list
DT>  > >>>Linux-parport at lists.infradead.org
DT>  > >>>http://lists.infradead.org/mailman/listinfo/linux-parport
DT>  > >>                                     \/
DT>  > >>Robert Heller                        ||InterNet:   heller at cs.umass.edu
DT>  > >>http://vis-www.cs.umass.edu/~heller  ||            heller at deepsoft.com
DT>  > >>http://www.deepsoft.com              /\FidoNet:    1:321/153
DT>  > >>
DT>  > >>_______________________________________________
DT>  > >>Linux-parport mailing list
DT>  > >>Linux-parport at lists.infradead.org
DT>  > >>http://lists.infradead.org/mailman/listinfo/linux-parport
DT>  > >>
DT>  > >
DT>  > >_______________________________________________
DT>  > >Linux-parport mailing list
DT>  > >Linux-parport at lists.infradead.org
DT>  > >http://lists.infradead.org/mailman/listinfo/linux-parport
DT>  >                                      \/
DT>  > Robert Heller                        ||InterNet:   heller at cs.umass.edu
DT>  > http://vis-www.cs.umass.edu/~heller  ||            heller at deepsoft.com
DT>  > http://www.deepsoft.com              /\FidoNet:    1:321/153
DT>  >
DT>  > _______________________________________________
DT>  > Linux-parport mailing list
DT>  > Linux-parport at lists.infradead.org
DT>  > http://lists.infradead.org/mailman/listinfo/linux-parport
DT>  >
DT> 
DT> _______________________________________________
DT> Linux-parport mailing list
DT> Linux-parport at lists.infradead.org
DT> http://lists.infradead.org/mailman/listinfo/linux-parport
DT> 
DT>                                                                                                        

                                     \/
Robert Heller                        ||InterNet:   heller at cs.umass.edu
http://vis-www.cs.umass.edu/~heller  ||            heller at deepsoft.com
http://www.deepsoft.com              /\FidoNet:    1:321/153

More information about the Linux-parport mailing list