1
TIASOUND.C - TIA SOUND EMULATION V1.0
2
=====================================
4
As I'm sure you've already discovered, the Stella manual isn't always
5
correct. My observations show what I believe to be several discrepancies
6
in the description of the distortions. Of course, I could be wrong on a few
7
of these, so if some of the games don't sound right, please let me know
8
which ones. If possible, it would be best if you could send me a wave file
9
of what it is supposed to sound like, preferably at 44 KHz. Only a few
10
seconds should be necessary.
20
In general, the sound hardware can be described as follows:
23
Selecting the Clock Modifier - Bits D0 and D1
24
---------------------------------------------
26
Bits D0 and D1 select the output clock modifier:
30
0 0 - direct clock (pure)
31
0 1 - direct clock (pure)
33
1 1 - 5-bit polynomial
35
The 'divide by 31' isn't simply the input clock divided by 31. It is, in
36
essence, a 5-bit polynomial with only two bits set. The resulting square
37
wave actually has a 13:18 ratio. This may be implemented in the hardware
38
as a pair of traps on a 5-bit counter.
41
Selecting the Source Pattern - Bits D2 and D3
42
---------------------------------------------
44
Bits D2 and D3 select the source to be clocked:
48
0 0 - 4-bit polynomial
50
1 0 - 5-bit polynomial
53
The 'pure' tones are generated by toggling the output. Whenever a clock
54
tick is received, the output will change states. I've used the notation Q'
55
to indicate the 'logical NOT of the last output'. Note that since the output
56
toggles, this can be thought of as a divide by 2 since the output frequency
57
will be half of the input frequency. This is only true for the pure tones.
60
Selecting the Source Clock - Bits D2 and D3
61
-------------------------------------------
63
When bits D2 and D3 are both set, it affects the source clock. I believe
64
the '30KHz' clock is actually the 3.58MHz clock divided by 114. When bits
65
D2 and D3 are set, the input source is switched to the 1.19MHz clock, so the
66
'30KHz' source clock is reduced to approximately 10KHz.
69
Exceptions - Selecting No Output or the 9-bit Polynomial
70
--------------------------------------------------------
72
There are two exceptions that occur when bits D0-D2 are all 0. If AUDC is
73
zero (0000), then I believe the output is set equal to the volume. If AUDC is
74
equal to 8 (1000), the 9-bit polynomial is selected as the source to be
78
Updated Detailed Functions for AUDC
79
-----------------------------------
81
From my observations, I would describe the distortion selections as follows:
83
HEX D3 D2 D1 D0 Clock Source Clock Modifier Source Pattern
84
--- ------------- -------------- ---------------- ----------------
85
0 0 0 0 0 3.58 MHz/114 -> none (pure) -> none
86
1 0 0 0 1 3.58 MHz/114 -> none (pure) -> 4-bit poly
87
2 0 0 1 0 3.58 MHz/114 -> divide by 31 -> 4-bit poly
88
3 0 0 1 1 3.58 MHz/114 -> 5-bit poly -> 4-bit poly
89
4 0 1 0 0 3.58 MHz/114 -> none (pure) -> pure (~Q)
90
5 0 1 0 1 3.58 MHz/114 -> none (pure) -> pure (~Q)
91
6 0 1 1 0 3.58 MHz/114 -> divide by 31 -> pure (~Q)
92
7 0 1 1 1 3.58 MHz/114 -> 5-bit poly -> pure (~Q)
93
8 1 0 0 0 3.58 MHz/114 -> none (pure) -> 9-bit poly
94
9 1 0 0 1 3.58 MHz/114 -> none (pure) -> 5-bit poly
95
A 1 0 1 0 3.58 MHz/114 -> divide by 31 -> 5-bit poly
96
B 1 0 1 1 3.58 MHz/114 -> 5-bit poly -> 5-bit poly
97
C 1 1 0 0 1.19 MHz/114 -> none (pure) -> pure (~Q)
98
D 1 1 0 1 1.19 MHz/114 -> none (pure) -> pure (~Q)
99
E 1 1 1 0 1.19 MHz/114 -> divide by 31 -> pure (~Q)
100
F 1 1 1 1 1.19 MHz/114 -> 5-bit poly -> pure (~Q)
102
For the most part, this follows the Stella manual, but there are a few
103
differences. Probably the most notable are hex entries 'A' and 'B', which
104
are listed in the Stella manual as 'div 31: pure tone' and 'set last 4 bits
107
On entries 'A' and 'B', both the data source and the clock have the same
108
number of entries (31). Because of this, they will always align in the
109
same way. Entry 'A' will then reduce to a pure 'div by 31' output which
110
is identical to entry '6'. On 'B', both the source and the clock align
111
in such a way that the output will always be 1.
118
The 4-bit, 5-bit, and 9-bit polynomials are essentially tables containing
119
a random series of bits (they are implemented in hardware as shift
120
registers). Because the tables are fixed in length, the 'random' pattern
121
will repeat periodically.
123
The size of the table is described by its name. The actual size of the
124
table is 2^x - 1, where x is either the 4, 5 or 9. The 4-bit polynomial
125
has 15 entries, the 5-bit polynomial has 31 entries, and the 9-bit
126
polynomial has 511 entries.
128
I've performed some analysis on the output of the actual Atari 2600, and
129
believe I have the actual 4-bit and 5-bit polynomials used by the Atari.
130
These have been encoded as byte arrays in my routines. For the 9-bit
131
polynomial, I use a random number generator which should produce
132
approximately the same results.
138
I believe the input clock for the audio is a division of the main system
139
clock. With this assumption, I determined that the input clock for the
140
audio is equal to the 3.58MHz system clock divided by 114. Note that this
141
produces an actual audio clock of 31.4 KHz. This value closely matches the
142
frequencies I recorded from my unit. The Stella manual describes the Audio
143
Clock as approximately 30KHz, which I suppose is correct if you consider 5%
146
If both bits D2 and D3 of the AUDC register are set, I believe the TIA chip
147
uses the 1.19MHz clock for the base audio clock instead of the 3.58MHz.
148
This, of course, produces the 'divide by 3' functionality described in the
156
The TIASOUND.C file is the heart of the TIA Sound Emulation program.
157
Although the routines in the file must work together, no other files are
158
modules are required for operation. A header file, 'TIASOUND.H', has
159
been included for use in other modules, and provides the necessary
160
function prototypes. I've attempted to make the routines as portable as
161
possible, so the file should compile on almost any compiler with little
164
I have made some attempts at optimizing the routines, though I am sure
165
more optimization can be done. They are currently only available in 'C'.
166
I'll be happy to convert them to assembly language if desired. Please feel
167
free to send me e-mail (see below).
169
The routines are easy to use. Detailed descriptions on the function calls
176
On start-up of the system, a single call should be made to Tia_sound_init.
177
This routine will prepare the structures for sound output. This routine
178
can be called again if necessary during warm-start or other reset.
180
Once in the main loop, there are two other functions that will be used.
181
Whenever the system needs to write to either the AUDC, AUDV or AUDF values,
182
a call should be made to the Update_tia_sound routine. This routine will
183
take care of updating the internal registers. It will pre-calculate several
184
values to help with optimization.
186
The only other routine that is called is the Tia_process function. This
187
function will fill a audio buffer with a specified number of bytes. This
188
function should be called whenever a new audio buffer is required.
190
For best results, I recommend using at least two output buffers. Using this
191
scheme, the sound card can be playing one buffer while the system is filling
195
DETAILED FUNCTION DESCRIPTIONS
196
------------------------------
198
Tia_sound_init(uint16 sample_freq, uint16 playback_freq)
199
--------------------------------------------------------
201
This function initializes the structures used by the TiaSound.C routines.
202
This function takes two parameters: the sample frequency and the playback
203
frequency. The sample frequency is the frequency of the 30KHz source clock.
204
For my calculations, this clock is about 31.4 KHz, though any 16-bit
205
unsigned integer value can be used (1-65535).
207
The playback frequency is the frequency of the sound playback (the frequency
208
used by the sound card). For best results, both the playback frequency and
209
the sample frequency should be identical. In the case where the sound card
210
cannot support 31.4 KHz (i.e. the original SB and many 'SB compatible' cards),
211
there are three options:
213
1) Set the sample frequency to 31400 and the playback frequency to the
214
maximum possible (e.g. 22050). Though the system will reproduce all
215
output values, a significant amount of aliasing is introduced.
217
2) Set the sample frequency and the playback frequency to the maximum possible
218
(e.g. 22050). In this case, all output values are reproduced with no
219
distortions; however, the pitch is about 2/3 of an octave low.
221
3) Set the sample frequency to 31400 and the playback frequency to exactly
222
1/2 of the sample frequency (15700). In this case, the output frequency
223
is correct and the aliasing is minimized. The aliasing is only
224
noticeable on the higher frequencies. Most notably, the highest pure tone
225
(AUDF = 0) is inaudible.
227
Feel free to experiment to find other alternatives as well.
229
This function has no return value (void).
232
Update_tia_sound (uint16 addr, uint8 val)
233
-----------------------------------------
235
This function should be called each time an AUDC, AUDF or AUDV value
236
changes. This function takes two parameters: the address to change and
237
the new value. The address should be one of the following values:
248
Any values outside of this range will be ignored.
250
The routine pre-calculates several values that are needed by the
251
processing function. This is done to optimize performance.
253
This function has no return value (void).
256
Tia_process (unsigned char *buffer, uint16 n)
257
---------------------------------------------
259
This function calculates and fills a buffer with unsigned 8-bit mono audio.
260
This function takes two parameters: a pointer to the buffer to fill and
261
the size of the buffer (limited to 65535). This function fills the
262
buffer based on the requested size and returns. It automatically
263
updates the pointers for the next call, so subsequent calls to this function
264
will provide a continuous stream of data.
266
The size of the buffer that is needed depends on the playback frequency.
267
It is best to keep the buffer as small as possible to maximize response time
268
to changes in the sound. Of course, the minimum size is dependent on
269
system and emulator performance.
271
Selecting the correct buffer size is a careful balance. Selecting a buffer
272
size that is too small will produce noticeable clicks in the output, though
273
selecting a size that is too large will cause a poor response time and
274
possible delays in the system when the new buffer is filled.
276
This function has no return value (void).
279
License Information and Copyright Notice
280
========================================
282
TiaSound is Copyright(c) 1996 by Ron Fries
284
This library is free software; you can redistribute it and/or modify it under
285
the terms of version 2 of the GNU Library General Public License as published
286
by the Free Software Foundation.
288
This library is distributed in the hope that it will be useful, but WITHOUT
289
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
290
FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more
293
To obtain a copy of the GNU Library General Public License, write to the Free
294
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
296
Any permitted reproduction of these routines, in whole or in part, must bear
added
removed
src/ui/sound/TIASound.txt
