im having problems with triangle channel in some games. One example is Circus Charlie in "pause" state. The channel keep making noise. I have revised and re-revised the code and it seems its ok. The only thing i can observe is that when it is in "pause" it sets the p. timer of all channels to "0" wich nearly inmediate clocks the step generator (the Linear counter and Lenght Counter are no zero both, so step generator is clocked).
It writes all (3) channel registers clearing control flag and writing 0x400B setting the Halt flag.
triangle channel problems: blargg are you there?
Moderator: Moderators
When I pause that game it writes 0 to $4015 to silence all channels. This write clears and keeps clear the length counters for the first four channels, and when a channel's length counter is 0, it is silent.
I think some of the Mega Man games set the triangle's period to 0 to silence it. When the period is sufficiently low, the frequency is so high that it's inaudible. The square channels also go silent when their period is 7 or less.
If you'd give a clearer description of the problem, I could offer more direct ideas. Describe the exact situation and what your emulator does that you consider wrong.
I think some of the Mega Man games set the triangle's period to 0 to silence it. When the period is sufficiently low, the frequency is so high that it's inaudible. The square channels also go silent when their period is 7 or less.
If you'd give a clearer description of the problem, I could offer more direct ideas. Describe the exact situation and what your emulator does that you consider wrong.
i think i know now where is the problem.
Its in the programmable timer.
Im doing the following:
im sampling at 81 cpu cc per sample. This is more or less 1789772.5 / 22050. Im using 22Khz.
I was using a method that maybe was not correct at all for emulating th ptiimer behavor:
Vars:
cPTimer is the counter itself
nPtimer is the 11 bit value loaded trough $400A and $400B (this is done when these registers are written)
i changed that so i have a func that calls ClockInPTimer(int nChannel);
where nChannel is the channel i want to clock the p timer.
The second method is better, more accurate and i only can hear a very high frequency but i still hear it .
Do you know what can be wrong?
Its in the programmable timer.
Im doing the following:
im sampling at 81 cpu cc per sample. This is more or less 1789772.5 / 22050. Im using 22Khz.
I was using a method that maybe was not correct at all for emulating th ptiimer behavor:
Vars:
cPTimer is the counter itself
nPtimer is the 11 bit value loaded trough $400A and $400B (this is done when these registers are written)
Code: Select all
ClockInPtimer(int cpuCycles)
{
cPtimer -= cpuCycles
if (cPtimer <= 0)
{
cPtimer += nPtimer + 1;
ClockInStepGenerator();
}
where nChannel is the channel i want to clock the p timer.
Code: Select all
//first function: these calls the ClockInPTimer;
ClockPTimers(int cpuCycles)
{
int i;
for (i =0; i < Cycles; i++)
{
ClockInPtimer(0); //SQUARE 1
ClockInPtimer(1); //SQUARE 2
ClockInPtimer(2); //TRIANGLE
ClockInPtimer(3); //NOISE
}
}
//second function (wich is called by ClockPTimers())
ClockInPTimer(int nChannel)
{
if (cPtimer == 0)
{
cPtimer = nPtimer + 1;
swich (nChannel)
{
case 0: case 1: ClockInDutyCycle(nChannel) break; //SQUARES
case 2: ClockInStepGenerator(); //TRIANGLE
case 3: ClockInRandomGenerator(); //NOISE
}
else // is it convinient to put this else here?
cPtimer--;
}
Do you know what can be wrong?
ANes
If it is setting the triangle channel's period to an "impossibly" low number (less than about 7), and you're hearing spurious high frequencies, then odds are you're hearing aliasing. To make aliasing less apparent you need to oversample and filter the audio signal. For a first approximation, try sampling every 27 cycles and averaging each three samples.
It's much simpler to just treat triangle frequencies above 20kHz as silent (or more correctly, as 50% amplitude, i.e. send 7.5 to the DAC). With the low 3 bits of $400B set to 0, these low values for $400A yield the following frequencies:
0 55.9 kHz
1 28.0 kHz
2 18.6 kHz
3 14.0 kHz
...
You could treat the first two or three entries as being inaudible, depending on how good your hearing is.
0 55.9 kHz
1 28.0 kHz
2 18.6 kHz
3 14.0 kHz
...
You could treat the first two or three entries as being inaudible, depending on how good your hearing is.