USB controller support through the Retrode?

So I just got a brand new Retrode 2 and it works wonders for loading the ROMs stored inside the original cartridges, but as far as I know there's no emulator (or official game, for that matter) that supports reading controller input from the Wii's USB ports and, by extension, from the Retrode.

I've noticed that the controllers do receive some signal when connected to it, as the buttons in the Arcade Power Stick light up when pressing them and when activating the "Megafire", but the controller of course can't be selected from the emulators.


Question is, would it be technically possible to read the controller input either from those ports the Retrode has, or at least directly from the USB port? It would be beyond amazing being able to play from the real cartridges using real controllers.

Thanks for reading.



Edited 5 time(s). Last edit at 02/10/2012 06:39PM by ICEknigh7.

Have you tried the Keyboard Mode ([HIDMode] 3 in the config file) that comes with the latest firmware 0.17d? It causes the Retrode to declare the controller ports as USB keyboards. See retrode.org for details.

None of these emulators have USB keyboard support.

Just did some research - it seems that there exists no USB keyboard nor HID gamepad driver for the Wii yet. I guess then there is not much that can be done from the Retrode's side.

There is most definitely a USB keyboard driver included in libogc.
There are also standard USB functions which can be used to talk to devices if you know the details of the protocol they expect. Libogc's mouse and keyboard drivers are good examples.

I guess a provisional solution could be adding USB keyboard support, and doing what Matthias_H initially suggested. =\

Okay, so driver support for keyboard is already existent? Even better, then it should be not too hard to add (or rather, restore?) keyboard input functionality in the respective emulator ports.

As long as the Retrode supports the boot protocol (required to be implemented by keyboards as per the HID spec).

Just double-checked - boot protocol should be supported.

Now I just hope somebody could point eke-eke and Tantric to this topic... They're usually cool about adding useful features, so I hope they consider this. :)

I've followed that topic but since i don't have an usb keyboard or a retrode, i could need some beta testing and more details on how keyboard buttons are mapped to genesis controller buttons, if there is something special required to handle two usb devices on the same port or if it's transparent from software view, etc...

My feeling is that writing a driver for USB controller class would be a better solution at the end since it would cover a larger audience and range of retro adapters. You could also use an adapter for genesis pad wiimote expansion port like i do (link to build your own or buy from developer on googlecode main page), it's even more practical than any wired solution.

About the retrode, i was curious to know how backup memory was handled: where are srm files saved ? Are they automatically written back to cartridge when writing that file ? Does it need to be 8-bit data only (a few games use 16-bit SRAM so emulator generally write 16-bit by default, LSB or MSB being left with unused data) ? Is there a way to detect a retrode is connected vs a normal usb hdd ? This could be useful to adapt srm file load/save location or even directly boot the inserted cartridge on startup, for the most authentic experience :-)

Oh right, the keyboard driver would need heavy modification to handle more than one instance/device. It wouldn't be difficult though.

As for writing a generic USB HID driver, have you seen the HID spec? Parsing the HID descriptor is a nightmare by itself and then you need to write an interface that lets the app know which features each controller has i.e. how many inputs, what they represent (buttons, axes, feedback etc.), how quick their response time is... it's a lot easier to add support for a specific device and call it a day.

I'd just like to point out this:

On the "Compatibility" page of the Retrode website, under "Operating Systems" is the following:

Quote

Wii(!!!) - details to follow. Thanks to [FelixV] for testing

[www.retrode.org]

Not sure how long that has been there or whatever, but maybe there is some sort of official support coming from the Retrode team?

EDIT: Maybe I misunderstood and this is just for loading games from cartridges, rather than controller support?



Edited 1 time(s). Last edit at 02/13/2012 03:53PM by SifJar.

@SifJar, The compatibility list is 2 years old. Back then, the Retrode only had the cartridge slots, and the controller ports were a user retrofit. So yes, that testing result is for the ROM part only.

@tueidj, Surely someone has parsed a HID descriptor before. A standard Linux distro may be a good point to look for code to start with. I don't think one would have to reinvent the wheel here.

@ekeeke, you mean when one writes to the SRAM file on the Retrode? By default, nothing would happen and the changes would be lost after a device reset (or immediately, depending on the level of R/W caching that your OS provides). Only when the config option [sramReadOnly] is set to 0, the SRAM is actually written back to the cart. (The way I have it, I usually copy the srm file over to my emulator's search path for SRAM).
Since we're talking about a Unix-type OS, it is also crucial to note that the Retrode with its very limited resources (600bytes of available RAM) cannot keep track of automatic backup copies and such. For both the SRAM and the config, the changes need to be written to the original FAT cluster of the respective files. For instance, under OS X, I found that

cp /Volumes/RETRODE/RETRODE.CFG /tmp
echo "[HIDMode] 3" >> /tmp/RETRODE.cfg
cp /tmp/RETRODE.cfg /Volumes/RETRODE

sometimes doesn't work, while

echo "[HIDMode] 3" >> /Volumes/RETRODE/RETRODE.CFG

always works. For SRAM, you may see a different behaviour between

fopen(name, "r+"); // write to existing file

and

fopen(name, "w"); // make new file

but I haven't had the chance to give that any deeper testing.

By the way, I am considering an open source transition for the Retrode firmware, and looking for folks who would like to join the core dev team. Anyone interested, please feel free to drop me a line.

Quote
Matthias_H
you mean when one writes to the SRAM file on the Retrode? By default, nothing would happen and the changes would be lost after a device reset (or immediately, depending on the level of R/W caching that your OS provides). Only when the config option [sramReadOnly] is set to 0, the SRAM is actually written back to the cart. (The way I have it, I usually copy the srm file over to my emulator's search path for SRAM).

So basically, if retrode config file is properly pre-configured, SRAM file is not write-protected when Retrode is powered ON and writing to the exiting file at the root of the device would write it back to the cartridge. I was thinking in a way to support Retrode more automatically, without having to copy srm file to SD /saves/ directory manually and was unsure if working on the srm file directly on its source location could work. I guess this would indeed requires some testing if you say fopen argument can matter.

What about Genesis srm file format ? Is it always 16-bit or does it depends on ROM header information ?

Quote
tueidj
As for writing a generic USB HID driver, have you seen the HID spec? Parsing the HID descriptor is a nightmare by itself and then you need to write an interface that lets the app know which features each controller has i.e. how many inputs, what they represent (buttons, axes, feedback etc.), how quick their response time is... it's a lot easier to add support for a specific device and call it a day.

I guessed it was not an easy task or it would have been done already :-)
I was thinking about something similar to what we have on Windows where anything you connect is immediately detected as generic controller by emulator which can then remap keys to whatever is pressed, though I admit I have pretty much zero idea how this is working at lower level. This gave me some interest in at least reading more about USB HID protocols though.

I always thought SRAM was 8 bit only because (1) most carts only use either the upper or the lower byte for SRAM, and (2) it seemed to work alright with Fusion (until I found out it didn't really). I'm now using 16-bit exclusively, and I have yet to find a failure case.

As for the search path for SRM files, I have yet to run into an emulator with an option to load SRAM from the path of the current ROM file. The best solution for all usage scenarios would probably be for SRAM reading to look in the ROM location by default, then fall back on some dedicated SRAM directory. And for writing, always to both locations.

Needless to say, I can help testing the official 3 and 6 button pads and Arcade Sticks if this goes through.