Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!purdue!haven!sylvester.umd.edu!brett
From: brett@sylvester.umd.edu (Brett S Bourbin)
Newsgroups: comp.sys.atari.8bit
Subject: Re: DLI's and other hardware
Message-ID: <3067@haven.umd.edu>
Date: 23 Jan 89 20:59:53 GMT
References: <34962@bbn.COM>
Sender: news@haven.umd.edu
Reply-To: brett@sylvester.umd.edu (Brett S Bourbin)
Organization: University of Maryland, College Park
Lines: 34

In article <34962@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>The thing I neglected to mention was what turned out to be the problem:  I was
>using a timer interrupt to track a trakball/mouse input.  The timer interrupt
>frequency was quite high, interrupting several times per display interval. 
>(I originally tried to use the VBI to track the trakball, but found that it
>was much too slow.  Even moderate speed in moving the ball would cause it
>to overrun.)

In my old days I wrote a handler to keep up with a mouse as an input device
and I had the same problems at first.  The VBI can not keep up with such a
device.  My solution was to track it during the VBI and selected DLI's.

I think I did it every four or so lines and then also during the VBI and
got a very acceptable responce.  You might want to try that.

Also, when working with DLI's, it is always good to split them over the
vertical length of the screen and handle them in slices.  Since there is
very little time during the DLI, (I think it was about 14 color-clocks for
horizontal blank) splitting up the tasks into small chunks helps eminiate
flickering.

Remember that there is only one DLI vector, so it has to be reloaded after 
each DLI slice.




--Brett S Bourbin
 __  __   _  __  _  Instructional Computing Programs -- Univ of Maryland
|  ||  | / ||  || \
|  ||  ||  ||  ||  |  INTERNET: brett@SYLVESTER.UMD.EDU
|  ||  ||  ||  ||  |            bbourbin@UMD5.UMD.EDU
 \_||_/ |__||__||__|       BIX: brettb
    College Park        BITNET: bbourbin@UMDD