jokim@jarthur.Claremont.EDU (John H. Kim) (03/27/91)
I am using a 386-33 with an Orchid PDII 1Meg in 800x600x256. I found out that when I'm using my 2400bps MNP5 modem with MNP5 enabled, the modem receives information faster than the Windows Terminal program or WinQVT can scroll it. Even when I drop down to 800x600x16, the scrolling speed is still too slow to keep up with the modem. This is rather frustrating since I timed the display rates with a stopwatch and found no difference between MNP5 enabled and disabled, making MNP5 nearly useless. However, I happened to try Procomm 2.4.3 in a window in 386/enhanced mode and found that if the display fell behind the modem, rather than scroll up methodically line by line as Terminal or WinQVT does, it would jump up as many lines as necessary to catch up. I'd use Procomm expect it seems to gobble up more CPU time and you can't cut and paste from it, which I tend to do a lot of. Soooo, (1) does anyone know how to speed up the scrolling speed of Terminal or WinQVT short of buying a new super-expensive video card, or (2) does anyone know of a Windows communication program that scrolls to keep up with the modem as Procomm in a window does? Maybe whoever it is that writes the code for WinQVT can make an option to get rid of the line-by-line scrolling. -- John H. Kim | (This space to be filled when I jokim@jarthur.claremont.edu | think of something very clever uunet!jarthur!jokim | to use as a disclaimer)
gerardis@cs.mcgill.ca (Tony GERARDIS) (03/28/91)
In article <11404@jarthur.Claremont.EDU> jokim@jarthur.Claremont.EDU (John H. Kim) writes: >I am using a 386-33 with an Orchid PDII 1Meg in 800x600x256. I found >out that when I'm using my 2400bps MNP5 modem with MNP5 enabled, the >modem receives information faster than the Windows Terminal program >or WinQVT can scroll it. Even when I drop down to 800x600x16, the >scrolling speed is still too slow to keep up with the modem. This [stuff deleted] >Soooo, (1) does anyone know how to speed up the scrolling speed of >Terminal or WinQVT short of buying a new super-expensive video card, >or (2) does anyone know of a Windows communication program that scrolls >to keep up with the modem as Procomm in a window does? > >Maybe whoever it is that writes the code for WinQVT can make an option >to get rid of the line-by-line scrolling. Well I'm using Crosstalk 1.1 For windows and still have the same damn problem. I'm also using a 2400 baud modem and this is getting annoying sometimes especially when I log on from home and have huge editting sessions. If the screen ends up falling behind at 2400 bps what would happen at 9600 bps. Does anyone out there use a 9600 bps modem with windows? If so, what are the results, can it handle 9600 baud without errors! Note: regardless of what communications package being used if you have windows and a 9600 bps modem, I would like to know how they are together. Thanks for responses! ////////////////////////////////////////////////////////////////////// gerardis@quiche.cs.mcgill.ca | The sun is the same in a relative way, | but you're older | And shorter of breath and one day | closer to DEATH. -Floyd m m
gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) (03/29/91)
In article <11404@jarthur.Claremont.EDU> jokim@jarthur.Claremont.EDU (John H. Kim) writes: >However, I happened to try Procomm 2.4.3 in a window in 386/enhanced >mode and found that if the display fell behind the modem, rather than >scroll up methodically line by line as Terminal or WinQVT does, it >would jump up as many lines as necessary to catch up. I'd use Procomm Simply a function of a vunderbar program called win386. This will happen no matter what windowed DOS task is up. There is code in the window handler which optimizes the amount of data being written by the amount of data that *can* be written per unit time. Clever. >expect it seems to gobble up more CPU time and you can't cut and paste >from it, which I tend to do a lot of. > >Soooo, (1) does anyone know how to speed up the scrolling speed of >Terminal or WinQVT short of buying a new super-expensive video card, >or (2) does anyone know of a Windows communication program that scrolls >to keep up with the modem as Procomm in a window does? > >Maybe whoever it is that writes the code for WinQVT can make an option >to get rid of the line-by-line scrolling. Software wheel # 3065 if (displayed line takes longer than time to actually read data from serial port) <scip a line or two of display> Wholey drum sticks! Concept! Concept! Concept! Raw message: God how I hate stupid programs. :-) >John H. Kim | (This space to be filled when I >jokim@jarthur.claremont.edu | think of something very clever >uunet!jarthur!jokim | to use as a disclaimer) -- 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
marshall@wind55.seri.gov (Marshall L. Buhl) (03/30/91)
gerardis@cs.mcgill.ca (Tony GERARDIS) writes: >In article <11404@jarthur.Claremont.EDU> jokim@jarthur.Claremont.EDU (John H. Kim) writes: >>I am using a 386-33 with an Orchid PDII 1Meg in 800x600x256. I found >>out that when I'm using my 2400bps MNP5 modem with MNP5 enabled, the >>modem receives information faster than the Windows Terminal program >>or WinQVT can scroll it. Even when I drop down to 800x600x16, the >>scrolling speed is still too slow to keep up with the modem. This >Well I'm using Crosstalk 1.1 For windows and still have the same damn >problem. I'm also using a 2400 baud modem and this is getting annoying >sometimes especially when I log on from home and have huge editting >sessions. If the screen ends up falling behind at 2400 bps what would >happen at 9600 bps. Does anyone out there use a 9600 bps modem with >windows? If so, what are the results, can it handle 9600 baud without >errors! >Note: regardless of what communications package being used if you have > windows and a 9600 bps modem, I would like to know how they are > together. Well, I don't have a 9600 baud modem, but I use CfW on a 19,200 direct line into my Unix box. I also have a 486/33 with a V7 VRAM VGA and I get approximately 2400-4800 baud thruput. It is very slow and frustrating. BTW, I am running 1024x768x16. I have done tests and the problem is VERY card and resolution dependent. I have found the the VRAM VGA is 5 times faster than the Ahead Systems VGA Wizard at 1024x768x16 resolution. There is also a major improvement dropping back to 800x600x16, but I really like all that info on my screen. Since I mostly use Unix for NetNews, this doesn't hinder me too much. When I have to do occasional programming, editing is painful. If the world is going to Windows, we absolutely MUST have an order of magnitute improvement in video speed. I NEED 1024x768x256, I need it now and I need it to be fast. It (monitor and card) MUST be less that $1000. I'll quit whining now... Marshall -- Marshall L. Buhl, Jr. EMAIL: marshall@seri.gov Senior Computer Engineer VOICE: (303)231-1014 Wind Program 1617 Cole Blvd., Golden, CO 80401-3393 Solar Energy Research Institute Solar - safe energy for a healthy future
altman@sbpmt.cs.sunysb.edu (Jeff Altman) (03/30/91)
In article <1991Mar28.041937.13827@cs.mcgill.ca> gerardis@cs.mcgill.ca (Tony GERARDIS) writes: >Well I'm using Crosstalk 1.1 For windows and still have the same damn >problem. I'm also using a 2400 baud modem and this is getting annoying >sometimes especially when I log on from home and have huge editting >sessions. If the screen ends up falling behind at 2400 bps what would >happen at 9600 bps. Does anyone out there use a 9600 bps modem with >windows? If so, what are the results, can it handle 9600 baud without >errors! > >Note: regardless of what communications package being used if you have > windows and a 9600 bps modem, I would like to know how they are > together. > > Thanks for responses! I am running both Crosstalk and WinComm at 19200 using a Courier HST modem. The machine is a 55sx with a 16550 chip and the Comm Driver patched to allow rates higher than 19200. (WinComm supports upto 115k.) I do not lose characters while editing on a Unix host with Emacs. Some characters are lost during high speed Zmodem downloads. They are buffer overruns caused by Windows inablility to service the Uart fast enough. I have ordered but not yet received a Windows Comm Driver which supports the 16550 buffers both for Windows Apps and virtualized 16550s in DOS Shells. I will post to the net when I receive it. -- - Jeff (jaltman@ccmail.sunysb.edu)
psheerin@zanzibar.saigon.com (Peter K. Sheerin) (03/31/91)
altman@sbpmt.cs.sunysb.edu (Jeff Altman) writes: > I have ordered but not yet received a Windows Comm Driver which > supports the 16550 buffers both for Windows Apps and virtualized > 16550s in DOS Shells. > > I will post to the net when I receive it. Better, yet, could you tell us where you found such a beast? That way we don't have to wait....
jokim@jarthur.Claremont.EDU (John H. Kim) (04/02/91)
In article <1991Mar30.055003.10515@sbcs.sunysb.edu> altman@sbpmt.cs.sunysb.edu (Jeff Altman) writes: > >I am running both Crosstalk and WinComm at 19200 using a Courier HST >modem. The machine is a 55sx with a 16550 chip and the Comm Driver >patched to allow rates higher than 19200. (WinComm supports upto >115k.) Pardon my ignorance but since I asked the original question, I'm interested in figuring out this reply. What is a 16550 chip and what does it do to the scrolling speed in a window? -- John H. Kim | (This space to be filled when I jokim@jarthur.claremont.edu | think of something very clever uunet!jarthur!jokim | to use as a disclaimer)
altman@sbpmt.cs.sunysb.edu (Jeff Altman) (04/02/91)
In article <BPTmZ1w163w@zanzibar.saigon.com> psheerin@zanzibar.saigon.com (Peter K. Sheerin) writes: >altman@sbpmt.cs.sunysb.edu (Jeff Altman) writes: > >> I have ordered but not yet received a Windows Comm Driver which >> supports the 16550 buffers both for Windows Apps and virtualized >> 16550s in DOS Shells. >> >> I will post to the net when I receive it. > >Better, yet, could you tell us where you found such a beast? That way >we don't have to wait.... Actually, I already did in an earlier posting approximately 5 weeks ago when I ordered this wonderful product. I have decided not to mention the source again until after I get the damm driver as incentive to the author to get it to me. I have spoken with the author who says the wait is caused by delays in his getting disks manufactured. BTW, I post items to this newsgroup quite regularly. I try and have the attitude that if I have information which is useful and it is within decent reach I will post it. So don't hassle me. Re: a post from a few days ago about a README.TXT file I posted. The README.TXT file was from the Windows 3.0a installation disk. Which is why many of you were unable to find the references I posted. -- - Jeff (jaltman@ccmail.sunysb.edu)