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

267 lines
5.7 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__);
Update to v101r16 release. byuu says: Changelog: - Z80: implemented 113 new instructions (all the easy LD/ADC/ADD/AND/OR/SBC/SUB/XOR ones) - Z80: used alternative to castable<To, With> type (manual cast inside instruction() register macros) - Z80: debugger: used register macros to reduce typing and increase readability - Z80: debugger: smarter way of handling multiple DD/FD prefixes (using gotos, yay!) - ruby: fixed crash with Windows input driver on exit (from SuperMikeMan) I have no idea how the P/V flag is supposed to work on AND/OR/XOR, so that's probably wrong for now. HALT is also mostly a dummy function for now. But I typically implement those inside instruction(), so it probably won't need to be changed? We'll see.
2016-09-06 00:09:33 +00:00
#define A (uint8&)(r.a)
#define F (uint8&)(r.f)
#define B (uint8&)(r.b)
#define C (uint8&)(r.c)
#define D (uint8&)(r.d)
#define E (uint8&)(r.e)
#define H (uint8&)(r.prefix == 0xdd ? r.ixh : r.prefix == 0xfd ? r.iyh : r.h)
#define L (uint8&)(r.prefix == 0xdd ? r.ixl : r.prefix == 0xfd ? r.iyl : r.l)
#define HD (uint8&)(r.h)
#define LD (uint8&)(r.l)
#define AF (uint16&)(r.af)
#define BC (uint16&)(r.bc)
#define DE (uint16&)(r.de)
#define HL (uint16&)(r.prefix == 0xdd ? r.ix : r.prefix == 0xfd ? r.iy : r.hl)
#define SP (uint16&)(r.sp)
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 v101r15 release. byuu says: Changelog: - added (poorly-named) castable<To, With> template - Z80 debugger rewritten to make declaring instructions much simpler - Z80 has more instructions implemented; supports displacement on (IX), (IY) now - added `Processor::M68K::Bus` to mirror `Processor::Z80::Bus` - it does add a pointer indirection; so I'm not sure if I want to do this for all of my emulator cores ...
2016-09-04 13:51:27 +00:00
op(0x01, LD_rr_nn, BC)
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)
Update to v101r15 release. byuu says: Changelog: - added (poorly-named) castable<To, With> template - Z80 debugger rewritten to make declaring instructions much simpler - Z80 has more instructions implemented; supports displacement on (IX), (IY) now - added `Processor::M68K::Bus` to mirror `Processor::Z80::Bus` - it does add a pointer indirection; so I'm not sure if I want to do this for all of my emulator cores ...
2016-09-04 13:51:27 +00:00
op(0x11, LD_rr_nn, DE)
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(0x16, LD_r_n, D)
op(0x18, JR_c_e, 1)
op(0x1e, LD_r_n, E)
op(0x20, JR_c_e, ZF == 0)
Update to v101r15 release. byuu says: Changelog: - added (poorly-named) castable<To, With> template - Z80 debugger rewritten to make declaring instructions much simpler - Z80 has more instructions implemented; supports displacement on (IX), (IY) now - added `Processor::M68K::Bus` to mirror `Processor::Z80::Bus` - it does add a pointer indirection; so I'm not sure if I want to do this for all of my emulator cores ...
2016-09-04 13:51:27 +00:00
op(0x21, LD_rr_nn, HL)
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(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)
Update to v101r15 release. byuu says: Changelog: - added (poorly-named) castable<To, With> template - Z80 debugger rewritten to make declaring instructions much simpler - Z80 has more instructions implemented; supports displacement on (IX), (IY) now - added `Processor::M68K::Bus` to mirror `Processor::Z80::Bus` - it does add a pointer indirection; so I'm not sure if I want to do this for all of my emulator cores ...
2016-09-04 13:51:27 +00:00
op(0x31, LD_rr_nn, SP)
op(0x32, LD_inn_a)
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(0x36, LD_irr_n, HL)
op(0x38, JR_c_e, CF == 1)
op(0x3e, LD_r_n, A)
Update to v101r16 release. byuu says: Changelog: - Z80: implemented 113 new instructions (all the easy LD/ADC/ADD/AND/OR/SBC/SUB/XOR ones) - Z80: used alternative to castable<To, With> type (manual cast inside instruction() register macros) - Z80: debugger: used register macros to reduce typing and increase readability - Z80: debugger: smarter way of handling multiple DD/FD prefixes (using gotos, yay!) - ruby: fixed crash with Windows input driver on exit (from SuperMikeMan) I have no idea how the P/V flag is supposed to work on AND/OR/XOR, so that's probably wrong for now. HALT is also mostly a dummy function for now. But I typically implement those inside instruction(), so it probably won't need to be changed? We'll see.
2016-09-06 00:09:33 +00:00
op(0x40, LD_r_r, B, B)
op(0x41, LD_r_r, B, C)
op(0x42, LD_r_r, B, D)
op(0x43, LD_r_r, B, E)
op(0x44, LD_r_r, B, H)
op(0x45, LD_r_r, B, L)
op(0x46, LD_r_irr, B, HL)
op(0x47, LD_r_r, B, A)
op(0x48, LD_r_r, C, B)
op(0x49, LD_r_r, C, C)
op(0x4a, LD_r_r, C, D)
op(0x4b, LD_r_r, C, E)
op(0x4c, LD_r_r, C, H)
op(0x4d, LD_r_r, C, L)
op(0x4e, LD_r_irr, C, HL)
op(0x4f, LD_r_r, C, A)
op(0x50, LD_r_r, D, B)
op(0x51, LD_r_r, D, C)
op(0x52, LD_r_r, D, D)
op(0x53, LD_r_r, D, E)
op(0x54, LD_r_r, D, H)
op(0x55, LD_r_r, D, L)
op(0x56, LD_r_irr, D, HL)
op(0x57, LD_r_r, D, A)
op(0x58, LD_r_r, E, B)
op(0x59, LD_r_r, E, C)
op(0x5a, LD_r_r, E, D)
op(0x5b, LD_r_r, E, E)
op(0x5c, LD_r_r, E, H)
op(0x5d, LD_r_r, E, L)
op(0x5e, LD_r_irr, E, HL)
op(0x5f, LD_r_r, E, A)
op(0x60, LD_r_r, H, B)
op(0x61, LD_r_r, H, C)
op(0x62, LD_r_r, H, D)
op(0x63, LD_r_r, H, E)
op(0x64, LD_r_r, H, H)
op(0x65, LD_r_r, H, L)
op(0x66, LD_r_irr, HD, HL)
op(0x67, LD_r_r, H, A)
op(0x68, LD_r_r, L, B)
op(0x69, LD_r_r, L, C)
op(0x6a, LD_r_r, L, D)
op(0x6b, LD_r_r, L, E)
op(0x6c, LD_r_r, L, H)
op(0x6d, LD_r_r, L, L)
op(0x6e, LD_r_irr, LD, HL)
op(0x6f, LD_r_r, L, A)
Update to v101r15 release. byuu says: Changelog: - added (poorly-named) castable<To, With> template - Z80 debugger rewritten to make declaring instructions much simpler - Z80 has more instructions implemented; supports displacement on (IX), (IY) now - added `Processor::M68K::Bus` to mirror `Processor::Z80::Bus` - it does add a pointer indirection; so I'm not sure if I want to do this for all of my emulator cores ...
2016-09-04 13:51:27 +00:00
op(0x70, LD_irr_r, HL, B)
op(0x71, LD_irr_r, HL, C)
op(0x72, LD_irr_r, HL, D)
op(0x73, LD_irr_r, HL, E)
Update to v101r16 release. byuu says: Changelog: - Z80: implemented 113 new instructions (all the easy LD/ADC/ADD/AND/OR/SBC/SUB/XOR ones) - Z80: used alternative to castable<To, With> type (manual cast inside instruction() register macros) - Z80: debugger: used register macros to reduce typing and increase readability - Z80: debugger: smarter way of handling multiple DD/FD prefixes (using gotos, yay!) - ruby: fixed crash with Windows input driver on exit (from SuperMikeMan) I have no idea how the P/V flag is supposed to work on AND/OR/XOR, so that's probably wrong for now. HALT is also mostly a dummy function for now. But I typically implement those inside instruction(), so it probably won't need to be changed? We'll see.
2016-09-06 00:09:33 +00:00
op(0x74, LD_irr_r, HL, HD)
op(0x75, LD_irr_r, HL, LD)
op(0x76, HALT)
Update to v101r15 release. byuu says: Changelog: - added (poorly-named) castable<To, With> template - Z80 debugger rewritten to make declaring instructions much simpler - Z80 has more instructions implemented; supports displacement on (IX), (IY) now - added `Processor::M68K::Bus` to mirror `Processor::Z80::Bus` - it does add a pointer indirection; so I'm not sure if I want to do this for all of my emulator cores ...
2016-09-04 13:51:27 +00:00
op(0x77, LD_irr_r, HL, A)
Update to v101r16 release. byuu says: Changelog: - Z80: implemented 113 new instructions (all the easy LD/ADC/ADD/AND/OR/SBC/SUB/XOR ones) - Z80: used alternative to castable<To, With> type (manual cast inside instruction() register macros) - Z80: debugger: used register macros to reduce typing and increase readability - Z80: debugger: smarter way of handling multiple DD/FD prefixes (using gotos, yay!) - ruby: fixed crash with Windows input driver on exit (from SuperMikeMan) I have no idea how the P/V flag is supposed to work on AND/OR/XOR, so that's probably wrong for now. HALT is also mostly a dummy function for now. But I typically implement those inside instruction(), so it probably won't need to be changed? We'll see.
2016-09-06 00:09:33 +00:00
op(0x78, LD_r_r, A, B)
op(0x79, LD_r_r, A, C)
op(0x7a, LD_r_r, A, D)
op(0x7b, LD_r_r, A, E)
op(0x7c, LD_r_r, A, H)
op(0x7d, LD_r_r, A, L)
op(0x7e, LD_r_irr, A, HL)
op(0x7f, LD_r_r, A, A)
op(0x80, ADD_a_r, B)
op(0x81, ADD_a_r, C)
op(0x82, ADD_a_r, D)
op(0x83, ADD_a_r, E)
op(0x84, ADD_a_r, H)
op(0x85, ADD_a_r, L)
op(0x86, ADD_a_irr, HL)
op(0x87, ADD_a_r, A)
op(0x88, ADC_a_r, B)
op(0x89, ADC_a_r, C)
op(0x8a, ADC_a_r, D)
op(0x8b, ADC_a_r, E)
op(0x8c, ADC_a_r, H)
op(0x8d, ADC_a_r, L)
op(0x8e, ADC_a_irr, HL)
op(0x8f, ADC_a_r, A)
op(0x90, SUB_a_r, B)
op(0x91, SUB_a_r, C)
op(0x92, SUB_a_r, D)
op(0x93, SUB_a_r, E)
op(0x94, SUB_a_r, H)
op(0x95, SUB_a_r, L)
op(0x96, SUB_a_irr, HL)
op(0x97, SUB_a_r, A)
op(0x98, SBC_a_r, B)
op(0x99, SBC_a_r, C)
op(0x9a, SBC_a_r, D)
op(0x9b, SBC_a_r, E)
op(0x9c, SBC_a_r, H)
op(0x9d, SBC_a_r, L)
op(0x9e, SBC_a_irr, HL)
op(0x9f, SBC_a_r, A)
op(0xa0, AND_a_r, B)
op(0xa1, AND_a_r, C)
op(0xa2, AND_a_r, D)
op(0xa3, AND_a_r, E)
op(0xa4, AND_a_r, H)
op(0xa5, AND_a_r, L)
op(0xa6, AND_a_irr, HL)
op(0xa7, AND_a_r, A)
op(0xa8, XOR_a_r, B)
op(0xa9, XOR_a_r, C)
op(0xaa, XOR_a_r, D)
op(0xab, XOR_a_r, E)
op(0xac, XOR_a_r, H)
op(0xad, XOR_a_r, L)
op(0xae, XOR_a_irr, HL)
op(0xaf, XOR_a_r, A)
op(0xb0, OR_a_r, B)
op(0xb1, OR_a_r, C)
op(0xb2, OR_a_r, D)
op(0xb3, OR_a_r, E)
op(0xb4, OR_a_r, H)
op(0xb5, OR_a_r, L)
op(0xb6, OR_a_irr, HL)
op(0xb7, OR_a_r, A)
op(0xb8, CP_a_r, B)
op(0xb9, CP_a_r, C)
op(0xba, CP_a_r, D)
op(0xbb, CP_a_r, E)
op(0xbc, CP_a_r, H)
op(0xbd, CP_a_r, L)
op(0xbe, CP_a_irr, HL)
op(0xbf, CP_a_r, A)
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(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 v101r16 release. byuu says: Changelog: - Z80: implemented 113 new instructions (all the easy LD/ADC/ADD/AND/OR/SBC/SUB/XOR ones) - Z80: used alternative to castable<To, With> type (manual cast inside instruction() register macros) - Z80: debugger: used register macros to reduce typing and increase readability - Z80: debugger: smarter way of handling multiple DD/FD prefixes (using gotos, yay!) - ruby: fixed crash with Windows input driver on exit (from SuperMikeMan) I have no idea how the P/V flag is supposed to work on AND/OR/XOR, so that's probably wrong for now. HALT is also mostly a dummy function for now. But I typically implement those inside instruction(), so it probably won't need to be changed? We'll see.
2016-09-06 00:09:33 +00:00
op(0xfe, CP_a_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
Update to v101r16 release. byuu says: Changelog: - Z80: implemented 113 new instructions (all the easy LD/ADC/ADD/AND/OR/SBC/SUB/XOR ones) - Z80: used alternative to castable<To, With> type (manual cast inside instruction() register macros) - Z80: debugger: used register macros to reduce typing and increase readability - Z80: debugger: smarter way of handling multiple DD/FD prefixes (using gotos, yay!) - ruby: fixed crash with Windows input driver on exit (from SuperMikeMan) I have no idea how the P/V flag is supposed to work on AND/OR/XOR, so that's probably wrong for now. HALT is also mostly a dummy function for now. But I typically implement those inside instruction(), so it probably won't need to be changed? We'll see.
2016-09-06 00:09:33 +00:00
#undef HD
#undef LD
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 AF
#undef BC
#undef DE
#undef HL
Update to v101r15 release. byuu says: Changelog: - added (poorly-named) castable<To, With> template - Z80 debugger rewritten to make declaring instructions much simpler - Z80 has more instructions implemented; supports displacement on (IX), (IY) now - added `Processor::M68K::Bus` to mirror `Processor::Z80::Bus` - it does add a pointer indirection; so I'm not sure if I want to do this for all of my emulator cores ...
2016-09-04 13:51:27 +00:00
#undef SP
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 CF
#undef NF
#undef PF
#undef VF
#undef XF
#undef HF
#undef YF
#undef ZF
#undef SF