Hardware Project for Pi's running RO.

I’m thinking of producing a pair of old skool game paddles for Raspberry Pis running RISC OS.

These would consist of a rotary encoder and a pushbutton akin to the TV games of the 70’s and early 80’s and would hook up to the Pi’s GPIO pins directly. (Hence the use of a digital rotary encoder, rather than a pot.) The plan is to get something mocked up for the Southwest Show next month and I’m looking for feedback.

Here’s the rough idea…

Each pair of paddles would come with a driver module that would provide the game programmer with a simple API provided using 3 SWI calls. I haven’t got anything official yet, so what I have here is subject to change (etc etc).

Paddle_Register : R0,R1,R2,R3

R0 > Paddle specifier (0 or 1)
R1 > GPIO pin of CLK signal.
R2 > GPIO pin of DT signal.
R3 > GPIO pin of pushbutton.

CLK and DT are the names PiHut gives for the rotary encoder pulses. Means paddles can be connected to any free I/O pins available. This call initialises a counter (UINT64 or a big enough unsigned INT to allow for movement.) and sets it at half max value for variable size. We would also setup an interrupt hook to increment and decrement this counter on movement of the paddle.

Paddle_Read : R0 TO R1,R2

R0 > Paddle specifier (as setup above).
R1 < Counter.
R2 < Button State.

Movement would be measured by doing a diff of the current counter value and the value last read by the user program. The button state 0, or 1 would be read on-the-fly.

Paddle_Deregister : R0

R0 > Paddle specifier.

This would de-register a paddle effectively un-doing whatever was done by a Paddle_Register call (above)

As mentioned above, the hardware itself will consist of a rotary paddle and a push button a la the classic analogue paddle controllers that went with the consoles and computers of the era…

Any suggestions here would be welcome. I’m also interested in anyone who has the knowledge to be able to help me in supporting hooking these up to other RISC OS platforms.

What about using the existing Joystick SWIs? If you do that, then any existing games will work with the paddles.

You could bypass GPIO entirely and do the paddle as a USB HID device. My USBJoystick module would probably ‘just work’ with that – although I appreciate that isn’t in the spirit! ;)

I’d second the suggestion to not use GPIO.

By all means, make a mock-up to show it in action, but for the real thing it might be better to wire the paddles to one of those STM32 gizmos to present themselves as joysticks.

Benefits?

• Will work with the existing joystick module (and games that use it).
• Will work on any machine that has a USB port.
• Shouldn’t be too complicated to drop in a couple of buttons for extra controls.
• Won’t need a complex and possibly error prone installation (that might be further complicated by existing hardware such as IIC/SPI/Serial).
• Won’t be relying on possibly lengthy pieces of wire hooked directly to the GPIO pins (noise, EMI, etc) – there’s a reason why USB uses differential signalling rather than just wiggling a wire.

In case it’s useful, I found this. It’s MIT licenced, not GPL.
https://github.com/vostrenkov/EazyJoy

I’d second the suggestion to not use GPIO.

I’ve so far destroyed two pi’s by incorrectly plugging somethins into the GPIO. While it’s good for things permanently connected, the presence of a 5v supply alongside inputs limited to 3.3v is a risk when users are asked to connect and disconnect things.

Much the hardest part of writing a USB HID is working out what the descriptors should be.

You can bypass that by writing a specific driver for your device, but of course it will be specific to RISC OS.

working out what the descriptors should be.

That’s why I included the GitHub link. Hopefully the hard part has already been done, and it’s more a matter of adapting the hardware (and it’s code) to the specifics of the paddle controller.

Having thought this through further… In a complete re-write of what I had posted here… In response to Richard, Rick & Alan’s concerns about killing Pi’s due to goofing up when connecting devices directly to GPIO header pins, I am planning on creating a “hat” board to alleviate this problem… This should also have the added side effect that the GPIO pins used will already be fixed, thus making the module internals a whole lot simpler to implement…

This “hat” PCB will therefore currently provide 2 keyed 4×2 header pins, one for each of the paddles (allowing me to detect if they’re plugged in or not) and will expose the I2C interface to allow something like an RTC to be connected to the Pi at the same time as the paddles…

If there are any other interfaces people would like me to expose, then please let me know here…