RTC state machine improvements #3459
Conversation
Unsure if all of this is entirely right (haven't ran any tests to confirm behavior here). Fixes RTC within Pokemon games (and maybe other games) due to the added write latch code adding a _readPins call.
|
Some quick testing seems to indicate this isn't entirely correct. It is correct in that spamming CS | SCK writes will not continously increase the bits read (makes sense, the RTC should have no way to distinguish these since it should only be able to react to edges happening). However, initial testing made it seem like simply setting CS to low would not abort the RTC command. However, the old code seems rather incorrect completely? The RTC transfer step 0 and 1 seem to be unneeded in practice. Those steps seem to be more how games usually interact with RTC. They kind of make sense with a more strict reading of the spec sheet, but in practice, it seems all that really happens here is a few things:
|
|
I can review this once you've gotten it tested well. You mention it fixes some Pokémon stuff but don't say how. |
|
The current (well, before the write latch PR) RTC state machine kind of only works with game code, but not any code which decides to be more naughty. The write latch PR proceeded to insert an extra _readPins call within direction change, which is sort of more the same as a "naughty" write writing the exact same data as before (which should do nothing, and my testing indicates that is the case), but the RTC state machine did not operate strictly on edges everywhere, so this triggered an extra bit read (but this is without SCK actually rising, so this should not happen). |
also correctly handle rtc output in general, even in cases outside of an rtc read cmd _outputPins needed to be corrected here, it shouldn't be reading gpioBase here...
Separate out command start and command write data processing Command start processing happens again if the command magic is invalid (note: doesn't apply to the unmapped command 5) Ensure command data processing loops Output 1s for commands with no actual output
CasualPokePlayer
changed the title
| int32_t rtcBytesRemaining; | ||
| int32_t rtcTransferStep; |
There was a problem hiding this comment.
You should put the new RTC flags here instead.
There was a problem hiding this comment.
For a later PR, I was planning on actually using this space for the RTC shift register, shrinking rtcBytesRemaining down to a byte, giving 7 free bytes total. I figure too reusing the uint8_t reserved0; would be better since these new flags are just another byte, instead of having it be GBASerializedHWFlags3 flags3; \ uint8_t reserved1[3];.
There was a problem hiding this comment.
How big is the shift register?
Also, if you can, it'd be nice to try to retain backwards compatibility by parsing the old state into the new format if the savestate is old enough. It probably won't matter much, but I'm not sure.
There was a problem hiding this comment.
As far as I know currently, at least 50 bits it seems, so at least need to have 7 bytes.
Currently, the changes should end up resulting in backwards compatibility for LE machines, due to how the changes have been applied, although BE machines would be screwed (although even then in practice, these savestates are very unlikely to be in the middle of some RTC operation so it practically shouldn't change anything).
There was a problem hiding this comment.
How does this affect endianness separately? The savestates are endianness-independent, by design. If you broke that, that's a bug.
There was a problem hiding this comment.
Might be misunderstanding how the state system operates, I was operating under the assumption shrinking a state variable down and reserving the later bytes is fine for LE (as the later bytes are always 0 anyways) but screws over BE. If it's the case that's fine for either then I guess the states should be fine for either case.
There was a problem hiding this comment.
Save states are stored in LE format, so shrinking the variable from the end should work as intended on either host byte order.
Unsure if all of this is entirely right (haven't ran any tests to confirm behavior here). Fixes RTC within Pokemon games (and maybe other games) due to the added write latch code adding a _readPins call to direction writes.