Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!faatcrl!jimb
From: jimb@faatcrl.UUCP (Jim Burwell)
Newsgroups: comp.sys.amiga.tech
Subject: CIA Timers and Interrupt priority problems
Message-ID: <650@faatcrl.UUCP>
Date: 31 Dec 90 20:33:13 GMT
Organization: FAA Technical Center, Atlantic City NJ
Lines: 66

Hi...

I'm writing a CLI based [Med|*tracker] module player.  The thing is pretty
much done, 'cept for one problem.  The music player routine uses Interrupts
from a CIA timer for its timing.  This is better than using vblank since
you don't have to worry about NTSC/PAL timing differences.  But now that CBM 
has stolen both CIA A timers for 2.0, I must use one of the CIA B timers.  
This works fine, except that the CIA B timer hardware Interrupt priorities 
are so high that the music player now interrupts EVERYTHING.  This is no 
problem until you try to call up you favorite BBS while listening to some 
modules.  The timer interrupt constantly interrupts the serial port Receive 
Buffer Full interrupt service routine (or just blocks the interrupt), often
causing a buffer overflow on the serial port.  The result, of course, are 
lots of dropped characters from the serial port, making telcom impossible.
This is unacceptable to me since one of my main reasons for writing this 
player is to give Amiga users the ability listen to modules while modeming. 
(Intuitracker fails mainly because it GURUs all the time.  EVERY time when
 you go into a Zmodem download with JR-Comm.  And secondly, because it doesn't 
 have all the features I wanted in a music player.)

Does anyone have any suggestons ?  

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.  
If I remember correctly, the software interrupt service routine can be
interrupted by other hardware interrupts.  Those that arn't "as important"
could be masked, but important interrupts like the RBF, could interrupt
the music player routine at certain points, hopefully solving the serial
overflow problems.  The only problem I see is that the timing could be 
thrown off if the right set of events happens between the rte from the 
hardware interrupt and the calling of the software interrupt (LOTS of
hardware interrupts, leading to/or a Timer interrupt occuring before the
software interrupt was serviced or before it could be masked).  
But I think it could work under most circumstances.

Comments ?

(no flames)

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