Hope this isn't too far off-topic, but maybe somebody who has actually
done something homebrew like this can give me some pointers.

I'd like to connect two PC's with EPP ports so they could "talk" to each
other (mono-directional at any instant but reversible -- probably by
passing a "token" back and forth -- and preferably NOT using interrupts
because I'll be doing most of the programming in a high-level language).

This is a one-off job and I'm not looking for elegance or portability;
I just want something to work reliably.

Maximum cable length will be be less than 10 meters, so propagation
time should be minimal.

The programming, itself, doesn't bother me, but it's how to CONNECT
the two parallel ports and how to implement half of the handshake.

Each port has the following pins/functions available:
DIRECTION: DESCRIPTION(#)
Out: Write
InOut: Data (8)
In: Interrupt
In: Wait
Out: DataStrobe
Out: Reset
Out: AdrsStrobe
In: Spare (3)
Ground: (8)

Some connections are fairly obvious:
* 8 data lines to corresponding 8 data lines
* 1 (or a few) ground line(s) to ground line(s)
* DataStrobe outputs to the other's Interrupt inputs
(but I'll DISable the Interrupts).

Possible algorithm:
Assume one PC is started as SeNDeR and the other as ReCeiVeR:
Not sure how RCVR lets SNDR know it is ready to receive,
but RCVR furiously polls the Interrupt input.
SNDR writes the data to its port.
which causes Write to go low
which causes data to be dumped on the output data lines
Not sure what signal from RCVR should be the SNDR's Wait signal.
but when SNDR's Wait is low SNDR's DataStrobe is set high

Something tells me this just isn't going to work!

HELP! Please!
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
NRA Life Member and Rifle, Pistol, & Home Firearm Safety Certified Instructor
Certified Instructor for the Kansas Concealed-Carry Handgun license

Just out of curiosity, is there any reason you can't either buy what you're
asking for off-the-shelf in the form of, e.g., LapLink or else use an
interface that's better suited to the problem to begin with (such as Ethernet
or even those USB "networking" cables)?

The last time I did what you're after here was in the late '80s!

wrote in message ...
Hope this isn't too far off-topic, but maybe somebody who has actually
done something homebrew like this can give me some pointers.

I'd like to connect two PC's with EPP ports so they could "talk" to each
other (mono-directional at any instant but reversible -- probably by
passing a "token" back and forth -- and preferably NOT using interrupts
because I'll be doing most of the programming in a high-level language).

This is a one-off job and I'm not looking for elegance or portability;
I just want something to work reliably.

Maximum cable length will be be less than 10 meters, so propagation
time should be minimal.

The programming, itself, doesn't bother me, but it's how to CONNECT
the two parallel ports and how to implement half of the handshake.

Each port has the following pins/functions available:
DIRECTION: DESCRIPTION(#)
Out: Write
InOut: Data (8)
In: Interrupt
In: Wait
Out: DataStrobe
Out: Reset
Out: AdrsStrobe
In: Spare (3)
Ground: (8)

Some connections are fairly obvious:
* 8 data lines to corresponding 8 data lines
* 1 (or a few) ground line(s) to ground line(s)
* DataStrobe outputs to the other's Interrupt inputs
(but I'll DISable the Interrupts).

Possible algorithm:
Assume one PC is started as SeNDeR and the other as ReCeiVeR:
Not sure how RCVR lets SNDR know it is ready to receive,
but RCVR furiously polls the Interrupt input.
SNDR writes the data to its port.
which causes Write to go low
which causes data to be dumped on the output data lines
Not sure what signal from RCVR should be the SNDR's Wait signal.
but when SNDR's Wait is low SNDR's DataStrobe is set high

Something tells me this just isn't going to work!

I don't suppose you have TCP stacks for the two machines?

Just out of curiosity, is there any reason you can't either buy what you're
asking for off-the-shelf in the form of, e.g., LapLink or else use an
interface that's better suited to the problem to begin with (such as Ethernet
or even those USB "networking" cables)?

An even better solution would be to cobble the destination drive
into the source-drive's PC, do a big XCOPY, and uncobble it.
Unfortunately, in my situation the drives are NOT compatible, either.

Neither do the computers I'm working with have Ethernet or USB.

And there's almost a times-100 ratio in speed; to copy a 1 gig
disk via laplink will take about 24 HOURS vs about 17 MINUTES via
the parallel port.

Besides, there's always the fun of doing it, and that much time
difference should even "pay" for the programming effort.

--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
NRA Life Member and Rifle, Pistol, & Home Firearm Safety Certified Instructor
Certified Instructor for the Kansas Concealed-Carry Handgun license

wrote in message ...
Just out of curiosity, is there any reason you can't either buy what
you're
asking for off-the-shelf in the form of, e.g., LapLink or else use an
interface that's better suited to the problem to begin with (such as
Ethernet
or even those USB "networking" cables)?

An even better solution would be to cobble the destination drive
into the source-drive's PC, do a big XCOPY, and uncobble it.
Unfortunately, in my situation the drives are NOT compatible, either.

Neither do the computers I'm working with have Ethernet or USB.

And there's almost a times-100 ratio in speed; to copy a 1 gig
disk via laplink will take about 24 HOURS vs about 17 MINUTES via
the parallel port.

Besides, there's always the fun of doing it, and that much time
difference should even "pay" for the programming effort.

At least one version of laplink that I remember used the printer port for
connecting.

Along a similar vein, there was talk in comp.os.cpm a couple of weeks ago
about a utility that allowed a dos machine to function as a disk drive for a
cp/m computer via the printer port, perhaps if you look that one up, you can
write a util that allows your machine to do the same. At least it should
help get you started.

In my opinion writing the utils to do it will take more than 24 hours, if
you start the copy now it might just be done before you finish writing the
utils.

Cross opsys transfers are done here the slow way with some form of xmodem or
zmodem at 19.2k, it may take a while but it works just fine while I am
asleep.

"john graesser" wrote in message
...

wrote in message ...
Just out of curiosity, is there any reason you can't either buy what
you're
asking for off-the-shelf in the form of, e.g., LapLink or else use an
interface that's better suited to the problem to begin with (such as
Ethernet
or even those USB "networking" cables)?

An even better solution would be to cobble the destination drive
into the source-drive's PC, do a big XCOPY, and uncobble it.
Unfortunately, in my situation the drives are NOT compatible, either.

Neither do the computers I'm working with have Ethernet or USB.

And there's almost a times-100 ratio in speed; to copy a 1 gig
disk via laplink will take about 24 HOURS vs about 17 MINUTES via
the parallel port.

Besides, there's always the fun of doing it, and that much time
difference should even "pay" for the programming effort.

At least one version of laplink that I remember used the printer port for
connecting.

I got into this a little late, but I'm also assuming in this case that there
are no standard, common media (CD, DVD, etc.) either. Somewhere around here
I still have a file transfer program which came with a null modem cable, but
also gave instructions on how to build a parallel port cable. IIRC, the
data lines were 1-to-1, but some control lines were switched. Would this
data be helpful or do you already have this information?

-NM

wrote in message ...

Neither do the computers I'm working with have Ethernet or USB.

16-bit NICs are $10 apiece, and likely free for the asking from almost any
office's dead PC junk heap.

Besides, there's always the fun of doing it, and that much time
difference should even "pay" for the programming effort.

Seems to me your time would be better spent on things with lasting value.

Linux is free. You can boot directly off the CD image. CD drives are less
than $20 new; likely free for the asking from the dead PC junk heap. Any
pre-built kernel less than 5 years old will work with most NICs, PC
filesystems, and CD drives. Total time and cost can be less than the kW-hrs
you already burned musing about parallel port transfers.

Mike Young wrote:
wrote in message ...

Neither do the computers I'm working with have Ethernet or USB.

16-bit NICs are $10 apiece, and likely free for the asking from almost
any office's dead PC junk heap.

Besides, there's always the fun of doing it, and that much time
difference should even "pay" for the programming effort.

Seems to me your time would be better spent on things with lasting value.

Linux is free. You can boot directly off the CD image. CD drives are
less than $20 new; likely free for the asking from the dead PC junk
heap. Any pre-built kernel less than 5 years old will work with most
NICs, PC filesystems, and CD drives. Total time and cost can be less
than the kW-hrs you already burned musing about parallel port transfers.


I bought two brand new Airlink NICs for $0.99 each from Fry's
Electronics a few months ago. How could I not pass up a bargain like that?

Bob

--
When replying direct, remove the Z in my email address.

Mike Young wrote:

wrote in message ...

Neither do the computers I'm working with have Ethernet or USB.

16-bit NICs are $10 apiece, and likely free for the asking from almost any
office's dead PC junk heap.

Besides, there's always the fun of doing it, and that much time
difference should even "pay" for the programming effort.

Seems to me your time would be better spent on things with lasting value.

Linux is free. You can boot directly off the CD image. CD drives are less
than $20 new; likely free for the asking from the dead PC junk heap. Any
pre-built kernel less than 5 years old will work with most NICs, PC
filesystems, and CD drives. Total time and cost can be less than the
kW-hrs you already burned musing about parallel port transfers.


Simply using google to find a laplink parallel cable is quick, too.

http://www.nullmodem.com/LapLink.htm

Neither do the computers I'm working with have Ethernet or USB.

16-bit NICs are $10 apiece, and likely free for the asking from almost any
office's dead PC junk heap.

And I have several. Have you ever made a NIC work with DOS?
If so, I'd sure love to learn how you did it.


Besides, there's always the fun of doing it, and that much time
difference should even "pay" for the programming effort.

Seems to me your time would be better spent on things with lasting value.
Linux is free....

Linux may be free, but the aftermath of installing Linux would cost
YEARS of effort to "port" the:
801 FORTRAN programs I currently use
225 Pascal programs I currently use
452 DOS .BAT and Norton's DOS .BTM scripts I currently use.

No, converting to Linux is NOT free, especially at my age!

--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
NRA Life Member and Rifle, Pistol, & Home Firearm Safety Certified Instructor
Certified Instructor for the Kansas Concealed-Carry Handgun license