bsnes/higan/pce/psg/psg.cpp

44 lines
863 B
C++
Raw Normal View History

Update to v101r30 release. byuu says: Changelog: - SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd) - SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics) - Z80: emulated "ex (sp),hl" instruction - Z80: fixed INx NF (should be set instead of cleared) - Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes walking in Wonder Boy) - SFC: removed Debugger and sfc/debugger.hpp - icarus: connected MS, GG, MD importing to the scan dialog - PCE: added emulation skeleton to higan and icarus At this point, Master System games are fairly highly compatible, sans audio. Game Gear games are running, but I need to crop the resolution and support the higher color palette that they can utilize. It's really something else the way they handled the resolution shrink on that thing. The last change is obviously going to be the biggest news. I'm very well aware it's not an ideal time to start on a new emulation core, with the MS and MD cores only just now coming to life with no audio support. But, for whatever reason, my heart's really set on working on the PC Engine. I wanted to write the final higan skeleton core, and get things ready so that whenever I'm in the mood to work on the PCE, I can do so. The skeleton is far and away the most tedious and obnoxious part of the emulator development, because it's basically all just lots of boilerplate templated code, lots of new files to create, etc. I really don't know how things are going to proceed ... but I can say with 99.9% certainty that this will be the final brand new core ever added to higan -- at least one written by me, that is. This was basically the last system from my childhood that I ever cared about. It's the last 2D system with games that I really enjoy playing. No other system is worth dividing my efforts and reducing the quality and amount of time to work on the systems I have. In the future, there will be potential for FDS, Mega CD and PCE-CD support. But those will all be add-ons, and they'll all be really difficult and challenge the entire design of higan's UI (it's entirely cartridge-driven at this time.) None of them will be entirely new cores like this one.
2017-01-11 20:27:30 +00:00
#include <pce/pce.hpp>
namespace PCEngine {
PSG psg;
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
#include "io.cpp"
#include "channel.cpp"
Update to v101r30 release. byuu says: Changelog: - SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd) - SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics) - Z80: emulated "ex (sp),hl" instruction - Z80: fixed INx NF (should be set instead of cleared) - Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes walking in Wonder Boy) - SFC: removed Debugger and sfc/debugger.hpp - icarus: connected MS, GG, MD importing to the scan dialog - PCE: added emulation skeleton to higan and icarus At this point, Master System games are fairly highly compatible, sans audio. Game Gear games are running, but I need to crop the resolution and support the higher color palette that they can utilize. It's really something else the way they handled the resolution shrink on that thing. The last change is obviously going to be the biggest news. I'm very well aware it's not an ideal time to start on a new emulation core, with the MS and MD cores only just now coming to life with no audio support. But, for whatever reason, my heart's really set on working on the PC Engine. I wanted to write the final higan skeleton core, and get things ready so that whenever I'm in the mood to work on the PCE, I can do so. The skeleton is far and away the most tedious and obnoxious part of the emulator development, because it's basically all just lots of boilerplate templated code, lots of new files to create, etc. I really don't know how things are going to proceed ... but I can say with 99.9% certainty that this will be the final brand new core ever added to higan -- at least one written by me, that is. This was basically the last system from my childhood that I ever cared about. It's the last 2D system with games that I really enjoy playing. No other system is worth dividing my efforts and reducing the quality and amount of time to work on the systems I have. In the future, there will be potential for FDS, Mega CD and PCE-CD support. But those will all be add-ons, and they'll all be really difficult and challenge the entire design of higan's UI (it's entirely cartridge-driven at this time.) None of them will be entirely new cores like this one.
2017-01-11 20:27:30 +00:00
auto PSG::Enter() -> void {
while(true) scheduler.synchronize(), psg.main();
}
auto PSG::main() -> void {
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
uint left = 0, right = 0;
for(auto C : range(6)) {
channel[C].run();
if(C == 1 && io.lfoEnable) {
//todo: frequency modulation of channel 0 using channel 1's output
} else {
left += channel[C].output.left;
right += channel[C].output.right;
}
}
stream->sample(left / 32768.0, right / 32768.0);
Update to v101r30 release. byuu says: Changelog: - SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd) - SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics) - Z80: emulated "ex (sp),hl" instruction - Z80: fixed INx NF (should be set instead of cleared) - Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes walking in Wonder Boy) - SFC: removed Debugger and sfc/debugger.hpp - icarus: connected MS, GG, MD importing to the scan dialog - PCE: added emulation skeleton to higan and icarus At this point, Master System games are fairly highly compatible, sans audio. Game Gear games are running, but I need to crop the resolution and support the higher color palette that they can utilize. It's really something else the way they handled the resolution shrink on that thing. The last change is obviously going to be the biggest news. I'm very well aware it's not an ideal time to start on a new emulation core, with the MS and MD cores only just now coming to life with no audio support. But, for whatever reason, my heart's really set on working on the PC Engine. I wanted to write the final higan skeleton core, and get things ready so that whenever I'm in the mood to work on the PCE, I can do so. The skeleton is far and away the most tedious and obnoxious part of the emulator development, because it's basically all just lots of boilerplate templated code, lots of new files to create, etc. I really don't know how things are going to proceed ... but I can say with 99.9% certainty that this will be the final brand new core ever added to higan -- at least one written by me, that is. This was basically the last system from my childhood that I ever cared about. It's the last 2D system with games that I really enjoy playing. No other system is worth dividing my efforts and reducing the quality and amount of time to work on the systems I have. In the future, there will be potential for FDS, Mega CD and PCE-CD support. But those will all be add-ons, and they'll all be really difficult and challenge the entire design of higan's UI (it's entirely cartridge-driven at this time.) None of them will be entirely new cores like this one.
2017-01-11 20:27:30 +00:00
step(1);
}
auto PSG::step(uint clocks) -> void {
Thread::step(clocks);
synchronize(cpu);
}
auto PSG::power() -> void {
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
create(PSG::Enter, system.colorburst());
stream = Emulator::audio.createStream(2, system.colorburst());
memory::fill(&io, sizeof(IO));
for(auto C : range(6)) channel[C].power(C);
Update to v101r30 release. byuu says: Changelog: - SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd) - SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics) - Z80: emulated "ex (sp),hl" instruction - Z80: fixed INx NF (should be set instead of cleared) - Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes walking in Wonder Boy) - SFC: removed Debugger and sfc/debugger.hpp - icarus: connected MS, GG, MD importing to the scan dialog - PCE: added emulation skeleton to higan and icarus At this point, Master System games are fairly highly compatible, sans audio. Game Gear games are running, but I need to crop the resolution and support the higher color palette that they can utilize. It's really something else the way they handled the resolution shrink on that thing. The last change is obviously going to be the biggest news. I'm very well aware it's not an ideal time to start on a new emulation core, with the MS and MD cores only just now coming to life with no audio support. But, for whatever reason, my heart's really set on working on the PC Engine. I wanted to write the final higan skeleton core, and get things ready so that whenever I'm in the mood to work on the PCE, I can do so. The skeleton is far and away the most tedious and obnoxious part of the emulator development, because it's basically all just lots of boilerplate templated code, lots of new files to create, etc. I really don't know how things are going to proceed ... but I can say with 99.9% certainty that this will be the final brand new core ever added to higan -- at least one written by me, that is. This was basically the last system from my childhood that I ever cared about. It's the last 2D system with games that I really enjoy playing. No other system is worth dividing my efforts and reducing the quality and amount of time to work on the systems I have. In the future, there will be potential for FDS, Mega CD and PCE-CD support. But those will all be add-ons, and they'll all be really difficult and challenge the entire design of higan's UI (it's entirely cartridge-driven at this time.) None of them will be entirely new cores like this one.
2017-01-11 20:27:30 +00:00
}
}