Posted By
TLC
on 2021-07-07
07:52:16
|  Re: Joypad for plus/4
As @BSZ has already pointed out, it's quite difficult to invent a viable bidirectional communication protocol for the Plus/4 joystick ports. (The Select' pin is the only, theoretically useable output, and even that one is controlled by a data bus bit. That means that 1.) the protocol must be aware (and protected...) of the normal "random" data bus traffic appearing on the pin, 2.) implementing the host-side transmit code looks fairly tricky, and 3.) clearly needs a programmable device i.e. a microcontroller or (maybe) a CPLD on the gamepad's side.) I'm sure this can be done, but needs effort.
Given "existing" C64 / or some other platform specific multi-button controllers that one'd be to interface to the Plus/4's joystick ports, I think we're certainly talking about building microcontroller based interfaces. (Bit overkill? Who knows.)
Given some multi button controllers whose host interface part could be updated or modified to support some Plus/4 specific protocol... well. There's a small / additional culprit here, that'd prevent users to hook the "C64 specific" controller to the Plus/4, using their "standard", old styled Mini-DIN to DB9 joystick interface cables, first. These classic interface cables typically wire the Select' pin of the Plus/4 joystick port, to the GND pin of the joystick's DB9 socket. This is almost certainly not what a custom C64 specific multi button controller needs. Any theoretically working solutions would need a straight (GND, +5V, UP, DOWN, RIGHT, LEFT) and Select' connection schema first. Only then, could we talk about the specific / multi button capable communication protocol to be implemented. (The point here is, that an "optionally" Plus/4 compatible C64 multi button controller would need custom hardware (at least, a specially wired interface cable) to connect to the Plus/4's joystick port, in any case.) From the implied complexity, I guess we'd be rather talking about some / exclusively Plus/4 specific (specific firmware + Mini-DIN equipped) multi button controller variant at this point.
Previously, I suspected some potential in using C64 specific "4 player" joystick adapters for a simple "shortcut", but... from a closer look, these typically use a multiplexer, so... all direction inputs of both joystick ports are exclusively inputs. No-go.
The SID-Card's joystick port (I'm talking about the classic Synergy type) is also of no use here. Although the joy port can be an output due to a design flaw (or... maybe, a last-minute change of substituting a 6529B in favour of a 74LS245), the outputs are only active during write cycles to the $fd80 port.
Producing a specific, fully compatible "single port" C64 joystick interface for the Plus/4's User Port, would be trivial. (Only a matter of connectors and wiring.) The User Port's data lines are trivially bidirectional, and can be set to input and output on a bit-by-bit basis. No C16 / C116 support of course  .
Coming up with an "extended" (fully C64 compatible, bidirectional) joystick interface for the Plus/4's joystick port, other than the difficulties already discussed, I think the main concern would be compatibility. The protocol would need to make sure that the joystick directions are never, ever pulled active, unless necessary. Remember, the standard Kernal ROM keyboard scan routines weren't written with separate keyboard + joystick selector lines in mind, so, any joystick port activity effectively results in producing keypresses in Basic... right? Any joystick port inputs accidentally or intentionally left active, act similarly to a stuck joystick, i.e. the "stuck key" can be only get rid of by disconnecting the device from the joystick port. Any interface design absolutely needs to make sure that the host joystick port's side is kept inactive, unless there's activity on the controller's side.
Theoretically, for a simple "multi button" protocol, maybe, the controller could use "time multiplexing" by some clever timing (i.e. in the order of some / some-ten single clock cycles), and only when necessary.
0.) No activity --> no activity
1.) One of the standard directions and button are activated --> transmit as-is, like it was a standard 1-button joystick
2.) At least one of the extra buttons is activated --> 5-bit nibbles are alternated sequentially by the pre-defined timing, as long as activity is present.
For 2.), one could use a "sync" nibble first, with all directions activated (--> under normal circumstances, it's pretty sure that opposite directions are never activated at the same time; so, an all-active nibble is certainly something that'd normally never happen). Nibble 2 should be the "standard 4 directions + fire", this one could be verified against no simultaneously active opposite directions, thus, provide a clue as to whether the sync is correct. From nibble 3 and on, the bits could carry the states of the various extra buttons and gadgets. The host code would need to sample the joystick port into a buffer with the predefined timing in mind, and make deductions accordingly.
|
