reisert@ricks.enet.dec.com (Jim Reisert) (01/17/91)
In article <20354@yunexus.YorkU.CA>, rreiner@yunexus.YorkU.CA (Richard Reiner) writes... >When I run communications software in DESQview 386 2.31 with text >screen virtualization turned on, screen updates are very jerky (lines >are written in increments). I cured this problem by using TAME with my DESQview tasks. TAME gives away the CPU if the active task is just waiting for keyboard input. This gives more time to active tasks. TAME250 can be downloaded from SIMTEL20. - Jim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The opinions expressed here in no way represent the views of Digital Equipment Corporation." James J. Reisert Internet: reisert@ricks.enet.dec.com Digital Equipment Corp. UUCP: ...decwrl!ricks.enet!reisert 77 Reed Road Hudson, MA 01749-2895
rreiner@yunexus.YorkU.CA (Richard Reiner) (01/17/91)
reisert@ricks.enet.dec.com (Jim Reisert) writes: > rreiner@yunexus.YorkU.CA (Richard Reiner) writes... >>When I run communications software in DESQview 386 2.31 with text >>screen virtualization turned on, screen updates are very jerky (lines >>are written in increments). >I cured this problem by using TAME with my DESQview tasks. TAME gives away >the CPU if the active task is just waiting for keyboard input. This gives >more time to active tasks. TAME250 can be downloaded from SIMTEL20. That must have been a different problem -- I get this behaviour even if the comms program in question is the *only* task running on the system. --richard
rreiner@yunexus.YorkU.CA (Richard Reiner) (01/20/91)
w8sdz@vela.acs.oakland.edu (Keith Petersen) writes: >>When I run communications software in DESQview 386 2.31 with text >>screen virtualization turned on, screen updates are very jerky (lines >>are written in increments). >This has something to do with the task switching in DESQview. I've >found the simple solution is to run the DESQview "MS" (memory status) >program in one window. >I use MS-Kermit which has an excellent VT102 emulator and is also >DESQview aware - which means it gives up time slices to other tasks I was encountering this problem with MS-Kermit. I had to use screen virualization because of a Kermit bug: it apparently violates DESQview-awareness and writes data directly into the physical frame buffer when executing the vt200 insert-character escape sequence in the vt320 emulator, producing corrupted screen displays if running without virtualization, but correct ones if running with it. The best workaround I've found is to tell my host I'm using a vt100. I can then turn the virtualization off. I have reported this bug to the Kermit people at Columbia, but have not yet received any response. --richard