PS2 Multitap Protocol

[FoxFireX]

Back again with another question for the masses.  I've progressed a bit since my last time around, and am to the point of playing with microcontrollers.  Just finished wiring up and testing a PSX -> DB25 converter which will eventually allow me to convert that for use on other systems, probably XBox360 to start with.  But that's really not the point right now.  I'm looking at making a converter to go the other way, from wired 360 controllers to PS2.  I'm not too worried about interpreting the 360 USB data, nor would just going to a straight up PS2 be too difficult.  However, what I'm considering (just considering) is making this thing actually convert TWO controllers.  To do that and have only one PS plug, I'd need to actually implement the same protocol as a PS2 Multitap rather than just one controller.  I've found plenty of resources (including here) that talk about the controller protocol.  Anyone have references for the Multitap?

If all else fails, I've got the equipment now to just hook it up and see what it actually does, but I'd rather avoid the excess research if I can mooch off someone else's knowledge.

[Blizzrad]

Reverse engineering and emulating the multitap seems like a lot of unnecessary work if you only plan to connect two controllers to the system. Wouldn't it be much simpler and have better compatibility if the second built-in controller port were used instead?

[FoxFireX]

What, me do unnecessary work? Never!

Actually, the intent is to come out of this with three controllers connected.  I guess a short explanation is maybe in order.  Before Rock Band, there was GuitarFreaks/DrumMania, a Japanese series on the PS/PS2 by Konami.  It actually allows for three simultaneous players, two guitar and one drum.  I've got a drum converter already finished that takes my low-end home-brew ekit and gives me a PSX controller from it.  However, to hook up both guitars, I've gotta use a Multitap.  Now, my figuring is that I'm already going to have to emulate something (unless I just decided to solder onto an existing PSX pad, but those are getting harder to find) so I may as well go all out and emulate the Multitap itself.  I've already done the reverse side, reading in a single PSX controller, so I figure hopefully I can pull it off in reverse.  May yet change my mind, but I do have my reasons, mad as they may be.

[Blizzrad]

Ok, that all makes sense now. I guess you will either have to emulate the whole thing as you said, or make separate guitar controllers and plug them into a real multitap if that doesn't work out. Does the original hardware for this game rely on the multitap to connect all of the devices simultaneously?

I am very happy to hear about your project because it is similar to something I am also working on at the moment (warning, long tangent). I usually emulate old NES games with a modified xbox and keep my NES stored away for special occasions, but I always miss using the old NES Advantage controller when I play through an emulator. I use a commercial Psx to xbox controller adapter which provides a substantial improvement (xbox controller is pretty awful when it comes to digital controls) but it still does not compare to the arcade style Advantage controller. I also recently wrote some code to read data from playstation controllers using AVR microcontrollers and figured it would be a fun challenge to try and build an adapter so that I could emulate a Psx controller, and connect my NES advantage in it's place (though this is turning out to be more difficult than I expected). So far, the adapter emulates a digital Psx controller using the AVRs SPI pins, and then bitbangs communication with a Psx controller, NES controller, or both on separate general I/O pins. With this, I am able to play Ps1 games and Ps2 games that don't require analog controls, but it won't work with the Psx to xbox adapter yet because it requires the controller to be configured in analog mode, (which is what I am working on now).

What microcontrollers and language are you working with? I'm not sure if we are allowed to post code or discuss programming in this forum, but if not maybe we could exchange ideas/code some other way as our objectives are very similar (and I could use all the help I can get ).

[FoxFireX]

No idea about what topics are or aren't allowed; I can send my source at some point if you're interested.  I've been working with the PIC line (I think a 16F913 is the specific one, but that's just from memory).  The thing that was really nice about using that one for the PSX side is that it has hardware SPI (Serial Peripheral Interface) support, which is what the PSX communication is based on.  The bit ordering is wrong, but I can handle that after the fact.  I've been pondering working on some improvements to the code because right now it's in C, and when I look at the disassembly it seems like it's doing a LOT of unnecessary work.  I'd prefer not to code raw assembly, but I may want to tweak some of the routines for efficiency.

I'm more worried about doing the emulation on the controller side, honestly.  I'm not sure how quickly the PS2 will send the various commands down, and I'm gonna have to have everything ready the moment it asks for it, which feels a little scary.  I may end up chickening out and just soldering onto PSX digipads since I know how to do that.   I could live with it, although it'd mean four boxes strung around (USB->DB25 parallel, DB25->PSX (Guitar) x2, stock Multitap).  Two boxes would be ever so much cooler, but ever so much harder.

Still gotta figure out the USB stuff, but I'm getting there.  Should really finish up my current project before starting this one, though.   (Oh, and to answer the actual question, the manual calls out drums on P1, both guitars through Multitap on P2.)

[Blizzrad]

I believe the Ps2 uses a 500kHz serial clock and polls a controller about 60 times per second. Since packets are only exchanged for a brief period every 16ms or so, this leaves a lot of free time to collect data from other controllers and set up the data to be returned next time the Ps2 polls the adapter. The crazy part is like you said, trying to keep up with all the different sub-packet commands and responses during the packet transmission. Since the the command sent from the Ps2 in the second byte determines what the controller is supposed to send following the third data byte, you have to process some stuff between the transmission of each command/data byte.

So far my adapter has been keeping up with it, but the code is still very crude at this point. It basically just answers with "I am a digital controller, and here are my two bytes of data," while ignoring any commands to enter config mode or activate the analog controls. As long as the game doesn't require analog controls to be active, the Ps2 will continue to poll it as a digital controller. Getting the adapter to respond to the different commands and switch between various modes is what I am working on now. It shouldn't be too difficult to get the adapter to enter and emulate the basic analog mode which would allow compatibility with most games (and should work with my xbox adapter).

I have been using the ATmega168 AVR microcontroller for my adapter and writing all of the code in C. This microcontroller also has hardware SPI support and can be configured for either MSB or LSB first communication which is convenient. I have it clocked at 8mHz which I think will be plenty fast, but I could take it as high as 20mHz if needed. The reason I am bit-banging the communication with the controllers is because the hardware SPI bus is occupied by the Ps2<->adapter communication, for which the Ps2 is always the master. The main Ps2<->adapter packet code will be tricky, but everything outside of it can be really sloppy as there is lots of time to kill between packet transmissions. Hopefully I will make some progress on it this weekend, though it is difficult to debug this stuff without a logic analyzer.

[FoxFireX]

Well, I just grabbed a spare Multitap, so I'll get to see what it does.  Also going to build a PS2 cable breakout box so it'll be easy to spy on the actual bytes going back and forth between the console and the controller(s).  By the way, you mentioned a logic analyzer.  I decided I probably need one and found this one for not TOO much: USBee SX  Doesn't do any analog processing, but I don't need analog.  Very helpful when I was troubleshooting my first micro project.

Edited to add: Just finished the breakout box.  Wasn't actually too hard; just grabbed an extension cable, sliced open the middle, and got lucky because the wires were color coded.  Grabbed a small project box, mounted a pair of 4 port speaker terminals on the top, barrier strip in the bottom, wire it all up, and boom.  Haven't tested grabbing the communication yet, but all my continuity tests passed and we can still use the cable as an extender, so I'm going to call it success.  Next time I'm bored I'll hook up the Multitap through the cable, toss a couple of controllers on it, and see what I can see.  This stuff is way too fun to play with.

[Blizzrad]

Thanks a lot for the link, I have been thinking about buying a USB logic analyzer for a while, and am primarily considering the Saleae Logic for it's upcoming Linux support.

After spending a few more hours working on the controller emulation code today, I have determined that trying to code and debug it all blind is far too time consuming. Being able to hook up some test probes and see what is actually going on instead of guessing will make everything much simpler and faster, particularly with the  SPI protocol decoding feature.

A real cheap and easy way to make a breakout adapter is to cut up a controller extension cable, strip the wires, and solder them to pin headers that can be easily inserted into a breadboard (image link).

*edit* Just saw your edit after posting, sounds like a great testing rig, even better than using a breadboard.  Good luck with the multitap.

[FoxFireX]

Yeah, this ended up being pretty cheap (maybe $20 total?) but the nice thing is that it's a passthrough.  The cable still works and still lets you actually play controller to PS2.  But with the breakout, I can snoop the lines live, and should be able to hook it up to that analyzer and see exactly what the communication back and forth looks like.  Should be fun.

Would have posted this quite a while ago, but decided to actually write up some stuff.  Here's a direct link to the wiretap I just finished, and here's a page discussing what I've done to this point for the converters.