Pokey
Pokey
0
==============================
by Ron Fries
31 Jan 97
New Features:
-------------
Standard Features:
------------------
The 'PokeySound' emulator does not currently support the following functions:
Though I don't believe adding support for the High-Pass filters is very
complicated, I decided not to add support right now because I don't
believe this feature is used much. I'm also not sure how much impact it
would have on performance. Let me know if you find an application that
uses it.
In the 2.0 release, I've removed the non-optimized vrersion. It was only
left in for reference. If you would still like to see the non-optimized
version, it's available in the 1.2 release.
One of the unique features of the emulator is that the processing time varies
based on the frequency. Since the routine only calculates new output values
when a change is sensed, the lower frequencies (which change less frequently)
will require less processing time.
The biggest difference between the emulator and the original hardware is
that the emulator emulates an 'ideal' POKEY chip. All output from the
emulator is a based on a precise square wave, whereas the output from the
original chip has decay. Though the output is slightly different, I
don't believe this difference is easily discernible.
There are also a few differences which are introduced by aliasing. This is
a direct result of using an output sampling rate which is not identical to
the original sound rate. It is most evident with high frequencies.
Sample/Test Application:
------------------------
The test program I've distributed is a 16-bit DOS application created with
the Borland 'C' compiler. The only reason I used 16-bit was because I
already had a set of working SB drivers in 16-bit. Since the test system
is dedicated to generating sounds, the performance in 16-bit is more than
adequate.
POKEY.C
=======
The routines are easy to use. Detailed descriptions on the function calls
are listed below.
GENERAL OVERVIEW
----------------
Once in the main loop, there are two other functions that will be used.
Whenever the system needs to write to either the AUDC or AUDF values,
a call should be made to the Update_pokey_sound routine. This routine will
take care of updating the internal registers. It will pre-calculate several
values to help with optimization.
The only other routine that is called is the Pokey_process function. This
function will fill a audio buffer with a specified number of bytes. This
function should be called whenever a new audio buffer is required.
For best results, I recommend using at least two output buffers. Using this
scheme, the sound card can be playing one buffer while the system is filling
the other.
The main clock frequency is the frequency of the 1.79MHz source clock.
To provide exact results, freq17 should be set equal to 1789790 Hz. As an
alternative, freq17 can be set to an approximate frequency of 1787520 Hz.
Using this approximate frequency will reduce aliasing and thus produce a
clearer output signal.
A constant has been defined for both of these values for your convenience.
The names are FREQ_17_EXACT and FREQ_17_APPROX.
The playback frequency is the frequency of the sound playback (the frequency
used by the sound card). For best results, the playback frequency should
be an even division of the main clock frequency. Since most of the sounds
will be generated using the 64kHz clock, I also recommend making the
playback frequency an even division of the 64kHz clock.
The 64kHz clock is exactly equal to the main clock divided by 28. For
the playback frequency, I recommend one of the following values:
Of course, these options also assume you are using the approximate
frequency for the main clock as well. Any of these choices will offer the
best results when the main 64kHz clock is used, reasonable results when the
15kHz clock is selected, and marginal results when the 1.79MHz clock is
selected (the only way to produce good results in all cases is to set the
playback frequency to 1.79MHz!)
This function should be called each time an AUDC, AUDF or AUDCTL value
changes. This function takes four parameters: the address to change,
the new value, the chip to be updated, and the gain to be used.
The lower four bits of the address should be one of the following values:
Addr Description
------ -----------
0x00 AUDF1
0x01 AUDC1
0x02 AUDF2
0x03 AUDC2
0x04 AUDF3
0x05 AUDC3
0x06 AUDF4
0x07 AUDC4
0x08 AUDCTL
In order to support multiple POKEY chips, only the lower four bits of
the address are used. Note that this routine can no longer be called with
any address as it will affect the operation of the specified chip.
The best value for the gain depends on the number of POKEYs emulated and
the maximum volume used. The maximum possible output for each channel is 15,
making the maximum possible output for a single chip to be 60. Assuming all
four channels on the chip are used at full volume, a gain of 64 can be used
without distortion. If 4 POKEY chips are emulated and all 16 channels are
used at full volume, the gain must be no more than 16 to prevent distortion.
Of course, if only a few of the 16 channels are used or not all channels are
used at full volume, a larger gain can be used.
To enable clipping, define the logical CLIP before compiling. This is the
default mode of operation as it has already been included in the POKEY.H file.
Note that this is only recommended if clipping is necessary since it will
impact the performance.
This function calculates and fills a buffer with unsigned 8-bit mono audio.
This function takes two parameters: a pointer to the buffer to fill and
the size of the buffer (limited to 65535). This function fills the
buffer based on the requested size and returns. It automatically
updates the pointers for the next call, so subsequent calls to this function
will provide a continuous stream of data.
The size of the buffer that is needed depends on the playback frequency.
It is best to keep the buffer as small as possible to maximize response time
to changes in the sound. Of course, the minimum size is dependent on
system and emulator performance.
This library is free software; you can redistribute it and/or modify it under
the terms of version 2 of the GNU Library General Public License as published
by the Free Software Foundation.
This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more
details.
To obtain a copy of the GNU Library General Public License, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.