AOH :: GTEK8.TXT

Advanced Gravis tech Note #8



TITLE:      Advanced Gravis Tech Note #8
AREA:       GUS MEMORY
DATE:       January 22, 1993
KEY WORDS:  GUS MEMORY BUFFER DMA PLAYFILE PLAYMIDI SBOS

SUBJECT: General Information on how GUS uses its memory

The memory on GUS is used as a sound data buffer.  The usage of this buffer
is determined by the GUS application

Example #1.  The application PLAYFILE.EXE uses about 128k of GUS RAM.
When a .SND file is played, PLAYFILE.EXE sets up a buffer in main memory
where the audio data copied from the HD is placed.  The data is then
transfered by DMA to a 64k buffer, which we'll call buffer A, in GUS's
memory.  After GUS is told to play, PLAYFILE proceeds to fetch, from
the HD, the next 64k chunk of data and places it in a second 64k buffer
(buffer B) after buffer A.  An interrupt (IRQ) is generated when GUS has
"played" the first 64k chunk (buffer A) while continuing to "play" into
buffer B.  This IRQ signals PLAYFILE to reload buffer A.  After GUS has
played buffer B, it generates an IRQ and loops back to start playing at
the beginning of buffer A which has been reloaded with new data while it
was playing buffer B.  The "loopback" IRQ signals PLAYFILE that buffer B
can now be reloaded and the cycle repeats.  The FLIDEMO uses this technique.

An application is not limited to a 64k buffer.  In theory, an application
could use the maximum current configuration of 1 meg and control two
or more GUS boards!  The limitations are HD access and CPU speed.

Example #2, The current version of SBOS uses 256k bytes of GUS RAM.  SBOS
fills this ram with small pieces of sound data and plays them as
instructed by the SB/Adlib application.  The sound data is not replaced or
swapped by SBOS, as in the above example.  Unlike the above example no
further HD access is required once the RAM is loaded.  SBOS currently needs
no more than the stock 256k bytes of RAM.

Example #3, PLAYMIDI.EXE will attempt to use as much RAM as it needs for
wave-table data, called patches.  The amount of memory required is
dependent on what the composition requires for its patches.  The current
MIDIDEMO demonstrates the compositions possible with 256k of available RAM.
More complex compositions are possible with more available RAM.  The more
instruments in a composition, the more RAM required to hold the patches.
Patch sizes are determined by the type and quality of the instrument
patch.



The entire AOH site is optimized to look best in Firefox® 2.0 on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2008 AOH
We do not send spam. If you have received spam bearing an artofhacking.com email address, please forward it with full headers to abuse@artofhacking.com.