Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!dkuug!diku!bombadil From: bombadil@diku.dk (Kristian Nielsen) Newsgroups: comp.sys.amiga.programmer Subject: Re: Mouse blanking Message-ID: <1991May9.132214.19206@odin.diku.dk> Date: 9 May 91 13:22:14 GMT References: <9107@crash.cts.com> Sender: bombadil@freja.diku.dk Organization: Department of Computer Science, U of Copenhagen Lines: 33 Frank.Neumann@arbi.informatik.uni-oldenburg.de (Frank Neumann) writes: >>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: >> * note, sometimes the sprite gets turned on again, so >> * we re-off it every mouse-ptr-timeout >> */ >> if (doipcmsg(0x81) == 0) { >> WaitTOF(); >> OFF_SPRITE; >> custom.spr[0].dataa=0; /* sprite0 DMA */ >> custom.spr[0].datab=0; /* data register */ >> sproff = 1; >> } >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.. :} The obvious answer to this should be to flank the WaitTOF()/OFF_SPRITE pair with Forbid()/Permit(). Since an input handler is usually (not always, I guess :-)) at the highest priority, this should prevent other tasks from messing up the timing. Remember, a Wait() is supposed to break a Forbid() until the task is woken up again. Now Where did I hear someone muttering about the graphics.library using busy-wait? (I think it was for the blitter, though) - Kristian.