rothberg@polya.Stanford.EDU (Edward Rothberg) (07/27/88)
I've been playing around with time dependent stuff a bit recently, and I can't seem to find the answers to the following questions: 1) It's made clear that Ticks will be updated whether there's time to do any VBL tasks or not. What I'm wondering is, if I put something in the queue with a vblCount of say 60, and in the interval between then and 60 ticks later, it's only able to do VBL tasks 30 times (a gross exageration for example's sake), will my VBL task still be executed after 60 ticks, or will it be executed after 60 + the lost 30? i.e. is decrementing the vblCount of all VBL tasks something that is always done, or only something that's done if there's time? 2) Why use the TickCount() trap when the Global variable Ticks is available? I realize that the underlying philosophy is that it makes future compatibility more likely, but it seems to me that Ticks is a machine state, not a process state, and therefore there doesn't seem to be a great motivation to get rid of it. Is it in Apple's list of "targeted" low-memory globals, globals that Apple says will have to go in the future? Ed Rothberg rothberg@polya.stanford.edu
shane@chianti.cc.umich.edu (Shane Looker) (07/27/88)
In article <3417@polya.Stanford.EDU> rothberg@polya.Stanford.EDU (Edward Rothberg) writes: >I've been playing around with time dependent stuff a bit recently, and I >can't seem to find the answers to the following questions: > >1) It's made clear that Ticks will be updated whether there's time to > do any VBL tasks or not. What I'm wondering is, if I put > something in the queue with a vblCount of say 60, and in > the interval between then and 60 ticks later, it's only able to > do VBL tasks 30 times (a gross exageration for example's sake), > will my VBL task still be executed after 60 ticks, or will it > be executed after 60 + the lost 30? i.e. is decrementing the > vblCount of all VBL tasks something that is always done, or only > something that's done if there's time? How crucial is it that this run every N ticks? If this is all inside an application you are writing, you might want to use the Time Manager. It gives a more accurate way of executing a time dependant task. Make sure you RmvTime on each task you install. I crash when I exit if I don't. My understanding (possibly wrong), is that the Vertical Retrace executes every 60th of a second. Updates of the vblCount fields is done then. VBl Tasks MAY not get run if the CPU is busy with something else right then, which primarily means disk access. The vblCount may not be be updated in the same situation. >2) Why use the TickCount() trap when the Global variable Ticks is available? > Is it in Apple's list of > "targeted" low-memory globals, globals that Apple says will have to > go in the future? Not all languages have access to low memory globals. It is safer anyway. What if Apple decides that the Mac IIe needs to have the globals shifted to another section of memory? Or they would fit better or look more aesthetic if layed out differently? I don't think they will, but TickCount() is the standard way to find out the information. >Ed Rothberg >rothberg@polya.stanford.edu Shane Looker Looker@um.cc.umich.edu
dwb@Apple.COM (David W. Berry) (07/28/88)
In article <3417@polya.Stanford.EDU> rothberg@polya.Stanford.EDU (Edward Rothberg) writes: >2) Why use the TickCount() trap when the Global variable Ticks is available? > I realize that the underlying philosophy is that it makes future > compatibility more likely, but it seems to me that Ticks is a machine > state, not a process state, and therefore there doesn't seem to be > a great motivation to get rid of it. Is it in Apple's list of > "targeted" low-memory globals, globals that Apple says will have to > go in the future? Well, for one thing, A/UX only supports Ticks with pain and suffering to the user, ie. it slows down the whole machine. The default setup is that it isn't supported. This may very well be true of other future Apple OS's that support memory protection. > >Ed Rothberg >rothberg@polya.stanford.edu Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry apple!dwb@sun.com dwb@apple.com 973-5168@408.MaBell
tedj@hpcilzb.HP.COM (Ted Johnson) (07/28/88)
>2) Why use the TickCount() trap when the Global variable Ticks is available?
According to the Mac supplement inside the Aug. '88 issue of Byte,
the "Ticks" global variable won't be increment when running under A/UX.
BUT the TickCount() trap will return the correct value.
-Tedech@poseidon.UUCP (Edward C Horvath) (07/29/88)
> 2) Why use the TickCount() trap when the Global variable Ticks is available? > I realize that the underlying philosophy is that it makes future > compatibility more likely, but it seems to me that Ticks is a machine > state, not a process state... But it's just a copy of a real timer elsewhere. Under A/UX, or any future Mac OS that memory-maps the low-memory globals, the TickCount trap can be supported by checking the hardware clock; but keeping the Ticks global up-to-date is fairly wastful. =Ned Horvath=
oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/07/88)
In article <460@poseidon.UUCP> ech@poseidon.UUCP (Edward C Horvath) writes: >> 2) Why use the TickCount() trap when the Global variable Ticks is available? >But it's just a copy of a real timer elsewhere. Under A/UX, or any future Mac >OS that memory-maps the low-memory globals, the TickCount trap can be >supported by checking the hardware clock; but keeping the Ticks global >up-to-date is fairly wastful. This is a misunderstanding of what is really going on. The Mac _does_ have a hardware timer, but it is implemented using a fairly slow LSI chip, so it is rarely used. On system start-up, the Mac copies time information from the real timer into the global variable Time. From then on, in normal operation, both Time and Ticks are update by an ordinary VBL task, not by the hardware timer. As has been discussed earlier, if the system is busy, it is allowed to skip executing VBL tasks. As a result, the variables Ticks and Time drift. My Menu Clock (shareware $5.00) resynchronizes to the hardware timer once every five minutes or so. The drift is negligable over that period, and the extra CPU it costs to update the clock variables form the slow hardware is also negligable, though I wouldn't want to try doing it 60 times a second. The TickCount() system call usually just returns the value of Ticks. If you have "profiling" on, (See I. M. Vol 1 (the Event Manager) for more deatils about this use of the word profiling.) then a Guided Tour or a macro can slow down or speed up the passing of time, from the point of view of an application program. An interesting bug in most versions of the imagewriter driver is that it assumes that registers A0, and A1 will be preserved across a call to TickCount(), which isn't true if profiling is on. --- David Phillip Oster --When you asked me to live in sin with you Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu