curtis@se-sd.SanDiego.NCR.COM (Curtis Johnson) (03/02/91)
I'm debugging a problem that occurs in an RS232 communications manager that runs under MSW3.0. This product provides a user interface to a mini-computer via MS Windows. The symptom that we're concerned with is that serial data apparently gets lost somewhere between the serial port and MS Windows. By attaching a serial communications analysis system between the serial port and the cable I can see that the data is going into the PC. Comparing that data with the data displayed on a debug monitor (from some debug code inserted immediately after the call to ReadComm()), I can see that the data coming into the port is different than the data in the buffer returned by ReadComm(). Usually this data is 200 - 300 characters of a login banner message. Sometimes a line or two is missing and sometimes just one or a few characters are missing. We're only seeing these problems on AT's, 386SX/MC and 486MC machines. These symptoms don't appear on 386DX machines. Also, these symptoms don't occur on *every* AT, 386SX/MC and 486MC we've tried. We've only tried PC's manufactured by one company (guess who) and some will work properly and some won't. We haven't found a common factor yet. The serial port is opened by calling OpenComm() with a value of 6144 for the input buffer size and a value of 2176 for the output buffer size. Other smaller values have been tried (1024 and 512 for both) with the same results. The symptoms occur at 19200, 9600, 4800, 2400 and 1200 baud with a 7 bit data size, one stop bit and even parity. The symptoms occur when the PC is connected directly to the serial port of the other computer and when connected through a modem. Any ideas? Sure could use some help on this one. Thanks. -- curtis@se-sd.sandiego.ncr.com (619) 693-5685
epperson@adobe.COM (Mark Epperson) (03/03/91)
You may be interested in an implementation of KERMIT for MSW 3.0 that you can get from either compuserve, microsoft online or, from (january's?) microsoft systems journal
gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) (03/18/91)
In article <4460@se-sd.SanDiego.NCR.COM> curtis@se-sd.SanDiego.NCR.COM (Curtis Johnson) writes: > > >I'm debugging a problem that occurs in an RS232 communications >manager that runs under MSW3.0. This product provides a user >interface to a mini-computer via MS Windows. > >The symptom that we're concerned with is that serial data >apparently gets lost somewhere between the serial port and >MS Windows. > >and 512 for both) with the same results. The symptoms occur at >19200, 9600, 4800, 2400 and 1200 baud with a 7 bit data size, >one stop bit and even parity. The symptoms occur when the PC >is connected directly to the serial port of the other computer >and when connected through a modem. If you are in standard mode use [kernel] int28filter=0 in system.ini to stop int 28 (TSR multiprocess interrupt) from happening. This may help improve comm throughput. Why not try an XON/XOFF protocol? This is handled at the driver level, and is thus impervious (I would hope) to system slowdowns and such. ASSIDE: All ps/2 machines have their comm port on one large logic component on the CPU card. The comm driver also must have special code to map to some of the BIOS locations on ps/2's that hold certain values relevant to comm operations. However, because the comm driver already accounts for this, I an still somewhat cloudy on the relationship you have implied between ps/2's and the comm problems. Please substantiate your claim with more info. > >Any ideas? Sure could use some help on this one. Thanks. > >-- >curtis@se-sd.sandiego.ncr.com >(619) 693-5685 -- Co-Op Scum "Bo doesn't know software" - George Brett "The galaxial hearth steams the sea as the sky blood red embrasses darkness" -John Constantine (HellBlazer) Glenn Steffler