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:               <gus-sdk%itchy@dsd.es.com>
To (un)subscribe or get help:       <gus-sdk-request%itchy@dsd.es.com>
To contact a human (last resort):     <gus-sdk-owner%itchy@dsd.es.com>

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 <gus-sdk-request%itchy@dsd.es.com> for info about
	other GUS related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)



