2015-10-10 02:16:12 +00:00
|
|
|
Justifier::Justifier(bool port, bool chained):
|
|
|
|
Controller(port),
|
|
|
|
chained(chained),
|
2015-11-10 11:02:29 +00:00
|
|
|
device(chained == false ? (unsigned)Device::ID::Justifier : (unsigned)Device::ID::Justifiers)
|
2015-10-10 02:16:12 +00:00
|
|
|
{
|
|
|
|
create(Controller::Enter, 21477272);
|
|
|
|
latched = 0;
|
|
|
|
counter = 0;
|
|
|
|
active = 0;
|
|
|
|
|
|
|
|
player1.x = 256 / 2;
|
|
|
|
player1.y = 240 / 2;
|
|
|
|
player1.trigger = false;
|
|
|
|
player2.start = false;
|
|
|
|
|
|
|
|
player2.x = 256 / 2;
|
|
|
|
player2.y = 240 / 2;
|
|
|
|
player2.trigger = false;
|
|
|
|
player2.start = false;
|
|
|
|
|
|
|
|
if(chained == false) {
|
|
|
|
player2.x = -1;
|
|
|
|
player2.y = -1;
|
|
|
|
} else {
|
|
|
|
player1.x -= 16;
|
|
|
|
player2.x += 16;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Justifier::enter() -> void {
|
2011-06-26 12:51:37 +00:00
|
|
|
unsigned prev = 0;
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
while(true) {
|
|
|
|
unsigned next = cpu.vcounter() * 1364 + cpu.hcounter();
|
2011-06-26 12:51:37 +00:00
|
|
|
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
signed x = (active == 0 ? player1.x : player2.x), y = (active == 0 ? player1.y : player2.y);
|
2011-06-26 12:51:37 +00:00
|
|
|
bool offscreen = (x < 0 || y < 0 || x >= 256 || y >= (ppu.overscan() ? 240 : 225));
|
|
|
|
|
|
|
|
if(offscreen == false) {
|
|
|
|
unsigned target = y * 1364 + (x + 24) * 4;
|
|
|
|
if(next >= target && prev < target) {
|
|
|
|
//CRT raster detected, toggle iobit to latch counters
|
|
|
|
iobit(0);
|
|
|
|
iobit(1);
|
|
|
|
}
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if(next < prev) {
|
2015-11-10 11:02:29 +00:00
|
|
|
int nx1 = interface->inputPoll(port, device, 0 + X);
|
|
|
|
int ny1 = interface->inputPoll(port, device, 0 + Y);
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
nx1 += player1.x;
|
|
|
|
ny1 += player1.y;
|
|
|
|
player1.x = max(-16, min(256 + 16, nx1));
|
|
|
|
player1.y = max(-16, min(240 + 16, ny1));
|
|
|
|
}
|
|
|
|
|
|
|
|
if(next < prev && chained) {
|
2015-11-10 11:02:29 +00:00
|
|
|
int nx2 = interface->inputPoll(port, device, 4 + X);
|
|
|
|
int ny2 = interface->inputPoll(port, device, 4 + Y);
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
nx2 += player2.x;
|
|
|
|
ny2 += player2.y;
|
|
|
|
player2.x = max(-16, min(256 + 16, nx2));
|
|
|
|
player2.y = max(-16, min(240 + 16, ny2));
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
prev = next;
|
2011-06-26 12:51:37 +00:00
|
|
|
step(2);
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-10 02:16:12 +00:00
|
|
|
auto Justifier::data() -> uint2 {
|
2011-06-24 10:43:29 +00:00
|
|
|
if(counter >= 32) return 1;
|
|
|
|
|
|
|
|
if(counter == 0) {
|
2015-11-10 11:02:29 +00:00
|
|
|
player1.trigger = interface->inputPoll(port, device, 0 + Trigger);
|
|
|
|
player1.start = interface->inputPoll(port, device, 0 + Start);
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if(counter == 0 && chained) {
|
2015-11-10 11:02:29 +00:00
|
|
|
player2.trigger = interface->inputPoll(port, device, 4 + Trigger);
|
|
|
|
player2.start = interface->inputPoll(port, device, 4 + Start);
|
2011-06-24 10:43:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
switch(counter++) {
|
|
|
|
case 0: return 0;
|
|
|
|
case 1: return 0;
|
|
|
|
case 2: return 0;
|
|
|
|
case 3: return 0;
|
|
|
|
case 4: return 0;
|
|
|
|
case 5: return 0;
|
|
|
|
case 6: return 0;
|
|
|
|
case 7: return 0;
|
|
|
|
case 8: return 0;
|
|
|
|
case 9: return 0;
|
|
|
|
case 10: return 0;
|
|
|
|
case 11: return 0;
|
|
|
|
|
|
|
|
case 12: return 1; //signature
|
|
|
|
case 13: return 1; // ||
|
|
|
|
case 14: return 1; // ||
|
|
|
|
case 15: return 0; // ||
|
|
|
|
|
|
|
|
case 16: return 0;
|
|
|
|
case 17: return 1;
|
|
|
|
case 18: return 0;
|
|
|
|
case 19: return 1;
|
|
|
|
case 20: return 0;
|
|
|
|
case 21: return 1;
|
|
|
|
case 22: return 0;
|
|
|
|
case 23: return 1;
|
|
|
|
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
case 24: return player1.trigger;
|
|
|
|
case 25: return player2.trigger;
|
|
|
|
case 26: return player1.start;
|
|
|
|
case 27: return player2.start;
|
2011-06-24 10:43:29 +00:00
|
|
|
case 28: return active;
|
|
|
|
|
|
|
|
case 29: return 0;
|
|
|
|
case 30: return 0;
|
|
|
|
case 31: return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-10 02:16:12 +00:00
|
|
|
auto Justifier::latch(bool data) -> void {
|
2011-06-24 10:43:29 +00:00
|
|
|
if(latched == data) return;
|
|
|
|
latched = data;
|
|
|
|
counter = 0;
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
if(latched == 0) active = !active; //toggle between both controllers, even when unchained
|
2011-06-24 10:43:29 +00:00
|
|
|
}
|