🚀 go-pugleaf

ccplumb@spurge.uwaterloo.ca (Colin Plumb) writes:

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

>Both CIA A timers are in use in 1.x, it's just that it wasn't properly
>documented for a long time.  See Appendix F of the 1.3 Hardware manual, or
>other recent sources.

Documented or not, under 1.3 OpenResource and AddICRHandler allowed me to
use CIA A Timer A.  Under 2.0, it didn't let me touch it.  This is tested
on some lucky guy's A3000 (hi Jack :-).

[deleted]
>>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. 

>Well, you need to, somehow, make your interrupt server faster, putting more
>work at lower interrupt levels.  The ultimate is to just have it trigger a
>lower-priority event and return.  The ones that are available are:

Well, making the service routine faster is almost impossible.  It's totally
68K assembly, and pretty tense as it is.  I could go though and bum some
cycles probably, but I doubt I could free enough to make a difference.

>- Lower-priority hardware interrupts.  Number 2, SOFT, looks particularly
Hmm.  How does one trigger a low level hardware interrupt.

>inviting, and it's level 1, the lowest there is.  You can also trigger

My original idea was to do a software interrupt in the Timer Int service
routine.  I'll have to look up the Mnemonics in my 68K book.  I'm a MC6809
assembly refugee :-).  I havn't written a whole lot of ASM code on the 68K
family yet.  Mostly C.  On the 6809 I would use a SWI :-).

>(using a write to the INTREQ register) a PORTS (CIA A) interrupt and install
>your own server in the chain.  This is completely multitasking-friendly,
>and lets you use all of your old code, changing only the checking to see if
>it's "really for me".

Hmm.  How does one go about adding your int server into the chain ?  I think
AddICRServer would fail.  I'll have to look into this.  It wouldn't be tough
to figure out if the interrupt is for me.  Wouldn't doing that also fool
any other int handlers which are using that interrupt into thinking 
the interrupt is for them ?  Unless my handler would be put "first in line",
and do an RTE instead of an RTS ?  I don't know what Exec's interrupt 
vectoring code requires (time to look into the RKMs :-).

>- Software interrupts.  Probably the thing to use, if you can.  These are
>really quite responsive.

Yeah.  I agree.  I think that's what I'll do.

>- Tasks.  It should be possible to sufficiently preprocess the information the
>interrupt server needs that it can be fast enough.  All it's doing, after all,
>is stuffing new values into the chip registers and CIA.  I'd be surprised
>if you couldn't MOVEM a table into registers and store it out.

Yeah.  I could re-write the player to set everything up for the next 
"event" and just move the a table of values into the appropriate spot.  But
then I must process the data for the next event.  Of course, as you seem to
indicate, this pre-processing would be done outside of the interrupt service
routine.  But what happens if the next interrupt occurs before my task gets
enough CPU time to prepare the data for the interrupt server ?

>>Does anyone have any suggestons ?  

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

>Actually, it's the exec.library Cause() function.

Hmm.  I'll look into that.  As you may have guessed by now, I'm not REAL 
familiar with the Amiga yet.  I don't have all the system calls memorized
yet.  Thanx for this pointer!  

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

>Yup.  Make an interrupt structure, and pass a pointer to it to Cause().

Great.  Useful info at last!  There IS a use for c.s.a.t.! :-)

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

>There's no good multitasking-friendly way to mask off other people's
>interrupts except to operate at a certain level interrupt yourself.
>I seriously doubt it would be necessary.

I was more thinking more on the lines of masking the interrupts needed to
make this service routine "equivelent" to the original CIA A Timer A interrupt
which worked so well.  Perhaps I won't need to.  But if the software interrupt
gets interrupted by EVERYTHING, then it will probably mess up the music.
Can't have that!  :-)

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

>If too much is happening, *something* isn't going to get serviced.  I suggest
>that a bobble in the music player is preferable to some other things.

Agreed.  I'm very happy with the way the music player works with the CIA A
timer A interrupt.  I don't notice ANY system slowdown.  Neither does JR-Comm
operating at 19.2Kbaud.  Zmodem doesn't even hiccup once!  And this is on a
lowly A500 with an '010 in it, with 2 floppies and 3 HD partitions.  

As soon as I get this little problem worked out, and add a few more it will 
be ready features, it will be ready for 1.0 distribution!  The program is
totally solid.  It hasn't GURU'ed my system once, and when run on an A3000,
enforcer doesn't make a peep.  (boy, I hope I didn't just jinx myself :-)

Thanx for the info!

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