Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker!ira.uka.de!fauern!tumuc!lan!rommel From: rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) Newsgroups: comp.windows.ms Subject: Re: Disable Windows handling of com port in 386 mode? Message-ID: <4275@tuminfo1.lan.informatik.tu-muenchen.dbp.de> Date: 4 Sep 90 16:25:27 GMT References: <4246@tuminfo1.lan.informatik.tu-muenchen.dbp.de> Sender: news@lan.informatik.tu-muenchen.dbp.de Reply-To: rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) Organization: Inst. fuer Informatik, TU Muenchen, W. Germany Lines: 28 In article jonathan@jspc.wimsey.bc.ca (Jonathan Story) writes: > I also have a 16550A chip. In win.ini, I commented out the "com1" and >"com2" lines (although this might not be necessary). Then, in the file >system.ini I commented the line "comm.drv=comm.drv". As a result, uucp >transfers work at very close to the same speed as under plain DOS, >although I have had problems with sustained high-speed zmodem reception. This does not work. With no comm.drv= line, Windows looks for a default file name, which is comm.drv, so it is loaded anyway. When I also rename the driver, Windows doesn't come up. > I haven't tried changing the values of COMBoost or the other COM >parameters in system.ini because I don't know what relationship they have >with the (missing) comm.drv. Experimenters and other adventurous fools >are encouraged to post their findings to the net. I found the solution in COMBoostTime. I had to set it to 10 (ms), the default is 2ms. Maybe 5ms works already, I didn't try it. This is for a 16MHz 386sx. The machine I had for testing, did not yet have the 16550, only a 16450 but my driver worked in 386enhanced mode, so I guess it will work with a 16550 too (unless Windows prevents it from writing to the new register needed to enable the FIFO). Kai Uwe Rommel Munich rommel@lan.informatik.tu-muenchen.dbp.de