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/spc700/algorithms.cpp

135 lines
2.4 KiB
C++
Raw Normal View History

Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_adc(uint8 x, uint8 y) -> uint8 {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
int r = x + y + regs.p.c;
regs.p.n = r & 0x80;
regs.p.v = ~(x ^ y) & (x ^ r) & 0x80;
regs.p.h = (x ^ y ^ r) & 0x10;
regs.p.z = (uint8)r == 0;
regs.p.c = r > 0xff;
return r;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_and(uint8 x, uint8 y) -> uint8 {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
x &= y;
regs.p.n = x & 0x80;
regs.p.z = x == 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_asl(uint8 x) -> uint8 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.c = x & 0x80;
x <<= 1;
regs.p.n = x & 0x80;
regs.p.z = x == 0;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_cmp(uint8 x, uint8 y) -> uint8 {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
int r = x - y;
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.n = r & 0x80;
regs.p.z = (uint8)r == 0;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.p.c = r >= 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_dec(uint8 x) -> uint8 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
x--;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.p.n = x & 0x80;
regs.p.z = x == 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_eor(uint8 x, uint8 y) -> uint8 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
x ^= y;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.p.n = x & 0x80;
regs.p.z = x == 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_inc(uint8 x) -> uint8 {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
x++;
regs.p.n = x & 0x80;
regs.p.z = x == 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_ld(uint8 x, uint8 y) -> uint8 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.n = y & 0x80;
regs.p.z = y == 0;
return y;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_lsr(uint8 x) -> uint8 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.c = x & 0x01;
x >>= 1;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.p.n = x & 0x80;
regs.p.z = x == 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_or(uint8 x, uint8 y) -> uint8 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
x |= y;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.p.n = x & 0x80;
regs.p.z = x == 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_rol(uint8 x) -> uint8 {
uint carry = regs.p.c << 0;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.p.c = x & 0x80;
x = (x << 1) | carry;
regs.p.n = x & 0x80;
regs.p.z = x == 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_ror(uint8 x) -> uint8 {
uint carry = regs.p.c << 7;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
regs.p.c = x & 0x01;
x = carry | (x >> 1);
regs.p.n = x & 0x80;
regs.p.z = x == 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_sbc(uint8 x, uint8 y) -> uint8 {
Update to v084r03 release. (r02 was not posted to the WIP thread) byuu says: Internally, all color is processed with 30-bit precision. The filters also operate at 30-bit depth. There's a new config file setting, video.depth, which defaults to 24. This causes the final output to downsample to 24-bit, as most will require. If you set it to 30-bit, the downsampling will not occur, and bsnes will ask ruby for a 30-bit surface. If you don't have one available, you're going to get bad colors. Or maybe even a crash with OpenGL. I don't yet have detection code to make sure you have an appropriate visual in place. 30-bit mode will really only work if you are running Linux, running Xorg at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD FireGL card with the official drivers, and have a 30-bit capable monitor. Lots of planning and work for very little gain here, but it's nice that it's finally finished. Oh, I had to change the contrast/brightness formulas a tiny bit, but they still work and look nice.
2011-12-03 03:22:54 +00:00
return op_adc(x, ~y);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_st(uint8 x, uint8 y) -> uint8 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
return y;
}
//
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_adw(uint16 x, uint16 y) -> uint16 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
uint16 r;
regs.p.c = 0;
r = op_adc(x, y);
r |= op_adc(x >> 8, y >> 8) << 8;
regs.p.z = r == 0;
return r;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_cpw(uint16 x, uint16 y) -> uint16 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
int r = x - y;
regs.p.n = r & 0x8000;
regs.p.z = (uint16)r == 0;
regs.p.c = r >= 0;
return x;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_ldw(uint16 x, uint16 y) -> uint16 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.n = y & 0x8000;
regs.p.z = y == 0;
return y;
}
Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::op_sbw(uint16 x, uint16 y) -> uint16 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
uint16 r;
regs.p.c = 1;
r = op_sbc(x, y);
r |= op_sbc(x >> 8, y >> 8) << 8;
regs.p.z = r == 0;
return r;
}