Thanks, I’ll check your trading post.
And you did send ribbon cable, but it’s monocolored, and I’d really rather have colorcoding to help cut down on idiocy on my part. And the radioshacks near me only stock crimp-pin DB15 connectors 
My bad; let me know if you decide to get hoods or anything else from me and I’ll throw it in to save one shipping. If you dont, that’s cool, just let me know so I can send you a rainbow cable.
Anyone: If you ordered a kit and got a grey ribbon cable instead of a rainbow one, let me know and I’ll send out a rainbow replacement.
After that I go to sleep I thought that is better to post here the message that I sent some hours back…
"sorry pal, I get lost with my thesis (needed to devote some time), I thought that how you said that write on the m-bus is easy you don’t be interested in my PIC code :xeye:, and for the last that I read on the forum hehe, I suppose that I was wrong…
Before I start with my thesis I think about of read m-bus and yes read is hard, but using a 18F4550 at 12 Mips Tcy 83.333ns we have 6 instruction cycles between falling edges of SDCKA and B(500ns), using 74LS95 and the CCP module in capture mode at every 4 rising edges and a 74LS04. Counting the falling edges(as rising edges) of SDCKB when the interruption occurs (at the 4th falling edge) we have a complete byte, using BTFSS and BRA to check the flag we use 2-4 instruction cycles leaving us 4-2 instruction cyles free after the interruption, the next instruction must be a MOVF to W that use 1 Tcy, leaving finally 1-3 instruction cycles free, but that little free time is not important because the next interruption occurs in 1.5 us 18 Tcy more or less, enough time to save the data in W to an array using FSR and POSTINC or POSTDEC and then wait to a new interruption, I write that code, and I simulated that and works fine (in MPLAB) but in the PIC… they simply does nothing how if never was a signal… (edit: I mean receive not was)
If you want I can send you my code and prepare an schematic of the circuit that I build on protoboard and some photos, what ever you want. (I think that my problem is the circuity not the code I don’t know)
Finally, I was talking with mojochan by e-mail (before I going to my thesis and before I can make contact with you the first time) at first very well they responds my e-mails and they ask to me if I could send some information (videos of the signal at the oscope, decode information of the signals by hand, photos) and I send the info… after, him send me back his code of his project and then never responds an email back. I don’t know what happened to him.
sorry for the long long LONG wait hehe."
I have two final tests today, and two tomorrow, so I understand. 
I am very busy, too. I am happy summer vacation is almost here.
I understand. Using two 4-bit shift registers (I would probably use one 4015 instead of two 74XX95) to read the maple bus, and then read in the data into the PIC one byte at a time. This is good. I thought about using this, but I did not know about CCP; I expected to read in the byte with ‘MOVFW PORTB’ or something similar. Using CCP looks very smart. I have not used CCP before. I will read the datasheet about CCP. Thank you for the suggestion.
How are you checking to see when to start reading? How can you tell the ‘start pattern’ is over so you can start reading the bus?
How are you detecting the ‘end pattern’ so you can stop reading?
How are you handling CRC patterns?
Are you able to snoop (‘eavesdrop’) the communication between a Dreamcast and a Dreamcast controller?
I will read up on CCP and see how I might use it. I have a few 4021 chips, and may order a few 4015’s and 7495’s to try and duplicate what you are doing. I will probably try to build it with a 18F2550 like you have. I will post anything I find. Thank you for the suggestion, and I will definitely be working on it.
If you send your code and schematic, I will test it, but I think I know where to work from now. If your code does not yet work on a real Dreamcast, then I will just try on my own for now and I will ask any questions I have. If you get it working, then please let me know; if I get it working, you will be able to see my code and schematic here.
Toodles, are you quoting somebody there?
Oops, fixed it. Thanks Green.
After the PIC send the device request to the controller, SDCKA and B go to stand by state, I configure the CCP2 to make an interruption at the first rise edge of the SDCKA, both signals A and B remains on stand by for 52 uS and then the controller send a response to the device request beginning with the start pattern, SDCKA go low, and remains low while SDCKB make his four falling edges, and then SDCKA make a rising edge (from the first falling edge of SDCKA and the rising edge of SDCKA the time elapsed is 2.2uS), and here is produced the interruption (sorry I don’t tell you before that I don’t use global interruption because uses more Tcy meet an interruption than use BTFSS and BRA to checking the interrup flag) At this moment who is marking with the A word in the image below we have 750nS before the first falling edge clock of SDCKB between A word in SDCKA and the first red 1 on SDCKB (may be more, I forget my notes with the timings in the school, tomorrow I search them), that is the key moment, at rising edge of SDCKA, here we know that the start pattern end, but we have a first falling edge on SDCKB that is not CLOCK signal is only data (Blue cero in the image), we can make time to pass these “cero” falling edge and avoid that the CCP1 count them, and then configure the CCP1 to count the next falling edges of SDCKB (that are marking with red numbers in group of four) using the CCP module and only waiting the interruption… that is my idea of how detect a start pattern and how know when the start pattern end and start the data. (I hope that you can understand me… no the idea I mean understand my English haha:looney:)
http://img37.picoodle.com/img/img37/4/5/12/t_help2m_187a8ae.jpg
the code that I build is a routine that recognizes the start pattern as the same manner of the last paragraph and try to read the first four bytes of the data (source AP, destiny AP, data size and command code) and then lets pass the rest of the info of the device status (108 bytes) in MPLAB works but implemented, well you know :wasted:. At this moment I don’t think too much in the end pattern the actual problem make me crazy :looney: (I post my problem in microchip forum)http://forum.microchip.com/tm.aspx?m=338063
The CRC I don’t know nothing of that I just jump that sections of the m-bus patent because when I reading the patent (december of the last year) I only interested in know the state of all buttons and analogs, (because I only attempt to interface a dreamcast controller by USB to the PC) I only uses device request and get condition and never the CRC, I don’t know when the CRC is used by the dreamcast on what situations are used I don’t know sorry, when I oscope the communications between dreamcast and the controller with cd game and without cd game when the dreamcast send get condition the controller response the status of all buttons without CRC but I can only see signals that are continuously repeated on the oscope like the get condition sorry :sad:.
tomorrow if I have time I will build the schematic and send you the code…
Edit: the Device request command I never look them at the oscope, I have to read the patent and then build a frame with the device request command and try, and it worked
No, the CCP in capture mode only capture the value of TMR1 or TMR3, but they help us with the count of the falling edges using his interruption, so you are right we must read with MOVF PORTB after the interruption and before the next falling edge or we miss a bit.
I’m getting an Xbox360 Madcatz microcon controller, for hackage into an arcade stick - but a few posts up you mention the piggyback support isn’t entirely there yet for 360.
What I’ll probably do is make a project box for it (in case I get a 360 for my arcade machine, in which case it’ll need to interface with my arcade setup - but so I can still take it elsewhere if I need a 360 stick on the go).
How does the UPCB work with a project box? Is it just making a neo-geo console cable and then using the outputs from that to go into a project box?
Cheers,
–flux
Piggyback support IS currently in. The piece that isn’t there is the way to control the Guide button as well. On the rev 2 boards, there is a line that can be connected to the guide button, and will activate with Start and Select are pressed. I just need to put in the code to do that, but thats a 5 minute one banana job. Given the choice, I’d seriously recommend piggybacking. I plan on working on the 360 piggybacking Instructable this weekend.
But, to answer your question directly, if you want to use a project box setup, here’s the pinout :
- GND 9. GND
- Roundhouse 10. Fierce
3 Select 11. Start
4 Forward 12. Strong
5 Short 13 Jab
6 Right 14 Left
7 Down 15 Up
8 +5v
Make SURE pin 1 and 9 BOTH connect to ground. That’s how the UPCB detects you’re using a Neogeo or project box setup.
I’ve been trying to tackle my to-do list, starting with Gamecube. Damn thing’s being a lot bitchier than it should be. Im about to start rewrite attempt #4 of the routine that reads the data from the Gamecube. I’m pretty confident of the routine that writes to the 'cube, but until I am reliably reading, there’s not much point in worrying about that yet. All I know is its being far more difficult than it should be.
Just wanted to drop a line saying work is in progress. The previous one-banana stuff that was needed has already been implemented:
- EEPROM Defaults. The EEPROM where the button mappings are saved are checked on boot; if they’ve been wiped (from installing a new UPCB .hex firmware), it auto sets up default mappings for everything.
- Button select USB cable can be used for xbox360 piggybacking by holding Fierce and Roundhouse when plugging in.
- Extra ‘RB4’ line on the piggyback connector will go low if both start and select are pressed, so that line can go to the guide button on the 360 pad or whatever other devious stuff you want.
As soon as I get progress on the actual console support ('cube or Saturn hardware or whatever) I’ll bundle a release. And yes, I still need to work on a 360 piggyback instructable. All in good time.
Just to be clear, there’s nothing out of the ordinary for 360 piggybacking, is there? It’s just wiring up the buttons/cord cables to the appropriate pins on the UPCB, correct?
Yup, nothing special about it as long as you have a common ground 360 pad. Up to up, down to down, jab to whatever (X? I forget), VCC to VCC, ground to ground, etc.
For the ones that are oddly named:
The ‘RB4’ pin (19) should go to the Guide button.
The ‘RA0’ pin (17) is the for the 7th button, the top most extra button if you have 8 play buttons instead of the regular six; I would recommend LT for it, and using a resistor on the trigger to hold it high.
The ‘RA1’ pin (18) is the for the 8th button, the bottom most extra button if you have 8 play buttons instead of the regular six; I would recommend RT for it, and using a resistor on the trigger to hold it high.
The ‘RB0’ pin (11) is for the Start button.
The ‘XBOX_PB_SELECT’ should not be used. leave it unconnected.
The X360_1 pin should go to the D- wire (white) of the USB cable coming out of the 360 pad
The X360_2 pin should go to the D+ wire (green) of the USB cable coming out of the 360 pad
WOOT! Gamecube works!:nunchuck:
Just played some Soulcalibur 2 on my old cube and it was smooth as all get out. I need to bring the code upstairs, test on the Wii with VC games, and then get started on a GC mode specifically for Smash Bros. Release hopefully in the next day or two after I try them out, but we WILL finally have a way of properly playing SSB on a stick!
Awsome. I cant wait for the new version. Now I will just have to get in some parts to make the cable with.
Firmware 1.9 is up. Changes:
- EEPROM Defaults. The EEPROM where the button mappings are saved are checked on boot; if they’ve been wiped (from installing a new UPCB .hex firmware), it auto sets up default mappings for everything.
- Button select USB cable can be used for xbox360 piggybacking by holding Fierce and Roundhouse when plugging in.
- Extra ‘RB4’ line on the piggyback connector will go low if both start and select are pressed, so that line can go to the guide button on the 360 pad or whatever other devious stuff you want.
- GAMECUBE! Tested and working on both original Gamecube and on Wii. There are 5 different modes available, but really, you don’t need to worry about it. I’ll go into more on the modes in another post so I can have all the nitty gritty GC details in a post by itself. But so far it’s handled everything I’ve thrown at it wonderfully: GC SoulCalibur 2, Wii VC games SF:WW, Mean Bean Machine, Punch-Out, Zelda:LttP, Wii native game GG:AC, and of course Smash Bros Brawl.
I’m a bit ashamed of the hackishness of the routines that read the GC line, but whatever; it works and can always be cleaned up later. I’ll edit the links and info in the first post and then post up the GC mode details.
Gamecube Modes
(Short and sweet for now since SRK ate my first writeup)
-
Default [automatic if you didn’t select any other mode] Stick gets reported to both right analog and d-pad. Select is Z, Start is start, and the layout is:
YXL
BAR -
D-pad only [hold Start when plugging in.] Same as default, but the stick is only reported to the d-pad. Right analog always in neutral.
-
Analog only [hold Select when pluggin in.] Same as default, but the stick is only reported to the right analog stick. D-pad is always in neutral.
-
Smash Bros. Basic [hold Strong and Forward when plugging in.] Short is shield, Jab is A, Strong is B. Double tap a direction to dash. A+B+Direction does a smash attack using the C stick. Select is a dpad down taunt.
-
Smash Bros. Advanced [hold Fierce and Roundhouse when plugging in.] Buttons same as Smash Bros. Basic, but include forward as ‘jump’ (just the Y button), fierce as ‘run’, and roundhouse as ‘lock’. Shield button will do a half-pull on the trigger with no click unless the ‘run’ button is pressed as well; then it will do a full pull with click so you can choose which type of shield you need for hit recovery, L-cancelling, whatever. ‘run’ button also makes the analog stick report as all of the way in the direction you want, instead of just a little bit, so you can choose to walk or run, tild or smash.‘lock’ button is for complex C-stick manuevers. It locks the analog stick where its at, and your stick will control the C-stick until you release the lock button. So, to do Peach’s floating b-air, jump and hold up on your stick, hold the lock button, and move the stick to the left or right.
Phew. Long day. All of these are 1st day creations. I’m very open to comments or suggestions in case any improvements that can be made. But, chances are you’ll pick the one Smash mode you like, remember that one if you play Smash, and for everything else, the default mode should work beautifully.
Great project, Toodles. Looking forward to installing my upcb soon.
Maybe a stupid question but…instead of cutting a hole for the blue connector (D-Sub 15?), is it possible to use the existing cord pass-through with, say an xbox cord (the kind that detaches easily)?
You mean you want a cord coming out of the case, and then connect your console specific cord to that? Sure, very doable; I know codyk did it that way with his. The only thing is that it needs to have 15 pins. The xbox breakaway cables only have about 5.
Using dsub connectors is by no means written in stone. Use whatever you like, but you are going to want them to have at least 15 pins to get the most out of the UPCB. If you want to use different connectors, like circular DIN connectors or just about anything, go for it. If it were me, what I’d do is get a long PC gameport extension cable like this:
(but definitely not at that price)
and have it hanging out of the stick. Make the dsub-15 cables just like normal, and plug them to the end of the cable. As a perk, if you just trim a little plastic off the end, you can plug it directly into a Neogeo AES, CD, or consolized MVS.
Cool, thanks for the info and link; I may try something like that.
So, how exactly do you crimp the IDC connectors onto the ribbon cable? Do you need a dedicated IDC crimper?