home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Large Pack of OldSkool DOS MOD Trackers
/
goattracker_2.68.zip
/
src
/
resid-fp
/
envelope.cpp
< prev
next >
Wrap
C/C++ Source or Header
|
2009-01-03
|
10KB
|
255 lines
// ---------------------------------------------------------------------------
// This file is part of reSID, a MOS6581 SID emulator engine.
// Copyright (C) 2004 Dag Lem <resid@nimrod.no>
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program 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 General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
// ---------------------------------------------------------------------------
#define __ENVELOPE_CC__
#include "envelope.h"
// ----------------------------------------------------------------------------
// Constructor.
// ----------------------------------------------------------------------------
EnvelopeGeneratorFP::EnvelopeGeneratorFP()
{
reset();
}
// ----------------------------------------------------------------------------
// SID reset.
// ----------------------------------------------------------------------------
void EnvelopeGeneratorFP::reset()
{
envelope_counter = 0;
attack = 0;
decay = 0;
sustain = 0;
release = 0;
gate = 0;
rate_counter = 0;
exponential_counter = 0;
exponential_counter_period = 1;
state = RELEASE;
rate_period = rate_counter_period[release];
hold_zero = true;
}
// Rate counter periods are calculated from the Envelope Rates table in
// the Programmer's Reference Guide. The rate counter period is the number of
// cycles between each increment of the envelope counter.
// The rates have been verified by sampling ENV3.
//
// The rate counter is a 16 bit register which is incremented each cycle.
// When the counter reaches a specific comparison value, the envelope counter
// is incremented (attack) or decremented (decay/release) and the
// counter is zeroed.
//
// NB! Sampling ENV3 shows that the calculated values are not exact.
// It may seem like most calculated values have been rounded (.5 is rounded
// down) and 1 has beed added to the result. A possible explanation for this
// is that the SID designers have used the calculated values directly
// as rate counter comparison values, not considering a one cycle delay to
// zero the counter. This would yield an actual period of comparison value + 1.
//
// The time of the first envelope count can not be exactly controlled, except
// possibly by resetting the chip. Because of this we cannot do cycle exact
// sampling and must devise another method to calculate the rate counter
// periods.
//
// The exact rate counter periods can be determined e.g. by counting the number
// of cycles from envelope level 1 to envelope level 129, and dividing the
// number of cycles by 128. CIA1 timer A and B in linked mode can perform
// the cycle count. This is the method used to find the rates below.
//
// To avoid the ADSR delay bug, sampling of ENV3 should be done using
// sustain = release = 0. This ensures that the attack state will not lower
// the current rate counter period.
//
// The ENV3 sampling code below yields a maximum timing error of 14 cycles.
// lda #$01
// l1: cmp $d41c
// bne l1
// ...
// lda #$ff
// l2: cmp $d41c
// bne l2
//
// This yields a maximum error for the calculated rate period of 14/128 cycles.
// The described method is thus sufficient for exact calculation of the rate
// periods.
//
reg16 EnvelopeGeneratorFP::rate_counter_period[] = {
9, // 2ms*1.0MHz/256 = 7.81
32, // 8ms*1.0MHz/256 = 31.25
63, // 16ms*1.0MHz/256 = 62.50
95, // 24ms*1.0MHz/256 = 93.75
149, // 38ms*1.0MHz/256 = 148.44
220, // 56ms*1.0MHz/256 = 218.75
267, // 68ms*1.0MHz/256 = 265.63
313, // 80ms*1.0MHz/256 = 312.50
392, // 100ms*1.0MHz/256 = 390.63
977, // 250ms*1.0MHz/256 = 976.56
1954, // 500ms*1.0MHz/256 = 1953.13
3126, // 800ms*1.0MHz/256 = 3125.00
3907, // 1 s*1.0MHz/256 = 3906.25
11720, // 3 s*1.0MHz/256 = 11718.75
19532, // 5 s*1.0MHz/256 = 19531.25
31251 // 8 s*1.0MHz/256 = 31250.00
};
// For decay and release, the clock to the envelope counter is sequentially
// divided by 1, 2, 4, 8, 16, 30, 1 to create a piece-wise linear approximation
// of an exponential. The exponential counter period is loaded at the envelope
// counter values 255, 93, 54, 26, 14, 6, 0. The period can be different for the
// same envelope counter value, depending on whether the envelope has been
// rising (attack -> release) or sinking (decay/release).
//
// Since it is not possible to reset the rate counter (the test bit has no
// influence on the envelope generator whatsoever) a method must be devised to
// do cycle exact sampling of ENV3 to do the investigation. This is possible
// with knowledge of the rate period for A=0, found above.
//
// The CPU can be synchronized with ENV3 by first synchronizing with the rate
// counter by setting A=0 and wait in a carefully timed loop for the envelope
// counter _not_ to change for 9 cycles. We can then wait for a specific value
// of ENV3 with another timed loop to fully synchronize with ENV3.
//
// At the first period when an exponential counter period larger than one
// is used (decay or relase), one extra cycle is spent before the envelope is
// decremented. The envelope output is then delayed one cycle until the state
// is changed to attack. Now one cycle less will be spent before the envelope
// is incremented, and the situation is normalized.
// The delay is probably caused by the comparison with the exponential counter,
// and does not seem to affect the rate counter. This has been verified by
// timing 256 consecutive complete envelopes with A = D = R = 1, S = 0, using
// CIA1 timer A and B in linked mode. If the rate counter is not affected the
// period of each complete envelope is
// (255 + 162*1 + 39*2 + 28*4 + 12*8 + 8*16 + 6*30)*32 = 756*32 = 32352
// which corresponds exactly to the timed value divided by the number of
// complete envelopes.
// NB! This one cycle delay is not modeled.
// From the sustain levels it follows that both the low and high 4 bits of the
// envelope counter are compared to the 4-bit sustain value.
// This has been verified by sampling ENV3.
//
reg8 EnvelopeGeneratorFP::sustain_level[] = {
0x00,
0x11,
0x22,
0x33,
0x44,
0x55,
0x66,
0x77,
0x88,
0x99,
0xaa,
0xbb,
0xcc,
0xdd,
0xee,
0xff,
};
// ----------------------------------------------------------------------------
// Register functions.
// ----------------------------------------------------------------------------
void EnvelopeGeneratorFP::writeCONTROL_REG(reg8 control)
{
reg8 gate_next = control & 0x01;
// The rate counter is never reset, thus there will be a delay before the
// envelope counter starts counting up (attack) or down (release).
// Gate bit on: Start attack, decay, sustain.
if (!gate && gate_next) {
state = ATTACK;
update_rate_period(rate_counter_period[attack]);
// Switching to attack state unlocks the zero freeze.
hold_zero = false;
}
// Gate bit off: Start release.
else if (gate && !gate_next) {
state = RELEASE;
update_rate_period(rate_counter_period[release]);
}
gate = gate_next;
}
void EnvelopeGeneratorFP::writeATTACK_DECAY(reg8 attack_decay)
{
attack = (attack_decay >> 4) & 0x0f;
decay = attack_decay & 0x0f;
if (state == ATTACK) {
update_rate_period(rate_counter_period[attack]);
}
else if (state == DECAY_SUSTAIN) {
update_rate_period(rate_counter_period[decay]);
}
}
void EnvelopeGeneratorFP::writeSUSTAIN_RELEASE(reg8 sustain_release)
{
sustain = (sustain_release >> 4) & 0x0f;
release = sustain_release & 0x0f;
if (state == RELEASE) {
update_rate_period(rate_counter_period[release]);
}
}
reg8 EnvelopeGeneratorFP::readENV()
{
return output();
}
void EnvelopeGeneratorFP::update_rate_period(reg16 newperiod)
{
rate_period = newperiod;
/* The ADSR counter is XOR shift register with 0x7fff unique values.
* If the rate_period is adjusted to a value already seen in this cycle,
* the register will wrap around. This is known as the ADSR delay bug.
*
* To simplify the hot path calculation, we simulate this through observing
* that we add the 0x7fff cycle delay by changing the rate_counter variable
* directly. This takes care of the 99 % common case. However, playroutine
* could make multiple consequtive rate_period adjustments, in which case we
* need to cancel the previous adjustment. */
/* if the new period exeecds 0x7fff, we need to wrap */
if (rate_period - rate_counter > 0x7fff)
rate_counter += 0x7fff;
/* simulate 0x7fff wraparound, if the period-to-be-written
* is less than the current value. */
if (rate_period <= rate_counter)
rate_counter -= 0x7fff;
/* at this point it should be impossible for
* rate_counter >= rate_period. If it is, there is a bug... */
}