Closed dshadoff closed 1 year ago
Pull request #12 corrects item 1, 2, and 4 above (the clear signal is now ALWAYS sent, because we assume single-controller input on a given port; this would work even with an unreleased multi-tap peripheral attached).
Additionally, the port type is now preserved in the return value of read_pad(), as it is valuable to be matched with the data. Pad_type should be derived from this, not from a separate read.
I can close this now anyway - if I come back to fix part 3, I'll make it a new issue (but it's not a big deal)
This is a more all-encompassing issue (and may account for part of the reason that the pad_type isn't working properly).
1) The read joypad routine assumes that there is zero time between issuing a scan command and being able to read the data. 2) The control register for "data ready" is misunderstood, and should be the determining factor on whether to read the data value after issuing a read command 3) The initialize function sets the data port to "output" mode rather than input mode 4) The "clear" signal (to send a reset value on scan) is never sent, and probably completely misunderstood.