Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!hp4nl!phigate!ehviea!leo
From: leo@ehviea.ine.philips.nl (Leo de Wit)
Newsgroups: comp.sys.atari.st.tech
Subject: Spurious interrupt
Message-ID: <883@ehviea.ine.philips.nl>
Date: 13 Aug 90 08:10:12 GMT
Reply-To: leo@ehviea.UUCP (Leo de Wit)
Organization: Philips I&E Eindhoven
Lines: 34

For the record: I am currently developing a MIDI recorder program; most
of it works already - still have to add some windowing stuff.

One part of the recorder is a metronome, that can be adjusted on the
fly (that is, you can alter the beats/minute while recording/playing,
which effectively can alter replay speed). The metronome is based on
Timer A; the interrupt routine increments a global variable, then
clears bit 5 of $ffff0a (if memory serves right). When the metronome is
altered, Xbtimer() is called with new parameters that reflect the new
timer A registers.

Now for the problem: this setup works - most of the time. Occasionally
when I alter the metronome a lot, a spurious interrupt occurs:
exception 24 (I get 24 bombs). From my MC68000 manual I believe this is
more or less a fake interrupt, a hardware designer might use it to
indicate that an extern exception occured (such as a bus error of the
MFP68nnn). Could it be that Xbtimer() is affecting the MFP68nnn while
it is still in my interrupt routine (e.g. between the last two
instructions: and.b #$df,$ffff0a and rte) ? The register dump always
shows that the last executed instruction was a clear of the interrupt
pending bit, something like bclr #d0,(a0) with d0.b being 5 and a0
$ffff0a, in either the Xbtimer() or Jdisint() calls (I also tried to
use Jdisint() before the next Xbtimer() call; same problem).

The current workaround I have is to revector the spurious interrupt and
save registers, then call Xbtimer() and when the interrupt occurs jump
back to retry (this is effectively a longjmp). The bios save area
pointer is also restored. This works fine now, but I would like to know
whether there is a less kludgy solution to this problem. Most
programmers using Xbtimer() will not have noted this problem, simply
because they use it only once (mostly I have to call Xbtimer() several
hundreds of times before the interrupt occurs).

    Leo.