New version is out

Version 2 is now out. Users reported that the L1 and L2 buttons were swapped, as well as R1 and R2 being swapped. I rechecked my notes, and everything looked right based on my references, but they must have had it wrong.

One user had also asked about a port for boards based on the AT90USB162 chip like the Minimus, so I compiled a version for that chip as well. I don't currently have a board with that chip, so I can't promise that this version will work. You'll also probably have to use Flip from Atmel to program the board. The Teensyloader application only works with Teensy boards.

Download for V2 -> Teensy
Download for V2 -> AT90USB162

Quick update

I know I haven't posted in a while, but I just wanted to let everyone know that I'm still working on this. I've found the info that I need to make the PS3 button work, but I need to port it from VUSB to LUFA so that it will work with the Teensy. I've asked another developer for some help so that I can get headed in the right direction, so hopefully I'll be able to get something working later this week.

Well...... that didn't work

I tried to do a general clean-up and rewrite of the code so that I can release it, and while the code compiled without problems, it just wouldn't work. I'll be working some more on this over the next couple of days, and hopefully I'll have a second version with a working PS3 home button out by the beginning of next week.

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.

Update on bluetooth dongle from Newegg.com

Despite being advertised as being 2.0+EDR, and despite receiving a response from IO Crest (the company that makes the dongle) saying that it uses a bluecore2-ext chipset, the dongle that I received from Newegg.com can't have it's bdaddr changed. If you're looking for a readily available dongle that's compatible with Matlo's solution, STEER CLEAR OF THIS ONE! The output from hciconfig shows the dongle that I received to have a BlueCore01a chip version.

Quick update for everyone

It may be another day or two before I have anything real to report. My wife and I are going to see Daniel Tosh tonight, and then I'm taking the day off work tomorrow to go to the Texas State Fair. Saturday is going to be a bit of a mess, but I should be able to squeeze in some hardware-hacking time Saturday night and some more on Sunday.

Keep checking back.

One more update before I go to sleep

So, I've been playing around with Matlo's bluetooth emulation software, and it's the real deal! Despite the necessity of needing a specific bluetooth chipset, I was able to get the software working and I even played a little COD. According to Matlo's blog, you need a bluetooth adapter that has a chipset made by CSR, TI, Zeevo, Ericsson, or ST. There's even several posts where it is specifically noted that Broadcom chipsets won't work. Well, that's not 100% true. While all the adapters that I tried that were Broadcom didn't work, I do have an HP MiniNote computer that has an on-board Broadcom bluetooth chipset. As it turns out, this chipset is compatible (I can get more info regarding this chipset if anyone would like to have it).

For those who are unaware, the HP MiniNote only has two USB ports and is completely devoid of a CD-ROM drive. This meant that one of my USB ports was taken up by a USB flash drive containing a flash-bootable version of Ubuntu 10.04. Since there was only one more USB port, I didn't even bother pulling out my gaming keyboard and mouse. All my tests were done using the trackpad and the on-board keyboard, but I can say without a doubt that I didn't notice any lag between the inputs and the actions on the screen.

Now back to more info regarding the original project that got me to start this blog. I took a bunch of XBox 360 stuff to Game Stop to do some trading since my XBox 360 decided to RROD. While there I picked up another PS3 controller, so the next step will be to tear it apart and figure out where to solder all the necessary wires to the board. If all goes well, I should have a VERY preliminary POC in the next week or so. However, at this point I think that my progress will be moot. Matlo's option, while a bit of a hassle for some users since it requires Linux, is VERY VERY good and it does, in fact, work with the newest PS3 firmware..... that's right kiddies, I upgraded to 3.50 and lost my jailbreak just to confirm that this will work for all of us lost XIM'ers. My time may be better spent tweaking on the mouse translations of Matlo's software and possibly doing some work to get a nice GUI laid over the top, especially since he's already working on making his solution cross platform. I may go ahead with my original project just to prove to myself that I can do it, but I'm not sure. Feel free to leave some comments letting me know which way you think my time would be better spent.

And as a side note for any of you guys out there that might try to do the same thing I did by using an on-board bluetooth chipset instead of a dongle, there's a really easy way to reset your bluetooth device without having to reboot the computer. After downloading the bluez bundle and building it, use hciconfig to reset the on-board bluetooth device. I would give you the exact syntax, but it's late, I've been drinking, and I can't remember it right off the top of my head. However, if you know your way around a Linux terminal you should be able to figure it out for yourself.

Everyone should take a look at this

Another blogger who goes by the name of Matlo posted in the comments of my last post that he had been working on a project that might be of interest to me. His project was to use a bluetooth dongle and a PC to emulate a six axis controller. The effectively eliminates the need for any kind of intermediary device. The only trick to it is that you can't just use any bluetooth dongle. I read over his blog, which is located at diy-machine.blogspot.com, and I decided to order a bluetooth dongle to see if I could make this work. Dongles that are compatible are listed on his blog, and after reading the list, I decided to purchase the Syba SY-ADA23012 adapter from Newegg.com. I'm not sure that it will work, but it does contain the necessary bluetooth chipset and support V2.0+EDR. I should have the adapter before Saturday, so I'll let everyone know if it works. If it does, this may be our next best bet since he's done all the leg work.

If you don't feel up to reading his blog, here's a quick run down of how it works. Right now Linux is the only supported OS, but everything will run from within a virtual machine or from a live cd. The first step after installing the necessary libraries is to grab the bluetooth address of one of your controllers while it's on and connected to the PS3. After doing that, you then use another set of tools to modify the bluetooth address of the dongle to match that of the PS3 controller. Then it's just a matter of starting two programs via the linux terminal and you're off to the races.

Right now there isn't any fancy GUI or even a button configurator... all that's done by directly modifying one of his source files. However, the entire project is open source and a fancy front-end could be whipped up for those that can't live without it.

Stay tuned... things just keep getting more and more interesting.

So, what kind of hardware do we need?

In order to determine what kind of hardware will be required, I'll have to draw on my memory of what OBsIV (the creator of the XIM and all it's iterations) said regarding the original XIM along with a few conclusions that I've drawn for myself. The original XIM was built using Silicon Labs Tookstick with the F330 daughter card. At the time that I built my XIM, I didn't know anything about embedded development but I've since come to realize that the Toolstick starter kit is a great way to begin learning about embedded development.

The Toolstick consists of two parts: the base adapter and the target MCU. The base adapter is the part that has the USB connector and it plugs directly into your PC. The base adapter provides a means of sending compiled hex files to the daughter card along with a channel that can be used to debug the chip while it runs, or that same channel can be used as a UART channel to transfer data between the PC and the target MCU. Data can, and often does, flow both directions via a UART channel. The target MCU contains the microprocessor (the 8051/8052 in the case of the XIM) and a break-out section where individual wires can the connected to the pins of the microcontroller.

In my searches this afternoon, I was unable to find the supported baud rates for the Toolstick's UART channel. I'm fairly certain that if I had dug far enough into the documentation I could have found it, but I lack the desire to study the device. There just aren't enough I/O pins on the F330 daughter card to handle the task of controlling all the electrical signals that would be needed to create a PS3-ified XIM2; for that task it's going to take something a bit beefier. Regardless of all that, I'm sure that OBsIV had the UART channel running just as fast it could possibly run in order to provide the best possible gaming experience.

So, what is the ideal starting point for this project? Well, I had an answer this morning, but now I'm intrigued by another option (more on that a few paragraphs down). Initially, I had thought that an AVR would do a great job, and I'm relatively sure that it still will. What's great about the AVR is the options that you have when it comes to writing code for it. There's always assembly, which is super fast and very easy to understand. Then there's C, which is also really fast, and the compiler is free unlike some of the compilers for the PIC family of microcontrollers. And lastly, there's the Arduino environment, which is a C++ extension for AVR C. While it only works for the specific chips that the Arduino boards have been created for, and it can add some fluff that can slow things down, assembly and C can easily be intermingled with the C++ code to help speeds things back up if the need arises. If you can't already tell, I'm a big Arduino fan.

Now before I get bashed for deciding on an Arduino as the platform to use for this project, let me offer up some info on why I chose it. First of all, Arduino is made for rapid prototyping. Writing code and getting it onto the chip and running is so easy that a cave man can do it.

Secondly, the Arduino board already has some things that you're going to need for this anyway. In order to have a UART channel, you either have to have a serial port on your computer (which are disappearing at a rapid pace) or you're going to have to use a USB->Serial converter. All modern Arduino boards include the necessary hardware for this out of the box. Plug in the Arduino board and Windows will find and install drivers for it. You'll have to do the driver installation yourself on a Mac, but big whoop.... at least Mac won't be getting left out in the cold. You a linux fan, well come on over by the fire and warm yourself, too. There's a PS3 gaming party in the works and all platforms are invited!

Lastly, in the event that the Arduino environment in all it's simplicity can't handle the throughput required for this project to run the way it should, there's nothing stopping me from porting the code to C or assembly. The board will still work even if the code was written in another environment. It might take a different kind of programmer to burn the hex file to the chip, but the ease of working with the Arduino board will still be there. You'll still have the USB->serial converter. You'll still have the compatible voltage levels. All OS environments can still be supported. It's a win-win-win situation.

Now before you all go out and buy an Arduino, let me say a few things. First of all, this project is still in it's infancy. It could be weeks before there's even a POC. Secondly, I've got to wait to get paid before I can buy a PS3 controller to cannibalize... those things aren't cheap. And last, but definitely not least, Arduino has released a new version of it's board that has some very intriguing features. The newest Arduinos no longer have a USB->serial converter on board. Instead, they use a native USB chipset that, and I'll quote Sparkfun.com on this, "...allows for the Arduino (with some code) to show up as a variety of USB devices (Keyboards, Mice, Joysticks, MIDI etc)..." Now I don't know if you can see the possibilities just from reading that statement, but allow me to expand on it for you. It is most likely possible that the new Arduino boards could be used to make a PS2->PS3 converter that can have custom, upgradeable, and modifiable USB descriptors should the need arise. Now I know very little about developing USB devices, but I'm quite intrigued by this. If it is possible to do what I think it is, this could make it so that there wouldn't be any controller cannibalizing. There would simply be a USB connection from the computer to the board, and then another running to your PS3. THINK ABOUT THAT FOR A MINUTE!

Regardless of the hardware, there's still the requirement of software. There's software (or as it's more commonly know as, firmware) that will be running on the microcontroller. There's software that will be needed on the PC that will translate the mouse and keyboard events and send them to the microcontroller. This is by no means an easy undertaking, and while I can do it by myself, I'm sure there are others out there that can do certain things better than I can. That being said, I'm planning on open-sourcing the PC-side software once I have it working to my liking. If someone thinks they can do a better job of handling the inputs, then I'm all for them doing it. When I get to that point, I'll provide a library that allows for sending data to the microcontroller and anyone who wants to write a front-end can do it. The firmware for the microcontroller shouldn't need any fine-tuning once I'm done with it, and as such won't be open source. All the calculations, like translating the mouse movements into joystick movements, will take place on the PC since there's far more processing power to play with there. The microcontroller will just need a "raw" data stream.

Alrighty, so hopefully the rest of the posts won't be this long. There's just a lot to talk about at this point in the game, and I'm trying to convey to everyone that I, at the very least, have an idea as to what I'm trying to do. There's a bunch of posers that would set up a web site and start asking for donations without the slightest idea where to begin... I'm not one of those people. Keep checking back, and I'll keep making posts as I have something new to say regarding the ongoing progress of creating a new way for us PS3 players to wage FPS war.

One more thing. I'm looking for some kind of name to give this project. Before anyone chimes in with some derivative of XIM, such as PSIM or PS3IM, don't even go there. I'm a member of the fourms at XIM360.com and I intend to keep my membership there in good standing. I don't want anyone there to think that I'm trying to capitalize on OBsIV's work.

PS3 jailbreak and the state of XIM for PS3 users

So, a lot has happened over the last few weeks with regards to the PS3. Hackers figured out a way to enable some debugging features using a very sophisticated USB attack. If you're interested in the particulars of how the hack works, there's a ton of info regarding it in the wiki over at PSFreedom.com. Sony reacted just as quickly as everyone thought they would and released a PS3 firmware update which closed the exploit. Shortly there after, they released another firmware update which secretly blacklisted most 3rd party USB peripherals. Included in these blacklisted peripherals were 3rd party controllers by companies like Mad Catz, FPS controllers like the FRAGnStein created by Bannco, and a whole host of adapters that allow gamers to use PlayStation 2 controllers on the PS3.

Something similar to this happened quite a while ago, and Sony quickly admitted that it was a complete accident. This time around they've been particularly quiet, only stating that unlicensed peripherals won't always work with the PS3. This has caused quite a problem for the people who use input devices like the XIM1 with the PlayStation 3. There are still a few adapters out there that work, but it will be a trial and error process to try to figure out which ones still work. Furthermore, any adapters that are found to be working aren't guaranteed to continue to work once Sony releases another firmware update for the PS3.

So, where does that leave us? Well, it leaves us between a rock and a hard place. We can continue to play this cat and mouse game, or we can come up with a better solution. In truth, a better solution has already been created. The creator of the XIM1 has taken his input device through two iterations and is currently working on a third, and each has been better than the last. The second XIM, more commonly knows and XIM2 or XIM360, uses a custom made FPC that solders directly to the motherboard of a wired XBox controller. This FPC is connected back to a computer via a USB cable, and it communicates with software running on the PC. This software takes raw mouse movement data, as well as mouse-button and keyboard data and sends it over the USB cable back to the microcontroller on the FPC. The microcontroller decodes the data, and electrically operates the controller. The design and functionality has been lauded by first-person shooter aficionados on the XBox 360, so why mess with success.

This brings me to my next point. The creator of the XIM1 and XIM360 has on several occasions said that he does not intend to support PS3 users, which is completely understandable. It was a complete accident that we were able to use the XIM1 on the PS3, and I think it was a bit of a slap in the face to the XIM scene that a device designed for the XBox 360 worked far better on an unintended platform than it did on the intended one. So, what are our options? Well, we'll just have to do it ourselves.

My first thought was to try to reverse engineer the firmware of the original XIM, and port it to another microcontroller that had enough outputs to electrically manipulate the PS3 controller. Basically this would just be tricking the PC software into thinking that another device was a XIM box. While this option sounds like a lot of fun since I would have to learn 8051 asm to accomplish this task, I have no intent to pursue it. I can't stand people who rip off the code of others, and I'll be damned if I'm going to do it myself. The second option is to create a completely new interface and write the PC-side software from scratch. This will be a fair amount of work, but in the end it will be the better option. It will give us far more control over fine-tuning every aspect of the performance.

I spent part of the weekend doing some bit-bashing and I believe that a project like this will be easy enough to accomplish. I'll make another post later today with some specifics regarding what kind of hardware will be necessary, along with some info on the software side of things.