🚀 go-pugleaf

In article <1990Dec11.032154.18383@dms3b1.uucp> dave@dms3b1.UUCP (Dave Hanna) writes:
>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.

DESQview does disable interrupts during a task switch - it HAS to.
I have a process control system written under DESQview (boy was that
a mistake!) that uses serial I/O. Serial I/O is limited to 9600 baud
on a 386/20. After that, I start loosing data, get overrun errors, etc.
Generally bad news. This is not in real mode, however, but in protected mode
under QEMM. I would suspect, if anything, for things to work a little better
in real modes (QEMM isn't handling interrupts at that point).

Hope this helps ....
Steve


-- 
----------------------------------------------------------------------------
steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick
Flames, grammar errors, spelling errrors >/dev/nul
The Asylum OS/2 BBS - (408)263-8017 IFNA 1:143/105.0