Thursday, September 30, 2010
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.
Keep checking back.
Tuesday, September 28, 2010
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.
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.
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.
Monday, September 27, 2010
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.
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.
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.
Subscribe to:
Posts (Atom)