I don’t think there’s anything you can do about PS3 controllers.
You have to have a PS2 connection/PCB. PS3-type controllers just don’t work with PS2 games, PERIOD… That’s built into the system and has nothing to do with backwards compatibility as far as I know. Besides, the only PS3 owners that this kind of thing helps are people with the 20GB, 60GB, and 4-USB port 80GB NTSC PS3 consoles and their PAL counterparts.
It’s really not that big a deal unless your only controller is a PS3-type. Converters and PS2 controllers are so plentiful it’s not as if you don’t have options.
Would be nice, but not necessary. In fact, extraneous IMO. So many sync issues with wiimotes, plus interference, plus the need for batteries. Unless you’re going to be playing REALLY far away from your Wii and need something wireless, I think using GC support to make a stick work with a Wii is the best solution all around.
Would love to see SNES support. Not so big on Genesis support, as if that happens, there would be 9 pins needed, and therefore less of a chance that a person could make cables out of RJ-45 connectors. If it’s incorporated, I’d love to see one pin for the extra Genesis wire, then the other 8 being for the rest of the cables, so that it would still be possible to use an RJ-45 out of ease/less soldering, and for others who want hardcore support to use a DB-9/15/25/IDE cable/whatever.
That’s my opinion. Plus, not sure how many Genesis games were stronger than SNES counterparts anyway. Obviously Eternal Champions players would love it. Maybe Shaq-Fu & Ballz (LOL). That’s about it. And this is coming from a former Sega fanboy.
Interesting idea. I have a Wii classic gamepad thing which I was planning to support going the other way (i.e. connecting it to USB). It uses an I2C interface so can be analysed easily.
The main issue I can see is that I don’t know how much power the Wiimote can supply, but I bet it’s not much. Power stability issues can be a problem for arcade sticks, because they use noisy microswitches instead of the usual carbon pad switches in gamepads.
Don’t the Gamecube controllers work for all games that support gamepads then?
Interesting, I never considered that, I’ll see what I can do. Unfortunately PS3s with PS2 compatibility are not available any more so testing it could be tricky. My brief investigation suggests that it is easy enough to do “blind” though and I have someone who can test it.
Genesis/SMS is definite, it’s the same as Neo Geo just a different cable. NES/SNES is so trivial I might as well, even if I don’t have an actual NES or SNES myself.
BTW, what games do you play on those systems that you want an arcade stick for?
I’ll keep an eye on this thread, but please hold off a bit until I have something to show.
I have a working prototype but am going to build a new one from the ground up. I also really need to get another stick to mod (I have no woodworking skillz…)
I’m also trying to implement just PS2 and PS3 on an AVR, mainly for size reasons. Have you managed to determine what exactly the USB device needs to do for the PS3 to see it as a PS3 controller? I’m providing descriptors lifted from the UPCB code and the same response to USBRQ_HID_GET_REPORT, but the ps3 still assigns a controller ID before I press the home button.
I’m afraid I don’t know. I am just using the same HID descriptor I use for Windows, and it’s fine in all PS3 games that have been tested. All you need is a two axis 8 bit stick and as many buttons as you like. I am experimenting with what else can be added.
I should have lists for the button mapping done soon.
Very good news. I thought about writing you a mail what about your plans about developing this controller board, but then saw this thread! Great!
I like the open source idea. So existing projects will benefit from your work. If somebody wants native DC support in UPCB, then your work is basis. I don’t like emulators, so I’m thinking of adding this 8 bit “protocols” to your work then.
Led controller connection and LCD display would be great, too. Perhaps then color schemes and pics can be loaded from the sd card.
UPCB
I’m the guy from germany with those UPCB. Jason from arcadezentrum.de will assemble them, too. Let me know I you want one for testing purposes. I can send you one.
I’m excited to see the finished product, and maybe some drafts of the board itself, as well as explanations. I think it would be good to put up, just to see what people think could be improved upon.
Honestly though, good luck, I hope this project turns out!
Yeah… I’m still trying to decide about that. I think I might just do them all and use a 15 pin connector like the UPCB. I really need to spend some time going over the docs for it, it see if I can make the cabling compatible. Maybe it’s just me but a lot of the design decisions in the UPCB seem rather odd, but if it’s not going to compromise my system then it might as well use the de facto standard.
As for the open source stuff, I have not decided if I will open the DC protocol stuff yet. Everything else will be open source though.
Saying that, the AVRs have no code protection what so ever anyway, so anyone could just read and disassemble the code I suppose.
BTW, does anyone know anything about the PC-FX controller protocol? I have found some documentation on it and worked out that it is a parallel to serial shift register of some kind, but don’t have a pin-out or a real console to sniff one from.
That sounds like a plan. I have a question though…
On what trigger should data be logged? There are two options I can think of: on a 1ms (1/1000th of a second) clock or when data is sent to the console.
The former gives very accurate timings, but does not show what the console itself is seeing. The latter gives you insight into what inputs the game receives, which should be helpful for checking what button presses and joystick movements you are missing or lingering on too long.
Of course, for some older systems you can’t know when the console polls the stick but all modern ones do (NES/SNES/N64/GC/XBOX/360/PS1/PS2/PS3/Saturn/DC etc).
Okay, thanks for the kind offer. I may take you up on that.
Well, take a look at http://denki.world3.net and you can see the old Arcade Joystick controller. I need to get some pics of the updated stick on there, as the LCD looks a lot better now it’s backlit.
Hopefully I’ll have some more pics soon.
Oh, and BTW, I did some tests today and the pass-through method for 360 pads should be doable. At least, I can use a CMOS analogue switch IC to change from one USB device to another seamlessly without the PC noticing what happened
I like the idea of the LCD screen being added to the mix as well. There is a cat on Ebay that sells the LCD sticks but they are strictly for 360 and leave a ton of people out of the loop. (e.g. ME) I would be seriously interested in this and would love to have something so versatile in one of my customs. Add me to your list of prospective buyers!
I’ll be sure to pick up the finished product–damned the shipping expenses. I lack a decent set of woodworking tools so I’ve ended up modding Agetecs and would love to have one like yours with the functional LCD someday.
I don’t know if this is new or not but nobody has cracked 360’s peripheral security. All of the mouse/keyboard/ps2 adapters need an original wired controller to interface with the 360 and they don’t do a very good job of it(35ms of lag and low polling rate). If you honestly could reverse engineer the security IC you would be able to sell it to 3rd manufacturers for a pretty penny. Every peripheral device that works with the 360 has a security IC on it, yet I don’t know if they’re interchangeable or not. You might want ask around the xbox-scene forums, they would be more up to date on the status of the peripheral security.
Yeah, sounds like a breakthru? To understand your plan correctly I summarize: You take in the init phase the payload sent from the security chip and after that (specific message) you want to change to your own xbox360 controller implementation. With this solution it should be possible to connect several custom xbox360 pcbs to one “security adapter”?
I don’t see the benefit of such a feature, but perhaps you could a timestamp when logging data sent to console. Then you’ve both, timing plus all data.
What about the lock bits in the fuses. Disassembling and the programm in assembler?? Sounds like great fun! Dreamcast / Maple Bus support is definitive a great advance!
Okay, your initial plan was to recognize the console via the protocoll data sent. This is of course a very good solution. UPCB recognizes the consoles via coding on DSub 15 pins. Take only the data lines and ignore the code pins. Then you should be safe and you’re cable compatible.
As bencao said, this doesn’t seem to be the case. The datasheets say “Further programming and verification of the Flash and EEPROM is disabled in Parallel and Serial Programming mode.” and the rest of the locking stuff sounds like it’s intended to protect the program code. To me, disassembling it doesn’t sound too painful - I’m guessing the important stuff is written in assembly to keep up with the bus anyway.
I agree with this too, I would be one of your first buyers if you do this…thinking of making another stick, but wanted it play all the current gen. games along with all the KoF collection fighting games for ps2 and SFAC :tup:
I thought about writing you a mail what about your plans about developing this controller board, but then saw this thread! Great!