HW support for fast-reading POTX/POTY (as paddles / as buttons)

[dansanderson]

Is your feature request related to a problem? Please describe. The mechanism for reading the analog pins of the joystick ports (POTX/POTY) involves instructing the CIA to connect a given port's pins to a SID, waiting 512 cycles at 1 MHz for the SID to measure the resistance on the line using an RC charge dump timer, then reading the value off of SID registers populated at that interval. 512 cycles at 1 MHz is a long delay for a game that otherwise runs at 40 MHz, and for a game that uses both joystick ports, this wait must be done twice in series. It is possible to code around the delay—the game can do other things while it is waiting—but this makes game code more complex.

Admittedly, very few games will use paddles, even when they're easy to code for. However, it would be nice to make 3-button gamepad controllers, which use POTX/POTY as buttons, easier to code for. A four-paddle game would be rare, but a two-player 3-button game might be more common, if it were an easy option.

Describe the solution you'd like Implement a dedicated FPGA circuit that performs a faster resistance test on the POTX/POTY lines of the joystick port. Offer POTX1, POTY1, POTX2, and POTY2 as dedicated registers in upper memory, as well as support the CIA+SID1 API.

If necessary, make this and the 1 MHz SID method selectable by a register, and/or delay the reporting of results on the SID1 register to simulate the delay.

Describe alternatives you've considered If we don't want to dedicate four upper memory byte registers for this, we could just support the CIA+SID1 API: $dc00.6-7 selects the port, and SID1 reports POTX $d419 and POTY $d41a. Making programs select the port is slightly cumbersome, but not a big deal if the SID register values are available immediately.

We could limit this feature to 3-button gamepads and merely report "high" and "low" POTX/POTY values as bits. Then we'd only need four bits of register space.

Additional context I do not know if any existing peripherals rely on the SID RC charge dump itself (i.e. fluctuating signal patterns imposed on the line by the computer) for any purpose. If this were opt-in via register by software, this wouldn't matter.

I'm assuming that the 1 MHz cycle rate used by the SID is a throwback and not a necessary electrical property of the RC timer.

[dansanderson]

— Oh wait, do we have this already? D620-D623? I'll try it out!

[dansanderson]

I'm going to close this. Even if there is a delay in updating the dedicated paddle registers, they obviate the need for a program to wait on the SID (because the SID connection isn't changing and destabilizing the value). The solution is to read paddle / button X/Y values from these registers.