for me to make a PSX->PS3 converter? Just get an InPin from laugh, it’d be cheaper.
for me to make a PSX->360 converter? A new 40 gig PS3.
for me to make a xbox360 to ps3 converter or visa versa? Two PS3’s and a year to work on it.
Custom work from me is spendy. I’d rather work on stuff that benefits everyone.
Yup. Assuming you have a newer revision firmware. I forget what revision I included it.
For a dedicated piggyback cable, you do, but you can use a button select cable.
Just the one I posted on the previous page.
If you don’t believe me, check the code. This excerpt is from main.c.
If it sees that line RE2 is high, it knows we’re dealing with a USB family of cables. If it sees RE1, RE0, RA5 and RB1 and all low, then it knows a button select USB cable was connected, and starts check the buttons to see which mode to go into.
Are you at all Unix-literate? The reason I ask is because apparently when holding Start and Select, your board should show up as a serial interface (USB CDC class?). That means I should get both a tty device and a cu device for it. It looks like OSX tries to, but somehow it has fits trying to actually match the device to a driver:
Jan 2 17:41:58 chibi kernel[0]: IOUSBCompositeDevice: family specific matching fails
When I plug it in without holding anything, I get this:
Jan 2 17:47:22 chibi kernel[0]: Universal PCB: family specific matching fails
I get the same thing with HP+HK held when plugging in. It’s almost like OSX tries to enumerate it, but somehow the USB product ID and vendor ID are getting garbled…or the device class. :\
Not sure what to make of it. You never claimed it worked on a mac, but dangit, from all appearances, the standard USB stack should handle this thing.
In bootloader mode, here’s what I’ve got:
USB Device:
Version: 0.00
Bus Power (mA): 500
Speed: Up to 12 Mb/sec
Product ID: 0x000b
Vendor ID: 0x04d8
I did manage to get my stick updated on my wife’s winblows laptop. I also found that if I failed to hold FP+FK and plug into the 360 that after a delay it appears to work…then it stops upon execution of a fireball (wtf?). I’m guess that it’s not supposed to work at all, and that would be what the XBOX_PB_SELECT is supposed to prevent. I guess I should look into that.
Still haven’t figured out why the stick pukes when I try to do the update on my mac though. There’s a whole open source project of utilities for USBPIC boards:
Of course I couldn’t compile it here because…well, of all things the thing make a glibc call to getline() which is part of stdio.h. Except it isn’t on a mac. getline() is gnu-specific and for whatever reason Apple chose not to include it in their stdio implementation. Yay.
So since I know nothing of how to write C or C++, that leaves me screwed to try it. Such a simple call too:
getline(&s, &ssize, f);
Like any of you care about that, but if you happen to know how to re-write that one liner without using a glibc-specific call speak up. I’m determined to not have to hunt down an MS box every time a new firmware revision comes out.
I don’t think the UPCB bootloader follows the CDC or HID protocols; its just a plain USB device and shouldn’t involve any tty’s. In a Unixy environment, I’d expect whatever program used it would likely be some libusb compiled custom program. The PID and VID you listed are the right ones for the bootloader, so the computer is seeing it properly; its just a matter of finding a program that communicates the way the bootloader expects.
Nah, the XBOX_PB_SELECT was only carried over to the piggyback on the v2 boards because I had an extra pin to work with. The only thing I saw it possibly being used for was a way to cut off power to the piggyback when not in use, but I never really followed that idea up. All of the xbox360 piggybacks I’ve done for others ignored that line completely. If something pukes doing a fireball, you have some sort of other wiring issue going on. Test it works ok without the piggybacked 360, and if so, start doublechecking your wiring on the 360 pad.
The bootloader on the UPCB is 100% the ‘PICDEM’ bootloader, the one that came standard on the PICDEM or PICDEM 2 boards. If you can find programs set to use those, you should be golden.
I am not sure if the NES support has been updated ever since you fixed it for me a while back, but I just recently ran into problems with it. I am running an older version on my UPCB, 1.8 or 1.A, I forget which one.
For all of my games so far I havent had any trouble but for one of them, Heavy Barrel, which I recently got, the game keeps randomly pausing and unpausing if I use the UPCB. I first though it might be due to a bad connection of the game since it took me quite a while just to get it to work and then it froze on me when I was using a normal NES controller. Although today I relaced the pin connector so the game works with no problems and the UPCB still has the same problem.
I am not sure if there is anything that can be done about this, but just letting you know that the NES support isnt 100%. There may be a few other games that will have this problem but this is the only one I have come by so far.
The software I load up is trying to find the cu interface created by the bootloader. Huh. Oh well, as I said - you never claimed it worked. I’ll research it some more. The stick-killing fireball only happens if I forget to hold HP+HK when I plug the stick in.
It tells me that I have a madcatz plugged in. The cursor on Point of view hat is working but the x/y axis doesn’t move at all. All the buttons seem to be fine.
The X/Y should be the left analog stick; it should stay where it’s at. Moving your stick should only change in the POV hat. It sounds like it’s working just as it should.
If possible, do this:
Turn on the xbox360 to the dashboard.
Plug in your stick with the Fierce and Roundhouse pressed.
Check to see how the lights on the 360 pad are reacting.
I hate to say it, but you’re probably looking at a problem with the security chip on the controller pcb suiciding. It connects and works fine on the PC, and the same steps fail on the Xbox360. The only thing that makes sense is a problem is the security chip on the pcb not authenticating like it should. Knowing how the lights are behaving may help to determine that.
It looks like Digikeys pricing went up a little bit since you made that original list and since I want to make 2 of these, I figured it was worth taking a look to see if I could save some money, since I was I planning on ordering my PIC through Newark anyway. (Microchip.com’s site gave me an error when I tried to sample some pics).
I’m pretty handy with a soldering iron and I understand basic circuit design, but I don’t know jack about different types of passive components and whether I should or shouldn’t avoid certain types/brands. Am I safe as long as I grab any resistor with the appropriate resistance or capacitor with the given capacitance? At the <12V that this device should be operating, I’m guessing that anything specced for 12V or better should be fine?
Microchip changed their sampling recently. It’d still be a little cheaper to wade through the site, but you’d be looking at paying about $7.50 for the sample shipment of at most 2 of the PICs you need. I’d totally understand if you just bought the things from Newark.
Hi Toddles and a great thank for all your job. I try myself, some years ago, to build a UPCB (call X-Pac, like an i-Pac). Pleasure to see we use the same core (18F4550 at 20M). The project can be found here: http://www.gamoover.net/Forums/index.php?topic=8255.0
Now UPCB replace it, but I try to use your GC source code to build GC controller with analog support. I don’t see anywhere the value of the pull up resistor, you put between pin 6 (3,43V) and pin 2 (DATA). Does a 4,7Kohms resistor can be used?
Ah, that information in the gc.h needs to be updated. The DATA line is already pulled high on the gamecube itself. You can use a multimeter on the gamecube itself to check. Hmm. I don’t remember now. It may be tied to the 3.3v, or it may be tied to the 5v source. The important part is that is it already tied. Read the line like you would any normal input. When responding to the gamecube, never set the output High; Set the TRIS to 1 for High, and both LAT and TRIS to 0 to set the output low.
For the time, only Data pin is used (plus GND and +5V to power the pic). +3,43v, pin 6 is not connect to anything. I used your source code and when I connect to Gamecube… nothing. When I used logical analyzer I see Gamecube init (probe) sequence (plus my answer) looping again and again. Like Gamecube don’t understand the reply.
Here are some photos of the traces:
Does the time between GC sequence and reply is important? Do you see something wrong in my traces?
I had planned on using both a 360 and wii classic controller, but I have run out of space inside the case. I saw in the systemselectlist.txt a listing for Wii-Chuck I2C. What is this? I don’t imagine I would just be able to make a system cable to plug into the Wii-Remote? Any plans on adding support without having the piggyback a classic controller? Any suggestions? Thanks.
