Any gamepad experts on the forum?
The easy question first:
Does anyone know of a programmable gamepad that sends data via standard socket connection, so that I can code my own receiver? It will have to be part of the LAN somehow. Does such a thing even exist?
And then a more tricky one for the hardware gurus. @Bryce (https://www.cpcwiki.eu/forum/index.php?action=profile;u=225) @TotO (https://www.cpcwiki.eu/forum/index.php?action=profile;u=290) @Duke (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1624) (When do we get roles here so we can just tag @HardwareGurus? :))
How easy/difficult would it be to make an adapter for an Amstrad CPC joystick/gamepad, to give it a USB plug.
It must identify as a keyboard HID, and the adapter has to contain some logic circuit to do the following:
It must send 1 single keycode-pressed for each changed state, similar to the CPC joystick.
UP = value 1
DOWN = value 2
LEFT = value 4
RIGHT = value 8
FIRE 1 = value 16
FIRE 2 = value 32
FIRE 3 = value 64
Press UP (and hold) on the gamepad => send keycode 1
Press LEFT (and hold) on the gamepad => send keycode 5 (4+1)
Release UP on the gamepad => send keycode 4 (because LEFT is still held)
So something like this:
https://www.retronicdesign.com/en/
Except it must also contain that logic circuit to give each button those CPC'ish values, and transmit a corresponding keycode each time the state changes.
If curious: This is for connecting an Amstrad/Amiga/C64 joystick to a blu-ray player that only accepts keyboards, with the intention of playing Blu-Play games (www.blu-play.com). But keyboards connected to blu-ray players usually fires KEY_PRESSED and KEY_RELEASED instantly, even though you didn't release the key. Hence the need for states.
I guess the best solution for this would be to hack a cheap keyboard and wire an old CPC Joystick to it, like this -> https://www.youtube.com/watch?v=Y83jmDICLlI 8)
Not the best solution, but yes. I was watching that particular video myself too.
The best solution is some kind of adapter, so we can use existing joysticks / gamepads - and buy this adapter from some source.
Hacking a keyboard and soldering wires is not something most people would do. ;)
EDIT: Also... hacking a keyboard controller wouldn't be enough.
It would only let me assign each joystick button to a key on a keyboard. And that's not what I want.
I want some kind of matrix in the controller too, so that only a single keycode is sent representing the whole state of the joystick.
Now this one looks interesting.
Could be usable, with some new code maybe.
https://ethertubes.com/joykey/
Anyone have any experience with Arduino programming?
That would be easy to make and modify. I might have a look at making one just for fun. I probably have one of those Arduino boards somewhere here, or maybe even a smaller one.
Bryce.
Quote from: Bryce on 08:31, 07 February 20
That would be easy to make and modify. I might have a look at making one just for fun. I probably have one of those Arduino boards somewhere here, or maybe even a smaller one.
Yea. Meanwhile I stumbled across this:
https://ethertubes.com/joykey/
Seems to be what I'm looking for, if the code was modified a bit.
But aren't those Arduino boards somewhat expensive? Keeping price down is necessary if anyone is to have any interest. (The interest is already low ;-))
It's just a geeky idea of turning a standard blu-ray player into a retro'ish game-console. :)
Quote from: mr_lou on 09:23, 07 February 20
Yea. Meanwhile I stumbled across this:
https://ethertubes.com/joykey/ (https://ethertubes.com/joykey/)
Seems to be what I'm looking for, if the code was modified a bit.
But aren't those Arduino boards somewhat expensive? Keeping price down is necessary if anyone is to have any interest. (The interest is already low ;-))
It's just a geeky idea of turning a standard blu-ray player into a retro'ish game-console. :)
Arduino Nanos cost about €2.50 each. I wouldn't consider that overly expensive.
Bryce.
Quote from: Bryce on 10:56, 07 February 20
Arduino Nanos cost about €2.50 each. I wouldn't consider that overly expensive.
No that sounds very acceptable! I remember prices a lot higher. But that was a long time ago of course.
I'll check at the weekend if I have the parts. I could make you a prototype for testing if you like.
Bryce.
Edit: Just looked at the code and realised it requires a 32u4 Arduino. I don't think I have one of those, but I'll order a few, they cost about €7 each. More expensive, but still not the world.
Well I hope I caught you in time before you ordered any hardware.
I found out some annoying news.
It turns out, blu-ray players in general doesn't support most keys on a keyboard. While you can connect it and use the arrow keys and Enter etc, it sadly doesn't mean all keys are supported. I just assumed so.
For example, even though a game supports all numeric keys - they only work from a remote control - not from a keyboard.
In fact, the only keys that'll work seems to be the arrows keys and Enter. And that's not enough to make a virtual matrix.
So that renders the whole idea useless. :-(
The only thing that can save the idea, is to use infrared instead of a USB plug somehow, since remote controls seems to have more support. But given that all remote controls differ so much from each other, that's probably not a feasible option either.
Sorry for wasting your time. I should have checked this. I just assumed when a keyboard was connected and the device responded to some of the keys, then all keys would obviously work. But apparently not. :-(
Hmm well....
I just did a quick search just for fun, and it seems there are in fact several Arduino infrared projects around, that can be easily programmed with another remote control...
So maybe there's still hope... dunno.
In any case, it'll be a different project then I suppose. And I don't know which keycodes are supported default via a remote....
@mr_lou (https://www.cpcwiki.eu/forum/index.php?action=profile;u=96) : Too late. I ordered a few Arduino 32u4 compatible boards and they arrived this morning. They won't go to waste, even if they won't help in this case. However, I can define the joystick directions to anything I choose, so if there are keys that would work let me know and I will edit the software accordingly. If infrared is better, I can stick an IR transmitter on the board and do it that way, however, not all Bluray players will use the same frequency, so the controller would have to be specific to the device being used.
Bryce.
Quote from: Bryce on 08:27, 12 February 20
@mr_lou (https://www.cpcwiki.eu/forum/index.php?action=profile;u=96) : Too late. I ordered a few Arduino 32u4 compatible boards and they arrived this morning. They won't go to waste, even if they won't help in this case. However, I can define the joystick directions to anything I choose, so if there are keys that would work let me know and I will edit the software accordingly. If infrared is better, I can stick an IR transmitter on the board and do it that way, however, not all Bluray players will use the same frequency, so the controller would have to be specific to the device being used.
My first thought too, was to maybe assign to other keys. But it seems that the only keys we can be sure works, are the arrow keys and Enter. And that's not enough. So the USB approach is dead.
Adding an infrared transmitter sounds interesting. And judging from other Arduino projects, it would be relatively easy to let the gamepad learn the infrared codes from another remote control.
However, I still don't know which codes will be accepted. For example. The number keys on the remote was accepted - but not on the keyboard. I know there are remote controls with alphabetic buttons, but do they work on devices that doesn't have such a remote? And even if they do, does that mean we can transmit any kind of code?
And infrared codes differ a lot from "keycode". How do we figure out which infrared transmitter code corresponds to "keycode 1"? That would require some recognizable pattern in the infrared codes, which I doubt will be present.
Meanwhile, I've learned that apparently there are quite a lot of infrared gamepads out there. So it should work, if the right codes are available and usable.....
It's not just the codes. It's the frequency too. IR transmitters can be anywhere between 30 and 56kHz and not all players use the same frequency. The codes (in most cases just some version of RC5) are just a software issue, but the frequency involves using different components too.
I thought the aim was to just connect a joystick, with maybe two fire buttons. Would that not be enough for a game?
Bryce.
Quote from: Bryce on 09:27, 12 February 20
It's not just the codes. It's the frequency too. IR transmitters can be anywhere between 30 and 56kHz and not all players use the same frequency. The codes (in most cases just some version of RC5) are just a software issue, but the frequency involves using different components too.
I've read about Arduino remote controls that can learn from existing remote controls. Are you saying that apart from this learning, one also has to manually supply the frequency?
Quote from: Bryce on 09:27, 12 February 20I thought the aim was to just connect a joystick, with maybe two fire buttons. Would that not be enough for a game?
The aim is to do that yes - but at the same time translate the state of the gamepad into 1 single keycode, similar to the CPC joystick.
If the state is UP + RIGHT + FIRE - then send value 1 + 8 + 16 = 25
This is because only one button can be pressed at a time on a standard remote control (and a USB keyboard too, when connected to a blu-ray player), so we have to set it up in a way that a single code represents the entire state of the gamepad.
UP + RIGHT + FIRE => Send 25
Release FIRE => Send 9
Release UP => Send 8
Press DOWN => Send 10
and so on
But these values are keycode values to receive by the BD-J Xlet - not infrared transmitter codes. So how do we figure out which infrared transmitter codes corresponds to "keycode 8?"?
Yes, the codes are the 1's and 0's being sent/received, but the carrier frequency they are "travelling" on can be anywhere between 30kHz and 56kHz. Most Arduino self learning plug-ins are set to a certain (unchangeable) frequency. Those fancy self-learning remote controls work differently in that they have a variable frequency receiver and transmitter.
The USB solution you linked to would only send one code at a time, but it wouldn't be the joystick state, rather each direction/fire button would be assigned a HID code (these are standard) and that would be sent to the device. However, I could change that within the Arduino, so that for example UP + Fire would have a different code than just UP. Which then gives the possibility of 12 different code (each direction + each direction plus Fire 1 + each direction + Fire 2 = 12)
Bryce.
Quote from: Bryce on 10:25, 12 February 20
However, I could change that within the Arduino, so that for example UP + Fire would have a different code than just UP. Which then gives the possibility of 12 different code (each direction + each direction plus Fire 1 + each direction + Fire 2 = 12)
It would have to be 8 directions though, to include diagonal directions too.
01: UP
02: DOWN
03: --- not used ---
04: LEFT
05: LEFT + UP
06: LEFT + DOWN
07: --- not used ---
08: RIGHT
09: RIGHT + UP
10: RIGHT + DOWN
11: --- not used ---
12: --- not used ---
13: --- not used ---
14: --- not used ---
15: --- not used ---
16: FIRE
17: FIRE + UP
18: FIRE + DOWN
19: --- not used ---
20: FIRE + LEFT
21: FIRE + LEFT + UP
22: FIRE + LEFT + DOWN
23: --- not used ---
24: FIRE + RIGHT
25: FIRE + RIGHT + UP
26: FIRE + RIGHT + DOWN
27: --- not used ---
28: --- not used ---
29: --- not used ---
30: --- not used ---
31: --- not used ---
32: FIRE 2
33: FIRE 2 + UP
34: FIRE 2 + DOWN
35: --- not used ---
36: FIRE 2 + LEFT
37: FIRE 2 + LEFT + UP
38: FIRE 2 + LEFT + DOWN
39: --- not used ---
40: FIRE 2 + RIGHT
41: FIRE 2 + RIGHT + UP
42: FIRE 2 + RIGHT + DOWN
43: --- not used ---
44: --- not used ---
45: --- not used ---
46: --- not used ---
47: --- not used ---
48: FIRE 2 + FIRE
49: FIRE 2 + FIRE + UP
50: FIRE 2 + FIRE + DOWN
51: --- not used ---
52: FIRE 2 + FIRE + LEFT
53: FIRE 2 + FIRE + LEFT + UP
54: FIRE 2 + FIRE + LEFT + DOWN
55: --- not used ---
56: FIRE 2 + FIRE + RIGHT
57: FIRE 2 + FIRE + RIGHT + UP
58: FIRE 2 + FIRE + RIGHT + DOWN
So that's 35 different codes for all possible combinations.
Also not an issue to do.
Bryce.
Here is the source for the BD-J Xlet handler of such an input. Just for confirmation / inspiration.
public class PadHandler {
private static final int TYPE_BLUPADS = 1;
private static final int TYPE_GAMEPAD = 2;
private static int activePad = TYPE_GAMEPAD;
private static int blupadsState = 0;
private static PadInterface padInterface = null;
public static void setCallback(PadInterface pi) {
padInterface = pi;
}
public static void handlePressed(int input) {
if (input < 9) { // Trigger BluPads if pressing directional keys on PAD0
activePad = TYPE_BLUPADS;
} else if (input > 400) { // Trigger normal gamepad if pressing shoulder buttons
activePad = TYPE_GAMEPAD;
}
switch (activePad) {
case TYPE_BLUPADS: // Translate into real keycodes
int pressed = (input & ~blupadsState);
int released = (blupadsState & ~input);
blupadsState = input;
if (pressed > 0) {
callPressed(pressed);
}
if (released > 0) {
callReleased(released);
}
break;
case TYPE_GAMEPAD:
padInterface.keyPressed(input); // Just forward the actual keycode
break;
}
}
public static void handleReleased(int released) {
switch (activePad) {
case TYPE_BLUPADS:
blupadsState = blupadsState & ~released;
callReleased(released);
break;
case TYPE_GAMEPAD:
padInterface.keyReleased(released);
break;
}
}
private static void callPressed(int pressed) {
if ((pressed & 1) != 0) {
padInterface.keyPressed(org.havi.ui.event.HRcEvent.VK_UP);
}
if ((pressed & 2) != 0) {
padInterface.keyPressed(org.havi.ui.event.HRcEvent.VK_DOWN);
}
if ((pressed & 4) != 0) {
padInterface.keyPressed(org.havi.ui.event.HRcEvent.VK_LEFT);
}
if ((pressed & 8) != 0) {
padInterface.keyPressed(org.havi.ui.event.HRcEvent.VK_RIGHT);
}
if ((pressed & 16) != 0) {
padInterface.keyPressed(org.havi.ui.event.HRcEvent.VK_ENTER);
}
if ((pressed & 32) != 0) {
padInterface.keyPressed(org.bluray.ui.event.HRcEvent.VK_POPUP_MENU);
}
}
private static void callReleased(int released) {
if ((released & 1) != 0) {
padInterface.keyReleased(org.havi.ui.event.HRcEvent.VK_UP);
}
if ((released & 2) != 0) {
padInterface.keyReleased(org.havi.ui.event.HRcEvent.VK_DOWN);
}
if ((released & 4) != 0) {
padInterface.keyReleased(org.havi.ui.event.HRcEvent.VK_LEFT);
}
if ((released & 8) != 0) {
padInterface.keyReleased(org.havi.ui.event.HRcEvent.VK_RIGHT);
}
if ((released & 16) != 0) {
padInterface.keyReleased(org.havi.ui.event.HRcEvent.VK_ENTER);
}
if ((released & 32) != 0) {
padInterface.keyReleased(org.bluray.ui.event.HRcEvent.VK_POPUP_MENU);
}
}
}
Can it handle 35 different input codes?
Bryce.
Quote from: Bryce on 11:24, 12 February 20
Can it handle 35 different input codes?
It should, since it translate the "virtual keycode" into 1+ real keycodes.
So if virtual keycode 10 is received, it calls
keyPressed(org.havi.ui.event.HRcEvent.VK_DOWN);
keyPressed(org.havi.ui.event.HRcEvent.VK_RIGHT);
This is why it would be really great if all values could be bit-based. Otherwise I'd have to add 35 individual translations.
The Arduino can read the Joystick status (with multiple key presses) but the USB HID standard can only send single integers. I could artificially use numbers that break down into bits of course.
Bryce.
Quote from: Bryce on 12:09, 12 February 20
The Arduino can read the Joystick status (with multiple key presses) but the USB HID standard can only send single integers. I could artificially use numbers that break down into bits of course.
And that was the exact idea with USB - until learning that blu-ray players only accept arrow keys and Enter key from a USB keyboard, which turned the attention towards an infrared solution instead.
But we could run into the same problem there. Who knows which transmit-codes a blu-ray player will accept.
D-pad and Enter? Absolutely. Number buttons? Yes. Alphabetic characters? Maybe. But transmit codes corresponding to keycodes from 1 to 58? Well we know that Enter = 10, so maybe....
Have you any way of finding out which players accept more than just those keys? Have you tried connecting a keyboard to your player?It may be that the players firmware only reacts to those limited keys, but that your software can read the port directly?
Bryce.
Quote from: Bryce on 12:38, 12 February 20
Have you any way of finding out which players accept more than just those keys? Have you tried connecting a keyboard to your player?It may be that the players firmware only reacts to those limited keys, but that your software can read the port directly?
No my software is sandboxed. I can only ask for keycodes.
So it is the device itself that has to receive the infrared transmit codes and interpret them into keycodes that it then forwards to my software.
But yes, I connected a keyboard to many players. That's how I know that only arrow keys and Enter key is supported.
Running the same software in PowerDVD for example, lets me use numeric keys. Hardware players don't.
Hmmm, then it's going to be very limited or not possible at all.
Bryce.
Quote from: Bryce on 12:53, 12 February 20
Hmmm, then it's going to be very limited or not possible at all.
We won't know till we try.
But it's a lot of work just to try....
...and even less usable when you say it won't be possible to make a universal self-learning thing.
So...
So I was messing around with the Micro Pro board I ordered and I may have a possible solution....
Do BluRay players accept a mouse input from the USB port?
Bryce.
Quote from: Bryce on 11:16, 14 February 20
So I was messing around with the Micro Pro board I ordered and I may have a possible solution....
Do BluRay players accept a mouse input from the USB port?
Sadly no. Not in general.The specs does support mouse input, and developers are actually encouraged to add mouse support for their apps. (8-bit Memoirs also supports mouse - you can click article numbers, or just click the sides to toggle pages etc).But there are almost no blu-ray players that implements it.
The only reliable input method is infrared remote control - or make a custom socket based solution.