Build your own XIM1->PS3 adapter

Alright, here's the tutorial.

The first thing we'll go over is what you'll need. Of course, you'll need an original XIM. The XIM used one of two daughter cards, either the F330 or the F362. My XIM was made using an F330, but this should work with the F362 card, as well.

The second thing that you'll need is a Teensy 2.0 dev board. They're available directly from the manufacturer at PJRC.com or you can also buy one from adafruit.com. If you get it directly from PJRC, you can get it without pins and save a few dollars. I soldered pins onto the one that I bought because I'll most likely use it for other things as well. If you're interested in microcontrollers, the Teensy is a good platform to start with.

The third thing that you'll need is one of the USB cables that you charge your PS3 controllers with. You'll use this USB cable for connecting the adapter to the PS3 and also for programming the Teensy.

Lastly, you're going to need the Teensy loader software and the HEX file that we're going to program the Teensy with. The Teensy loader software can be downloaded from PJRC at this link -> Teensy Loader download. The HEX file can be downloaded from here -> USB HID Gamepad HEX file.

Now it's time for the fun stuff. The first thing you're going to need to do is figure out where to solder the wires to. The connections listed in the picture below are for the F330, so if you've got a F362 you may not be able to use this.

Once you've got all the solder connections done, connect the Teensy to your computer with the USB cable and run the Teensy loader app. In the file menu, click open HEX file and browser to the HEX file you downloaded earlier. Click the AUTO button in the menu and then press the button on the Teensy to load the HEX file onto it. In AUTO mode, the Teensy loader app will automatically program the chip and then reboot it. After being rebooted, it should show up in device manager as a HID gamepad.

The next step is to try it with the PS3. These are the steps that I have found to work best when getting the XIM/Teensy connected to the PS3. First, turn the PS3 on by pressing the power button on the face of the PS3. Next, connect the Teensy-side of the adapter to the PS3. The Teensy will power on at this point. Then you'll need to plug the other side of the XIM into the computer and run the XIM software. The number of updates should be showing somewhere around 125.

Right now there's no PS button emulation since generic HID devices "can't" have one. My initial goal with this project was to create something that could get around whatever restrictions that Sony has implemented, and I've done that without too much trouble. Now it's time to start working on the specific stuff. Also, there's always a possibility that I've managed to switch a few buttons when I'm translating the PSX into USB. If you find a problem, post in the comments and I'll get it fixed.

DIY XIM1->PS3 adapter tutorial info

In my last post I mentioned that I was evaluating two new pieces of hardware, one of which would hopefully work for the DIY XIM1->PS3 adapter. Well, I just finished a quick and dirty port of my code over to the new hardware, and it works great. The updates per second with the new hardware is running at 125 per second, and since there's other adapters out there that run that fast, I'm not going to try to slow it down any. It _might_ run a little faster once the code is cleaned up, but I won't know until I get that done.

Odds and ends...

Here's a few updates on several different facets of this proect:

1) I'm still working on the XBox360->PS3 adapter. My logic analyzer should be here tomorrow to help with getting the MCU talking to the USB host IC that I'm working with. I'm a little worried about latency at this point, but I have nothing to base those concerns on and won't be sure about anything until I get everything working.

2) I said a while ago that I had chosen the C8051F342 as the development platform for this project. Ever since then, I've been using an AVR development board. The code is semi-working on the F342, but I've yet to even really start porting the more critical portions of the code over. Both the F342 and the ATMega328 are more than capable for the intended purpose, but the final platform is all going to depend on latency.... which brings me to my next point.

3) I'm in the process of evaluating two new pieces of hardware. The first is an all-in-one IC that can host both the XBox 360 controller and be a slave to the PS3 all at the same time. This is the ideal platform, but it'll mean starting over on the whole project and learning a completely new architecture.

The second piece of hardware that I'm looking at will be for the original XIM users that want to have a firmware upgradable adapter that they can build themselves and who aren't interested in upgrading to XIM2 or XIM3 once I get the XBox360->PS3 adapter working to my liking. Bootloading the MCU to allow for easy firmware upgrades is something that I've given a lot of thought to, and I think that there's already great solutions out there. Once I get the new MCU and get the code ported to it, I'll make a post with all the details and a link to download the hex code needed to get everything running. The only thing that you'll need to program the hardware that I'm looking at will be a USB cable.

Unfortunately, there won't be a DIY solution for the XBox360->PS3 adapter since some custom PC boards will have to be printed up.

Another quick update

Last week I began playing around with trying to get a USB host IC to talk to the XBox 360 controller. Despite my best efforts at the time, the communication was problematic at best. Last night I decided to play around with it some more, and I'm fairly certain that I've figured out what the problem was. However, the data is being sent over a UART, and that'll never work for the finished product. The next step is to get the host IC sending and reading data via it's parallel FIFO buffer, which brings me to my next piece of news.

I just ordered a 34 channel logic analyzer. I'd been thinking that I needed one for a while, and it became even more apparent while I was working out the Playstation controller's protocol. Working with micro-controllers without some way to debug what's happening is like running through the forest with a blindfold on.... chances are you're going to hit a tree! While I'm waiting for the logic analyzer, I'm going to try to work it out on my own, but this could be tricky. Regardless, I'm hoping to have FIFO working and talking to the XBox controller by the end of the weekend, after that it'll be a trivial to get it talking to the PS3.

How far I've come, and what to do next...

For those of you following me or reading this blog, I just want to re-cap everything that's happened thus far and seek your opinion on where to take this next. What I've done is nothing especially out of the ordinary. There are others that have done similar things, and I've even linked to a site where a guy is selling adapters much like mine that used to, and may still, be able to connect to the PS3. Furthermore, the adapter that I've made is only running as a low speed USB device. That being said, it should work as well as we'd ever need it to regardless of it's speed...... in fact, that may be the one reason it never get's blocked by Sony. Despite that, this is where this project will hit a split in the road.

OBsIV and I have been emailing back and forth for a while now, and after talking to him it has become a mission of mine to make my adapter also work with XBox 360 controllers, and thus work with XIM3. I'm hoping to be able to pull this off so that PS3 users will be able to use the XIM3 via a quality X360->PS3 adapter that's fully upgradable and supported for cheaper than the other guys can. If this sounds like something that you would like to see, please leave some comments. If there's enough demand, I'll put a rush on this so as to be ready as quickly after XIM3 is released as it possible can be, otherwise it may drag out until January or February depending on exactly how complicated everything becomes.

Here's the video!

XIM working with PS3 and homebrew adapter from Nick Myers on Vimeo.

Well, the hard part of this particular project is done. There are still a few things that need to be ironed out, like easy firmware updates, but those should be relatively easy to get ironed out. I've also got a big decision to make. I'll make another post later today to discuss it, and I'll be looking for some feedback from you guys on which direction I should go.

I'm so close I can taste it!

All buttons and timings have been handled, and I got my PC to recognize the STK500. I want to do a little more testing before calling it done, but I'm close. I'm going to go eat some Mexican food and drink a few beers and let my brain cool off for a while. I'll get back to this a bit later tonight.

Oh yeah, 180 updates per second without any data corruption!!! THINK ABOUT THAT FOR A MINUTE!

**EDIT**

I've been staying up waiting for Vimeo to finish converting my newest video, but I'm going to sleep. Check back tomorrow (10/22/2010) at about 8:00 AM CST to see what I've got to show you!

What a difference a day (and a delay) makes!!!

I've got some really good news, and I've also got some kind-of bad news. We'll get the good news out of the way first.

The PS2 protocol has given me fits for the last few days but I finally got it figured out. What was happening was that the first two commands to the controller returned the expected data. However, the third byte read from the controller was coming in as 0xDA instead of 0x5A. At first I thought I had found a bug in OBsIV's code, and that this was the reason why some adapters recognized the XIM and other's didn't. Given the order of the comands that I'm issuing to the controller, the return value of 0x5A is kind of useless and can be ignored. However, after telling the adapter to ignore that data, it became quite obvious that my timing was off somewhere. I did a little more looking around, and found the answer. When changing the states of the lines to and from the PS2 controller, you're supposed to give the signals time to settle before moving on to the next command. A 1 micro second delay is plenty of time. As it turns out, I had delayed everywhere I needed to except for one place. That delay in made all the difference.

Now for the bad news. My wife has my computer that has AVR studio on it, and my P.O.S. Vista machine won't recognize my STK500. If I can get the chip burned, I'll be able to post a video later tonight. Otherwise, it'll be tomorrow before I can show everything working.

Stay tuned, kiddies! The best is yet to come!

Making steady progress

Earlier this week I decided it was time to get the XIM connected to the adapter that I've been working on. My initial attempt was a huge failure. I was trying to use a library that I thought would work, but it didn't. So, yesterday I wrote my own implementation of the Playstation 2 controller protocol, and everything is working a lot better now. I've still got a little bit of an issue with timing, though, since some of the data isn't being interpreted properly. My wife has class tonight, so I'm going to work on getting the kinks ironed out of that after work today.

And speaking of debugging embedded systems... what makes all this even more difficult is that I don't have a way to debug my code while it's running on the device. I guess a debugger is the next thing that I need to get. If anyone knows of a one that works with more than one MCU, please post in the comments.

**EDIT**

I can't believe that I forgot to let everyone know that I've shattered 60-ish updates per second that we've seen with other adapters. My setup has been running in excess of 150 updates per second, however I think that the speed has something to do with data corruption. I'm going to tone it down a bit and see what happens. Regardless, 100 updates per second should be do-able without any data loss!

Quick udpdate on today's progress

I was right about the Afterglow controller holding the info that I needed to get my adapter working properly. I was able to connect it to my PC to get the button order, and one hot minute later I was playing Lumines with a SNES controller and not fumbling for where the buttons were supposed to be. The hard part of all this is over. Tomorrow or the next day I'll implement the PS2 protocol over the working code and hopefully be able to show everyone a XIM working with my adapter on PS3 firmware 3.50.

And as if that isn't good enough, I've got a new project in mind that I think you'll all find quite intriguing. I'm not going to spill the beans just yet. but it's BIG.... REALLY REALLY BIG!

Even more good news!

So, I've been banging my head against the wall for the last 24 hours trying my hardest to get a proper report descriptor set up. Nothing that I had tried worked very well at all, but I think I now hold the key. My goal ever since I began this project was to create a specialized PS2->PS3 adapter that will allow the XIM to talk to the PS3; in theory it should work with PS2 controllers as well, but the analog button data won't be translated. They'll be either on or off. Given that the XIM is a keyboard and mouse adapter, the only part of the data that gets reported to the PS3 that _needs_ to report analog data is that for the analog sticks. The rest are just going to be reported as digital buttons. By going about it this way, the end result will be far simpler to code and hopefully it will be generic enough that Sony won't see fit to add devices this generic to it's blocked list.

So, I took a chance and went to Best Buy earlier today to see what they had. The ONLY 3rd party controller that they had available is the Afterglow AP.1 which is made by Pelican, and it's actually a really nice controller. What's even better than the design is it's report descriptor! This controller's report descriptor is EXACTLY what I was trying to implement, so this tells me that it can be done! In fact, I'm going to copy the report descriptor verbatim and see what happens.

On a side note, if I ever decide to go back and try to work up a PS3 version of XIM2, this controller would be ideal. First of all, it's wired so there shouldn't be any lag once the buttons on the controller are activated. Secondly, it's got some very easily accessible solder points. Thirdly, the main board of the controller is quite small with two, smaller daughter cards soldered to it. These daughter cards could be removed quite easily leaving a very small interface card that would fit into some really small project enclosures.

Here's a link to the controller at Best Buy's website. This controller won't be used for the final design, so there's no need to purchase one. I just bought it so I could see the USB information. However, if you like the layout of the XBOX controller, you might give this one a try.

And here's the video!

Right at the beginning of the video I show the two PS3 controllers that I have so that you can see that they aren't on. Then I show the SNES controller (a cheap knock-off), the Arduino board that I'm using as the development platform, and all the connections. The buttons are a little screwey, and you can tell at certain points in the video that I'm looking for a particular function but can't find the corresponding button. Anyway, those little problems are easily fixable.

POC -> USB adapter working with PS3 from Nick Myers on Vimeo.

I'd like to thank everyone who's been following my progress, and I encourage you to continue to do so. It won't be too much longer before this begins to get close to a finished product.

BOO-YAAAA!

I've been busy this morning, and I've got two GREAT pieces of news to report on.

The first piece of good news is that I figured out why my code was lagging so bad, and I'm almost too embarrassed to admit what the problem was.

When the AVR polls the SNES controller, it's suppsed to hold the clock line high for 12 micro-seconds before pulling it low again. It was really late the other night when I got all this working in the first place, and instead of delaying for 12 micro-seconds, I was delaying for 12 milli-seconds. Now you may be thinking, "milli, micro, what's the difference? They're both so small that we can't tell a difference." Well, here's a practical comparison between the difference. Let's say that when coded properly that it takes one day to fully poll the SNES controller for the button states. When coded improperly (the way I had it to begin with), it would take a little over three months!

And now for the second, and more important piece of news. Not only does the adapter that I've built work with all my computers, it also works with the PS3. The buttons are a little screwey since they're not being reported in the order that the PS3 wants to see them, but it does work. Furthermore, this has been accomplished with very little customization of the USB protocol. I'm not currently spoofing the PID/VID of any other working controller, and the report descriptor is just a basic dual-axis/eight-button report. This leads me to believe that accomplishing the ultimate goal of this project won't be as hard as I initially figured it would be.

But wait, it gets better! I'VE GOT VIDEO! I've just finished uploading the video to vimeo.com, and it will be a little bit before it will be available. Once it is, I'll make another post.

Finally some success!

My wife had to go to class this afternoon, so I got to spend some time working on getting the SNES controller to talk to the AVR. That was relatively simple. Then it was time to get it working with VUSB, and that took a while. And while it's working, it is terribly laggy. I'm fairly certain that it has to do with the way I have the update coded, but I'm not sure how else to do it. Regardless, now that I've done it on the AVR it should be trivial to get it working on the F340.

More good news!

I've got a bit of more good news in case anyone is even still interested in my work. After working through all the muck to get the F340 to enumerate as a gamepad, I've gone back and done the same thing with an Arduino Duemilanove using the VUSB library. Being able to work with the AVR will speed development along a lot. There are still a bunch of things that I don't fully understand in regards to the F340, but AVRs are my proverbial "old stomping grounds." The only downside that I can think of in regards to VUSB is that it only implements USB 1.1, however that _shouldn't_ be a problem given that there just isn't that much data to process. When you take a PS2 controller and break it down into raw data, there are only 16 bits of data for the buttons (excluding analog data) and 4 bytes of data that describe the position of the analog sticks. Even if the analog portion of the buttons has to be coded into the program, it will be easy enough to just assign full depression data to those values based on simple button states.

Given that I can now fall back into a development environment that I'm more familiar with, I'm hoping to know a lot more about what will and won't work with the PS3 sometime later this weekend. I would love to work on this kind of stuff every afternoon, but it doesn't pay the bills and my wife is getting a little annoyed with me. She really doesn't care if I was able to enumerate an Arduino as a USB gamepad LOL!

Finally! Some real progress!

I know that a bunch of you out there were probably beginning to think that this project was showing all the signs of being vaporware, but I'm here today to let you know that it is not! In my last post I let everyone know that I had finally decided on a development platform, and today my new Toolstick base adapter and F340 daughter card arrived. I'm admittedly a USB noob, but I've already managed some awesome progress.

For those who are interested, there are several great reference materials available from Silicon Labs regarding USB HID development using their F320- and F340-series daughter cards (f you're interested in seeing them, there will be some links at the bottom of this post). I've been over them with a fine-tooth comb several times a piece over the last few days, and I've finally gotten my head wrapped around how they implement their USB functionality. I have taken a ton of notes, and I was actually able to start with their USB HID template and compile a hex file for the F340, but alas it didn't work. I'm fairly certain that I missed some kind of initialization since the PC didn't even report that there was a malfunctioning USB device.

Over the course of my reading, I had come to realize that the only real difference between a mouse and a gamepad (in the world of USB-HID) is the report descriptor. Everything else is pretty much the same. So, instead of basing my code off the template, I decided to base my code on Silicon Lab's USB mouse example. After commenting out the unnecessary stuff, modifying the report descriptor, and setting the code up to send static input values to the host, I was able to successfully enumerate the F340 as a USB HID-compliant gamepad. Below is a picture of the device showing up in Device Manager on my wife's laptop running Windows 7.

Since I got rid of my PS2 controllers a long time ago, and since I don't want to mess up my XIM just yet, the first iteration of this project is going to work with a SNES controller. Now before you get all worked up about it not working with the XIM just yet, let's remember what the biggest part of the project is: creating an adapter that will work with the PS3, and you don't have to emulate a PS2 controller to be compatible with the PS3..... or at least you didn't have to before firmware 3.50. There's a project that you can check out called Retro Adapter that has done exactly what I'm looking at try trying and his adapter has worked with the PS3 in the past. However, I emailed the guy who created it and he can't tell me if it still works with the PS3 or not. If I can't find a way to make simple HID emulation work, I'll move on to trying to emulate the TAC PS2->PS3 adatper which shouldn't be that hard since I've now got a working USB HID project to hack on.

As a side note, when I ordered my base adapter last week, I didn't realize that they came in shiny little jewel cases now. AND, as if that wasn't cool enough, the F340 daughter card has little plastic adhesive feet stuck to it's underside so that it can sit on your desk or table without having the circuit board touching anything. The more I play with this Silicon Labs stuff, the more I like it.

 

Anyway, here's those links that I promised.

- This one is by far the best that I've come across. It's very device specific, but it was an invaluable tool for the work I accomplished today and I'm sure I'll be going back to it before long.

- This one is also good. This document is the reason I decided to go with the F340.

- This one is a neat solution for developers that want USB functionaltiy without all the fuss. It's a set of libraries that you use to create the device firmware and the pc software. It isn't HID, but it's still a neat concept. The compiler that comes with the dev tools only compiles code that's less that 4k which might be a problem if you're doing what I'm doing an implementing the USB stuff yourself. However, this solution comes with libraries from Silicon Labs that you can use to compile your source with SDCC, a free, non-codesize restricted compiler.

I ordered some new toys today

Since deciding to change direction with my project, I've been doing a lot of research on where to start. Not knowing much about USB, most of the focus has been on understanding all the descriptors that go into USB communication. I've finally gotten my mind kind-of wrapped around all the data, and I've started looking into which development platform would be the best place to start. I had planned on using VUSB (and I still might give it a try), but I've changed my mind.

After looking at all the options, I've finally settled on Silicon Labs and their C8051F342 MCU. If the name Silicon Labs sound familiar, it's because they're the same company that makes the hardware that OBsIV's original XIM uses. I had thought about using one of the PIC18F chips, but I couldn't find what I considered sufficient documentation. Then I thought about using Atmel's AT90USBKey, but they're hard to find since they're the primary platform for commercially available PS3 jailbreak clones. Then I remembered OBsIV's comments on how nice Silicon Labs' environment and tools are, so I decided to check out they're offerings. Their documentation is top-notch, and their MCUs are cheap. AND, if you aren't opposed to taking your XIM apart, you can use the base adapter you already have to program the MCU.

All my stuff should be here on Monday, so hopefully everything will progress a bit quicker after that.

I never thought I would say this....

I'm changing my primary development environment to Linux. There's just so much stuff that's much easier to do in Linux, and I'm tired of fighting with Visual Studio. This means that the initial releases of any projects will be Linux-based for the PC-side software. However, I'm going to do my best to make the code as portable as possible.

Also, I want to give everyone an update regarding the PS3 controller hacking that I've been working on. I've been discussing this a lot with Matlo, and I've come to the conclusion that the best first course of action will be to create a new PS2->PS3 adapter that will work with the newest versions of the PS3 firmware. In the long run, this will be a better first step for several reasons. First of all, there's a bunch of XIM users that have been left out in the cold and the driving force behind this project was to remedy that. With a working PS2->PS3 adapter, this would solve the problem of having to start from scratch. The XIM software would still be usable on the PC, which would mean that we can still use OBsIV's wonderful mouse translations.

The second reason that this will be a better first step is the cost. In order to get a micro-controller that's capable of sending all the necessary signals, you have to step up to something that's got quite a bit of horsepower. My initial goal was to use a ATMega 168 or 328, but there wasn't enough IO pins. This meant that the next best solution was the Arduino Mega which is $50 from sparkfun.com. Since there are still working adapters out there, $50 is just too much to spend to have to hack up a controller to get it working. I believe there's a good chance that either the ATMega 168 or 328 can be used to emulate a working adapter. If I'm right, not only will this cost far less than the other option, but it will also be far easier to build. Another plus to this option is that the firmware could easily be upgraded if the need ever arises.

So, where am I at in the development process? Not very far along, as it turns out. If it weren't for needing a few zener diodes, I could get started a lot quicker. However, I'm compiling a list of the components that I need and I'm going to get them ordered this afternoon. If all goes well, they should be here on Friday.

A quick update on a few things...

First of all, Visual Studio Express 2010 sucks! If you're thinking about upgrading, don't do it. I spent all day yesterday trying to get some code working, and if I had been using 2008 it would have been a lot easier. So, I'm downloading and installing it right now.

Secondly, I found out something neat in regards to Matlo's diy ps3 controller software. If you haven't found a dongle that is capable of having it's bdaddr changed, check this out. I was checking out a bluetooth dongle earlier that had a Broadcom chipset. When I ran the bdaddr command to change the address, the output said that the address was successfully changed and running bdaddr again showed that the change was successful. However, after unplugging the dongle and then plugging it back in, the bdaddr had reverted to the original address. Included in the bluez file that you download is a command called hciconfig that, among other things, has a reset command that you can use to reset any dongle that you have connected. After setting the bdaddr of the dongle to match the bdaddr of the controller, doing a soft reset with hciconfig doesn't cause the dongle's bdaddr to revert and you should be able to build and launch emu and emuclient from the diyps3controller source. If you aren't sure how to use hciconfig to reset a dongle, just use the command below. Of course, the dongle's address will revert the next time the computer is reset or if you remove the dongle from the USB port.

sudo hciconfig hci0 reset

One step forward.... two steps back....

Over the course of the weekend, I have come to the realization that the ATMega 328 isn't going to have enough IO pins to be able to control all the electrical signals needed to manipulate a PS3 controller. Because of this, I have put the PS3 controller hacking on the back burner for a little while. I'm going to have to get one of the newer Arduino XMega boards in order to get this project fully working.

In the mean time, I set about taking on a similar, yet smaller, project. I decided that it would be a good exercise to take the idea and adapt it to an NES controller. I started by finding the pinout for the shift registers used in old NES controllers and soldering wires to the board for each of the eight buttons on the controller. Then it was time to write the firmware for the ATMega328. When it boots, the ATMega waits for the computer to send a connect signal. In this case the connect signal is a C character. Upon receiving the connect signal, the Arduino responds with an R for ready, and then program control is transferred back to the main loop where any serial data that's read will be translated into button presses. I know that the whole connect step is kind of overkill when all the controller data can be sent in one byte, but this will be a lot more important when I start on the PS3 version.

The only thing keeping me from being able to finish this and post everything up is that I'm currently downloading the DirectX SDK, which is over half a gig in size. I decided to use direct input instead of SDL because there's a lot more versatility built into direct input than what I remember from messing around with SDL.

All this work isn't just for the hell of it, though. This test will give a good indication of how many updates per second we'll be able to get for the PS3 version once I get an Arduino that has enough IO pins. Also, doing all this work will help speed things along once I get started on the PC-side software for the PS3 version. In fact, most of the code that I've written thus far will port over without having to do much of anything.

The DirectX SDK will be done downloading sometime later tonight, and I should be able to get everything finished, documented, and posted up sometime tomorrow night.