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/z80/instruction.cpp

128 lines
2.3 KiB
C++
Raw Normal View History

Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
auto Z80::trap(uint8 prefix, uint8 code) -> void {
print("[Z80] unimplemented instruction: ", prefix ? pad(hex(prefix, 2L), -3L, ' ') : "", hex(code, 2L), "\n");
Update to v101r13 release. byuu says: Changelog: - MS: added ms/bus - Z80: implemented JP/JR/CP/DI/IM/IN instructions - MD/VDP: added window layer emulation - MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires this) The Z80 is definitely a lot nastier than the LR35902. There's a lot of table duplication with HL→IX→IY; and two of them nest two levels deep (eg FD CB xx xx), so the design may change as I implement more.
2016-08-27 04:48:21 +00:00
print("[Z80] instructions executed: ", --instructionsExecuted, "\n");
while(true) wait();
}
Update to v101r10 release. byuu says: Changelog: - 68K: MOVEQ is 8-bit signed - 68K: disassembler was print EOR for OR instructions - 68K: address/program-counter indexed mode had the signed-word/long bit backward - 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size - 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by one instead of two - Z80: added registers and initial two instructions - MS: hooked up enough to load and start running games - Sonic the Hedgehog can execute exactly one instruction... whoo.
2016-08-19 14:11:26 +00:00
auto Z80::instruction() -> void {
Update to v101r13 release. byuu says: Changelog: - MS: added ms/bus - Z80: implemented JP/JR/CP/DI/IM/IN instructions - MD/VDP: added window layer emulation - MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires this) The Z80 is definitely a lot nastier than the LR35902. There's a lot of table duplication with HL→IX→IY; and two of them nest two levels deep (eg FD CB xx xx), so the design may change as I implement more.
2016-08-27 04:48:21 +00:00
#if 1
if(instructionsExecuted < 20)
print(disassemble(r.pc), "\n");
#endif
Update to v101r10 release. byuu says: Changelog: - 68K: MOVEQ is 8-bit signed - 68K: disassembler was print EOR for OR instructions - 68K: address/program-counter indexed mode had the signed-word/long bit backward - 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size - 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by one instead of two - Z80: added registers and initial two instructions - MS: hooked up enough to load and start running games - Sonic the Hedgehog can execute exactly one instruction... whoo.
2016-08-19 14:11:26 +00:00
instructionsExecuted++;
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
auto code = opcode();
if(code == 0xdd || code == 0xfd) {
r.prefix = code;
return;
}
instruction__(code);
r.prefix = 0x00;
}
#define op(id, name, ...) case id: return instruction##name(__VA_ARGS__);
#define A r.a
#define F r.f
#define B r.b
#define C r.c
#define D r.d
#define E r.e
#define H r.prefix == 0xdd ? r.ixh : r.prefix == 0xfd ? r.iyh : r.h
#define L r.prefix == 0xdd ? r.ixl : r.prefix == 0xfd ? r.iyl : r.l
#define AF r.af
#define BC r.bc
#define DE r.de
#define HL r.prefix == 0xdd ? r.ix : r.prefix == 0xfd ? r.iy : r.hl
Update to v101r10 release. byuu says: Changelog: - 68K: MOVEQ is 8-bit signed - 68K: disassembler was print EOR for OR instructions - 68K: address/program-counter indexed mode had the signed-word/long bit backward - 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size - 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by one instead of two - Z80: added registers and initial two instructions - MS: hooked up enough to load and start running games - Sonic the Hedgehog can execute exactly one instruction... whoo.
2016-08-19 14:11:26 +00:00
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
#define CF r.p.c
#define NF r.p.n
#define PF r.p.p
#define VF r.p.v
#define XF r.p.x
#define HF r.p.h
#define YF r.p.y
#define ZF r.p.z
#define SF r.p.s
auto Z80::instruction__(uint8 code) -> void {
switch(code) {
Update to v101r10 release. byuu says: Changelog: - 68K: MOVEQ is 8-bit signed - 68K: disassembler was print EOR for OR instructions - 68K: address/program-counter indexed mode had the signed-word/long bit backward - 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size - 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by one instead of two - Z80: added registers and initial two instructions - MS: hooked up enough to load and start running games - Sonic the Hedgehog can execute exactly one instruction... whoo.
2016-08-19 14:11:26 +00:00
op(0x00, NOP)
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
op(0x06, LD_r_n, B)
op(0x0e, LD_r_n, C)
op(0x16, LD_r_n, D)
op(0x18, JR_c_e, 1)
op(0x1e, LD_r_n, E)
op(0x20, JR_c_e, ZF == 0)
op(0x26, LD_r_n, H)
op(0x28, JR_c_e, ZF == 1)
op(0x2e, LD_r_n, L)
op(0x30, JR_c_e, CF == 0)
op(0x36, LD_irr_n, HL)
op(0x38, JR_c_e, CF == 1)
op(0x3e, LD_r_n, A)
op(0xc2, JP_c_nn, ZF == 0)
op(0xc3, JP_c_nn, 1)
op(0xca, JP_c_nn, ZF == 1)
op(0xcb, CB, opcode())
op(0xd2, JP_c_nn, CF == 0)
op(0xda, JP_c_nn, CF == 1)
Update to v101r13 release. byuu says: Changelog: - MS: added ms/bus - Z80: implemented JP/JR/CP/DI/IM/IN instructions - MD/VDP: added window layer emulation - MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires this) The Z80 is definitely a lot nastier than the LR35902. There's a lot of table duplication with HL→IX→IY; and two of them nest two levels deep (eg FD CB xx xx), so the design may change as I implement more.
2016-08-27 04:48:21 +00:00
op(0xdb, IN_a_in)
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
op(0xe2, JP_c_nn, PF == 0)
op(0xea, JP_c_nn, PF == 1)
op(0xed, ED, opcode())
op(0xf2, JP_c_nn, SF == 0)
Update to v101r10 release. byuu says: Changelog: - 68K: MOVEQ is 8-bit signed - 68K: disassembler was print EOR for OR instructions - 68K: address/program-counter indexed mode had the signed-word/long bit backward - 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size - 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by one instead of two - Z80: added registers and initial two instructions - MS: hooked up enough to load and start running games - Sonic the Hedgehog can execute exactly one instruction... whoo.
2016-08-19 14:11:26 +00:00
op(0xf3, DI)
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
op(0xfa, JP_c_nn, SF == 1)
op(0xfb, EI)
Update to v101r13 release. byuu says: Changelog: - MS: added ms/bus - Z80: implemented JP/JR/CP/DI/IM/IN instructions - MD/VDP: added window layer emulation - MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires this) The Z80 is definitely a lot nastier than the LR35902. There's a lot of table duplication with HL→IX→IY; and two of them nest two levels deep (eg FD CB xx xx), so the design may change as I implement more.
2016-08-27 04:48:21 +00:00
op(0xfe, CP_n)
Update to v101r10 release. byuu says: Changelog: - 68K: MOVEQ is 8-bit signed - 68K: disassembler was print EOR for OR instructions - 68K: address/program-counter indexed mode had the signed-word/long bit backward - 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size - 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by one instead of two - Z80: added registers and initial two instructions - MS: hooked up enough to load and start running games - Sonic the Hedgehog can execute exactly one instruction... whoo.
2016-08-19 14:11:26 +00:00
}
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
trap(0x00, code);
Update to v101r13 release. byuu says: Changelog: - MS: added ms/bus - Z80: implemented JP/JR/CP/DI/IM/IN instructions - MD/VDP: added window layer emulation - MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires this) The Z80 is definitely a lot nastier than the LR35902. There's a lot of table duplication with HL→IX→IY; and two of them nest two levels deep (eg FD CB xx xx), so the design may change as I implement more.
2016-08-27 04:48:21 +00:00
}
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
auto Z80::instructionCB(uint8 code) -> void {
switch(code) {
Update to v101r13 release. byuu says: Changelog: - MS: added ms/bus - Z80: implemented JP/JR/CP/DI/IM/IN instructions - MD/VDP: added window layer emulation - MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires this) The Z80 is definitely a lot nastier than the LR35902. There's a lot of table duplication with HL→IX→IY; and two of them nest two levels deep (eg FD CB xx xx), so the design may change as I implement more.
2016-08-27 04:48:21 +00:00
}
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
trap(0xcb, code);
Update to v101r13 release. byuu says: Changelog: - MS: added ms/bus - Z80: implemented JP/JR/CP/DI/IM/IN instructions - MD/VDP: added window layer emulation - MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires this) The Z80 is definitely a lot nastier than the LR35902. There's a lot of table duplication with HL→IX→IY; and two of them nest two levels deep (eg FD CB xx xx), so the design may change as I implement more.
2016-08-27 04:48:21 +00:00
}
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
auto Z80::instructionED(uint8 code) -> void {
switch(code) {
op(0x46, IM_o, 0)
op(0x56, IM_o, 1)
op(0x5e, IM_o, 2)
Update to v101r13 release. byuu says: Changelog: - MS: added ms/bus - Z80: implemented JP/JR/CP/DI/IM/IN instructions - MD/VDP: added window layer emulation - MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires this) The Z80 is definitely a lot nastier than the LR35902. There's a lot of table duplication with HL→IX→IY; and two of them nest two levels deep (eg FD CB xx xx), so the design may change as I implement more.
2016-08-27 04:48:21 +00:00
}
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
trap(0xed, code);
Update to v101r10 release. byuu says: Changelog: - 68K: MOVEQ is 8-bit signed - 68K: disassembler was print EOR for OR instructions - 68K: address/program-counter indexed mode had the signed-word/long bit backward - 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size - 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by one instead of two - Z80: added registers and initial two instructions - MS: hooked up enough to load and start running games - Sonic the Hedgehog can execute exactly one instruction... whoo.
2016-08-19 14:11:26 +00:00
}
#undef op
Update to v101r14 release. byuu says: Changelog: - rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY) prefixes - added Processor::Z80::Bus as a new type of abstraction - all of the instructions implemented have their proper T-cycle counts now - added nall/certificates for my public keys The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being 2-read + 2-wait states; operand+regular reads/writes being 3-read. For now, this puts the cycle counts inside the CPU core. At the moment, I can't think of any CPU core where this wouldn't be appropriate. But it's certainly possible that such a case exists. So this may not be the perfect solution. The reason for having it be a subclass of Processor::Z80 instead of virtual functions for the MasterSystem::CPU core to define is due to naming conflicts. I wanted the core to say `in(addr)` and have it take the four clocks. But I also wanted a version of the function that didn't consume time when called. One way to do that would be for the core to call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to `MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::` prefix on all of the opcodes. Very easy to forget it, and then end up not consuming any time. Another is to use uglier names in the `MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But, yuck. So ... yeah, this is an experiment. We'll see how it goes.
2016-09-03 11:26:04 +00:00
#undef A
#undef F
#undef B
#undef C
#undef D
#undef E
#undef H
#undef L
#undef AF
#undef BC
#undef DE
#undef HL
#undef CF
#undef NF
#undef PF
#undef VF
#undef XF
#undef HF
#undef YF
#undef ZF
#undef SF