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/instructions.cpp

558 lines
11 KiB
C++
Raw Normal View History

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
#define call (this->*op)
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
template<auto (SPC700::*op)(uint8) -> uint8>
auto SPC700::op_adjust(uint8& r) -> void {
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
op_io();
r = call(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
template<auto (SPC700::*op)(uint8) -> uint8>
auto SPC700::op_adjust_addr() -> void {
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
dp.l = op_readpc();
dp.h = op_readpc();
rd = op_read(dp);
rd = call(rd);
op_write(dp, rd);
}
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
template<auto (SPC700::*op)(uint8) -> uint8>
auto SPC700::op_adjust_dp() -> void {
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
dp = op_readpc();
rd = op_readdp(dp);
rd = call(rd);
op_writedp(dp, rd);
}
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_adjust_dpw(int n) -> void {
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
dp = op_readpc();
rd.w = op_readdp(dp) + n;
op_writedp(dp++, rd.l);
rd.h += op_readdp(dp);
op_writedp(dp++, rd.h);
regs.p.n = rd & 0x8000;
regs.p.z = rd == 0;
}
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
template<auto (SPC700::*op)(uint8) -> uint8>
auto SPC700::op_adjust_dpx() -> void {
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
dp = op_readpc();
op_io();
rd = op_readdp(dp + regs.x);
rd = call(rd);
op_writedp(dp + regs.x, rd);
}
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_branch(bool condition) -> void {
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
rd = op_readpc();
if(condition == false) return;
op_io();
op_io();
regs.pc += (int8)rd;
}
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_branch_bit() -> void {
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
dp = op_readpc();
sp = op_readdp(dp);
rd = op_readpc();
op_io();
if((bool)(sp & (1 << (opcode >> 5))) == (bool)(opcode & 0x10)) return;
op_io();
op_io();
regs.pc += (int8)rd;
}
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_pull(uint8& r) -> void {
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
op_io();
op_io();
r = op_readsp();
}
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_push(uint8 r) -> void {
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
op_io();
op_io();
op_writesp(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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_read_addr(uint8& r) -> void {
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
dp.l = op_readpc();
dp.h = op_readpc();
rd = op_read(dp);
r = call(r, rd);
}
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_read_addri(uint8& r) -> void {
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
dp.l = op_readpc();
dp.h = op_readpc();
op_io();
rd = op_read(dp + r);
regs.a = call(regs.a, rd);
}
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_read_const(uint8& r) -> void {
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
rd = op_readpc();
r = call(r, rd);
}
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_read_dp(uint8& r) -> void {
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
dp = op_readpc();
rd = op_readdp(dp);
r = call(r, rd);
}
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_read_dpi(uint8& r, uint8& i) -> void {
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
dp = op_readpc();
op_io();
rd = op_readdp(dp + i);
r = call(r, rd);
}
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
template<auto (SPC700::*op)(uint16, uint16) -> uint16>
auto SPC700::op_read_dpw() -> void {
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
dp = op_readpc();
rd.l = op_readdp(dp++);
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
if(op != &SPC700::op_cpw) op_io();
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
rd.h = op_readdp(dp++);
regs.ya = call(regs.ya, rd);
}
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_read_idpx() -> void {
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
dp = op_readpc() + regs.x;
op_io();
sp.l = op_readdp(dp++);
sp.h = op_readdp(dp++);
rd = op_read(sp);
regs.a = call(regs.a, rd);
}
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_read_idpy() -> void {
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
dp = op_readpc();
op_io();
sp.l = op_readdp(dp++);
sp.h = op_readdp(dp++);
rd = op_read(sp + regs.y);
regs.a = call(regs.a, rd);
}
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_read_ix() -> void {
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
op_io();
rd = op_readdp(regs.x);
regs.a = call(regs.a, rd);
}
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_set_addr_bit() -> void {
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
dp.l = op_readpc();
dp.h = op_readpc();
bit = dp >> 13;
dp &= 0x1fff;
rd = op_read(dp);
switch(opcode >> 5) {
case 0: //orc addr:bit
case 1: //orc !addr:bit
op_io();
regs.p.c |= (rd & (1 << bit)) ^ (bool)(opcode & 0x20);
break;
case 2: //and addr:bit
case 3: //and !addr:bit
regs.p.c &= (rd & (1 << bit)) ^ (bool)(opcode & 0x20);
break;
case 4: //eor addr:bit
op_io();
Update to v085 release. byuu says: A new release for the new year. Changelog: fixed auto joypad polling edge case; fixes Ys 5 controls fixed Justifier polling code; Lethal Enforcers should be fully responsive once again rewrote SNES S-SMP processor core (~20% code reduction) fixed Game Boy 8x16 sprite mode; fixed some sprites in Zelda: Link's Awakening treat Game Boy HuC1 RAM enable flag as writable flag instead; fixes Pokemon Card GB created far faster XML parser; bsnes can now load XML files once again updated to mightymo's most recent cheat code database internal color calculations now performed at 30-bits per pixel gamma slider now acts as fine-tuned gamma ramp option Linux OpenGL driver will output at 30bpp on capable displays Linux port defaults to GTK+ now instead of Qt (both are still available)
2012-01-03 12:56:24 +00:00
regs.p.c ^= (bool)(rd & (1 << bit));
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
break;
case 5: //ldc addr:bit
regs.p.c = (rd & (1 << bit));
break;
case 6: //stc addr:bit
op_io();
rd = (rd & ~(1 << bit)) | (regs.p.c << bit);
op_write(dp, rd);
break;
case 7: //not addr:bit
rd ^= 1 << bit;
op_write(dp, rd);
break;
}
}
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_set_bit() -> void {
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
dp = op_readpc();
rd = op_readdp(dp) & ~(1 << (opcode >> 5));
op_writedp(dp, rd | (!(opcode & 0x10) << (opcode >> 5)));
}
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_set_flag(bool& flag, bool data) -> void {
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
op_io();
if(&flag == &regs.p.i) op_io();
flag = data;
}
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_test_addr(bool set) -> void {
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
dp.l = op_readpc();
dp.h = op_readpc();
rd = op_read(dp);
regs.p.n = (regs.a - rd) & 0x80;
regs.p.z = (regs.a - rd) == 0;
op_read(dp);
op_write(dp, set ? rd | regs.a : rd & ~regs.a);
}
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_transfer(uint8& from, uint8& to) -> void {
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
op_io();
to = from;
if(&to == &regs.s) return;
regs.p.n = (to & 0x80);
regs.p.z = (to == 0);
}
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_write_addr(uint8& r) -> void {
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
dp.l = op_readpc();
dp.h = op_readpc();
op_read(dp);
op_write(dp, 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_write_addri(uint8& i) -> void {
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
dp.l = op_readpc();
dp.h = op_readpc();
op_io();
dp += i;
op_read(dp);
op_write(dp, regs.a);
}
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_write_dp(uint8& r) -> void {
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
dp = op_readpc();
op_readdp(dp);
op_writedp(dp, 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_write_dpi(uint8& r, uint8& i) -> void {
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
dp = op_readpc() + i;
op_io();
op_readdp(dp);
op_writedp(dp, 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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_write_dp_const() -> void {
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
rd = op_readpc();
dp = op_readpc();
wr = op_readdp(dp);
wr = call(wr, rd);
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
op != &SPC700::op_cmp ? op_writedp(dp, wr) : op_io();
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_write_dp_dp() -> void {
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
sp = op_readpc();
rd = op_readdp(sp);
dp = op_readpc();
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
if(op != &SPC700::op_st) wr = op_readdp(dp);
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
wr = call(wr, rd);
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
op != &SPC700::op_cmp ? op_writedp(dp, wr) : op_io();
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
template<auto (SPC700::*op)(uint8, uint8) -> uint8>
auto SPC700::op_write_ix_iy() -> void {
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
op_io();
rd = op_readdp(regs.y);
wr = op_readdp(regs.x);
wr = call(wr, rd);
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
op != &SPC700::op_cmp ? op_writedp(regs.x, wr) : op_io();
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_bne_dp() -> void {
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
dp = op_readpc();
sp = op_readdp(dp);
rd = op_readpc();
op_io();
if(regs.a == sp) return;
op_io();
op_io();
regs.pc += (int8)rd;
}
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_bne_dpdec() -> void {
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
dp = op_readpc();
wr = op_readdp(dp);
op_writedp(dp, --wr);
rd = op_readpc();
if(wr == 0) return;
op_io();
op_io();
regs.pc += (int8)rd;
}
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_bne_dpx() -> void {
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
dp = op_readpc();
op_io();
sp = op_readdp(dp + regs.x);
rd = op_readpc();
op_io();
if(regs.a == sp) return;
op_io();
op_io();
regs.pc += (int8)rd;
}
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_bne_ydec() -> void {
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
rd = op_readpc();
op_io();
op_io();
if(--regs.y == 0) return;
op_io();
op_io();
regs.pc += (int8)rd;
}
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_brk() -> void {
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
rd.l = op_read(0xffde);
rd.h = op_read(0xffdf);
op_io();
op_io();
op_writesp(regs.pc.h);
op_writesp(regs.pc.l);
op_writesp(regs.p);
regs.pc = rd;
regs.p.b = 1;
regs.p.i = 0;
}
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_clv() -> void {
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
op_io();
regs.p.v = 0;
regs.p.h = 0;
}
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_cmc() -> void {
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
op_io();
op_io();
regs.p.c = !regs.p.c;
}
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_daa() -> void {
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
op_io();
op_io();
if(regs.p.c || (regs.a) > 0x99) {
regs.a += 0x60;
regs.p.c = 1;
}
if(regs.p.h || (regs.a & 15) > 0x09) {
regs.a += 0x06;
}
regs.p.n = (regs.a & 0x80);
regs.p.z = (regs.a == 0);
}
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_das() -> void {
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
op_io();
op_io();
if(!regs.p.c || (regs.a) > 0x99) {
regs.a -= 0x60;
regs.p.c = 0;
}
if(!regs.p.h || (regs.a & 15) > 0x09) {
regs.a -= 0x06;
}
regs.p.n = (regs.a & 0x80);
regs.p.z = (regs.a == 0);
}
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_div_ya_x() -> void {
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
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
ya = regs.ya;
//overflow set if quotient >= 256
regs.p.v = (regs.y >= regs.x);
regs.p.h = ((regs.y & 15) >= (regs.x & 15));
if(regs.y < (regs.x << 1)) {
//if quotient is <= 511 (will fit into 9-bit result)
regs.a = ya / regs.x;
regs.y = ya % regs.x;
} else {
//otherwise, the quotient won't fit into regs.p.v + regs.a
//this emulates the odd behavior of the S-SMP in this case
regs.a = 255 - (ya - (regs.x << 9)) / (256 - regs.x);
regs.y = regs.x + (ya - (regs.x << 9)) % (256 - regs.x);
}
//result is set based on a (quotient) only
regs.p.n = (regs.a & 0x80);
regs.p.z = (regs.a == 0);
}
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_jmp_addr() -> void {
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
rd.l = op_readpc();
rd.h = op_readpc();
regs.pc = rd;
}
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_jmp_iaddrx() -> void {
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
dp.l = op_readpc();
dp.h = op_readpc();
op_io();
dp += regs.x;
rd.l = op_read(dp++);
rd.h = op_read(dp++);
regs.pc = rd;
}
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_jsp_dp() -> void {
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
rd = op_readpc();
op_io();
op_io();
op_writesp(regs.pc.h);
op_writesp(regs.pc.l);
regs.pc = 0xff00 | rd;
}
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_jsr_addr() -> void {
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
rd.l = op_readpc();
rd.h = op_readpc();
op_io();
op_io();
op_io();
op_writesp(regs.pc.h);
op_writesp(regs.pc.l);
regs.pc = rd;
}
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_jst() -> void {
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
dp = 0xffde - ((opcode >> 4) << 1);
rd.l = op_read(dp++);
rd.h = op_read(dp++);
op_io();
op_io();
op_io();
op_writesp(regs.pc.h);
op_writesp(regs.pc.l);
regs.pc = rd;
}
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_lda_ixinc() -> void {
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
op_io();
regs.a = op_readdp(regs.x++);
op_io();
regs.p.n = regs.a & 0x80;
regs.p.z = regs.a == 0;
}
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_mul_ya() -> void {
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
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
op_io();
ya = regs.y * regs.a;
regs.a = ya;
regs.y = ya >> 8;
//result is set based on y (high-byte) only
regs.p.n = (regs.y & 0x80);
regs.p.z = (regs.y == 0);
}
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_nop() -> void {
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
op_io();
}
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_plp() -> void {
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
op_io();
op_io();
regs.p = op_readsp();
}
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_rti() -> void {
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 = op_readsp();
rd.l = op_readsp();
rd.h = op_readsp();
op_io();
op_io();
regs.pc = rd;
}
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_rts() -> void {
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
rd.l = op_readsp();
rd.h = op_readsp();
op_io();
op_io();
regs.pc = rd;
}
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_sta_idpx() -> void {
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
sp = op_readpc() + regs.x;
op_io();
dp.l = op_readdp(sp++);
dp.h = op_readdp(sp++);
op_read(dp);
op_write(dp, regs.a);
}
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_sta_idpy() -> void {
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
sp = op_readpc();
dp.l = op_readdp(sp++);
dp.h = op_readdp(sp++);
op_io();
dp += regs.y;
op_read(dp);
op_write(dp, regs.a);
}
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_sta_ix() -> void {
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
op_io();
op_readdp(regs.x);
op_writedp(regs.x, regs.a);
}
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_sta_ixinc() -> void {
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
op_io();
op_io();
op_writedp(regs.x++, regs.a);
}
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_stw_dp() -> void {
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
dp = op_readpc();
op_readdp(dp);
op_writedp(dp++, regs.a);
op_writedp(dp++, regs.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_wait() -> void {
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
while(true) {
op_io();
op_io();
}
}
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_xcn() -> void {
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
op_io();
op_io();
op_io();
op_io();
regs.a = (regs.a >> 4) | (regs.a << 4);
regs.p.n = regs.a & 0x80;
regs.p.z = regs.a == 0;
}
#undef call