Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!faatcrl!jimb
From: jimb@faatcrl.UUCP (Jim Burwell)
Newsgroups: comp.sys.amiga.tech
Subject: Re: CIA Timers and Interrupt priority problems
Message-ID: <658@faatcrl.UUCP>
Date: 2 Jan 91 23:30:33 GMT
References: <650@faatcrl.UUCP> <1991Jan2.170422.10398@nada.kth.se>
Organization: FAA Technical Center, Atlantic City NJ
Lines: 38

d88-skl@dront.nada.kth.se (Stellan Klebom) writes:

>In article <650@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes:

[all kinds of text deleted]

>>I have been thinking of a scheme to use Software Interrupts called in the
>>timer interrupt routine.  Something like this:
>>
>>TimerIntServer:  trap (or whatever)
>>                 rts
>>
>>This would get in and out of the high-priority interrupt server quickly,
>>hopefully giving the time back to other interrupts.  I'm assuming that

>So use the timer.device, because that is how the timer.device works...

Well, no.  There's another level to the timer device which makes it too
unstable for a music program IMHO.  Of course, I havn't really tried it :-).
But, I'm assuming things won't be reliable enough because the timer.device
only returns Exec IOrequests to your task.  Exec must then (eventually) 
wake up your task.  That can take any ammount of time, depending on 
system load, priorities, etc.  

With the scheme I proposed, the player routine would still be on an interrupt,
which is CPU controlled instead of Kernal controlled.

And since you mentioned that the timer.device does exactly what I proposed,
I guess that means what I proposed will work!  Thanx.  You managed to answer
one of my questions.

C'ya,
Jim
-- 
UUCP:  ...!rutgers!faatcrl!jimb              Internet:  jimb@faatcrl.UUCP
		Under brooding skys and watchful eyes
		On convulsive seas of false urgency
		We walk empty corridors in vain - "No Exit", Fate's Warning