🚀 go-pugleaf

Has anyone worked very much with programs under DesqView?  Specifically,
does anyone know what the maximum interrupt latency it imposes is?

Here's my situation:  I have a program that takes serial input at
19200 baud.  By experimentation, I've determined that, with code in
the interrupt service loop, I can spare about an additional 250 microsec.
of delay in the interrupt response before risking occasional overruns.
(This is running on a 25 MHz 386 in real mode.)  

When I load the program up under DesqView, with options set to lock
the program in memory, run in background, and optimize for high-speed
serial operation,  I begin getting overrun errors as soon as I do
anything in DesqView besides just let the program run.  I.e., as soon
as I tap the Alt key to bring up the main menu window, I get a few
errors, and everytime I press a key, I get a few more.

I'm theorizing that DesqView is probably disabling all interrupts
while it switches things around, and that that is taking long enough
to cause problems.  Does anyone have any experience with any similar
situation that would either confirm this or suggest any ways around
the problem?  I thought about writing the serial buffering as
a TSR, and getting it out of DesqView's way, but if it's disabling
CPU interrupts, that wouldn't improve things any.  Does anyone know
if a TSR would have any advantage in interrupt response time over
a program flagged to be locked in memory and run in background?


Any help would be appreciated. 


Possibly relevant information: DesqView Version 2.25, MSDOS 4.01,
code written in TurboC 2.0.



-- 
Dave Hanna,  Infotouch Systems, Inc. |  "Do or do not -- There is no try"
P.O. Box 584, Bedford, TX 76095      |                        - Yoda
(214) 358-4534   (817) 540-1524      |
UUCP:  ...!letni!dms3b1!dave         |