Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!phigate!ehviea!leo
From: leo@ehviea.ine.philips.nl (Leo de Wit)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Using Timer A to replay a sample
Message-ID: <894@ehviea.ine.philips.nl>
Date: 29 Sep 90 23:00:09 GMT
References: <1990Sep24.122920.15704@irscscm.UUCP> <891@ehviea.ine.philips.nl> <892@ehviea.ine.philips.nl> <5558@harrier.ukc.ac.uk>
Reply-To: leo@ehviea.UUCP (Leo de Wit)
Organization: Philips I&E Eindhoven
Lines: 59

In article <5558@harrier.ukc.ac.uk> dac@ukc.ac.uk (David Clear) writes:
|In article <892@ehviea.ine.philips.nl> leo@ehviea.UUCP (Leo de Wit) writes:
|>
|>The sequence for timer A is (I looked it up):
|>
|>my_timint
|>    ... do your stuff here ...
|>    bclr #5,$fffa0f
|>    rte
|>
|
|This sequence is correct - I have had no problems using it. I've never
|seen any documents to suggest that 1s have to be written into the other
|bits of the "interrupt in service" register.

I'll quote my source (the Atari Profi buch, Dutch translation):

- Nadat de lopende interrupt werd afgehandeld, dient de CPU het bijbehorende
bit in het ISRA of ISRB "0" te maken. Een bit wordt "0" door in alle bits van
het register, behalve het bedoelde bit, een "1" te schrijven. Doordat bits in
het Interrupt Pending Register softwarematig alleen "0" en niet "1" gemaakt
kunnen worden, wordt de inhoud van het register door het schrijven van de
"enen" niet gewijzigd.

(Original text to help understand a bit what it is like to read texts
that are not written in your native language).

|                                             As I understand it, when
|the MFP gets an interrupt, it will not signal the 68000 unless it is
|of a higher priority than those already in service.

The MFP can't even GET an interrupt that is of equal or lower priority
than that currently being serviced, let alone notify the 68000 (by
interrupting it); however such an interrupt remains pending and will
be serviced when the current one terminates (if this is within the
maximum amount of time it may be pending, the so-called interrupt
latency).

|                                                    Similarly, if it
|does signal the 68000, the 68000 will not service it unless the IPL has
|been moved back below 6 (?).

The same holds here; the interrupt will be serviced when the IPL has
been moved back below 6 (and if it is still pending then).

|
|So, for general purpose, multi-level interrupts, the order of events
|should be:
|
|int:	move.w	#$2300,sr	/* Also enables VBI, #$2400, disables VBI */

Sorry, no. The whole purpose of having multi-level interrupts is that
an higher level interrupt won't be interrupted by a lower level one;
this just defeats it. Also never plainly put a value in sr, OR it in or
AND it out.

Sorry to be such a nit-picker, Dave. Feel free to counter-attack 8-).

    Leo.