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.