stevew@en.ecn.purdue.edu (Steven L Wootton) (04/21/91)
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
mlord@bwdls58.bnr.ca (Mark Lord) (04/23/91)
In article <1991Apr21.102731.19232@en.ecn.purdue.edu> stevew@en.ecn.purdue.edu (Steven L Wootton) writes:
...
<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 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.
Hmm.. almost as if there were a steady flow of interrupts (or a stuck interrupt)
in/under windows...
Is the baud rate set up correctly in windows? (just fishin').aragorn@csd4.csd.uwm.edu (Steve J White) (04/24/91)
In article <6553@bwdls58.bnr.ca> mlord@bwdls58.bnr.ca (Mark Lord) writes: >In article <1991Apr21.102731.19232@en.ecn.purdue.edu> stevew@en.ecn.purdue.edu (Steven L Wootton) writes: >... >< ><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. > >Hmm.. almost as if there were a steady flow of interrupts (or a stuck interrupt) >in/under windows... > >Is the baud rate set up correctly in windows? (just fishin'). I see two possibilities here. First, and most unlikely, is the trouble Win3 has with sharing IRQ lines. I can give the details of this if you like. Second, and MORE likely, is that the port card you are using is somehow tying up the COM port that you want to use for the DOV unit. It could be that, if this is a cheaper clone port card, it is pulling some aspect f the COM port down. I have had the experience with some of the lesser known brands of port cards that when they are set up for only one COM port, they still have the (dis)ability to tie up the other COM port. I've never quite figured this one out. Let us know what happens. - steve -- "Laugh and the world laughs with you... | All disclaimers apply... snore and you sleep alone." | except my own, of course. - anonymous fortune cookie thingy | *** Steve J. White *** <<< aragorn@csd4.csd.uwm.edu >>>
stevew@en.ecn.purdue.edu (Steven L Wootton) (04/24/91)
If there's a RAQ (Rarely Asked Question) file somewhere, this topic might be worth it. :-) Apparently, Windows gets really unhappy about a couple of serial signals. Or maybe my COM ports do, but only under Windows. In article <11332@uwm.edu> aragorn@csd4.csd.uwm.edu (Steve J White) writes: >In article <6553@bwdls58.bnr.ca> mlord@bwdls58.bnr.ca (Mark Lord) writes: >>In article <1991Apr21.102731.19232@en.ecn.purdue.edu> stevew@en.ecn.purdue.edu (Steven L Wootton) writes: >>... >>< >><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. >> >>Hmm.. almost as if there were a steady flow of interrupts (or a stuck interrupt) >>in/under windows... > >Second, and MORE likely, is that the port card you are using is somehow >tying up the COM port that you want to use for the DOV unit. And this would not affect the port under DOS? Interesting. The DOV unit works well on my machine under DOS, and has for years. I don't *think* the COM ports had much to do with the problem, but they may have. >Let us know what happens. Well, I'm not sure HOW this solved the problem, but it did. According to the Gandalf DOV manual, some systems may have trouble with the SCT and SCR signals coming from the DOV unit. They note that this would be "an exceptional case," and that the system seller would note if these signals would cause a problem. I had tried pretty much everything else, so I flipped the dip switch to suppress SCT and SCR. Terminal (and QVT, and WinKermit) started working perfectly with the DOV, at 9600bps. I have no idea what SCT and SCR are for or what they do, but I'd be interested in hearing about them. Steve Wootton
aragorn@csd4.csd.uwm.edu (Steve J White) (04/24/91)
>the Gandalf DOV manual, some systems may have trouble with the SCT and SCR >signals coming from the DOV unit. They note that this would be "an >exceptional case," and that the system seller would note if these signals >would cause a problem. > >I had tried pretty much everything else, so I flipped the dip switch to >suppress SCT and SCR. Terminal (and QVT, and WinKermit) started working >perfectly with the DOV, at 9600bps. I have no idea what SCT and SCR are >for or what they do, but I'd be interested in hearing about them. > >Steve Wootton I haven't a clue either, and I work a LOT with datacom stuff. Anyone else know without pulling out the old RS-232 manual? - steve -- "Laugh and the world laughs with you... | All disclaimers apply... snore and you sleep alone." | except my own, of course. - anonymous fortune cookie thingy | *** Steve J. White *** <<< aragorn@csd4.csd.uwm.edu >>>
BA.CGB@forsythe.stanford.edu (Clif Baker) (04/25/91)
Folks, This question is a bit on the broad based side... Is there an overall survey of communications packages for Windows 3.0? Specifically one that rates their features, compatibility etc. Of course failing that...what sorts of recommendations from experienced users are there? Thanks! Clif
neves@becks.colorado.edu (NEVES RICHARD K) (04/25/91)
>Is there an overall survey of communications packages for >Windows 3.0? Specifically one that rates their features, >compatibility etc. Take a look at the April 30th PC Magazine. It takes a look at: Unicomm, WinComm, Crosstalk, Dynacomm Rich
user2@cgevs3.cem.msu.edu (Stephen Medlin) (04/25/91)
In article <1991Apr24.170157.28070@morrow.stanford.edu>, BA.CGB@forsythe.stanford.edu (Clif Baker) writes: >Folks, > >This question is a bit on the broad based side... > >Is there an overall survey of communications packages for >Windows 3.0? Specifically one that rates their features, >compatibility etc. > >Of course failing that...what sorts of recommendations from >experienced users are there? > >Thanks! > >Clif Clif, I can tell you about my experience with UniCom...Basically Did Not Like IT!!!!! Now, I have been presently using GT-PowerCom (non-Windows program). I've checked out a lot of Comm programs and I find that I can learn the commands for any type of program, but what I couldn't abide with was weak or missing features. When I saw/bought Unicom, my colleages and I were initially impressed with the layout of the program. It was easy/fairly intuitive to use. But the features were missing. The dialing directory was weak, scripts were adequate, and the transfer rates/ screen updates were slow. I do like the Windows-type of features--DDE, cut/paste, running other programs, etc.; but I think that Win Comm programs have a lot to catch up to GT-PowerComm, Telix, etc. I hope that they do. I would be interested in hearing responses from other people on Win Comm programs. I have heard that CrossTalk is supposed to be good. Any other comments out there? Stephen