Man I wish I could afford the kit. I have PICs too. I need to get some sticks sold first. Keep up the good work Toodles and hopefully you can hack the XBox sticks.
It hasn’t been dropped, I just havent had time. I took the break from the flashes to get the UPCB released and get the documents up for it and work on the code. Then came the racing project I’m getting paid for, and now school’s starting, and when that gets settled I need ot finish the racing project. Believe me, I haven’t forgotten about the flashes at all, I’m just pretty damn strapped for time.
Steve F, if you’d be so kind, could you take a crap ton of pictures of the 10 pin connector you’re using and the resulting ribbon cable and all of that? I’d love to use them to add to the Instructable for those using Comp style sticks.
Yeah, ill take some pics when I get it all wired up to the stick, hopefully by the end of the week. Today, I just stripped the wires and touched them together to make sure it was all functioning correctly, gotta wire it up when I have time.
OH, just wanted to ask about the Genesis support as well. when I get a new hood connector, I am going to want to hook this up. Any reason it only supports three button?
A couple questions about the DC piggybacking tutorial. Why use a diode for taunt? Can’t the program button do exactly that, and furthermore, can’t you save it so it works every time you start? I was under that impression.
I’m using a third party controller, not the agetec PCB so you get an idea where I’m starting from. The L and R buttons were so shittily made on it, that they activate digitally ( I tested them out with a button attached). The dc1 and 2 come from the controller’s wire, so am i going to have to strip the casing at a higher place on the wire or something to wire the console cable up?
Is it just me, or is that the same connector, but you are saying the wires do different things? If you could please clear this up…
Button remapping is NOT possible on piggyback controllers; this was pointed out a couple of times in the thread, and in the first post when mapping was introduced.
EDIT: My mistake, it wasn’t included in the first post. I will update that now.
In my defense, it was pointed out clearly before:
http://forums.shoryuken.com/showpost.php?p=4059295&postcount=205
http://forums.shoryuken.com/showpost.php?p=4059295&postcount=210
http://forums.shoryuken.com/showpost.php?p=4059295&postcount=211
The cable that connects the DC controller to the Dreamcast originally will need to be cut; the Instructable recommends about 3" from the point where it connects to the DC PCB. That would give you plenty of wire with the 3" left connected to the PCB to connect to the ribbon cable, while leaving almost all of the cable that plugs into the Dreamcast to use for making the UPCB cable. Perhaps I’m not understanding the question, so feel to reiterate if that explanation or the one in the Instructable doesn’t answer what you need.
The ‘right connector on the bottom’ refers to where the cable that plugs into the console connects to the Agetec PCB. You’re third party one may be the same or not; I have no way of knowing. The second one is the pinout of the plug that goes into the dreamcast. On the Agetec, those are the two ends of the same cable.
The two lines that hold the communication for the Dreamcast are called Serial A and Serial B. On the UPCB, the connections for those simply named DC_1 and DC_2. You want to connect the red wire from that 3" stub to DC_1, and the white wire to DC_2.
Oh, okay, now I get it, thanks for clearing that up.
rant
MFing piece of shit Gamecube. Grrrrrrrrrrr
I have the stimulus file all setup in MPLAB, to send both a probe and a status request, with perfect timing so everything sends exact. Debug with the simulator, and it works AWESOME. Plug in into da cube, and it reads jibberish.
Damn frustrating piece of crap. Grrrrrrr. If the stimulus file is EXACT to the specification I find everywhere of how things are transmitted, and the code reads it slick as shit, why won’t it read the real thing yet???
I can find example of uber last gen chips, with less that half the speed, doing the job just peachy; why can’t I get this uber awesome monster of a supped up turbocharged PIC to do it!!! Am I really that stupid? Worse yet, there’s may one or two people I could hunt ont he internet that might have the PIC knowledge and gamecube knowledge to make heads or tails of things…
Baby punching time.
/rant
Have you tried this page Toodles?
http://www.int03.co.uk/crema/hardware/gamecube/gc-control.htm
TTFN
Kaytrim
Oh god yeah, but thanks for trying. That page has been invaluable, and has also been listed as one of my resources in the gc.h for a few releases now 
It just kills me. Bosed on the information on that page, and the many others, I’ve got the waveforms nailed; its not even a hard protocol. But for some reason, the code works flawlessly on the simulated waveform I send to it, all based on that information.
http://img267.imageshack.us/img267/940/logicanalyzelw9.th.jpg
That shows the simulated 0x00 probe by the gamecube on the bottom line, and the top line is the 0x090000 response my code gives. Based on the information on all of the gamecube pages, its perfect. (the gamecube uses a single line for communication, but in order to separate things out easier when debugging, I made the output from the UPCB go to a different line than normal. When hardware compiled, it goes back to both reading and writing the one line. )
http://img50.imageshack.us/img50/6360/logicanalyze2ei9.th.jpg
This shows the 0x40??? (0x400301 in the pic) code that the gamecube should send to ask for the status of the controller buttons and stick. While I don’t have a response coded in yet (I try to save the easy stuff for last), I can still watch the code read it and respond properly.
What really sucks is that I know I’ve read the 0x00’s properly before now, and after having responded with the 0x0900 controller ID, read the first byte of the status poll, the 0x40. I had a bug in the code that wouldn’t let me properly read past the first byte, but I squashed it. I finally figured out enough about the stimulus files to be able to make that waveform I’m sending it, get it working awesome against the waveform, only to have it shit the bed when hooked with real hardware.
Add in that there’s code for a far lesser PIC doing just fine here: http://www.ppl-pilot.com/index.htm
Yup, baby punching time.
Just a teensy bit frustrating.
Steve F (and anyone else that is interested in Dreamcast piggyback), I realized I could setup the select button to taunt on the Dreamcast. If someone pipes up and says they want it, I’ll put it in, otherwise I won’t.
Frankly, I’d rather not. It would make any piggybacked controller on the DC_AUX port have Select press both Start and Short. If someone tried to piggyback say an xbox controller on that port, then they’d be shit out of luck; if they did wire up select, pressing it would activate short, start, and back at the same time. If they didnt, well, no back button.
Long time no speak…Freakin’ life! Anyhoo, apparently I have an old MAS dreamcast stick and it has an interesting pc board in it with this chip: SX28AC/DP.
It appears that it has only that chip and some resistors, caps, and a crystal. Shall I investigate further? It still works like a charm. I also have a Gamecube MAS
its an SX brand microprocessor, same idea as this, but it goes very damn fast. If you have a way of trying to download the code of the microprocessor, feel free to try. Frankly, I dont know anything about the SX microprocessors except that they can have very high clock speeds.
I’d like for it to be taunt on the DC piggyback… But I see what you mean about the kind of conflict it could make… If it’s not hard to do, I think it’d be useful, maybe as a separate thing for those using Dreamcast?
BTW, I will take the pictures of the wiring for the happ stuff this week, I’ve been putting the case, and everything else together.
No rush on the pictures. As for the DC taunt, Id REALLY rather not have it as part of the main build. If I do, that’ll double the number of different configuration .hex’s I’d have to make each release. If you’ll give me the info on your particular setup (extra buttons or LEDs, using the programming button) and I’ll keep just one build in the releases for your setup with the coded in DC taunt.
Well, I received my new Magic Box converter in the mail, and I’m using it for Saturn->Xbox1 conversion, just like I’m using the Innovation for Saturn->DC conversion. It works, but Im not sure if I’m ready to recommend it to everyone yet. CvS2 just did not feel as snappy as it does on the DC with the other converter. MvC2 felt fine, I was able to do everything I could on a DC, so I’m not sure if its a problem with the Magic Box or with CvS2 for xbox. I using the programming button to set all of the buttons to be all of the buttons, and the key display on CvS2 training mode showed them all come up on the same frame. The sluggishness seems to be d-pad related; I had a bit of trouble pulling off wake up reversals, which I normally don’t have any problems with. Hmmm.
Sorry for the babbling, just need to jot some notes down. The magic box uses the MC14015B (should be a standard 4015B) as the four bit shift register described in the maple patent docs.
Good news: putting the pcb in a VSHG is pretty straightforward. I’ve got some pics if anybody could use them.
Bad news: I can confirm chaosdragon13’s reports that the UPCB w/ usb cable doesn’t work correctly on PS3. I tried the upcb hex v1.4 and v1.6, same results:
winxp: diagonals & all buttons work fine. confirmed in control panel & played games in fba. This leads me to believe the stick is wired correctly.
ps3:
Ps3 games: VF5: diagonals don’t work. confirmed via input display.
PSNetwork games: R-type: diagonals don’t work.
Ps2 games: CCC2 & Gradius V: no inputs recognized at all, "press ps button"
psx games: Einhander: diagonals don’t work.
I can keep testing on individual games, but something tells me the diagonals issue isn’t game specific.
I have a stock vshg to compare against if you can give me any tips on capturing usb information.
Well, damn; I coulda sworn I had working diagonals when I tried VF5. Weird. Okay, the PS3 is incomplete and I’ll update the first post to note it.
I appreciate the offer to capture the original VSHG data, but I have a sixaxis controller here I can just try to use that data directly.
I have one hell of a math test I’m currently studying for, and should be done with that either this weekend or sometime mid next week. Once that’s done, I’ll work on getting a separate USB modue going specifically for the PS3 using the SIXAXIS information.
If you dont mind me throwing a bunch of .HEXs at you to test, I wont mind trying to whip it into shape.
Well, I already captured the vshg hardware descriptors & some sample inputs from the two sticks, if you want to take a crack at them, they’re here
Most notable difference is that the vshg is only sending info during a change of state, the upcb is sending info constantly.
I don’t mind testing out different revisions, although my time is going to be kinda erratic for a while, so it may be as much as a week before I can test any particular batch.
Same thing with the Pelican converter and SIXAXIS; they both send the data only on state change. (although I seem to recall the Pelican would start sending constantly if you hit the analog button and/or were using a dualshock 1 or 2 controller; I wrote it off to minor fluctuations in the analog stick’s readings.) I thought originally that it had to do with the descriptor, but Im starting to think that I’m supposed to check for a state change and only send on changes, which is easy to implement.
I’m pretty sure I still have your email, so I’ll send them as they’re built and you can try them out whenever.
If any other UPCB owners have PS3s they can test with, PM your email please.
Any secrets to wiring together those pesky 15 pin connectors for the Console cables? Or just a few tips might help. I have wired and rewired my USB cable maybe 10 times, and unplugging and re-plugging it, it may show up 1/10 times or so, but never consistently. Anything in particular I should check or do to try to get a handle on this?
The only tricks to it that have made it easy for me are to use a very small guage wire for the system select lines (the ones marked High or Low in the .H file), do the system select lines first, check them with a multimeter, then add the four USB wires, check it with a multimeter, close up the hood, and check with a multimeter. If the cable checks all out (passes all of the tests described in the Instructable) and doesn’t work, then something else is going on.
One problem someone had that you should double check is the orientation of the chips. The orientation of the 4066N is opposite the PIC; the notch on the PIC should be closest to the ‘Output to DB15’ end, while the notch in the 4066N is farthest from the ‘Output to DB15’ end. If in doubt, pop the 4066N out and test without it. (If either chip is in backwards, you’ll notice that chip getting warm. The chips should NEVER be warm.) If you have piggybacked the DC already, disconnect it for the testing.