ignacij@orion (Ignacy Misztal) (05/28/91)
I run Kermit under OS/2 using a 9600 baud modem with v.42bis data compression that can be connected up to 38,400 baud. A version of Kermit (VIO) runs at 19,200 baud using almost all CPU time but the newer versions for PM with sliding Windows run marginally (only when display is in 800x600 mode but not in 640x480!). Probably interrupts took most CPU cycles. Several publications recommend exchanging the common, non-buffered SIO cotroller 16450 by a newer chip 16550, with 10 character FIFO. Will OS/2 take advantage of this chip automatically, reducing the number of interrupts, or does the application have to do it? ===================================================================== Ignacy Misztal Internet:ignacij@orion.animal.uiuc.edu University of Illinois Bitnet: ignacy@uiucvmd 1207 W Gregory Dr. Phone: (217) 244-3164 Urbana IL 61801 =====================================================================
d9mikael@dtek.chalmers.se (Mikael Wahlgren) (05/29/91)
In article <ignacij.675448326@orion> ignacij@orion (Ignacy Misztal) writes: >I run Kermit under OS/2 using a 9600 baud modem with v.42bis data compression >that can be connected up to 38,400 baud. A version of Kermit (VIO) runs >recommend exchanging the common, non-buffered SIO cotroller 16450 by a newer >chip 16550, with 10 character FIFO. Will OS/2 take advantage of this chip >automatically, reducing the number of interrupts, or does the application have >to do it? Actually the 16550 UART has two 16 bytes FIFOs. Yes, OS/2 (version 1.2 and 1.3) automaticly take SOME advantage of the FIFO, but to make full use of them, the program must be programmed with the FIFO's in mind. The FIFO support is very easy to use, so I think most modern communication packages support the FIFO. The FIFO helps A LOT! The first thing to do when you use high speed asynchronous communication is to replace all 8250/16450 with a 16550 and get a program using the FIFO. It is VERY easy to patch both COM01.SYS and COM02.SYS (OS/2 version 1.3) to support any speed up to maximum 115 kBaud. Please write a mail if interested. Because of the CPUI-load, I wouldn't recommend this patch to anyone without the 16550 FIFO though. Mikael Wahlgren d9mikael@dtek.chalmers.se
d9mikael@dtek.chalmers.se (Mikael Wahlgren) (05/30/91)
In article <1991May29.142252.22685@mathrt0.math.chalmers.se> d9mikael@dtek.chalmers.se (Mikael Wahlgren) writes: >It is VERY easy to patch both COM01.SYS and COM02.SYS (OS/2 version 1.3) >to support any speed up to maximum 115 kBaud. Please write a mail if >interested. Because of the CPUI-load, I wouldn't recommend this patch >to anyone without the 16550 FIFO though. As I got a lot of mail requesting the patch, I will describe it here. First of all, I don't know about the legal matters implementing this patch, as you have to alter device drivers from IBM, so you take all responsibility yourself. Take a backup copy of your original COM0x.SYS driver before you implement this patch. Use a HEX-editor (like PC-TOOLS) and search in the COM01.SYS or COM02.SYS driver for the HEX-string: 3D 00 4B This string should only appear in one place, and you should replace it by the string: 3D FF FF This is all, and you only have to reboot with the patched COM0x.SYS driver. Note that I promised a little too much before, as the API for setting baud rate only accepts 16 bit baudrates, so the maximum baud rate you can use is 65535 baud (I think the highest useable baudrate is 57600 bauds). Also note that your communication program has to support these speeds. Many programs just won't let you set the baudrate to anything higher than 19200 (or if you are lucky it will accept 38400). M2Zmodem will accept any baud rate up to 57600. I have tested this patch with: IBM OS/2 1.3 SE COM02.SYS (offset 6081 dec) IBM OS/2 1.3 SE COM01.SYS (offset 3905 dec) IBM OS/2 1.3 EE COM01.SYS (offset 3905 dec) IBM OS/2 1.3 EE COM02.SYS (won't work, can't find string?) If you have any further questions please mail me. Mikael Wahlgren d9mikael@dtek.chalmers.se
tholen@uhccux.uhcc.Hawaii.Edu (David Tholen) (05/31/91)
Mikael Wahlgren writes: > As I got a lot of mail requesting the patch, I will describe it here. First > of all, I don't know about the legal matters implementing this patch, as you > have to alter device drivers from IBM, so you take all responsibility yourself Many thanks for this patch, which I will give a try. I would also like to emphasize that IBM will likely not support a system with a patched serial port driver, so be sure to keep the original driver around just in case. The remaining question is this: why doesn't the supplied driver support high baud rates? IBM's hardware will support higher serial port speeds (at least the new Models 90 and 95), and the available communications programs will also support higher speeds, so why was the driver written to support speeds up to only 19200, especially if the patch is as simple as Mr. Wahlgren has indicated? Is there a reliability problem? Can some knowledgable IBMer explain why the higher speed shouldn't be used?
d9mikael@dtek.chalmers.se (Mikael Wahlgren) (06/01/91)
In article <13262@uhccux.uhcc.Hawaii.Edu> tholen@uhccux.uhcc.Hawaii.Edu (David Tholen) writes: >The remaining question is this: why doesn't the supplied driver support >high baud rates? IBM's hardware will support higher serial port speeds >(at least the new Models 90 and 95), and the available communications >programs will also support higher speeds, so why was the driver written to >support speeds up to only 19200, especially if the patch is as simple as >Mr. Wahlgren has indicated? Is there a reliability problem? Can some >knowledgable IBMer explain why the higher speed shouldn't be used? The current COM0x.SYS driver deliberately compares the given baud rate with the maximum 19200 bauds, and jumps out with an error message if the baud rate is too high. This is easy to see in the patch message I sent before (the first character is the OPcode for a compare instruction and the following two characters the value 19200). I think this is a conservative decision by IBM, as SOME of their machines (especially those without 16550 UARTs) won't be able to utilize the high speeds, while most others certainly will manage this, without any problems (I have used the high speeds for quite some time, and doesn{t experience any loss of characters or other symptoms). Mikael Wahlgren d9mikael@dtek.chalmers.se