wrote in message ...
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.

NICs work fine in DOS. At least back with Windows NT (and probably still
2000... possibly not XP anymore though) you could tell it to build you a "DOS
startup disk" which configured most everything you needed to connect to a
NetBEUI-based server (which is still supported in XP, etc.). Many network
cards still come with DOS drivers, and of those that don't, many really cheap
ones are still "NE2000 compatible" and generic drivers can be found. I'm sure
you can Google for the details -- I haven't done this in a number of years,
but very commonly what I used to do was make DOS network startup disks so that
I could connect to a server to pull over a complete hard drive image to set up
the machine using, e.g., Norton Ghost.

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.

There's a very good chance the vast majority of your programs would work under
WINE in Linux. That being said, Linux -- especially with the "popular"
desktops such as KDE -- has gotten to the point of requiring powerful enough
hardware that, if your PCs wouldn't "comfortably" run at least Windows 2000,
you probably shouldn't bother with Linux as you probably won't have a pleasant
experience if you just perform a "default" install of any contemporary
distributions.

---Joel

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.

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.

Wollongong. Beame and Whiteside. To name two.

But that's going backwards. With one foot in the grave already, you need to
keep moving forward, not back. If it runs DOS, it'll run Linux.



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.

It boots off the CD. I know I mentioned that. It's worth mentioning a second
time. And a third: It boots off the CD. No installing, no configuring...
Just boot it, FTP your files, and get on with whatever it is you're trying
to do.


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

Yeah, I know just what you mean. About the age thing, that is. Time's
wasting; best get to it.

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?

I did this back in 1984 when I got a Toshiba portable with the new 3"
floppies, just to get files back and forth.
Later somebody made some commercial products (pdq, lablink, ...)

In short I did:

Server end is a program that reads requeste from other pc, and reads or
writes disk sectors.

Client side has a device driver, disk type, so I now has a D: on that
computer.
I took the memdisk example from the tech books, and rewrote the read and
write sectors to go to other computer.

It works very nice. Only trashed a few disks when doing small
programming mistakes ;-)


Now the interface between the pc's, which first was tested for function
of rx/tx, like Send512Bytes(SomeData)

I had the old parallelport, so I had 5 bits and used 4 for data and 1
for strobe.
I did not use interrupts, as the server just sat there waiting for the
other end to start flipping the strobe bit.

Procedure SendHalfByte(Strobe,B: Byte);
begin
Port():= Strobe+ (B and $0F);
SleepShort;
Port():= (1 xor Strobe)+ (B and $0F);
SleepShort;
end;

Procedure Send1Byte(B: Byte);
begin
SendHalfByte($00,B);
SendHalfByte($80,B shr 4);
end;

The receiver end will do

Function Read1Byte: Byte;
var X: Byte;
begin
repeat until StrobeBit0;
X:=Port() and $0F;
repeat until StrobeBit=0;
Result:=X + (Port() shl 4);
end;

Use Send1Byte and Read1Byte, and you have data. Make some framing like
DataToSend:= LF + MyData + CR
and it is easy to check for correct reception.

I managed to put some 50KBytes between two PC's in 198x, at 8MHz I
guess.

PS: All coding above is out of my head, and was done in assembler back
then.

--
Christen Fihl
OZ1AAB
http://HSPascal.Fihl.net/

Have you thought about using PLIP to do tcpip over your parallel ports?



wrote:
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

kl7r wrote:
Have you thought about using PLIP to do tcpip over your parallel ports?



Check out :

http://www.crynwr.com/ for DOS packet drivers
http://tldp.org/HOWTO/PLIP-9.html for information on DOS/LINUX PLIP
connections