PS button difficulties

Activating this PS buttons is more difficult than expected. I found different sources that claims to succesfully make this button work:

• http://www.slashdev.ca/2010/05/25/ps3-gamepad-with-home-button/
• http://code.google.com/p/diyps3controller/
• http://forums.obdev.at/viewtopic.php?f=8&t=5385

The first one is a nice project using a breakout board with an AVR to implement a USB controller for PS3 with home button enabled. The second one is another project with AVR chip, it's a controller simulator that gets its input from a serial port intead of directly checking button states. Both projects provides complete source code which is pretty nice. The third one is a thread discussion of people trying to make the button work, it gives some information of what seems required or not but gives no code whatsoever.

Everybody seems to agree the magic bytes are:

0x21, 0x26, 0x01, 0x07, 0x00, 0x00, 0x00, 0x00

Everybody agree these bytes should be sent to the host after the HID report descriptor. But it is not clear if these bytes should be sent in the data stage of the setup request, or in a spearate transfer just after. But from what people says in the thread, it seems it should be in the data stage. But it's just speculation as I can't find any confirmation in the projects source code. For the first project, the magic bytes are sent when the hosts does a HID class request GET_REPORT (not on a standard request GET_DESCRIPTOR that actually sends the HID report descriptor). And for the second project, the bytes are defined but does not used at all.

As the only project that seems to potentially work is the first one (it actually uses the magic bytes), I tried to use the same HID report descriptor and report data structure they have, added the piece of code sending the magic bytes on GET_REPORT. But no success. I don't event get the regular button events to be catched by the host. I highly doupt the report descriptor does not correspond the actual report data strucutre, in additoin this report descriptor contains some Sony specific stuff. If they are required to make it work on PS3 i'm pretty sure it will make it fail on Mac. The PS3 never send any GET_REPORT request. Not sure if this is due to the fact I use two endpoints (ep0 for control ep1 for Interrupt) whereas the project uses juste one endpoint (ep0). I don't think so as the original PS3 controller uses three endpoints. The number of endpoint should not alter the behavior.

It is pretty unclear what are the conditions the HID report must match to work with the magic bytes and make the PS3 happy. The thread lists some requirements point, but again it's just conversational and not strictly clear (is order important? etc...). It is not clear also if a specific vendor/product ID should be used. I guess no, because I doupt Sony does a firmware update anytime a new controller construcor pops-out.

I'm going to do some more investigation with different report variations. It saw the original PS3 controller defines some Feature fields in the reports, and there features sizes are 8 bytes just like the magic bytes. May be a hint?

USB Joystick update: It works with PS3!

It works with PS3! After all this time trying to understand what was wrong in the communication protocol (DATA bit setting etc...), I just figured out what was holding my USB Joystick project to work on PS3. And it doesn't really makes sense. Just as a reminder, I'm developing a USB Joystick to work with PS3 and PC (Mac in my case). The Joystick worked just fine on my Mac, but poorly on PS3 (see video here). Turns out the DATA bits were completely messed-up at this time (can't really tel how the Mac managed to make it work nice). I fixed all this and ended up with the joystick still working nicely on the Mac but nothing at all happening on the PS3. After some investigations I noticed the PS3 sends the following request to the device:

HID class request SET_PROTOCOL

This request is supposed to be sent to Boot devices only. But my device is not, I triple checked the descriptors and there is no subclass defined on device or interface. As stated by the USB HID standard this request is required for boot devices only, so I was invalidating the request with a good old Stall. Pretty normal, I was sticking to the specs. Then just to checking I enabled the call: just don't Stall the endpoint. And all of a sudden all just worked nice. The PS3 was accepting my data. I still can't tell whether or not it is normal for a non-boot device to have to implement this call. In fact, just after the SET_PROTOCOL, the PS3 sends a GET_PROTOCOL, I figure just to check if the setting went OK. I Stall on this GET_PROTOCOL call, but it does not seem to bother the console. In a nutshell, I'm pretty happy to have it working at last, but a bit puzzled by what I had to do for it.

Next steps:
Make Home button work. Shouldn't be too difficult there are some projects explaining how you have to send some magic data in the report to have it work.
Retrieve the controller number. I guess I'll need to use a OUT ep with some specific report to get the data from the console. Just hope the PS3 will consent to send me the info.

Supergun project

I know i didn't even managed to get my USB Joystick to work completely yet, but I have a Supergun project in mind. It's a long term project as it will be composed of different parts, each requiring different electornic skill that promise long hours, day and month of enjoyment.

For those who don't know what a Supergun is, it's a device that enable to play arcade PCBs on regular TV/monitor screen and regular controller instead of a dedicated arcade cabinet. It's basically composed of three parts:

•  Power supply. The arcade PCBs require 12v and 5v power and even -5 for some boards
• Controls input. The arcade PCBs provides pins to connect controllers, the super just exposes then to connect regular ones.
• Audio/Video output. Arcades PCBs output RGB signal at 15Hz,this video signal is transformed to VGA or PAL/NTSC to regular Monitor/TV set. the audio itself is mostly untouched.

There exist numberous Superguns on the market, most are home made, but none really fits my needs. And I'm quire surprised by this as some features seems pretty useful. So I intent to create my own with an awesome list of features:

• Integrated Power supply. I know it would be much easier to get a PC ATX power supply or any kind of existing external power unit, but I really look for something that can sit on a table without taking too much space, and won't require a lot of noisy cooling fans. Plus power supply is an awesome electronic project. I must admit I don't know how many Watt a JAMMA board can suck, but I think it will need much less than the 350 or 400W of an ATX PSU. In addition I'd really like to be able to monitor the power supply state (mostly consumption) and build some fine tuning mechanisms. Some arcade boards are pretty old and may require some specific tuning to work.
• Raw pins for control inpout AND USB. All superguns just exposes the JAMMA pins to connect a simple controller. It's pretty simple and highly efficient, but it lacks flexibility. Mostly the possibility to add 4 players easily, or plus your USB Joystick you already use on PC or console, or the possibility to use exotic devices some PCBs uses like trackball or driving wheel/pedals. The USB interface should enable to plug regular PC devices and emulate the JAMMA device for the board.
• USB service port. I especially want to be able to plug the Supergun to a PC. The features we can imagine with a Supergun as a USB device are numerous, but I mostly want to be able to record the audio/video, to update the firmware, and configure the settings (buttons layouts, power, etc...).
• Video upscaller. I intent to output a RGB VGA signal rather than TV PAL/SECAM. Mostly because it will require just a video upsaller to double the scan lines. Support PAL and/or SECAM just adds to the region problems with different TV sets. VGA is simple and nowadays even TVs have a VGA input. A nice to have is a scan-line generator integrated with scan line doubler. Just making the added lines darker to give a fine CRT feeling on LCD. Offering the possitility of video inversion can be fine as some PCBs output inverted video to projectors, but usually these boards has some configuration pins for video inversion, and this would surely complexify the video circuit and add latency. So not required, but nice to have.
• Open source hardware and software. I intent to publish everything, because let's face it, I'm not an electronic engineer or an awesome coder. So help from community is always a plus. I really intent to build the hardware with plenly of room for some cool software features I didn't tought yet.

A great project, a lot of ideas, but I really should finish this USB Joystick first.

USB Joystick

For some time now I try to develop an USB Joystick out of a broken one. The goal is to remove the faulty pcb board and replace it with a board of my own design. It's a much longer and harder process than I though, but it is quite rewarding and I learn a lot in the process. Here is a small video presentation of where is project is at.