Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!caen!news.cs.indiana.edu!noose.ecn.purdue.edu!en.ecn.purdue.edu!stevew From: stevew@en.ecn.purdue.edu (Steven L Wootton) Newsgroups: comp.windows.ms Subject: Comm trouble: Win + DOV unit Message-ID: <1991Apr21.102731.19232@en.ecn.purdue.edu> Date: 21 Apr 91 10:27:31 GMT Sender: stevew@en.ecn.purdue.edu (Steven L Wootton) Organization: Purdue University Engineering Computer Network Lines: 38 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