GUS Programmer's Digest Wed Jun 16 00:07 Volume 2: Issue 14 Today's Topics: Gravis/FORTE - Please read this!!! Turbo Pascal SDK Standard Info: - Meta-info about the GUS can be found at the end of the Digest. - Before you ask a question, please READ THE FAQ. ---------------------------------------------------------------------- Date: Tue, 15 Jun 93 10:20:12 EDT From: davidm@opl.com Subject: Gravis/FORTE - Please read this!!! Message-ID: (Hi, gus-sdk readers, this is primarily intended for...) Gravis/FORTE, I have been working with the low level SDK (version 2.01) for a few nights now and I have discovered a couple of points which you neglected to put in the low level SDK code and/or documentation. I describe them here and follow their descriptions with some suggestions for their correction and/or improvement. At the end I ask a few quesitons and offer some praise. POINT 1 ------- The first point is what was causing the problem I had with looping and wave table interrupts. If I set up a voice with looping and WITHOUT interrupts, everything behaved as expected. If I set up a voice with looping and WITH interrupts, the voice would play from start to end and then stop - no looping. This was driving me crazy (for quite some time, I might add) until I looked in IRQ.C and saw the following... if (!(wave_ignore & voice_bit)) { UltraStopVoice(voice); wave_ignore |= voice_bit; /* Call waveform processing function.... */ _gf1_data.wavetable_func(voice); } EUREKA!!! UltraStopVoice gets called before my callback function!!! You neglect to mention this fact in the SDK documentation (thank you, NOT!) or at least I couldn't find reference to it. The ramifications of this fact are that (more often than not, IMHO) the first thing that anyone's wave table callback function will do is call UltraGoVoice. Since UltraGoVoice needs a "mode" passed to it, the mode bits for every voice that may generate a wave table IRQ must be stored in a global array. (I haven't gotten to it yet, but from what I saw in IRQ.C, I suspect that volume ramping will have the same kind of situation.) POINT 2 ------- The second thing that irks me has to do with the rollover bit. It seems to me that this bit has more to do with controlling a voice than it has to do with controlling a volume ramp. It seems that the number of voice control bits didn't fit into an 8 bit register so one bit got stuck into an ununsed position of the volume ramp control register. This is borne out by the fact that in GF1HWARE.H most of the bits for the volume ramp control are labelled VL_, but the rollover bit is labelled VC_ROLLOVER (the VC_ prefix corresponds to the prefixes of the other voice control bits). I have no problem with this bit "relocation". The one gripe I do have about this topic is that there is no clean way to manipulate this bit, using the functions provided in the SDK. As far as I can tell, the only way to influence this bit, using the functions provided in the SDK, is to use UltraRampVolume. It seems to me that it would be rather difficult, using the functions provided in the SDK, to alter the rollover bit without affecting what very well may be an active volume ramp. Since this bit plays such an important part in a ping-pong buffer implementation, it seems like a gross oversight to leave this functionality out of the SDK. SUGGESTIONS ----------- Regarding the first point, it's not clear to me why UltraStopVoice needs to be called before calling the callback function. In any event, you should either change the SDK to not call it or at least *MENTION* that it does in fact get called before the callback. Why does this call get made anyway? Regarding the second point, looking in VOCSTART.C it becomes apparent that the two least significant bits of the "mode" byte get stripped in UltraGoVoice before it is written to the voice control register. It seems that one of those bits could be used as a rollover flag that gets written to the the rollover bit in the voice's volume ramp control register. This would give the ability to control ALL of a voice's control bits in the "mode" byte that is passed to UltraGoVoice (and UltraPrimeVoice and UltraStartVoice). QUESTIONS --------- 1) Why does UltraStopVoice need to be called before the wave table callback function is called? 2) Assuming UltraStopVoice needs to be called before the wave table callback function is called, is a global array the best way to keep track of the control bits for the various voices that may want to call UltraGoVoice in the wave table callback funtion? 3) Is there a way, using the functions provided in the SDK, to read the current mode bits of a voice? 4) What do you think the chances are for an improved UltraGoVoice that accepts a rollover flag in one of the two least significant bits of the "mode" byte? 5) Until such an improved UltraGoVoice becomes available, can you provide example code that will allow the examination and modification of the rollover bit WITHOUT affecting any volume ramp that may be in progress? Here are the prototypes of the functions I would like... // returns the current state of the rollover bit for voice int UltraGetRollover( int voice_num); // sets the state of the rollover bit for voice to 1 if // is non-zero or to 0 if is zero // returns the previous state of the rollover bit int UltraSetRollover( int voice_num, int state); // toggles the state of the rollover bit for voice // returns the previous state of the rollover bit for voice int UltraToggleRollover( int voice_num); Well, if you give me the first two, I can come up with the third one :-) PRAISE ------ Please take the above comments seriously, but not too harshly. I love my GUS!!! And (as I wrote on my registration card) I bought one primarily because it had such AWESOME support (i.e. SDK) available over the Internet and on BBS's. I know, I get what I pay for, but you (Gravis and FORTE) get what you pay for, too. I haven't charged you anything (would've if I could've) for all the time I spent finding these "quirks" which are affecting (or will affect) countless others developing code for this FANTASTIC sound card. Keep up the good work, Dave David MacMahon Systems Administrator davidm@opl.com ------------------------------ Date: Tue, 15 Jun 93 13:53 EDT From: "Matthew E. Bernold" Subject: Turbo Pascal SDK Message-ID: <9306151752.AA10814@orca.es.com> I made the mistake of posting my first announcement on a Friday night, and I am not sure how many people missed it because of it being delivered on a Saturday, so I'll post one more time. I am currently in the process of making a straight translation of the GUS SDK version 2.01 from C to Turbo Pascal (Version 6). As of right now, I have been able to translate all commands that do not have to do with IRQ and DMA functions, and I want to release an alpha test version of the SDK to a few people. If anyone is interested in helping me test this SDK, please note me by Friday or so, as I should be mailing out the alpha by then. Also, if there is someone who is familiar with programming IRQ or DMA in Turbo Pascal/C, I could use some help with translating some of the more involved functions in the SDK. Thank you, Matthew E. Bernold MEB117@PSUVM.PSU.EDU <> meb@wilbur.cac.psu.edu ------------------------------ End of GUS Programmer's Digest V2 #14 ************************************* To post to tomorrow's digest: To (un)subscribe or get help: To contact a human (last resort): FTP sites: archive.epas.utoronto.ca pub/pc/ultrasound wuarchive.wustl.edu systems/msdos/ultrasound Hints: - Get the FAQ from the FTP sites or the request server. - Mail to for info about other GUS related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)