Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!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: <1991Jan2.170422.10398@nada.kth.se>
Date: 2 Jan 91 17:04:22 GMT
References: <650@faatcrl.UUCP>
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 40

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

[deleted text]

>I don't think the timer device would work for me.  It isn't "real time" enough 
>for a music player (to much wavering mostly due to task schedualing), plus 
>it uses the CIA B timers, which would cause the same problem.
>
>I could recode things to use the vblank Interrupt, but that would require 
>compensating for the video mode you're presently in.  Plus I don't want to
>give up on the timers yet.
>
>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
>there's some sort of software interrupt which doesn't interrupt hardware
>interrupt service routines, or is maskable, and which would take effect
>upon an rte from the hardware interrupt service routine.  The software
>interrupt, would of course be vectored to the music player routine.  

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

[text deleted]

>
>C'ya,
>Jim
>
>-- 
>UUCP:  ...!rutgers!faatcrl!jimb              Internet:  jimb@faatcrl.UUCP
[sig deleted]

Stellan

No sig is a good sig...