green (Brian Green) (08/30/89)
I have a Mac SE/30 for which I am (GASP!) writing my own SCC (serial
controller) interrupt service routines so that I can develop some MIDI
utilities (yes, yes, I know that there is a toolkit available...).
So far, I have had great sucess intercepting, buffering, and re-transmitting
the MIDI stream from my keyboard under FINDER, but when I run the
application under MULTIFINDER, I am plagued by seemingly random losses of
MIDI data, along with occasional total lock-ups of the Mac (requiring power
down to reset). Can anybody suggest what I may be doing wrong?
I have tried to follow the compatibility guidelines in Inside Macintosh I-V
which include:
- not using the user stack pointer in assembler routines
- not changing interrupt status
- not making assumptions about the location of the application
or system heaps
- not doing anything to the status register.
I suspect that the problem has something to do with Multifinder periodically
taking over for so long that a receiver overrun occurs. Any suggestions?
Sorry to the rec.music.synth group if this posting doesn't belong there, but
I have on occasion read some excellent technical discussions there.
Please reply via e-mail and I will summarize to the net if responses warrant
it.
green@amc-vlsi.uucp (Brian Green)
<Insert standard disclaimer here>rich@sendai.sendai.ann-arbor.mi.us (K. Richard Magill) (08/30/89)
In article <832@amc-vlsi.UUCP> green (Brian Green) writes:
So far, I have had great sucess intercepting, buffering, and re-transmitting
the MIDI stream from my keyboard under FINDER, but when I run the
application under MULTIFINDER, I am plagued by seemingly random losses of
MIDI data, along with occasional total lock-ups of the Mac (requiring power
down to reset). Can anybody suggest what I may be doing wrong?
Yes.
A) Don't use global data. You are probably presuming that A5 is set
properly within one of your interrupt service routines. This is not a
valid assumption under multifinder. The MIDI driver that came with
glib-1.6 suffered from this same problem. (mail me if you'd like a
corrected version)
B) Why are you writing your own when several versions already exist,
more or less in the public domain? (rhetorical question).
C) Why would anyone in their right mind write anything other than MIDI
Manager on mac these days?
I have tried to follow the compatibility guidelines in Inside Macintosh I-V
which include:
- not using the user stack pointer in assembler routines
There is nothing wrong with using stack. (short of avoiding
overflows). What they are trying to get across in the tech notes is
that you can't make any assumptions about the contents of stack below
your frame, across calls. ie, any two functions, F and G may not see
the same thing below their stack frames. This is only common sense,
but someone at apple didn't realize this when they originally wrote
the save/restoreA5 code.
--
rich.time@oxtrap.oxtrap.UUCP (Tim Endres) (08/30/89)
In article <832@amc-vlsi.UUCP> green (Brian Green) writes:
I have a Mac SE/30 for which I am (GASP!) writing my own SCC (serial
controller) interrupt service routines so that I can develop some MIDI
utilities (yes, yes, I know that there is a toolkit available...).
So far, I have had great sucess intercepting, buffering, and re-transmitting
the MIDI stream from my keyboard under FINDER, but when I run the
application under MULTIFINDER, I am plagued by seemingly random losses of
MIDI data, along with occasional total lock-ups of the Mac (requiring power
down to reset). Can anybody suggest what I may be doing wrong?
We just got over a *very* similar problem with glib. We were utilizing
application globals, so needed a valid A5 at interrupt time. The old
way of doing this, using CurrentA5 as discussed in TechNotes, does not
suffice under MultiFinder. This is because CurrentA5 changes as each
application is swapped in and out. You must now store the A5 within
the interrupt handler code itself. This gets trickier on 68030 with
instruction caching, but we haven't addressed that yet.
If this is not the problem, another potential problem may be how you
install your interrupts. For instance, under MultiFinder, VBL tasks
that reside in the application heap are removed when the application
is swapped out, and replaced when it is swapped in. You are probably
not using VBL tasks, but this illustrates the diverse problems of
MultiFinder compatability.
Beyond this, I need more info.