SLMYQ@USU.BITNET (04/15/88)
>>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. > > Hmm, Does WaitTOF() free the CPU for other tasks? I never use it. Well if it doesn't, then Commodore has violates an Amiga standard! Somewhere in one of the Addison-Wesley manuals I think, it said that the VBlank handler keeps a list of tasks waiting with WaitTOF(), and it wakes them up when it gets a VBlank. You might want to try - just write a program to wait 60 seconds this way and try loading a big program. If it goes "gronk, gronk" then it's not hogging the CPU. If it goes "groooonk, groooonk" then it is. :) > 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. It's more powerful, possibly faster, asynchronous, and it can process lots of different requests at the same time. Nice. Except most of us just want to wait 5 seconds while the user finds out why the alien ate him for lunch. :) > 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? That would be great. In fact, if the big compiler compainies wanted to make it easy, they would just add some code into the stub for Delay() to check the input for 0. However, I understand that the stubs are created automatically, and it might not be that easy. Bryan Ford (SLMYQ@USU.BITNET)
toebes@sas.UUCP (John Toebes) (04/17/88)
In article <8804150348.AA26966@jade.berkeley.edu> SLMYQ@USU.BITNET writes: >> 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? > >That would be great. In fact, if the big compiler compainies wanted to make >it easy, they would just add some code into the stub for Delay() to check >the input for 0. However, I understand that the stubs are created >automatically, and it might not be that easy. > > Bryan Ford (SLMYQ@USU.BITNET) Actually, Commodore supplies the stubs in Amiga.LIB. With 4.0, we give you the ability to go straight through to AmigaDos without the stub by loading the registers directly and calling as if you were coding in assembler. Suggestion for a good project for someone starting out: Write a simple program that 'SetFunction's Delay and immediately returns for values of 0 that are passed to it. It certainly would halt a lot of crashes from non-well behaved programs. (No malice intended) On the original subject, I find that INTUITICKS is an excellent way to do processing only when your window is active. You get the 'ticks' at a regular interval which is usually enough to update the screen. They are not for every application but they do fit quite a lot of them. Besides, they are much simpler to use than the timer device. /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/
morgan@brambo.UUCP (Morgan W. Jones) (04/20/88)
In article <8804150348.AA26966@jade.berkeley.edu> SLMYQ@USU.BITNET writes: >That would be great. In fact, if the big compiler compainies wanted to make >it easy, they would just add some code into the stub for Delay() to check >the input for 0. Sorry to keep picking on you Bryan, but the compiler companies shouldn't add code to their stubs to check for anything. 1) It isn't portable. The next guy tries to compile code with a different compiler which doesn't have the checking code and gets a Guru. It would be almost imposible to track down. 2) It isn't upwardly compatible. What if an option is added to a routine that just happens to be nullified by the stub code in an old compiler - you can't access the new functionality until you get a new copy of the compiler (or libraries). > Bryan Ford (SLMYQ@USU.BITNET) -- Morgan Jones - Bramalea Software Inc. morgan@brambo.UUCP ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan "These might not even be my opinions, let alone anyone else's."