This is sounding very promising now.
Shipping should be pretty cheap as PCBs are quite light. At a guess I’d say maybe $10 by airmail.
Interesting, do you have a link for that?
I think cracking it is unrealistic, but the pass-through method is tried and tested. As LuckyDay points out though, MS could kill it with a firmware update. It makes me wonder why they have not so far.
I have not done any tests on the pass-though for lag, but in theory it should be as low a normal pad. My guess is that the reason the adapters are so slow is that they have to poll the PS2/mouse/keyboard and interpret the results which adds a delay.
bencao74: Not quite. What I did was use a switch to make the USB lines be connected to a 360 controller when first plugged in. The 360 controller does all the security stuff and starts responding to update requests from the console. After a short time I switch the USB lines over to my controller, which starts responding to update requests with it’s own data. The console is none the wiser because it only checks the security stuff once when the pad is plugged in, or at least that’s the theory.
In actual fact all I have managed to do is swap one USB device for another so far, as I don’t have a 360 console yet. Next step is to use a 360 controller with Windows and see if I can do the switch with that. I have no idea if Windows checks the security though.
Of course this is all assuming that the security stuff is only checked once. If it’s more than that, it’s going to be very tricky to do. The only thing I can think of would be to have my controller watch the USB bus and switch itself in only when sending back status reports, then switch back to the pad for everything else.
I have contacted a few companies in China re sourcing the controller chips, but so far I have not had any luck. I still think the best option would be de-solder controller chips, but it’s an expensive way to do it since it means destroying an official pad and some slightly tricky soldering which will inevitably result in a few duds. It would be 100% reliable though, completely indistinguishable from a normal pad and with zero lag.
I will get hold of one and try it.
[quote]
perhaps this helps
Sorry, it’s no use, the PC-FX is completely different to the PC-Engine. I have PC-E pads working fine (both 3 and 6 button), but PC-FX pads use a different protocol.
Yeah… It depends on the implementation, but I think that would be a good way of doing it. The advantage would be compatibility with any joystick, simply by attaching the correct wires.
You are right, the newer ones do support locking. I see people on eBay advertising to crack it though, so I guess it’s not that good, but oh well. As you say, it would be easy to disassemble because all the important stuff has to be written in assembler anyway.
Screw it, I’m not King Canute. Open source it is.
Very cool! Good luck.
I’m assuming you’ll also support Toodles’ features:
-button mapping, including buttons (e.g. L1, L2) that may not be default on a 6-button stick.
-turbo fire
-tournament mode (disable start)
-playback recorded inputs (for training mode). This has been on my UPCB wishlist since day 1.
BTW, an LCD screen would help a lot in manipulating these options 
Out of curiosity, could MadCatz sell some kind of bare bones “controller” consisting only of the security chip, or is that out of the question?
This won’t happen. Microsoft wouldn’t authorize it and there wouldn’t be any commercial reason for them to do so. How many would they sell? 1000 optimistically?
According to this review it looks like the 360 only checks the pad once. Or am I reading it wrong?! Kyle would know
Of course connecting the xbox360 controller to a PC and investigate the payload plus header infos is a step forward. But you’ll need a real xbox360 for testing the security issue. Is there no guy from UK who can borrow a xbox360 
Nice idea!
Honestly it sounds to easy… but however. Never tried to snoop usb raw data, but do you know this tools:
Heard that sniffing usb is possible with wireshark, too. But only with linux…
- Button mapping - yes
- Autofire / Turbo fire - yes
- Tournament mode - yes
- Playback of recorded inputs - yes *
- I will do the recording module as a separate unit. It will have playback capability.
No, but it wouldn’t stop someone harvesting security chips. Datel did that with the PS2 Action Replay / Gameshark. If you look at the disc, the centre part containing the protection stuff has been cut out of a licensed game and glued into the Datel disc.
I still think that would be the way to go, but I’m no expert when it comes to SMD reworking. Anyone here any good at that?
I have a infinite supply of broken PCBs to practice on, but I don’t have a rework station (hot air gun). The cheap ones break really easily so I’m looking at other options. Some people have had success using ordinary household electric irons but I don’t think the controller PCB is flat enough to make it viable.
No, that appears to be correct. Very encouraging.
Maybe, maybe not, depends if the Windows driver does any security stuff I guess. I’ll just have to buy a 360 once I get to that stage.
Unfortunately sniffing the security payload won’t help. It’s almost certainly some kind of cryptographic handshake, otherwise it would be easy to clone. In other words, the data changes every time, a replay attack won’t work.
im so excited that a european and proudly can state british guy is aiming to construct something for the community, and also i will save a bundle on shipping as i am in the UK 
.
hows the progress with your retro boards also?
no, you can’t do anything with the security payload, but there should be a message, that cryptograhpic is now done and ok. I thought this message could be helpful to start then your own xbox360 protocol implementation afterwards.
This sounds odd. The first concern is that the 360 pad is (I’m guessing) USB full speed (12mbps), while AVRs can only do low speed (1.5mbps). The electrical signalling for the two is different - I would expect the host to force a reconnect if you changed between the two, as communication would not work until it switched the signalling. Then there’s the other USB stuff, like being in setup/addressed mode, one device is not going to receive an address and won’t be receiving packets.
I’m getting there. The firmware is almost finished and I have finalised PCB designs ready to go too. The main issue is getting extension cables. They are dirt cheap in the US but really expensive here. I’m considering asking a friend in the US if I can get them sent to him and then posted via surface mail to me to make it more economical.
I see. Well, as far as I can tell, it does not seem to be necessary, you can just wait 1 second and then check for any activity on the bus to make sure the connection is active, then switch over.
You are right about the speed difference. I would have to use an AVR with built in USB, as they support full speed. The addressing issue isn’t such a big one, as you can just pick up the address from the first packet you receive and assume that it’s the one you want. Since there is only one device on the local bus, it works okay.
As I say, it’s not a method I’m keen on. De-soldering is the way to go.
A little update…
I have finished prototyping the input recording hardware, and am now working on the software. It uses an SD card for data storage, and simultaneously outputs over RS232 for realtime monitoring. I thought about using USB but there are too many overheads for something which needs to be able to record data at high speed with high accuracy.
The realtime monitoring part will need some software developing on the computer side. It’s not something I’m big on but I’ll see if I can come up with something. The data format will be open so hopefully others will provide their own tools.
I have been thinking of ways to control the monitoring. Ideally there would be one button combo for “start/stop recording” which would also start a new file on the SD card. I suppose it could even be programmable, so for example you could have “up+start” to do it. A bi-colour LED will show green when ready and red when recording.
this just sounds better with every post, i cant wait to see a prototype in action.
mojochan, were you able to read the DC controller with a 12mhz, or did you use a co-processor.
If the avr is running at 12 mhz and it can do 1 mips per clock . and I think I read you say " that is 6 instructions per bit" makes sense since the maple is at 2 bits / second. Do you reading two bits at once? Or are you using an interrupt?
any updates mojo?
I hope to God that you will be able to build in 360 support. Back to the good old days of one PCB per stick… maybe.
Okay, a little update. I managed to remove the controller chip from an XBOX 360 pad kindly donated by speedsterharry. I have soldered it on to my own PCB and am in the process of tracing all the necessary connections to make it work.
I have the USB data and power lines set up, I just need to figure out how to generate a suitable 12MHz clock. It appears that the chip uses a series mode resonator with a single clock input. I have the crystal from the pad itself which I am going to try to recycle, but if that doesn’t work I’ll just generate it with another IC.
In theory, that should be all that is required to get it going. I hope to have results soon, but it just seems like there are not enough hours in the day at the moment!
I did start with 12MHz and got quite far on my own, but got stuck so left it for a while. I have now moved to a 15MHz clock (original 12MHz was required for USB, but thanks to V-USB I can use 15MHz now). The one thing which greatly helped was a logic analyser, which has allowed me to check my code’s timing much more easily and now fully decode and reproduce the protocol.
I use an interrupt which is triggered on the start of the Dreamcast’s bus poll. The first 8 bits are just a preamble to the main data so I can use that time to do some set-up stuff and verify that it really is the special start byte.
After that it’s simply a case of sampling bits on clock edges and packing them all back together into bytes. At 15MHz it’s not too hard to do in assembler. That AVR’s clock is accurate enough to stay locked on, but I do occasional re-syncs to bus clock edges anyway. Ideally I’d do them for every bit, but you have to account for the bits suddenly not coming any more which means implementing a time-out, and it’s cutting it a bit fine to do that. There are some other options I’m looking at, such as using one of the timer interrupts or just a few conditional branches in a row.
BTW, in order to respond quickly enough all the data for the response is pre-calculated by the main joystick polling routine, so there is no need for any processing by the interrupt.
Things would be even easier at 20MHz, but for maximum USB compatibility 15MHz is in theory best. In my limited tests 20MHz works with all systems I have tried (including PS3), but if I can do everything I need to at 15MHz then there is no point adding another potential issue, especially one which may not be fixable by a firmware upgrade.
thx for the info mojochan, I was hoping to use the SPCR ( like the ps2 project on v-usbs page ) with a 12mhz. I also use the v-usb project but hate to re time my other code, used to read other devices, to use the 15mh.
in your experience would you say the 12 mhz is not going to do the job period, understanding the job certainly would be easier with a 15.
12MHz is pushing it a bit. You can do it, but the problem is there is little room for flexibility. If you have code space to burn and can prepare all your data in advance then it’s possible.
I just bit-bang the port, I don’t use any SPI stuff. It’s not immediately obvious how you would use it. The Dreamcast uses a two line async serial bus. The two serial data lines alternate between clock and data every bit.
So I’m curious.
Is your final goal to have something that can be built without having to provide a security chip from an existing 360 controller?
Or is this something that you’ll just be able to create if someone provides a pad to sacrifice?