Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!kth.se!cyklop.nada.kth.se!news
From: d88-skl@dront.nada.kth.se (Stellan Klebom)
Newsgroups: comp.sys.amiga.tech
Subject: Re: CIA Timers and Interrupt priority problems
Message-ID: <1991Jan3.213113.27604@nada.kth.se>
Date: 3 Jan 91 21:31:13 GMT
References: <650@faatcrl.UUCP> <1991Jan2.170422.10398@nada.kth.se> <658@faatcrl.UUCP>
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 33

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

[many kinds of text deleted]

>
>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.

Well, you can setup your message port so that a software interrupt is generated
when the timer.device replys your IOrequest. Of course your suggested method
have slightly less overhead, but I don't think the difference is so big after
all.
>
>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.
>

Well, I did forget to mention software interrupts in connection to message
ports. I sort of assumed you knew about that possibility...  ;)

>Jim

/Stellan
-----------
This sig is stolen, but that is alright since nobody ever missed it...