It’s no secret the PS3 will work with most USB HID gamepads or joysticks. However the Home button is something special. If you connect your sixaxis controller to your PC and monitor button presses, the Home button comes up as button number 13. If you then create a standard gamepad with the same button mapping, the PS3 will refuse to recognize the Home button.
After some tracing of the USB traffic from an official Madcatz Street Fighter IV FightStick I was able to come up with a solution! There are 8 bytes transfered during the enumeration phase, just after the device sends it’s report descriptor. Mimicking the same exchange results in the Home button functioning correctly when button 13 is pressed.
I used the amazingly awesome Teensy++ development board after being inspired by this guys work. I also used the report descriptor from Toodles UPCB project which appears to come from the SEGA VIRTUA STICK. This descriptor is very similar to the one from the Madcatz controller, except their is one endpoint instead of two which simplifies things somewhat.
I also created a shield (pictured above) which brings several pins on the Teensy to convenient screw terminals.
This document can be printed onto transparency for exposing your pre-sensitized copper clad. To use this for toner transfer, be sure to mirror the image first.
And a compiled version of the code in ihex. This is for the teensy++ 2.0. The code might work with other versions of the teensy, but a re-compile will be required.
I built this board several months ago. It’s a USB gamepad circuit with 6 buttons mapped to correlate with the standard layout of a Street Fighter IV FightStick for the PS3.
You’ll find the source code and Eagle files here, both licensed under the GPL.
PS: It’ll also work just fine on a Window/Linux/Mac OS X computer as well since all operating systems come with drivers for USB HID gamepads.
Came across this handy little hack today googlin around the internetz. On several occasions I’ve had the need to get the full device and report descriptors from an attached USB device. Today was another one of those occasions. If you run lsusb with the -v flag you will get a nice verbose output, but if you locate the section that contains the report descriptor you’ll be welcomed with a typical Linux friendly message: UNAVAILABLE .
I thought to myself, self: “certainly there must be some way to tame this beast?”. Wouldn’t you know it, there certainly is.
A year or so ago I wrote out some instructions detailing how to make SignatureTool.jar work in Unix type systems. Soon after I got word that somewhere around JDE 4.6 or DE 4.7, RIM actually fixed the mistake in the sigtool. Sadly they missed one.
If you attempt to sign a
.cod file larger than 64KB (ie: contains sibling
files or child files or whatever files) then you will likely get a file
created in your current working directory that looks something like
kd8m34jkf/my_lame_app-1.cod. When you load the file to the device it will
result in an error of some sort. The fix for this is relatively simple.
Read on for the details.
It’s 10:00pm EST, Jan. 28th and RIM’s signing servers have been down for the last sixty minutes. This wouldn’t be such an issue if the rest of the BlackBerry development tool suite wasn’t such a steaming pile of crap! Quite literally the only component that works - is the compiler.
The simulator doesn’t sim and the signing tool doesn’t sign. These two issues cause a serious problem.
First the simulator. If you take an OS 4.3.1 simulator and a device also running OS 4.3.1 the two will behave very differently in a few subtle, but important ways. My gripe is localized to the mmapi api (handles audio/video playback). Long story short, the simulator can’t be trusted so we have to debug device/OS idiosyncrasies on the device itself.
But hold on a second. The signing servers aren’t working so I can’t debug on the device in all it’s developer friendly glory with lack of usable debugger and lack of even something as simple as a means to read text written to freaking standard output!
Thank you RIM! Thank you for wasting my valuable time. Thank you for reminding me that no amount of money can justify writing software for this platform any longer.
(10:30, signing servers still not working)
The result I think is actually quite nice, and I love me some pretty code!
This is mainly a show and tell post. What we have here is a NES controller that has been converted into a USB HID device. This means it can be connected to a computer without installing any drivers (Linux, Mac OS X, and Windows XP).
The circuit, PCB design, and firmware for the Atmega8 micro-controller are courtesy of Raphaël Assénat. His website is a veritable cornucopia of awesome circuitry. And the best part? All of his work is fully documented and provided for use under the GPL license where applicable.
Now the show part is over, time for the tell.
In a previous post I listed 4 key items needed for BlackBerry development:
At the time of writing the first two worked fine. The third, Simulator, is if’y at best. And the fourth was just not possible.
Until now. In late December, a saviour by the name of Nicolas Vivien dropped by the barry mailing list to let everyone know that he was hard at work on reverse engineering the Javaloader USB protocol. Within a few weeks he had developed a proof of concept that enabled users to load cod files to the BlackBerry.
Since then several developers (including myself) have chipped in to implement all of the crucial aspects of the Javaloader needed for day-to-day use.
Just a quick update on the Arduino LCD Library (bring it to version 0.3). I have worked many hours to iron out all the bugs in the code that checks the LCD modules busy flag. This is the part of the LCD modules controller that tells the arduino it’s in the middle of an internal operation.
Hopefully this fixes the sporadic behavior people have reported with their LCD’s. It certainly fixes the problem with the two LCD’s I have tested.
I also added a schematic to the package. It just outlines where to connect VCC, GND and where to put the 10K pot.
A short time ago Handbrake began to ship with default encoding settings for the “Normal” profile using 2-pass h264 encoding. Sadly my XBox and XBMC just weren’t up to the task of decoding all those fancy h264 bits in software anymore.
Naturally instead of adjusting the encoding parameters, I decided to begin the hunt for a new video player… oh and it has to be cheaper than that AppleTV thing since it does h264. It also has to be similarly quiet, power efficient, and small.
Well this is the result. It’s a bit bigger than an AppleTV but it’s certainly quiet and power efficient. And I actually quite like the look of it.