Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!coherent!dplatt From: dplatt@coherent.com (Dave Platt) Newsgroups: comp.sys.mac.hardware Subject: Re: Status of SID hardware kits? Message-ID: <62566@coherent.coherent.com> Date: 5 Jul 90 00:45:18 GMT References: <1123@gvgspd.GVG.TEK.COM> <9255@wheat-chex.ai.mit.edu> <443@6sceng.UUCP> <13852@wpi.wpi.edu> Reply-To: dplatt@coherent.com (Dave Platt) Organization: Coherent Thought Inc., Palo Alto CA Lines: 69 In article palmer@gap.caltech.edu (David Palmer) writes: > My problem is that it when it's plugged in, it sends out data and so > prevents the CPU form working because of interrupts. (A Mac SE/30 > runs very slowly (~100x slower), and motion on an SE is imperceptible.) > I can digitize with it plugged in, and then unplug it and play back the sound > and everything's fine. > > Since other people don't have this problem, it is something wrong in the > one I built. I don't think there's anything wrong with your unit. Mine has a similar behavior, but only on the two Mac SE machines I tested it with at work. The SE locks up (its cursor won't track) for as long as the SID is plugged into the serial port and the SID Test Utility is running. When it's unplugged, the cursor jumps to where it "should have been". The same SID II works perfectly with my Mac II at home. Mike Ciholas tells me that he tested the SID II design with both the II and Plus, and that it works correctly... but that he didn't have a chance to test it with an SE. His best guess is that the HearHere.c code isn't properly disabling all of the serial port interrupts on the SCC when it puts the SCC into high-speed-clocked-data mode. As a result, the 22 kilobytes/second coming in from the SID causes the Mac to swamp itself with serial port interrupts, and the mainline code never gets any time. I've looked at the SCC-twiddling code, but can't figure out why it's not working... I don't have any documentation on the Zilog chip, Inside Mac isn't at all helpful, and the code is somewhat opaque. It _looks_ as if the code is intending to turn off the SCC interrupts... but I could very well be wrong about this. I suppose it's possible that the SE and SE/30 have a different SCC chip than the Plus and II... or that there's an error in the HearHere.c code which is only exercised when running in an SE-style architecture. Beats me, though. Anybody got a Mac Family Hardware Manual handy? I suppose that it would be possible to rewrite HearHere.c so that it actually configures the serial port only when it's about to digitize... and turns off all interrupts, first. It might be necessary to throw away the first tenth-of-a-second's samples, when this is done, in order to give the digitizer time to stabilize itself. > It is my understanding that when the digitizer is not sampling, it is > suppowed to be unpowered. Is my understanding wrong? mine always has > 5 V available. If that is not how sampling is turned on and off, how > is it done? The digitizer is powered from the differential transmit-data lines, which are always enabled (one way or the other); it's always digitizing and sending data. I believe that some other digitizers (e.g. the Impulse) have a green status LED which is tied to the Mac's handshake-out line (the one which is usually connected to the DTR pin on a modem), and will light the LED only when the serial port has been configured to receive data from the digitizer. I don't believe that this controls whether or not the digitizer is sampling and converting data... it just shows the user that the port is in use. > Please mail me instead of posting. If there is general interest (which > I doubt) I will post a summary. Thanks for the help. I don't think you're going to be the only person in this situation... hence my posting.