Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!evax!utacfd!letni!dms3b1!dave From: dave@dms3b1.uucp (Dave Hanna) Newsgroups: comp.os.msdos.programmer Subject: Serial input under DesqView Summary: Does anyone know interrupt latency under DesqView Keywords: DesqView interrupts serial Message-ID: <1990Dec11.032154.18383@dms3b1.uucp> Date: 11 Dec 90 03:21:54 GMT Reply-To: dave@dms3b1.UUCP (Dave Hanna) Organization: Infotouch Systems, Inc., Dallas Lines: 40 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 |