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

542 lines
9.1 KiB
C++
Raw Normal View History

Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
#define call (this->*op)
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_adjust(fps op, reg r) {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
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
r = call(r);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_adjust_addr(fps op) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readPC();
dp.h = readPC();
rd = read(dp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
rd = call(rd);
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
write(dp, rd);
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_adjust_dp(fps op) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
rd = readDP(dp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
rd = call(rd);
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
writeDP(dp, rd);
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_adjust_dpw(int n) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
rd.w = readDP(dp) + n;
writeDP(dp++, rd.l);
rd.h += readDP(dp);
writeDP(dp++, rd.h);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.n = rd & 0x8000;
regs.p.z = rd == 0;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_adjust_dpx(fps op) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readDP(dp + regs.x);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
rd = call(rd);
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
writeDP(dp + regs.x, rd);
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_branch(bool condition) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readPC();
if(!condition) return;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc += (int8)rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_branch_bit() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
sp = readDP(dp);
rd = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
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
if((bool)(sp & (1 << (opcode >> 5))) == (bool)(opcode & 0x10)) return;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc += (int8)rd;
}
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_pull(reg r) {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
r = readSP();
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_push(uint8 r) {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
writeSP(r);
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 v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_read_addr(fpb op, reg r) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readPC();
dp.h = readPC();
rd = read(dp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
r = call(r, rd);
}
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_read_addri(fpb op, reg r) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readPC();
dp.h = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = read(dp + r);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.a = call(regs.a, rd);
}
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_read_const(fpb op, reg r) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readPC();
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
r = call(r, rd);
}
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_read_dp(fpb op, reg r) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
rd = readDP(dp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
r = call(r, rd);
}
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_read_dpi(fpb op, reg r, reg i) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readDP(dp + i);
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
r = call(r, rd);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_read_dpw(fpw op) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
rd.l = readDP(dp++);
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
if(op != &SPC700::op_cpw) idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd.h = readDP(dp++);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.ya = call(regs.ya, rd);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_read_idpx(fpb op) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC() + regs.x;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
sp.l = readDP(dp++);
sp.h = readDP(dp++);
rd = read(sp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.a = call(regs.a, rd);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_read_idpy(fpb op) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
sp.l = readDP(dp++);
sp.h = readDP(dp++);
rd = read(sp + regs.y);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.a = call(regs.a, rd);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_read_ix(fpb op) {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readDP(regs.x);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.a = call(regs.a, rd);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_set_addr_bit() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readPC();
dp.h = readPC();
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
bit = dp >> 13;
dp &= 0x1fff;
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = read(dp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
switch(opcode >> 5) {
case 0: //orc addr:bit
case 1: //orc !addr:bit
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.c |= (rd & (1 << bit)) ^ (bool)(opcode & 0x20);
break;
case 2: //and addr:bit
case 3: //and !addr:bit
regs.p.c &= (rd & (1 << bit)) ^ (bool)(opcode & 0x20);
break;
case 4: //eor addr:bit
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v085 release. byuu says: A new release for the new year. Changelog: fixed auto joypad polling edge case; fixes Ys 5 controls fixed Justifier polling code; Lethal Enforcers should be fully responsive once again rewrote SNES S-SMP processor core (~20% code reduction) fixed Game Boy 8x16 sprite mode; fixed some sprites in Zelda: Link's Awakening treat Game Boy HuC1 RAM enable flag as writable flag instead; fixes Pokemon Card GB created far faster XML parser; bsnes can now load XML files once again updated to mightymo's most recent cheat code database internal color calculations now performed at 30-bits per pixel gamma slider now acts as fine-tuned gamma ramp option Linux OpenGL driver will output at 30bpp on capable displays Linux port defaults to GTK+ now instead of Qt (both are still available)
2012-01-03 12:56:24 +00:00
regs.p.c ^= (bool)(rd & (1 << bit));
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
break;
case 5: //ldc addr:bit
regs.p.c = (rd & (1 << bit));
break;
case 6: //stc addr:bit
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
rd = (rd & ~(1 << bit)) | (regs.p.c << bit);
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
write(dp, rd);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
break;
case 7: //not addr:bit
rd ^= 1 << bit;
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
write(dp, rd);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
break;
}
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_set_bit() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
rd = readDP(dp) & ~(1 << (opcode >> 5));
writeDP(dp, rd | (!(opcode & 0x10) << (opcode >> 5)));
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 v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_set_flag(uint bit, bool value) {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
if(bit == regs.p.i.bit) idle();
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
regs.p = value ? (regs.p | (1 << bit)) : (regs.p & ~(1 << bit));
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_test_addr(bool set) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readPC();
dp.h = readPC();
rd = read(dp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.n = (regs.a - rd) & 0x80;
regs.p.z = (regs.a - rd) == 0;
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
read(dp);
write(dp, set ? rd | regs.a : rd & ~regs.a);
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 v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_transfer(reg from, reg to) {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
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
to = from;
if(&to == &regs.s) return;
regs.p.n = (to & 0x80);
regs.p.z = (to == 0);
}
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_write_addr(reg r) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readPC();
dp.h = readPC();
read(dp);
write(dp, r);
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 v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_write_addri(reg i) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readPC();
dp.h = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
dp += i;
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
read(dp);
write(dp, regs.a);
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 v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_write_dp(reg r) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
readDP(dp);
writeDP(dp, r);
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 v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
auto SPC700::op_write_dpi(reg r, reg i) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC() + i;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
readDP(dp);
writeDP(dp, r);
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_write_dp_const(fpb op) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readPC();
dp = readPC();
wr = readDP(dp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
wr = call(wr, rd);
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
op != &SPC700::op_cmp ? writeDP(dp, wr) : idle();
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_write_dp_dp(fpb op) {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
sp = readPC();
rd = readDP(sp);
dp = readPC();
if(op != &SPC700::op_st) wr = readDP(dp);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
wr = call(wr, rd);
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
op != &SPC700::op_cmp ? writeDP(dp, wr) : idle();
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_write_ix_iy(fpb op) {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readDP(regs.y);
wr = readDP(regs.x);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
wr = call(wr, rd);
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
op != &SPC700::op_cmp ? writeDP(regs.x, wr) : idle();
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_bne_dp() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
sp = readDP(dp);
rd = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
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
if(regs.a == sp) return;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc += (int8)rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_bne_dpdec() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
wr = readDP(dp);
writeDP(dp, --wr);
rd = readPC();
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
if(wr == 0) return;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc += (int8)rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_bne_dpx() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
sp = readDP(dp + regs.x);
rd = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
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
if(regs.a == sp) return;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc += (int8)rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_bne_ydec() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
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
if(--regs.y == 0) return;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc += (int8)rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_brk() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd.l = read(0xffde);
rd.h = read(0xffdf);
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
writeSP(regs.pc.h);
writeSP(regs.pc.l);
writeSP(regs.p);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc = rd;
regs.p.b = 1;
regs.p.i = 0;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_clv() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.v = 0;
regs.p.h = 0;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_cmc() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.c = !regs.p.c;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_daa() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
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
if(regs.p.c || (regs.a) > 0x99) {
regs.a += 0x60;
regs.p.c = 1;
}
if(regs.p.h || (regs.a & 15) > 0x09) {
regs.a += 0x06;
}
regs.p.n = (regs.a & 0x80);
regs.p.z = (regs.a == 0);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_das() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
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
if(!regs.p.c || (regs.a) > 0x99) {
regs.a -= 0x60;
regs.p.c = 0;
}
if(!regs.p.h || (regs.a & 15) > 0x09) {
regs.a -= 0x06;
}
regs.p.n = (regs.a & 0x80);
regs.p.z = (regs.a == 0);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_div_ya_x() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
idle();
idle();
idle();
idle();
idle();
idle();
idle();
idle();
idle();
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
ya = regs.ya;
//overflow set if quotient >= 256
regs.p.v = (regs.y >= regs.x);
regs.p.h = ((regs.y & 15) >= (regs.x & 15));
if(regs.y < (regs.x << 1)) {
//if quotient is <= 511 (will fit into 9-bit result)
regs.a = ya / regs.x;
regs.y = ya % regs.x;
} else {
//otherwise, the quotient won't fit into regs.p.v + regs.a
//this emulates the odd behavior of the S-SMP in this case
regs.a = 255 - (ya - (regs.x << 9)) / (256 - regs.x);
regs.y = regs.x + (ya - (regs.x << 9)) % (256 - regs.x);
}
//result is set based on a (quotient) only
regs.p.n = (regs.a & 0x80);
regs.p.z = (regs.a == 0);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_jmp_addr() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd.l = readPC();
rd.h = readPC();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc = rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_jmp_iaddrx() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readPC();
dp.h = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
dp += regs.x;
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd.l = read(dp++);
rd.h = read(dp++);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc = rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_jsp_dp() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
writeSP(regs.pc.h);
writeSP(regs.pc.l);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc = 0xff00 | rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_jsr_addr() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd.l = readPC();
rd.h = readPC();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
writeSP(regs.pc.h);
writeSP(regs.pc.l);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc = rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_jst() {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
dp = 0xffde - ((opcode >> 4) << 1);
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd.l = read(dp++);
rd.h = read(dp++);
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
writeSP(regs.pc.h);
writeSP(regs.pc.l);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc = rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_lda_ixinc() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
regs.a = readDP(regs.x++);
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.p.n = regs.a & 0x80;
regs.p.z = regs.a == 0;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_mul_ya() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
idle();
idle();
idle();
idle();
idle();
idle();
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
ya = regs.y * regs.a;
regs.a = ya;
regs.y = ya >> 8;
//result is set based on y (high-byte) only
regs.p.n = (regs.y & 0x80);
regs.p.z = (regs.y == 0);
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_nop() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_plp() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
regs.p = readSP();
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_rti() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
regs.p = readSP();
rd.l = readSP();
rd.h = readSP();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc = rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_rts() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
rd.l = readSP();
rd.h = readSP();
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.pc = rd;
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_sta_idpx() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
sp = readPC() + regs.x;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp.l = readDP(sp++);
dp.h = readDP(sp++);
read(dp);
write(dp, regs.a);
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_sta_idpy() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
sp = readPC();
dp.l = readDP(sp++);
dp.h = readDP(sp++);
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
dp += regs.y;
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
read(dp);
write(dp, regs.a);
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_sta_ix() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
readDP(regs.x);
writeDP(regs.x, regs.a);
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_sta_ixinc() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
writeDP(regs.x++, regs.a);
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_stw_dp() {
Update to v098r15 release. byuu says: Changelog: - removed template usage from processor/spc700; cleaned up many function names and the switch table - object size: 176.8kb => 127.3kb - source code size: 43.5kb => 37.0kb - fixed processor/r65816 BRK/COP vector regression [hex_usr] - corrected HuC3 unmapped RAM read value; fixes Robopon [endrift] - cosmetic: simplified the butterworth constant calculation [Wolfram|Alpha] The SPC700 core changes took forever, about three hours of work. Only the LR35902 and R6502 still need their template functions removed. The point of this is that it doesn't cause any speed penalty to do so, and it results in smaller binary sizes and faster compilation times.
2016-06-05 04:52:43 +00:00
dp = readPC();
readDP(dp);
writeDP(dp++, regs.a);
writeDP(dp++, regs.y);
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
}
Update to v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_wait() {
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
while(true) {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
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 v098r17 release. byuu says: Changelog: - fixed Super Game Boy regression from v096r04 with bottom tile row flickering - fixed GB STAT IRQ regression from previous WIP - Altered Space is now playable - GBVideoPlayer isn't; but nobody seems to know exactly what weird hardware quirk that one relies on to work - ~3-4% speed improvement in SuperFX games by eliminating function<> callback on register assignments - most noticeable in Doom in-game; least noticeable on Yoshi's Island title screen (darn) - finished GSU core and SuperFX coprocessor code cleanups - did some more work cleaning up the LR35902 core and GB CPU code Just a fair warning: don't get your hopes up on these GB fixes. Cliffhanger now hangs completely (har har), and none of the other bugs are fixed. We pretty much did all this work just for Altered Space. So, I hope you like playing Altered Space.
2016-06-05 22:10:01 +00:00
auto SPC700::op_xcn() {
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
idle();
idle();
idle();
idle();
Update to v084r01 release. I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.) EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside term(). Without it, there is a tiny pop when the driver is re-initialized. But with it, the entire emulator would lock up for five whole seconds waiting on that call to complete. I'll take the pop any day over that.
2011-11-17 12:05:35 +00:00
regs.a = (regs.a >> 4) | (regs.a << 4);
regs.p.n = regs.a & 0x80;
regs.p.z = regs.a == 0;
}
#undef call