Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: Mouse blanking Message-ID: Date: 8 May 91 23:59:46 GMT References: <9107@crash.cts.com> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 37 In-Reply-To: Frank.Neumann@arbi.informatik.uni-oldenburg.de's message of 8 May 91 10:14:27 GMT In article Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) writes: I'll be glad to hear such suggestions, too.. Well, someone mentioned the Prefs method. I used to use that; it created more problems than it solved under 1.3 - you had to kill it to save prefernces. It should work better under 2.0, but I don't use many things that need the extra sprites. >Matt, what does DMouse do to prevent the sprite dma from being turned >off while a sprite is being displayed? I'm still trying to find a good >solution to that. Although I'm not Matt ;^), I had a short look into dmouse-handler.c: So - before switching off sprite DMA, he waits for the top of the frame - in this time there is for sure NO sprite DMA, so it is a safe way - however, one might think about what would happen if just after the WaitTOF() the scheduler would do his work to give the CPU to another task...but this should happen so rarely.. :} Yeah, I used to do the WaitTOF(). Not only do you have to worry about the scheduler getting the task, but all the interrupts & such get to run before you do. I beat that by having the mouse get turned off by code in the VBLANK interrupt chain. I _still_ get hit by the dma going off at the wrong time every so often. Maybe I should turn off overscan and quit using a crosshair mouse, as they both contribute to it. BTW, my mouse blanker is the only one I know of that uses a keystroke count instead of a timeout. I've come to prefer that.