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

306 lines
12 KiB
C++
Raw Normal View History

Update to v095r08 release. byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course.
2015-11-21 07:36:48 +00:00
auto SPC700::disassemble(uint16 addr, bool p) -> string {
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
auto read = [&](uint16 addr) -> uint8 {
Update to v099r12 release. byuu says: Changelog: - fixed FC AxROM / VRC7 regression - BitField split to BooleanBitField/NaturalBitField (in preparation for IntegerBitField) - BitFieldReference removed - GB CPU cleaned up - GB Cartridge + Mappers cleaned up - SFC CGRAM is now emulated as uint15[256] instead of uint[512] - sfc/ppu/memory.cpp no longer needed; removed - purged SFC Debugger hooks for now (some of the operator[] calls were bypassing them anyway) Unfortunately, for reasons that defy all semblance of logic, the CGRAM change caused a slight speed hit. As have the last few changes. We're now down to around 129.5fps compared to 123.fps for v099 and 134.5fps at our peak (v099r01-r02). I really like the style I came up with for the Game Boy mappers to settle the purpose(ROM,RAM) vs (rom,ram)Purpose naming convention. If I ever get around to redoing the NES mappers, that's likely the approach I'll take.
2016-06-28 10:43:47 +00:00
return readDisassembler(addr);
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 relative = [&](uint length, int8 offset) -> uint16 {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
uint16 pc = addr + length;
return pc + offset;
};
Update to v094r37 release. byuu says: Changelog: - synchronizes lots of nall changes - changes displayed program title from tomoko to higan(*) - browser dialog sort is case-insensitive - .sys folders look at user-selected library path; no longer hard-coded Tried to get rid of the file modes from the Windows browser dialog, but it was being a bitch so I left it on for now. - The storage locations and binary still use tomoko. I'm not really sure what to do here. The idea is there may be more than one "higan" UI in the future, but I don't want people to go around calling the entire program by the UI name. For official Windows releases, I can rename the binaries to "higan-{profile}.exe", and by putting the config files with the binary, they won't ever see the tomoko folder. Linux is of course trickier. Note: Windows users will need to edit hiro/components.hpp and comment out these lines: #define Hiro_Console #define Hiro_IconView #define Hiro_SourceView #define Hiro_TreeView I forgot to do that, and too lazy to upload another WIP.
2015-07-14 09:32:43 +00:00
auto a = [&] { return hex((read(addr + 1) << 0) + (read(addr + 2) << 8), 4L); };
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 b = [&](uint n) { return hex(read(addr + 1 + n), 2L); };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
auto rel = [&](uint r, uint n = 0) { return hex(addr + r + (int8)read(addr + 1 + n), 4L); };
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 dp = [&](uint n) { return hex((p << 8) + read(addr + 1 + n), 3L); };
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
auto ab = [&] {
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
uint n = (read(addr + 1) << 0) + (read(addr + 2) << 8);
return string{hex(n & 0x1fff, 4L), ":", hex(n >> 13, 1L)};
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
};
auto mnemonic = [&]() -> string {
switch(read(addr)) {
case 0x00: return { "nop" };
case 0x01: return { "jst $ffde" };
case 0x02: return { "set $", dp(0), ":0" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x03: return { "bbs $", dp(0), ":0=$", rel(+3, 1) };
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
case 0x04: return { "ora $", dp(0) };
case 0x05: return { "ora $", a() };
case 0x06: return { "ora (x)" };
case 0x07: return { "ora ($", dp(0), ",x)" };
case 0x08: return { "ora #$", b(0) };
case 0x09: return { "orr $", dp(1), "=$", dp(0) };
case 0x0a: return { "orc $", ab() };
case 0x0b: return { "asl $", dp(0) };
case 0x0c: return { "asl $", a() };
case 0x0d: return { "php" };
case 0x0e: return { "tsb $", a() };
case 0x0f: return { "brk" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x10: return { "bpl $", rel(+2) };
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
case 0x11: return { "jst $ffdc" };
case 0x12: return { "clr $", dp(0), ":0" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x13: return { "bbc $", dp(0), ":0=$", rel(+3, 1) };
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
case 0x14: return { "ora $", dp(0), ",x" };
case 0x15: return { "ora $", a(), ",x" };
case 0x16: return { "ora $", a(), ",y" };
case 0x17: return { "ora ($", dp(0), "),y" };
case 0x18: return { "orr $", dp(1), "=#$", b(0) };
case 0x19: return { "orr (x)=(y)" };
case 0x1a: return { "dew $", dp(0) };
case 0x1b: return { "asl $", dp(0), ",x" };
case 0x1c: return { "asl" };
case 0x1d: return { "dex" };
case 0x1e: return { "cpx $", a() };
case 0x1f: return { "jmp ($", a(), ",x)" };
case 0x20: return { "clp" };
case 0x21: return { "jst $ffda" };
case 0x22: return { "set $", dp(0), ":1" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x23: return { "bbs $", dp(0), ":1=$", rel(+3, 1) };
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
case 0x24: return { "and $", dp(0) };
case 0x25: return { "and $", a() };
case 0x26: return { "and (x)" };
case 0x27: return { "and ($", dp(0), ",x)" };
Update to v102r27 release. byuu says: Changelog: - processor/gsu: minor code cleanup - processor/hg51b: renamed reg(Read,Write) to register(Read,Write) - processor/lr35902: minor code cleanup - processor/spc700: completed code cleanup (sans disassembler) - no longer uses internal global state inside instructions - processor/spc700: will no longer hang the emulator if stuck in a WAI (SLEEP) or STP (STOP) instruction - processor/spc700: fixed bug in handling of OR1 and AND1 instructions - processor/z80: minor code cleanup - sfc/dsp: revert to initializing registers to 0x00; save for ENDX=random(), FLG=0xe0 [Jonas Quinn] Major testing of the SNES game library would be appreciated, now that its CPU cores have all been revised. We know the DSP registers read back as randomized data ... mostly, but there are apparently internal latches, which we can't emulate with the current DSP design. So until we know which registers have separate internal state that actually *is* initialized, I'm going to play it safe and not break more games. Thanks again to Jonas Quinn for the continued research into this issue. EDIT: that said ... `MD works if((ENDX&0x30) > 0)` is only a 3:4 chance that the game will work. That seems pretty unlikely that the odds of it working are that low, given hardware testing by others in the past :/ I thought if worked if `PITCH != 0` before, which would have been way more likely. The two remaining CPU cores that need major cleanup efforts are the LR35902 and ARM cores. Both are very large, complicated, annoying cores that will probably be better off as full rewrites from scratch. I don't think I want to delay v103 in trying to accomplish that, however. So I think it'll be best to focus on allowing the Mega Drive core to not lock when processors are frozen waiting on a response from other processors during a save state operation. Then we should be good for a new release.
2017-06-19 02:07:54 +00:00
case 0x28: return { "and #$", b(0) };
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
case 0x29: return { "and $", dp(1), "=$", dp(0) };
case 0x2a: return { "orc !$", ab() };
case 0x2b: return { "rol $", dp(0) };
case 0x2c: return { "rol $", a() };
case 0x2d: return { "pha" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x2e: return { "bne $", dp(0), "=$", rel(+3, 1) };
case 0x2f: return { "bra $", rel(+2) };
case 0x30: return { "bmi $", rel(+2) };
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
case 0x31: return { "jst $ffd8" };
case 0x32: return { "clr $", dp(0), ":1" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x33: return { "bbc $", dp(0), ":1=$", rel(+3, 1) };
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
case 0x34: return { "and $", dp(0), ",x" };
case 0x35: return { "and $", a(), ",x" };
case 0x36: return { "and $", a(), ",y" };
case 0x37: return { "and ($", dp(0), "),y" };
case 0x38: return { "and $", dp(1), "=#$", b(0) };
case 0x39: return { "and (x)=(y)" };
case 0x3a: return { "inw $", dp(0) };
case 0x3b: return { "rol $", dp(0), ",x" };
case 0x3c: return { "rol" };
case 0x3d: return { "inx" };
case 0x3e: return { "cpx $", dp(0) };
case 0x3f: return { "jsr $", a() };
case 0x40: return { "sep" };
case 0x41: return { "jst $ffd6" };
case 0x42: return { "set $", dp(0), ":2" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x43: return { "bbs $", dp(0), ":2=$", rel(+3, 1) };
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
case 0x44: return { "eor $", dp(0) };
case 0x45: return { "eor $", a() };
case 0x46: return { "eor (x)" };
case 0x47: return { "eor ($", dp(0), ",x)" };
case 0x48: return { "eor #$", b(0) };
case 0x49: return { "eor $", dp(1), "=$", dp(0) };
case 0x4a: return { "and $", ab() };
case 0x4b: return { "lsr $", dp(0) };
case 0x4c: return { "lsr $", a() };
case 0x4d: return { "phx" };
case 0x4e: return { "trb $", a() };
case 0x4f: return { "jsp $ff", b(0) };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x50: return { "bvc $", rel(+2) };
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
case 0x51: return { "jst $ffd4" };
case 0x52: return { "clr $", dp(0), ":2" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x53: return { "bbc $", dp(0), ":2=$", rel(+3, 1) };
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
case 0x54: return { "eor $", dp(0), ",x" };
case 0x55: return { "eor $", a(), ",x" };
case 0x56: return { "eor $", a(), ",y" };
case 0x57: return { "eor ($", dp(0), "),y" };
case 0x58: return { "eor $", dp(1), "=#$", b(0) };
case 0x59: return { "eor (x)=(y)" };
case 0x5a: return { "cpw $", a() };
case 0x5b: return { "lsr $", dp(0), ",x" };
case 0x5c: return { "lsr" };
case 0x5d: return { "tax" };
case 0x5e: return { "cpy $", a() };
case 0x5f: return { "jmp $", a() };
case 0x60: return { "clc" };
case 0x61: return { "jst $ffd2" };
case 0x62: return { "set $", dp(0), ":3" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x63: return { "bbs $", dp(0), ":3=$", rel(+3, 1) };
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
case 0x64: return { "cmp $", dp(0) };
case 0x65: return { "cmp $", a() };
case 0x66: return { "cmp (x)" };
case 0x67: return { "cmp ($", dp(0), ",x)" };
case 0x68: return { "cmp #$", b(0) };
case 0x69: return { "cmp $", dp(1), "=$", dp(0) };
case 0x6a: return { "and !$", ab() };
case 0x6b: return { "ror $", dp(0) };
case 0x6c: return { "ror $", a() };
case 0x6d: return { "phy" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x6e: return { "bne --$", dp(0), "=$", rel(+3, 1) };
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
case 0x6f: return { "rts" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x70: return { "bvs $", rel(+2) };
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
case 0x71: return { "jst $ffd0" };
case 0x72: return { "clr $", dp(0), ":3" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x73: return { "bbc $", dp(0), ":3=$", rel(+3, 1) };
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
case 0x74: return { "cmp $", dp(0), ",x" };
case 0x75: return { "cmp $", a(), ",x" };
case 0x76: return { "cmp $", a(), ",y" };
case 0x77: return { "cmp ($", dp(0), "),y" };
case 0x78: return { "cmp $", dp(1), "=#$", b(0) };
case 0x79: return { "cmp (x)=(y)" };
case 0x7a: return { "adw $", a() };
case 0x7b: return { "ror $", dp(0), ",x" };
case 0x7c: return { "ror" };
case 0x7d: return { "txa" };
case 0x7e: return { "cpy $", dp(0) };
case 0x7f: return { "rti" };
case 0x80: return { "sec" };
case 0x81: return { "jst $ffce" };
case 0x82: return { "set $", dp(0), ":4" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x83: return { "bbs $", dp(0), ":4=$", rel(+3, 1) };
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
case 0x84: return { "adc $", dp(0) };
case 0x85: return { "adc $", a() };
case 0x86: return { "adc (x)" };
case 0x87: return { "adc ($", dp(0), ",x)" };
case 0x88: return { "adc #$", b(0) };
case 0x89: return { "adc $", dp(1), "=$", dp(0) };
case 0x8a: return { "eor $", ab() };
case 0x8b: return { "dec $", dp(0) };
case 0x8c: return { "dec $", a() };
case 0x8d: return { "ldy #$", b(0) };
case 0x8e: return { "plp" };
case 0x8f: return { "str $", dp(1), "=#$", b(0) };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x90: return { "bcc $", rel(+2) };
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
case 0x91: return { "jst $ffcc" };
case 0x92: return { "clr $", dp(0), ":4" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0x93: return { "bbc $", dp(0), ":4=$", rel(+3, 1) };
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
case 0x94: return { "adc $", dp(0), ",x" };
case 0x95: return { "adc $", a(), ",x" };
case 0x96: return { "adc $", a(), ",y" };
case 0x97: return { "adc ($", dp(0), "),y" };
case 0x98: return { "adc $", dp(1), "=#$", b(0) };
case 0x99: return { "adc (x)=(y)" };
case 0x9a: return { "sbw $", a() };
case 0x9b: return { "dec $", dp(0), ",x" };
case 0x9c: return { "dec" };
case 0x9d: return { "tsx" };
case 0x9e: return { "div" };
case 0x9f: return { "xcn" };
case 0xa0: return { "sei" };
case 0xa1: return { "jst $ffca" };
case 0xa2: return { "set $", dp(0), ":5" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xa3: return { "bbs $", dp(0), ":5=$", rel(+3, 1) };
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
case 0xa4: return { "sbc $", dp(0) };
case 0xa5: return { "sbc $", a() };
case 0xa6: return { "sbc (x)" };
case 0xa7: return { "sbc ($", dp(0), ",x)" };
case 0xa8: return { "sbc #$", b(0) };
case 0xa9: return { "sbc $", dp(1), "=$", dp(0) };
case 0xaa: return { "ldc $", ab() };
case 0xab: return { "inc $", dp(0) };
case 0xac: return { "inc $", a() };
case 0xad: return { "cpy #$", b(0) };
case 0xae: return { "pla" };
case 0xaf: return { "sta (x++)" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xb0: return { "bcs $", rel(+2) };
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
case 0xb1: return { "jst $ffc8" };
case 0xb2: return { "clr $", dp(0), ":5" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xb3: return { "bbc $", dp(0), ":5=$", rel(+3, 1) };
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
case 0xb4: return { "sbc $", dp(0), ",x" };
case 0xb5: return { "sbc $", a(), ",x" };
case 0xb6: return { "sbc $", a(), ",y" };
case 0xb7: return { "sbc ($", dp(0), "),y" };
case 0xb8: return { "sbc $", dp(1), "=#$", b(0) };
case 0xb9: return { "sbc (x)=(y)" };
case 0xba: return { "ldw $", dp(0) };
case 0xbb: return { "inc $", dp(0), ",x" };
case 0xbc: return { "inc" };
case 0xbd: return { "txs" };
case 0xbe: return { "das" };
case 0xbf: return { "lda (x++)" };
case 0xc0: return { "cli" };
case 0xc1: return { "jst $ffc6" };
case 0xc2: return { "set $", dp(0), ":6" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xc3: return { "bbs $", dp(0), ":6=$", rel(+3, 1) };
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
case 0xc4: return { "sta $", dp(0) };
case 0xc5: return { "sta $", a() };
case 0xc6: return { "sta (x)" };
case 0xc7: return { "sta ($", dp(0), ",x)" };
case 0xc8: return { "cpx #$", b(0) };
case 0xc9: return { "stx $", a() };
case 0xca: return { "stc $", ab() };
case 0xcb: return { "sty $", dp(0) };
case 0xcc: return { "sty $", a() };
case 0xcd: return { "ldx #$", b(0) };
case 0xce: return { "plx" };
case 0xcf: return { "mul" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xd0: return { "bne $", rel(+2) };
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
case 0xd1: return { "jst $ffc4" };
case 0xd2: return { "clr $", dp(0), ":6" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xd3: return { "bbc $", dp(0), ":6=$", rel(+3, 1) };
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
case 0xd4: return { "sta $", dp(0), ",x" };
case 0xd5: return { "sta $", a(), ",x" };
case 0xd6: return { "sta $", a(), ",y" };
case 0xd7: return { "sta ($", dp(0), "),y" };
case 0xd8: return { "stx $", dp(0) };
case 0xd9: return { "stx $", dp(0), ",y" };
case 0xda: return { "stw $", dp(0) };
case 0xdb: return { "sty $", dp(0), ",x" };
case 0xdc: return { "dey" };
case 0xdd: return { "tya" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xde: return { "bne $", dp(0), ",x=$", rel(+3, 1) };
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
case 0xdf: return { "daa" };
case 0xe0: return { "clv" };
case 0xe1: return { "jst $ffc2" };
case 0xe2: return { "set $", dp(0), ":7" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xe3: return { "bbs $", dp(0), ":7=$", rel(+3, 1) };
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
case 0xe4: return { "lda $", dp(0) };
case 0xe5: return { "lda $", a() };
case 0xe6: return { "lda (x)" };
case 0xe7: return { "lda ($", dp(0), ",x)" };
case 0xe8: return { "lda #$", b(0) };
case 0xe9: return { "ldx $", a() };
case 0xea: return { "not $", ab() };
case 0xeb: return { "ldy $", dp(0) };
case 0xec: return { "ldy $", a() };
case 0xed: return { "cmc" };
case 0xee: return { "ply" };
case 0xef: return { "wai" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xf0: return { "beq $", rel(+2) };
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
case 0xf1: return { "jst $ffc0" };
case 0xf2: return { "clr $", dp(0), ":7" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xf3: return { "bbc $", dp(0), ":7=$", rel(+3, 1) };
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
case 0xf4: return { "lda $", dp(0), ",x" };
case 0xf5: return { "lda $", a(), ",x" };
case 0xf6: return { "lda $", a(), ",y" };
case 0xf7: return { "lda ($", dp(0), "),y" };
case 0xf8: return { "ldx $", dp(0) };
case 0xf9: return { "ldx $", dp(0), ",y" };
case 0xfa: return { "str $", dp(1), "=$", dp(0) };
case 0xfb: return { "ldy $", dp(0), ",x" };
case 0xfc: return { "iny" };
case 0xfd: return { "tay" };
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
case 0xfe: return { "bne --y=$", rel(+2) };
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
case 0xff: return { "stp" };
}
throw;
};
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
string output = {"..", hex(addr, 4L), " ", mnemonic()};
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
uint length = output.length();
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(length++ < 30) output.append(" ");
output.append(
Update to v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
"YA:", hex(YA, 4L),
" A:", hex(A, 2L),
" X:", hex(X, 2L),
" Y:", hex(Y, 2L),
" S:", hex(S, 2L),
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 v102r26 release. byuu says: Changelog: - md/ym2612: initialize DAC sample to center volume [Cydrak] - processor/arm: add accumulate mode extra cycle to mlal [Jonas Quinn] - processor/huc6280: split off algorithms, improve naming of functions - processor/mos6502: split off algorithms - processor/spc700: major revamp of entire core (~50% completed) - processor/wdc65816: fixed several bugs introduced by rewrite For the SPC700, this turns out to be very old code as well, with global object state variables, those annoying `{Boolean,Natural}BitField` types, `under_case` naming conventions, heavily abbreviated function names, etc. I'm working to get the code to be in the same design as the MOS6502, HuC6280, WDC65816 cores, since they're all extremely similar in terms of architectural design (the SPC700 is more of an off-label reimplementation of a 6502 core, but still.) The main thing left is that about 90% of the actual instructions still need to be adapted to not use the internal state (`aa`, `rd`, `dp`, `sp`, `bit` variables.) I wanted to finish this today, but ran out of time before work. I wouldn't suggest too much testing just yet. We should wait until the SPC700 core is finished for that. However, if some does want to and spots regressions, please let me know.
2017-06-16 00:06:17 +00:00
NF ? "N" : "n",
VF ? "V" : "v",
PF ? "P" : "p",
BF ? "B" : "b",
HF ? "H" : "h",
IF ? "I" : "i",
ZF ? "Z" : "z",
CF ? "C" : "c"
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
);
return output;
}