Path: utzoo!attcan!uunet!maverick.ksu.ksu.edu!kuhub.cc.ukans.edu!markv From: markv@kuhub.cc.ukans.edu Newsgroups: comp.sys.amiga.tech Subject: Re: Wait(scanline) type function?y Message-ID: <26624.273930e3@kuhub.cc.ukans.edu> Date: 8 Nov 90 15:18:11 GMT References: Organization: University of Kansas Academic Computing Services Lines: 54 > Well, time to ask another programming question. > > Is there a nice way using Lattice C to perform a Wait type function > that puts my program to sleep until a given scanline is passed? Not really. WaitBOVP() gets you sooner than WaitTOF() but it busy waits by looping looking at the VPOS register. The only asynchrounus way to wait for a specific line is to use the Copper to cause an interrupt or something similar. But not pretty. > Basically, I am using DrawImage to place a small picture on the > screen and move it around. I am using WaitTOF() to keep things > moving around at 60Hz, but DrawImage can't finish the draw in time > near the top of the screen (flicker, and random color splotches > depending on what bitplane it has gotten through by then). Even if you can get the CPU the instant you past the scan line you are limited in how many bits you can move over time. Its quite a few, but a large multi-bitplane area is a problem. > I want to avoid assembler for now, but I didn't see a way to > utilize the copper for this in C in the RKM. One system call you can try is QBSBlit(). You enqueue a BltNode with a beamsync value. When your somewhere past that line a function you specify gets called and you can do your blit. This of course requires "blitter arithmatic" which can be confusing but faaasssttt. If you can get your blit to be done in ascending mode, you can gain extra time by haveing the blitter "chase" the display DMA or vice versa (which to do depends one which is getting more cycles, you want the slower to chase the faster). This is because display hashing only occurs when the blitter passes the display DMA or vice versa. However, sooner or later you just not going to have enough cycles and double buffering is the only solution, but it has its own problems (like keeping intuition happy). > Any clues? > > Thanks, > Joe Peck > peck@ral.rpi.edu > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~