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

Daniel Tahin daniel.t at a1.net
Tue Jun 29 10:28:02 EDT 2004

Ok, I thank you again for your answers. 
It seems I should search other ways:-))

Best regards,
and a lot of thanx again.

Am 2004.06.29 15:07 schrieb(en) Robert Heller:
>  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> 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
>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> Thank you for your answer, and patience.
>DT> Robert Heller <heller at deepsoft.com> schrieb:
>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> Linux-parport mailing list
>DT> Linux-parport at lists.infradead.org
>DT> http://lists.infradead.org/mailman/listinfo/linux-parport
>                                     \/
>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
>Linux-parport mailing list
>Linux-parport at lists.infradead.org

More information about the Linux-parport mailing list