I’ll have to look those up later. The big requirement for me is Unix-compatibility. I work on macs normally, but even Linux/FreeBSD would be feasible. If it only works on Windows it’s pretty useless to me. 
I’d like to buy one (don’t care whether kit or just pcb).
How are you handling the (probably long) list of people who want to order one?
Toodles! Good work man! I must admit, I am a bit jealous, for I as well have been working on such a thing. I am using the MC68HC11, with a 2Mhz bus speed. My first priority was indeed tackling the Maple bus, but with not much luk (oddly enough I am and EE). I am thinking with it’s dual serial protocol, maybe it isn’t too strict with the timing? Or if it is, I could make a parallel -> serial converter to collect data and then shooting it out at the 2 mhz speed the DC wants. I was doing research today, and totally stumbled across this thread! I think I will delay my efforts for now and see how yours turns out, for it’s much easier to NOT re-invent the wheel 
Mucho props to you my friend, and I will open some of my many PS2 2 DC converters to get an idea of what they are using. Perhaps this may be a help to you or anyone else who wants to simulate a DC joystick.
I’m not too familiar with PIC development on other OSes. I know that the MPLAB IDE and the debugging hardware made to go with it, like the ICD2 or Inchworm, are supposed to be for windows. I do not know if any other applications for other OSes support it. But, the debugger uses serial, and handing a serial port for VMWare to use was pretty easy last time I tried. If you just want a simple programmer like a JDM, I am sure there are apps for linux or MAC that will do it, but you may be up a creek for debugging.
Hadn’t put too much thought into it. Even if they all sold out immediately (which I doubt), it would only take less than 2 weeks to replace and have more ready to go.
MC68HC11 at 2Mhz? Please keep in mind, I don’t know the Motorola uC’s well at all, but I was under the impression that each instruction would take somewhere between 2-6 clock cycles (I forget the official name of it. E-steps or something). The Maple bus transmits at 2Mbits/sec, giving you only 500ns between bits. You sure that’ll be fast enough to bitbang? Unless you converted the signals to something a separate function like SPI or SPP could read and write, I don’t see how you’d get around the immediate speed problem. Of course if you did figure out how to convert the signal to something SPI could read, then for the love of god, tell me how, because that would mean implementing would be easy. I am hoping my friends can help point out a few normal glue logic gates that will help make it easier to read, even if it is not in SPI format. I’m thinking having an OR gate, so when it is time to read the data, we know which bit is being sent (since one will be low to mark the clock, the other line is the bit to read. Both inputs in an OR will give us the bit to read) and having the two lines each going to an input that will trigger an interupt on negative edge (since according to the waveforms in the maple bus patent, the only times the lines drop is when sending the clock tick so the other line is read). Sad thing is, even doing that, I have only about 3 assembly instructions possible in the interupt to stash the bit, since I only have 6 instructions between bits. I’m not too worried about writing to the bus; as long as the string of bits to send has been figured out before sending, I am sure I can have it move the data line and the clock drop every 6 instructions.
But boy am I hoping they can help make it something SPI can read; that’d make it soo much easier. As always, anything I figure out, I’ll be posting here.
As for converters, I know the Innovation converter uses a slower PIC, the 16C…err, 16c57? Damn, I forgot the PIC they use. They have a daughterboard on them with a 74HC126, a cap, and a transistor on it. I’ve tried to map out the connections as best I can, but it makes no sense at all so far. I am hoping to see the in and out with my Oscope when I get a chance to see if it makes any sense when I see it run.
Why isn’t this thread a sticky?
Great stuff toodles!!!
I just opened one of my best converters, and the CPU info was scratched off! But I was going to solve the DC thing one of two ways:
-
Test the maple bus for speed acceptance. I am 62% sure that it will allow a slow CPU to send the data based on the negative edge of the serial line that is the ‘clock’.
-
Build TTL circuitry that can talk ‘speedy’ to the DC, and just send it 8 bits at a time.
One of these has to be the case for converters, for putting beefy CPU’s in a device doesn’t make you a lot of money. I’ll do more research tonight with my other adapters.
@Vidness - That sucks. I hate it when vendors go scratching identifying info off of IC’s. Actually, back in 1999 there was a company called Netpliance that put out a pretty neat little QNX-based box called i-Opener. Getting Linux to run on it was pretty simple…then they locked down the bios, which was socketed. Next revision? The bios was epoxied into the socket. So then we had to spend half an hour scraping epoxy off prior to switching out the chips. 
Lame…
@Toodles - yeah, I could probably get the stuff running in Wine (I have Crossover Office here…just about all Windows software works, but I avoid it as it’s a pain to set up the first time)
The more I think about it, the more I think that OR gate will help a lot with DC support. I can’t count on it to always switch the dropping clock line; there are interupt commands it sends by holding one line low and pulsing the other high a low repeatedly.
Does anyone know of any kind of logic gate (or a chip using multiples of the same gate, but only needing one chip for our needs) that will change the output on the falling edge of either of two inputs? Perferably either toggling the state (from high to low, or low to high) so that each change happens when one of the lines is dropped. I guess the truth table would look something like this:
(X = Don't Care)
Input 1 Input 2 Output
_/---- X No Change
---\__ X !O (opposite of what O was before the change)
X _/---- No Change
X ---\__ !O (opposite of what O was before the change)
Or maybe that would pull the output line high (or low, I can check either way) when one of the inputs goes low, and then changes the line back to normal when either of the lines goes high (since there will always be at least one line going high before the next ‘clock’ tick)
Input 1 Input 2 Output
---\___ X H
___/--- X L
X ---\___ H
X ___/--- L
It’s a longshot, but if any EE guys have any ideas on how to make something like the above, please let me know.
The racing gear just got in. I’ll be checking the thread prolly once a day, but won’t be able to do additional work on the UPCB until this is done. I will make a thread in the Trading outlet when the kit parts come in.
If anyone wants to help, I could certainly use contructive criticism on the two Instructables currently up. Grammar, typos, anything that doesn’t make sense that you feel could use more explanation. I’d like to have it be as complete as humanly possible, while staying on topic (so no How to Solder, or What’s a PIC Programmer type info) just with the assembly of a UPCB or UPCB console cable.
So I popped open a couple of my other adapters…One had a EM78P447SBP in it, with another chip epoxied. The other had both of it’s chips epoxied. The third, however, had nothing covered. It is using a PIC16C57C, with a 20Mhz crystal next to it. The schematic wouldn’t be too hard to discern, and I suppose the chip is readable (if I had a programmer). Hopefully this can lead us to an easy DC solution.
I’ll take a closer look at your question. Seems that the first can be designed with a feedback circuit. The 2nd seems quite easy, perhaps that OR gate you were talking about.
DC code you will be ours!!
PIC16C57C sounds like the one in the Innovation I mentioned. Did it have any other parts between the DC data lines and the PIC? Cuz I know the UPCB PIC is faster.
If you have a way of trying ot read the code on that PIC, please do. All of my programmers use serial, and that chip has to use a parallel method of programming like the PICkit 2 uses. There is a very good chance the code is protected, so we’d prolly be up a creek even if you have the hardware to read it.
Oh, and I realized the secondtruth table I put up wont work. If the DC sends 10, there will be no low to high transistion between bits.
If we can:
- Make a clock circuit that goes from low to high when either of the data lines goes low, and holds itself high for 1-3us before falling back down to low.
- Make an OR gate that will only change state when either of the data lines goes low, and holds the output at that value until the next time one of the lines goes low.
Then BAM, we have a way to read the incoming data via the SPI. The output of 1 would be used for the clock line, the output of 2 would be the serial data in line (that’s why the special OR gate; so we know the value is legit, even though we’d be reading it on the falling edge of the clock 1-3us after the clock went high) We’d still have to bitbang the writing to the data lines , but that’s much much much easier and less error prone than reading the incoming data.
!@#$!#$%! The student edition of C18 expired recently. It still works, but loses some of the optimizations. No optimizations means that the bootloader code extends past 0x800 and causes it to break. I actually had to program the hex from the last release just to get a good bootloader. Damnit, I’m gonna start write protecting that bootloader area for safety’s sake. Don’t worry, none of these means a damn thing to anyone, I’m just venting.
First post updated, version 1.2 released. Changes are:
-All USB code consoladated (sp?) into usbtemplate.c and usbtemplate.h. This should make adding other USB devices side by side a bit easier than fishing through too many files that go 4 subdirectories deep.
- usbtemplate.h includes the needed pinout information for making the different USB cables.
- Added support for EJP/Jaguar and 3DO. Both are untested.
- Added a config.h to hold the different selectable configuration options, like LEDs and buttons on the unused lines.
- Changed the HID descriptor back to the Radio Shack converter. Now works on PS3.
Last update for a bit while I work on another project. I’ll update when the boards and kits are in. When the other project is through, first thing is fixing the PS2 code.
I’m puzzled. (Understand you’re talking to a network engineer, and sometimes perl coder here, bear with me…)
I was of the impression that the DC’s maple bus was a well-documented beast. Am I wrong about this? I have an off-brand DC controller here I can pop open to see if there’s anything useful about it, but I’m a bit suprised that a controller that doesn’t have analog buttons such as the DC would be so difficult. Last I looked, all of the buttons on my controller hit to a common ground, are simple digital gates, and hit back to an IC (or is the IC in question the major problem here…?)
(Went ahead and opened up the controller…it’s a first-gen mad-catz controller, 6 face buttons, Z/C which are just L/R rewired.)
It has a single IC, Xilinx XC9572. Has some other numbers on it:
PC44AEM9917
F1083247A
15C
Just at a glance, the buttons do share common ground. The chips appears to be an FPGA:
Manu Part # Description DigiKey Part # Price Each
U1 XC9572-15PC44C Xilinx CPLD 122-1171-ND $5.35
In case it becomes pertinent at some point, you can make a programming cable for the FPGA chips:
http://toolbox.xilinx.com/docsan/2_1i/data/common/hug/fig13.htm
Another potentially useful link:
EE & perl programer here as well The problem with the Maple bus is twofold:
- The speed at which it handles data, on the order of 2mhz, and
- The method it deals with data, using an alternating clock scheme.
Both are by no means unsurmountable, just will take time and perhaps creativity with the given hardware. Knowledge of how the DC handles certain situations would also be nice. If we were just sending data, that would improve our situation, but we also need to read data from the DC as well, in order to follow the functions it asks. Fun stuff
Vidness explained it well. How the maple bus works is well documented, but it is still a complicated protocol running at very fast speed. Hell, I’ve stick got an incomplete PS2 code, which is a simple protocol running at 1/4 the speed. But the source code to UPCB is open, so I encourage everyone and anyone to give it a shot. It’s just C code, and a quick look at any system already in there should give you an idea of how things work. I dont care how it’s done, as long as it works. I just think a little bit of glue logic, hopefully small enough to fit in a Dsub-15 hood, would make the process a whole bunch easier and more reliable. I’d love to learn to play with FPGA’s down the road, but they are outside of my ability for the moment, and I have never seen a through-hole FPGA, only surface mount. Using the PIC meant assembling would be fairly easy, even if the only soldering you’ve ever done was tinning speaker cables. It also allowed me to reuse the bootloader code and USB code that was already provided by Microchip.
Heh, long time Perl coder here, too. Make sure to download the code so you can see it without the word wrapping.
http://www.perlmonks.org/?node_id=118799
Ya know, if someone DID manage to pull the code from that FPGA, and they’re still available to purchase like Numbski said, then making a daughterboard specifically for it would be very doable. Instead of the IDC header in the DC Connector part of the UPCB, just put in a standard 2 row header. Make the daughterboard with optional VMU connector (the vmu connector would have to come from a sacrifice VMU or puru puru pack, but would be optional), a place for the fpga and any components it needed, and have it connect straight to the headers like the old Xbox mod chips that connected straight onto pins soldered to the LPC bus did. Hmmmm.
Any FPGA guru’s in the house?
Oh shit son, am I reading this right? Someone wanna help me wrap my head around this? Page 16 of 76 in the maple bus (page 17 of the pdf), Fig. 28 and 29.
http://boob.co.uk/docs/MaplePatent.pdf
If I’m reading that right, that’s a one chip, (two chip tops) method of converting DC to parallel, 8 bits at a time. Damnit, and none of the pins for the parallel function of the PIC are on the output pins. There are other small schematics for detecting the start pattern/start crc pattern/end pattern crap, too. Man, i gotta try to hunt down a shift register that’ll match that waveform. If that one shift register does what I seriously think it’s doing, that’s the hard part. Filling in all of the details of the communication would be time consuming as all fuck, but itd be POSSIBLE ffs.
Edit: The 4015 chips like the 74HC4015 look perfect, except they mark the clock by the transition from low to high, and we need the other direction. I suppose I could use a single inverter chip to invert the two lines going in and the one line going out…hmmmm
Great work man, you are working FAST! I read the post from the beginning, and it sounds like it’s going great. The PCB you had custom made looks awesome. I wish I knew enough about programming to help with something… I will definitely want one of these when you have all the kinks worked out.