ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/higan/processor/gsu/instructions.cpp

425 lines
9.2 KiB
C++
Raw Normal View History

First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
//$00 stop
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_stop() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
if(regs.cfgr.irq == 0) {
regs.sfr.irq = 1;
Update to v088r07 release. byuu says: (r05 and r06 were save points between large core modifications) I would really appreciate extensive regression testing (especially around SuperFX, Cx4, ST018, DSP-n, ST-01n, NES, GB) at this point. The most critical core changes should be completed now. And it was an unbelievable amount of restructuring. Changelog: - SuperFX core moved to Processor::GSU - SNES::CPU core moved to Processor::R65816 - SNES::SMP core moved to Processor::SPC700 - NES::CPU core renamed to Processor::R6502 - use filestream to load RAM files from interface - save states store SHA256 instead of CRC32 (CRC32 usage removed entirely from bsnes) - nes/ -> fc/ and NES -> FC - snes/ -> sfc/ and SNES -> SFC - SuperFamicom::MappedRAM::copy uses stream instead of data+size - Linux port uses gcc-4.7 (still using only gcc-4.6 subset, so you can make a gcc-4.6 symlink for now if you like.) - all profiles and all targets compile and work properly All eight instruction set cores have been moved to processor/ now. Consistency's a wonderful thing. The last remnants of NES/SNES are now limited to target-ui code; and the nall/(system) folder names. I'm building with gcc-4.7 on my Linux box now because the resultant binaries are up to 20% faster (seriously) than gcc-4.6.
2012-04-29 06:16:44 +00:00
stop();
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
regs.sfr.g = 0;
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
regs.pipeline = 0x01; //nop
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
//$01 nop
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_nop() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
//$02 cache
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_cache() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
if(regs.cbr != (regs.r[15] & 0xfff0)) {
regs.cbr = regs.r[15] & 0xfff0;
cache_flush();
}
regs.reset();
}
//$03 lsr
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_lsr() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.cy = (regs.sr() & 1);
regs.dr() = regs.sr() >> 1;
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
//$04 rol
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_rol() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
bool carry = (regs.sr() & 0x8000);
regs.dr() = (regs.sr() << 1) | regs.sfr.cy;
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.cy = carry;
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
//$05 bra e
//$06 blt e
//$07 bge e
//$08 bne e
//$09 beq e
//$0a bpl e
//$0b bmi e
//$0c bcc e
//$0d bcs e
//$0e bvc e
//$0f bvs e
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
auto GSU::op_branch(bool c) {
auto d = (int8)pipe();
if(c) regs.r[15] += d;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$10-1f(b0) to rN
//$10-1f(b1) move rN
auto GSU::op_to_move(uint n) {
if(!regs.sfr.b) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dreg = n;
} else {
regs.r[n] = regs.sr();
regs.reset();
}
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$20-2f with rN
auto GSU::op_with(uint n) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sreg = n;
regs.dreg = n;
regs.sfr.b = 1;
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$30-3b(alt0) stw (rN)
//$30-3b(alt1) stb (rN)
auto GSU::op_store(uint n) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.ramaddr = regs.r[n];
rambuffer_write(regs.ramaddr, regs.sr());
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
if(!regs.sfr.alt1) rambuffer_write(regs.ramaddr ^ 1, regs.sr() >> 8);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
//$3c loop
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_loop() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.r[12]--;
regs.sfr.s = (regs.r[12] & 0x8000);
regs.sfr.z = (regs.r[12] == 0);
if(!regs.sfr.z) regs.r[15] = regs.r[13];
regs.reset();
}
//$3d alt1
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_alt1() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.b = 0;
regs.sfr.alt1 = 1;
}
//$3e alt2
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_alt2() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.b = 0;
regs.sfr.alt2 = 1;
}
//$3f alt3
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_alt3() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.b = 0;
regs.sfr.alt1 = 1;
regs.sfr.alt2 = 1;
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$40-4b(alt0) ldw (rN)
//$40-4b(alt1) ldb (rN)
auto GSU::op_load(uint n) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.ramaddr = regs.r[n];
regs.dr() = rambuffer_read(regs.ramaddr);
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
if(!regs.sfr.alt1) regs.dr() |= rambuffer_read(regs.ramaddr ^ 1) << 8;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$4c(alt0) plot
//$4c(alt1) rpix
auto GSU::op_plot_rpix() {
if(!regs.sfr.alt1) {
plot(regs.r[1], regs.r[2]);
regs.r[1]++;
} else {
regs.dr() = rpix(regs.r[1], regs.r[2]);
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$4d swap
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_swap() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dr() = (regs.sr() >> 8) | (regs.sr() << 8);
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$4e(alt0) color
//$4e(alt1) cmode
auto GSU::op_color_cmode() {
if(!regs.sfr.alt1) {
regs.colr = color(regs.sr());
} else {
regs.por = regs.sr();
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$4f not
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_not() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dr() = ~regs.sr();
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$50-5f(alt0) add rN
//$50-5f(alt1) adc rN
//$50-5f(alt2) add #N
//$50-5f(alt3) adc #N
auto GSU::op_add_adc(uint n) {
if(!regs.sfr.alt2) n = regs.r[n];
int r = regs.sr() + n + (regs.sfr.alt1 ? regs.sfr.cy : 0);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.ov = ~(regs.sr() ^ n) & (n ^ r) & 0x8000;
regs.sfr.s = (r & 0x8000);
regs.sfr.cy = (r >= 0x10000);
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
regs.sfr.z = ((uint16)r == 0);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dr() = r;
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$60-6f(alt0) sub rN
//$60-6f(alt1) sbc rN
//$60-6f(alt2) sub #N
//$60-6f(alt3) cmp rN
auto GSU::op_sub_sbc_cmp(uint n) {
if(!regs.sfr.alt2 || regs.sfr.alt1) n = regs.r[n];
int r = regs.sr() - n - (!regs.sfr.alt2 && regs.sfr.alt1 ? !regs.sfr.cy : 0);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.ov = (regs.sr() ^ n) & (regs.sr() ^ r) & 0x8000;
regs.sfr.s = (r & 0x8000);
regs.sfr.cy = (r >= 0);
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
regs.sfr.z = ((uint16)r == 0);
if(!regs.sfr.alt2 || !regs.sfr.alt1) regs.dr() = r;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$70 merge
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_merge() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dr() = (regs.r[7] & 0xff00) | (regs.r[8] >> 8);
regs.sfr.ov = (regs.dr() & 0xc0c0);
regs.sfr.s = (regs.dr() & 0x8080);
regs.sfr.cy = (regs.dr() & 0xe0e0);
regs.sfr.z = (regs.dr() & 0xf0f0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$71-7f(alt0) and rN
//$71-7f(alt1) bic rN
//$71-7f(alt2) and #N
//$71-7f(alt3) bic #N
auto GSU::op_and_bic(uint n) {
if(!regs.sfr.alt2) n = regs.r[n];
regs.dr() = regs.sr() & (regs.sfr.alt1 ? ~n : n);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$80-8f(alt0) mult rN
//$80-8f(alt1) umult rN
//$80-8f(alt2) mult #N
//$80-8f(alt3) umult #N
auto GSU::op_mult_umult(uint n) {
if(!regs.sfr.alt2) n = regs.r[n];
regs.dr() = (!regs.sfr.alt1 ? ((int8)regs.sr() * (int8)n) : ((uint8)regs.sr() * (uint8)n));
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
Update to v094r34 release. byuu says: Fixes SuperFX fmult, lmult timings; rambr, bramr and clsr assignment masking. Implements true GBA ROM prefetch (buggy, lower test score, but runs Mario & Luigi without crashing on battles anymore.)
2015-06-28 08:44:56 +00:00
if(!regs.cfgr.ms0) step(regs.clsr ? 1 : 2);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$90 sbk
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_sbk() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
rambuffer_write(regs.ramaddr ^ 0, regs.sr() >> 0);
rambuffer_write(regs.ramaddr ^ 1, regs.sr() >> 8);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$91-94 link #N
auto GSU::op_link(uint n) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.r[11] = regs.r[15] + n;
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$95 sex
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_sex() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dr() = (int8)regs.sr();
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$96(alt0) asr
//$96(alt1) div2
auto GSU::op_asr_div2() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.cy = (regs.sr() & 1);
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
regs.dr() = ((int16)regs.sr() >> 1) + (regs.sfr.alt1 ? ((regs.sr() + 1) >> 16) : 0);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$97 ror
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_ror() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
bool carry = (regs.sr() & 1);
regs.dr() = (regs.sfr.cy << 15) | (regs.sr() >> 1);
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.cy = carry;
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$98-9d(alt0) jmp rN
//$98-9d(alt1) ljmp rN
auto GSU::op_jmp_ljmp(uint n) {
if(!regs.sfr.alt1) {
regs.r[15] = regs.r[n];
} else {
regs.pbr = regs.r[n] & 0x7f;
regs.r[15] = regs.sr();
regs.cbr = regs.r[15] & 0xfff0;
cache_flush();
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$9e lob
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_lob() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dr() = regs.sr() & 0xff;
regs.sfr.s = (regs.dr() & 0x80);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$9f(alt0) fmult
//$9f(alt1) lmult
auto GSU::op_fmult_lmult() {
uint32 result = (int16)regs.sr() * (int16)regs.r[6];
if(regs.sfr.alt1) regs.r[4] = result;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dr() = result >> 16;
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.cy = (result & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
Update to v094r34 release. byuu says: Fixes SuperFX fmult, lmult timings; rambr, bramr and clsr assignment masking. Implements true GBA ROM prefetch (buggy, lower test score, but runs Mario & Luigi without crashing on battles anymore.)
2015-06-28 08:44:56 +00:00
step((regs.cfgr.ms0 ? 3 : 7) * (regs.clsr ? 1 : 2));
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$a0-af(alt0) ibt rN,#pp
//$a0-af(alt1) lms rN,(yy)
//$a0-af(alt2) sms (yy),rN
auto GSU::op_ibt_lms_sms(uint n) {
if(regs.sfr.alt1) {
regs.ramaddr = pipe() << 1;
uint8 lo = rambuffer_read(regs.ramaddr ^ 0) << 0;
regs.r[n] = rambuffer_read(regs.ramaddr ^ 1) << 8 | lo;
} else if(regs.sfr.alt2) {
regs.ramaddr = pipe() << 1;
rambuffer_write(regs.ramaddr ^ 0, regs.r[n] >> 0);
rambuffer_write(regs.ramaddr ^ 1, regs.r[n] >> 8);
} else {
regs.r[n] = (int8)pipe();
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$b0-bf(b0) from rN
//$b0-bf(b1) moves rN
auto GSU::op_from_moves(uint n) {
if(!regs.sfr.b) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sreg = n;
} else {
regs.dr() = regs.r[n];
regs.sfr.ov = (regs.dr() & 0x80);
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$c0 hib
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_hib() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.dr() = regs.sr() >> 8;
regs.sfr.s = (regs.dr() & 0x80);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$c1-cf(alt0) or rN
//$c1-cf(alt1) xor rN
//$c1-cf(alt2) or #N
//$c1-cf(alt3) xor #N
auto GSU::op_or_xor(uint n) {
if(!regs.sfr.alt2) n = regs.r[n];
regs.dr() = (!regs.sfr.alt1 ? (regs.sr() | n) : (regs.sr() ^ n));
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.sfr.s = (regs.dr() & 0x8000);
regs.sfr.z = (regs.dr() == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$d0-de inc rN
auto GSU::op_inc(uint n) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.r[n]++;
regs.sfr.s = (regs.r[n] & 0x8000);
regs.sfr.z = (regs.r[n] == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$df(alt0) getc
//$df(alt2) ramb
//$df(alt3) romb
auto GSU::op_getc_ramb_romb() {
if(!regs.sfr.alt2) {
regs.colr = color(rombuffer_read());
} else if(!regs.sfr.alt1) {
rambuffer_sync();
regs.rambr = regs.sr() & 0x01;
} else {
rombuffer_sync();
regs.rombr = regs.sr() & 0x7f;
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$e0-ee dec rN
auto GSU::op_dec(uint n) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.r[n]--;
regs.sfr.s = (regs.r[n] & 0x8000);
regs.sfr.z = (regs.r[n] == 0);
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$ef(alt0) getb
//$ef(alt1) getbh
//$ef(alt2) getbl
//$ef(alt3) getbs
Update to v094r33 release. byuu says: Small WIP, just fixes the timings for GSU multiply. However, the actual product may still be wrong when CLSR and MS0 are both set. Since I wasn't 'corrupting' the value in said case before, then this behavior can only be better than before. Turned the (cache,memory)_access_timing into functions that compute the values; and pulled "clockspeed" into GSU. Also, I'm thinking it might be kind of pointless to have clockspeed at all. Supposedly even the Mario Chip can run at 21.48MHz anyway. Enforcing 10.74MHz mode seems kind of silly. If we change it to just be a "default value for CLSR", then we can just inline the memory access tests without the need for the access_timing functions (literally just clsr?2:1 then) Slight compilation bug: go to processor/gsu/registers.hpp:33 and add reg16_t() = default; I missed it due to a partial recompile. Too lazy to upload another WIP just for that. Probably not worth doing much SuperFX testing just yet, as it looks like they're doing some other tests at the moment on NESdev.
2015-06-27 02:38:47 +00:00
auto GSU::op_getb() {
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
switch(regs.sfr.alt2 << 1 | regs.sfr.alt1 << 0) {
case 0: regs.dr() = rombuffer_read(); break;
case 1: regs.dr() = rombuffer_read() << 8 | (uint8)regs.sr(); break;
case 2: regs.dr() = (regs.sr() & 0xff00) | rombuffer_read(); break;
case 3: regs.dr() = (int8)rombuffer_read(); break;
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}
Update to v098r13 release. byuu says: Changelog: - nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files - nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't cause too many moves with FIFO) - audio streams now only buffer 20ms; so even if multiple audio streams desync, latency can never exceed 20ms - replaced blackman windwed sinc FIR hermite audio filter with transposed direct form II biquadratic sixth-order IIR butterworth filter (better attenuation of frequencies above 20KHz, faster, no need for decimation, less code) - put in experimental eight-tap echo filter (a lot better than what I had before, but still rather weak) - substantial cleanups to the SuperFX GSU processor core (slightly faster, 479KB->100KB object file, 42.7KB->33.4KB source code size, way less code duplication) We'll definitely want to test the whole SuperFX library (not many games) just to make sure there's no regressions caused by this one. Not sure what I want to do with audio processing effects yet. I've always really wanted lots of fun controls to customize audio, and now finally with this new biquad filter, I can finally start implementing real effects. For instance, an equalizer wouldn't be too complicated anymore. The new reverb effect is still a poor man's version. I need to find human readable source for implementing a comb-filter properly. I'm pretty sure I can already treat nall::queue as an all-pass filter since all that does is phase shift (fancy audio term for "delay audio"). What's really going to be hard is figuring out how to expose user-friendly settings for controlling it. It looks like you need a bunch of coprime coefficients, and I don't think casual users are going to be able to hand-enter coprime values to get the echo effect they want. I uh ... don't even know how to calculate coprime values dynamically right now >_> But we're going to have to, as they are correlated to the output sampling rate. We'll definitely want to make some audio profiles so that users can quickly select pre-configured themes that sound nice, but expose the underlying coefficients so that they can tweak stuff to their liking. This isn't just about higan, this is about me trying to learn digital signal processing, so please don't be too upset about feature creep or anything on this. Anyway ... I'm having some difficulties with my audio right now. When the reverb effect is enabled, there's a bunch of static on system reset for just a moment. But this should not be possible. nall::queue is initializing all previous reverb sample elements to 0.0. I don't understand where static is coming in from. Further, we have the same issue with both the windowed sinc and the biquad filters ... a bit of a popping sound when starting a game. Any help tracking this down would be appreciated. There's also one really annoying issue ... I can't seem to do reverb or volume adjustments with normalized samples. If I say "volume *= 0.5" in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it adds a whole bunch of distortion. This makes absolutely zero sense to me. The sample values are between 0.0 (mute) and 1.0 (full volume) here, so multiplying a double by 0.5 shouldn't cause distortion. So right now, I'm doing these adjustments with less precision after denormalizing back to int16. Anyone ever see something like that? :/
2016-05-31 22:29:36 +00:00
//$f0-ff(alt0) iwt rN,#xx
//$f0-ff(alt1) lm rN,(xx)
//$f0-ff(alt2) sm (xx),rN
auto GSU::op_iwt_lm_sm(uint n) {
if(regs.sfr.alt1) {
regs.ramaddr = pipe() << 0;
regs.ramaddr |= pipe() << 8;
uint8 lo = rambuffer_read(regs.ramaddr ^ 0) << 0;
regs.r[n] = rambuffer_read(regs.ramaddr ^ 1) << 8 | lo;
} else if(regs.sfr.alt2) {
regs.ramaddr = pipe() << 0;
regs.ramaddr |= pipe() << 8;
rambuffer_write(regs.ramaddr ^ 0, regs.r[n] >> 0);
rambuffer_write(regs.ramaddr ^ 1, regs.r[n] >> 8);
} else {
uint8 lo = pipe();
regs.r[n] = pipe() << 8 | lo;
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.reset();
}