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
|
|
|
//legend:
|
2016-09-06 13:53:14 +00:00
|
|
|
// a = register A
|
2016-09-06 00:09:33 +00:00
|
|
|
// c = condition
|
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
|
|
|
// e = relative operand
|
|
|
|
// in = (operand)
|
2016-09-04 13:51:27 +00:00
|
|
|
// inn = (operand-word)
|
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
|
|
|
// irr = (register-word)
|
|
|
|
// o = opcode bits
|
|
|
|
// n = operand
|
|
|
|
// nn = operand-word
|
|
|
|
// r = register
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::ADD(uint8 x, uint8 y, bool c) -> uint8 {
|
|
|
|
uint9 z = x + y + c;
|
2016-08-27 04:48:21 +00:00
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
CF = z.bit(8);
|
|
|
|
NF = 0;
|
2016-11-15 07:20:42 +00:00
|
|
|
VF = uint8(~(x ^ y) & (x ^ z)).bit(7);
|
2016-09-06 13:53:14 +00:00
|
|
|
XF = z.bit(3);
|
2016-11-15 07:20:42 +00:00
|
|
|
HF = uint8(x ^ y ^ z).bit(4);
|
2016-09-06 13:53:14 +00:00
|
|
|
YF = z.bit(5);
|
2016-11-15 07:20:42 +00:00
|
|
|
ZF = uint8(z) == 0;
|
2016-09-06 13:53:14 +00:00
|
|
|
SF = z.bit(7);
|
2016-09-06 00:09:33 +00:00
|
|
|
|
|
|
|
return z;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::AND(uint8 x, uint8 y) -> uint8 {
|
|
|
|
uint8 z = x & y;
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
CF = 0;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(z);
|
|
|
|
XF = z.bit(3);
|
|
|
|
HF = 1;
|
|
|
|
YF = z.bit(5);
|
|
|
|
ZF = z == 0;
|
|
|
|
SF = z.bit(7);
|
|
|
|
|
|
|
|
return z;
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::BIT(uint3 bit, uint8 x) -> uint8 {
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
uint8 z = x & 1 << bit;
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
NF = 0;
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
PF = parity(z);
|
|
|
|
XF = z.bit(3);
|
2016-10-29 00:33:30 +00:00
|
|
|
HF = 1;
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
YF = z.bit(5);
|
|
|
|
ZF = z == 0;
|
|
|
|
SF = z.bit(7);
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
|
|
|
|
return x;
|
2016-10-29 00:33:30 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::DEC(uint8 x) -> uint8 {
|
|
|
|
uint8 z = x - 1;
|
|
|
|
|
|
|
|
NF = 1;
|
|
|
|
VF = z == 0x7f;
|
|
|
|
XF = z.bit(3);
|
|
|
|
HF = z.bits(0,3) == 0x0f;
|
|
|
|
YF = z.bit(5);
|
|
|
|
ZF = z == 0;
|
|
|
|
SF = z.bit(7);
|
|
|
|
|
|
|
|
return z;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::INC(uint8 x) -> uint8 {
|
|
|
|
uint8 z = x + 1;
|
|
|
|
|
|
|
|
NF = 0;
|
|
|
|
VF = z == 0x80;
|
|
|
|
XF = z.bit(3);
|
|
|
|
HF = z.bits(0,3) == 0x00;
|
|
|
|
YF = z.bit(5);
|
|
|
|
ZF = z == 0;
|
|
|
|
SF = z.bit(7);
|
2016-09-06 00:09:33 +00:00
|
|
|
|
|
|
|
return z;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::OR(uint8 x, uint8 y) -> uint8 {
|
|
|
|
uint8 z = x | y;
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
CF = 0;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(z);
|
|
|
|
XF = z.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = z.bit(5);
|
|
|
|
ZF = z == 0;
|
|
|
|
SF = z.bit(7);
|
2016-09-06 00:09:33 +00:00
|
|
|
|
|
|
|
return z;
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::RES(uint3 bit, uint8 x) -> uint8 {
|
|
|
|
x &= ~(1 << bit);
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::RL(uint8 x) -> uint8 {
|
|
|
|
bool c = x.bit(7);
|
|
|
|
x = x << 1 | CF;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(x);
|
|
|
|
XF = x.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = x.bit(5);
|
|
|
|
ZF = x == 0;
|
|
|
|
SF = x.bit(7);
|
|
|
|
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::RLC(uint8 x) -> uint8 {
|
|
|
|
x = x << 1 | x >> 7;
|
|
|
|
|
|
|
|
CF = x.bit(0);
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(x);
|
|
|
|
XF = x.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = x.bit(5);
|
|
|
|
ZF = x == 0;
|
|
|
|
SF = x.bit(7);
|
|
|
|
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::RR(uint8 x) -> uint8 {
|
|
|
|
bool c = x.bit(0);
|
|
|
|
x = x >> 1 | CF << 7;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(x);
|
|
|
|
XF = x.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = x.bit(5);
|
|
|
|
ZF = x == 0;
|
|
|
|
SF = x.bit(7);
|
|
|
|
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::RRC(uint8 x) -> uint8 {
|
|
|
|
x = x >> 1 | x << 7;
|
|
|
|
|
|
|
|
CF = x.bit(7);
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(x);
|
|
|
|
XF = x.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = x.bit(5);
|
|
|
|
ZF = x == 0;
|
|
|
|
SF = x.bit(7);
|
|
|
|
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::SET(uint3 bit, uint8 x) -> uint8 {
|
|
|
|
x |= (1 << bit);
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::SLA(uint8 x) -> uint8 {
|
|
|
|
bool c = x.bit(7);
|
|
|
|
x = x << 1;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(x);
|
|
|
|
XF = x.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = x.bit(5);
|
|
|
|
ZF = x == 0;
|
|
|
|
SF = x.bit(7);
|
|
|
|
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::SLL(uint8 x) -> uint8 {
|
|
|
|
bool c = x.bit(7);
|
|
|
|
x = x << 1 | 1;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(x);
|
|
|
|
XF = x.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = x.bit(5);
|
|
|
|
ZF = x == 0;
|
|
|
|
SF = x.bit(7);
|
|
|
|
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::SRA(uint8 x) -> uint8 {
|
|
|
|
bool c = x.bit(0);
|
|
|
|
x = (int8)x >> 1;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(x);
|
|
|
|
XF = x.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = x.bit(5);
|
|
|
|
ZF = x == 0;
|
|
|
|
SF = x.bit(7);
|
|
|
|
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::SRL(uint8 x) -> uint8 {
|
|
|
|
bool c = x.bit(0);
|
|
|
|
x = x >> 1;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(x);
|
|
|
|
XF = x.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = x.bit(5);
|
|
|
|
ZF = x == 0;
|
|
|
|
SF = x.bit(7);
|
|
|
|
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::SUB(uint8 x, uint8 y, bool c) -> uint8 {
|
|
|
|
uint9 z = x - y - c;
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
CF = z.bit(8);
|
|
|
|
NF = 1;
|
2016-11-15 07:20:42 +00:00
|
|
|
VF = uint8((x ^ y) & (x ^ z)).bit(7);
|
2016-09-06 13:53:14 +00:00
|
|
|
XF = z.bit(3);
|
2016-11-15 07:20:42 +00:00
|
|
|
HF = uint8(x ^ y ^ z).bit(4);
|
2016-09-06 13:53:14 +00:00
|
|
|
YF = z.bit(5);
|
2016-11-15 07:20:42 +00:00
|
|
|
ZF = uint8(z) == 0;
|
2016-09-06 13:53:14 +00:00
|
|
|
SF = z.bit(7);
|
2016-09-06 00:09:33 +00:00
|
|
|
|
|
|
|
return z;
|
2016-08-27 04:48:21 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::XOR(uint8 x, uint8 y) -> uint8 {
|
|
|
|
uint8 z = x ^ y;
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
CF = 0;
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(z);
|
|
|
|
XF = z.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = z.bit(5);
|
|
|
|
ZF = z == 0;
|
|
|
|
SF = z.bit(7);
|
2016-09-06 00:09:33 +00:00
|
|
|
|
|
|
|
return z;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
|
|
|
|
auto Z80::instructionADC_a_irr(uint16& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = ADD(A, read(displace(x)), CF);
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionADC_a_n() -> void {
|
|
|
|
A = ADD(A, operand(), CF);
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionADC_a_r(uint8& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = ADD(A, x, CF);
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
2016-11-01 11:42:25 +00:00
|
|
|
auto Z80::instructionADC_hl_rr(uint16& x) -> void {
|
|
|
|
wait(4);
|
|
|
|
auto lo = ADD(HL >> 0, x >> 0, CF);
|
|
|
|
wait(3);
|
|
|
|
auto hi = ADD(HL >> 8, x >> 8, CF);
|
|
|
|
HL = hi << 8 | lo << 0;
|
|
|
|
ZF = HL == 0;
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionADD_a_irr(uint16& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = ADD(A, read(displace(x)));
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionADD_a_n() -> void {
|
|
|
|
A = ADD(A, operand());
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionADD_a_r(uint8& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = ADD(A, x);
|
|
|
|
}
|
|
|
|
|
2016-11-01 11:42:25 +00:00
|
|
|
auto Z80::instructionADD_hl_rr(uint16& x) -> void {
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
bool vf = VF, zf = ZF, sf = SF;
|
2016-09-06 13:53:14 +00:00
|
|
|
wait(4);
|
2016-11-01 11:42:25 +00:00
|
|
|
auto lo = ADD(HL >> 0, x >> 0);
|
2016-09-06 13:53:14 +00:00
|
|
|
wait(3);
|
2016-11-01 11:42:25 +00:00
|
|
|
auto hi = ADD(HL >> 8, x >> 8, CF);
|
|
|
|
HL = hi << 8 | lo << 0;
|
2016-11-15 07:20:42 +00:00
|
|
|
VF = vf, ZF = zf, SF = sf; //restore unaffected flags
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionAND_a_irr(uint16& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = AND(A, read(displace(x)));
|
2016-09-04 13:51:27 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionAND_a_n() -> void {
|
|
|
|
A = AND(A, operand());
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionAND_a_r(uint8& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = AND(A, x);
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionBIT_o_irr(uint3 bit, uint16& addr) -> void {
|
|
|
|
BIT(bit, read(addr));
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionBIT_o_irr_r(uint3 bit, uint16& addr, uint8& x) -> void {
|
|
|
|
x = BIT(bit, read(addr));
|
2016-10-29 00:33:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionBIT_o_r(uint3 bit, uint8& x) -> void {
|
|
|
|
BIT(bit, x);
|
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionCALL_c_nn(bool c) -> void {
|
|
|
|
auto addr = operands();
|
|
|
|
if(!c) return;
|
|
|
|
wait(1);
|
|
|
|
push(PC);
|
|
|
|
PC = addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionCALL_nn() -> void {
|
|
|
|
auto addr = operands();
|
|
|
|
wait(1);
|
|
|
|
push(PC);
|
|
|
|
PC = addr;
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionCCF() -> void {
|
|
|
|
CF = !CF;
|
|
|
|
NF = 0;
|
|
|
|
HF = !CF;
|
2016-08-27 04:48:21 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionCP_a_irr(uint16& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
SUB(A, read(displace(x)));
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionCP_a_n() -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
SUB(A, operand());
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionCP_a_r(uint8& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
SUB(A, x);
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionCPD() -> void {
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
bool cf = CF;
|
2016-10-29 00:33:30 +00:00
|
|
|
auto data = read(_HL--);
|
|
|
|
wait(5);
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
SUB(A, data);
|
|
|
|
VF = --BC != 0;
|
|
|
|
CF = cf; //restore unaffected flag
|
2016-10-29 00:33:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionCPDR() -> void {
|
|
|
|
instructionCPD();
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
if(!BC) return;
|
2016-10-29 00:33:30 +00:00
|
|
|
wait(5);
|
|
|
|
PC -= 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionCPI() -> void {
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
bool cf = CF;
|
2016-10-29 00:33:30 +00:00
|
|
|
auto data = read(_HL++);
|
2016-10-31 21:10:33 +00:00
|
|
|
wait(5);
|
2016-10-29 00:33:30 +00:00
|
|
|
SUB(A, data);
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
VF = --BC != 0;
|
|
|
|
CF = cf; //restore unaffected flag
|
2016-10-29 00:33:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionCPIR() -> void {
|
|
|
|
instructionCPI();
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
if(!BC) return;
|
2016-10-29 00:33:30 +00:00
|
|
|
wait(5);
|
|
|
|
PC -= 2;
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionCPL() -> void {
|
|
|
|
A = ~A;
|
|
|
|
|
|
|
|
NF = 1;
|
|
|
|
XF = A.bit(3);
|
|
|
|
HF = 1;
|
|
|
|
YF = A.bit(5);
|
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionDAA() -> void {
|
2016-11-15 07:20:42 +00:00
|
|
|
auto a = A;
|
|
|
|
if(CF || (A.bits(0,7) > 0x99)) { A += NF ? -0x60 : 0x60; CF = 1; }
|
|
|
|
if(HF || (A.bits(0,3) > 0x09)) { A += NF ? -0x06 : 0x06; }
|
|
|
|
|
2016-11-01 11:42:25 +00:00
|
|
|
PF = parity(A);
|
|
|
|
XF = A.bit(3);
|
2016-11-15 07:20:42 +00:00
|
|
|
HF = uint8(A ^ a).bit(4);
|
2016-11-01 11:42:25 +00:00
|
|
|
YF = A.bit(5);
|
|
|
|
ZF = A == 0;
|
|
|
|
SF = A.bit(7);
|
2016-10-31 21:10:33 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionDEC_irr(uint16& x) -> void {
|
|
|
|
auto addr = displace(x);
|
|
|
|
auto data = read(addr);
|
|
|
|
wait(1);
|
|
|
|
write(addr, DEC(data));
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionDEC_r(uint8& x) -> void {
|
|
|
|
x = DEC(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionDEC_rr(uint16& x) -> void {
|
|
|
|
wait(2);
|
|
|
|
x--;
|
2016-09-04 13:51:27 +00:00
|
|
|
}
|
|
|
|
|
2016-08-19 14:11:26 +00:00
|
|
|
auto Z80::instructionDI() -> void {
|
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
|
|
|
r.iff1 = 0;
|
|
|
|
r.iff2 = 0;
|
2016-08-27 04:48:21 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionDJNZ_e() -> void {
|
|
|
|
wait(1);
|
|
|
|
auto e = operand();
|
|
|
|
if(!--B) return;
|
|
|
|
wait(5);
|
|
|
|
PC += (int8)e;
|
|
|
|
}
|
|
|
|
|
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::instructionEI() -> void {
|
2016-12-26 12:09:56 +00:00
|
|
|
r.ei = 1; //raise IFF1, IFF2 after the next instruction
|
2016-08-27 04:48:21 +00:00
|
|
|
}
|
|
|
|
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
auto Z80::instructionEX_irr_rr(uint16& x, uint16& y) -> void {
|
|
|
|
uint16 z;
|
|
|
|
z.byte(0) = read(x + 0);
|
|
|
|
z.byte(1) = read(x + 1);
|
|
|
|
write(x + 0, y.byte(0));
|
|
|
|
write(x + 1, y.byte(1));
|
|
|
|
y = z;
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionEX_rr_rr(uint16& x, uint16& y) -> void {
|
|
|
|
auto z = x;
|
|
|
|
x = y;
|
|
|
|
y = z;
|
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionEXX() -> void {
|
|
|
|
swap(BC, BC_);
|
|
|
|
swap(DE, DE_);
|
|
|
|
swap(_HL, HL_);
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionHALT() -> void {
|
|
|
|
r.halt = 1;
|
|
|
|
}
|
|
|
|
|
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::instructionIM_o(uint2 code) -> void {
|
|
|
|
wait(4);
|
|
|
|
r.im = code;
|
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::instructionIN_a_in() -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = in(operand());
|
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionIN_r_ic(uint8& x) -> void {
|
|
|
|
x = in(C);
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionINC_irr(uint16& x) -> void {
|
|
|
|
auto addr = displace(x);
|
|
|
|
auto data = read(addr);
|
|
|
|
wait(1);
|
|
|
|
write(addr, INC(data));
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionINC_r(uint8& x) -> void {
|
|
|
|
x = INC(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionINC_rr(uint16& x) -> void {
|
|
|
|
wait(2);
|
|
|
|
x++;
|
2016-08-27 04:48:21 +00:00
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionIND() -> void {
|
2016-10-31 21:10:33 +00:00
|
|
|
wait(1);
|
2016-10-29 00:33:30 +00:00
|
|
|
auto data = in(C);
|
|
|
|
write(_HL--, data);
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
NF = 1;
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
ZF = --B == 0;
|
2016-10-29 00:33:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionINDR() -> void {
|
|
|
|
instructionIND();
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
if(!B) return;
|
2016-10-29 00:33:30 +00:00
|
|
|
wait(5);
|
|
|
|
PC -= 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionINI() -> void {
|
2016-10-31 21:10:33 +00:00
|
|
|
wait(1);
|
2016-10-29 00:33:30 +00:00
|
|
|
auto data = in(C);
|
|
|
|
write(_HL++, data);
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
NF = 1;
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
ZF = --B == 0;
|
2016-10-29 00:33:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionINIR() -> void {
|
|
|
|
instructionINI();
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
if(!B) return;
|
2016-10-29 00:33:30 +00:00
|
|
|
wait(5);
|
|
|
|
PC -= 2;
|
|
|
|
}
|
|
|
|
|
2016-08-27 04:48:21 +00:00
|
|
|
auto Z80::instructionJP_c_nn(bool c) -> void {
|
2016-09-06 00:09:33 +00:00
|
|
|
auto pc = operands();
|
|
|
|
if(c) r.pc = pc;
|
2016-08-27 04:48:21 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionJP_rr(uint16& x) -> void {
|
|
|
|
PC = x;
|
|
|
|
}
|
|
|
|
|
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::instructionJR_c_e(bool c) -> void {
|
|
|
|
auto e = operand();
|
2016-09-06 00:09:33 +00:00
|
|
|
if(c) wait(5), r.pc += (int8)e;
|
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
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionLD_a_inn() -> void {
|
|
|
|
A = read(operands());
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLD_a_irr(uint16& x) -> void {
|
|
|
|
A = read(displace(x));
|
|
|
|
}
|
|
|
|
|
2016-09-04 13:51:27 +00:00
|
|
|
auto Z80::instructionLD_inn_a() -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
write(operands(), A);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLD_inn_rr(uint16& x) -> void {
|
|
|
|
auto addr = operands();
|
|
|
|
write(addr + 0, x >> 0);
|
|
|
|
write(addr + 1, x >> 8);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLD_irr_a(uint16& x) -> void {
|
|
|
|
write(displace(x), A);
|
2016-09-04 13:51:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLD_irr_n(uint16& x) -> void {
|
|
|
|
auto addr = displace(x);
|
|
|
|
write(addr, operand());
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLD_irr_r(uint16& x, uint8& y) -> void {
|
2016-09-06 00:09:33 +00:00
|
|
|
write(displace(x), y);
|
2016-08-27 04:48:21 +00:00
|
|
|
}
|
|
|
|
|
2016-09-04 13:51:27 +00:00
|
|
|
auto Z80::instructionLD_r_n(uint8& x) -> void {
|
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
|
|
|
x = operand();
|
2016-08-19 14:11:26 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionLD_r_irr(uint8& x, uint16& y) -> void {
|
|
|
|
x = read(displace(y));
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLD_r_r(uint8& x, uint8& y) -> void {
|
|
|
|
x = y;
|
|
|
|
}
|
|
|
|
|
2016-11-01 11:42:25 +00:00
|
|
|
//LD to/from I/R requires an extra T-cycle
|
|
|
|
auto Z80::instructionLD_r_r1(uint8& x, uint8& y) -> void {
|
|
|
|
wait(1);
|
|
|
|
x = y;
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionLD_rr_inn(uint16& x) -> void {
|
|
|
|
auto addr = operands();
|
|
|
|
x.byte(0) = read(addr + 0);
|
|
|
|
x.byte(1) = read(addr + 1);
|
|
|
|
}
|
|
|
|
|
2016-09-04 13:51:27 +00:00
|
|
|
auto Z80::instructionLD_rr_nn(uint16& x) -> void {
|
2016-09-06 00:09:33 +00:00
|
|
|
x = operands();
|
2016-09-04 13:51:27 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionLD_sp_rr(uint16& x) -> void {
|
|
|
|
wait(2);
|
|
|
|
SP = x;
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionLDD() -> void {
|
|
|
|
auto data = read(_HL--);
|
|
|
|
write(DE--, data);
|
|
|
|
wait(2);
|
|
|
|
NF = 0;
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
VF = --BC != 0;
|
2016-10-29 00:33:30 +00:00
|
|
|
HF = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLDDR() -> void {
|
|
|
|
instructionLDD();
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
if(!BC) return;
|
2016-10-29 00:33:30 +00:00
|
|
|
wait(5);
|
|
|
|
PC -= 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLDI() -> void {
|
|
|
|
auto data = read(_HL++);
|
|
|
|
write(DE++, data);
|
|
|
|
wait(2);
|
|
|
|
NF = 0;
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
VF = --BC != 0;
|
2016-10-29 00:33:30 +00:00
|
|
|
HF = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionLDIR() -> void {
|
|
|
|
instructionLDI();
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
if(!BC) return;
|
2016-10-29 00:33:30 +00:00
|
|
|
wait(5);
|
|
|
|
PC -= 2;
|
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionNEG() -> void {
|
|
|
|
A = SUB(0, A);
|
|
|
|
}
|
|
|
|
|
2016-08-19 14:11:26 +00:00
|
|
|
auto Z80::instructionNOP() -> void {
|
|
|
|
}
|
2016-09-06 00:09:33 +00:00
|
|
|
|
|
|
|
auto Z80::instructionOR_a_irr(uint16& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = OR(A, read(displace(x)));
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionOR_a_n() -> void {
|
|
|
|
A = OR(A, operand());
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionOR_a_r(uint8& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = OR(A, x);
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionOTDR() -> void {
|
|
|
|
instructionOUTD();
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
if(!B) return;
|
2016-10-29 00:33:30 +00:00
|
|
|
wait(5);
|
|
|
|
PC -= 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionOTIR() -> void {
|
|
|
|
instructionOUTI();
|
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
2017-01-11 20:27:30 +00:00
|
|
|
if(!B) return;
|
2016-10-29 00:33:30 +00:00
|
|
|
wait(5);
|
|
|
|
PC -= 2;
|
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionOUT_ic_r(uint8& x) -> void {
|
|
|
|
out(C, x);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionOUT_n_a() -> void {
|
|
|
|
auto addr = operand();
|
|
|
|
out(addr, A);
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionOUTD() -> void {
|
2016-10-31 21:10:33 +00:00
|
|
|
wait(1);
|
2016-10-29 00:33:30 +00:00
|
|
|
auto data = read(_HL--);
|
|
|
|
out(C, data);
|
|
|
|
NF = 1;
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
ZF = --B == 0;
|
2016-10-29 00:33:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionOUTI() -> void {
|
2016-10-31 21:10:33 +00:00
|
|
|
wait(1);
|
2016-10-29 00:33:30 +00:00
|
|
|
auto data = read(_HL++);
|
|
|
|
out(C, data);
|
|
|
|
NF = 1;
|
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
|
|
|
ZF = --B == 0;
|
2016-10-31 21:10:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionPOP_rr(uint16& x) -> void {
|
|
|
|
x = pop();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionPUSH_rr(uint16& x) -> void {
|
|
|
|
wait(1);
|
|
|
|
push(x);
|
2016-10-29 00:33:30 +00:00
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionRES_o_irr(uint3 bit, uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, RES(bit, read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionRES_o_irr_r(uint3 bit, uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = RES(bit, read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionRES_o_r(uint3 bit, uint8& x) -> void {
|
|
|
|
x = RES(bit, x);
|
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionRET() -> void {
|
|
|
|
wait(1);
|
|
|
|
PC = pop();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionRET_c(bool c) -> void {
|
|
|
|
wait(1);
|
|
|
|
if(!c) return;
|
|
|
|
PC = pop();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionRETI() -> void {
|
|
|
|
PC = pop();
|
2016-11-15 07:20:42 +00:00
|
|
|
r.iff1 = r.iff2;
|
2016-10-31 21:10:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionRETN() -> void {
|
|
|
|
PC = pop();
|
|
|
|
r.iff1 = r.iff2;
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionRL_irr(uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, RL(read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionRL_irr_r(uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = RL(read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionRL_r(uint8& x) -> void {
|
|
|
|
x = RL(x);
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionRLA() -> void {
|
|
|
|
bool c = A.bit(7);
|
|
|
|
A = A << 1 | CF;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
XF = A.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = A.bit(5);
|
|
|
|
}
|
|
|
|
|
Update to v101r27 release.
byuu says:
Changelog:
- SMS: emulated the generic Sega memory mapper (none of the more
limited forms of it yet)
- (missing ROM shift, ROM write enable emulation -- no commercial
games use either, though)
- SMS: bus I/O returns 0xff instead of 0x00 so games don't think every
key is being pressed at once
- (this is a hack until I implement proper controller pad reading)
- SMS: very limited protection against reading/writing past the end of
ROM/RAM (todo: should mirror)
- SMS: VDP background HSCROLL subtracts, rather than adds, to the
offset (unlike VSCROLL)
- SMS: VDP VSCROLL is 9-bit, modulates voffset+vscroll to 224 in
192-line mode (32x28 tilemap)
- SMS: VDP tiledata for backgrounds and sprites use `7-(x&7)` rather
than `(x&7)`
- SMS: fix output color to be 6-bit rather than 5-bit
- SMS: left clip uses register `#7`, not palette color `#7`
- (todo: do we want `color[reg7]` or `color[16 + reg7]`?)
- SMS: refined handling of 0xcb, 0xed prefixes in the Z80 core and its
disassembler
- SMS: emulated (0xfd, 0xdd) 0xcb opcodes 0x00-0x0f (still missing
0x10-0xff)
- SMS: fixed 0xcb 0b-----110 opcodes to use direct HL and never allow
(IX,IY)+d
- SMS: fixed major logic bug in (IX,IY)+d displacement
- (was using `read(x)` instead of `operand()` for the displacement
byte fetch before)
- icarus: fake there always being 32KiB of RAM in all SMS cartridges
for the time being
- (not sure how to detect this stuff yet; although I've read it's
not even really possible `>_>`)
TODO: remove processor/z80/dissassembler.cpp code block at line 396 (as it's unnecessary.)
Lots of commercial games are starting to show trashed graphical output now.
2017-01-06 08:11:38 +00:00
|
|
|
auto Z80::instructionRLC_irr(uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, RLC(read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r27 release.
byuu says:
Changelog:
- SMS: emulated the generic Sega memory mapper (none of the more
limited forms of it yet)
- (missing ROM shift, ROM write enable emulation -- no commercial
games use either, though)
- SMS: bus I/O returns 0xff instead of 0x00 so games don't think every
key is being pressed at once
- (this is a hack until I implement proper controller pad reading)
- SMS: very limited protection against reading/writing past the end of
ROM/RAM (todo: should mirror)
- SMS: VDP background HSCROLL subtracts, rather than adds, to the
offset (unlike VSCROLL)
- SMS: VDP VSCROLL is 9-bit, modulates voffset+vscroll to 224 in
192-line mode (32x28 tilemap)
- SMS: VDP tiledata for backgrounds and sprites use `7-(x&7)` rather
than `(x&7)`
- SMS: fix output color to be 6-bit rather than 5-bit
- SMS: left clip uses register `#7`, not palette color `#7`
- (todo: do we want `color[reg7]` or `color[16 + reg7]`?)
- SMS: refined handling of 0xcb, 0xed prefixes in the Z80 core and its
disassembler
- SMS: emulated (0xfd, 0xdd) 0xcb opcodes 0x00-0x0f (still missing
0x10-0xff)
- SMS: fixed 0xcb 0b-----110 opcodes to use direct HL and never allow
(IX,IY)+d
- SMS: fixed major logic bug in (IX,IY)+d displacement
- (was using `read(x)` instead of `operand()` for the displacement
byte fetch before)
- icarus: fake there always being 32KiB of RAM in all SMS cartridges
for the time being
- (not sure how to detect this stuff yet; although I've read it's
not even really possible `>_>`)
TODO: remove processor/z80/dissassembler.cpp code block at line 396 (as it's unnecessary.)
Lots of commercial games are starting to show trashed graphical output now.
2017-01-06 08:11:38 +00:00
|
|
|
auto Z80::instructionRLC_irr_r(uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = RLC(read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionRLC_r(uint8& x) -> void {
|
|
|
|
x = RLC(x);
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionRLCA() -> void {
|
|
|
|
bool c = A.bit(7);
|
|
|
|
A = A << 1 | c;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
XF = A.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = A.bit(5);
|
|
|
|
}
|
|
|
|
|
2016-11-01 11:42:25 +00:00
|
|
|
auto Z80::instructionRLD() -> void {
|
|
|
|
auto data = read(HL);
|
|
|
|
wait(1);
|
|
|
|
write(HL, (data << 4) | (A & 0x0f));
|
|
|
|
wait(3);
|
|
|
|
A = (A & 0xf0) | (data >> 4);
|
|
|
|
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(A);
|
|
|
|
XF = A.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = A.bit(5);
|
|
|
|
ZF = A == 0;
|
|
|
|
SF = A.bit(7);
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionRR_irr(uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, RR(read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionRR_irr_r(uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = RR(read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionRR_r(uint8& x) -> void {
|
|
|
|
x = RR(x);
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionRRA() -> void {
|
|
|
|
bool c = A.bit(0);
|
|
|
|
A = CF << 7 | A >> 1;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
XF = A.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = A.bit(5);
|
|
|
|
}
|
|
|
|
|
Update to v101r27 release.
byuu says:
Changelog:
- SMS: emulated the generic Sega memory mapper (none of the more
limited forms of it yet)
- (missing ROM shift, ROM write enable emulation -- no commercial
games use either, though)
- SMS: bus I/O returns 0xff instead of 0x00 so games don't think every
key is being pressed at once
- (this is a hack until I implement proper controller pad reading)
- SMS: very limited protection against reading/writing past the end of
ROM/RAM (todo: should mirror)
- SMS: VDP background HSCROLL subtracts, rather than adds, to the
offset (unlike VSCROLL)
- SMS: VDP VSCROLL is 9-bit, modulates voffset+vscroll to 224 in
192-line mode (32x28 tilemap)
- SMS: VDP tiledata for backgrounds and sprites use `7-(x&7)` rather
than `(x&7)`
- SMS: fix output color to be 6-bit rather than 5-bit
- SMS: left clip uses register `#7`, not palette color `#7`
- (todo: do we want `color[reg7]` or `color[16 + reg7]`?)
- SMS: refined handling of 0xcb, 0xed prefixes in the Z80 core and its
disassembler
- SMS: emulated (0xfd, 0xdd) 0xcb opcodes 0x00-0x0f (still missing
0x10-0xff)
- SMS: fixed 0xcb 0b-----110 opcodes to use direct HL and never allow
(IX,IY)+d
- SMS: fixed major logic bug in (IX,IY)+d displacement
- (was using `read(x)` instead of `operand()` for the displacement
byte fetch before)
- icarus: fake there always being 32KiB of RAM in all SMS cartridges
for the time being
- (not sure how to detect this stuff yet; although I've read it's
not even really possible `>_>`)
TODO: remove processor/z80/dissassembler.cpp code block at line 396 (as it's unnecessary.)
Lots of commercial games are starting to show trashed graphical output now.
2017-01-06 08:11:38 +00:00
|
|
|
auto Z80::instructionRRC_irr(uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, RRC(read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r27 release.
byuu says:
Changelog:
- SMS: emulated the generic Sega memory mapper (none of the more
limited forms of it yet)
- (missing ROM shift, ROM write enable emulation -- no commercial
games use either, though)
- SMS: bus I/O returns 0xff instead of 0x00 so games don't think every
key is being pressed at once
- (this is a hack until I implement proper controller pad reading)
- SMS: very limited protection against reading/writing past the end of
ROM/RAM (todo: should mirror)
- SMS: VDP background HSCROLL subtracts, rather than adds, to the
offset (unlike VSCROLL)
- SMS: VDP VSCROLL is 9-bit, modulates voffset+vscroll to 224 in
192-line mode (32x28 tilemap)
- SMS: VDP tiledata for backgrounds and sprites use `7-(x&7)` rather
than `(x&7)`
- SMS: fix output color to be 6-bit rather than 5-bit
- SMS: left clip uses register `#7`, not palette color `#7`
- (todo: do we want `color[reg7]` or `color[16 + reg7]`?)
- SMS: refined handling of 0xcb, 0xed prefixes in the Z80 core and its
disassembler
- SMS: emulated (0xfd, 0xdd) 0xcb opcodes 0x00-0x0f (still missing
0x10-0xff)
- SMS: fixed 0xcb 0b-----110 opcodes to use direct HL and never allow
(IX,IY)+d
- SMS: fixed major logic bug in (IX,IY)+d displacement
- (was using `read(x)` instead of `operand()` for the displacement
byte fetch before)
- icarus: fake there always being 32KiB of RAM in all SMS cartridges
for the time being
- (not sure how to detect this stuff yet; although I've read it's
not even really possible `>_>`)
TODO: remove processor/z80/dissassembler.cpp code block at line 396 (as it's unnecessary.)
Lots of commercial games are starting to show trashed graphical output now.
2017-01-06 08:11:38 +00:00
|
|
|
auto Z80::instructionRRC_irr_r(uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = RRC(read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionRRC_r(uint8& x) -> void {
|
|
|
|
x = RRC(x);
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionRRCA() -> void {
|
|
|
|
bool c = A.bit(0);
|
|
|
|
A = c << 7 | A >> 1;
|
|
|
|
|
|
|
|
CF = c;
|
|
|
|
NF = 0;
|
|
|
|
XF = A.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = A.bit(5);
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
2016-11-01 11:42:25 +00:00
|
|
|
auto Z80::instructionRRD() -> void {
|
|
|
|
auto data = read(HL);
|
|
|
|
wait(1);
|
|
|
|
write(HL, (data >> 4) | (A << 4));
|
|
|
|
wait(3);
|
|
|
|
A = (A & 0xf0) | (data & 0x0f);
|
|
|
|
|
|
|
|
NF = 0;
|
|
|
|
PF = parity(A);
|
|
|
|
XF = A.bit(3);
|
|
|
|
HF = 0;
|
|
|
|
YF = A.bit(5);
|
|
|
|
ZF = A == 0;
|
|
|
|
SF = A.bit(7);
|
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionRST_o(uint3 vector) -> void {
|
|
|
|
wait(1);
|
|
|
|
push(PC);
|
|
|
|
PC = vector << 3;
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionSBC_a_irr(uint16& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = SUB(A, read(displace(x)), CF);
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionSBC_a_n() -> void {
|
|
|
|
A = SUB(A, operand(), CF);
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionSBC_a_r(uint8& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = SUB(A, x, CF);
|
|
|
|
}
|
|
|
|
|
2016-11-01 11:42:25 +00:00
|
|
|
auto Z80::instructionSBC_hl_rr(uint16& x) -> void {
|
|
|
|
wait(4);
|
|
|
|
auto lo = SUB(HL >> 0, x >> 0, CF);
|
|
|
|
wait(3);
|
|
|
|
auto hi = SUB(HL >> 8, x >> 8, CF);
|
|
|
|
HL = hi << 8 | lo << 0;
|
|
|
|
ZF = HL == 0;
|
|
|
|
}
|
|
|
|
|
2016-09-06 13:53:14 +00:00
|
|
|
auto Z80::instructionSCF() -> void {
|
|
|
|
CF = 1;
|
|
|
|
NF = 0;
|
|
|
|
HF = 0;
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSET_o_irr(uint3 bit, uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, SET(bit, read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSET_o_irr_r(uint3 bit, uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = SET(bit, read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionSET_o_r(uint3 bit, uint8& x) -> void {
|
|
|
|
x = SET(bit, x);
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSLA_irr(uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, SLA(read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSLA_irr_r(uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = SLA(read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionSLA_r(uint8& x) -> void {
|
|
|
|
x = SLA(x);
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSLL_irr(uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, SLL(read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSLL_irr_r(uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = SLL(read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionSLL_r(uint8& x) -> void {
|
|
|
|
x = SLL(x);
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSRA_irr(uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, SRA(read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSRA_irr_r(uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = SRA(read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionSRA_r(uint8& x) -> void {
|
|
|
|
x = SRA(x);
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSRL_irr(uint16& addr) -> void {
|
2016-10-29 00:33:30 +00:00
|
|
|
write(addr, SRL(read(addr)));
|
|
|
|
}
|
|
|
|
|
Update to v101r28 release.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
2017-01-08 20:55:02 +00:00
|
|
|
auto Z80::instructionSRL_irr_r(uint16& addr, uint8& x) -> void {
|
|
|
|
write(addr, x = SRL(read(addr)));
|
|
|
|
}
|
|
|
|
|
2016-10-29 00:33:30 +00:00
|
|
|
auto Z80::instructionSRL_r(uint8& x) -> void {
|
|
|
|
x = SRL(x);
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionSUB_a_irr(uint16& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = SUB(A, read(displace(x)));
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionSUB_a_n() -> void {
|
|
|
|
A = SUB(A, operand());
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionSUB_a_r(uint8& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = SUB(A, x);
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto Z80::instructionXOR_a_irr(uint16& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = XOR(A, read(displace(x)));
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|
|
|
|
|
2016-10-31 21:10:33 +00:00
|
|
|
auto Z80::instructionXOR_a_n() -> void {
|
|
|
|
A = XOR(A, operand());
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:09:33 +00:00
|
|
|
auto Z80::instructionXOR_a_r(uint8& x) -> void {
|
2016-09-06 13:53:14 +00:00
|
|
|
A = XOR(A, x);
|
2016-09-06 00:09:33 +00:00
|
|
|
}
|