SLMYQ@USU.BITNET (04/12/88)
> I was wondering if there was a friendly way for an amiga Process to >Sleep for a period of time (in C). Currently to sleep for say, >1 second I do a > >for(i=0;i<50;i++) > WaitTOF(); > >Is there a better, possibly more precise way of waiting for a period >of time without hogging the CPU. You bet. You can use the Delay() command. Just give it the number of ticks to wait for. This would wait for one second: Delay(50); There are two problems. First, you must be operating on a process, not a task, since it uses the DOS library, so you can only call it from the main program or sub-PROCESSES - not sub-tasks. Second, there have been rumors that using Delay(0) or an equivalent might corrupt the disk (and I believe the rumors are actually true :). You might want to open up the timer.device directly, but the only advantage this would give is you could do something else while it's "ticking" - it's asynchronous. You can use this method within tasks as well as processes, but if you just want a synchronous wait within a task, using WaitTOF() is probably better. >Thanks >-Roger Bryan
haitex@pnet01.cts.com (Wade Bickel) (04/13/88)
SLMYQ@USU.BITNET writes: >> I was wondering if there was a friendly way for an amiga Process to >>Sleep for a period of time (in C). Currently to sleep for say, >>1 second I do a >> >>for(i=0;i<50;i++) >> WaitTOF(); >> >>Is there a better, possibly more precise way of waiting for a period >>of time without hogging the CPU. > > [Deleted explanation of Delay] > >You might want to open up the timer.device directly, but the only advantage >this would give is you could do something else while it's "ticking" - it's >asynchronous. You can use this method within tasks as well as processes, >but if you just want a synchronous wait within a task, using WaitTOF() >is probably better. > >>Thanks >>-Roger > > Bryan Hmm, Does WaitTOF() free the CPU for other tasks? I never use it. If you can arrange to never be drawing into the current displayed bitmap you should never need it, which is what I do. I think the timer device is the way to go. Set up the timer to genrate a software interrupt to restart your task. There are dozens of ways to construct such a setup, depending on your needs and the accuracy of the timing desired. This will be more complicated but will allow much more flexable control of the system. Good Luck, Wade. PS: If Delay() does indeed cause damage to disks if a 0 is passed wouldn't it make sense to either not use it or encapuslate it within a procedure which ensures a non-zero input? UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
doug@eris (Doug Merritt) (04/14/88)
In article <2814@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > Hmm, Does WaitTOF() free the CPU for other tasks? I never use it. Yes. Although FYI WaitBOVP() busy-waits. (This is from Jim Mackraz, who gave a talk recently at BADGE). The overhead mentioned in a previous posting was the loop *around* WaitTOF(): "for(i=0;i<60;i++) WaitTOF();" Granted it's not *too* much, although note that the context switch overhead dwarfs the few instructions that implement the loop. Delay(50) is more to the point. Also more accurate over an extended period of time, if that matters. > If you can arrange to never be drawing into the current displayed bitmap > you should never need it, which is what I do. Jim talked a lot about this. His recommendation for taking advantage of available bandwidth in the vertical retrace was to use copper interrupts to signal your task to wake up near the bottom of the frame. He has some example code that he's polishing, he's giving a talk at Devcon on this, and will make a full release after the talk. It shows what amounts to the "best" way to do double buffering to take maximum advantage of the Amiga's architecture. It also shows all kinds of great stuff about transparently turning Intuition on and off, using fancy copper stuff without destroying the system software, etc. > PS: If Delay() does indeed cause damage to disks if a 0 is passed > wouldn't it make sense to either not use it or encapuslate > it within a procedure which ensures a non-zero input? Sounds good to me! Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
jan@oscvax.UUCP (Jan Sven Trabandt) (04/14/88)
In article <8804120421.AA04436@jade.berkeley.edu> SLMYQ@USU.BITNET writes: > >You might want to open up the timer.device directly, but the only advantage >this would give is you could do something else while it's "ticking" - it's >asynchronous. You can use this method within tasks as well as processes, >but if you just want a synchronous wait within a task, using WaitTOF() >is probably better. > Bryan The timer.device can be used asynchronously [using SendIO() and WaitIO()] OR Synchronously using DoIO(). If anyone's interested, I've got a set of handy-dandy routines for using the timer.device (which I wrote myself) which, among other things, allows you to access and release the timer.device through a "master" time-request and quickly (ie. little overhead) get(rid of) "slave" time-requests which can be used while you haven't released the "master". Essentially it is an extension of the timer.device examples in the RKM which give you greater flexibility (you can use the same port for the "master" and all its "slaves") or simplicity if you like (just one call does a synchronous timer delay). Jan "I'm putting together a library of my handy-dandy routines" Sven. ---------------------------------------------------------------- Happiness is being smart enough to know what not to worry about. Mind like parachute - function only when open! Jan (Jan, from Amsterdam) no-hyphen Sven Trabandt ...!{allegro,ihnp4,decvax,pyramid}!utzoo!oscvax!jan