2012-04-29 06:16:44 +00:00
|
|
|
#ifndef PROCESSOR_SPC700_HPP
|
|
|
|
#define PROCESSOR_SPC700_HPP
|
|
|
|
|
|
|
|
namespace Processor {
|
|
|
|
|
|
|
|
struct SPC700 {
|
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
|
|
|
virtual void op_io() = 0;
|
|
|
|
virtual uint8 op_read(uint16 addr) = 0;
|
|
|
|
virtual void op_write(uint16 addr, uint8 data) = 0;
|
|
|
|
void op_step();
|
|
|
|
|
2012-04-29 06:16:44 +00:00
|
|
|
virtual uint8 disassembler_read(uint16 addr) = 0;
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
#include "registers.hpp"
|
|
|
|
#include "memory.hpp"
|
|
|
|
|
|
|
|
regs_t regs;
|
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
|
|
|
word_t dp, sp, rd, wr, bit, ya;
|
|
|
|
uint8 opcode;
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2012-04-29 06:16:44 +00:00
|
|
|
void serialize(serializer&);
|
2014-02-09 05:59:46 +00:00
|
|
|
string disassemble_opcode(uint16 addr, bool p);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
protected:
|
|
|
|
uint8 op_adc(uint8, uint8);
|
|
|
|
uint8 op_and(uint8, uint8);
|
|
|
|
uint8 op_asl(uint8);
|
|
|
|
uint8 op_cmp(uint8, uint8);
|
|
|
|
uint8 op_dec(uint8);
|
|
|
|
uint8 op_eor(uint8, uint8);
|
|
|
|
uint8 op_inc(uint8);
|
|
|
|
uint8 op_ld (uint8, uint8);
|
|
|
|
uint8 op_lsr(uint8);
|
|
|
|
uint8 op_or (uint8, uint8);
|
|
|
|
uint8 op_rol(uint8);
|
|
|
|
uint8 op_ror(uint8);
|
|
|
|
uint8 op_sbc(uint8, uint8);
|
|
|
|
uint8 op_st (uint8, uint8);
|
|
|
|
uint16 op_adw(uint16, uint16);
|
|
|
|
uint16 op_cpw(uint16, uint16);
|
|
|
|
uint16 op_ldw(uint16, uint16);
|
|
|
|
uint16 op_sbw(uint16, uint16);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2012-04-29 06:16:44 +00:00
|
|
|
template<uint8 (SPC700::*op)(uint8)> void op_adjust(uint8&);
|
|
|
|
template<uint8 (SPC700::*op)(uint8)> void op_adjust_addr();
|
|
|
|
template<uint8 (SPC700::*op)(uint8)> void op_adjust_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
|
|
|
void op_adjust_dpw(signed);
|
2012-04-29 06:16:44 +00:00
|
|
|
template<uint8 (SPC700::*op)(uint8)> void op_adjust_dpx();
|
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
|
|
|
void op_branch(bool);
|
|
|
|
void op_branch_bit();
|
|
|
|
void op_pull(uint8&);
|
|
|
|
void op_push(uint8);
|
2012-04-29 06:16:44 +00:00
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_read_addr(uint8&);
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_read_addri(uint8&);
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_read_const(uint8&);
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_read_dp(uint8&);
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_read_dpi(uint8&, uint8&);
|
|
|
|
template<uint16 (SPC700::*op)(uint16, uint16)> void op_read_dpw();
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_read_idpx();
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_read_idpy();
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_read_ix();
|
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
|
|
|
void op_set_addr_bit();
|
|
|
|
void op_set_bit();
|
|
|
|
void op_set_flag(bool&, bool);
|
|
|
|
void op_test_addr(bool);
|
|
|
|
void op_transfer(uint8&, uint8&);
|
|
|
|
void op_write_addr(uint8&);
|
|
|
|
void op_write_addri(uint8&);
|
|
|
|
void op_write_dp(uint8&);
|
|
|
|
void op_write_dpi(uint8&, uint8&);
|
2012-04-29 06:16:44 +00:00
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_write_dp_const();
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_write_dp_dp();
|
|
|
|
template<uint8 (SPC700::*op)(uint8, uint8)> void op_write_ix_iy();
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
void op_bne_dp();
|
|
|
|
void op_bne_dpdec();
|
|
|
|
void op_bne_dpx();
|
|
|
|
void op_bne_ydec();
|
|
|
|
void op_brk();
|
|
|
|
void op_clv();
|
|
|
|
void op_cmc();
|
|
|
|
void op_daa();
|
|
|
|
void op_das();
|
|
|
|
void op_div_ya_x();
|
2010-08-09 13:28:56 +00:00
|
|
|
void op_jmp_addr();
|
|
|
|
void op_jmp_iaddrx();
|
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
|
|
|
void op_jsp_dp();
|
|
|
|
void op_jsr_addr();
|
|
|
|
void op_jst();
|
|
|
|
void op_lda_ixinc();
|
|
|
|
void op_mul_ya();
|
2010-08-09 13:28:56 +00:00
|
|
|
void op_nop();
|
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
|
|
|
void op_plp();
|
|
|
|
void op_rti();
|
|
|
|
void op_rts();
|
|
|
|
void op_sta_idpx();
|
|
|
|
void op_sta_idpy();
|
|
|
|
void op_sta_ix();
|
|
|
|
void op_sta_ixinc();
|
|
|
|
void op_stw_dp();
|
2010-08-09 13:28:56 +00:00
|
|
|
void op_wait();
|
|
|
|
void op_xcn();
|
|
|
|
};
|
2012-04-29 06:16:44 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|