TAB113@psuvm.psu.edu (09/14/90)
I'm writing a program that needs to output data to a file while at the same time, new data may be comming into the Mac via an interface card. We would like to have the data saved upon its arrival, but we can not lose any data when doing this. My question: What is the best way to go about doing this? I'm using THINK C, version 4.0.2 with the TCLs. I've already tried setting up a VBL task which just did a SysBeep(1) and an interval of 60 ticks, but shortly into the application, the beeping stopped. Everything else worked fine. Anyway, if anyone has any info regarding this topic, please let me know. Thanks for listening! Michael Bitonti
stevec@Apple.COM (Steve Christensen) (09/14/90)
In article <90256.130529TAB113@psuvm.psu.edu> TAB113@psuvm.psu.edu writes: > > I'm writing a program that needs to output data to a file while at the >same time, new data may be comming into the Mac via an interface card. We >would like to have the data saved upon its arrival, but we can not lose any >data when doing this. > > My question: What is the best way to go about doing this? I'm using >THINK C, version 4.0.2 with the TCLs. I've already tried setting up a VBL >task which just did a SysBeep(1) and an interval of 60 ticks, but shortly >into the application, the beeping stopped. Everything else worked fine. >Anyway, if anyone has any info regarding this topic, please let me know. It sounds like your interface card doesn't generate interrupts when data is available, so you use the VBL task to periodically check for data. One way to do it would be to use 2 buffers and switch back and forth, so that when one is full it can be written out to disk while the other is filling. When it's time to write a buffer to disk, the VBL could setup a deferred task to do the actual write so that you won't run into any interrupt task-related problems. Regarding the problem you're seeing with SysBeep, I don't think it works very well when called from an interrupt task, since it uses the Resource Manager to load the sound to play, which uses the Memory Manager to allocate space for the sound in the heap, which is a no-no from an interrupt task since the heap could be invalid. At least that's what could be happening... steve -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ whoami? Steve Christensen snail: Apple Computer, 20525 Mariani Ave, MS-81CS, Cupertino, CA 95014 Internet: stevec@goofy.apple.com AppleLink: stevec CompuServe: 76174,1712
ts@cup.portal.com (Tim W Smith) (09/14/90)
SysBeep, according to IM-III, is a trap that can move or purge memory. Thus, it can't be called from a completion routine or a VBL task. When you are playing around with something and want to know if it gets exectuted (e.g., a completion routine, a VBL task, a slot interrupt, or whatever), do something like this: move.l ScrnBase, a0 add.l #1, (a0) or, from Think C ++*(long *)ScrnBase; (don't trust me on the syntax for this...and be aware that MPW C handles low memory globals differently). Then, just watch the upper left corner of the screen to see if your code is getting called. Tim Smith