rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (09/02/90)
I have a problem with '386 mode of windows 3.0. For its virtualization of the PC's resources, Windows handles the hardware interrupts of the serial ports itself. Because Windows 3.0 does not support the 16550 chip, I wrote a DOS device driver which uses its advanced capabilities and creates a new character device for DOS to access the 16550 port. This device can be accessed from my Windows app with open(), close() , read() and write() without problems in real or standard mode and I can transfer data at 19200 baud with very good performance and no data lost. But under 386 mode, the driver does not receive any hardware interrrupt (although it hooked up the vector) from the serial port (either COM1 or COM2) for incoming characters. How can I force Windows 3.0 in 386 mode not to handle serial port interrupts or, more precisely, deliver them to the address where the vector pointed to before Windows was started (to the DOS device driver)? The COMx port handling of Windows 3.0 seems to be highly configurable. But can it be disabled (for one port, that one that is not used by the mouse)? Or did I oversee something? Thanks for any ideas, Kai Uwe Rommel -- /* Kai Uwe Rommel * Munich * rommel@lan.informatik.tu-muenchen.dbp.de */
jonathan@jspc.wimsey.bc.ca (Jonathan Story) (09/03/90)
In article <4246@tuminfo1.lan.informatik.tu-muenchen.dbp.de> rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) writes: > I have a problem with '386 mode of windows 3.0. For its virtualization > of the PC's resources, Windows handles the hardware interrupts of the > serial ports itself. > Because Windows 3.0 does not support the 16550 chip, I wrote a DOS > device driver which uses its advanced capabilities and creates a new > character device for DOS to access the 16550 port. > [....] > But under 386 mode, the driver does not receive any hardware interrrupt > How can I force Windows 3.0 in 386 mode not to handle serial port > interrupts [....] 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. 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. (As an aside from a former Desqview user: there are only two things about Windows which really bother me. One is that I can't quickly switch from one DOS session to another, but have to return to windows, select the next DOS icon, etc. The other peeve is that if I have to terminate a DOS session, Windows doesn't have the decency, unlike Desqview, to close any files that are still open. Maybe in 3.1....)
rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (09/04/90)
In article <fa2/1d63@jspc.wimsey.bc.ca> 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