Apparently-To: john.smith@gravis.com GUS Programmer's Digest Wed, 6 Oct 93 007 MDT Volume 5: Issue 5 Today's Topics: Recording with the GUS Timer stuff (retry) 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, 5 Oct 93 10:03:10 EST From: support@fortech.com (Technical Support) Subject: Recording with the GUS Message-ID: <9310051003.0.UUL1.3#16204@fortech.com> Hi folks, There have been several posts recently regarding 'anomolies' in the samples when recording with the GUS. I am not going to get into analysis of the numbers because the actual numbers are not really important. It is important to understand what it going on so your software can be made to work as well as possible. 1) Its true that the GUS will NOT automatically restart after it has triggered a DMA TC. The software must re-enable the xfer. (reg $49, bit 0). This means that the software should put priority on restarting the xfer before doing anything else. Obviously, don't run with IRQs off for very long either. Putting the PC DMA controller in auto-init mode will help because you will not need to re-program it after each buffer, you'll just have to re-start the GUS. 2) There probably will be a small amount of 'jitter' in the sample that is take immediately after the GUS is re-started. I have no doubt that the counter will be skewed by the amount of time that it takes your software to clear the condition. This is one of the main reasons to hit it as soon after the IRQ as possible. There is nothing that can be done about the jitter, but the effect will be impossible to notice if your buffers are of a reasonable size. (32 bytes is NOT a resonable size...) 32K (or even 4K) would be sufficient.... 3) Use autoinit on the PC DMA controller. This means that your buffer MUST reside completely within 1 64K page. This can easily be gaurenteed with a little software to figure out where the buffer sits in a linear address space (non- segment/offset). 4) The sample rate register ($48) is only 8 bits. That means that there is only 255 different possible sample sample rates. Obviously, that means that not all the freqencies are going to be exact. The formula (CLK/(16*rate+2)) will give you the value needed to get the APPROXIMATE frequency you requested. (CLK=9.878MHz). Here a few examples. ADSR ($48) Rate ----------------- 0-12 44.1KHZ (rates over 44.1 are forced to 44.1) 26 22.050 Khz 54 11.025 Khz 255 2.402 Khz (slowest possible) Note that the 'popular' frequencies are exact. Any others will be close enough. 5) The 16-bit daughter card and UltraMax will not have these problems. They use a Crystal codec to do the recording (and playback in some cases...) An SDK for them will be available sometime. (Soon I think) Subject #2 ======================================================================= > >Gravis/Forte technical support, talk to us! We're busy drumming up > >software support for your products. The least you could do is help > >us out. > Ditto! I wonder if they give game developers the same level of support they > give to programmers over internet/Gravis nodes/sdk-digest. That would > explain why native GUS support is taking so long to appear in games. I know > they say "you get what you pay for", but do game developers pay for support > or SDK's? I hope not, that would be another reason native GUS support is > taking so long. Game developers probably get free hardware, SDK's, AND > support. Do Gravis/Forte have a developer program? If so, what does it > take to get on it (besides being a million dollar software company)? Sorry > to flame so badly here, but lately it seems that Gravis/Forte is *getting* > alot more support from the internet community than they are *giving*. Developer support chews up a MAJORITY of our time. Like it or not, that IS what is most important. Its nice to have support from people on the net (and there is a LOT of it, and we REALLY appreciate it ....) but it is much more important that companies like SIERRA, SSI, ID etc come out with new games that have direct support. That is what sells cards. NOBODY pays for developer support. Gravis/Forte do not charge anybody for any of the support they recieve. The SDK is free, phone support is free, custom software is free, we look over somebody else software to see where the problems are, etc. All this takes a LOT of time and effort. That is also why some things don't get out as fast we would like. (Daughter card, OS/2, news SDK etc ....) Subject #3 ========== There are various things I have seen posted that I would like to clear up. Some of this has bee thru the news, some thru the digest and some thru the devel account. 1) Ultrajoy 0 will disable the joystick on rev 3.4 boards or later. There is no jumper on these boards to disable it. Its a software latch. The new Ultrajoy (I think in the 2.06 releases) will do this. It has not effect on pre-3.4 boards. 2) Register 15 ($2XF) For all practical purposes, you won't have to deal with this register. It is a register select for $2XB on rev 3.4 and later boards. There are 6 register currently associated with $2XB. Only 2 are actively used. 1-4 are reserved. 5 is to clear out any pending IRQ's and only needs to be done at power up time. Ultrinit does it. Its also done in the SDK in case ultrinit was not run. Register 6 is used to enable and disable the joystick. This is done by the new Ultrinit (not released yet) and Ultrajoy (on 2.06 and up disks) Hope some of this info is helpful. I'll try and respond to questions sooner next time. Mike ------------------------------ Date: Tue, 5 Oct 93 06:19:13 PDT From: deraud@power.amasd.anatcp.rockwell.com (Robert Lee DeRaud) Subject: Timer stuff (retry) Message-ID: <9310051319.AA04951@power.amasd.anatcp.rockwell.com> The BrainDead Mailer (tm) strikes again...my post from yesterday got truncated, so I'll try to recreate it. >From: Tom_Klok@mindlink.bc.ca (Tom Klok) >Subject: Re: How to avoid a recording pitfall (long ramblings) [much interesting stuff deleted...no, I mean REALLY deleted: I can't find the file with the original post :-( ] [question concerning possibility of using PC timers for GUS] My humble contribution - An outfit called Ryle Design markets a package called PCHRT (PC High-resolution Timer), AKA PC Timer Tools. It provides microsecond resolution timing functions by reprogramming the timer chip, interuupt vectors, and such, and unlike some games, does NOT bugger up the normal clock in the process. They have little-bitty ads in the back of Dr. Dobbs, C Users' Journal, etc. The version I have is ancient (1990 or so), but I think the current price is about $90 US; includes source code in C and assembler. (I think Austin Code Works amy have it also, maybe at a discount.) *********************************************************************** Lee DeRaud Will program Windows for food. Rockwell Int. AESD (Hey, I'm easy but I'm not cheap!) DoD #985 - Fast and ugly beats slow and cute any day of the week. ---------------------------------------------------------------------- My own opinions only, not those of Rockwell International. (Yeah, right: like anyone around here cares what *I* say...NOT!) *********************************************************************** ------------------------------ End of GUS Programmer's Digest V5 #5 ************************************ 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.)