🚀 go-pugleaf

So here's the deal:  I have an unusual external modem.  It is a Gandalf
DOV 640, a 9600 bps Data-Over-Voice unit.  Basically, it acts like a
direct connection to a terminal server (it always shows CD).  Works
perfectly with DOS (MS-Kermit, Qmodem, Zcomm, etc.).

Under Windows, though, it doesn't work at all.  I configure my COM2 as
9600, 7E1, no flow control.  When the Gandalf is plugged in, every
communication program that I have tried slows to a crawl (e.g., it takes 15
minutes to draw Terminal's window, and it takes 2 hours after ALT+F,X
for Terminal to exit).  When I unplug the Gandalf, everything goes back to
normal speed.  Plug the Gandalf back in, and everything stops.  The apps
only stop when they are set to talk to the Gandalf's port (i.e., if the DOV
is on COM2, Terminal runs fine pointed at COM1; set Terminal to COM2 and
it stops).

I've tried reducing the available memory to near zero, increasing the
available memory as much as possible, and running under both standard and
real modes.  No difference.  If I run MS-Kermit from Windows, the Gandalf
works just fine.  Return to Windows and fire up Terminal, the system
stops.

I pulled my I/O card and put in a 1200 bps Hayes compatible internal modem,
and all of the Windows apps work.  Put the I/O card back in and attach the
cable to the Gandalf, and everything stops again.

The system is based on a VLSI 286 mb with 2M ram.  The I/O card is a
generic "AT/XT Multi I/O" (2s, 1p, 1g) using SSI 82c450s.  The POST reports
COM1 at 03F8 and COM2 at 02F8.

I've just about given up on using Windows for communication (9600 bps is a
WHOLE lot more comfortable than 1200 bps).  If you have any advice, hints,
suggestions, or pointers to relevant sections of TFM, please let me know.
Post or email, either is appreciated.

Steve Wootton
stevew@ecn.purdue.edu
stevew@pur-ee.uucp
stevew%ecn.purdue.edu@purccvm.bitnet