ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (11/09/90)
I don't recall seeing this mentioned anywhere in the 6.0.7 release notes,
but there is another System 7.0 goody that has been included in
System 6.0.7: the Extended Time Manager. This allows you to queue
periodic wakeups at very accurate intervals, with zero drift.
Here's a brief summary of how to use the new facilities.
There is a new extended TMTask record, as follows (note the two
extra fields on the end):
Type
TMTask = { extended Time Manager task }
Record
qLink : QElemPtr; { link to next queue element }
qType : Integer; { Time Manager uses this for indicating its version }
tmAddr : ProcPtr; { pointer to task, if any }
tmCount : LongInt; { unused time, +ve => ms, -ve => us }
tmWakeUp : LongInt; { time of last wakeup }
tmReserved : LongInt { future use }
End {Record};
TMTaskPtr = ^TMTask;
And one new trap, InsXTime, which you call instead of InsTime,
to insert a TMTask into the queue:
Procedure InsXTime
(
TheTask : TMTaskPtr
);
Inline
$205F, { move.l (sp)+, a0 }
$A458; { _InsXTime }
Once you've queued the TMTask with InsXTime, you use the same old
PrimeTime and RmvTime traps to start and remove the timer. The
only difference is that you must set the tmWakeUp field to zero
before the first call to PrimeTime; the Time Manager sets this to
an internal representation of the moment when the timer actually
goes off (though it's not clear whether this happens on the PrimeTime
call, or when the timer goes off), and on the next call to PrimeTime,
it measures the interval you specify from that moment, rather than
from the time of the call.
The end result is that you can do some processing when the timer
goes off, and then requeue the timer, without having to worry
about the time you took to do the processing causing any drift.
For those who were unaware of it, System 6.0.3 introduced a "revised"
Time Manager, which supports microsecond as well as millisecond
timings. You just specify a negative value for the "count" argument
to PrimeTime, and that's taken to be microseconds. The documentation
claims a maximum resolution of 20 microseconds.
If you're wondering how I found out about the new Time Manager,
I was mucking about with the Gestalt call, trying out all the
selectors, and was surprised to find the "tmgr" (Time Manager version)
selector returning a value of 3 instead of 2. I typed in the
"TimeMgrInfo" routine out of an interim Inside Mac Vol VI
I had--this routine makes calls to the Time Manager to determine
its version and what maximum interval it supports--and sure enough,
it reported the same result!
It also reported a maximum timing interval of 87724005 milliseconds--
I'm not sure if this number depends on your exact machine, system
version or what. Interesting.
Actually, I'm assuming that the Extended Time Manager has only
appeared with 6.0.6/6.0.7. For all I know, it was in 6.0.5.
Or 6.0.4...
Lawrence D'Oliveiro fone: +64-71-562-889
Computer Services Dept fax: +64-71-384-066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
"How did you know they were sergeants' quarters?"
"There were ten huts."eby@cbnewsj.att.com (robert.p.eby) (11/09/90)
In article <2252.273af53c@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > ..... > > Actually, I'm assuming that the Extended Time Manager has only > appeared with 6.0.6/6.0.7. For all I know, it was in 6.0.5. > Or 6.0.4... > According to Gestalt DA, 6.0.5 also has time manager version 3, so presumably this stuff will work there also. Robert P. Eby UUCP: att!pegasus!eby AT&T Bell Laboratories Domain: eby@pegasus.ATT.COM
pratt@boulder.Colorado.EDU (Jonathan Pratt) (11/10/90)
As long as this thread is going on, I have a few questions about the
Time Manager. First, I know it's documented somewhere how to tell how
much time is left in a task. So, either where is this documented, or
how can the tmCount field be interpreted? (Also, is this applicable before
RmvTime is called?) I seem to recall from snooping around that the tmCount
increments are dependent on the time requested - is this true? Note
that the tmCount field is incorrectly called an integer in IM IV.
Second, is it supposed to be possible for a task to reinstall itself
with _PrimeTime, the way vbl tasks do by resettings their counts?
I've found this works unless it's allowed to happen when the computer
is doing other things, because of WNE calls. Nothing funny happening
at interrupt level - just a _PrimeTime call.
Finally, is it legitimate to call _PrimeTime for an active task - that
is, reset to a higher time before an installed task times out?
Any comments and information will be appreciated.
Jonathan
/* Jonathan Pratt Internet: pratt@boulder.colorado.edu *
* Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt *
* University of Colorado *
* Boulder, CO 80309 Phone: (303) 492-4293 */keith@Apple.COM (Keith Rollin) (11/11/90)
In article <29523@boulder.Colorado.EDU> pratt@boulder.Colorado.EDU (Jonathan Pratt) writes: >As long as this thread is going on, I have a few questions about the >Time Manager. First, I know it's documented somewhere how to tell how >much time is left in a task. So, either where is this documented, or >how can the tmCount field be interpreted? (Also, is this applicable before >RmvTime is called?) I seem to recall from snooping around that the tmCount >increments are dependent on the time requested - is this true? Note >that the tmCount field is incorrectly called an integer in IM IV. I don't think this is true any longer. I believe that the Extended Time Manager gets its greater resoution (250 microsec) by letting the hardware count down, rather than doing its own counting in tmCount. >Second, is it supposed to be possible for a task to reinstall itself >with _PrimeTime, the way vbl tasks do by resettings their counts? >I've found this works unless it's allowed to happen when the computer >is doing other things, because of WNE calls. Nothing funny happening >at interrupt level - just a _PrimeTime call. I use the Time Manager -- even in the brackground -- in the DTS sample code FracApp 2.0. I've never noticed any problems. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
pratt@boulder.Colorado.EDU (Jonathan Pratt) (11/11/90)
In article <29523@boulder.Colorado.EDU> I wrote: (Asked how to determine time left in a TM task, to which Tom Dowdy <dowdy@apple.com> kindly replied:) According to [new docs], after calling RmvTime, the time remaining until the completion of the task will be in tmCount. >In article <46475@apple.Apple.COM> keith@Apple.COM (Keith Rollin) wrote: (In response to my complaint about troubles having TM tasks reinstall themselves:) >I use the Time Manager -- even in the brackground -- in the DTS sample >code FracApp 2.0. I've never noticed any problems. I'm afraid I'm guilty of not giving the whole story in my original post. I ran into trouble when I tried to get several dozen tasks running at one millisecond intervals to simulate how the Mac would behave with Nubus interrupts occurring at frequencies from 10khz to 100khz. Perhaps there should be an addendum to the tech note titled "Don't Abuse the Managers" :-) Jonathan /* Jonathan Pratt Internet: pratt@boulder.colorado.edu * * Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt * * University of Colorado * * Boulder, CO 80309 Phone: (303) 492-4293 */
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (11/13/90)
So *that* was the meaning of the cryptic paragraph in the 6.0.5 release notes, where it said that "System 6.0.5 implements the functionality of the Time Manager found in the Macintosh IIci ROMs on all Macintosh CPUs. The interface to the Time Manager has not changed since system 6.0.3." I think Apple's engineers should get their documentation people to check out their release notes... Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 "...so she tried to break into the father bear's computer, but it was too hard. Then she tried to break into the mother bear's computer, but that was too easy..."