| Posted By
Mad
on 2021-07-03
21:39:00
|  Joypad for plus/4
Hi guys!
I got a request by a future manufacturer of joypads. He was asking if it is possible to send commands to the joystick via the joystick port. On C64 this seems to be possible, and their joypads support several buttons by this. Not just one button like the standard joysticks for C64.. I couldn't give a propper answer because I almost know nothing of the plus/4 circuitry / periphal access.. I said I can ask here in the forum about that. So.. Is it possible to send signals to the joystick through the joystick port on plus/4?
Cheers and have a good day!
|
|
Posted By
gerliczer
on 2021-07-04
03:06:15
| Re: Joypad for plus/4
Some sort of limited single line serial communication might be possible using the joystick select bits/pins.
I'm thinking about a very simple protocol like this:
- at power up, after reset and (****)time-outs behave like normal 4 direction, 1 fire button joystick
- if received (*)k select line toggles in (**)rapid succession enter identification mode where signature is transmitted in 4 consecutive (***)scans (e.g. LR/NF, UD/F, LRUD/NF, -/F)
- if received k-1 select line toggles in rapid succession enter extended data transmission mode where 20 bits of state data are transmitted in 4 consecutive scans
- if received k+1 select line toggles in rapid succession reset to normal joystick mode
* 3? 4? 5?
** double clock, border, no memory refresh interference, different NTSC and PAL clock rates must be considered
*** select joystick, read data, deselect joystick
**** longer than reasonable scan duration
Four scans and twenty bits status word length are arbitrary values used only as an example.
|
|
Posted By
BSZ
on 2021-07-04
12:09:36
| Re: Joypad for plus/4
@gerliczer:Interesting idea! But I don't think it is that "simple". Remember: the Joy's select line controlled by the data lines directly! Select is not only active in the $FF08 write cycle. Select pulses also come during normal program execution or TED's video data fetch!
@Mad: There is no easy way for this, I think. Although I might be missing something. 
|
|
Posted By
Mad
on 2021-07-04
13:11:54
| Re: Joypad for plus/4
@BSZ: Thanks for the explanation.. If someday something pops up to get around this, I would be happy to hear about that.. After gerliczer posted about that I thought it would be an easy thing to do..
|
|
Posted By
gerliczer
on 2021-07-04
13:16:20
| Re: Joypad for plus/4
@BSZ: Damn cheapskates! I already felt proud of my help in creating multi-button gamepad support for the 264 series.  And it turned out to be all for naught.  No cookies for me this time either.  Well, life goes on...
|
|
Posted By
BSZ
on 2021-07-04
16:30:50
| Re: Joypad for plus/4
@gerliczer: Don't worry, you still have time to save the (plus/4)world! Anyway, let's be happy that we at least have any Joy-port!
|
|
Posted By
MIK
on 2021-07-05
12:12:28
 | Re: Joypad for plus/4
I'm not 100% sure but I believe 90's console pads do it the other way around, as in a chip in the pad sends a number to the machine. So it doesn't matter how many buttons a pad has because a direction or button in any combination has a number which the computers software interprets as a command. From what I recall, a game might skip say 3 out of every 9 commands sent from a pad to maintain comunication speed...
It's all above me though as I'm not a coder and are just thinking out loud..., if say the Select line in a Plus4 could be used in some way then maybe a chip in a pad could make use of it and with software to make sense of it then any thing could be possible (maybe).
I'll get my coat. 
|
|
Posted By
gerliczer
on 2021-07-06
02:33:37
| Re: Joypad for plus/4
So, I think, we have quite limited options. One would be manufacturing C64 compatible joystick interface for the Expansion Port which is not necessarily a good idea. Next would be using the joystick port of the SID-Cards but that would be too restrictive. Another way would be using the User Port as there are eight plus one or two more lines which could be used for data transfer and signalling. This method may be easily adapted to the other Commodore 8 bits with User Port too, but that would make it unusable with C16s and C116s. And finally MIK's idea in some slightly modified form like using the two joystick ports where one transmits continuously at some well tuned rate a synchronization stream and the other continuously cycles through and transmits the state data in sync with the other port. Or a combination of some of the options above.
|
|
Posted By
MIK
on 2021-07-06
09:20:39
| Re: Joypad for plus/4
Using both ports, you could have a 6 button controller.
The spare ports 4 directions and fire make up the remaining 5 buttons. You'd need 2 circuit boards in the pad, one wired to port 1 and the other port 2.
For two player, network two machines.
|
|
Posted By
gerliczer
on 2021-07-06
13:41:43
| Re: Joypad for plus/4
If ten bits are enough to describe all possible states of the designed gamepad then obviously yes. However, if you want to connect a more complicated device or want to connect two (or even more) controllers that need more than five bits to represent their states then a bit more complexity is required.
|
|
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.
|
|
Posted By
Chronos
on 2021-07-07
10:09:59
 | Re: Joypad for plus/4
And finally there is ZERO piece of software that supports more than 1 action button on our beloved plus/4. (..and you can hardly found any of them on c64 too)
|
|
Posted By
Mad
on 2021-07-07
13:23:34
| Re: Joypad for plus/4
@Chronos: The guy asked me if I would support this new joystick and protocol. On C64 these guys are one of the biggest publishers of C64 games. Sadly on plus/4 almost no one except You, Csabo, Kichy and me are doing new games it seems (I forgot maybe 10 others). So he would ask everyone doing games on plus/4 too later I suppose. Even if for instance Csabo and Kichy never would do such stuff I think.
For me it would be cool if space would be wired on the second button. Which is not possible.. But voila there would be hundreds of games (at least 3) supporting this not ZERO.
|
|
Posted By
gerliczer
on 2021-07-07
14:50:53
| Re: Joypad for plus/4
@TLC: KERNAL compatibility seems to be a blocking issue. I don't remember what happens when diagonal directions or directions with fire are selected in the BASIC editor screen. Do those generate erroneous key presses too? If not then perhaps every not standard joystick compatible gamepad event could be encoded as invalid signal combinations (two opposite directions or three directions at the same time and these combined with fire button presses). Or was that already what you were talking about?
|
|
Posted By
Chronos
on 2021-07-07
15:20:23
| Re: Joypad for plus/4
@MAD: okay, nice, we'll see what happens, i'm a big fan of 2 button systems like NES or MASTER SYSTEM so if any progress happens once i will support it!
|
|
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.
|
|
Posted By
Mad
on 2021-07-08
16:13:04
| Re: Joypad for plus/4
@TLC: Ok understood. It's "just" a demoscene guy from a big games label for C64 games. I think he is somehow the main man there, but not sure about that. Seems like they built an own protocol for C64, maybe they are aware of all other solutions for C64 since they are also there since the eightees doing C64 stuff. Maybe they don't know about the other approaches, but I would guess they know all the techniques used till now on their platform. Seems like they already finished the C64 part. They plus/4 part was somehow a sneaky addon they just wanted for fun. Maybe it will never turn into existence after you, Chronos, BSZ, MIK and gerliczer outlined the problems. Not sure, time will tell. At least they read this forum I think!
|
|
Posted By
unclouded
on 2021-07-09
23:24:42
| Re: Joypad for plus/4
"For me it would be cool if space would be wired on the second button"
This makes me think of an idea. It would require modifying the machine reversibly, but what if there were a MITM joystick on the keyboard cable? It would pass through any keys pulling K0 to K7 TED inputs to U13 outputs (only one output low impedance to GND when scanning that particular column). It could then be programmed to pull a K* input to GND when a particular joystick "button" (actual button or one direction of an axis) when a given U13 (C16. Is it a different refdes on other 264 machines?) output is low.
For example, a profile for a particular game that uses SPACE as "fire" could pull K4 low when the 6529 shows $fe on its outputs when the fire button is pressed. The game thinks the SPACE bar is being pressed even though the key switch for the space bar is open.
You'd need a different mapping for each game that used different keys, though the same approach could emulate a joystick (though not both joysticks since D1 and D2 from the data bus are not available on the keyboard cable) by recognizing $ff on the 6529 outputs.
Bonus points for pulling K* inputs to GND through the impedance of a pristine keyboard key held down hard.
|
|
Posted By
siz
on 2021-07-13
07:27:28
| Re: Joypad for plus/4
Following up TLC's ideas I have my own(?) protocol suggestion: the gamepad itself could be switched between traditional (4 directions and all fire buttons connected to the same wire) and extended mode where the select line of the joystick port would toggle between state read from the joystick:
1) read joystick state returns the 4 directions AND fire as being high to indicate that directions are read
2) second joystick state returns fire=low and the directions contain the state of up to 4 buttons.
This would require 2 subsequent joystick reads for the same port but IMHO this is simple enough to implement. Of course all the programs should be aware of this extended gamepad so it must be selected as a different control method but that's the price to use the extra buttons.
|
|
Posted By
gerliczer
on 2021-07-13
09:01:32
| Re: Joypad for plus/4
@siz: Unfortunately any similar scheme is almost doomed because of Data Bus "noise" on the select bits. BSZ directed my attention to this crucial detail more than a week ago. It made me sad.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
