Xref: utzoo comp.sys.mac.programmer:8742 comp.sys.mac:37312 rec.music.synth:8814 Path: utzoo!attcan!utgpu!watmath!iuvax!mailrus!shadooby!oxtrap!time From: time@oxtrap.oxtrap.UUCP (Tim Endres) Newsgroups: comp.sys.mac.programmer,comp.sys.mac,rec.music.synth Subject: Re: Mac SCC madness (Multifinder deranged?) Message-ID: Date: 30 Aug 89 15:09:22 GMT References: <832@amc-vlsi.UUCP> Reply-To: time@oxtrap.UUCP Distribution: na Organization: Oxtrap - Ann Arbor, MI Lines: 28 In-reply-to: green's message of 29 Aug 89 22:14:02 GMT 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.