Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] SI: Rework SI command architecture #8239

Open
wants to merge 6 commits into
base: master
from

Conversation

@booto
Copy link
Contributor

commented Jul 13, 2019

[WIP: Opening to generate builds for testers.]

This builds on #8236, but is separated out because this is potentially more dangerous, and it shouldn't hold up those changes.

This is a rework of the SI command architecture, causing it to be event based with distinct sending command/getting response stages.

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch from 2ad0a31 to af08b43 Jul 13, 2019

SI: Overhaul SI request/response
This commit overhauls the SI request/response architecture to that each of
those parts of the protocol actually take some amount of time. Events are
used to trigger the next stage of the protcol, and it's only hooked up for
commands that go via SerialInterface::RunSIBuffer.

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch from af08b43 to a00d855 Jul 13, 2019

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch 2 times, most recently from 4868a11 to 26b4fde Jul 13, 2019

SI: Migrate polling to the event-based architecture
SI polling happens via events, SI_POLL enable bits are respected. Netplay
is probably broken by this.

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch 2 times, most recently from e2530fc to 54a691e Jul 13, 2019

SI: Fix bugs with input for movies
GetPadStatus() causes input to be read from the movie, but gets called
twice in the RunBuffer path for CMD_DIRECT- once at the start, and once
within GetData(). This isn't a problem when polled input wasn't going
through the "normal" command mechanism, but now the result from the first
GetPadStatus is kept and reused.

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch from 54a691e to 24d3b04 Jul 13, 2019

@@ -164,10 +162,8 @@ GCPadStatus CSIDevice_GCController::GetPadStatus()
// [00?SYXBA] [1LRZUDRL] [x] [y] [cx] [cy] [l] [r]
// |\_ ERR_LATCH (error latched - check SISR)
// |_ ERR_STATUS (error on last GetData or SendCmd?)
bool CSIDevice_GCController::GetData(u32& hi, u32& low)
bool CSIDevice_GCController::GetData(GCPadStatus& pad_status, u32& hi, u32& low)

This comment has been minimized.

Copy link
@BhaaLseN

BhaaLseN Jul 13, 2019

Member

It seems that pad_status could be const here (and cascading everywhere else) - at least I didn't see anything that would mutate its state.

Suggested change
bool CSIDevice_GCController::GetData(GCPadStatus& pad_status, u32& hi, u32& low)
bool CSIDevice_GCController::GetData(const GCPadStatus& pad_status, u32& hi, u32& low)
Source/Core/Core/HW/SI/SI.cpp Outdated Show resolved Hide resolved

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch 3 times, most recently from 2774a28 to 695cc1f Jul 16, 2019

SI: Constrain sampling by SI_POLL Y field
Confirmed on hardware using a signal capture device:
 - SI polls are aligned to the beginning of vsync for each field
 - There are only Y polls per field
 - Each (3 byte, pad status) SI poll on the wire goes for roughly 0.384ms
   (including est. on high trailing edge of stop bit) with a genuine
   controller, this equates to roughly 6 scan lines

Includes some bug fixes from earlier commits in this series.

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch 7 times, most recently from 4a0628b to e0352ad Aug 6, 2019

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch 3 times, most recently from 16d12f5 to ce26557 Aug 17, 2019

SI: GCAdapter reorganisation
Reorganise GCAdapter, try to cater for calibration.

@booto booto force-pushed the booto:si_greatest_hits_vol_2 branch from ce26557 to 672001b Aug 17, 2019

VI: Trying to make SI polling more accurate
These changes were based on trying to match a trace of hardware polling on
the controller port.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.