Good find!! It does look like it each shift register is responsible for every other bit. The bottom one takes the 0-bit, then they switch and the top one takes bit-1, etc, until all 8 bits are accounted for. This is the type of thing I was suggesting earlier (option #2 on my May 30 post). I have an all-day convention today, but I will definitely devote some time to this over the weekend.
I don’t quite follow how a transition of high to low for a data change won’t trigger an accidental data pull on the ‘off’ register…perhaps there is an ‘enable’ on the shift register that is synchronized to a 2mhz clock? Still, I can definitely see this working…
PS2 is fixed. From what I can tell, the bootloader was using one set of configuration bits, while the main program uses its own. I made the hex file using the bootloader’s config, which I gather is just too slow to keep up with the PS2, but barely enough to keep up with the PSX mode (controller clock is 250KHz in PSX mode, and 500KHz in PS2 mode). I may just hunt down the bootloader config, but for now, I’ll just leave the config bits in the main program and tell the bootload program to use the new config instead. I’ll update the zip package to 1.2 as soon as I get a few old school consoles supported, especially Saturn, and hopefully a tested PS3 USB.
Just stumbled across your UPCB project… Absolutely amazing! I’ve been using a dsPic30F6040A to so a PS2 controller to console interface among other things. But frustratingly getting stuck on emulating a PS2 controller (analog red mode) while pumping out seemly appropriate bit pattern responses on the SPI to the console. Specifically the console is not switching its clock freq from 250KhZ to 500kHz to engage the PS2 controller mode.
You mentioned both a SPI and bit banging approach. The SPI seem the more elegant of the two (utilizing existing on-chip modules)…
I would like to request some advice on how you got it to work and perhaps your latest code. This means I could port it to the dsPIC30 development board and assist in some that aspect of the PS2 testing as well as getting me out of a deep hole… Hope you can help!
Hell I can answer that. The first one has the serial input connected to A, and Clock connected to B. Second one has the serial input connected to B, and Clock connected to A. The idea behind the shift registers is that each one of the lines, will go up and then down, every 1MHz. It may go up immediately after it went down, or just before it goes down again, but it will go down every 1us, and go up sometime between each drop. Look at the waveforms on that page by itself. However I can’t seem to find chips that act when the clock drops, only when it rises. Unless Im completely off my rocket when reading them.
So, let’s see. An inverter to swap the two lines so the shift register shifts at the right time. A counter (that has an enable and reset line) set to count the number of rising edges that will set or drop a line when it gets to 4 (to tell the uC to read the 8 parallel bits when the 4th bit has been latched). And the counter flip/flop setup in the pdf to tell use when we get a valid start frame/start crc frame/end frame data, so we can reset and enable the counter. uC waits until one of the start frame command pins drops. When it does, the counter is reset. When the counter pin shows the 4th bit has been read, uC reads all 8 bits at once, stashes it in a buffer and resets the counter. Repeat until an end frame pulse is found or an error pulse if found.
I think that’d make you able to read the data from the DC, even on a 2MHz uC. There’s still sending to deal with, but it looks like the pdf answers most of that except for how to make the CLKA, shift CLKA, CLKB, and shift CLKB lines.
I am starting to think that doing this will require either a bunch of logic and a separate microcontroller on a daughterboard connected to the DC Connector port, or a single CPLD in the Dsub hood. Maybe I’m gonna have to leard vhdl or verilog…
Does anyone know: Does the DC controller have to package the data it sends to the DC in the ‘start frame’ and ‘end frame’ pulses, too? And how does the DC controller figure out which port it’s pluged into?
When I was looking for information to see if others have done something similar, I came across a post from a guy complaining of the same problem. He mentioned briefly that he did get xbox working via a uC though. If you’re that guy, PLEASE get ahold of me about how you did the xbox!
The post complained that he could get it working as the dualshock 1, but his post indicated that the PS2 somehow was identifying the dualshock 2 controllers immediately and instantly kicked the clock up to 500KHz. If that is true, then I do not know how it is identifying the controller so quickly. It would make sense that the bus would start at 250Khz, run a couple of commands to the controller to identify its capabilities (Commands for querying and setting modes: http://lynxmotion.com/images/files/ps2cmd01.txt ) and then kick it up to 500KHz once it has comfirmed the controller supports it. This is what would make sense, but either that poster wasnt aware of those commands, or the ps2 is using some other method of checking to see if the controller supports 500KHz.
I agree that SPI is the best way to do this and that is how it is currently implemented. The code I’m using is only trying to emulate a digital PSX controller, and has no support currently for anything else, or for any commands other than the 0x42 status command. You’re free to take a peek at it; it’s in psx.h and psx.c in the archive, linked in the first post of the thread. Its written for C18, but if you want the disassembly for those functions instead, I can easily send them to you. But to be honest, it sounds like you may be farther supporting it than I am. Any input you may have would be appreciated, and I’d love to see the code you’re using as well. If you have the ability, via Oscope or any kind of snooping, you should check the clock line on the legit dual shock 2 when it is first plugged in. If the clock immediately starts at 500KHz, then I don’t know how it’s identifying that the controller supports it. If it starts at 250KHz, and then later changes to 500KHz, then you can bet that the PS2 is querying the controller, and changing the clock when it gets the response that the controller supports it.
On a PS2 with PS2 games, the controller code is not properly working in the P1 slot, but works fine in P2. If I could take a peek at your code as well, maybe I can resolve that problem.
Not a guru, but the programming cable can be made. I’m presuming one can read from an fpga as well as write using the same cable…or I would hope anyway. If that’s the case, what needs to happen is I sacrifice my controller, get an fpga socket, and solder it to the programming cable. The issue is that the solder points for the socket will be TINY. Unless there’s a hold-through version that I can put it into a little piece of breadboard…in that case I have some chip-off around here someplace from way back when. If I can find it, use that to remove the fpga chip (it’s a surface-mount chip version rather than socketed), and drop it into the socket.
If that logic doesn’t carry, I guess I could always leave the chip on the board, and solder the programming cable directly to the controller at nearby solder points. Might be easier to do at the end of the day too.
>>It appears that most FPGA’s are programmed with a serial eeprom.
I have closed my controller up now, but I don’t recall seeing an eeprom on the controller. I’ll look again later. If that’s the case, then what we need is an eeprom reader, and then figure out how this thing fires up. You’d have two chips, eeprom and fpga, and that’d be about it. If you could fidget the eeprom code into your existing chips, then your design goes up by 1 chip, nothing more.
Your first question: No, I’m not the same guy so unable to help with the XBox issues.
Fortunately, I have access to a scope and can see the hand-shaking taking place when a legit PS2 controller is plugged into the PS2 console. The clock starts at 250kHz and a complex hand-shaking procedures follows which eventually cumulates in the console deciding that the controller can support 500kHz. It has not been possible to decipher the procedure yet, since it takes place over many frames. I can only the trigger the scope on one frame at a time. Effectively, my efforts are comparable to yours on this narrow PS2 controller topic. I am in pursuit of a possible solution and will send you the outcome (and relevant code) of my investigation as when I get them in the next few days… Magnificent effort on your part in the UPCB!
Numski, I think usually development FPGA’s use eeproms to hold the code, which is loaded when the FPGA boots. It looks like that CPLD holds the code itself internally. I dont know i it can be READ, but they can be programmed. I doubt highly there is a separate EEPROM on that controller.
Damn, it was a longshot with the xbox, but had to ask. Knowing that clock speeds up after handshaking is a huge help tho. The commands in that txt file I linked to should be the ones that tell the PS2 that its a dual shock 2, and then ps2 tells it to enter dual shock 2 native mode. Controller responds with a successfull response, and the ps2 kicks up the clock. It makes sense and sounds like ‘The Right Way’.
Dont worry about the trigger on the oscope keeping you from seeing the response, put the PIC to work. attached the SPI pins to the CMD, CLK, and ATT lines with a dual shock 2 plugged in. Make an array in RAM of unsigned bytes egual in size to the EEPROM, setup SPI, and have it just record each byte to RAM, and when its full, write it to the eeprom. Remove when its done and hook it up to your programer to read the eeprom. Do it twice if you need to, one to see what the ps2 sends, and another to see what the dualshock 2 says (DATA line instead of CMD). Youll know once you start seeing the 0x42 status query commands over and over that the speed has been adjusted. You should be able to match what the ps2 sends to what is in the text file I linked. Just remember the ps2 sends LSB first, while the SPI module is MSB first.
Excellent idea! I’m doing something similar (write to an array) to debug code. There is a feature ion the MPLAB IDE V7.52 in tools/‘Data monitor and interface’ which can display your array data graphically. Its almost real-time display (after stopping the processor execution and much better than a kick in the nuts when it comes to debugging. You can also download the array data from the watch window too without having to read it off using a programmer (to save you some steps). It may be because I’m using a mega PIC, but these features are all part of the standard IDE. Fantastic piece of SW considering it free.
I’ve got the luxury of lots spare ram (16K) and would suggest that while you are developing to take the view of using a much better processor than the one you will finally implement ?(but in the same family) . The development task is hard enough without having to worry about HW constraints!
LSB and MSB first. Fallen in that one already! Nice to know it wasn’t just me having a ga-ga moment :)…
Apparently I didn’t get time to work on anything this weekend But anyhoo, a side question for ya, Toodles. By chance have you compared response times between various joysticks? I would be curious to know the time difference between pressing a button and signals sent to the console. In the interim while the pcb is coming along, it would be nice to know which joysticks are the fastest in getting data to the console.
That’s all it supports yet. Eventually there will be code for emulating DS1 and DS2’s, but for now it only has code for the original digital PSX pad.
A lot of the consoles use a banking system, where the console sets a pin or pins to high or low, and then reads the other pins to see which directions or buttons in that bank are pressed. There’s no way of knowing how long until the console reads these pins, so I can’t answer for those definitively. But I can tell you that when there is a change in either your buttons/directions or the bank select pins, it takes around 2us for the output pins to change to match. TWO MICROSECONDS. That’s 1/500th of a single frame. The most advanced of these bank select systems are the Saturn and Neogeo, both of which wait much longer that 2us after changing the bank select pins before reading their status.
Some systems, like the NES and SNES, actually have LESS lag than their original counterparts. The NES and SNES UPCB modules check the status of the buttons as they’re being sent, while the original one locked in the status of every button and direction at the beginning of the transmission.
All of the rest send the data immediately as directed by the console. The only way there could be lag there is if the communication was interupted somehow.
I am making this with an eye on making sure it as lag free as humanly possible.
It’s on the ToDo list, but it is WAY down on the priority list unless someone can give me a good reason it is needed.
Numbski, thanks for pointing out the CPLD on your controller. I am expecting I will end up going that route when I get back to working on the UPCB. I’ll be making that JTAG cable and trying to make an interface that converts the DC into a SPI compatible format. Although it sounds like your controller does all of the implementation on the CPLD, I don’t think I’ll be quite going that route, at least at first. Converting it to SPI still leaves the processing and interpretation up to the PIC, and would allow me to answer some of the questions I still have about the maple bus. If you can get the code off of that CPLD (there is code protection available on that chip), then please let me know. I’m hoping that I can make a decent maple->SPI interface in a CPLD small enough that I can fit into a DB-15 hood, maybe even with connection pins for attaching a vmu. Otherwise, I’ll have to make a daughterboard to connect to the DC Connector spot and fully implement all of the DC stuff on the daughterboard; requiring another PIC, or lots of time to fully implement the DC in the CPLD.
Sadly, all of this will have to wait until the current racing project is done. But it is fun brain candy to read up on until then.
Still waiting for the damn shipment of kit parts to arrive. As soon as they get here, I’ll assemble one to verify all of the parts are correct and working, and likely put the assembled one up on ebay with a starting price of the kit; let the market decide what the cost of an assembled UPCB should be. The unassembled kits and bare pcb’s will be be sold here in a trading outlet thread.
One thing I wanted to do after I got my scope was to use one input connected to a pushbutton and the other on the serial line going to the console. That way I could measure the delay between button-press and transmit. Just wanted to get an idea of the delay in certain types of joysticks out there…
I ran out of wire so my racing project got an early reprieve tonight. Release early, release often.
Release 1.3 is up with the following changes:
PSX and PS2 are FULLY working! Testing in both player ports in CvS2, MvC2, Tekken Tag, and VF4:Evo, works beautifully. I changed the code to keep a closer eye on the ATT line, and it seems to have done the trick.
Extra button option is used in the USB (PC and PS3) code as the L1 and L2 equivalents, Saturn code as L and R, PSX code as L1 and L2.
Now that PSX/PS2 is working solid, I feel a lot better about this project. Now, I can say without reservation this is the PCB you want in your stick. I know it’s the one I want in my stick, and it’s only gonna get better.
i didnt notice it being mentioned earlier in the thread so forgive me if its been stated. but how big is the pcb? cuz if i can get a 360, ps2, ps3 support off one pcb… that is just way too good.
oh yeah, when i get back from running evo north, i might holla at ya about that pcb to wire up a p360 to xb360
