From: ptran@sciborg.uwaterloo.ca (Phat H Tran)
Subject: Re: Curiosity about what low-level things GUS can do
Organization: University of Waterloo
Date: Thu, 7 Jan 1993 05:10:45 GMT

In article <1993Jan6.173829.1755@nntpd.lkg.dec.com> fisher@decwin.enet.dec.com () writes:
>
>In article <C0ExAM.4vK@watserv2.uwaterloo.ca>, ptran@sciborg.uwaterloo.ca
>(Phat H Tran) writes:
>|>
>|>In article <1993Jan5.160120.21526@nntpd.lkg.dec.com>
>|>fisher@decwin.enet.dec.com () writes:
>|>>
>|>>Some questions about how GUS works.  If anyone can legally answer, I'd 
>|>>appreciate it.
>|>>
>|>
>|>I'll try to answer your questions to the best of my knowledge and let
>|>others correct me and/or fill in the blanks where they can.  I don't
>|>have the SDK, and hence, am not bound by any non-disclosure agreements,
>|>so yes, what I'm doing is legal. :)
>
>So how did you find out?  Just by poking and hacking, or is there a better way
>that the rest of us can use?
>

I'm learning about the GUS largely from reading this group, asking 
programmers such as Josh Jensen, and browsing the register docs that Josh
and Tran wrote.  I also do a bit of experimenting on the side, but I'm not
an adept hacker, at least as far as PCs are concerned.  But you should see
me on my old C64! :)

>|>The GUS's processor is not programmable.  It has a fixed set of commands
>|>that must be issued by the CPU.  That is, you cannot upload a program to
>|>it and have it execute the sequence of instructions on its own.  However,
>|>the card's hardwired commands and functions are quite powerful, it would
>|>seem.
>|>
>
>Anyone remember vector processing displays like the DEC GT40?  (Showing my age,
>I guess).  I was imagining the CPU command to the GUS being sort of like
>"execute this display list" where the display list was really mostly a bunch
>of samples with a couple little flag words to say loop back.  But anyway...
>

I don't think the GUS can buffer and process command lists.  

>Can you give any clue as to what commands are available?  I would still think
>that, for example, you would have to be able to have a "loop back" command in
>the patch itself, and not have to have the CPU take an interrupt at the end
>of the sample and command the GUS back to the beginning.  It also must be
>capable of some sort of multiprocessing in the sense that it has to be able
>to play back 32 streams of samples pseudo-simultaneously, presumably by doing
>some sort of DSP to mix them. 
>

To program the GUS at the lowest level, you basically "pull its strings"
via its registers.  You have to set up each voice so that it knows:
  - where to find the patch in memory
  - the playback frequency
  - where to begin looping
  - its pan position
  - its volume
  - the decay parameter(s)
  - etc.
Once the voice is set up, you can tell it to start playing by storing the
right instruction into its command register.  Things such as looping
are all handled in hardware, I believe.  The voice won't have to trigger
an interrupt and have the CPU reconfigure it for the looping portion of
the note, for example.  If that's the case, I'd imagine that the
sound quality would be quite sloppy, especially when the CPU has to
handle interrupts from 32 possible voices.  But the card sounds very
nice.  Please, anybody, correct me where I'm wrong.  I am hardly sure
of myself.

For more information, refer to the "Ultradox" (low-level register 
information) found on epas (128.100.160.36).  Though Tran and Jensen
weren't able to decipher everything, they've done an admirable job
figuring out the basics of the hardware.  I've asked Gravis why they
themselves don't release low-level docs, and they said that there
are things that Forte (co-designers of the GUS) don't feel comfortable
divulging.

Phat.
Newsgroups: comp.sys.ibm.pc.soundcard