btw are the pictures of the UPCB and the kits you sell have double sided board using vias and such to access both sides??
oh and does it matter where the resistors are placed?
btw are the pictures of the UPCB and the kits you sell have double sided board using vias and such to access both sides??
oh and does it matter where the resistors are placed?
Yup. Doublesided copper, soldermask on both sides, silkscreen on the parts side.
Uhhhh…As long as they’re electrically connected like in the schematic, not really.
Just a braindump of what I’ve done.
USB code has gone through a major overhaul. All of the Microchip code has been removed from the UPCB code, although the bootloader is still Microchip code, that’s a very separate module from the UPCB code. That means I can finally have all of the UPCB code released under a proper GPL. Yay!
The USB code has been split up to have a ‘allusb’ section, with definitions and a few global variables expected to be used by the other USB sections. I’ve got a PCUSB section in now, using the Radio Shack adapter descriptor, exactly like the last release; works on PS3 but without the PSX/Home button.
I’ve also started a PS3USB section, using the descriptor from the SIXAXIS. That section works just peachy on a PC, but gets no response from a PS3 yet. I’m sure there is a bunch of data I’m missing before the proper SIXAXIS support works on real hardware. For example, in order to get the SIXAXIS responding with the button states, a particular GET_REPORT request has to be sent, at least according to the patch Sony wrote for getting the controller working under Linux. That request is expecting 17 bytes of data to be returned, but the response should, AFAIK, be the normal status report, which is 0x31 bytes. So I’m a little unsure what is really going on in that transfer, and god only knows what kinds of other requests are going on. Blah. I’m not really sure how I can handle this. I really need some way of snooping the USB traffic; USB protocol analyzers are DAMN spendy. I could try making a protocol analyzer on my FPGA dev board (Altera DE-2 in case anyones familiar with them) but god only knows how well that’d work out or how long that would take. Another, albeit very painful option, is to try and have the UPCB record the odd requests that come in, try to write code on the PC to send the same request to the SIXAXIS, and then try to implement that response on the UPCB. Also painful.
But, if I can get some sort of USB snooping going in, then getting the SIXAXIS code going and getting native Xbox support starts becoming very possible. What’s even more interesting is that it might actually become possible to figure out which requests are handled by the 8 pin Xbox360 security chip. I’m not saying Xbox360 support becomes possible by itself, but it might just mean that the little security chip could be desoldered from cheap or broken controllers, soldered to a spot on the UPCB, and have 360 support going without a piggyback. Total pie in the sky idea at this point, so hold your questions for two years or so.
So, what to work on? Back to getting Playstation support working with converters? Record/Playback? Work on implementing Xbox1 USB in case I get lucky? Dreamcast?
Dreamcast
EDIT: PSX-> converter support sounds better, actually
TBH I’d much prefer additional system/ps adapter support over record/playback. What you’ve got already is amazing though, of course
Oh, did I mention I have it figured out in my head how to attach that 2x16 character LCD screen
Alright, I’m gonna take a quick shot at Xbox1, which I doubt will work. Then, getting PSX adapter support fixed, which shouldn’t take too long now that I have the debugger, console, laptop, and oscope all connected together now.
Would there be a way to allow over 9 buttons, analogs and, d-pads? I guess the d-pads would just be buttons…
Example being an n64 stick layout. That is if it was like the neogeo independent pinning witch it is not. If a person made a 10 button, four direction, and x/y analogs arcade stick could it be used some how?
Obviously 15 independent pins wont hack this, would there be another way with your device, or is it limited to 4 directions 9 buttons and under?
My vote would be for dreamcast, then record / playback.
Doing my best to ask around about the hid issue.
Okay, I don’t know if I’m being dumb, but I can’t get the extra two buttons on my stick work through the Universal PCB.
I’ve crimped the button cable in the order that is in the first post, but only the first 6 plus start and select seem to work when I plug it into Windows. I tested the connector with a multimeter and it seem okay. I tried flashing the PCB with the latest version, but that didn’t help.
Any suggestions?
Oh crap you’re right. Flash a ‘B’ version of the latest firmware instead of the ‘BP’; the BP version isn’t working right with the extra buttons. I’ll get to figuring out why and posting up a new version later tonight.
Ahh that did the trick! :tup: Thanks, I’ve not got the programming button hooked up yet anyway.
I just found the bug that caused it; Im betting they woulda shown up just find if Start and/or Select were pressed as well. It’s fixed, but now I gotta package everything together, put GPL notices on everything, etc. I’ll have the new revision up tonight as promised. Sorry for the less than perfect introduction to the UPCB
Version 2.0 released.
Changes. Lots of 'em.
To use Turbo: Hold down the Program button by itself. Hold down the button you want to change the speed of, and press Down to make the speed slower, or Up to make the speed faster. “No Turbo” is the same as “Fastest Turbo”, so you’ll want to keep pressing Up to turn off any turbo. Turbo is based on the physical button, NOT what it’s mapped to, so if a button is mapped to many different keys, and that button is set to turbo, holding the button down will press those keys repeatedly, at the same time, at the same frequency. (I know, confusing to read, but hell its confusing to write. Just try it.)
For those who like details, the fastest speed is one frame on, one frame off. Next is two frames on, two frames off; three on, three off, and so on up to 255 (a little over four seconds on, four seconds off). Frame speed is determined by an internal time where needed (USB, Neogeo) or by when the console checks the controller (NES, SNES, PSX, etc)
Nice, all the buttons seem to work okay now from the BP.hex :rock:. I’ll try the turbo support when I’ve got my programming button hooked up.
Hrm, just tried to flash 2.0 version x onto my UPCB, and get the following:
WARNING - Failed to program CONFIG DATA
MESSAGE - Programming CONFIG DATA…
MESSAGE - Programming FLASH Completed
MESSAGE - Erasing and Programming FLASH…
Little worrying?
Flashing the backup dump that I made before trying to flash 2.0 works afterwards though.
:)…
tschah!
Was too excited by the big 2.0 number and didn’t read thoroughly :(((
Got one built, and just got 'er connected to my PC, and it’s showing up as unknown device. I’ve double and triple-checked the cable, and made sure PROG is not shorted. What gives?
Additionally, when I plug it in and unknown device appears, the entire bus sometimes dies until I power-cycle the machine. Have you seen anything like this?
That’s not good. You need to recheck the wiring on your cable; make sure there isn’t a short between power and vcc; plug the USB cable into the UPCB, but don’t plug it into the PC. Set the multimeter to read resistance, and see what the resistance between VCC and GND is using the two test points on the UPCB. Then, check the pinout of the UPCB cable to make sure the pins that are tied high or low are the pins that should be tied high or low.
Which revision of the board do you have? (EDIT: You got the v2.1 PCBs from me) Does the PIC get warm? Are you 100% sure the PIC has been programmed? Does the behavior change if PROG IS shorted? Post up a scan of the board if you would.
Thanks so far, Toodles, though I’ve checked the cable countless times: no short there. When I was checking the pinouts though, I managed to break the flimsy-ass VCC line from the USB cable so I can’t get you more testing until I fix that.
There is no short in the cable, though, nor anywhere between the two test points. I’ve checked that a near-infinite number of times.
I followed the instructable for the cable…and lo and behold, IT CHANGED in 2.1?! Gah…someone should poke those guys and get those instructables updated if it has actually changed, and I’m not misreading. In the old one, Pins 9 and 12 didn’t have to be connected to anything. Now they’re both pulled High. Is this correct? If that’s the case we found our bug.
[ Edit: Nevermind, checking USBTEMPLATE.H there is no change from the instructable. Systemselectlist.txt says there is. Which is correct?]