leo@ehviea.ine.philips.nl (Leo de Wit) (08/13/90)
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.uace0@uhnix2.uh.edu (Michael B. Vederman) (08/19/90)
Leo - Just as a guess, sounds like your interrupt is ocurring at the same time you are attempting to change it. Just some observations: 1) Be certain your interrupt is restoring any registers it destroys 2) Be certain _not_ to save registers onto the stack, but rather use a static storage area 3) If neither one of those help, try masking off interrupts by raising your ipl to 7 before issuing the xbtimer() call. From what I can see of the xbtimer() call, it does not touch the ipl when it is initing the mfp, so you can conceivably be interrupting when you are changing. Altho, the xbtimer() call does disable the interrupt before changing it... - mike -- ------------------------------------------------------------------------------ Double Click Me | Double Click Software | P.O. Box 741206 | Houston, Tx, 77274 ------------------------------------------------------------------------------ Voice: (713)977-6520 | DC DESKTOP | DC FORMATTER | DC UTILITIES | and others
uace0@uhnix2.uh.edu (Michael B. Vederman) (08/19/90)
Leo - Also, 24 bombs is not real. Chances are you are getting 2 or 3 bombs (address error (3 bombs) or BUSSERR bus error (2 bombs)) but repeatedly. In other words, the system crashes, attempts recovery, crashes again, etc. until it locks up. Well, 24 bombs is real, but I've never seen it occur... - mike -- ------------------------------------------------------------------------------ Double Click Me | Double Click Software | P.O. Box 741206 | Houston, Tx, 77274 ------------------------------------------------------------------------------ Voice: (713)977-6520 | DC DESKTOP | DC FORMATTER | DC UTILITIES | and others
leo@ehviea.ine.philips.nl (Leo de Wit) (08/20/90)
In article <1166@uhnix2.uh.edu> uace0@uhnix2.UUCP writes: |Leo - | |Just as a guess, sounds like your interrupt is ocurring at the same time you |are attempting to change it. Just some observations: | |1) Be certain your interrupt is restoring any registers it destroys Yep, it is _very_ simple (also in order to have a fast counter): myint add.l #1,counter rte |2) Be certain _not_ to save registers onto the stack, but rather use a static | storage area Does not apply here. |3) If neither one of those help, try masking off interrupts by raising your | ipl to 7 before issuing the xbtimer() call. From what I can see of the | xbtimer() call, it does not touch the ipl when it is initing the mfp, so | you can conceivably be interrupting when you are changing. Altho, the | xbtimer() call does disable the interrupt before changing it... Ah, but the spurious interrupt does indicate problems with the MFP, not with the 68000; if I understand correctly, it generally indicates that a BUSERR occured on a periferal chip. So masking all interrupts shouldn't help (but it won't hurt to give it a try). In your second note: |Also, 24 bombs is not real. Chances are you are getting 2 or 3 bombs (address |error (3 bombs) or BUSSERR bus error (2 bombs)) but repeatedly. In other words, |the system crashes, attempts recovery, crashes again, etc. until it locks up. | |Well, 24 bombs is real, but I've never seen it occur... But it is most definitely exception 24 (spurious interrupt); this is not only indicated by the ST bomb thrower - which occasionally is unreliable - but also the exception save area indicates this. And catching vector 24 and retrying does solve the problem ... B.T.W. thanks for your suggestions, Mike. If someone is still interested, I'll try to cut out a minimal code fragment to hack on. | |- mike | |-- |------------------------------------------------------------------------------ |Double Click Me | Double Click Software | P.O. Box 741206 | Houston, Tx, 77274 |------------------------------------------------------------------------------ |Voice: (713)977-6520 | DC DESKTOP | DC FORMATTER | DC UTILITIES | and others Leo.
uace0@uhnix2.uh.edu (Michael B. Vederman) (08/21/90)
Leo - I'll be glad to mull over anything you send which you think will help isolate your problem. I always like a good mystery! :-) - mike -- ------------------------------------------------------------------------------ Double Click Me | Double Click Software | P.O. Box 741206 | Houston, Tx, 77274 ------------------------------------------------------------------------------ Voice: (713)977-6520 | DC DESKTOP | DC FORMATTER | DC UTILITIES | and others
franky@netmbx.UUCP (Frank Bergemann) (08/30/90)
hello ! anybody here, who knows how to get the tos-routines (gemdos, (x)bios) reentrant, to use in interrupts ? same question failed in german nets. we don't know which adresses (or their contents) must be saved and reinstalled before leaving an interrupt... mfg .......franky
7103_2622@uwovax.uwo.ca (Eric Smith) (09/01/90)
In article <1081@netmbx.UUCP>, franky@netmbx.UUCP (Frank Bergemann) writes: > anybody here, who knows how to get the tos-routines (gemdos, (x)bios) > reentrant, to use in interrupts ? same question failed in german > nets. we don't know which adresses (or their contents) must be > saved and reinstalled before leaving an interrupt... > The BIOS and XBIOS routines are already somewhat re-entrant, and can be made more so by providing a bigger BIOS stack. GEMDOS is inherently non-reentrant. The safest strategy is probably just to set a flag in the interrupt routine, and then have the user code check the flag every so often and take the appropriate action. -- Eric R. Smith email: Dept. of Mathematics ersmith@uwovax.uwo.ca University of Western Ontario ersmith@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638