Re: [PARPORT] custom cabling

From: Nate Jenkins (nate@uniwest.com)
Date: Mon May 12 2003 - 18:33:28 EDT

  • Next message: Jason Majors: "[PARPORT] simple parallel device"

    So as an update and as a request for more assistance . . .

    I have tried to read 8 bits of data using status and control ports. I
    shifted my lower nibble of the desired 8 bits differently than my pin out
    chart listed before. I have changed to model after this:
    http://www.beyondlogic.org/spp/parallel.htm#7

    "No luck". I should clarify by saying "not complete success". However, I
    don't know if the chip is good for this or not either. That may be good
    news or bad news. :)

    I have the status port of PC #2 accepting bit changes from data port of
    PC #1. However, no matter what I do, I cannot change the values of the
    control port of PC #2 from outside of PC #2.

    I am explicitly telling how to get this executable to compile for posterity
    and for those who may not know how. I have attached some source files I
    wrote for this test. To compile the executable, put the 4 attached files in
    a directory. At the console prompt in that directory, type "make", (without
    parenthesis). This while yield the executable "sim.x". To run the program
    at the console, type "./sim.x" plus the number of loops to read the ports.
    It assumes that the kernel has parport and parport_pc. The executable will
    load and unload ppdev.o and its only real purpose is to see and manipulate
    the bits of the respective ports...

    I have two parallel port cards in my PC so I am simulating both PC's on a
    single computer. I have tried several W83787F chip boards and a couple
    others types. I connect them with the cable as described on the link above
    but also here:

    PC PC
     1 - 2 <-
     2 - 1 ->
     3 - 14 ->
     4 - 16 ->
     5 - 17 ->
     6 - 13
     7 - 12
     8 - 10
     9 - 11
    10 - 8
    11 - 9
    12 - 7
    13 - 6
    14 - 3 <-
    15 - 15
    16 - 4 <-
    17 - 5 <-
    18 - 18
    19 - 19
    20 - 20
    21 - 21
    22 - 22
    23 - 23
    24 - 24
    25 - 25

    Note: The arrows above indicate my open collector inverters.
    I am using 5.6 K resisters in front of the transistors to make my open
    collector logic and I know it works, (should sink a couple hundred
    milliamps)

    So I have been able to set my data lines to the values I wish. I can see my
    status bits PC#2 change when I set data bits on PC#1 but not control bits.
    So I am able to probe the open collector logic and it looks correct. When I
    drive pin 2 high on either PC, I see the other side sink low and vice versa.
    However, the software isn't seeing the change. So what I am thinking is
    that the values are being held either by hardware or software despite the
    values changing on the pins. Is this a driver thing? Is it a chip thing?
    Did I miss some driver documentation on toggling the control from output to
    input?

    Thank You,

    Nate Jenkins

    ----- Original Message -----
    From: "Blaise Gassend" <blaise@gassend.com>
    To: "Nate Jenkins" <nate@uniwest.com>
    Cc: <linux-parport@torque.net>; "Gregg C Levine"
    <yodathejediknight@worldnet.att.net>
    Sent: Monday, April 21, 2003 11:10 AM
    Subject: Re: [PARPORT] custom cabling

    > If you are worried about damaging your parallel port, just put a
    > suitable resistor on lines that might both be outputs at the same time.
    > That way, if they both try to drive the line, the resistor will limit
    > the current to a safe value.
    >
    > Blaise
    >
    > Quoted from Nate Jenkins on Mon, Apr 21, 2003 at 10:47:44AM -0700.
    > > Thanks for your input,
    > >
    > > I just found a few extra ISA parallel port cards laying around here.
    Maybe
    > > I'll have to try it on one of those. I didn't want to attempt to
    destroy
    > > the parport on the mother board, for fear I might render the mother
    board
    > > useless. I know, no guts, no glory. If I blow up an ISA card, that
    might
    > > be fun. I'll let you know how it goes when I try. It may be a couple
    of
    > > weeks, depending on how it goes around here.
    > >
    > > Nate
    > >
    > >
    > > ----- Original Message -----
    > > From: "Gregg C Levine" <yodathejediknight@worldnet.att.net>
    > > To: "Nate Jenkins" <nate@uniwest.com>; <linux-parport@torque.net>
    > > Cc: "Blaise Gassend" <blaise@gassend.com>
    > > Sent: Saturday, April 19, 2003 6:01 PM
    > > Subject: Re: [PARPORT] custom cabling
    > >
    > >
    > > > Hello from Gregg C Levine
    > > > I, too, looked at the site. I also have one of the Lap Link Turbo
    cables,
    > > > made by Belkin. It works, under an OS made by the Evil Empire.
    However, to
    > > > get it to work under Linux, using, say, PLIP functions would take an
    act
    > > of
    > > > God, or somebody because it did not work for me, even after filing a
    > > > particular How To note. I think the Beyond Logic data, is
    questionable,
    > > not
    > > > your interpretations of them. How about you, Nate, keep working on it,
    and
    > > > report back?
    > > > Gregg C Levine yodathejediknight@att.net or
    > > > yodathejediknight@worldnet.att.net
    > > > "May the Force be with you!"
    > > > ----- Original Message -----
    > > > From: "Nate Jenkins" <nate@uniwest.com>
    > > > To: <linux-parport@torque.net>
    > > > Cc: "Blaise Gassend" <blaise@gassend.com>
    > > > Sent: Friday, April 18, 2003 12:59 PM
    > > > Subject: Re: [PARPORT] custom cabling
    > > >
    > > >
    > > > > Blaise, et al.
    > > > >
    > > > > I appreciate your input. I have tried to not disregard the fact
    that
    > > some
    > > > > pins are input and others are output. Maybe my source is
    > > questionable...
    > > > >
    > > > > http://www.beyondlogic.org/spp/parallel.htm
    > > > >
    > > > >
    > > > > Hardware Properties
    > > > > .
    > > > > .<some copy snipped>
    > > > > .
    > > > > Pin No (D-Type 25) Pin No (Centronics) SPP Signal Direction
    > > In/out
    > > > > Register Hardware Inverted
    > > > > 1 1 nStrobe In/Out Control Yes
    > > > > 2 2 Data 0 Out Data
    > > > > 3 3 Data 1 Out Data
    > > > > 4 4 Data 2 Out Data
    > > > > 5 5 Data 3 Out Data
    > > > > 6 6 Data 4 Out Data
    > > > > 7 7 Data 5 Out Data
    > > > > 8 8 Data 6 Out Data
    > > > > 9 9 Data 7 Out Data
    > > > > 10 10 nAck In Status
    > > > > 11 11 Busy In Status Yes
    > > > > 12 12 Paper-Out / Paper-End In Status
    > > > > 13 13 Select In Status
    > > > > 14 14 nAuto-Linefeed In/Out Control Yes
    > > > > 15 32 nError / nFault In Status
    > > > > 16 31 nInitialize In/Out Control
    > > > > 17 36 nSelect-Printer / nSelect-In In/Out Control Yes
    > > > > 18 - 25 19-30 Ground Gnd
    > > > >
    > > > > Table 1. Pin Assignments of the D-Type 25 pin Parallel Port
    Connector.
    > > > >
    > > > >
    > > > > Specifically, on nStrobe, I read that it could be used for input or
    > > > output.
    > > > > This is why I thought, it may be fine to connect. Is this not
    correct?
    > > > >
    > > > > I know I have tested with reading and writing to the
    data/status/control
    > > > > ports to see which bits I can use for outputting to the other PC
    using a
    > > > > LapLink cable. I think I double checked my pin assignments before I
    > > > > originally sent my inquiry to the list. Am I off? Where I am not
    > > certain
    > > > > is if I will damage hardware before attempting such a feat.
    > > > >
    > > > > Regarding an 8 bit cable, I have only seen the cable at
    > > http://www.lpt.com
    > > > > for 8 bit transfer. However, they will not even think about
    allowing
    > > > their
    > > > > products to deviate from the world of M$. I have talked to them a
    few
    > > > times
    > > > > about Linux support and they inferred that they cannot as if they
    were
    > > > being
    > > > > watched right then by big brother... I think they have some extra
    > > > circuitry
    > > > > in the cable to buffer and do some crossing over. That is why the
    cable
    > > > is
    > > > > faster and very software dependent...
    > > > >
    > > > >
    > > > > Thank You,
    > > > >
    > > > > Nate Jenkins
    > > > >
    > > > > United Western Technologies
    > > > > Software Engineer
    > > > > http://www.uniwest.com
    > > > >
    > > > > nate@uniwest.com
    > > > > Ph: (509) 544-0720
    > > > > Fx: (509) 544-0868
    > > > >
    > > > >
    > > > > NOTICE: This email may contain confidential or privileged material
    and
    > > > > is intended for use solely by the above-referenced recipient. Any
    > > > > review, copying, printing, disclosure, distribution, or other use
    > > > > by any other person or entity is strictly prohibited. If you
    > > > > are not the named recipient, or believe you have
    > > > > received this email in error, please reply
    > > > > to the sender and delete the copy
    > > > > you received. Thank you.
    > > > >
    > > > >
    > > > > ----- Original Message -----
    > > > > From: "Blaise Gassend" <blaise@gassend.com>
    > > > > To: "Nate Jenkins" <nate@uniwest.com>
    > > > > Cc: <linux-parport@torque.net>
    > > > > Sent: Thursday, April 17, 2003 4:11 PM
    > > > > Subject: Re: [PARPORT] custom cabling
    > > > >
    > > > >
    > > > > > > **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]
    > > > > >
    > > > > > It seems to me like you are disregarding the fact that some pins
    are
    > > > > > inputs and others are outputs. For example, connecting nStrobe to
    > > > > > nStrobe won't work because they are both of the same type.
    > > > > >
    > > > > > I think there are some common designs for 8 bit parallel cables.
    They
    > > > > > connect the data lines to the data lines (on recent parallel ports
    the
    > > > > > data lines are usually bidirectional) and use the unidirectional
    > > signals
    > > > > > for handshaking. I don't have a link to a precise description of
    one
    > > of
    > > > > > these cables, but I expect that a little googling should help. I
    also
    > > > > > expect that the software for these cables is already available.
    > > > > >
    > > > > > Blaise
    > > > > >
    > > > >
    > > > >
    > > > > -- To unsubscribe, send mail to:
    linux-parport-request@torque.net --
    > > > > -- with the single word "unsubscribe" in the body of the
    message. --
    > > > >
    > > >
    > > >
    > >
    > >
    > > -- To unsubscribe, send mail to: linux-parport-request@torque.net --
    > > -- with the single word "unsubscribe" in the body of the message. --
    > >
    >









    -- To unsubscribe, send mail to: linux-parport-request@torque.net --
    -- with the single word "unsubscribe" in the body of the message. --



    This archive was generated by hypermail 2b29 : Mon May 12 2003 - 18:38:21 EDT