Ps3 rapid fire studying and understanding project open source

[geraldrubalcava]

EDIT:  this thread might start to die,(but work from hyper and others might still be in progress here) but i just want to recap. Throughout this forum, alot of people put in hard work and if you wish to see the progress then feel free.

overall, Hyper999 manged to complete code and make the first version of it. You can find it on its onwn thread at
https://www.acidmods.com/forum/index.php/topic,37606.0.html

also, RDC made a code with 5 modes, its further down the thread. so there is a lot of work that got done here. and if you are interested in making your own code feel free to look though this thread. you will probably find all the info you need.

Thank you, all of you. and hope to see code flourish from here.

[sikkwidditt]

i know for fact that the rapid fire kit for ps3 , used a lot of voltage thats why the battery charge drain so quickly!

[geraldrubalcava]

ohh well yess that article is also good info. but i found out another in hackaday.com it was a wile but they tested out the micro chips vulnerability for brute hacking.  well if anyone has c knowledge or know how to code then ur welcome to help. well yes the 12f683 takers up alot of juce. and you drain alot of the battery. again it only drains it when the controller is on tho. the way the power is wired it only uses the electricity that comes from the analog sticks and they are not always on.

[Hazer]

IF the PIC is draining the battery, somethings wired wrong. They take less current to power the processor than the controller draws when its 'off'.

Lets get some better knowledge in here:

First, stop talking anything about the x360 controllers. There is no similarity.

Now here is some more useful info:

There are 3 commons driving all of the buttons, and they are all analog. The sticks are typical X-Y potentiometer style (I say style because they are not actual potentiometers, but newer technology with less mechaincal parts to wear out, but they still function the same electrically).

So, the shoulder buttons act the same as all of the other buttons. They are pressure sensitive. They are analog. They share common lines. But these common lines are not the same as any other controller before. For instance, matrixed controllers have 'shared' lines where there are outputs and inputs. Example: The X360 has 4 outputs that go to every button, and the other side goes to 4 inputs. The controller sequences each output to a low state in turn, and looks at the 4 inputs connected to the other side of that output.

The PS3 is much different, as by this picture provided by RDC:


The common here is not wired like everyone thinks it is. There are 6 lines that run to the buttons (which change resistance with pressure) and then they all run back to the one common. The above picture shows the waveform on the common line. What is not shown is that if you look at the waveform for R2, its the same signal except the first dip there goes all the way to 0 volts. This waveform does not change when you press the R2 button. Thats becuase contrary to the way most controllers are matrixed, the 6 liens are all outputs, and the one common line is an analog input. These 6 output lines are normally tri-stated (and held high by the common line) and only output a low signal as according to the picture above. In this way, the controllers will can use that short period of time to do an ADC conversion for all 6 buttons in sequence. .

So what does this mean? Well, the first 'dipp' in voltage tells us when the controller is actually looking at the first button press. We can piggy off the common line and see this to determine what to do next. The second neat thing is we can force the either A) a button press signal without pressing the button, or B) force the 'released' voltage state (ie-force it back high) when the button is pressed. In otherwords, you can have rapidfire on the button. This means you can rapidfire every single button on the controller, with just 3 lines. You do not neeed highly accurate timing logic like the opensource either. You just have to keep monitoring the common line for that first drop in voltage to start your logic. From there, you can count these waveforms to set your 'fire rates'. You can bet your ass that each waveform is the controllers update rate. The entire waveform is pretty structured, meaning you can time out the 500 microsecond pulses for each button with simple routines and finish by making the PIC wait for the next initial voltage dip.. My only caution is use a 1-5K Ohm resistor in sseraies with the common line, as forcing the common high or low during these times could end up with alot of current and drain the batteries faster than expected.
So, I hope that this helps those people with enough knowledge to start thier own opensource code. I wont be playing with this anytime soon. And if I did, I would probably make the first SUB flashable and USB macro programmable version instead of a 8 pin mod anyway.

Good luck.

[geraldrubalcava]

wow! great input Hazer. also i did further studying. with my oscilloscope  i got the same reading and i was wondering about that beginning wave for R2, thank you for clearing that up. i also put the "R1 chips" under the probe and to my surprise this just keeps sending the release for R1 only.  this also goes exactly how u said.  well this is the biggest knowledge i found out. thank you so much .

so now ima try to do what you said. with a arduino (hopefully this works) ima look for that voltage drop 0v then set a pwm or I/O pin to high for 100 ms then low 100 ms then high .. for 500 ms in total then scan for voltege drop agan?? well my question is does the hole pulse (all 6 buttons) last 500 ms or just one? well its at least simple enough that only 3 wires are needed vcc grd and signal for common.

[hyper999]

im going to guess each one is 500us and am just starting to modify bmu 3 to work with ps3 however im going to just make it one mode for now however i do not have a spare ps3 controller i can test on atm so i will need someone else to test it for me
************************************************
Update im in a abit of a lazy mood this evening so i have written a code but it is very simmple
a 12f683 is needed power and ground should be connected as normal then connect the common on the controller to gp1
however this is a no where near final code as it may not work, only has 1 mode, is set at like 1sps and cannot be turned off but i need somone to test it to see if i am heading in the right direction

*************************************************
UPDATE 2
ok i do not know how to attatch files so if you are able to test reply on here and i will email the hex file to you 

[geraldrubalcava]

hyper999, great! if your able to port that code for the ps3 i would be gladly test it out. is if for the 12f683 or 12f629? ether one i have them and i have a controller on standby to test so shoot away.  also how much will the speed for the mode will be? well great1 if this succeeds you just created the first open source R1 rapid fire for ps3.

[hyper999]

oops just realised ive been staring at the attatch butoon for like 10mins DUH!

[geraldrubalcava]

all right well hyper999 u rock! ima test them out with cod6 mw2. il have to get back to u tomorrow because i have to solder in socket for quick debugging or re flashing. all right i will program a 12f683  and connect it. witch pin in the chip is set to output? pin 3? well thank you. also if we can get Hazer to input a method for showing when mode is on or off. but of course this is for the future lol i believe this is the first time it has bin done. so thank you Hazer and hyper999.

[Hazer]

Some info you may not be looking at: That above waveform with the 6 dips in it happens every 10 milliseconds (or a frequency of 100 Hz). So the waveform repeats like this:

500 usec for R2
500 usec for R1
500 usec for triamngle
500 usec for circle
500 usec for X
500 usec for square
7 msec of nothing till the next repeat

If you try to hold the common high for anything longer than 500 microseconds during the first dip, you will mess up the other buttons as well. The trick is to use the very first dip for R2 as the start, and then manipulate the signal for each 500 microsecond period for each button. Once your done manipulating each button, have the PIC sit and wait for the next R2 start.

Since this waveform repeats 100 times per second, you set the frequency of your rapidfire by simply using a counter for every waveform. For example, your rapidfire would count down once every waveform for 50 times, and then begin forcing the output high only during the R2 signal for another 50 waveforms by reseting that counter. Once you have force the waveform high for 50 counts, reset the counter again and stop forcing the R2 signal high. After another 50 coutns go by, begin forcing the R2 signal high again. This would give you a repeating signal on the R2 line at a rate of 10 times per second.

Its much easier than using any timing the BMU or flex uses.

[hyper999]

you need pin 6 and if this works then i will neaten up the code and add modes and leds etc.
also when testing the code hold down r1 and see if it fires multiple shots but it will be very slow and be sure to chech all other r common buttons do not rapid fire (especially /\ )

EDIT:
@Hazer yh i realised that just as i started so in the end i wrote the code pretty much from scrap thats why i didnt get as much done as i thought i would but thanks anyway for all the information

[geraldrubalcava]

all right im also going to try to code this on a arduino. because is easier ide for me. but hyper999 keep going on the code. i will love to support it. but don't know the language quite well to make a descent rapid fire. i will still make a accessible adapter for the controller to test out and reflash when update the code to debugg.

Hazer, if your making a easy reprogrammable try using somthing like a attiny 2313. if you make the code correctly you can add a usb mode in order to make a ealy and user friendly reprogrammable controller. or a arduino? all u would need is to have the boot-loader run the program within 4 sec or something so that it can have a 4 sec wait to be programed and all you would have to connect is the Tx singal and ground. this would even be able to do a stealth mod. being able to change though the usb port . just a suggestion. lol well thank you for your input. i am going to try writing code with the info you have me. but im still looking foward for hyper999.

thank you again for your info guys. and yes i will check the triangle see if it dont rapidfire too.

[hyper999]

ok ive worked on the code this one is more acurate, efficient, and neater so should work better however im still yet to add modes on and off etc but i will add these when i know this works. this needs rightcommon to be connected to pin7 of the ic and should fire about 10sps when r1 is pressed

p.s i have included the asm file this time
Post Merge: August 21, 2010, 01:03:06 PMsorry for the double post but i couldnt add the attatchments and turns out i cannot atatch asm files

[geraldrubalcava]

well at this moment im re soldering the chip socket to pin 7. but previews code was successful. unfortunate i forgot to test the /\ but this time ima test ur new code.

[hyper999]

ok awesome how long will that takeyou?

[geraldrubalcava]

closing up the controller and getting chip programed! lol il get back to you in 15 min xD


edit: it did not work :/ ima try it with a diferent controller and a diferent chip. :/

[hyper999]

if you could, could you retry the first code see if only r1 is rapid fire and also try if any buttons are rapid fired with the second code

[geraldrubalcava]

all right i tried the first code. but i discovered that last time it worked it was just a short and some bad sodering. so the code dosnt work. :/ no other buttons rapidfire. i am going to try the second code with my new controller see how it goes but any suggestions why it might not work? can Hazer review the code to atleat to see if hyper999 is heading in the right detection?

edit: the first code does seem to trigger the controller to do certain things. but it don't activate then r1 is pressed. all the buttons seem to press themselves at random times. it might be actualy working. but the timming might be off thats why its being set of randomly

the second code dosnt seem  do anything. u sure its pin 7?it dosnt work at all. so the first one seems to have something going. but i would still want to see if Hazer can see if were heading in the right derection

[hyper999]

sorry should have double checked the code
should work now and still use pin 7
Post Merge: August 22, 2010, 06:02:35 AMok here is the source file as a txt file if anyone wants to look over it

[geraldrubalcava]

all right. o tired the code and now seems to behave like the previews code. is does random presses on the r1. not quite sure if its the timing. because when i pres the button lightly its sometimes shoots twice. and in other times is starts shooting quite fast 1o sots per second or something. i would really like for Hazer to give a little input. Because he seems to know show we should start off.

i will add a video soon if you wish to see the results.

[hyper999]

ok sso not really going well then lol i hope to get my hands on a cod game for my ps3 soon so i can test myself and speed up the process but untill then try this code it wont rapid fire but it should prevent you from pressing r1 so i need you to test if it does and if all the other buttons still work (btw use pin7 again aswell)
sounds kinda pointless but it will help me guage where im going wrong

edit oh yh and hazer i would really appreciate it if you looked over the source code from the previous post as im sure you will be able to see where im going wrong

[geraldrubalcava]

all right i get it. it wont rapid fire but this is to check if its going the right way. also thnks for the pin 7 lol so i wont open up the controller again. well yes i hope he looks over the code. he apparently knows how to do it but hasn't made one. so were just asking for some help. well i will add the youtube link once i find my camera. lol well you have a ps3 as well? awsome! well mw2, a call of duty title dont have any patches that i know of that block fast rapidfire so there shouldn't be a limit in speed. but you can get other cod tittles for 25-30 bucks. currently own cod5-6

Edit: new code dosnt work. :/ dam! it kept firing form R1. :/ any thoughts Hazer? ahh. well i dubble checked my connections and are all ok. in the previews code did something but this code  don't anything. well keep at it! we may have something but work is needed.

testing ps3 opensource disable test

[hyper999]

Ok im running out of things to try :S so can you confirm what the voltage is on the rcommon line during the r1 pulse is when pressed/ unpressed please?

[802Chives]

hyper999, I looked over your code and it looks like you are conceptualy almost there...  I have a few suggestions:

You should start an interupt on the falling edge of R2 and then simply delay 500uS and then provide your positve signal for 500uS and then go back to tri state and reset the interupt.  that will impede your signal as it looks like you are trying to do.  Add a couple of counters and you should be able to toggle your impeded signal on an off on a 10mS interupt cycle.


You may not be able to read R2's signal as a digital low in your current code and hence you may be having issues with your code.  If you can accurately tell when R2 starts you will be able to control all 6 of the buttons easily.

Hint: there are a couple of simple solutions, the least simple but most elegant, would be a comparator interupt triggered by the portion of the R2 signal that hangs lower then the rest.

[geraldrubalcava]

true maybe the begining of the R2 delay is off.

yes i will do that. and if we had some guidance of Hazer or any other coder we would of probably get this off the ground. i will also upload a vid hot the 1.1 code randomly shoots. If anything you think i can email different people in here with your code to see if someone can give some feedback? hopeful one can just correct it then once started we can finally debug features the code.

Edit: if the code cant read R2  as a digital low try programing one that can and to test it out make pin 3 like output to a led to visually see if it actually seeing that droop. if so were in the right direction. then prefort the interupts see if the controller then response with a disable code for R1. or any way easiest way to tell that your code is working. thanks for your time dude

[802Chives]

ding ding ding!   If it doesnt trigger the LED you will know you need to approach it differently.  If that is the case then probe around with your O-scope and Im sure you can find something you could use

[Modded Matt]

and if we had some guidance of Hazer or any other coder we would of probably get this off the ground.

Chives does this for a living, dont be so hung up on hazer and take the profesional advice that is front of you.

(no offence to Hazer of course, god knows he taught me a thing or two...but then again so has chives.)

[Hazer]

Sorry guys. I am very busy right now. Even if I look at the code, it means nothing until I setup the hardware, and I dont have time right now. I dont even have a PS3, just a dualshock that I run through the USB line to my comp.

Chives is hinting at the fact that the R2 line goes all the way to ground, and would be a great place to trigger the logic. You can grab your digital low there on a seperate pin. I have been avoiding that due to the new controllers that force you to use vias, so the best solution is to make your code work with just the common lines.

This brings us to Matts suggestion: The comparator. Setup the comparator with internal reference which can be software set. Once the comparator sees the first dip, change the pin to an input and wait out the R2 signal. Force the R1 signal high and decrement a 50-count counter. Change back to an input and wait out the rest of the signals. Then setup the comparator again and wait for the hardware interupt.

When your 50-count counter reaches zero, reset it but then stop forcing the R1 signal high. Once hte counter zeros out again, begin forcing R1 high again, etc etc.

Another option (dont like) is using the analog ADC. The response should be fast enough to get a decent ADC result and still manipulate the R2 signal if need be, but I have always found the quality of the internal ADC to be rather glitchy.

[hyper999]

ok thanks for all your inputs guys ive written a code to test with an led as gerald and chives suggested if this fails we will have to move on to using comparators. but anyway with this code connect pin 7 to common as usual and pin 6 to the positive lead of an led then as soon as the controller turns on the led should turn on for 8ms every time it detects the r2 pulse i have also included the source as a text file again

[geraldrubalcava]

all right. thank you 802chivas honestly its true alot of people here are great here including modded matt, 802chivas, hazer hyper999 and many others. that's what a community is. well the only reason why i kept hope on hazer because he seemed to know how to do it. im going to test this code within an hour and il make a vid.

Edit: ok well apparently the led doesn't light up. i checked the polarities twice but no go. so i guess the problem was the initial dip of R2. well i guess you will have to use comparators :/

FILE0123