Posted By
TLC
on 2021-07-08
08:31:08
|  Re: Joypad for plus/4
@gerliczer: I merely outlined some loose facts and ideas, with context (applicable port, schema, whatever) admittedly changed frequently  .
I think there's no problem with particular combinations of joystick directions + fire, with regards to the Kernal's (buggy) keyscan routine. What I meant, that any joystick activity is (mis)interpreted by the Kernal keyscan as keyboard activity, and produces unwanted garbage keypresses for Basic. This is a problem, if some particular device occassionally leaves joy port inputs in an active state. Any protocols invented for "extended" devices, will need to make sure that no "permanent" joystick port activity is produced under their normal operation. I think the simplest solution for that, is just to strictly follow the "no user activity --> no joystick port activity" principle in an extended protocol design. With that, "extended" devices could not disturb Basic any more than typical standard joysticks already do.
As for direction combinations normally not produced by joysticks, I merely meant that this knowledge could be taken advantage of as a clue for sequence syncing in a "theoretical" time-multiplexing extended joystick protocol.
@MAD: one final note. In fact, there "have" already been classic, multi-button "controllers" produced for the C64. Might sound a bit far fetched example at first, but, the Commodore 1350 "joystick mouse" in has two independent buttons. There's no bidirectional communications schema implemented; LMB is "fire", and RMB is simply mapped to the POTX input of the C64 joystick port (and can be scanned using the SID's POTX register). I don't know if there were any 3-button mice officially produced for the C64 which follow the 2-button 1350's schema, but an additional MMB could just have been mapped to the POTY input of the C64 port, logically extending upon the 1350 RMB's way. The point I'd like to make is - in fact, your friend doesn't really have to invent a bidirectional protocol for a multi-button controller, unless (s)he absolutely wants one, even for the C64. Given (up to) two extra buttons, these could just be hooked to the POTX/POTY inputs similarly to how the 1350 does this (and query them from C64 code in a similar fashion). Given, say, 4, 6 extra buttons, these could still be hooked to the POTX/POTY inputs over some cleverly calibrated resistor networks (...remember, POTX/POTY are analog paddle inputs), and still queried by C64 code independently. As for Plus/4 compatibility.... In short, standard Plus/4 joystick port interfacing would be similarly tough as outlined earlier. (This task would definitely need a microcontroller + some clever / likely time multiplexed protocol). SID Card joystick port compatibility would just be "granted" as-is (--> it'd work out of the box). A theoretical Plus/4 User Port C64 joy port interface would need to be just a little bit more complicated (given max. 2 extra buttons) or fairly more complicated (given more than 2 extra buttons) to support this, to a theoretical simple, digital/bidirectional one.
|
