I have been using the parport module(s)* to communicate between two PCs for
about 6 months or so now. However, it is too slow. The reason it is slow
is because of at least two reasons....
1. I am controlling the flow of data in software using a strobe/ack
2. I am using a standard LapLink style cable. This gives me access to send
a nibble (4 bits), namely D0-D3.
**Standard LapLink Style Cable Map**
D4 - ~S7
D3 - S6
D2 - S5
D1 - S4
D0 - S3
So I am considering improving my speed by wiring a custom cable. I am
thinking of this scenario to control the flow of data... The data Source PC
will write to the data port, a full byte (8 bits, D7-D0). And then set its
~C0 to high to indicate the data is valid (like a strobe). Then the Dest PC
would send back the same data on its data port so the Source PC could tell
that the Dest PC had received the data. At that point it would drop the ~C0
line to indicate to the Dest PC that the data is no longer valid. Then it
would start all over again.
The diagram is on both ends, so it would be the same for each PC. I wanted
to see if my parallel port circuitry would be damaged if I wired it in the
**Proposed Custom Cable Map**
D7 - ~S7 , (09-11) , [data7-busy]
D6 - S6 , (08-10) , [data6-nAck]
D5 - S5 , (07-12) , [data5-paper]
D4 - S4 , (06-13) , [data4-select]
D3 - S3 , (05-15) , [data3-error]
D2 - ~C3 , (04-17) , [data2-nSelPrntr]
D1 - C2 , (03-16) , [data1-nInit]
D0 - ~C1 , (02-14) , [data0-nAutoLF]
~C0 - ~C0 , (01-01) , [nStrobe-nStrobe]
Will this custom wiring make the magic smoke come out of the circuitry? Is
this a bad idea? Do you have better suggestions for controlled 8 bit
parallel port data transfer from PC to PC?
* - parport module(s) referenced above that I am using in the program are:
parport.o, parport_pc.o with /dev/ppdev using the 2.4.2-2 Linux kernel.
-- To unsubscribe, send mail to: firstname.lastname@example.org --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Thu Apr 17 2003 - 14:22:48 EDT