bsnes/higan/pce/psg/channel.cpp

30 lines
629 B
C++
Raw Normal View History

auto PSG::Channel::power(uint id) -> void {
this->id = id;
Update to v102r05 release. byuu says: Changelog: - higan: added Makefile option, `build=(release|debug|instrument|optimize)` , defaults to release - PCE: added preliminary PSG (sound) emulation The Makefile thing is just to make it easier to build debug releases without having to hand-edit the Makefile. Just say "gmake build=debug" and you'll get -g, otherwise you'll get -O3 -s. I'll probably start adding these build= blocks to my other projects. Or maybe I'll put it into nall, in which case release will need a different name ... a stable -01, and a fast -03 mode. I also want to add a mode to generate profiling information (via gprof.) Unfortunately, the existing documentation on the PCE's PSG is as barebones as humanly possible. Right now, I support waveform mode, direct D/A mode, and noise generation mode. However for noise, I'm not actually generating a proper square wave, and I don't know the PRNG algorithm used for choosing the random values. So for now, I'm just feeding in nall::random() values to it. I'm also not sure about the noise mode's frequency counter. Magic Kit is implying it's 64*~frequency, but that results in an 11-bit period. It seems only logical that we'd want a 12-bit period. So my guess is that it's actually 12-bit, and halfway through it alternates between two randomly generated values every 32 samples, and the two values are generated every time the period hits zero. Next up, it's not clear when the period counter is reloaded, either for the waveform or the noise mode. So for now, when enabling the channel, I reload the waveform period. And when enabling noise mode, I reload the noise period. I don't know if you need to do it when writing to the frequency registers or not. Next, it's not clear whether the period is a decrement-and-compare, or a compare-and-decrement, and whether we reload with frequency, frequency-1, or frequency+1. There's this cryptic note in pcetext.txt: > The PSG channel frequency is 12 bits, $001 is the highest frequency, > $FFF is the next to lowest frequency, and $000 is the lowest frequency. As best I can tell, he's trying to say that it's decrement-and-compare. Whatever the case, there's periodic popping noises every few seconds. I thought it might be because this is the first system with a fractional sampling rate (~3.57MHz), but rounding the frequency to a whole number doesn't help at all, and emulator/audio should be able to handle fractional resampling rates anyway. The popping noises could also be due to PSG writes being cycle-timed, and my HuC6280 cycle timings not being very great yet. The PSG has no kind of interrupts, so I think careful timing is the only way to do certain things, especially D/A mode. Next up, I really don't understand the frequency modulation mode at all. I don't have any idea whatsoever how to support that. It also has a frequency value that we'll need to understand how the period works and reloads. Basic idea though is the channel 1 output turns into a value to modulate channel 0's frequency by, and channel 1's output gets muted. Next up, I don't know how the volume controls work at all. There's a master volume left+right, per-channel volume left+right, and per-channel overall volume. The documentation lists their effects in terms of decibels. I have no fucking clue how to turn decibels into multiply-by values. Let alone how to stack THREE levels of audio volume controls >_> Next, it looks like the output is always 5-bit unsigned per-channel, but there's also all the volume adjustments. So I don't know the final bit-depth of the final output to normalize the value into a signed floating point value between -1.0 and +1.0. So for now, half the potential speaker range (anything below zero) isn't used in the generated output. As bad as all this sounds, and it is indeed bad ... the audio's about ~75% correct, so you can definitely play games like this, it just won't be all that much fun.
2017-02-09 20:10:38 +00:00
memory::fill(&io, sizeof(IO));
}
auto PSG::Channel::run() -> void {
if(!io.enable) return sample(0);
if(!io.direct && --io.wavePeriod == 0) {
io.wavePeriod = io.waveFrequency;
io.waveOffset++;
io.waveSample = io.waveBuffer[io.waveOffset];
Update to v102r05 release. byuu says: Changelog: - higan: added Makefile option, `build=(release|debug|instrument|optimize)` , defaults to release - PCE: added preliminary PSG (sound) emulation The Makefile thing is just to make it easier to build debug releases without having to hand-edit the Makefile. Just say "gmake build=debug" and you'll get -g, otherwise you'll get -O3 -s. I'll probably start adding these build= blocks to my other projects. Or maybe I'll put it into nall, in which case release will need a different name ... a stable -01, and a fast -03 mode. I also want to add a mode to generate profiling information (via gprof.) Unfortunately, the existing documentation on the PCE's PSG is as barebones as humanly possible. Right now, I support waveform mode, direct D/A mode, and noise generation mode. However for noise, I'm not actually generating a proper square wave, and I don't know the PRNG algorithm used for choosing the random values. So for now, I'm just feeding in nall::random() values to it. I'm also not sure about the noise mode's frequency counter. Magic Kit is implying it's 64*~frequency, but that results in an 11-bit period. It seems only logical that we'd want a 12-bit period. So my guess is that it's actually 12-bit, and halfway through it alternates between two randomly generated values every 32 samples, and the two values are generated every time the period hits zero. Next up, it's not clear when the period counter is reloaded, either for the waveform or the noise mode. So for now, when enabling the channel, I reload the waveform period. And when enabling noise mode, I reload the noise period. I don't know if you need to do it when writing to the frequency registers or not. Next, it's not clear whether the period is a decrement-and-compare, or a compare-and-decrement, and whether we reload with frequency, frequency-1, or frequency+1. There's this cryptic note in pcetext.txt: > The PSG channel frequency is 12 bits, $001 is the highest frequency, > $FFF is the next to lowest frequency, and $000 is the lowest frequency. As best I can tell, he's trying to say that it's decrement-and-compare. Whatever the case, there's periodic popping noises every few seconds. I thought it might be because this is the first system with a fractional sampling rate (~3.57MHz), but rounding the frequency to a whole number doesn't help at all, and emulator/audio should be able to handle fractional resampling rates anyway. The popping noises could also be due to PSG writes being cycle-timed, and my HuC6280 cycle timings not being very great yet. The PSG has no kind of interrupts, so I think careful timing is the only way to do certain things, especially D/A mode. Next up, I really don't understand the frequency modulation mode at all. I don't have any idea whatsoever how to support that. It also has a frequency value that we'll need to understand how the period works and reloads. Basic idea though is the channel 1 output turns into a value to modulate channel 0's frequency by, and channel 1's output gets muted. Next up, I don't know how the volume controls work at all. There's a master volume left+right, per-channel volume left+right, and per-channel overall volume. The documentation lists their effects in terms of decibels. I have no fucking clue how to turn decibels into multiply-by values. Let alone how to stack THREE levels of audio volume controls >_> Next, it looks like the output is always 5-bit unsigned per-channel, but there's also all the volume adjustments. So I don't know the final bit-depth of the final output to normalize the value into a signed floating point value between -1.0 and +1.0. So for now, half the potential speaker range (anything below zero) isn't used in the generated output. As bad as all this sounds, and it is indeed bad ... the audio's about ~75% correct, so you can definitely play games like this, it just won't be all that much fun.
2017-02-09 20:10:38 +00:00
}
if(!io.noiseEnable) {
return sample(io.waveSample);
}
Update to v102r05 release. byuu says: Changelog: - higan: added Makefile option, `build=(release|debug|instrument|optimize)` , defaults to release - PCE: added preliminary PSG (sound) emulation The Makefile thing is just to make it easier to build debug releases without having to hand-edit the Makefile. Just say "gmake build=debug" and you'll get -g, otherwise you'll get -O3 -s. I'll probably start adding these build= blocks to my other projects. Or maybe I'll put it into nall, in which case release will need a different name ... a stable -01, and a fast -03 mode. I also want to add a mode to generate profiling information (via gprof.) Unfortunately, the existing documentation on the PCE's PSG is as barebones as humanly possible. Right now, I support waveform mode, direct D/A mode, and noise generation mode. However for noise, I'm not actually generating a proper square wave, and I don't know the PRNG algorithm used for choosing the random values. So for now, I'm just feeding in nall::random() values to it. I'm also not sure about the noise mode's frequency counter. Magic Kit is implying it's 64*~frequency, but that results in an 11-bit period. It seems only logical that we'd want a 12-bit period. So my guess is that it's actually 12-bit, and halfway through it alternates between two randomly generated values every 32 samples, and the two values are generated every time the period hits zero. Next up, it's not clear when the period counter is reloaded, either for the waveform or the noise mode. So for now, when enabling the channel, I reload the waveform period. And when enabling noise mode, I reload the noise period. I don't know if you need to do it when writing to the frequency registers or not. Next, it's not clear whether the period is a decrement-and-compare, or a compare-and-decrement, and whether we reload with frequency, frequency-1, or frequency+1. There's this cryptic note in pcetext.txt: > The PSG channel frequency is 12 bits, $001 is the highest frequency, > $FFF is the next to lowest frequency, and $000 is the lowest frequency. As best I can tell, he's trying to say that it's decrement-and-compare. Whatever the case, there's periodic popping noises every few seconds. I thought it might be because this is the first system with a fractional sampling rate (~3.57MHz), but rounding the frequency to a whole number doesn't help at all, and emulator/audio should be able to handle fractional resampling rates anyway. The popping noises could also be due to PSG writes being cycle-timed, and my HuC6280 cycle timings not being very great yet. The PSG has no kind of interrupts, so I think careful timing is the only way to do certain things, especially D/A mode. Next up, I really don't understand the frequency modulation mode at all. I don't have any idea whatsoever how to support that. It also has a frequency value that we'll need to understand how the period works and reloads. Basic idea though is the channel 1 output turns into a value to modulate channel 0's frequency by, and channel 1's output gets muted. Next up, I don't know how the volume controls work at all. There's a master volume left+right, per-channel volume left+right, and per-channel overall volume. The documentation lists their effects in terms of decibels. I have no fucking clue how to turn decibels into multiply-by values. Let alone how to stack THREE levels of audio volume controls >_> Next, it looks like the output is always 5-bit unsigned per-channel, but there's also all the volume adjustments. So I don't know the final bit-depth of the final output to normalize the value into a signed floating point value between -1.0 and +1.0. So for now, half the potential speaker range (anything below zero) isn't used in the generated output. As bad as all this sounds, and it is indeed bad ... the audio's about ~75% correct, so you can definitely play games like this, it just won't be all that much fun.
2017-02-09 20:10:38 +00:00
if(--io.noisePeriod == 0) {
io.noisePeriod = ~io.noiseFrequency << 7;
io.noiseSample = nall::random() & 1 ? ~0 : 0;
Update to v102r05 release. byuu says: Changelog: - higan: added Makefile option, `build=(release|debug|instrument|optimize)` , defaults to release - PCE: added preliminary PSG (sound) emulation The Makefile thing is just to make it easier to build debug releases without having to hand-edit the Makefile. Just say "gmake build=debug" and you'll get -g, otherwise you'll get -O3 -s. I'll probably start adding these build= blocks to my other projects. Or maybe I'll put it into nall, in which case release will need a different name ... a stable -01, and a fast -03 mode. I also want to add a mode to generate profiling information (via gprof.) Unfortunately, the existing documentation on the PCE's PSG is as barebones as humanly possible. Right now, I support waveform mode, direct D/A mode, and noise generation mode. However for noise, I'm not actually generating a proper square wave, and I don't know the PRNG algorithm used for choosing the random values. So for now, I'm just feeding in nall::random() values to it. I'm also not sure about the noise mode's frequency counter. Magic Kit is implying it's 64*~frequency, but that results in an 11-bit period. It seems only logical that we'd want a 12-bit period. So my guess is that it's actually 12-bit, and halfway through it alternates between two randomly generated values every 32 samples, and the two values are generated every time the period hits zero. Next up, it's not clear when the period counter is reloaded, either for the waveform or the noise mode. So for now, when enabling the channel, I reload the waveform period. And when enabling noise mode, I reload the noise period. I don't know if you need to do it when writing to the frequency registers or not. Next, it's not clear whether the period is a decrement-and-compare, or a compare-and-decrement, and whether we reload with frequency, frequency-1, or frequency+1. There's this cryptic note in pcetext.txt: > The PSG channel frequency is 12 bits, $001 is the highest frequency, > $FFF is the next to lowest frequency, and $000 is the lowest frequency. As best I can tell, he's trying to say that it's decrement-and-compare. Whatever the case, there's periodic popping noises every few seconds. I thought it might be because this is the first system with a fractional sampling rate (~3.57MHz), but rounding the frequency to a whole number doesn't help at all, and emulator/audio should be able to handle fractional resampling rates anyway. The popping noises could also be due to PSG writes being cycle-timed, and my HuC6280 cycle timings not being very great yet. The PSG has no kind of interrupts, so I think careful timing is the only way to do certain things, especially D/A mode. Next up, I really don't understand the frequency modulation mode at all. I don't have any idea whatsoever how to support that. It also has a frequency value that we'll need to understand how the period works and reloads. Basic idea though is the channel 1 output turns into a value to modulate channel 0's frequency by, and channel 1's output gets muted. Next up, I don't know how the volume controls work at all. There's a master volume left+right, per-channel volume left+right, and per-channel overall volume. The documentation lists their effects in terms of decibels. I have no fucking clue how to turn decibels into multiply-by values. Let alone how to stack THREE levels of audio volume controls >_> Next, it looks like the output is always 5-bit unsigned per-channel, but there's also all the volume adjustments. So I don't know the final bit-depth of the final output to normalize the value into a signed floating point value between -1.0 and +1.0. So for now, half the potential speaker range (anything below zero) isn't used in the generated output. As bad as all this sounds, and it is indeed bad ... the audio's about ~75% correct, so you can definitely play games like this, it just won't be all that much fun.
2017-02-09 20:10:38 +00:00
}
return sample(io.noiseSample);
}
Update to v102r05 release. byuu says: Changelog: - higan: added Makefile option, `build=(release|debug|instrument|optimize)` , defaults to release - PCE: added preliminary PSG (sound) emulation The Makefile thing is just to make it easier to build debug releases without having to hand-edit the Makefile. Just say "gmake build=debug" and you'll get -g, otherwise you'll get -O3 -s. I'll probably start adding these build= blocks to my other projects. Or maybe I'll put it into nall, in which case release will need a different name ... a stable -01, and a fast -03 mode. I also want to add a mode to generate profiling information (via gprof.) Unfortunately, the existing documentation on the PCE's PSG is as barebones as humanly possible. Right now, I support waveform mode, direct D/A mode, and noise generation mode. However for noise, I'm not actually generating a proper square wave, and I don't know the PRNG algorithm used for choosing the random values. So for now, I'm just feeding in nall::random() values to it. I'm also not sure about the noise mode's frequency counter. Magic Kit is implying it's 64*~frequency, but that results in an 11-bit period. It seems only logical that we'd want a 12-bit period. So my guess is that it's actually 12-bit, and halfway through it alternates between two randomly generated values every 32 samples, and the two values are generated every time the period hits zero. Next up, it's not clear when the period counter is reloaded, either for the waveform or the noise mode. So for now, when enabling the channel, I reload the waveform period. And when enabling noise mode, I reload the noise period. I don't know if you need to do it when writing to the frequency registers or not. Next, it's not clear whether the period is a decrement-and-compare, or a compare-and-decrement, and whether we reload with frequency, frequency-1, or frequency+1. There's this cryptic note in pcetext.txt: > The PSG channel frequency is 12 bits, $001 is the highest frequency, > $FFF is the next to lowest frequency, and $000 is the lowest frequency. As best I can tell, he's trying to say that it's decrement-and-compare. Whatever the case, there's periodic popping noises every few seconds. I thought it might be because this is the first system with a fractional sampling rate (~3.57MHz), but rounding the frequency to a whole number doesn't help at all, and emulator/audio should be able to handle fractional resampling rates anyway. The popping noises could also be due to PSG writes being cycle-timed, and my HuC6280 cycle timings not being very great yet. The PSG has no kind of interrupts, so I think careful timing is the only way to do certain things, especially D/A mode. Next up, I really don't understand the frequency modulation mode at all. I don't have any idea whatsoever how to support that. It also has a frequency value that we'll need to understand how the period works and reloads. Basic idea though is the channel 1 output turns into a value to modulate channel 0's frequency by, and channel 1's output gets muted. Next up, I don't know how the volume controls work at all. There's a master volume left+right, per-channel volume left+right, and per-channel overall volume. The documentation lists their effects in terms of decibels. I have no fucking clue how to turn decibels into multiply-by values. Let alone how to stack THREE levels of audio volume controls >_> Next, it looks like the output is always 5-bit unsigned per-channel, but there's also all the volume adjustments. So I don't know the final bit-depth of the final output to normalize the value into a signed floating point value between -1.0 and +1.0. So for now, half the potential speaker range (anything below zero) isn't used in the generated output. As bad as all this sounds, and it is indeed bad ... the audio's about ~75% correct, so you can definitely play games like this, it just won't be all that much fun.
2017-02-09 20:10:38 +00:00
auto PSG::Channel::sample(uint5 sample) -> void {
io.output = sample;
Update to v102r05 release. byuu says: Changelog: - higan: added Makefile option, `build=(release|debug|instrument|optimize)` , defaults to release - PCE: added preliminary PSG (sound) emulation The Makefile thing is just to make it easier to build debug releases without having to hand-edit the Makefile. Just say "gmake build=debug" and you'll get -g, otherwise you'll get -O3 -s. I'll probably start adding these build= blocks to my other projects. Or maybe I'll put it into nall, in which case release will need a different name ... a stable -01, and a fast -03 mode. I also want to add a mode to generate profiling information (via gprof.) Unfortunately, the existing documentation on the PCE's PSG is as barebones as humanly possible. Right now, I support waveform mode, direct D/A mode, and noise generation mode. However for noise, I'm not actually generating a proper square wave, and I don't know the PRNG algorithm used for choosing the random values. So for now, I'm just feeding in nall::random() values to it. I'm also not sure about the noise mode's frequency counter. Magic Kit is implying it's 64*~frequency, but that results in an 11-bit period. It seems only logical that we'd want a 12-bit period. So my guess is that it's actually 12-bit, and halfway through it alternates between two randomly generated values every 32 samples, and the two values are generated every time the period hits zero. Next up, it's not clear when the period counter is reloaded, either for the waveform or the noise mode. So for now, when enabling the channel, I reload the waveform period. And when enabling noise mode, I reload the noise period. I don't know if you need to do it when writing to the frequency registers or not. Next, it's not clear whether the period is a decrement-and-compare, or a compare-and-decrement, and whether we reload with frequency, frequency-1, or frequency+1. There's this cryptic note in pcetext.txt: > The PSG channel frequency is 12 bits, $001 is the highest frequency, > $FFF is the next to lowest frequency, and $000 is the lowest frequency. As best I can tell, he's trying to say that it's decrement-and-compare. Whatever the case, there's periodic popping noises every few seconds. I thought it might be because this is the first system with a fractional sampling rate (~3.57MHz), but rounding the frequency to a whole number doesn't help at all, and emulator/audio should be able to handle fractional resampling rates anyway. The popping noises could also be due to PSG writes being cycle-timed, and my HuC6280 cycle timings not being very great yet. The PSG has no kind of interrupts, so I think careful timing is the only way to do certain things, especially D/A mode. Next up, I really don't understand the frequency modulation mode at all. I don't have any idea whatsoever how to support that. It also has a frequency value that we'll need to understand how the period works and reloads. Basic idea though is the channel 1 output turns into a value to modulate channel 0's frequency by, and channel 1's output gets muted. Next up, I don't know how the volume controls work at all. There's a master volume left+right, per-channel volume left+right, and per-channel overall volume. The documentation lists their effects in terms of decibels. I have no fucking clue how to turn decibels into multiply-by values. Let alone how to stack THREE levels of audio volume controls >_> Next, it looks like the output is always 5-bit unsigned per-channel, but there's also all the volume adjustments. So I don't know the final bit-depth of the final output to normalize the value into a signed floating point value between -1.0 and +1.0. So for now, half the potential speaker range (anything below zero) isn't used in the generated output. As bad as all this sounds, and it is indeed bad ... the audio's about ~75% correct, so you can definitely play games like this, it just won't be all that much fun.
2017-02-09 20:10:38 +00:00
}