Ps3 rapid fire studying and understanding project open source

[geraldrubalcava]

so if i get it right the L2 drop are followed by the same button set up like Rcom? like L2 then L1 etc.

Modder matt. i agree that waw is a awesome game. But what appeal to me mostly was National Socialist Zombies lol. well i do believe you in the respect of, if configured correctly they can shoot faster. i guess i havent had a proper configure to make the gun shot faster. but RDC code shoot faster then anything from ebay so i believe its a awesome code. hum The new cod game Black Ops by treyarch might have a patch like that too. But they might not have gun limits of there are semi-auto like mw2. Its because the game engine on COD:4 and 5 use Infinity award 4.0 engine. And i believe that the new game might be using a enhanced version of it. They cant use the mw2 5.0 engine because they had that agreement in the contract with Actvision.

Sorry to get off track, as for  a product similar to instafire, it would be great! and can bec ontrolled with few wires. But it all depends on hyper or RDC if they wish to take it upon themselves

hey hyper if you wish for me to test out your code i still can. but i dint have a oscpe fast enough i guess. can you write up the same code just disabling the R1? Im not quite sure if you can do this but thanks!

[rafaliyo86]

Hey guys

First i want to congratulate you for your job. You are doing a excellent job!! I would like to help you. I dont know nothing about code writting but if you always use the same wiring i would like to do a controller to test the code. I mean something like this:

https://www.acidmods.com/forum/index.php/topic,37459.msg280518.html#msg280518

RDC can you say me wich is the best code now??

Thanks

[RDC]

My code will never be 'finished', I might get sick of it and quit working on it, but I'll never be finished with it. Burst fire and L1 firing might be all I'll add to this as it's become more like a job now than something to just figure out, and I still don't have games to really test it on, which slows things down as well.


@ geraldrubalcava  - The COM1 line is Up, Right, Down, Left, L2, L1, with the L2 being lower than the rest like R2 is on the COM2 line, but it's 'in time' with the COM2 line as 802Chives has mentioned earlier in this thread (see attached pic) so you don't really even need to read the COM1 line with the ADC as the timing from the reading of COM2 is the same, you just have to wait the correct amount of time and then drive the button Hi to mask it for a crude R/F on both L1 and R1. Likewise doing the face buttons and such is also doable this way, but not really the best way to go about it.


@ rafaliyo86 - As far as I know the only one posted in here at the moment that does anything is the last one I did, you can try it out if you like and I'm sure here before long hyper999 and others will have some up for testing as well. You'll have to at least be able to program the PIC 12F683 chip for testing any of these out also.

It's really hard for a coder to get feedback from multiple testers trying out multiple codes, so it's best to have a set person or group do it or for one coder and better still for them to have access to the games so they can get 'real time' feedback and make adjustments, but I'm more than glad to hear any and all feedback from anyone that wishes to try mine out. It's not even close to what I'd call complete, but it works.

Post #123 has the wiring of what pin on the PIC goes where for my code, and post #127 has the latest version of code that I've done. Now if you go and wire up the controller for my setup it may not work with someone elses code as they will most likely use different pins on the PIC, so you'll want to make it so you can swap the wiring around if need be. Naturally Vdd and Vss will be the same, but the other pins you'll need to be able to swap around if you wish to test out other setups, so don't go and install a socket directly on the controller as you aren't going to be able to change the wiring around easily that way if you have to.

[geraldrubalcava]

hum i see with com1. so it might not be difficult coding it for dual trigger. hum i understand that you dont have the game ether and you kinda feel like Rapidfire is not worth  making or putting time into. well in ebay im winning a cod:waw game so if i get it do you want it RDC? if it would help you out with the proses of debugging then awesome. hum well i believe that RDc already Got the basics of what this topic asked for?... alot of people got info and 3 people have made a successful rapidfire and hyper is getting there too

as for rafaliyo86, if you wire it directly to your controller in that way different coders will put it in different pins. although all use Com2 or Right common. they differ from person to person.

well RDC i might take up Basic to learn how you did your code. see if i can understand lol. I still believe you did a great job

[hyper999]

@matt kk thanks for the info and yes as soon as i can acuratley catch the first pulse on the com2 line it will be very easy to rapid fire any button on the controller and i will be implementing this feature in the final code

@RDC yeah i think ive got the best threshold level now so im gna fiddle with the timing tonight

@Gerald i recomend learning asm as its not as hard as it looks so here is how i learnt http://www.gooligum.com.au/tut_midrange.html and of course the 12f683 datasheet
also if you want a scope i highly recomned the dso nano its great only downside is that it is only single chanel
Post Merge: September 11, 2010, 07:14:22 AMMAJOR UPDATE!!!!!
think ive cracked it guys!!!! 
ok try this same as previous
pin7 - com2
pin5 - oscope

catches falling edge then makes pin5 high for ~4ms

[RDC]

Still looks glitchy here.

If you can, set it up to detect the falling edge, then as soon as it does have it wait 500us, set your output (GP2) Hi for 500us and then back to Lo or TriState, then wait 3ms and do it all over again.

That should give you a fairly steady output on GP2. Then after that I'd combine the Input and Output pins and see where it's actually putting the Hi pulse in the signal. Even then you still may need to play around with the values to get it just right, I had to use 380us and 490us instead of 500us, so it could be anything from those values up to 500us that will work best in your code.

Also, the whole 500us is academic, when doing the math that all works out just fine, and if we could get perfectly in time with it then it would work with that value, but real world doesn't play by the same rules so you'll have to mess around there to get it just right, or at least close enough so it works, and I imagine that's the only hang up you're having right now, something is just off by ~100us or so at most.


Can you post a pic of what the COM2 line looks like on that scope of yours?

[hyper999]

on my scope the frequency of com2 and the ouput from gp2 is 88hz and they both goto 100hz when on usb

edit: ok cant get a decent pic of the screen on my camera so gna see if i can work out the screenshot function
Post Merge: September 11, 2010, 05:01:37 PMok heres com2 unmodified on my scope

[RDC]

That looks pretty nice.

If they're both solid there then toss the output into the input mix and see where she lands on the scope.

[geraldrubalcava]

@ rafaliyo86 im going to atach a pdf of a mod ship i bought along time ago. is should help you install with the writing if you would like. this pdf is not mine! lol

well Im still undecided about Basic or Assembly code. but witch has more flexibly ? and/r has a smaller learning cure?

hum i wonder why does sony have a weird changing of frequencies when on usb or batt. werd! lol hum i will test out your code tomorrow Hyper and give you a vid. but do you have a code were its more noticeable if i can check to see if its working? my oscpe aint much and led is too fast. anyways would be good for me to test. sorry. if you don't feel like coding something then i understand tho. and i might get that scope that you suggested.

[Hazer]

Just a little to share on this whole thing:

There has been enough screen shots showing that COM1 and COM2 are timed, so I wont waste bandwidth. But here is a nice shot of COM2 vs R2:



Red is R2, yellow is COM2. Now lets see what it looks like when we press the R2 button:



R2 stays the same, and COM2 drops to ground. If you press the other buttons tied to this train pulse, they will drop to gournd, and thier respective waveforms look the same too (the button solder point signal will have its pulse always at ground, never changing.).

So what does this mean? It means that each button solder point is actually an output. It stays tri-stated until its 'turn' on the train pulse we see. So it leads us to the idea that COM2 is an input. If we take the flex PCB out of the controller and measure the resistance of the button, it is about 6KOhms at rest. It drops to roughly 1KOhms when fully pressed. So looking at our signal pulse again, we see that when R2 drops to ground, COM2 only drops to half of VDD. This leads me to believe that COM2 has a pullup resistor at about 5KOhms (probably internal to the SONY ASIC chip). It makes sense since the pulse floats at VDD until the button pulses activate. So here is the conpetual circuit of the R2-COM2 lines:



So lets think about this: We connect our PIC to the COM2 line and do what we can to manipulate it. If the R2 is outputing a digital low signal, and the button is pressed, then the output current is dropped across the 5K pullup and the 1K button (pressed). If we force the COM2 signal high using the PIC, then we are sourcing the current through the PIC across only the 1K of the button and sinking it through R2 of the ASIC. In effect, we multiplied the current by 6 times. My original deisgn was to run the logic through a series 5K resistor to keep things at the same design tolerance of the controller.

Once I ge MPLAB installed again, I will work on the comparator (and post the asm while I am at it).

Any thoughts about the current?

[RDC]

The Pull-Up Resistors are on the Daughter (flex) board, and they're around 7~8k in value depending on the controller version. Only L2 and R2 measure around 6k, the rest of the buttons are around 10k. This is how I've drawn it up, and the Resistors with the lines over them represent the 'pressure sensitive' buttons, the harder it's pressed the lower the Resistance.



A button doesn't need to be pressed completely to have it activate in game, around 1/2 to 2/3 of the way usually does the job, depending on the game, so the lowest value that it can hit (which is around 350ohm if it's fully pressed) isn't a good value to go by, half to 2/3 of it (around 1.5k~3k for L2/R2 and around 3k~5k for all other buttons) are better values to use, unless someone is just heavy on the buttons for whatever reason.

Also you have to look at the current draw from the stand point that a button press lasts for 500us, so it's not constantly having to source more current, only 500us out of every 10ms or 50ms per second on USB power, it's less than that when running from the Battery power, and that's provided the button would be held down the whole time, which it isn't going be, so the added current draw while technically a factor, doesn't seem to be causing any issues at the moment and most likely never will.

You really don't want to put a Resistor in between the PIC and COM line, what will happen is the button will only fire within a really specific range as the Resistor keeps the masking signal (Hi pulse from the PIC) from being Hi enough to keep masking the button press even though it's pressed. So what you end up with the 'sticking button' issue where the controller will think the button is being held down all the time after it's pressed because the Hi pulse from the PIC can't drive it back Hi enough to mask it to mimic you letting it go. Even with no Resistor at all in there if the button is pressed hard enough this can still occur, but putting a Resistor in there just makes it worse.

[Hazer]

I agree that there is no harm posed to the controller. You are absolutely correct that the extra current is only 10% of the over-all signal time and that should be well in the range of tolrance for the controller.

As for not driving the button high enough using a 5K resistor, I will have to argue that one. Specifically, I used a 5K resistor already to mask the entire pulse train to 'diable' the buttons during my initial testing. The pulse train is a voltage divider even by your diagram (nice one BTW). As the button is pushed, the pulse drops lower. By pulsing the common back to high through the series resistor, it brings it back to its original 'released' state.

So, even though I have already tested that using the resistor would disable a button press without the sticking button issue, the other problem is would you be able to apply a low signal to a 'released' button and drive it low enough to simulate a button press?

I am also remembering how analog setups like this (X360 triggers) would have problems using resistors to condition the signals since the controllers resistance would not necessarily follow from one controller to another. So while the testing I made with a resistor on the one controller I have worked, it may not work for some other controllers.

I guess the best solution is no resistor.

Will work on a comparator solution soon. I still believe this will have a much more faster and stable trigger and allow manipulation of all of the buttons.

[hyper999]

small update on my part have got adc interupt working and am in progress of disabling r1

edit: ok fed up with adc kinda got it working but am gna have another go with the comparator now i have my scope

[Hazer]

First attempt:



Nice 3 wire solution:



I am attaching the hex and asm file (renamed as txt file) so someone else here can double verify. I only have this connected to my PC with the six-axis driver, so I have no PS3 to test button presses, just the control-panel config util. I dont know how you guys wired your previous attemps, but this one is VDD, GND, and pin 6 (GPIO1) goes to the COM2 on the controller since this is the comparators CIN- pin.

I used the internal voltage refference at max setting (its like 2/3 VDD). I keep polling the COUT register bit until it sees the first falling edge. From there, a simple 475 usec looping routine to pass the R2 pulse and then use the remaining 25 usec to turn off the comparator and change it to a digital output latched as a high. Wait another 475 usec and reenable the analog input and wait out the rest of the pulse train. Then go back to polling COUT.

I am surprised, I ussually make typos when doing my first test codes as I switch back and forth from the datasheet alot. This one worked very first time.

The next thing to do would be use a counter to RF the R1 line. But we need to discuss something. Since we are now aware of the different frequencies when on USB vs battery power, I would think that just using counters directly with the pulse train will be a bad code as the RF frequency should change with the power source. I would suggest possibly using the T2 interupt scheme I had with the older X360 codes. Instead of having the interupts change the output though, just have it toggle a FLAG bit. Then you can use that flag bit to determine what you will do during the train pulse.

Thoughts? We should also see if we can build an akimbo test, but will need a PS3 owner to volunteer testing.

[geraldrubalcava]

hyper so your going back to com? well you were almost there with adc. but i believe com will be a more fancier approach. well hyper are you able to mange to fix the issue of usb/batt with competitors?

as for hazer, i previusly wired the controller using vdd, ground (as usual) and pin 3 to com2, pin 2 for led, and pin 5 for mode select. but i would desolder to test your code. one Q; this code is meant to rapid fire? or to disable R1 in a sort of way?. well i would gladly test your code. i can also test akimbo with mw2.. and il post some vids up of usb/batt changes during "gameplay"

[Hazer]

This code just disables R1. I will work on a counter RF for us to test the USB/battery power situation next.

The whole reason for this is that the comparator solution has a faster reaction time. It is repeatable to the usec on the falling edge of R2 (the beginning of the pulse train). The ADC solution has a slower reaction time and is not in synch with the falling edge. Basically, you keep running the ADC capture over and over until the ADC value falls below your limit.

Quite simply, the comparator is exactly what your forcing the ADC to do. The ADC has to be constantly run and manually compared to the reference voltage value, whereas the comparator will instantly react to that reference voltage level.

Also, another good thing about the comparator is that you can use it in the middle of the pulse train to determine if any of the button have been pressed or remain released using the internal voltage reference. You can even connect COM1 to pin 7 and use the comparators switching ability to monitor both common lines and hence see button presses on most of the controller.

This will give you the ability to macro most of the controller if the code is done right.

[802Chives]

Hazer, you dont need to use a comparator for determining when buttons are pressed, digital works fine as long as you arent pressing the buttons with a limp noodle.  As long as you can trigger your pic on the falling edge of R2 you can read all the buttons and activate/inhibit all the buttons digitally.

I am not sure that the 1.2mSec timming difference when charging will effect the use of the code enough to actually try and compensate for it.  Detecting the faster speed and dropping a cycle seems like a lot of work when all you need to do is charge your controller from a different source.

nice work getting the comparator working, im an interrupt so I would put it on an interrupt, but to each their own.

[hyper999]

ok guys ive been hard at work with the comparators because hazer your pretty much a god to me lol so if adc is not good enough for you its not good enough for me either! ive read and reread the lesson on comparators and the section in the datasheet and ive finally managed to disable r1! although i now see hazer beat me to it . however during testing i found if you press hard r1 will still work? not sure if this is just because i was testing on gh or not?? but anyway heres the hex and source
just pin7 - COM2

edit: and sorry for the misleading file names it actually uses the comparator not adc i promise!
Post Merge: September 14, 2010, 01:19:06 PMOk, here is a one mode code set at 1sps but this can be modified by changing the firerate variable in the source code and then reassembling it with mplab. Can someone else please test other speeds as i have no games to test with and do not intend on playing with this code lol.

[geraldrubalcava]

ok well i tested hazers R1 disabeling code and its seems to work perfectly, but for some reason when you press the button hard enough, but i mean hard! the gun shoots but other then that its working a-ok even on usb and batt.

as for hypers code the disable code dint work for me :/ sorry. and the Rapidfire 1sps dint ether. ima give it another go but im not sure whats wrong. ima give it another go. but can you guys put the RF in the same pin? atleast for comparators? lol like pin7 ? lol well there is my update. but im sure hyper might get it soon! dont give up! your almost there! i will post vids soon.

[hyper999]

sorry i meant pin 6 and yes that means we are using the same pin now but why dont you just connect the controller to your pic via your breadboard to save soldering and desoldering over and over again?

[geraldrubalcava]

hum working! lol both the disable and the 1sps, but the com test with 1sps seemed alittle slow. like 1.5 seconds or something. lol well successes! now RDC, Hazer, Hyper managed to get this off the ground but also same result with pressing it hard enough will "re-enable" R1 witht he disabling code. but in gameplay no one presses that hard. lol

[hyper999]

did you find the same problem with rdc's code when pressing too hard? and yes 1sps was a theoretical value im still working on simplifying my code to make actual speed closer to the theoretical.

[geraldrubalcava]

hum actualy i never noticed if RDC code did that too. ima have to check it out too. lol well yess good job man! finally! well most people dont actualy press that hard do they?
Post Merge: September 14, 2010, 03:20:28 PMso the code is finally working with comparators for you hyper? awesome! woo! lol so after this the speed needs to go faster?

[hyper999]

Well i dnt know lol i dont use my ps3. The only reason im doing this is that i thought it would be a good first project to test out my coding skills on and obviously i wanted to help out the acidmods community
Post Merge: September 14, 2010, 07:23:33 AMAnd yes i will work on reducing the stutter and increasing the speed tomorow
Post Merge: September 14, 2010, 03:27:49 PMAlso for when i move on to modes how do the leds in a ps3 controller work? And do they work the same on all revisions?

[geraldrubalcava]

on the ps3 all leds work the same. they have a common positive so ground is the one that has to activate it.
Post Merge: September 14, 2010, 03:40:31 PMalso for modes its easyer to have a 2 sec torn off thing, then to cycle though all the modes to turn it off.

[Hazer]

Well guys, I didnt test pressing the button hard because my controller here is disassmebled. I can only press so hard. But I think I know what is going on. RDC said that if you press hard enough, the resistance of the button can drop down to a few hundred Ohms. If the R1 pulse outputs to ground and the button resistance drops too low the voltage output will begin to drop. Look at the 12F683 datasheet, pg 149 Figure 16-25. It shows the output voltage vs the output current for VDD=3V. It looks like the voltage output begins to drop as the current source gets larger.

I am not sure that the 1.2mSec timming difference when charging will effect the use of the code enough to actually try and compensate for it.  Detecting the faster speed and dropping a cycle seems like a lot of work when all you need to do is charge your controller from a different source.

The way I look at it, timing down to the 1msec seemed to matter alot, especially with game patches. I plan to do two simple RF codes at around 6Hz to test. One code will be directly with a counter going off the train pulse, the second code will use the TIMER2 interupt to flag the RF schedule. This will be a test to see if either code can be seen to have any difference between power sources. It should be noticeable at that speed.

The trick though will be to have the smallest ISR routine possible. And maybe it would be best to time it at 500 usec so that I guarantee it happens during every button pulse and I can remove that time from the wait routine. I will have to remove the interupt during those times near the falling/rising edge so that it occurs after the correct timing of manipulating the pulse train in case it gets 'in synch'. We will see.

[RDC]

@ Hazer - Checked you R1 disable on the scope here and it looks nice, it's more solid than using the ADC, good work. I wouldn't worry about the button being pressed all the way in as an issue, anyone hitting the thing that hard needs to learn how to use the controller first before installing a R/F chip to most likely do nothing but be a jerkhole online with it anyway.


@ hyper999 - Your R1 disable has an issue. If you press R2 all the way you should see it on the scope there.


Everyone's R/F speeds should change slightly based on USB power or Battery power and the game that's being played. In MW2 here it changes based on USB/Battery power with the same timing of masked versus pressed times on the R1 button, so while that's fixed, the rate of fire changes because of the 100Hz versus 89.3Hz deal. Since the vast majority of people will play wireless, Battery power, that's the setup I'd shoot for (what a horrible pun) but make sure that plugging it up isn't going to cause any major issues other than it firing a shade faster, but again that's going to be game dependent as well.

[Hazer]

Everyone's R/F speeds should change slightly based on USB power or Battery power and the game that's being played. In MW2 here it changes based on USB/Battery power with the same timing of masked versus pressed times on the R1 button, so while that's fixed, the rate of fire changes because of the 100Hz versus 89.3Hz deal. Since the vast majority of people will play wireless, Battery power, that's the setup I'd shoot for (what a horrible pun) but make sure that plugging it up isn't going to cause any major issues other than it firing a shade faster, but again that's going to be game dependent as well.

Thats the reason why I want to use the timer interupt. It would run independantly of the power and should keep the frequencies stable. Basically, the RF timing happens in the interupt and doesnt change. But it doesnt directly manipulate the COM line. It would simply manipulate a memory bit. When the pulse train routine sees R2 falling edge, it will check the status of that memory bit in order to determine if you need to force a release or do nothing. This way, the RF frequency should not change with the update rate of the controller. It just means a little finesse with assembly instructions in order to maintain good timing to manipulate the pulse train.

[geraldrubalcava]

well if using timer interrupt then also hyper can correct his code with usb and batt if he uses this code? hum. well awesome code guys 

[hyper999]

bad news guys i reinstalled win 7 on my laptop yesterday and have some how deleted all of my coding projects so im gonna have to start again tonight however it shouldnt take so long as i know how to do it now and it give me a completely fresh start.
im gna start by writing a disable code with where you can choose which buttons to disable by using a bit in a register for each button then develop from there.