Acidmods
AcidMods Resources ----- ( These are helpful tools for modding ) => Open Source Code & AcidMods Free Code => Topic started by: geraldrubalcava on August 09, 2010, 07:04:22 PM
-
EDIT: :#1: 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 (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.
-
i know for fact that the rapid fire kit for ps3 , used a lot of voltage thats why the battery charge drain so quickly!
-
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.
-
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:
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi50.photobucket.com%2Falbums%2Ff320%2FRDCXBG%2FPS3%2520RF%2FPS3COM2CloseLabeled.jpg&hash=2a9476f680a87b30420d671a9ea673635e5ac0d1)
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.
-
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 :tup: .
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.
-
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 :)
-
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. :tup: 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.
-
oops just realised ive been staring at the attatch butoon for like 10mins DUH!
-
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. :hifive:
-
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.
-
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
-
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. :)
-
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 PM
sorry for the double post but i couldnt add the attatchments and turns out i cannot atatch asm files :(
-
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.
-
ok awesome how long will that takeyou?
-
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. :/
-
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 :)
-
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
-
sorry should have double checked the code
should work now and still use pin 7
Post Merge: August 22, 2010, 06:02:35 AM
ok here is the source file as a txt file if anyone wants to look over it
-
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.
-
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 :)
-
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 (http://www.youtube.com/watch?v=TvYoq3w4yPs#ws)
-
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?
-
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.
-
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 :)
-
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 ;)
-
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.)
-
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.
-
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
-
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 (http://www.youtube.com/watch?v=OoViRQwpCAg#)
-
I have written a nice PS3 code in which was sold to BGR mods for their Intensafire PS3 Clip Mod (http://www.bgrmods.com/products/PS3IntensaFire.php) (also did the xbox360 code) so i have alittle bit of experience when it comes to coding pics.
I have not seen your schematic but it sounds like you are trying to both trigger on and manipulate the Rcommon Line which is possible using comparators or ADC like Hazer pointed out. You should be able to continue your current code buy triggering on the R2 line with one pin and outputing on the Rcommon line with another pin.
If you would like to use comparators.. you could poll your comparator similar to how you have your code set up now on Rcommon, but the real beauty of Pics are their many varieties of interupts available to the user. I have never implemented the comparator interupt, but it basically consists of setting up an internal reference voltage for your comparator and using it just like a pin change interupts or a timer interupt.
-
Great to know that some one else knows about this! :) the more people the better. well true. we will have to change to have one pin output and one input. thank you 802 chives. well then if you coded the Intensafire without using comparators. but did you use two different pins for input or output? because if its just one pin then there is still a possibility without comparators. but i think right now for a open source we need to keep it simple, but it also has to work tho :/
so in your opinion should we stick to the current code or to with comparators.
here is my basic setup.:) ps3 rapidfire setup (http://www.youtube.com/watch?v=81kIzBtgQGk#ws) i know there is a 360 controller there. but its just for a friend. i just do ps3 sorry :dntknw:
-
yesh i did it it without comparators... using two pins. Only real difference is I used an interupt on pin change, instead of polling the pin. Both methods are the same, one uses interupts one does not.
In my opinion comparators is a better code because it is less pins that need to be hooked up,,, but im also of the opinion that if there is a simple hardware fix like grabbing an extra pin then make your code simple. In other words I designed for a clip, so grabbing a pin was not a big deal, but if i made one to be hooked up by hand I would want to use comparators to cut down on install time. Now that is because I design commercially and am always looking at things in time effeciency coding vs manufacturing. For open source I say let em hook up another pin :laughing:
-
lol let them hook them up. well i guess comparators might be the way to go. if there is a choice between the codes soft is easier to correct that a broken controller lol. i broke one doing different mods to it. so ppl not that experienced in these forums might also have a chance to break. so i would say interrupt. lol or if we use two pins? like 7&6? lol then we can just brige the conections and hook them up to Rcommon? lol u think that can work? but i still root for Comparators.
its up to hyper999 tho. because its his code. plus i dont know much. :)
-
nope i wouldnt bridge any pins, just use one pin and disable the comparator imediately following the interupt. and reenable it with the interupt once you finished all your computing and after the signal train has finished.
Depending on the skill level of hyper999's coding he will decide what works for him, he may want to simply poll one pin connected R2 and control another pin connected to Rcommon
-
very true. comparator would be ideal but its up to him. plus now in days all ps3 controllers dosnt have R2 test point. they will only have Right common and Left common so it might not work for newer controllers. well its up to him :) i will always be here to test it at least :tup:
-
Ok well ive got one last thing to try wire this just like the last led test however if it doesnot work try connecting the led between positive and pin 6 if it then stays lit then yes i will start using a comparator
-
2nd led test has bin unsuccessful. :/ i guess we will have to use comparators. so do you want to use two different pins or comparators? i guess comparators would be better tho. well good luck! i will b here to test the code! xD
-
ok i agree with chives seeing as this is opensource until there is a need for only soldering to rcommon i will use two pins as this should help reduce the amount of people flogging the code on ebay il post a ten sps code in an hour or so for you to test
**********************************************
ok done
pin7 common
pin6 r2
should rapid fire at 10sps when r1 is pressed
-
all right true :) well i will open up the controller and connect R2 well i will soon. well i guess we should add a clause were people can use it for monetary gain. well that's the forum rules but not all people do follow the rules. its true. its great that your doing this :). well maybe in the future it would be possible making one using comparators. but for now this is great! but if you think about it, if so many people use ur code there will be mo market for them. it would be pointless for them (the ebay :censored:ers) lol. welll i will get back at you in 2-4 hours to see if it works :)
Edit: unfortuently i have a newer controller so there is no test point were i can get R2 so ima buy buy more old controllers. see if one has test points.
-
They all have a solder point for r2
http://forums.xbox-scene.com/index.php?showtopic=648322 (http://forums.xbox-scene.com/index.php?showtopic=648322)
-
sorry that list is not updated. there is a new controller out. MSU_VX4 is the model after November 2009. so any controller bough after that will not have tp for any buttons except for Rcommon and Lcommon. sorry :/ well i have a broken sixaxis controller. ima see if i can fix it.
-
Last picture on the 3rd post
-
true but here not test point, there traces. but sure il give it a try :) well i found a old dual shock controller. that one does ave the test points so i will do it right now :)
-
Hey guys, I have been watching this thread for about a week and finally was able to borrow an O-scope from work to check things out myself. I am able to view the wave form on the R common just fine. But There is one thing I am a little confused about is, if the pattern repeats only every 10ms than wouldn't you only be able to have rapid fire speeds in increments of 10ms since that is the "refresh" rate of the controller?
Looking back at Hazers post
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.
If you were to count for 50 cycles you would have 10ms X 50 or 500ms then for it high for the same amount of time, or another 500ms you have 1s so it would actually be 1 shot per second instead of 10 shots per second like his example. But regardless most games require more accurate timing than 10ms differences. You would not be able to achieve a "on time" of say 25ms and "off time" of 25ms (20 sps). Or am I missing something?
With other types of PS3 rapid fire "that fire with a button" you can change the speeds in 1ms intervals and see that it makes a difference in the games. But I don't see how that is possible if the controller is only checking the button every 10ms??
Sorry for the lengthy post but This has been bothering me for a day now. Hopefully someone can point out my that I am in error about something and set me straight.
-
interesting observation orko007, and you are correct PS3 Rapid fire only works in 10mSec increments... but at its fastest button press is still 50 press/sec, which is much faster then anygame allows.
The codes that operate on a 1mSec interupt cycle have more resolution then using a code like this, however that resolution makes no difference to the PS3 controller or an xbox controller for that matter.
the difference you can see with 1mSec increments on the faster speeds is due to aliasing with the sampleing signal. On a game like COD, the game has to see the trigger pulled for at least 3 cycles before calling it a pulled. therefore 3X10mSec = 30mSec so 60mSec Period makes for ~16.6 shots/second maximum readable trigger speed. So what you may be noticing is at speeds above 16s/sec you will see a difference between 1mSec changes speed because you are operating faster then the controller can see thus creating an aliasing effect between the signal and the sample.
The larger resolution is not a problem because if you make your trigger pull and release 3 cycles long for your fastest speed, then 16.6s/sec is the max speed, the next available speeds go like this: 14.3s/sec, 12.5s/sec, 11.1s/sec, 10s/sec, 9s/sec, 8.3s/sec, 7.7s/sec, 7.1s/sec, ect. So you are not really losing anything as far as available speeds.
this is the the most precise method of timing of Rapid Fire for PS3, and if we could sync up to the sample rate on xbox then it would make for a more precise code there too.
-
how long until you will have tested the code gerald? and as orko has pointed out it will actualy only fire at 1sps but i will speed this up later
-
well i finished soodering. i had to do it 2 times because the testpoint were unclear. unfortunately no go :/ ima try to recheck my points this model is the v3.5x but so far its still not working just shoots regular. but i will continue testing to see if i manage to get it working.
Edit: ok. so i posted the pictures of this new board im testing. if anyone could tell me if im wrong? because the website tells me that R1 is in tp35 but its not numbered :help: so if anyone know better then me pliz help. if not the code isnt working. well chives do you think the code is correct?
-
what voltage arer the pot points?
-
3.3v but thats how you always have to wire it. i tested a led on it and it works to power is ok. just need the dam R2 test point! lol bcuz its not the clearest one tho lol. i may just probe around and see if it rapid fires. lol
-
Kk cool was only asking the voltage cos should i move on to using the comparator i need toknow the input voltage and i will double check the code again in the morning
-
ok sorry. well i realy tried but it dint work :/ comparator usually is easier to solder. and when you get your cod title you will be able to install this easy too :) but im still trying this code.
Edit: the voltage of my pot personaly is 2.6v but in all the places i searched it mentioned it was 3.0-3.3 volts.
-
geraldrubalcava, you are using the wrong tp points for R1. see attached photo.
-
modded matt. i had to use the R2 because we had to get the r2 signal to get the initial dip in signal and timing it correctly. and i originally soldered it to that point. and it dint work :/ i hoped it did but unfortunately it dint :/ thanks for your input tho :) and great picture :tup:
-
The R2 line will work as a trigger point for your micro.... Its an 802Chives %100 garuntee cuz i have dont it before.
I think that probably if Hyper had an Osciolloscope to help with testing it would be going a lot smoother for you guys... I am impressed you guys are able to work so well with one coder and one tester with no overlap. Unfortanately it will only get you so far... Hyper needs to verify his code for himself because he will be able to identify his errors easier, especially if he had a scope.
Edit: also you guys need to step back and take smaller steps with your code. Start of by making a program that lights up an LED when you press a button. Then take the button input and put it on the R2 line... now you probably wont see the LED light up visually, but you should be able to see it on a scope. Once you have proven the Pic can see R2, then make a code that just inhibits the use of any of the 6 buttons. Then move on to rapidfire, then to modes, then to edit/eeprom, ect to as far as ur taking it.
-
chives your very true! :tup: well i over looked modder matts pic and the R2 was correct but R common was one tp off lol so ima correct that and check again. well true he will have to get his own testing done. but meanwhile he might be trying to start of in the right detection. but its true. we should of start of by simple led's and other. well now if he did the code for comparators, he said he was ganna check the comparator code today in the morning. but im still testing the previous code. so if it works i will give you the info.
i guess the way it works is that he writes the code i check it and test it and i give him feedback. then when people add there info like chives and hazer then this becomes possible. :)
Edit: the previous code still did not work :/
-
well im baffled as to why its not working but gerald have you tried any of the other codes with the different right common tp spot?
on a side note if we dont have any breakthroughs soon i will start doing some hardware testing myself to help speed the project up. also i agree an oscope would be useful so just wondering if any of you have built your own becuase i was just looking at opensource ones but am not sure if any of them are any good?
-
Edit:the last thing to try is comparators. if that works then maybe that was my problem. if it dosnt them break out the oscilloscope. its up to you what you wanna do. if you wanna try to code one more time for comparators or do you want to start building your oscilloscope to test your previeus codes.
well i had a rapidfire chip from ebay along time ago in this controller so im sure it works. well ima open up a different controller and check on those. i agree is would be faster if you can also debug the code. that would be optimal. so if you get this working people should give in there info and see how well it works.
good question about an oscilloscope.
1:have you ever programed avr chips? do you have a composite input source? well heck this one out http://www.nbb.cornell.edu/neurobio/land/PROJECTS/VideoScope/ (http://www.nbb.cornell.edu/neurobio/land/PROJECTS/VideoScope/)
2: http://www.serasidis.gr/circuits/AVR_oscilloscope/avr_oscilloscope.htm (http://www.serasidis.gr/circuits/AVR_oscilloscope/avr_oscilloscope.htm)
3:http://yveslebrac.blogspot.com/2008/10/cheapest-dual-trace-scope-in-galaxy.html
4:http://accrochages.drone.ws/en/node/90
all you can make yourself its cheaper than a real oscilloscope. so im not sure if these would work for the speed of the controller but all should be ok :)
sorry i cant always be here tho. dam calculus lol. and college drains money so i cant buy a "real oscilloscope" ether lol.
-
i only have pickit 2 so cannot program avr chips but what scope have you got? also i am considering buying this one http://www.virtualvillage.co.uk/2-channel-5v-pc-usb-digital-storage-oscilloscope-new-001482-009.html?utm_source=googlebase&utm_medium=shcomp (http://www.virtualvillage.co.uk/2-channel-5v-pc-usb-digital-storage-oscilloscope-new-001482-009.html?utm_source=googlebase&utm_medium=shcomp) because im just about to start at sixthform and am poor :'( lol
-
OK I'm going to open up to you guys a little but because 802Chives is being helpful to you but not helpful enough. Possibly this is because he has contractual obligations to BGRmods if he indeed wrote their firmware.
I am the owner of Console Customs www.consolecustoms.com (http://), I've been doing Xbox 360 mods and PS3 mods for over 3 years. Feel free to send an email from the website if you want to verify. Everything I do has been written from scratch, i've actually never even looked at the open source code here.
Anyway I have been doing R1 mods for a long time already but doing it by cutting the R1 trace and using a gate controlled by a PIC to open/close the cut trace. But this allows for little control over what is going on. I've been looking for other methods for a long time and come across someone in the UK a while back doing it through only the R common TP. I've made little progress on my own mainly because I did not have an O-scope. But after seeing this post with the image from Hazer I tried harder to get a Scope and finally was able to borrow one.
After having a O-scope and being able to see what is really going on with some info from this thread I have a working rapid fire on ALL the buttons connecting only to R common and will soon have it for the L1 and L2 as well. This only took me about a day of work. It is far from a complete mod but I have the basics in place.
Since I obviously sell mods retail (which is my main source of income) I'm not going to post and source or hex but I will get you going in the right direction, at least based on how I got it working.
First off you don't need to connect to R2 at all.
I am doing everything based off analog reads on R Common.
To start I looked for a voltage drop from VDD (2.8V) which should tell you when the sequence starts. Then delay for around 450us to jump over the R2 dip, pull the pin high for 500us, then back to tri-state for 3ms(wait for other button dips to pass) and start the analog read again.
Watching on the scope i could see the change in the R1 portion of the sequence being high all the time. You may need to change the amount you are delaying based on the sample time of your analog read. Once you are completely blocking out the R1 dip you can advance.
After that I just put it into a loop where it would pull R1 high for 3 cycles then leave it alone for 3 cycles. Bam, Rapid fire on R1. Add in a button so the whole thing can be turned on or off and you are all set for R1.
I have already taken it well beyond that point adding in the ability to have rapid fire on all the buttons and enable/disable the rapid fire for each button. But these are things you should be able to figure out as well based on what I explained above and taking analog reads at different times.
one thing I will Stress that 802Chives has already said is you will not get very far trying to do this without a programmer, a ps3 controller and a O-scope in the same room. changes by as little as 50us will affect the outcome of the rapid fire working or not working.
My next task will be working on L2 and L2, Which by the way the L common TP goes in this sequence (Dpad-up, Dpad-Right, Dpad-Down, Dpad-Left, L2, L1). After that I will be adding in modes and speeds like all our other mods and then working on a burst fire.
I hope that you find this useful in getting your mod working and understand why I will not be posting any code here.
p.s. this was done on a 12F683
Enjoy,
Chris
-
Edit: orko007, wow that alot of great info. so you haven't looked over hyper999 code? well then im not sure in what hyper thinks but it would be awesome if you can help us a lot :) plus only people here who have programmers will use the code. and one of the rules here in this forum is that people cant use it for monitory gain. of if people try to sell it on ebay then that's a big no no:)
well i have a complicated arduino setup. lol its the cheapest way i found. there are arduino clones out there that can be cheaper. i got one for 5 bucks and scavenged a usb to rs232 ttl so that solution was 5 bucks. but i got lucky. the one your looking at seems like a good build. its similar to http://yveslebrac.blogspot.com/2008/10/cheapest-dual-trace-scope-in-galaxy.html (http://yveslebrac.blogspot.com/2008/10/cheapest-dual-trace-scope-in-galaxy.html) but the one you pointed out seems to have a faster one. i know you you feel, for me college drains my pockets lol i guess thats why i want a free ps3 rapidfire solution then to keep buying them. lol
well do you think you cam make one with comparators? so at least i can test one last time? if there is finally success then that works ;) if not them i will start debugging with my o scope too. lol and when you get your you can also do it :) and i guess that would be the alternative if it dosnt work. its up to you wann get a oscope? or want to code with comparators? ether way i will be here to test it out. :) and if anything i will do videos of debugging with the oscope and so you can get a inside look in how i do it :yess:
Post Merge: August 28, 2010, 06:43:36 PM
hey! orko007 i understand why u cant post any code lol :) well true if he gets his oscope them this would be smoothly. but i will also debugg. but thank you tho. one question. so did you use comparators or with analog read? but what you did is gave hope. so if anything can hyper email you the code and you can tell if anything is wrong or any notes? lol well thank you again :)
-
Forum Rules are one thing, what people actually do is another. Alot of what is on ebay has com from these forums. Luckily I have alot of unique mods and keep updating them and improving them which keeps my customer base up.
I have looked at one of hypers code posts somewhere on the first page. But here's the kicker. My ASM is very limited so without spending alot of time looking at it and referencing commands I have no idea what is going on, LOL. so maybe this is one point where you can call me a Noob but I use a higher level compiler as I was already familiar with the language.
I did not use any Comparator, I thought about it but the 12F683 has only 1 CCP module and so if I wanted to be able to look at R_Common and L_common using that chip I had to do something else.
I've been working on this literally all day and now I already have it working for ALL of the buttons except L3 and R3. I have it setup so you can enable or disable rapid fire for any button by holding down on the Dpad and pressing one of the buttons. I also implemented our standard rapid fire modes and speed setup. Still to come is burst fire, our jitter mod and a custom mode. In the end once you get the hang of how these controllers work it's actually easier to write code for than the 360. I definitely did not expect to be as far as I am in just 2 days of work.
With how well things have gone I hope to have a complete chip by next weekend that is better than the Intensafire and wont cost $70 or whatever that thing costs, you'll just have to solder some wires instead of just Clipping it on, but it will also work for all controller types.
Again all this would not have happened if I did not have an O-scope to check my work.
P.S. The common line for L3, R3, Start and Back works differently than the other two common lines and from what i have seen I think it will take connections to each of those buttons separately to be able to read and manipulate them. I will do more checking with those later.
Chris
-
Thanks Chris. I can appreciate what it takes to offer that much help.
I keep an eye on this post, but I still wont be able to help here other than conceptual advice. If I actually start doing this again, I wont be using anything people can do at home.
Honestly, I have been waiting to get enough free time to make a USB flash chip. The ADC converter does work fast enough, but I would prefer the comparator and just use a PIC that has 3 of them. The reasoning is that the comparator hardware interupt is almost instantaneous. Well, I should say that the ADC capture time is 2 to 4 usec, whereas the typical comparator settling time is 200 nsec. With the ADC, you are constantly checking at a frequency of 2-4 usec not synced with the signal, but the comparator interupt happens directly with the falling edge. Its a faster response.
Anyways, as I mentioned, I wont be making any code unless its to go all out: USB firmware flash, USB conection to PC to configure frerquencies and macros without firmware flash, connection to all buttons. Ive already created a proprietary encoded flash program, but thats where my tinkering has stopped.
Plus, like was said by Chris earlier, you need the hardware too. I have dualshock myself just for testing the signals. Bad thing is the battery is dead. I have to use the USB cable to get it to power on, and I dont have a PS3. I used that PC USB six-axis driver to configure the controller to my PC so I can see button presses, but I would much rather have a full hardware setup to start doing code. I dont know if the internal power is higher or lower when running purely off the battery.
Anyways, You guys should take Chives suggestion about just testing simple steps to the whole project, not coding everything at once. Untill you know what will work, the rest of the code is useless and would need to be rewritten anyways until you find the hardware/logic that works.
-
ok try this
pin7 to rcommon
pin6 to led or oscope (i personally think oscope would be better :))
pin6 will be low
the code waits for the first r2 pulse to be detected
then makes pin6 high for 8ms
then starts over
-
Chris, I take a little offense to you saying I am not helpful enough, being as we are both coders I cannot find anything that you have posted that is more straightforward then my own... unless you just dont follow the terminology of assembly language and im just not helpful enough to you. Either way Im a big boy and the tears have stopped, just know that you re-stated a lot of what I have already posted here in this thread in your two posts...
Im glad you have been so successful at getting your code to work, once I manned up and dropped the $1200 on a decent scope I had the intensafire code done and debugged in well under 40 hours, and If you look around the forum you will see myself saying the exact same thing to Hazer and RDC about how suprisingly easy it was and how much cleaner it is then my xbox codes.
If you look in our shop you will notice we dont sell BGR's PS3 device, even though I made the code. That is because we do not stand behind it quality wise. The code is very nice, but mediocre in terms of features. It was however intended for the masses and they dont need rapid fire on start or R3, so if you are trying to take a shot at my code, it wont work because of that fact that that code was flashed 5000 times on the first run, and and I had to make it work so the most people possible will be happy. If i flashed onesy twosy chips, I could make any feature you want including burst, however with BGR's chip I was barely able to put rapid fire on R2, R1, and X in 7 modes including the edit mode and 7 modes is alread too many imho so burst got cut. The clip is the part of that product i do not like because of both price and the fact that a clip can get jostled when you throw ur controller at the wall. Im a solder monkey all the way. Also my code works for all versions of the controller... the clip does not.
I thought about it but the 12F683 has only 1 CCP module and so if I wanted to be able to look at R_Common and L_common using that chip I had to do something else.
You only need 1 comparator for both Rcommon and Lcommon, because both signals are synced. (put one on each channel of your scope) R2 and Digital Up are in sync... R1 and Digital Right are in sync.. ect.
Polling the ADC can make this code work, but I agree with Hazer, the comparator is still a better solution. The only reason I used R2 is because it was for a clip and an extra pin was no big deal to add and the code for IOC is much simpler then using ADC or a comparator.
Sorry hyper and gerald for getting side tracked, there are ways to use your microphone input on a soundcard, as an opensource oscilloscope. You will have to make probes for it, but I think in this situation it will be sufficient. I have never used a USB scope, but it looks intriging. What I really am trying to say is that you dont need a $1200 scope to do this, there are much cheaper alternatives because your really only dealing with speeds on the order of 10khz and not the 100mhz that $1200 gets you.
-
Hazer,
Not sure if you remember but last year we were PM'ing back and forth over on X-S about the COD5 Patch and Viking chip. Well i actually moved forward on that and designed a completely encrypted USB mod off the 18LF14K50. See attached picture. I finally have most of the issues worked out I'm just waiting right now in some of the updated PCB's to arrive before I start to sell them.
Now if Only I could find out where I could get a clip type adapter made up for the 360 (similar to intensafire's ps3 clip) it would make that installation alot easier. I would eliminate 14 of the 17 wires that need to be soldered.
As for this project yes the comparator would be faster and I will probably use the same 18LF14K50 chip in a PS3 USB mod which has two comparators which could be used for the L and R common lines. I believe that the R3, L3, Start and Back will need individual connections anyway. Even if it did not the smallest PIC with 3 comparators and USB is 28pins (18F26J53) and twice the cost if the 18LF14K50.
You would still need to use the ADC but just not as often since you could trigger off the comparator.
I probably won't make any more progress today as I have my NFL fantasy draft this afternoon. Then I need to work on things to ship for tomorrow. But I will be working to finish this up during the week.
I do hope you guys get it working, but I dread the flood to ebay of all your hard work. Also like both Hazer and and Chives said you should start out by flashing an LED. I actually did this as well to help me get started.
Post Merge: August 29, 2010, 08:26:55 AM
Chives,
I am sorry about that, my intent was not to discount things you have said and after I posted and re read it I thought it might come across that way. I just wanted to get them moving in the direction of using only one pin for the mod as that is what they ultimately wanted.
We both have chosen not to post our own code here for our own reasons, but this thread has been very helpful to me and I wanted to give back some of my own findings.
As for your code for BGR mods I assumed you codded whatever they asked for and as I said I keep myself in business by continuous improvement. I always want to have more features than the other guy but keep it easy to use. Now if only I had the marketing skills of BRG I would be all set.
Again my intent was not to be offensive and I apologize for that.
You also did just spark a "A DUH" moment in me though with your comment.
You only need 1 comparator for both Rcommon and Lcommon, because both signals are synced. (put one on each channel of your scope) R2 and Digital Up are in sync... R1 and Digital Right are in sync.. ect.
I am actually only triggering off of the R common because I did see that they were sync'd. After the trigger I am using the ADC on both to read the state of each individual button, which will still be needed, but I don't know why I did not think of using the comparator for just the trigger. I will have to try switching that around this week and give it a go.
I used to hate the PS3 controllers but after this weekend, I wish that the 360 controllers where designed this way.
-
Great hyper! i will test this put with my first controller and with my oscope. :) actually im getting everything ready now and im so exited :w00t: i will show you guys a pic if i can of the software. but hopefully the arduino adc is fast enough to read 5 ms. lol
hum i understand you guys cant post anything too specific because ther are probably some of you who wrote code for some other people.
orko007, Hazer, chives, modder matt and everyone ! you all have given great info about the rapidfire, even enough to get this started off and even further, thank you. i truly belive this post is woth sticking because of all the info.
and i dont know why orko007 has to mention his new chip. but i guess it was just getting distracted. but all of you are smart guys. hum i envy your coding skills (im more of a hardware guy) and you guys have to understand that we have ps3 so sometimes in theory it works but in games it dosnt. but i cant stress enough all the help you guys have given. Thank you!
-
I only mentioned it because Hazer said he would only get into it making a full USB mod and we had previously talked together about USB mods over on X-S for the 360. Sorry if it came off as trying to plug my product, but it's not even for sale yet.
-
Chris no worries, it just felt like I was called out a bit... or it might have been the hangover i was battling this morning :dntknw: reguardless im here to help everyone learn, and in this situation i feel like i am teaching these guys how to work through writing a code, which is much more valuable then just the opensource ps3 rapid fire.
I got another one for you... you dont need to use an ADC to see the state of the buttons, it can be done digitally. All you need ADC for is identifying the beginning of the wave train from there you can tell if buttons are pressed or not digitally.
-
all right i probed pin 6 but i keeped getting a high state. im not sure in whats wrong but it was just outputting digital high. i will have a video in how im working with the oscope.
FILE0129 (http://www.youtube.com/watch?v=fd2cZyY99xw#ws)
as for the usb product that would actually be pretty sweet! :w00t: i would buy if i had money lol and you guys all are great! so chives you still think we should go with two pins for reading R2 then write on rcommon? or something like comparators (a fancy way to do it).
-
I still think you should get two pins working (using R2 and Rcommon) and then move on to a comparator or ADC solution.
a simple loop code will verify if the pic can see R2, where RA0 is R2 line and RA1 is an led or better yet your scope probe:
BEGIN
BTFSS GPIO,RA0
BSF GPIO,RA1
BTFSC GPIO,RA0
BCF GPIO,RA1
GOTO BEGIN
just set RA0 as a digital input and RA1 as a digital output. If you monitor the RA1 output you should see when the R2 line is low which signals the beginning of the signal train. (may not be visible to human eye in this method)
-
ok well i think that the reasons that it only shows high are because
1. the resolution of your oscope
2. the time it takes for the pic to manipulate the pin
because it keeps it high for 8ms before starting over and the whole signal is only 10ms long
however on a brighter note the fact that it is high shows that it is detecting the pulse and the reason that the previous codes didnt work was because the they were polling the pin for low then waiting for it to go high again before reacting whereas i should probably just delal for 500usec after it has gone low instead in a minute i will assemble chives's code for you and and the led test code again but with a shorter dely befor it makes the pin low again
and @orko i to dread the flood to ebay but unlike the other codes on here i will be making the effort to publish it under a creative commons licence to deter ebayers
Post Merge: August 27, 2010, 08:03:01 PM
although on second thoughts it could be because its detecting all the button pulses as r2 try hooking it up to the oscope again and see if the signal changes when you press random rcommon butons(r1 r2 /\ [] O etc)
Post Merge: August 28, 2010, 04:13:36 AM
ok heres the code hook them both up like so (but not at the same time)
pin7 rcommon (and then after r2 if you can)
pin6 oscope
also whilst you have them connected to rcommon check if pressing the other buttons affects the signal
and @gerald can you send me alink to the info for your arduino scope?
Post Merge: August 29, 2010, 08:27:59 AM
ok more codes to test YAY lol compr2ledtest and compr2ledtest both use comparators and are wired up the same as the others
-
yea i was thinking my scope speed was too slow Edit it goes (200khz) so it might be fast enough i just need to modify the software on my pc :( but i will see if i can speed up the post posses. hum yes well the second chanel was steady so im sure that it wasn't a battery fluxuation.
second yes some buttons got presses randomly when attached by the oscope. so i guess there is somthing happening.
third its great that you are trying to publish it under creative commons license. most ebay dealers if they steal your code imagine ( 20 sellers trying to sell the same thing) they will hardly get any business because there is too much market. (brothers a business major lol) so u better put it under cc! lol
i will check the buttons right now and so for all of those codes do i use the same pins? great! here is the arduino scope http://code.google.com/p/arduinoscope/ (http://code.google.com/p/arduinoscope/)
-
1.yes same pins
2. there should be no random button presses with these codes or the previous one
3. i meant while attacthed to the oscope press buttons (with your finger) on the controller and see if the signal on the oscope changes
-
here is my test results for the coparator with led wait test. lol i will have the future codes testing up in a bit
FILE0132 (http://www.youtube.com/watch?v=PR4or8nBxHs#ws)
-
I think the blips are just noise but try all the other codes and can you hook up your scope to rcommon and see what voltage all the buttons are when pressed / unpressed cos i need to know so i can setup the comparator properly
also just curious what voltage does r2 go to when pressed? and then when unpressed?
-
sorry if i responded late. well the first two codes keeped giving me a steady digital high. well if you can write a code that complimates my scope? well i will give a second round to the codes and record them with and without button press.
-
all of these codes were meant to compliment your scope :/ but can you post vids please
@chives i looked into the soundcard oscope as i have a spare soundcard but it will only work with ac signals and only up to 1.7v so i think i might buy a cheap arduino clone for the same setup as gerald
-
gerald, you are able to see the signal that hazer posted earlier in the the thread of Rcommon correct? As well as the signal that is produced from R2?
-
well i am currently uploading the vids. lol my camera takes 120 frames per second at 720p so its ganna take a while lol sorry. but yes the arduino itself is able to pickup the signal coming from Rcommon. its not perfect like Hazers chart but similar. i will check the signal from R2 too. but i will have all the vids hopefully up pretty soon sorry for the delay, (calculus classes are exhausting).
ok here is just the test of the Rcommon with my oscilloscope.
FILE0133 (http://www.youtube.com/watch?v=jPllXTg9q1A#ws)
here is my test with R2 signal
FILE0134 (http://www.youtube.com/watch?v=EkI4DbklChI#ws)
-
What a PITA, lol, and I know diddle about coding, so it was even worse. I've been messing with this off and on for awhile now, try a few things outs, scope it and see it fail, miserably, then get fed up and let it sit a few days before repeating the entire process again, code, flash, scope, fail, repeat. What really grinds my gears is I could swear that what I did in code this time I'd already tried before, but it's all such a mess of trying this and that out now I can't remember half of what all didn't work.
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi50.photobucket.com%2Falbums%2Ff320%2FRDCXBG%2FPS3%2520RF%2FAlmostthere.jpg&hash=0b23db35ee335322677c160897a83a01b86978a4)
This has the R1 button disabled for sure, at least here anyway, then R2 and /\, which are on either side of it, still work just fine, as do the rest of the buttons.
So this CAN be done, lol.
I personally could care less about R/F, it's not my thing at all, and most of the time some new one comes out I find the install diagrams have my pics in them anyway, used without asking permission. I was just after the challenge of trying to do this, even though I can't code for spit, but I just couldn't leave it alone and am finally glad I've gotten to this point, which is all the farther I'm going with it as again, R/F isn't my thing at all.
If anyone would like to test/confirm this (please do) the R1_OFF.hex is attached. Pin 3 connects to COM2/TP18 (it's TP26 on the MSU_V2, MSU_V2.5 (Six-Axis) MSU_VX (DS3) versions only) then Vdd and Vss, that's it, R1 shouldn't work at all and the rest of the buttons should.
-
@gerald, that signal is bunk... your going to have a hard time being able to tell what is going on if you cant even see the original signal.
@hyper, I wouldnt go out and buy an arduino scope quite just yet...
-
I agree with chives, hold on of buying a arduino. it might be cheaper but not what you realy looking for. and the signal aprears to be bunk, i know :/
for RDC i will try your R1 disable code. il get back to you in a few hours.
-
yh lol i changed my mind as soon as i saw that vid
@RDC can you post the source for that code? :)
and what do you guys think of this oscope? its a clone of seeedstudios opensource one and looks good enough for anything id need http://cgi.ebay.co.uk/ARM-DSO-Nano-Pocket-Sized-Digital-Oscilloscope-2-8-/300458819103?pt=Radio_Control_Parts_Accessories#shId (http://cgi.ebay.co.uk/ARM-DSO-Nano-Pocket-Sized-Digital-Oscilloscope-2-8-/300458819103?pt=Radio_Control_Parts_Accessories#shId)
-
So this CAN be done, lol.
ur a funny guy :P One of our members Exofire was the first (to my knowledge) to have an Rcommon only RF on the market... and another great looking guy around here also has succeeded as well ;).
-
and what do you guys think of this oscope? its a clone of seeedstudios opensource one and looks good enough for anything id need http://cgi.ebay.co.uk/ARM-DSO-Nano-Pocket-Sized-Digital-Oscilloscope-2-8-/300458819103?pt=Radio_Control_Parts_Accessories#shId (http://cgi.ebay.co.uk/ARM-DSO-Nano-Pocket-Sized-Digital-Oscilloscope-2-8-/300458819103?pt=Radio_Control_Parts_Accessories#shId)
seen those on deal extreme:
http://www.dealextreme.com/details.dx/sku.39753 (http://www.dealextreme.com/details.dx/sku.39753)
check the comments... seems to get decent reviews. Hard to beat $80 for 1mhz...., but for $180 you can get into a 40mhz USB scope:
http://www.dealextreme.com/details.dx/sku.37062 (http://www.dealextreme.com/details.dx/sku.37062)
I like the idea of the portable one and price is right.
-
i think i will get this one and i will be getting it from ebay cos im in the uk :)
-
I got another one for you... you dont need to use an ADC to see the state of the buttons, it can be done digitally. All you need ADC for is identifying the beginning of the wave train from there you can tell if buttons are pressed or not digitally.
I did not try that only because the buttons are analog and each press is going to give you a different voltage and it is possible to press a button light enough to get it to activate in the game but not give a digital low reading. but for the most part a normal pressure press of the button (past the tactile feeling "bump") will give a digital low reading. Also R2 already sits digital low when at rest so you pretty much have to use the ADC to check for any activity.
if anything the way I set it up if I ever wanted to make something different happen based on how hard the button is pushed I could do it.
also just curious what voltage does r2 go to when pressed? and then when unpressed?
I didn't see anyone answer this but for R2 when not pressed it sits at 1.3v and pressed depends on how hard you press it. a full pull of R2 will goto 0V but in a game it will start to fire at around 1.1V - 1.0V.
All of the other buttons are 1.6v at rest and an average press gives you around 1.3v but again they are all analog so a harder press will give a lower voltage.
Also if RDC were to post his source you could just take what he has done and put it into a loop so it pulls R1 high for a few cycles, like his code does all the time now, then just do nothing for a few cycles. That was the basics of how my first success happened.
p.s. I have spent the last two days working up code to do burst fire (only for R1 or R2) but is was very much a pain compared to just normal rapid fire or even burst fire on the 360. I would probably be easier using a comparator but I have yet to mess with that yet, most likely later this week.
-
ur a funny guy :P One of our members Exofire was the first (to my knowledge) to have an Rcommon only RF on the market... and another great looking guy around here also has succeeded as well ;).
I've seen the chip you worked on, and am also familiar with the Exofire one since they use some pretty familiar looking pics in 'their' install diagrams.
What I meant by "So this can be done" was just that it has been eluding me personally for awhile now and that I finally got it. I don't write code, can't code for squat and probably never will to any decent degree, and I was starting to think I'd have to be at it for some time until I learned a whole lot more so I'd able too get it or wait until someone else showed exactly what needed to be done, at which point it wouldn't have been any fun to try and figure out after that, which is all I was after on this, so it was more of an 'ah-ha' kinda statement. That's also why I mainly do Hardware hacks and did that side of the CGnome Project and left the coding to someone that knew what they were doing. ;)
I honestly have no desire at all to proceed any further with this, as after this point it's just pressing a button over and over, and R/F really just doesn't appeal to me at all. It might if I was paid for it, or at least compensated for the use of the controller pics as that's done nothing but make others profit from my work, which if thought about would get anyone a bit testy, and there's way too many people investing time, effort and money into R/F controllers that I'd really like to see them do, or at least try, something new that might actually be useful to some gamers that are after more than a controller that pushes the button for them over and over again. But I seem to be in the minority there, which is fine, I'm just not the type of gamer that has to get every achievement point or trophy in a game that there is to get or think that a controller that shoots 1/sps faster than the other guys will make all the difference in the world. That's no knock on you or anyone else that's spent time figuring out how to do it and get it as good as it can be (except the lazy thieving types) but it's still just pressing a button over and over again, and even the more 'complex' controllers that pull off a game glitch are just an extension of that in my book, and again no offense to anyone that does it, I'm just not into it and all I was after here was seeing how the first part of it was done as that was starting to drive me nutz since I knew it already had been.
@ hyper999 - I'd look for a good used Analog O-scope. I have an (old) Fluke 97 50MHz ScopeMeter, that's the screen shot from earlier in the thread that Hazer posted, then an Analog 60MHz one (that's the pic I posted a bit ago) and both are Dual channel also, which is pretty nice for some things, but an Analog scope will let you see a lot clearer what a Digital one just kinda does. A newer Digital scope would be a lot better than the Fluke 97 I have, and for what they cost they better, but you should be able to get you a decent used Dual channel Analog one for a reasonable price. They each have their advantages/disadvantages, just so long as it works for you is all that matters though.
As far as the source goes, I'm just reading the AN3 pin. If it's a shade under the vRef (Vdd) then start your wait time to skip R2 and so forth as described by others, but if it's not then loop until it is, that should get you to the point where I'm at and it's only 3 lines of code in Basic, no idea how to do it in Assembly or C, barely know how to do it in Basic. The overhead code meant I had to set the 500us wait time, to skip over R2, to around 380us, and it still 'wiggles' back and forth a tiny bit, not staying spot on the R1 button, but it doesn't cause any issues so far from what I can tell as R1 is completely masked and the other buttons all work as normal.
You can't treat a button press as a voltage change when using only the COM2 line, the controller doesn't really work that way, what you have to do is start off right at the beginning, or as close as you can get, of the falling edge of R2. So you're looking for the voltage to be under vRef (Vdd, 2.8v) but not just at any spot, right at the very beginning of it, the falling edge. After that you can 'read' the voltage of it and see where it's at if you wanted.
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi50.photobucket.com%2Falbums%2Ff320%2FRDCXBG%2FPS3%2520RF%2FCOM2Flow.jpg&hash=7d29de13448825085965347e6130870f3305e178)
-
Orko: 0.8V is the digital high threshold for a schmitt trigger, so R2 is not a digital low to start. all the buttons on Rcommon and Lcommon can be read digitally... I know because I have tested it.
You are correct however that the buttons need to be pressed normally in order to register, but no more firmly then in normal use (a light press will not be seen digitally). you could take advantage of the pressure sensitivity using ADC as sony does, but I cannont see an application where you would want to at this point, not for turning RF on and off and cycling modes.
I think these guys may be getting off track by the arduino oscope not giving them the resolution they need, once they can see the signals they will be moving in no time.
RDC: I can understand your fustration with people using your pics in their product sales, if it makes u feel better i always know where they come from :) I share your sentiment for Rapid Fire, I do not use it, and when I have it makes me worse so I think it is very gimiky (with acception to rapid fire on X for 1942 for PS3) Making macros for buttons is really simple with micro's as well, but like you I also would like to see more. The Usb Flash version of a mod chip is a great idea, Viking and Consolecustoms are not the only ones tossing that idea around either, but it will be the PC GUI for making a custom controller and a slick interface that will prevail in the end.
Gerald and Hyper: I dont want to muddy the waters anymore, but there is another pic interupt feature that can be used for triggering the beggining of this wavetrain, and that is External Interupt feature for the INT pin (I believe it is GP2). that interupt can be triggered for either falling edge or rising edge of a signal. I would have to look at the spec some more to see what the threshold for the falling signal is for this interupt, but it would undoubtedly work for R2 and maybe Rcommon
Edit: RDC, everytime I see you write that you would not be a good coder, I cringe,,, you would be a great coder and you already know the electricity so you are already way ahead of the game. That picture you just posted, you wrote a suedo code loop there that is easily converted to assembly which I am assuming you did. The rest of the code would be no harder then breaking it down into similar seudo code and tackling it piece by piece... IDK, but if I were you I would go through the 12 tutorials that come with a PicKit2 and Low Pincount demo board from microchip and then re-evaluate whether or not you should code.
-
well good news! RDC code works! it dissabled R1.
First ps3 rapidfire success (http://www.youtube.com/watch?v=ziKs_dovXzE#ws)
and true what chives said, RDC is a great coder. Ive seen some of his work and amazing. you shouldn't dough yourself. like you i like doing Hardware. ive done bluetooth military headsets for ps3 and phone. hase mods hardware and hardware cracking. But i can do software with networks (penetration vulnerabilities and others.) so like me i can do both pritty well but you sir can do the middle basic. that re able to take hardware and software to create different things. so i envy your skills :) . but i disagree that were wasting time and money. well money maybe, but a o-scope is a coders favorite buddy lol. so if he dosnt use it for this project he can use it in the future :) as for time the most i spend testing and typing is max 2 hours (school takes up too much time). so this is for people who dont know much but can program there own chips. but who who ever comes out with a successful open source ps3 rapidfire should protected from the ebay :censored:ers. lol
well sorry for this question but, can you put out the code you got for the disable R2 button? i mean the assembly code lol sorry if you mind me asking. and if it would be possible for hyper to work on your code?
thank for all your input. this has bin a great community. over at xbox seance are not as friendly sometimes lol. woo somthing finaly working! im still exited lol
-
Rdc's source is of no use to me as he wrote it in basic but he has explained how he did it however he used adc to do it where as i would like to stick with comparators so we will just have to wait for my scope to arrive from hong kong then i will get the code done in no time
-
yes its understandable. well yee i can wait till you get your oscilloscope. and i will always be here to test it out :tup: hum well then RDC you dont look like you want to pursue making one because its pointless well i understand. you seem to have the right idea. and you were able gi give us a working same of it. thank you. it would be awesome if in yous spare time you could develop this just a little? :clap: just asking. sorry well thank you so much u are a awesome coder.
Thank you too hyper999 for your time. And hopefully you will get you scope to complete a fully working ps3 R/F on R1 thank you too man! :tup:
-
progress: just wired up my test controller :)
-
good :tup: lol. if you have any code that you are going to test in your controller feel free to post it here so i can test it here. lol you got the chips and everything (except scope)? lol
-
More progress lol : scope ordered will probs be here in like 7 days
Tommorow i will build a dev board to plug into my controller
-
all right lol. thats good i suggest to keep open the controller or have a way to run out the cables though a hole or something. lol. and if you manage to get this working then led will come in the future so u might want to have that prepared. that if you want lol also to test the controller out with different games because like earlier, someone said in cod games it takes 3 cycles for the game to register a push on the button. so different games are critical lol
and if you want i can try out any code you want on cod6 :)
-
@ 802Chives - Thanks for the encouragement. I used GCB to compile it, and I write it all out in Notepad. My first real messing with coding was doing the PS3 Slot Loader (http://forums.xbox-scene.com/index.php?showtopic=713354), and that was just a bunch of loops waiting for a switch to change state so the code could move on, horrible, lol, but it works pretty good. I can barely half understand Assembly, but to look at it gives me a headache, where in Basic I'm to the point now that I can kinda 'see' what it's doing, though I've still only scratched the surface of what all I can probably do with the 12F683 chip and Basic.
@ hyper999 - Looking forward to seeing how your scope works out and the Comparator method goes from both you and orko007.
@ geraldrublcave - I'm a Head Mod over at XS, and friendly can only extend so far in the face of what is sometimes nothing but sheer stupidity, not saying that what you've posted over there is, if anything even, but you'll find all kinds online, and if you ask a question in an open forum expect to get all manner of answers, comments and such, because there are all types online and all of them believe they know it all regardless of the fact. So long as people keep it civil and/or constructive that's fine with me, but I personally don't tolerate abuse in threads over there, mine or other members, so if you're catching grief for asking a question over there PM me about it.
I've attached another .hex, and if you would, please try it out and see how it acts, same wiring as before. I honestly don't have any PS3 games at all that could even use R/F, and only a couple of Demos that can't really make use of it either, so I'm going to have to haul the PS3 over to a friends and d/l a few or get one before I can really go any further with this, so this one is just a shot from the hip, so to speak.
-
awsome well i will soon test this out. welll most games are ok at a certain speed. As mentioned above for cod games have to have 3 cycles in order trigger a push. but i will give you code a try :) if it pulls fast enough it might register. but some games like cod5 had patches witch limit to 11.5 sps. so you do your code in basic? well i guess i should start learning it. and you say your code can be transferred to assembly? great! dam! i only know objective-c. well better crack the books open and begin learing lol.
well i get you its true :) sometimes cooperative people reply and sometimes others do. well your right and have wize words :) thank you for those words of encouragement! lol and i understand maybe i asked a obvious question for them. well thank you again, and i will get back to you in a bit. lol
-
but it will be the PC GUI for making a custom controller and a slick interface that will prevail in the end.
I'm workin on it, I'm workin on it, sheesh! Seriously though, I took the USB sample code and encoded it. I rebuilt the GUI interface as well to Make encoded hex files from source hex files. I can use a modified version of the original downloader to download those encoded hex files. I got all that working first.
I was then able to modify the USB sample interface and transfer bytes back and forth to/from the EEPROM. I could pretty that up by changing some text and have the USB version of what I did with the 12F683 on the X360 controller.
The last part I was working on was converting all that USB source code over to assembly. I dont have a full C18 licence, and I dont like arbitrary use of the memory registers. I like assembly for what it is: complete control over the entire chip. Once I reverse the entire source back to assembly, I can change the code to maximize the memory usage for MY code, and just trigger the USB interface only when purposely needed. In order to make full use of teh USB interface, I will need enough EEPROM/Program memory to be able to hold the data for at least 8 macros. This will not be an easy fit. I was half done converting when life caught up, and I do not see continuing any time soon.
But back on topic: Even though the easy way is to use R2 for your trigger, you should still keep trying to get the comparator to work. I say this because it will allow you the ability to manipulate R2 in the future. I know the short-term goal is to get R1 to RF, but getting the comparator to work not only gives the 'one-wire' solution, but you will be able to RF or macro the R2 line as well.
Oh, another thing about the frequencies: Since we know now that the 100 Hz pulse train is the sampling of the controller, I dont want you guys to think that RF rates are limited to the same on and off times. You can force a release after 20 pulse-trains, and then dwell for 18 pulse-trains. This would change the frequency just enough to possibly have even more resolution than just a 50% duty cycle.
-
But back on topic: Even though the easy way is to use R2 for your trigger, you should still keep trying to get the comparator to work. I say this because it will allow you the ability to manipulate R2 in the future. I know the short-term goal is to get R1 to RF, but getting the comparator to work not only gives the 'one-wire' solution, but you will be able to RF or macro the R2 line as well.
Using Either IOC or EXT INT you can still manipulate R2 using a 2 pin method... the code I wrote using IOC has rapidfire on R1,R2, and X.
Reguardless we all agree the comparator one pin solution is the best way to go.
Hazer: u truely are a madman for converting the USB source to assembly, I love assembly like the next guy, but those are lengths I am not sure I could go to :)
-
lol a agree with chives lol converting into asembly line by like is crazy. but patience is a gift for some. lol
Hey RDC! successes! again your code worked! :) not as fast as i seen other R/F/ but i believe its this speed because cod has a rule 3cyles= 1push. well hope you continue with the rapid fire. wow great work! have you made a 360 into a pa3 case? just me wondering. lol
RDC test 2 (http://www.youtube.com/watch?v=HKF_1JTpiG8#ws)
well true. comparators would work and that would be what in the futrure the ps3 Rf will be heading at. but would this interrupt having two in different pins? i mean in the future if we have dual trigger. or would ADC be the way to go if there will be dual trigger( i know im getting to ahead but just want to know if its future proof) lol
-
all right lol. thats good i suggest to keep open the controller or have a way to run out the cables though a hole or something. lol. and if you manage to get this working then led will come in the future so u might want to have that prepared. that if you want lol also to test the controller out with different games because like earlier, someone said in cod games it takes 3 cycles for the game to register a push on the button. so different games are critical lol
I haven't played around with code anymore yet but after reading your post I wanted to show how I setup my controller to make my life alot easier.(see attached pictures)
You can get everything you need for a setup like this at radioshack for under $10.00. The board is $1.99 and I cut it in half to maximize use, IC socket 99 cents, 30ga Kynar wire 2.99, the buttons i get somewhere else but you can get similar buttons at radio shack for around $1.99. For this setup I also added in some header pins to make connecting to the scope easier. I have some laying around from old original xbox modding days. If you don't have any you could get creative by either pulling something out of a dead piece of electronics or cutting a small section off a resistor to make a nice post.
For the cost and a little bit of work it makes testing a whole lot easier than sitting with an open controller. Especially when you flip it over and the R1/L1 buttons fall out
-
yes actuality i had what your testing. lol except the hole was at the bottom of the controller lol. and i had a 8 pin socket. but i believe it would be a good idea how you have it. well u just suggested to keep it open because he may not not have the materials or the setup ready. but definitely go how he suggested. except i would keep the points like common R and other connections like a different part of the board to make it easier to solder and or connect to oscilloscope. just a suggestion tho. lol also connect to Left ground if you wish in the future to have dual trigger mod. lol
Edit: i saw the pics again and yes do it like that! lol good job dude! actually im a make my controller like yours. hope you dont mind lol.
-
what kind of modder do you guys take me for!?!? lol ive put header sockets on my controller wired to r and l common power and ground with extra sockets should i want more connections to leds and such then i am in the process of soldering up a protoboard to connect to the controller with an ic socket a tact switch and an icsp header for my pic kit 2 :)
@chives how can the buttons be read digitally if they are at 1.3v when pressed?
-
what is 1.3V when pressed?
anything below 0.8V is a digital low with schmit trigger. All the buttons (with exception of start, select, ps, ect) go to ground when pressed. I have seen it work a couple of places: when using 3.0V on a 360 controller I was digitally able to determine when the trigger is pressed or not, and the triggers on a 360 are on a 1.7V line. Also on the PS3 I was able to read Lcommon buttons with BTFSS and BTFSC commands in the middle of each finger in the waveform digitally. The best way is to try those things and see what works, you can only work on a simulator and with specs for so long before you have to try the hardware.
-
hehe sorry dude. no offense with the wiring or anything. lol well ye hope to see progress. both RDC code and hyper code will be awesome. but one question hyper, what program do you use for assembly? if its mp labs there is a build in function that turns a hex into assembly. but sure if its useful. but i just want to thow it out there.
well hopefully you will get your code soon! cant wait to begin testing :tup:.
-
@ 802Chives - The Triggers/Sticks on the 360 controllers are on a 1.5v or 1.6v line, depending on the controller version. ;)
@ geraldrubalcava - As soon as I get a dead (and cheap) 80gb PS3 to use I'll get back into the PS3 Slot Loader project, would really like to finish it up one day.
I'm not going for any speed records or the bells and whistles like multiple modes and such, that's something everyone else will do, just a simple R1 R/F is all I'm after as I really don't want to invest a lot of time into something I don't go in for, which I technically have already getting to this point, but that was mainly to get it to work in the first place, which was all I was kinda after and as soon as I was able to disable R1 that was about it for me. For now it's just something to tinker with off and on and learn how to do different things, so any updates from me will probably be few and far between, everyone else will probably be done with others that do a ton more than this before I get anything changed.
Attached is the latest one for you to check out. It's not going to really get any faster than this until I learn some more coding so I can control better when R1 is masked, or allowed to fire, depending on how you look at it, but it can be turned on and off now with an external button and light up an LED to show it's on or off if you want. Any N.O. momentary type button/switch can be used, like a Tact switch, which I personally don't like and I'll probably code something different up later on so it uses existing buttons or a combination thereof to turn it on/off, but for now it's a way to turn it on/off so it can be used.
' PINOUT
'1 - Vdd
'2 - LED Cathode (can use LED2, 3 or 4 on the controller or any alternate LED you like)
'3 - COM2
'4 -
'5 - Tact Switch (other side of button/switch goes to GND)
'6 -
'7 -
'8 - Vss
-
well i will give your code a try :) but it will for sure work. your a excellent coder.
ohh well just asking. because i had a broken ps3 fat that i sold the power supply and blueray drive to get a ps3 slim (my old ps3 gave me a ylod :cry2:) so i have a ps3 shell you could use. cosmetically it aint a++ but i guess it might help you for prototyping. and i also have a old apple slot loading drive. i mention this because ive seen over at xbox scene that did a 360 with slot loading. lol so if you want i can ship it to you in a medium flat rate box.
Ohh and theres one more thing lol (all apple status). for the fat style ps3's the power and eject button are touch sensitive. but lucky i found out somewhere if i recall it was "qt115" this 8 pin chip allows you to make a touch event into a push button event. so just little help if your gonna built it.
well enough of that. lol i will get back to you tomorrow about your code :) and one question. is the tact switch code like ( if you press for 2 sec it turn off/on? or just a quick press? thank you again man!
-
I hope it 'for sure' works, since it did here already, but that's no guarantee at all. ;)
Just give the button a quick press to turn it on/off is all. I need to clean that bit of code up as well because if you hold the button down when it's off it will turn the R/F on/off real quick, but if it's on and you hold it then it just turns off until you let go, so it's almost how it needs to be, but just give it a quick press to turn on/off and it'll work like it's supposed to for now. Also it's not TriStated, so if you use it on an LED in the controller that LED will not work normally, as in when you power on the controller and all 4 blink a few times if you're wired up to one of those that one isn't going to light up for that event, but it's nothing that will cause any issue and will be sorted later as well.
I already have a few QT110 sitting around that will do the button work, touch to active Lo, and have had them for long before starting on the PS3 Slot Loader project, but thanks just the same.
Post Merge: September 02, 2010, 07:49:39 AM
Hey all, the controllers 100Hz signal isn't when running off just the batteries (looks more like 89.3Hz) at least on 3 different MSU PP 4.05 version controllers I have here. I can't say for sure yet on the later ones until I get another one to tear up and test out, but can anyone else with a PS3, O-scope and a later version controller confirm/test this also?
I noticed this as the RoF changed on me when I unplugged the controller from the PS3 and it straight up screwed the timing of other things I was trying out, so using a set time to create the R/F masking isn't a good method at all and will cause issues if the controller is ever used both ways. I'm sure this isn't going to affect anyone's code as you guys will probably be using timers and counting pulses, but it's put a kink in the way I have this setup right now as I'm just waiting them out for set times.
-
RDC I will take a look at the controller i have here... It sounds like your saying the speed of the signal changes when plugged into usb and not? I know the controller i am using isn't exactly 100hz because it has an 11.2mSec period rather then 10mSec, but i never noticed any speed changing. I will take a look and post here.
-
ohh wow. ive had actualy noticed the changing speed. and i think you can see it on the vid i posted. but i will do more testing. and im soldering up the test right now.
Edit: IMPOrant, lol how do you add a post to the news bulletin in these forums? because i got big news of the ps3. some people have made an open source ps3 jailbreak usb device and with a easly to buy usb teensy development board (similar to arduino). it has piracy disabled but it is used for homebrew! anyone now how to post it up in the news? here is the link to the original page http://github.com/psgroove/psgroove/blob/master/README.md (http://github.com/psgroove/psgroove/blob/master/README.md)
sorry if its off topic
-
RDC I will take a look at the controller i have here... It sounds like your saying the speed of the signal changes when plugged into usb and not? I know the controller i am using isn't exactly 100hz because it has an 11.2mSec period rather then 10mSec, but i never noticed any speed changing. I will take a look and post here.
Thanks, and correct. Plug your controller up to the PS3 and I imagine it'll change to 100Hz and 10ms. That 11.2ms period you have works out to right around 89.3Hz also.
Here are O-scope shots of both USB and Battery powered measuring the COM2 line at the same 2ms/DIV setting.
USB Powered @ 2ms/DIV
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi50.photobucket.com%2Falbums%2Ff320%2FRDCXBG%2FPS3%2520RF%2FCOM2onUSB2ms-Div.jpg&hash=758c4b064d1ca2c122cbd189f2dba5835bbafc51)
BATTERY Powered @ 2ms/DIV
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi50.photobucket.com%2Falbums%2Ff320%2FRDCXBG%2FPS3%2520RF%2FCOM2onBattery2ms-Div.jpg&hash=9c52b1d2d0adc4fa3265ac9cd649b9345f4f42af)
It's the time between the 3ms of 'button signal' that's actually changing, not the 500us per button speed, that stays the same. It's the duration from the Rising Edge of /\ to the Falling Edge of R2 that's slightly different, so it's 'Hi' for a shade longer (roughly 1.2ms ;) ) in between the button presses on Battery as opposed to USB powered.
-
wierd.. mine shows that 11.2mSec period either way. I hooked the controller up to my computer usb, but I can imagine how being hooked up to a PS3 makes a difference if it has something to do with charging. I will post pics when i get a flash drive from my girlfriend. I will also look at what version my controller is.
-
Plugging it into the PC doesn't change it here either, just the PS3.
-
wow... I just confirmed it and that is the oddest thing I have seen yet. cant even think of why that happens...
-
the reason might be that in order to sent the signal though the usb, the controller has to chage the frequency to match that of the system. if you guys can try and hook up two controllers to the system. this might be because the system might want to sync all controllers up. im not sure were ive heard this but it was at a controller tear down.
Post Merge: September 03, 2010, 11:48:26 AM
all right finished testing the led off/on button for RDC rapid fire and it works. the only thing is that it shoots 1 per second. but idk if you coded it like that.
-
wow... I just confirmed it and that is the oddest thing I have seen yet. cant even think of why that happens...
Just more pointless Sony voodoo. ;)
@ geraldrubalcava - Yeah that one is messed up because of the USB/Battery timing issues, it should work fine on USB. Attached another one that should work on both USB or Battery power roughly the same now.
-
Great! well i will test out your code tomorrow. sorry for the delay. Ive bin getting all glittery about the psgroove. Hum all right.i would like too see if hyper has made any improvements. But he might be waiting for his scope still.
So i will give your code a try without usb and with usb connected. we will see how it goes
-
Here are a couple more to test out if you have a chance. Also if you would, please let me know which is faster and in what game. I'm only using the Demos for CoD WaW and MW2 and testing with only single shot weapons. Thanks.
-
and no real progress my way waiting for scope but i have the controller and dev board done so i can get straight into coding
@RDC are the COD demos on the playstation store?
Post Merge: September 04, 2010, 03:47:00 AM
small update: my scope will be leaving hong kong tommorow :tup:
-
Yes they are both on there.
I'm interested in seeing how well your scope works out. My 50MHz Fluke 97 ScopeMeter isn't the greatest for messing with the PS3 controllers, though it is almost 2 decades old now, and the 60MHz Analog one I'm using is much better for this, but they each have their strong points and I couldn't pick one over the other as the situation really dictates which will work best.
-
yh well i read plenty of reviews before i bought it and nobody had a bad word to say about it performance wise and im unlikely to be doing any projects involving particulairly fancy or high frequencey signals so i think it will be ok :)
-
New one to test out if anyone likes.
Same wiring as before..
PINOUT
1 - Vdd
2 - LED Cathode
3 - COM2
4 -
5 - Button (other side goes to GND)
6 -
7 -
8 - Vss
This one has 5 Modes, but only Mode 1 and Mode 2 have R/F on them for right now, which are the same as the 2 previous hex files, Modes 3, 4 and 5 are R/F off at the moment.
Tap the button to cycle thru Modes and the LED blinks to show which one is loaded. First tap turns the LED on and R/F is enabled in Mode 1, tap again and LED blinks twice (off/on/off/on) now it's in Mode 2, and so forth and so on. After Mode 5 is R/F Off and the LED turns off, then it starts all over. You can hold the button down to cycle thru all the Modes until the LED turns off, a little bit faster way of getting the R/F turned off for right now, though not really by much.
The only real issue at the moment is when the controller is turned off the PIC R/F still runs, this is because the point used for Vdd is always on and I haven't coded it up yet to know when the controller is off to turn it off, so you have to manually turn the R/F Off either before or after the controller is turned off or LED4 will just stay on.
-
ok well i hope your scope works great hyper. and i want to see progress with the code! xD lol
RDC i tested your code of the battery/usb fix with led on/off and shots fast.
2N2 shoots fater on cod:mw2
2n3 shoots even faster ! i mean fast! wow! like amazing! lol better then the ebay chips. on mw2
The 5 modes one i still haven't tested. and i haven't tested on cod5 or world at war. lol
i will get back to you tomorrow to give the results in the other games too. lol awesome!
Edit: hey! hyper u stil wanna make a pretty inexpensive diy oscilloscope. you already have a pic programmer right? your halfway there! well if you want check this out. http://www.semifluid.com/?p=9 (http://www.semifluid.com/?p=9)
-
yeah i saw that one but looks pretty naff and i didnt have a level shifter handy to test it but my scope should be here tomorow or the day after so i should have the majority of the code done before i start at sixth form on friday
-
all right that is awesome! hope your scope works :) well i will be also here to test it out. :)
Post Merge: September 06, 2010, 06:25:55 PM
all right well ive tested RDC code with 5 modes. on mw2 and cod5. both work great! mode one is same as 2n2 and mode 3 is 2n3 i believe? well both work great with cod5 but keep the both because it one is on medium speed and another is fast speed. well that test was great! hum. i has to cycle though five modes to turn it off. well im not sure about he power but when the controller is off does the power to the analogs sticks turn off too? i mean on the newer version of the controller were it has polls. (or 4 pins) if the power to that also cuts off then you may not need to code to turn it off. well there are guns in mw2 who have burst mode. so im not sure if you want to add one of the other modes like that but wow. great work! also. If you press the button for 3 sec it turns of the rf.
well Great! i this is so awesome! well great work! and hyper i still look forward for your work too :)
-
Latest one to try out, just let me know what Mode does what best for what games/guns and such.
I'm not sure about the power on the newer controllers, honestly never checked to see if they stay powered on or not, but I will later this week as I have one on the way here that's going to be hacked up, so I'll check it before I lay into it, but the MSU PP 4.05 I'm using does, so I just coded it up now to still be able to cycle thru the Modes so you can get to R/F Off for now even if the controller is turned off first.
No idea what all I'll do with this as far as other modes and such go yet. Since I don't really have any games to test on and only these couple of Demos I can't see at all how it's doing for anything else, and that means more miss than hit and more error in the trials, so it's getting to be no fun at all at that point.
Most of these on this latest one are kinda close together, testing out what works best for what, so don't be surprised if they seem kind of similar speed wise in the same game, but they might work different in another one, but I can't tell that here for right now.
-
I got around to testing using the comparator method this weekend. for me it is more bad news than good.
Using the comparator I set it to look for every falling edge. But when looking at the common line it never sees a falling edge unless I press a button. so the buttons at rest do not create enough if a falling edge to trigger the interrupt. If I set it up on the R2 line using that as a trigger it works fine. But since I am looking for a solution to use only the common line it looks like the comparator method will not work and leaves only the ADC method.
The ADC method seems to be working very well but the comparator method would allow for a lot cleaner code and more exact changes.
Chris
-
ok thanks chris when scope finally arrives im gna try interupt on change then if that fails i will be using adc :)
Post Merge: September 08, 2010, 12:27:18 PM
ok got bored this afternoon so wrote and adc code for you to test gerald
pin3 - COM2
pin5 - an led or preferabley your oscope
pin 5 should be low until everytime the r2 pulse falling edge is detected then it will switch high for 5ms
also please upload video if you can :)
-
@ hyper999 - Pin 5 stays Lo with that code, I scoped it as well.
-
ok take two use exactly the same as the last code :)
-
You have output on Pin 5 now (see attached pic) but it doesn't matter if Pin 3 is connected or not, so your code is running regardless of the input. It's also way, way too fast (172Hz) for using an LED to tell if it's working or not. A human eye can't see the 'blinks' at that speed and with your code it just appears to be on all the time, but the scope can tell that's not the case (shown in the pic) hence another reason for needing one before really messing with this mess. ;)
-
i agree with RDC on the first led test i keep getting a constant low. and i dint check without connecting it to com2. so i guess RDC is right about it triggering without the R2 drop. and the thing with the led is true ( my eyes are not what they used to be) lol.
hum well i will test of the 5 mode one. im still testing with the two games and different guns lol so i will get back on you with the full report.
-
ok thanks for that just spotted an error in the acquisition delay
so take 3
-
Hi guys, this is my first post. I am a reverse engineer for a well known console accessories manufacturer and I have just been reading some of these comments about making a controller rapidfire.
So can someone tell me how far you have got with all of this?
This latest attachment which has been included what does it do?
I am just trying to see where we stand with things before I add my bit to this project
-
ok here we go
- orko and chives have both successfully written ps3 rapid fire codes professionally
- RDC has now done it successfully in basic
- I am in the process of doing the same in asm, however am struggling to debug my code as i am still waiting for my oscope to arrive in the mail so my only way to test is through feedback from gerald
-the above code repeatedly polls adc for the initial voltage drop then makes pin5 high for 5ms so that i can identify if i am detecting the falling edge
-
@ hyper999 - Pretty much the same deal on that one as well. The output has changed some in duration only, but the input makes no change to it at all.
If you can, code up something simple to check and make sure your PIC is configured correctly for the Analog input on pin 3. This isn't in any coding language at all, just what it should be doing for a test, something like..
START:
Get AN value
If AN value is higher than 512 turn LED on
If AN value is lower than 510 turn LED off
goto START
This way we can connect a POT up to the PIC (voltage divider between Vdd and Vss, Wiper to pin3) and see if the ADC and your code are working. Since it will be checking the AN value over and over, with the POT turned past half way up the LED should be on, turned past half down the LED should be off. If this doesn't work then something isn't configured correctly with the TRISIO and such.
-
ok have another one to try have tested this on my pickit demo board so i know the adc is working
GP0 - COM2
GP2 - Oscope
-
well my findings on hypers code is the same as RDC. subplay, at the end what matters is if it works well i can conform that in the axis controller on tp11 the RF turns off when controller is off. and in the newer models were the pot has Positive and negative. when controller is off the RF turns off. so coding for that may not be needed.
-
ok for some reasone the atattchment didnt upload properly but never mind here it is and once again
GP0 - COM2
GP2 - Oscope
-
@ hyper999 - You're getting closer now with that one, but it's sporadic, like the timing is off somewhere with the ADC. The acquisition time or your wait time before starting the next ADC conversion, but the output is being controlled by the input now.
-
i think now it is simply a question of finding the correct threshold for the adc heres the same again but with a higher threshold
-
That's a bit better, but something is causing a pretty big pause in there, see first attached pic, that's on USB power. On Battery power it's much different, second attached pic.
-
ok im gna try shotening the delay time for how long the pin is high forr down to 3ms
also i now have my scope up and running but ive never used one before so i will continue posting them up here for you and gerald to test aswell as testing myself :)
ok same as before with shorter delay...
-
There's still a small glitch in it. I've no idea how your scope looks there, but on the Digital scope here it's a little hard to see it while it's running, and on a screen shot, which is held, you can't really see it at all, but on the Analog scope it's pretty obvious something isn't quite right, but I can't get a screen shot of that as you have to see it running to be able to 'catch' it.
-
ive been fiddling and ive managed to get it pretty consistant but something like 1 in 10 pulses from pin 5 are missing and it averages out at 78hz on my scope
Post Merge: September 10, 2010, 06:14:25 PM
ok im gna call it a night now cos its 2.30 in the morning over here but do you think you could post a video of the glitch perhaps?
-
all right finished testing fully RDCs code. its a pretty similar result overall. some for faster then others. but there isnt much difference in mw2 the speeds dependent of the gun. all that mattered was just the speed programed. But for cod5:waw it did matter the type of gun you would use. But it might be because of the patch the game has for rapidfire. its limit is like 10 sps? or something. but waw game kinda sucks, only ting good about it is National Socialist-zombies. (fuggen awesome game mode) lol. i don't own any other game first person shooting game with R1 so with testing that is as far as it goes. good code! awsome speeds! i should suggest Modder Matt to add this to the list of available codes. Because its awesome! if you need me to test out any other code i would be happy to give it a go.
Now @ hyper, Is com2 connected to pin 3? and were the oscope? sorry. hum i might not be able to help you out much with he o scope part but i can show you if you finalize one code with he rapid fire. ok. well i will still test your code :) so should i test it with usb or bettery? or is that currently fixed?
one more question... Now we know how The sequence of Right common works. But is t similar to Left common? just asking. and does the adc effect if there are two inputs/outputs? because one of the neet features that would be nice would be dual "trigger" but i guess that's still for the future, lol soon i will post a vid of all the working codes and there reactions if it would help :)
-
ive been fiddling and ive managed to get it pretty consistant but something like 1 in 10 pulses from pin 5 are missing and it averages out at 78hz on my scope
ok im gna call it a night now cos its 2.30 in the morning over here but do you think you could post a video of the glitch perhaps?
Sorry man, I can't upload video of it here.
I don't know how you're having the code work exactly, so the 'glitch' could be normal, but if you're making the output trigger from the Falling Edge of COM2 remember the button presses are 500us each and it's 6 buttons, so 3ms in total, but you'll want to wait say another 1ms or so before starting the next ADC conversion or you might catch the /\ button somewhere or the Rising Edge and that will cause a problem. Waiting 4ms from the Falling Edge will make sure that you're back into the 'Hi' part of the signal and the ADC then can wait for the next Falling Edge.
The way I have my R1 Disable code done is as soon as it detects the Falling Edge it waits a bit to skip the R2 button, then sets the output hi for the duration of R1, then waits 3ms to skip the rest of the buttons, then starts all over. It's technically only 2ms for the other 4 buttons, but I have it wait 3ms so it doesn't catch the Rising Edge or /\ button, which would start the next timing run all out of whack and cause issues.
@ geraldrubalcava - The COM1 and COM2 lines work pretty much the same way and are timed the same, just the order of the buttons are different is all. It shouldn't be too difficult to make L1 fire as well and is on my list of things to try out when I mess with this again.
-
2 cents:
first I want to thank everyone who is a part of this project, everyone is working together in harmony and it is paying off. good job guys!!
secondly, I think the author of each code your developing needs to ask for it to actually be published once the author feels the code is COMPLETE. in order to publish it, you will need an actual install diagram (art team will help if needed, make a post in that section)
Finlay, I want to address the recent WAW comment. cod WAW is a aw some game. the rapid fire, once configured correctly fires much faster than anything allowed in mw2. I know that sounds hard to believe, but its not. mw2 the guns have diff limitations. which affects RF, in WAW the game its self is what is restricting RF...this means for mw2 you need diff codes/speeds for diff guns. but in WAW once you get around the game patch, all RF guns fire faster and they are much cooler in doing so.
by the way, trearch made the waw and the patch for it. treacrh are also the ones making the new game, therefor its only logical they will implament a similar, if not the same patch WAW has. as a logical person, I would advise working with that info in preparance for the next game.
anyway, good job everybody. I will begin testing next week. please let me know when you guys feel your codes are COMPLETE so they can be added to the official list.
as an after thought, I dont play ps3 much, but what about your face buttons? reading through your work so far, and how they are on a common line, I dont think it would take much alteration to make a mode for the face buttons.. similar to instafire... but thats just my 2 cents
-
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! :)
-
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 (https://www.acidmods.com/forum/index.php/topic,37459.msg280518.html#msg280518)
RDC can you say me wich is the best code now??
Thanks
-
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.
-
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 :)
-
@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 (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 AM
MAJOR UPDATE!!!!!
think ive cracked it guys!!!! :drunk: :drunk:
ok try this same as previous
pin7 - com2
pin5 - oscope
catches falling edge then makes pin5 high for ~4ms
-
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?
-
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 PM
ok heres com2 unmodified on my scope
-
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. ;)
-
@ 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. :)
-
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:
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fimg638.imageshack.us%2Fimg638%2F4152%2Fsam0026mw.jpg&hash=e00fc0cad21276c40c0b7b059c493575fe70a3b4)
Red is R2, yellow is COM2. Now lets see what it looks like when we press the R2 button:
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fimg818.imageshack.us%2Fimg818%2F2483%2Fsam0027.jpg&hash=3e4f902d6624cb42f5cba4c4e032028d5b4d4cc4)
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:
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fimg148.imageshack.us%2Fimg148%2F5513%2Fps3001.png&hash=2cd80497a14a45035925fafb44375fe53ed3341f)
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?
-
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.
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi50.photobucket.com%2Falbums%2Ff320%2FRDCXBG%2FPS3%2520RF%2FCOM2-Schematic.jpg&hash=0bf546e5e02a1e40682a86b91dacf3cf30678d26)
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.
-
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.
-
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
-
First attempt:
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fimg444.imageshack.us%2Fimg444%2F1822%2Fsam0029j.jpg&hash=b2924da1789a26f7dc345e007a555360e5bc9be2)
Nice 3 wire solution:
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fimg32.imageshack.us%2Fimg32%2F4743%2Fsam0030g.jpg&hash=fd80abb430f10ac7db4a66ff4a0968ccb8339e0e)
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.
-
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"
-
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.
-
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 :censored: so I would put it on an interrupt, but to each their own.
-
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 PM
Ok, 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.
-
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.
-
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?
-
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
-
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.
-
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 PM
so the code is finally working with comparators for you hyper? awesome! woo! lol so after this the speed needs to go faster?
-
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 AM
And yes i will work on reducing the stutter and increasing the speed tomorow
Post Merge: September 14, 2010, 03:27:49 PM
Also 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?
-
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 PM
also for modes its easyer to have a 2 sec torn off thing, then to cycle though all the modes to turn it off.
-
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.
-
@ 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.
-
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.
-
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 :tup:
-
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.
-
yea, that sucks!!
I will start testing thsi weekend. other than MW2 and WAW wuld you like feedback for?
I can test it for halo...oh wait, no I guess I cant LMAO
-
awesome thanks matt
@RDC i downloaded my disable hex from here again and saw no problem when pressing any combination of r1 and r2 ???
-
If R2 is pressed all the way here the R1 Disable 'skips' between R1 and /\ or shifts over /\ completely. Then if R1 is pressed the same thing happens on down the line, there's a bug in there somewhere.
This may not be happening on the version of controller you're using also, since the Daughter boards on them vary slightly, but it does do it here on this MSU PP 4.05 version. Really bad video of it, but it shows what's happening.
RDCXBG - hyper999R1DisableGlicth.mp4 (http://s50.photobucket.com/albums/f320/RDCXBG/PS3%20RF/?action=view¤t=hyper999R1DisableGlicth.mp4)
-
OK. Here is a simple RF at 6 SPS. This uses the counter method. Very simple toggling of the TRISIO with each counter reset. I know it works, I can see it through the PC. But two things need to be tested:
1. Is it choppy or stable in a game.
2. If you switch the power supply, will it slow down enough to notice?
I have a feeling it will be noticeable, and this test should prove it.
-
1. It's not choppy in the Demo of MW2 or WaW with the pistol.
2. It is a different speed based on USB or battery power.
-
Here is the TMR2 test. I simulated it, but did not program it and test it. It should work, but yell at me if it does not.
This uses the TMR2 interupt at a frequency of 500 usec. So it is timed to occur inside every button pulse in the pulse train. This way, I can guarantee it will consume 20 cycles in the interupt and plan for it during the button pulses. I have added NOPs everywhere to force the timing to be perfect under each condition. The ISR will take 20 usec no matter what happens during it (I simulated it repeatedly to add the right number of NOPs) and then did the same thing during the wait loops. Using the simulator, I set breakpoints at each call of the wait loop, and added just the right amount of NOPs so that each call was 500 usec apart.
So now this new code should run independant of the power source.
-
@ Hazer - I'm not gonna yell, but I don't even know where to start with how tanked that one is..
It starts off looking like it should on the scope, for anywhere form 1 to 4 seconds or so, then it holds the entire COM2 line Hi until a button is pressed kinda hard (almost all the way) and it doesn't R/F but maybe once in every 10 presses or so and even then only a few shots, if that, then the R/F is still off time when it does work. It's the same on Battery or USB also, so you should be able to see it on the scope there without even touching a button, just fire it up and watch the COM2 line for a few seconds, it's right jacked up.
@ hyper999 - That 'bug' that's shown in the video I posted, it only happens on USB power, on Battery it's solid.
-
Yup. Just found the big hole. I left the possibility that SHADOW could get updated between switching of the TRISIO inside the pulse train. Since I was using that to XOR TRISIO, if it changed it would leave the output on after the pulse train was finished and then stay that way since it would never return to the comparator.
I fixed that, noticed other possible bugs and tested it. The only thing that bugs me now is that from what I can see the speed is 3 shots per second, not the 6 I was calculating at (and even simulated). I will have to doulbe check the PR2 value later.
For now, its still a valid enough code to test the power theory.
-
Now that one is more like it there Hazer. ;)
The speed is 6 SPS here, least in 2 the Demos I have anyway, and the same on both USB and Battery.
An interesting side note about that deal with pressing the button too hard and it only firing once with the R1 disable code and even when using a semi-automatic weapon when the R/F is on, is that if you're on an automatic weapon most times the R/F is probably going to make it stutter (depending on the gun of course) but it will fire at it's normal rate if the button is pressed harder, so that 'issue' kind of works for the best if you use the button properly.
-
ok heres my disable code
you can disable any combination of buttons on com2 by changing the value of buttonsR in the asm file
it is currently set to disable r1 in the asm and hex files attatched
-
Hazer's latest code:
the full game results are the same, kinda slow for MW2, but fires very smooth and consistently. The speed is not dependant on the power source.
I too had an issue with the button sensitivity, if you slam the button, it seems to skip the RF sequence completely, however a normal squeeze, or soft press of the button activates RF everytime.
this is surly on the right track
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi370.photobucket.com%2Falbums%2Foo142%2Fmoddedmatt%2Fth_IMG_3821.jpg&hash=4f27e48d1c7607cab9672605ee8b1b404d746600) (http://s370.photobucket.com/albums/oo142/moddedmatt/?action=view¤t=IMG_3821.jpg)(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi370.photobucket.com%2Falbums%2Foo142%2Fmoddedmatt%2Fth_IMG_3827.jpg&hash=dede43de40e257c257df252aca13b0a32e6077dd) (http://s370.photobucket.com/albums/oo142/moddedmatt/?action=view¤t=IMG_3827.jpg)
-
you can disable any combination of buttons on com2 by changing the value of buttonsR in the asm file
..and then recompiling it into a new .hex file to program onto the PIC that is.
I tried it on default (R1), then just R2 and then all buttons at the same time and it seems good, that bug is gone now too. ;)
-
all right, well i will use mplabs to recompile the asm.
hazer which pin does your current code use for com2? if the same i will yest.
also i have the full game of both waw and mw2, so if there is any specific gun you want me to test like, all semi-auto? or other in a video then i would be glad to do that :)
hyper, your code fixes the speed from batt/usb?
Post Merge: September 18, 2010, 04:32:23 PM
nice work on your ps3 controller modder matt! xD lol great for debugging. truly this is going in the right direction :)
also RDC, are you going to be working on your code or are you looking at hypers code at the moment? just wondering the status of different codes
-
As I have said, I believe the reason that pressing the button too hard is due to hardware limitations of the PICs output pin current. This cannot be overcome with code. To prove it, someone put a 500 Ohm resistor between COM2 and pin 6 and see if the code works no matter how hard you push.
geraldrubalcava: Com2 is connected to pin 6 of the PIC (GPIO1).
My intentions were to show how to get the comparator to work, and that it has a much faster and stable reaction time. I also wanted to find a way to overcome the power problem. My last code needs some cleanup and has redundant instructions to get rid of the bugs RDC found. The intention is to show how to get this done.
So now here is the real question: Is anyone going to even bother looking at the code structure I provided? If not, just tell me what you want the chip to do and I can give it a week and do it for you. Simply give me the design requirements. I dont care about speeds. That whole 'fixed speeds' from the X360 days was retarded. THe final code needs to be self edittable. Hell, if the battery can provide enough power, I can make it configure through RS232 and not even bother changing the PC utility I made for the X360.
So whats the endgame here? Flex? Akimbo? Macros? RS232?
I dont have a PS3 to even test on. I cannot even charge the battery. I have to plug this into my PC USB port just to do a simple verification and look at scope signals. If you want to learn how to make specific functions, tell me what they are.
-
well the code you previously posted will help out alot of people in this forum. so i dont think is useless. It will be a great asset here. You were able to fix the speed and power buggs. thats so awesome.
I agree the hole "preset" speeds. ridiculous. but according to game informer, the ps3's most popular game is mw2 for 5 consecutive weeks. so that might be a target. hum well it would be great to have akimbo too. but can the pic12f683 do rs232? or TTL. well if its reprogrammable i belieave it would be better on the ps3 because with com1 & com2 you can control most of the controller. so this might be a good thing :) hum also in dealextreme there are 1800mah batterys, so power consumption is not a problem.
well after all my mumbling...
if would be good if there are different codes. ie,
1a)one with modes,
1b) editable by Pressing the Change button for 3 sec then pulling trigger to change speed(for some people that might one it, may be me too lol)
2:) well it should include akimbo.
3) a code thats reprogrammable by rs232 or other form of pc communication. with a usb to rs232 adapter it would be great, but might be difficult for certain users.
so it might be kool to have two versions for the ps3. one for solid performance and other for people who have the materials to reprogram. im not sure if you would like to do this but i just generalized users to two category.
-
hazer i glanced at the code structure from your tmr2 code but i struggled to understand it but i will give it a propper read later
also i think rs232 is overkill for this altho i would likke to see an rs323 code as i am very interested in learning how to use it
my plan was to make use of the awesome dpad on the ps3 controller to edit the settings in a similair way to flex
-
i agree its overkill, but! i would still like to see this happen. i was thinking of adding a special port to my controller around were the leds are at. i was thinking of something similar to the contacts of a cellphone battery, then on a charging station have the prongs like a phones contacts. (if you get what i mean) then it might be as easy as just plug it in to the station, connect it to the com though usb serial adapter (build in to the station) then boom! lol.
But a better alternative would be something similar to flex like hyper said. but the idea with the dpad would be awesome! but i still believe we need a extra tack button on the bottom of the controller to change the modes , or put them into program mode or something similar. it might be easier to do what hyper said because if you are able to read com1 line then thats a good way to reprogram. hum...
hyper, how about if the d-pad increases by 10 sps when you push up and decreases 10 by pushing down, & pressing left and right change the speed by 1.
it should have a led. so i believe we should brainstorm in how we think we might need the RF.
-
my plan is to have it like so
hold tact then use left and right to cycle modes, down for quick on off, and up to enter programming mode
-
actually that is a great idea! but would during gameplay will move the game? but actualy i would prefer "pressing tact for 3 sec it turns off" Quick press, turns on/switch modes. Programing mode is a quick press with a tact and on the up dpad to enter programing.
or like having 3 pre-program modes & a 4th mode with programing. and it saves to the eeprom.
hum but your idea is still awesome! just have to work if it will interrupt the gameplay, and or how fast you can turn off and on. it does matter during gameplay to not interrupt to turn it of or switch modes.
-
yh actually that would be better just tap the tact to turn off/on
@hazer im up to speed with your code now and am gna try and intergrate it with my latest code but am struggling to think of ways i could repeatadly read a swith to add modes and such without totally destroying the timing. well actually thats not true i know how to do it but am unsure on how to write it atm but il get there eventually atm im basicly atm trying to deal with mode change, leds and switch debouncing in <500us
also i have some ideas to test and would really apreciate it if you posted your counter test source code
-
well i would be happy to test your codes hyper. as for assembly, i started studying ... but im still lost lol
well the ides of using dpad to modify/ reprogram a mode would be great! but as i heard, ps3 code is much smaller than the 360 code, so there might even be enough room for all sorts of creative stuff. :)
hyper i would suggest to get mw2, or in November cod7 (black ops). because it might be the funnest game yet. tey will try to compete with mw2 multiplier and also include "special co-ops" maybe National Socialist zombies :)
-
The tact button test would easily be placed during the time the comparator is waiting for the falling edge of R2.
After that, you would create flag that lets the code know you are in program/switch mode and use that to test button presses on COM2 and COM1. In order for that to happen, you will have to change the wait loops to half the time so you are testing the COM lines in the middle of the pulses.
I am personally biased to the Flex code, so I will not offer any opinion beyond that. I will say however that changing the config through RS232 is MUCH better than any kind of onboard editting code. If you get to the point where you can pull your speeds from the EEPROM, I will show how easy it is to add the serial coms using just 2 resistors.
But first I will need to test that code with the 2.8V power supply from the controller. It should work, but testing it is better than guessing.
-
anyway on a side note just thought i should point out my aims for this code. I am doing this project for fun and as a test of my newly learnt assembly skills so i cannot promise any deadlines. I plan to make a code like bmu and then end up with a code similair to flex but a bit more user friendly, but i will release the source code whatever i end up with. and on the subject of rs232 i would like to learn how to use r232 for a number of other unrelated projects i want to try :victory:
Post Merge: September 20, 2010, 01:32:58 AM
kk am working on making a bmu like code from hazers counter test now
Post Merge: September 20, 2010, 01:37:38 PM
here is a 1mode test i have no idea how it will work as i have no means of testing atm but connect like so
pin8 - gnd
pin6 - com2
pin5 - tact switch - gnd
pin3 - negative side of led
pin1 - power
use like so tap the switch to switch between off and 6sps, simples :)
and please feel free to check up on the code
-
ok i will test your code tomorrow :) i already had it set up like that so this is ganna be a good base. hum well if hyper is ganna work on a bmu code for a ps3 i guess Hazer could make a rs232? i think it would be a good idea :)
do you want a vid for conformation that it works? :) well for the ps3 there might b a lot of possibilities in store.
-
kk cool dnt really need a video though unless it does something real crazy just test that it turns on and off and that when its on tht it shoots at 6sps
and for rs232 i think the plan is for hazer to test if the controller battery can provide enough voltage (not mah ) for it to work. after that i think (hope lol) that he is going to teach me how to add it to the code when i get to the stage of loading speeds from the eeprom, which if the code i posted above works, should be within a week.
as for possibilities they are pretty much endless and the 12f683 can provide more than enough memory for this.
-
so the code above is a able to read the speed from the eeprom? aweosme! well the ps3 controller puts out 3.7 so im not sure if it might ne enough for standard rs232. But for TTL if im not mistaking it can work with lower voltages. humm
well then i guess vids are not needed lol :) exacly what part of cod6 is the demo? what guns can you try out? well il get back to you on the results.
-
I will do a quick test on the on/off led this evening. with my test controller (pictured above) it will only take a matter of seconds to test just about anything. I ported vdd,gnd,com1,com2, l1,l2, r1,r2 out to the test board mounted cleanly on the back of the controler. with that setup, I can wire/rewire anything you guys throw at me and the controller is still completly usable. you cant even tell its there
-
this code doesnt load from the eeprom but if it works its easy enough to add if my code for the reading the button works i need other people to test this as i have no tact switches atm and only have the cod 6 demo i just need to know if it turns off and on by pressing the button and if when its on it still fires at 6sps
-
ok, the speed is about the same, but its very choppy. the button does nothing. the led does nothing
-
agree the tact switch does not do anything. the led nether. its choppy but i guess that is what you would expect of 6sps. but it was a even choppy so it might just be the speed. :)
-
the fire rate is being chopped up, its not smooth like hazers code was.
hazers code was
f.f.f.f.f.f.f.f.f.
your code is
f.f...f.f.f.f...f.f....f.f.
-
for the led by does nothing do you mean always on or always off?
Post Merge: September 22, 2010, 01:14:21 AM
kk here we go wire up same as before also i managed to salvage a button so tested my self so i know the button and led work just need you guys to verify this and check for choppyness again lol
p.s i wanted to just quickly get this done so led pin switches between hi and lo not lo and tristate but il sort that in a bit
Post Merge: September 24, 2010, 05:42:52 AM
hmm what has happend to this thread just as we are nearing the finish everyone seems to have died lol
Post Merge: September 24, 2010, 03:03:56 PM
also when reading up on r232 and serial comms and what not i stumbled upon this
http://www.uchobby.com/index.php/2009/10/04/diy-usb-to-serial-cable-for-3/#more-492 (http://www.uchobby.com/index.php/2009/10/04/diy-usb-to-serial-cable-for-3/#more-492)
and i believe this cable operates at 3.3v so the ps3 battery should just be able to provide enough potential difference for the converter to recognise a high signal from the pic
-
im not dead still here :) lol wll ive bin bizzy with some term papers but finally out for a week1 xD (thank god for spell check!!)
hum exactly! the type of signal is called ttl and its what arduinos use to communicate. it can also operate at 3.3 v so this is potentially a way to work. hum its true, seems like no one else wants to post anymore. but modder matt seems to take a interest on this project. well hope people still contribute :)
Post Merge: September 24, 2010, 04:32:49 PM
also ima try your code right now :)
-
also try this
same setup up but
starts up in off mode
mode1 = 6sps
mode2 = 4sps
mode3 = 8sps
although i think by the way the signal looks on my scope the last 2 speeds are backwards
-
i will be glad to try it :) hum. well hope this thread will still live. its bin a lot of work to die off like this. and we have posted a lot! so come on guys! we can finish this! well be gald and i will post the result of the other test too :)
-
less posty more testy! lol
and yes if this code works i should be able to release the ps3 bmu equivilent sometime tomorow.
-
kk sorry :) be with you in a bit, have to turn setup testing :hifive:
-
kk asap please
-
ok i tested the second code and the led dint seemed to work nor the RF. so im not sure. did it work for you?
-
Per hypers request: The source code I used for RS232 comms is at this link:
http://www.codeworks.it/net/VBNetRs232.htm (http://www.codeworks.it/net/VBNetRs232.htm)
and I used Visual C++ Express to build it. Attached is RS232 routine ripped from my final project. I dont want to share the original files for a couple of reasons: First, it has a simple encoding/decoding algorythm embedded in it that I use on more than one code, so sharing it would be bad. Some of the encryption is hardcoded and would take quite a bit of time to remove. Also, if I posted the entire thing, others would be able to rip my PC utility for thier own creations without doing the leg-work for that. Instead, I included the bare basics for RS232 comms using 2 resistors and no level comverting. Its quite nice as it works for 5V and 13V RS232 (except that some 13V recievers will not read from the PIC if it powered below 3.3V).
A quick explanation of the code: The main routine checks the recieving pin (pin 4, the one that is only good as an input) to see if the RS232 port has sent the START bit. once it does, the RS232 routine takes over and enables the watchdog timer. The whole routine is simple wait-loops at just the right moment for 14.4KBps 8N1 serial comms. The watchdog timer is there to make sure the PIC does not get lost or validate glitch voltage levels on the recieving pin. I use a FLAG bit to keep validity. As long as the transmission goes through flawlessly, only then will the PIC record the values.
What I did not include here is that I send back all of the bytes to the PC after recieving them and perform another verification transmission as redundant verification that the correct bytes were sent. After all of that, I would then save everything to EEPROM. Your choice if you want to build it. Again, I took it out as I dont want to share all of the details of how the original PC util works, and also its alot to get working so just get the basic transmission tested before adding in redundant verification.
The link above shows the Visual program I used. If you know any PC programming, it should take very little time to convert it to work with the PIC. A good program for debugging this stuff is called Docklight. You can use it to see RS232 transmission in realtime.
I will check back form time to time to see how its going and answer questions.
I dont plan to add much in the way of finalized code. I would just be doing all the work againand get nothing from it. Insteaed, I will be using what free time I have reversing the USB source code so I can start using that for furutre projects.
Have fun.
-
Thanks hazer your the man!
@gerald are you sure you wired it up correctly as i have tested on gh and rf and led work i just couldnt tell how stable the speed was :/
Post Merge: September 24, 2010, 02:33:17 PM
well ok just to make sure the hex i uploaded was ok i downloaded it from here my self and programmed it straight into my setup and it still works for me.
how ever on my setup im not using the controller led as i forgot to wire that to my header and cba now but i have an led on my breadboard wired like so pic pin - resistor - led - vdd which i believe is the same setup as in the controller?
but here is the setup again just in case
pin 1 - Vdd (+)
pin 2 - unused
pin 3 - tact switch - Vss (-)
pin 4 - unused
pin 5 - 100 ohm resistor - led
pin 6 - COM2
pin 7 - unused
pin 8 - Vss (-)
at power up it will start in off mode press the tact to switch modes
mode 1 - led turns on - 6sps
mode 2 - led blinks once - 4sps
mode 3 - led blinks twice - 8sps
like i said befor by looking at my scope i think the speeds for mode 2 and 3 maybe backwards.
i know this setup and code works because i have it working right here in front of me but due to my lack of games i cannot see how stable the speeed is
Post Merge: September 25, 2010, 07:00:57 AM
just tried it on the mw2 demo with a usp and all seems good :hifive:
-
that was my mistake! lol i wired it like pin 3 is led and pin5 is the button. lol sorry. well that's a good way to test the chip. the usp in the game is pretty good with the hole rapid fire. ima text out today with other guns. and i recommend you getting a game. mw2 is a good game. even the single payer. its awesome overall.
-
Orko: 0.8V is the digital high threshold for a schmitt trigger, so R2 is not a digital low to start. all the buttons on Rcommon and Lcommon can be read digitally... I know because I have tested it.
just wanted to clear up some misinformation in my post from way back... i am currently writing some code and had the triggers on a 360 controller that were 1.2V when pressed not register using a schmitt trigger buffered pin like I claim in my post O_o so I broke out the spec sheets and found out that it is the TTL buffered pins that I was able to read digital values of trigger pulls between 0-1.2V
Those are the two digital buffers available on Pics, and the TTL is more forgiving with lower voltage readings and incidentally what I used for both PS3 and Xbox button readings.
the 12F683 only has one Schmitt trigger pin (GP2) so you shouldnt have any problems reading the button presses on a PS3 digitally using any input but GP2. If you move to a bigger chip PORTA tends to be all ST and PORTB tend to be TTL. See the Pinout Descriptions (usually table 1-1) in the spec sheets see what buffer the pin uses for what funciton.
-
@ chives that makes everything make more sense after you told me most of the inputs were schmit trigger i looked it up on the data sheet but tht said they were mostly ttl which greatly confused me lol
as for the previous code i found that the speeds for the last 2 modes are backwards but that is an easy fix
i will probably start a new thread for the code later and submit it to the code list
then im gna learn visual basic and work on a pc app
-
ive tested your code and it seems wo work prity good too:) yes the last to modes are reversed but its working a ok :) i would suggest to keep working on the code tho. because he seems to only want a code that is fully finalized. But if you want a simple code with 3 modes. then this is is a good choice. he dint want to accept RDC code, also is akimbo rapid fire in the future too?
-
i am gonna release the code as it is as a sort of beta and akimbo will be in the future
-
this is great. its going to be a good beta. and hopefully this can develop more! i will be here to test. looking foward for it. and i believe once the code its in its final stages it can be presented to modders matts list. :) well awesome job tho. and i will still look forward for some work on a code with serial communication with a pc :)
-
i will releasse this code as is for v1 as for a simple r1 rapid fire mod this is very good this will help point out any bugs with the code as is
you should think of this code as a building block for the future
v2 will be akimbo and rapid any button
then i will work on things like burst fire, macros, and rs232
Post Merge: September 25, 2010, 05:12:15 PM
thread for release of V1 can be found here
https://www.acidmods.com/forum/index.php/topic,37606.msg281507.html#msg281507 (https://www.acidmods.com/forum/index.php/topic,37606.msg281507.html#msg281507)
-
unless anyone else wants to post useful information in this thread i guess it might be dying. But i would really like this thread to be pinned. mainly because it offers so much information and the process of how the ps3 rapid fire works. so it might be a useful archive of info :)
-
just thought is there the same patch on waw as there is on 360?
Post Merge: September 26, 2010, 06:34:27 AM
just about to start on akimbo
-
the code list is for final codes. The code list requiers a new topic that will only discuss that particular code. I have not had a chance to test the new code, but I will, and I see you have a new thread, so your almost there. now as for the akembo and rsss/burst. I sugest continuing development here. and once that part of the code is added and complete, name it and issue it as a new code, those are too big of changes to be considered a code revision. We learned this from the development of topfire, the thread gets too diluted and confuses the user. the name v2,v3,v4 etc are reserved for bug fixes. and I will need to be told when a v2 is ready so I can update the main download package.
RDC's code is welcome just like anyone elses, but it must meet the requierments, new topic, named code, and final version (with the exception of bugs) I amnot sure he is ready for that, if so, please let me know. any questions please feel free.
-
can someone do me a favour and test the code in the other thread cos i cant seem to get it to work but am unsure if this is something i have done to it in code or if my test rig is playing up again or both?
-
i would test your code. but modder matt changed it a different place and it not letting me go there. not sure whats happening. but i would of i could
-
the code in the other thread dont work. post removed until its updated. I assume its the same as this one?
the code in your other thread: (PS3-3 mode opensouce.hex)
led acts same as this one (see below)
RF dosnt exist in any mode
code in this thread: (hazeredit3mode.hex)
the led is not right
the rf works, but your modes are wrong values as stated
LED problems:
turn on controller, led lights instantly, but RF is off
press tact once, led goes off and in mode one around 8sps
press tact again, (led is off due to above) led blinks on once then back to off state, RF is on around 15sps
press tact again (led is in off state due to above) led blinks twice, rf is around 6 sps
mode one and three are smooth, mode two is choppy as hell im mw2. not sure if this is your speeds or ingame programing. I have a feeling your sppeds are being edited as apposed to using the value of FIRERATE in your code, but IDK
@ hyper, kleep development here until its finalized
-
@gerald did you find the same thing with the leds as matt in any of my codes? and what controller version are you using?
@matt what controller version are you using? and are the leds on your board common positive? and yes mode 2 is probably just too fast
Post Merge: September 26, 2010, 02:12:33 AM
ok try this rf is working again same speeds but mode 2 and 3 are the right way round now
so..
off
6sps
4sps
8sps
and led should be working but i was told that leds on all board revisions were controlled via ground?
-
ok, thats a bit better.
led responce:
controller first powers on=led state off, rf state off
press tact once, led lights, Rf around 8-10 sps smooth
press tact again, led blinks one time, rf very fast (too fast a bit choppy at times)
press tact again, led blinks twice, 6 sps steady
as seen above the led is now working properly, but the mode count flash is wrong, when it goes into mode one, it turns on, so when going to mode two it should flash twice, then when going to mode three it should flash three times.
-
the led flashing was intentional and i personally prefer the leds as they are but its easily changed if you think most ppl will prefer it or i could do it like flex (my favourite) and the first speed should be the same as hazer's 6sps code?
-
uh... you are going to get alot of complaints about that. the flex format is good, but this is on one pin and is a flash count system, and the flash count cant count. it should be like bmu3
-
il get it done in a minute it will only take a second as already included the code for up to for flashes i just didnt use it
Post Merge: September 26, 2010, 12:07:51 PM
done however i just pulled the header off my test setup oops!
-
well im not sure if peole are going to complain. this will be one of the first R1 codes. so i dont think people should demand alot from it. but i guess this can be changed easily. well i will test your code too. hum i have to buy some more 12f683 chips. because the last one got stuck in my programmer and the pins ripped. so ima scavebge for one or buy another from a us seller.
Post Merge: September 26, 2010, 07:03:02 PM
unless this code can be ported to the 12f629? because i have some of those. but i will still look for the other :)
and all of the boards LED's are common positive. :)
-
What Matt is refering to is that FLEX uses two LEDs for on-board editting. Hyper will need to add another LED in order to copy that.
But here is a trick I used for my final RF: You can light 2 LEDs from one pin and create 3 colors. If you connect the anode of a gree LED to VDD, then connect the cathode of that green LED to the anode of a red LED and also the PIC pin, then ground the cathode of the red LED, you can have 3 colors from one pin. Make the output high, you light the red LED. Make the output low, you light the green LED. Make the pin output hi-low @ 100 Hz and you have yellow. Make the pin an input, they are both off.
The hard part is controlling all that with flashes. But it can be done.
-
Genius! lol. but if you want to turn off the leds or any specific combination will effect the controller or any part of the code?
-
that was what i have used before with other projects and is my preffered choice but unlike with the 360 controller i cannot think of where in ps3 shell you could put the leds apart from an extra 0603 by the current p4 led but tht would be a pain to solder
@Gerald
1. this cannot be ported to the 629 as it requires timer 2
2. turning the leds in this config off is not a problem we simply tristate the pin which efectivly disconects the pin from the circuit
3. it would be great if could you come up with some ideas as to where the leds could go for that method?
also my serial cable came today :)
-
if you want it like flex, just piggy back p3 and p4 leds. if you want it tricolored as hazer said (harder to install) i would put them in the ps button. if its just count based, enerhize p4 led like normal.
-
hum well aawesome! so did you get a RS232 cable or TTL cable? because one uses +-12v and other 5v so it might be important. well it might be easyer just using p4 led, or p3+p4 led. but as for the ps led mod. depnding on your controller version, it might be easyer or more dificult.
-
what does that mean? Is english not your first language?
-
its a 3v ttl nokia phone cable i got for £2.50
Post Merge: September 27, 2010, 06:11:24 AM
think im gna modify the code to like flex tommorow but which method do you guys prefer? And has anyone tested the code then i have been too busy playing halo reach :tup: to fix my test rig
-
well no its not my first Language. but i would love to see a serial rapidfire :) woo! lol
-
also matt just a thought but do you think there is anyone in rnd that would be interested in helping and could make a pc app when we get to that stage? cos i know nothing about programming beyond pics lol im learning vb but its not going well
-
posibly. lets get this code finished and released then start changing it.
as for where we are:
no change in Rf, the led is another story, needs a bit of work.
when the controller first powers on, the led and rf is off
press tact once, led comes on and then it blinks once and stays solid, RF is in mode 1
press tact a second time, led has no change, RF is now in mode two
press tact a third time, led (which is on from before) blinks blinks twice and remains lit. RF is in mode 3
press tact again and led goes off, and so does RF
-
kk matt thanks went back and found a stupid mistake fixed now and tested kinda but what is everyones opinion on the speed of the flashing? and are the modes the right way round? should be
6sps
4sps
8sps
Post Merge: September 29, 2010, 05:17:50 AM
@hazer ive just been reading through your rs232 source and just wondering am i correct that this code recieves 13 bytes and save them to the first 13 ee registers? and what resistor should be used?
-
yea, we are so close. the rf numbers look good. as far as the proportions, I cant tell if they are acuratly 6, 4, or 8. mode three seems to be faster then 8. but mode one is mid speed, mode two is slower, mode three is fast.
when controller first comes on, its off
press tact once, light turns on and then flashes off then back on (need to just come on)
press tact a second time, light flashes twice (this is good)
press tact a third time, led flashes three times.
you can leave this, or I advise to take the flash out of mode one.
-
oh i thought that was what you were asking for il take it out and post it up later when i finish seting up my new breadboard
-
cool fix that and this standard 3 mode RF is ready for release!!!
-
done
Post Merge: September 30, 2010, 02:19:10 PM
so yeah i guess its time for names ppl
any suggestions? cos i dont really care lol
-
lol well ive tested and its a ok :) lol well one more suggestion, instead of cycling though 3 modes to turn off seems a little impractical. is there a way to make, pressing the button for 2 sec turns the rf off? well by itself its awesome. lol
Post Merge: September 30, 2010, 02:57:47 PM
as for names, hum ps-flex? idk. lol names people! xD
-
I could but its a pain to do and i would rather spend the time doing akimbo and rs232, also i personaly think that would be pointless as it only takes a split second to turn of atm regardless off what mode your in and can it really be that hard to keep track with only 3 modes?!
-
its this in like PS3BMU, everything seems to be in order 1am4.hex
its three quick clicks, not impractical. if it was 13 modes it would be impractical
-
hey hyper999 I was told you needed my help. stop all your coding and hit me up you need to completly change direction.
-
Just my opinion, BMU was a stealth code. Since this code uses a tact, you should code it like gameplay:
Quicktap of tact = on/off toggle
Hold tact for 2 sec = change mode
Just sayin.....
-
I will probs do a code like gamplay rf when i have akimbo done cos for now its easy enough as it is
also i will port hazers interupt routine onto my disable code this weekend to give us akimbo and what not
also do any buttons other than r1 r2 l1 and l2 need rf?
-
wow, you have made a great job guys, hyper the connections would be like this???:
pin 1 - Vdd (+)
pin 2 - unused
pin 3 - tact switch - Vss (-)
pin 4 - unused
pin 5 - 100 ohm resistor - led
pin 6 - COM2
pin 7 - unused
pin 8 - Vss (-)
I have thsi PCB:
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi50.photobucket.com%2Falbums%2Ff320%2FRDCXBG%2FPS3%2520Six-Axis%2520and%2520DS3%2FMSU_V25105Bottom.jpg&hash=fb9d0e750c09d99658ba5291f4bf0eb9b7a278ac)
The point i have to use in Pin 6 (COM2) its TP26 but i dont know if its right. In this pic would be the point near TP40??
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi50.photobucket.com%2Falbums%2Ff320%2FRDCXBG%2FPS3%2520Six-Axis%2520and%2520DS3%2FNewSixAxisandDS3.jpg&hash=e0e3ab59ba36b3f5d31a27ea9ed1097322888254)
I want to test it this weekend
-
Yes tht list is correct and i have some nice install diagrams for when we release the code
-
Yes tht list is correct and i have some nice install diagrams for when we release the code
Thanks for the reply, i will try it in my pcb this weekend but i will wait also for your pics
Only one question more. The resistor is obligatory?? I say this becuase i want to check the code as soon as i can but i dony have resistors now and i would have to buy it lol
-
the resistor is not obligatory but recomended however you could use pretty much any resistor up to like 1k but this will affect the brightness and if you have no reasonable resistor now i recomend you put one in asap just to be safe cos resistors are pennies, pics are pounds, and pads are expensive!
-
i recomend you put one in asap just to be safe cos resistors are pennies, pics are pounds, and pads are expensive!
wow I love that quote!!!
-
ok, i will put the resistor after to close the controller, to test it i dont put it.
Can you say me if TP26 is the correct point of my PCB??
Thanks hypper and matt
-
@matt i was feeling poetic lol and just to let you know me and system/cyberpyrot :S have started talking about the pc app
@rally here are the pics
-
Thanks hypper and matt
the only part I had was late testing and bug reporting. I think credit also nees to be given to hazer and rdc also as without them I dont think this project would have got off the ground.
-
so is there anything else you want changing or should i update the other topic?
-
I think we are done here. release it and then we can start to revise it as you mentioned above.
-
hum true without hazer or rdc we cold of not do this. well hum, in the future if you do add more modes then the 2 sec tap on/off mode is ideal. but right now its fine as it is :) well hope this thread will still live for development like rs232 and future goals :)
-
ok just so we do not have a repeat of last time try this should behave the same as the last one
@gerald i will make sure i keep this thread updated with progress info and what not
Post Merge: October 01, 2010, 11:46:08 AM
i have updated the release thread so if this works you can move the thread back whenever you like
-
Just for further reference for the RS232 code I gave earlier, I took the design from the Picaxe download cable. You can find it the ssecond schematic down on this page:
http://dave.fraildream.net/picaxe/pxhwser.shtml (http://dave.fraildream.net/picaxe/pxhwser.shtml)
Its the one that uses the combo of a 10K and 22K resiators. That breaks the RS232 transmission to the Pic to acceptable voltage levels. The recieving side gets wired directly to the Pic since its output is already at a safe voltage level.
You can confirm the schemtic on page 7 of the Picaxe manual:
http://www.rev-ed.co.uk/docs/picaxe_manual1.pdf (http://www.rev-ed.co.uk/docs/picaxe_manual1.pdf)
I would also suggest using Docklight for troubleshooting. Its a real neat freeware program that manipulates the RS232 port of your computer, and you can even setup automatic transmissions based upon set specific byte strings.
http://download.cnet.com/Docklight-RS232-Terminal-RS232-Monitor/3000-2218_4-10103185.html (http://download.cnet.com/Docklight-RS232-Terminal-RS232-Monitor/3000-2218_4-10103185.html)
I would try setting up a single byte recieve followed by a single byte transmission to confirm what got sent. Use docklight to test the results multiple times. You will probably find that not every transaction works perfectly. Hence the reason why my original code recieved every byte, then echoed them back and then waited for a final verification byte. Otherwise, it would dump the entire transmission and reset itself.
-
thanks hazer but as i am using a usb serial cable with in built level converter your code doesnt work for me so i decided i should write my own routine as id learn more that way so i did and i now have the pic efectively acting as a loopback. so now im trying to write what the pic recieves to eeprom im just wondering if you know how i can veiw the eeprom on my pc via the pickit2?
-
A USB-Serial cable does not 'level convert'. A level convert changes the RS232 standard to TTL. That means it changes both voltage AND polarity. Here is what I mean:
For old-school serial ports on desktops, the voltage swings from -13V to +13V. But idle the voltage stays negative, and the start bit goes positive. The '1' bits are negative voltage and the '0' bits are postive.
USB-serial converters (and most built-in serial ports on laptops) have voltages that swing from 0V to 5V, but the polarity is the same. So, the same as above where idle is 0V, '1' is 0V, and '0' is 5V. This works because the legacy RS232 standard above is supposed to be tolerant from -3V to +3V.
An RS232 level converter changes everything to TTL. With TTL, idle is 5V, '0' are 0V, and '1' are 5V. The voltages and the polarities change. This level converting is usually done with IC chips and usually require a circuit with a few capacitors. There is no 'black-box' or 'USB' versions of these.
The code I provided looks at the voltage levels of the RS232 standard directly (and hence removes the need of the TTL converter). The 2 resistors are there to break the 13V swings down to 3V swings and current that the Pics IO pin clamping can tolerate. The code itself bit-bangs the serial 8N1 completely backwards to any other sample code because most other codes expect a TTL converter to be used.
thanks hazer but as i am using a usb serial cable with in built level converter your code doesnt work for me so i decided i should write my own routine as id learn more that way so i did and i now have the pic efectively acting as a loopback. so now im trying to write what the pic recieves to eeprom im just wondering if you know how i can veiw the eeprom on my pc via the pickit2?
Good to hear you wrote your own. If you have a Pikkit2, you can either use the direct pickkit2 utility or MPLAB to read the chip . In MPLAB you can read the chip and then view the memory in VIEW->EEPROM.
-
Yes my adapter changes the polarity and the levels to 3.3v ttl
so from my adapter a '1' or the stop bit is +3.3v and a '0' or the start bit is 0v
although really it doesnt convert as it doesnt put out a rs232 standard signal even if i wanted it to
and yh i tried using the view eeprom thing in mplab and i keep getting crazy values but i know tht the transmission carrys out correctly becaues after it saves to eeprom it returns the value back to the serial port correctly but il work on it some more today
Post Merge: October 03, 2010, 10:47:28 AM
also with docklight i have found i get a 99%+ successful transmission rate
-
Sounds like more of a problem writing to the EEPROM, not the transmission. Especially if Docklight shows the bytes being echoed back from the Pic.
-
yh thats what i thought but i am using your routine from bmu3 so it should work right?
-
It should. I take it your coding in assembly now then? Or at least using _asm _endasm in C?
The only tricky thing about writing to the EEPROM is that you have to wait for the EEPROM to finish before writing the next byte. It takes awhile (in Pic terms) for each byte write to finish. The code I have in BMU3 waits until the EECON says its finished. If your not working with MPLAB, then I cannot confirm if your comiler is doing the same thing?
-
erm assembly is the only programminng language i know??
but anyway heres the jist of my code
Start
call Rcv
movwf TEMP1
call XMIT
movfw TEMP1
call WriteEE
goto Start
WriteEE
bsf STATUS , RP0
movwf EEDAT
movlw 0x04
movwf EEADR
bsf EECON1,WREN ;Enable write
bcf INTCON, GIE ;Disable INTs
btfsc INTCON, GIE ;See AN576
goto $-2
movlw 0x55 ;Unlock write
movwf EECON2
movlw 0xAA
movwf EECON2
bsf EECON1, WR ;Start the write
WaitForEEWrite
btfsc EECON1, WR ;wait for hardware to clear (done writing)
goto WaitForEEWrite
bcf STATUS , RP0 ;Bank0
bsf INTCON, GIE ;Enable INTS
return
Post Merge: October 04, 2010, 09:38:17 PM
also hazer i dnt suppose you know of any good learning resources for windows programming for absolute beginners?
Post Merge: October 06, 2010, 01:11:33 PM
scrap that last post just giving you all a small update have started learning c# and am well on the way towards a pc app
-
so no one manged to make you a app? hum well how are you going to start? visual basic?
-
Nah cyber pyrots gone so hes not doing it and im learning c# essentially have the app done but am struggling to convert the sps value the user enters which is a decimal to a 8 bit binary value for the counter in the pic code
-
Nah cyber pyrots gone so hes not doing it and im learning c# essentially have the app done but am struggling to convert the sps value the user enters which is a decimal to a 8 bit binary value for the counter in the pic code
StringToHex
-
@hazer sorry i dont understand what you mean (im a mega noob with c#) could you show me an example use?
waht i need to do is (1000/[an sps value like 9.15]) then output the answer of that rounded to the nearest integer. restrictions of the form ensure the answer will always be greater than one and less than 255
ok as for the pic side of things try the attatched hex setup as normal but all 3 modes now have 25% dutycycle ive set each mode to a different speed around 10sps so let me know which works best
-
Ok guys, I have tested and the first and the second mode with the Grehwer and when you finish the firs charger, the second one shoot blocked by the patch. I think the speeds are too faster, but the third mode works fine. I have made this video:
Cod waw RF test (http://www.youtube.com/watch?v=Djfb52F7pNQ#)
Then i think PS3BMU could be:
Mode 1: 8sps - Cod 4
Mode 2: 10sps - Cod MW2
Mode 3: ?? sps (I dont know wich speed has used hyper) - Cod 5
Hyper I think you could edit the topic including this new .hex code and the .asm but you would have to say that in cod waw the speed needs to be wich you have use.
-
mode three is theoretically 9.5sps but did you test online as the video was offline and as im sure you know the patch only kicks in when playing online
Post Merge: October 10, 2010, 06:56:52 AM
also @ hazer again the eeprom problem seemed to just be the pickit2 reading the eeprom wrong it reads itself fine
-
Yes i know, this video its online in private match. In fact, with the others modes I have been blocked in a private
-
kk am just about to edit the official thread
and have setup the hex as you asked
-
Ok :hifive: i think these are good speeds but i someone test others speeds wich think are better could post it here
Post Merge: October 10, 2010, 08:56:16 AM
Hyper, I have problems with the new code. I tell you:
The speed for Cod WaW you have put (9.5 sps) is blocked by the patch. Do you remeber wich speeds put in the other code? Maybe 9.5 isnt in the mode 3. But doesnt matter because is a small problem that changing the speed will be fixed. The mainly problem I have is the following:
When you posted the new code to test it in Cod waw, when I installed it the tact switch didnt work. I touch the PIC and the modes changed. At first I thought "I have made a bad soldering". But now when I have intalled the new code you have posted (with the right speeds), it happen me the same I have checked the wires and resolder it again but nothing then I have decided to change the PIC but dont work yet. The tact switch only works if I put the finger in the leg of the PIC. I have made a vid to show you:
Fail in the installation (http://www.youtube.com/watch?v=g6IgD0BYBfU#)
I dont know why happen this but would be when you add the duty cycle?? Its very rare
Can anybody do the installation to see if happen the same??
Do you know guys if MPLAB works in MAC?? if not, do you use any program for it? I say this because when I want to change the .asm I have to use my old laptop
-
that looks like a bad conection somewhere im fairly sure its not the code also i suggest installing a socket in your pad for easy re programming
as for mplab i dnt know if it works on mac but there may be other pic asm compilers
-
I have done the connections twice and with differents pics and happen the same. I will wait if someno test it
-
what happened there is you not grounding that leg witch when you touch it you grounding it yourself have you connected the tact wires side by side or oppsite try removing the tact and touching the 2 wires on the tact toghether
-
I dont think so because in fact the first time I checked the code with the duty cycle, i just desolder the wires of the pic (with the other code worked fine), reprogrammed the pic and soldered it again
But i will try what you say
-
did you install it to the correct diagram?
-
Yes, i did but didnt work. I will check it again tomorrow. Maybe its a bad connection but its rare because i have changed the wires, the PIC and the tact switch and fail with both.
-
well i since in the other thread you have had a problem with it it might be with your truble shooting. but hopefully you will get the rf working. ima test it tonight and do some research on different games and guns. also there might not be a speed patch because ether sony dint approve. eather because of gamestop products witch have a turbo mode. or because there isnt people with rf in psn anyways. many reasons why there isnt one, but thus, this is good! :tup:
-
well i since in the other thread you have had a problem with it it might be with your truble shooting. but hopefully you will get the rf working
Yes I hope finally works fine for me lol
there might not be a speed patch because ether sony dint approve. eather because of gamestop products witch have a turbo mode. or because there isnt people with rf in psn anyways. many reasons why there isnt one
I dont know sony didnt approve it but there is a patch. When I get home i will do a new vid showing it
-
hypre, please dont edit the release thread, until I have had a chance to test your new codes. we dont want the same mess as last time do we? and we seem to be getting a bit of wishwashy feedback. If the patchis properly bypassed, 11.5 sps will not be patched.
-
Ok guys, finally my controller is working!!!. I just put some flux and resolder the leg and.... you know the end. You are right guys (i look like a noob lol). Matt I have an issue, would be possible that the patch on the PS3 has differents speeds to be blocked? I say this because with 10sps its blocked. Here is a vid:
Rf cod patch (http://www.youtube.com/watch?v=6212Nw4Z3_Q#)
Hyper I have checked it with 9.5 sps and works fine. I had to use the incorrect mode the first time
And as gerald say in the released thread, leds work at the following way:
Off: Led on
Mode 1: Led blink once and turn off
Mode 2: Led blink twice and turn off
Mode 3: Led blink three times and turn off
-
well thats fine then we just need someone who can recompile the code to play with cod 5 speeds a bit more it should work the exact same as on 360 as i copied and pasted the patch beating code directly from the bmu source
as for the leds it sounds like they are different on different versions which is a pain cos it means im gna have to cram in a 50% hi low duty cycle and all that :censored:
Post Merge: October 11, 2010, 08:31:35 AM
update on serial i think ive cracked the pc app so tht should be done soon but i may not release a full rs232 version yet as i plan to sell them on ebay to earn back what i spent on an oscope first
-
I have ordered some pic sockets on ebay. When i get it, it wold be easier for me to test the codes but in the code there is now would have to check the own code because in the speeds, with 9.5 you arent blocked but yes with 10
-
can we see a video of 9.5 sps please
-
can we see a video of 9.5 sps please
Ok, i have an update. When I was recording a video with 9.5 sps I have been blocked by the patch again. I think with this speed you are blocked sometimes and others no. I have made a video in wich I started shooting at 8 sps and I am not blocked then change to 9.5 I finish the first charger and in the second one I am blocked:
Testing diferents sps (http://www.youtube.com/watch?v=uNglKqiilDc#)
-
hum so you say that you get the shooting patched on some and sometimes not? well, did you try different guns? it might matter. well i would suggest more testing to see if there are consistences. :)
-
No, I only have tested with the grewher. I have tested it 4 times. 1 and 3 i didnt be blocked but in 2 and 4 yes
-
did you hold the trigger whilst reloading?
-
Ohh I dont remember. I will test it in both ways (holding and no)
Post Merge: October 12, 2010, 02:36:23 PM
Ok guy I hane tested the code again and today has worked for me. I am trying it pulling down the trigger while was reloading and just pullin down when finish reload and works in both ways.
I dont understand why sometimes works fine and others no
-
when you say works do you mean the whole code or the cod 5 duty cycle also have you tried the code i posted in the release thread to fix the led problem?
-
I mean the duty cycle mode 1 and 2 works fine in cod4 and codmw2
I dont have tested the new code yet
-
thE only reason it wouldent is if the patch is different in some way as the code is exactly the same as the 360 version although id imagine it is quite likely to be different as during normal operation the triggers on ps3 have a much smaller voltage swing? If so surely the waveform is going to be more squarewave than one from a 360 trigger and a different duty cycle may be needed? I think i may pm chives later to see if he can enlighten me
and please do test the led fix code
-
its going to also be slightly affected by the preasure sinsitive buttons.
-
kk i have put the release thread back to the origional release code so here is the
latest version for you guys to test
-
hey matt, i hope i wasnt one of the "new guy" you were talking about. ive tested and it worked. hum. i have cod5 too. so is there any specific modes you would wish for me to test? also do you wish for me to make a full pdf in how to install the chip? it might help you the new comers from your other thread.
-
Dude, I've installed the RF on a pin socket. The pic programmed with the previous released bmu code is working well beside the led problem. The new pic programmed with this code is not working. The board is a MSU_VX_4.0 this might be the problem. And I am not new with installing RF. I have tested all the codes mentioned in acidmods official free code list.
-
@gerald, no its ok.
@ hyper, the origional code is going into the code list. when you get waw working you will have a new release thread and a new code for the list. akembo would be another new one (unless you choose to combine thoese two together.
however, once a release thread is published, it should not be changed. (unless someone drew the diagram wrong) I have linked about 10 other sites to that code, and put my name behind the fact that it works. If you cahnge the code, my word that it works cannot be honored as I have not tested it. Just like any other code in the official code list. I have tested them all.
I hope everyopne understands.
-
also RDC confirmed for me all ps3 pads have common anode leds
Post Merge: October 13, 2010, 09:08:42 AM
ok heres what needs doing now i need people to test the previous code and see what the max setting you can have using this code on cod 5 with the duty cycle enabled and then what setting on cod 5 without the duty cycle
-
hyper i could of told you that already! xD lol well thats good. i understand what matt is trying to say. well this is the third revision to the original code correct? well when ive tested i believe it was the second revision. akimbo might be next. but what are the duty cycles for cod5? it may not be the same like 360. this is another challenge we will have to overcome :)
Post Merge: October 13, 2010, 09:12:17 AM
hey hyper, ive recently moved to a mac and still setting up windows. so i dont have mplabs to compile the code. but you think you can post both hex codes you would want me to test and i can give u a fast answer?
-
wtf is with everyone getting rid of windows for mac atm!?!?!? but for you to find out the max speed with and without the duty cylce i would have to post more hex files than i am willing and able to so i will need someone who can compile the code to do it also the code posted above is what was on the release thread before i changed it to the origional
-
Dude, I've installed the RF on a pin socket. The pic programmed with the previous released bmu code is working well beside the led problem. The new pic programmed with this code is not working. The board is a MSU_VX_4.0 this might be the problem. And I am not new with installing RF. I have tested all the codes mentioned in acidmods official free code list.
Anybody else tested the new code on VX_4.0?
-
Yasin if its not working youve installed it wrong
-
Anybody else tested the new code on VX_4.0?
Hi there, i recently bought a new controller and it seems to have the same coding on the PCB (VX_4.0). i experienced pretty much the same problem as yasin did.
The first system worked besides the LED mistake. Afterwards it stopped working. I doubt that the problem is a installation mistake.. i triple checked the wiring and there are no accidental short circuits.
Could anyone test the rapidfire on a VX_4.0 controller and see if it works?
-
hum ive not tested the newer code, so i cant conform this. i will get back with you once i tested it.
-
WHere to start: First, when you RRF a value, you divide it by 2. In your code, you divide by two twice then add that to FREQ. So your adding 25% extra to FREQ, and not changing DWELL at all. Thats not realy a 25% duty cycle. You want to divide DWELL by 2, and FREQ by 2 just before adding it. That is a 25% duty cycle.
Also, at the start of the interupt, you should force to Bank 0 before checking the FLAGS register since you do not know which bank the PIC was in before the interupt occured.
And when you declare OPTIONS at the beginning, you are setting the name of the GPR address, not the value of what is in OPTIONS. In otherwords, when you do a BTFSC of the OPTIONS you are actually checking registers 0x00 and 0x01. Also, you declare COD5 equal to 1, but the value in OPTIONS that you had meant to represent the COD5 bit is actually bit 0.
I do not know how these things would effect the RF not working, but I do know you are not actually peforming any changed output signal (25%).
-
Well now i feel like a lemon lol but thanks hazer i have nearly done the pc app so when its finished il clean up this code and maybe add l1 l2 and r2 cos the codes a mess
however the code in the release thread is working correct?
-
Yasin if its not working youve installed it wrong
The code is tested by 3 users on a VX4.0 board.
All these testers are reporting the code is not working on this vx4.0 board.
Nobody here confirmed the new code is working on a VX4.0.
And you are still saying that we are installing it wrong..
You only want to hear positive feedback.
I'm out dude.
-
yasin how can you say that i only want to hear positive feedback have you seen the rest of the thread 90% of it is about how my previous codes have failed then i have read the feedback and tryed again for example just this morning hazer pointed out my mistakes did i say " hazer you cant read! im always right! ", no. and no offence but i have trouble trusting feedback from people with less than 10 posts with no known experience in modding that i have never worked with before
Post Merge: October 14, 2010, 01:54:38 AM
i replaced the old release thread cos it was messy i can now guarantee that the hex there is 100% working and as per matts request i will leave it alone :P
this weekend im gonna start a fresh so i can put in r2 l2 l1 support and fix the errors hazer pointed out
-
yasin, I think you missed the resolution to your problem, in the release thread the schematic was posted wrong, as pointed out by rafaliyo86 the origional drawing had the tact switch on the wrong pin. and that created the results you were experiancing. the diagram has been fixed rewire your tact to pin three (not four) and all should be good. the test points and leds all operate the same from the vx3 to the vx4 and I have personally teste the vx3 and found it to be in working order.
please rewire your tact switch and post your findings clearly.
-
ok looked through the cod5 code it and ran out of fingers when counting the mistakes lol so heres take 2 hook up the same as the origional
all three modes have been set up for cod 5 around 10sps just let me know which works best
-
I wont be able to get cod 5 until sat sorry.
-
matt am i able to post links to files in the rnd storage folder to here?
just wondering because i made a nice little pc app to help noobs calculate values for speeds for this code
-
its fine, when you post post it like this:
[url=insert link here]clik me[/url]
-
PC app (https://www.acidmods.com/RAND/upload/files/upload/SpeedCalcbyHYPER999.rar)
heres the pc app just have a play let me know what you think, calculating the speeds the normal way is better but i think this will really help the noobs out there but i just made it cos i was bored lol
windows only i think and requires .net framework
Post Merge: October 15, 2010, 11:53:08 AM
ok my findings on cod5
*the hex code posted above gets capped
*without the bmu v1 origional code (50% duty cycle) smallest value for firerate that doesnt get capped is .122 so theoretically just over 8 sps
*with the 25% duty cycle the smallest firerate value you can have is .100 however if you just constantly hold down r1 through reloads and stuff this will eventually get capped but with a firerate value of .102 you can shout all your ammo without letting go of r1 and you will not get capped
im just cleaning up the code then i will post it here
Post Merge: October 16, 2010, 04:32:56 AM
ok tested all working 100%
as default
mode 1 - 10sps - MW2
mode 2 - 9.9sps - COD5
mode 3 - 8sps - COD4
but i left cod5 mode on in all of them so they all work with cod5 aswell
in the source code change speeds as normal and adjust the option setting just below the firerates in the asm/text file to turn on/off cod5 duty cylce then recompile in mplab
same pinout as usual
-
PC app (https://www.acidmods.com/RAND/upload/files/upload/SpeedCalcbyHYPER999.rar)
heres the pc app just have a play let me know what you think, calculating the speeds the normal way is better but i think this will really help the noobs out there but i just made it cos i was bored lol
windows only i think and requires .net framework
Post Merge: October 15, 2010, 11:53:08 AM
ok my findings on cod5
*the hex code posted above gets capped
*without the bmu v1 origional code (50% duty cycle) smallest value for firerate that doesnt get capped is .122 so theoretically just over 8 sps
*with the 25% duty cycle the smallest firerate value you can have is .100 however if you just constantly hold down r1 through reloads and stuff this will eventually get capped but with a firerate value of .102 you can shout all your ammo without letting go of r1 and you will not get capped
im just cleaning up the code then i will post it here
Post Merge: October 16, 2010, 04:32:56 AM
ok tested all working 100%
as default
mode 1 - 10sps - MW2
mode 2 - 9.9sps - COD5
mode 3 - 8sps - COD4
but i left cod5 mode on in all of them so they all work with cod5 aswell
in the source code change speeds as normal and adjust the option setting just below the firerates in the asm/text file to turn on/off cod5 duty cylce then recompile in mplab
same pinout as usual
wow hyper i envy your job!! you got it and with almost 10 sps. I will test it also
-
envy my job? i dont have a job :S
when i clean up the code it will probs be 10 sps but ive lost track of the nops and stuff so il work on that soon but this will do for now
Post Merge: October 16, 2010, 07:34:22 AM
@ hazer ive just come up on a possible genious idea if i was to rewrite the code and use timer0 for the 500us delays because this runs regardless of the isr then the length of the isr doesnt matter so long as it takes sub 500us yes? what are your thoughts on this?
-
envy my job? i dont have a job :S
when i clean up the code it will probs be 10 sps but ive lost track of the nops and stuff so il work on that soon but this will do for now
Post Merge: October 16, 2010, 07:34:22 AM
@ hazer ive just come up on a possible genious idea if i was to rewrite the code and use timer0 for the 500us delays because this runs regardless of the isr then the length of the isr doesnt matter so long as it takes sub 500us yes? what are your thoughts on this?
Oh sorry man, when i say job i mean this code
I have played this afternoon to cod5 and works very nice
-
Thats not a bad idea. You would start with it off until the comparator triggers, then set it up for the 500usec. Then in the main code you could do whatever you wanted without worrying about counting cycles. Just perform a bunch of tasks (manipulating IO) and then wait for the TIMER0 flag. You wouldnt even need the interupt to be on, just poll the flag. Then reset the timer for each pulse.
That would work.
-
thanks it just came to me when i was tidying up the code as i normally use tmr0 for all my delays and yeah that would be ideal but i had trouble with polling the flag in my disable code still to this day dont know why but its easy enough just to xor it and test the z flag but i will try both tomoro
Post Merge: October 16, 2010, 09:31:55 PM
@hazer just tryed replacing the the delay routine and took out all the nops in your 6sps code but it didnt work when i polled the flag :S but it did work when i used the xoring method :) so il work on this now
-
Hello everybody,
Thanks for your reasearch ,it's great ,I will test that in the week-end...
I have a suggestion for your source code : use timer instead of a lot of nop it is most precise (trust me^^)
What compillation do you use ?
For the rapid fire on L1,why we can't take the same software ?
The commun 1 is different than the 2 ?
-
hi
this project is pretty dead now but..
-if you read the information in the thread you will see that the left common line is in a different order although it should be pretty easy to do i never got round to it as not many people are interested and i play 360.
-as for the timer i started using timer0 for the delays in the code just before i gave up because it means the isr can be as long as you want whereas with the nops we had to ensure the length of the isr did not push our total delay over 500us, however, although using the timer0 makes the code neater in this instince im pretty sure its not more precise than using nops.
unless of course you are talking about using a timer for the actual rapid firing in which case yes we are using a timer driven interupt
-and finally by compilation i asume you mean compiler which is MPLAB
-
thanks for your quick answer
Sorry for the question about commun line but after 12 pages of reading (I'm french) ,I forget something (important) so I'm looking on it...
OK for the compilation but they are another compiler which is mikroelectronika and I love it :laughing:
You say you play 360 but on the 360 the rapid fire is finish so what you say ? You play on the 360 for the rapid fire ? and I think a lot of people are interressed but they don't know this website :angry:
I can't help you for programmation because you programme in ASM and me in C but if you continue the project ,I can test all you want =)
Another question for add another mod,in your source code,I add a fonction FLASHON and FLASHOFF and another state and at the end that
"
btfsc FLASH, OFFX
call FLASHOFFX
"
and that
"
ONX EQU X
OFFX EQU X
"
And that all ?
Thanks
-
to add more modes would take alot more coding than that
- the mode selection routine would need alot of work as it only allows for 4 states atm
- and you would need to add subroutines for how many flashes you would want
as for continuing the project i'm done for now but i may pick it up again someday in the future
-
ah so it's not cool I must learn the asm :laughing:
So if you have to spend time please spend it on that because learn a language don't take 5 min...
And thanks for all
My dream is make an apply windows which we choose the number of mode and the firerate and click on make .hex and here we go like that
http://dagmentar.free.fr/ (http://dagmentar.free.fr/)
-
NVM
I found it
sorry for the post
-
I wonder why poeple keep thinking that making an entire hex file is the way to interface a chip to the PC? For starters, none of the 8-pin pics are self-writable (they cannot write thier program memory). This means new hex = remove the chip to program it. The second thing is that all you need to change how many modes and firerates are a handful of bytes, which are VERY easy to send over serial comms and stored in the EEPROM.
-
beats me lol
-
yasin, I think you missed the resolution to your problem, in the release thread the schematic was posted wrong, as pointed out by rafaliyo86 the origional drawing had the tact switch on the wrong pin. and that created the results you were experiancing. the diagram has been fixed rewire your tact to pin three (not four) and all should be good. the test points and leds all operate the same from the vx3 to the vx4 and I have personally teste the vx3 and found it to be in working order.
please rewire your tact switch and post your findings clearly.
Modded Matt and Hyper.
I am on Yasin's side on thise one,
I have a VX4
i installed the same mod twice linking the
places to the corresponding colors on this image attached
i also linked the LED up correctly and the switch correctly using a socket so i can reprogramme the chip quicker.
The problem i am facing though is not being able to use the Push Button to change modes. It does not change when i press the button. I have checked multiple times and installed it over and am still facing the same problem. Any help on the VX4?
Thanks for all your work so far
-
what pin is your tact conected to?
-
It's connected to pin 3
-
How come this is dead?
-
the final code is completed and awaiting admin testing
-
skittles, remove your tact and just touch the wire to a ground point to see if you can make it change modes.
Hyper, please link me tot he code???? I thought we were moving forward with a new project. I will have some vacation time next week to finish alot of open projects i have going at the moment
-
yes i am moving forward the code that i need you to test was finished last month check out the bottom of reply 332 but no need to rush if your busy :)
-
tried that Matt,
i recently though saw that a user on the PS3 BMU V1 posted a new position to connect the wires to on the VX4
i will try that and get back to you
-
Sorry I've bin absent for a while. Well skittles, I've tested on dat board and its working fine. I realy don't see problem did you dubble check ur connections? How about with a multimitter to see if there is a good connection? Is it modes turing on or not at all?
-
gerald, can u post a picture of where you are connecting each wire on the Vx4 board, because maybe i am soldering to different points which is leading do a different condition between my board and yours, but i dont know.
And yes i have solder it twice with two different sockets with 30avg wire on both times,
i used the hex code "PS3BMU.hex" if that makes any difference
Thanks gerald.
-
hyper, these codes all need some work. we have two threads. this one, and the PS3BMUV1 release thread. we need to get them both corrected. I will post the notes for V1 in the V1 thread as this thread has passed into the V2 phase. (V2 posted in reply #332)
two key notes on both projects. on v1 you used pin 3 to change modes, with v1 you are using v2. this is very confusing. also noticed more in the v2 code then before in the v1 is a bouncing effect. you need to "debounce the input" do you know what I mean? the chip needs to make sure it the button was really pressed and not just static (I think thats what these guys are tallking about when they touch the chip. (static giving a false ground.))
ok, V2 bugs:
1) RF speeds are backwards from what youve listed. mode one is the slowest, mode three is the fastest.
2) the led is :censored:ed, when you first turn on the controller, the led is ON constant and RF is OFF, press the button and the led turns OFF and the RF enters mode1. press again, the led blinks twice then back off, rf enters mode2. preass button again, thed blinks three times then back off. Press button a last time LED turns on (constant) and RF is OFF.
3) activation button is on pin2????!!!! pin needs debounce programing.
I will post V1 findings in the PS3BMUV1 thread the keep the confusion down. please make sure to post the ASM as well as any new code revisions.
-
still got problems..... it may just be me tho, anyone else got problems?
-
:tup:
I'm only on page 6 of this thread--but the reading of it and the process you guys went through in testing is more interesting than what lead me here in the first place.
Hopefully, by the end of the thread, I'll still remember to get my gf's rapidfire going for her, but she may have to wait....
To be honest, I want to get more info so I can be a part of something like this in the future, but I havent read enough to ask pertinent questions yet.
-
well thank you, :) and all this work lead up to Hypers code. hope this informs you how alittle more into what created that code :) happy reading
-
I finished reading it and then started looking around the forum--YES! Instructions on building a PIC programmer! I have an eeprom programmer, but I couldn't find the 12F683 config in the programmer app's options. Maybe the 12f683 is 'the same' as another PIC?
Either way, made a stop at Radio Shack and no PIC's there--went to Fry's and the closest PIC I found was not to be found on the shelf. They were also out of the switching diodes. I will have to wait for an eBayer to send them to me.
Then, I'm going to go through the code and see if I can decipher some of it.
This is great--nice forum.
-
no PIC at radio shack. get them from ebay, mouser, or microchip.com as for the diodes and the programer. they are off the shelf parts at the shack. have fun
-
no PIC at radio shack. get them from ebay, mouser, or microchip.com as for the diodes and the programer. they are off the shelf parts at the shack. have fun
Thanks--got most from Fry's and depending on when I receive a PIC, I'll drop by the local Radio Shack for the switching diode.
The programmer, I'm just going to put together from the instructions here.
Lastly, no new updates here, it seems. But, if I can just get an idea of what everyone did in this thread and duplicate the results, maybe I can contribute on another project--This was an excellent read. :tup:
Oh... already got winpic and mplab installed... just got to wait for a pic to play with.
-
i need some help with 2 ps3 controllers.
i have downloaded the PS3BMU__2_.zip from the free codes list and installed the chips in to two separate controllers.
my problem is that the rapidfire hardly works. it will sometimes work for 24hrs and sometimes not at all.
i keep having to disassemble the controllers, try new positive/ground points and see if it works.
usually the rapidfire flakes out after only a few shots or cycles through modes.
i installed the chip using the supplied 5 wire diagram.
am i missing something here? i really need some help here. im totally lost as to why the code doesnt work.
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi795.photobucket.com%2Falbums%2Fyy231%2Fk0mpresd%2F0fc4563f.jpg&hash=b8f2972b49e6b3d46f6cf271d26686e5ce9ae114)
-
I dont remember exactly but I think there was a problem with the diagram. The wire wich goes to the switch was the leg 2 not 3.
But ask to hyper he could help you
-
thanks for the reply. i dont think thats my problem though. as the chip seems to switch modes fine.
everything seems fine really, just only the occasional rapidfire. :dntknw:
-
thanks for the reply. i dont think thats my problem though. as the chip seems to switch modes fine.
everything seems fine really, just only the occasional rapidfire. :dntknw:
Well, if you could post a vid it would be better
-
Well with the pic i see somthing wrong already. Ypu put the power to the pic wrong. Uou don't get it from the motor. (Red wire. ) you get it from da analog stick
-
Well with the pic i see somthing wrong already. Ypu put the power to the pic wrong. Uou don't get it from the motor. (Red wire. ) you get it from da analog stick
i took it from the analog stick first. neither controller worked. i moved it to the motor and both controllers rapidfire started working and then both died about 24hrs later. the chip changes modes but the rapidfire does not work.
-
In addition to what geraldrubalcava said, I'd say that if the problem is intermittent, you have a problem with the actual soldering. Try re-soldering everything. It may be just one dirty solder point.
Of course, it could be that one of the wires are bad... Works until the controller gets jostled a bit and breaks connection....
Post Merge: February 25, 2011, 08:15:47 AM
i took it from the analog stick first. neither controller worked. i moved it to the motor and both controllers rapidfire started working and then both died about 24hrs later. the chip changes modes but the rapidfire does not work.
Hmmmm, maybe you could just re-solder both ends of the COM2 points?
-
the wireing diagram in the free code list has been verified and confirmed working by myself before it was posted. except for on version 4 of the controller. there were mixed reports about the v4 controllers.
the chips are static sinsitive as well as heat sensitive, your hot glue may have damaged the chip.
-
i have done tons and tons of x360 controllers and never had a problem. these ps3 controllers are the only issue ive ever had.
Post Merge: February 25, 2011, 11:18:54 AM
Post Merge: February 25, 2011, 08:15:47 AM
Hmmmm, maybe you could just re-solder both ends of the COM2 points?
should i try just soldering to r1 instead of rcommon?
-
nope must be COM2/RCOMMON
-
thanks for all the replies. i just really do not understand why these things flake out so much. ive wasted so much time on them already.
-
that is odd. what v is ur controller? the white numbers on the back right hand side.]
-
vx3.07
-
Just looking at your photo again--I was thinking, what if your COM2/RCOM wire is getting pinched or shorted? If the modes work but the rapid-fire doesn't, then it's got to be something to do with that connection... This is assuming that none of the rf modes work in any scenario and that you didn't modify the code so that it shoots faster than the games allows for....
On a side note, received my PICs! I gotta try it out tomorrow. So looking forward to it.
-
a question why im getting a error when i click the link ?
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fimg684.imageshack.us%2Fi%2F96427398.png%2F&hash=1ba5116e452743a851078ed7e5ab365c396c065d)
-
a question why im getting a error when i click the link ?
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fimg684.imageshack.us%2Fi%2F96427398.png%2F&hash=1ba5116e452743a851078ed7e5ab365c396c065d)
I think I have the same problem--I just looked through the free codes section and found it.
On another note, that guy in your sig... is he Armenian? In Sweden? Looks like this guy my gf says Swedish radio plays even though he sings in Armenian/Swedish/and another language (English? :dntknw:)
-
Just to re-iterate: The power in the picture is way wrong. Just wire it like the diagram. The only board having problems was teh V4.0.
Now, I would highly suggest removing all of your wires and throw them out. Next, glue the chip to the main part of the controller, not the back shell. You are obviously pinching wires, and theres a good chance that the solid core wire your using has been broken inside the wire jacket causing intermittant operation. Glue the chip to the side where your wiring will not move after your done soldering.
Try that then get back yo us.
-
Just to re-iterate: The power in the picture is way wrong. Just wire it like the diagram. The only board having problems was teh V4.0.
Now, I would highly suggest removing all of your wires and throw them out. Next, glue the chip to the main part of the controller, not the back shell. You are obviously pinching wires, and theres a good chance that the solid core wire your using has been broken inside the wire jacket causing intermittant operation. Glue the chip to the side where your wiring will not move after your done soldering.
Try that then get back yo us.
:tup:
-
Just to re-iterate: The power in the picture is way wrong. Just wire it like the diagram. The only board having problems was teh V4.0.
Now, I would highly suggest removing all of your wires and throw them out. Next, glue the chip to the main part of the controller, not the back shell. You are obviously pinching wires, and theres a good chance that the solid core wire your using has been broken inside the wire jacket causing intermittant operation. Glue the chip to the side where your wiring will not move after your done soldering.
Try that then get back yo us.
im about do this right now. thanks again for all the suggestion.
Post Merge: February 26, 2011, 01:56:50 PM
eh?
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi795.photobucket.com%2Falbums%2Fyy231%2Fk0mpresd%2Faee091c7.jpg&hash=3b94e581658e6832617de5f03d431c0fd950f587)
Post Merge: February 26, 2011, 02:25:38 PM
ok. heres a video. i 100% rewired the controller as you see in the pic above. i tested it, worked ok. tested again, worked ok. let it sit, come back to it, no rapidfire.
so i moved the ground wire to the ground point you see in the video. tested, worked ok, then same thing happen.
the video starts with the rapidfire NOT working.
might want to right click, save as. its ~185mb i think. i4 records in 720p, so its a big file.
http://mycarbl0ws.com/IMG_2219.MOV (http://mycarbl0ws.com/IMG_2219.MOV)
-
Just saw that you tested while open...
but, did notice that the wires are being pinched somewhere--one (for the tactile button) was clearly "pinched" or "shaped" by something. If so, I assume others are also being crushed or whatnot.
or, did you re-use the old wires from previous? You said you re-did the wiring but did you reuse the old wires?
-
what do you mean? i never reassembled the controller if thats what youre asking.
-
what do you mean? i never reassembled the controller if thats what youre asking.
sorry, yeah, i made the reply before seeing the vid
-
i used all new wiring. if it was shaped by anything it was from my holding it or maybe moving the controller around a bit. i never put the controller halves together. i am 100% confident that the wires are being pinched and broken.
-
i am 100% confident that the wires are being pinched and broken.
well that'll be why its not working then ;) LOL
have you tried a different PIC?
-
I have to admit--this is perplexing.
No one else has noted problems like this, so we're missing one thing k0mpresd has done differently.
-
well that'll be why its not working then ;) LOL
have you tried a different PIC?
haha. ;) wow, i just read i totally missed a word there. :drunk:
i havent tried a new pic. but both of these controllers act the same. so i doubt its the pic.
i installed the mod in to a different controller almost 2 weeks ago now. i used the supplied diagram and this controller had the same problem UNTIL i switched the ground wire from the spot next to vdd in the diagram to the spot in the video you see i used for ground. i talked to the owner of that controller a few days ago and he says it works perfect.
to me it seems to be a power supply issue.
just for reference im using a gq-3x to program the chips. before when i first started doing x360 installs the programmer was programming the config bits wrong (hazer helped me diag that one, thanks for that). but ive done a lot of installs since then after they updated the software and all seems ok programming wise.
-
I recall reading, early in this thread, that if a button is pressed hard it would not rapidfire--was that issue resolved?
-
it was not and will not be fixed. and it could posibly be contributed to what he is experiancing. there is no way to eliminate the preassure sinsitve buttons without cutting the trace and using a transistor.
-
Actaully, thats is not the case.
What is going wrong with kompresd install may or may not have anything to do with the PIC. Its still up inthe air.
As for the problem with the buttons being pressed too far, there is a simple fix that no one ever tried. Simply put a resistor in series, say 150 Ohms. It should have no effect on the comparator reading, but will keep the current draw on the IO pin from maxing out.
-
so i should try a 150ohm resistor on the wire going to r-common?
-
EDIT: :#1: 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 (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.
why im getting a error when i click the link???
-
SO! I got this all installed and running. Worked on the first attempt (PIC programmer, programming the PIC, wiring....)
That is awesome and not to be said about my 'skills' -- The tutorials and information available here is just great.
-
I should mention that I believe the code found at https://www.acidmods.com/forum/index.php/topic,38069.0.html (https://www.acidmods.com/forum/index.php/topic,38069.0.html) is not the latest code that hyper999 made up though--he had a later version which I read that resolved different issues. I will go back in this thread to find it and try that one out.
-
I should mention that I believe the code found at https://www.acidmods.com/forum/index.php/topic,38069.0.html (https://www.acidmods.com/forum/index.php/topic,38069.0.html) is not the latest code that hyper999 made up though--he had a later version which I read that resolved different issues. I will go back in this thread to find it and try that one out.
that is the latest released version of the code and it works fine when installed correctly...
-
i feel so much better about myself now since dudes up there works. lol. and the other controller i did works ok too. :dntknw:
-
i think im gonna re do this mod but better in the summer now ive got my oscope and everything sorted nthis time it will have l1 aswell and serial updating
-
i feel so much better about myself now since dudes up there works. lol. and the other controller i did works ok too. :dntknw:
Well, if it makes you feel any better.... look what hyper just said right after--seems I didnt install mine correctly.
It does work, but the LED must be wired wrong--dont care atm. my gf is happy as-is. she loves the zombie game in black ops.
-
i totally see what hazer is saying about the button issue.
i installed a new pic tonight and had to wire (again) to the vibrate motor for the rf to work. but its working consistently again UNTIL you press the button too hard. then it stops.
im going to get a resistor here in a few minutes and wire it up to see what happens. *hopefully* that will fix it 100%.
-
so i put in a 150ohm resistor on the wire to rcommon and power cycled both controllers and ran through the modes a bunch of times and neither cut out. is it possible it was overloading the pic and it was crashing?
-
so i put in a 150ohm resistor on the wire to rcommon and power cycled both controllers and ran through the modes a bunch of times and neither cut out. is it possible it was overloading the pic and it was crashing?
kinda overloading, but not causing the pic to crash, but when the button is pressed so hard , its resistance becomes so low it causes excessive current drain on the output pin of the pic preventing it from being able to hold the common line high, the adition of the 150ohm resistor increases the resistance between R1 and the pic and prevents the excessive current drain.
(I think atleast i'm still learning but hazer or someone can confirm)
-
k0mpresd
please give it a day or so, play hard with the controllers and report back. if this has solved you problem without any adverse side effects, the install diagram needs to be corrected so this is not an issue for others. although I have never experianced this myself I dont play playstation, I have a ps3 and tested these codes, but i play xbox when I am gaming, I only rent games games for my big sony blueray player fr testing. i personally hate the way the ps3 controllers strain my hands.
thanks for the bug report.
-
i mean each time the rf cut out, if i removed a power wire (positive or ground) and reattached the wire, basically power cycling the pic, the rf would start working again. this is why i assumed the pic was crashing or shutting down for some reason.
with the addition of the resistor, neither controller seemed to flake out. though, i tested the white controller in the video a lot more than the 2nd controller, but if one works, i assume the other does as well.
i dont own the controllers but im sure the owners will be quick to report if they crap out again.
-
Will a 100ohm resistor work also? (I suppose I could look through the thread and find where it was posted that the voltage drops and then plug numbers into ohm's law to see--but even then, i wouldnt be sure that i did it all correctly).
I'm just wondering if 100ohm would on one extreme end and if 150ohms is like a value in the middle possibly?
-
100ohm would probably work although you can use a combination of 100ohm resistors to make a 150ohm resistor if you want
----100ohm----
like so [PIC]------100ohm----| |----------[RCOMMON]
----100ohm----
either way trying a 100ohm resistor will not harm your controller so give it a go...
-
100ohm would probably work although you can use a combination of 100ohm resistors to make a 150ohm resistor if you want
----100ohm----
like so [PIC]------100ohm----| |----------[RCOMMON]
----100ohm----
either way trying a 100ohm resistor will not harm your controller so give it a go...
I was thinking the same thing--just trying to avoid doing that if poss. I'll try it with just the 100ohm and see if any issues arise. Thanks for the quick reply.
Time to program the pic for my gf's controller. Then, she can stop wanting to use mine. btw, no issues (other than LED) on my controller regarding this, but her controller is newer.
-
The reason for the resistor is that the button is basically a variable resistor that is connected to the input of the controllers ASIC. We connect the PIC at the direct point of this input. When the buton is pressed, it lowers its resistance, all the way to ground. The PIC tries to force the input back to a high state. The button acts like a resisot to ground. What we found is that that resistance drops so low, the current the PIC has to output to drive high again exceeds it rating and it can no longer output a high enough voltage. In order to stop this, we put the resistor in series. This reduces the current draw on the PICs output when the PIC outputs a 2.8V level and the button drops all the way to ground. The current the PIC can handle is 20 mAmps. The value of this resistor needs to be (2.8V - 0V)/20mA = 140 Ohms.
It is better to use a 200 Ohm resistor than it is to use a 100 Ohm resistor. The only reason why we do not want to use too high a resistor value is that we do not want it to inadvertantly affect when we are trying to determine button presses using the comparator.
-
Nice work!! ive been looking for a decent R1 mod for ages
i just tryed to update the code to add a 4th mode of fire ive included the hex it is untested as ive not got a controller arround just now ill test it out 2morrow and check if it works. Feel free to download and test as well. If it does ill upload the asm for people to download
-
Nice work!! ive been looking for a decent R1 mod for ages
i just tryed to update the code to add a 4th mode of fire ive included the hex it is untested as ive not got a controller arround just now ill test it out 2morrow and check if it works. Feel free to download and test as well. If it does ill upload the asm for people to download
I could test it but... which diagram would have to follow?? what are the firerates ?? there is any mode with dutycycle?? If you could post more information about the code would be great
-
hey m8t its the same diagram for hazers as its his code with an extra mode. im just about to rip a ps3 controller apart n find out if it worked. ill post back soon
-
it didnt work it just goes straight to mode 4 after 2 insted of going to mode 3 then 4 :-(
Waitup
btfss GPIO,BUTTON
return
movlw 0x40
addwf STATER, f ;cyclic change in state manipulates
;last 2 bits in STATER.
btfsc STATER, 7 ;state 1 or 2
goto Continue01
btfsc STATER, 6
goto State2
btfsc STATER, 5
goto Continue02
State1 ;OFF
clrf FLASH
bcf GPIO,LED
bsf FLAGS,OFF
goto Startover
State2
movlw FIRERATE1
movwf FREQ
clrf FLASH
bsf GPIO,LED
bcf FLAGS,OFF
goto Startover
Continue01
btfss STATER, 6 ;state 3 or state 4
goto State4
btfss STATER, 5 ;think its something do do with this part not working properly
goto Continue02
State3
movlw FIRERATE3
movwf FREQ
clrf FLASH
bsf FLASH, OFF3
bcf FLAGS,OFF
goto Startover
State4
movlw FIRERATE4
movwf FREQ
clrf FLASH
bsf FLASH, OFF2
bcf FLAGS,OFF
goto Startover
Continue02
btfss STATER, 5
goto State5
State5
movlw FIRERATE4
movwf FREQ
clrf FLASH
bsf FLASH, OFF4
bcf FLAGS, OFF
goto Startover
-
movlw 0x40
addwf STATER, f ;cyclic change in state manipulates
;last 2 bits in STATER.
in order to add more modes you need to edit a fair bit of code, its along time since i wrote this but you should begin with the above piece of code, after the button is tapped and debounced (kinda) the code adds 0x40 to STATER, adding 0x40 to STATER causes a cyclic change in the last 2 bits of STATER, the rest of the codes then reads these last two bits of STATER to determine what mode it is in. I'd love to help you but i have never used this code myself and was a major noob when i wrote it so i cant really remember how it works.
TBH i would just leave it alone the code is poorly written and an absolute mess, if i get time in summer i'm gonna re do it but better..
-
thanks for the reply hyper. i know its realy confusing me i only know a little asm. ive all ready added the code for the led to flash when in mode 4 and it works. do u know if its like burnmeup for the 360 u need to add like 4 modes not just 1? also could i not change movlw 0x40 to 0x20?
-
well i should know i wrote it :P but the way it manipulates the 2 last bits is exactly the same as BMU but thats about it, and it doesnt matter what number you add you can only get 4 states out of 2 bits and these are, 11, 10 , 01 , and 00
-
movlw 0x20
addwf STATER, f ;cyclic change in state manipulates
;last 2 bits in STATER.
movf STATER,w
btfsc STATER, 7 ;state 1 or 2
goto Continue01
btfsc STATER, 6
goto Continue02
btfsc STATER, 5
goto State2
;OFF
; clrf FLASH
; bcf GPIO,LED
; bsf FLAGS,OFF;
; goto Startover
State2
movlw FIRERATE1 ;STATER = '00100000'
movwf FREQ
clrf FLASH
bsf GPIO,LED ;FLASH LED
bcf FLAGS,OFF
goto Startover
Continue02
btfss STATER, 5
goto State4
movlw FIRERATE2
movwf FREQ
clrf FLASH
bsf GPIO,OFF2 ;FLASH LED
bcf FLAGS,OFF
goto Startover
State4
movlw FIRERATE3 ;STATER = '0110000'
movwf FREQ
clrf FLASH
bsf FLASH,OFF3 ;FLASH LED
bcf FLAGS,OFF
goto Startover
Continue01
btfss STATER,6
goto Continue03
btfss STATER,5
goto State6
movlw FIRERATE4
movwf FREQ
clrf FLASH
bsf FLASH,OFF4
bcf FLAGS,OFF
goto Startover
State6
movlw FIRERATE5 ;STATER '1010000'
movwf FREQ
clrf FLASH
bsf FLASH,OFF4
bcf FLAGS,OFF
goto Startover
Continue03
btfss STATER,5
goto State8
movlw FIRERATE6 ;STATER '1100000'
movlw FREQ
clrf FLASH
bsf FLASH, OFF3
bcf FLAGS,OFF
goto Startover
State8
movlw FIRERATE7 ;STATER '1110000'
movwf FREQ
clrf FLASH
bsf FLASH, OFF2
bcf FLAGS, OFF
goto Startover
thats what ive got so far but its still not working. i still need to mess with the leds FLASH in this post
it compiles fine but just doenst change modes correctly ive made it 7 modes of fire
-
Ok guys, today my friend has brought his controller to put hypers code. The mobo its a MSU_VX3 but like k0mpresed, i am having some problems
First i got rf works but after a few second it stopped. Its something rare because when i do the installation everything is good but when i try to close the controller rf doesnt work. The modes change well but led blinks fastly and rf doesnt work. If i resolder the wire wich goes to ground it works again but when i move the pic again rf doesnt work again. I have made a vid:
http://www.youtube.com/watch?v=WUVV639YP8I
Do you think i would glue the pic first? However this should not happen
-
rewire with fresh wires make, try to make them only as long as they need to be becuase i can see in the video that your com2 wire is pinched as :censored: and some of the others may be too
-
I have change the wires three times but I have always the same problem and its rare if I resolder ground wire works. I will try with shorter wires
-
well all i can say is its definitely your install that is the problem,
you should hot glue the PIC somewhere before you start wiring and make sure all your wires are held down somewhere they can get pinched. or maybe try a different ground spot?
-
i am using this diagram and exactly the same ground spot
(https://www.acidmods.com/forum/index.php?action=dlattach;topic=38069.0;attach=2546;image)
-
Hi
I have a V3.7 and I had the same problem like you so to fix this bug I have wire the positive pins to the positive vibror.
:cool:
-
This is a V3.7...gf's btw. Wired up the as per pictures/diagrams--she loves it!
As you see, though, I put the button right on top though.
EDIT... forgot to mention that I switched out the red LEDs for pink ones too... LOL
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi52.tinypic.com%2F15plt7m.jpg&hash=1878cd1fbf017522e6a29c5ccd7b1ef4d248afcb)
-
Nice your controller
Where have you buy your stick ?
I have bought news controllers and when I have opened it I was surprised there is new board ... :
http://img842.imageshack.us/g/img0795t.jpg/
So is it an official or not ?
Thanks
-
I would say it isnt an official controller but I am not sure
-
Me too ^^ because there are in official package.
And I have a non official and it is same PCB so ?
-
wow... they made it a true counterfeit? I wouldnt mind them making non-official as long as the buyer is informed. But, when they make a counterfeit and sell as a real one---that gets me so angry.
btw, i bought the sticks from ebay
-
Hi all,
I want to know where did you buy your controller ?
Thanks
(I know I'm not in the good section but I want an offical board for rapid fire of course)
-
Hi all,
I want to know where did you buy your controller ?
Thanks
(I know I'm not in the good section but I want an offical board for rapid fire of course)
The red controller (my gf's) I bought from a game store. GameFix? GameStop? I just know they recently went out of business--all the brick n mortar stores are gone now. Paid full price-maybe slightly discounted.
I recently bought a controller from Sears--again, full price.
But, my controller that I installed rf came with my console--a used gunmetal gray....
-
Hi,
(Sorry for ascend this topic but I think my questions take part of it...)
I try to make my own code (in C), I have read and understand a lot of things thanks to you guys :clap:.
But I'm missed like orko007 was about the refresh rate of the controller (page 2) despite explains of 802Chives and RDC I don't understand these things :
PS3 Rapid fire only works in 10mSec increments... but at its fastest button press is still 50 press/sec
so why the fastest button press it isn't 100press/sec ?
PS3 Rapid fire only works in 10mSec increments
the range of the rapid fire is 0-100hz by level of 1hz ?
On a game like COD, the game has to see the trigger pulled for at least 3 cycles before calling it a pulled.
so the range is now 0-33 by level of 3hz ?
In supplement, how does the "burst fire" works ?
Can somebody explain me, please :beg: ?
Thanks for all
-
- The controller reads the state of each button 100 times a second, so your 50sps maximum comes from 50pressed pulses and 50 un-pressed pulses, like on off on off on off etc
- Therefore the range of speeds is 1-50 sps.
- Yes the COD game software requires 3 pressed pulses to actual count as a trigger press so the absolute maximum is around 33sps however the actual playable rate is a fair bit lower.
- Burst works by works by reading the trigger and not rapidfire'ing until a trigger press occurs, then after the desired number of shots have fired it reads the trigger again then returns to the start when the trigger has been unpressed.
-
OK thanks hyper for your reply I understand better but :
1) So for up the speed we must increment by 1hz ? But in your source code, we can put numbers more precised than that....
2) I don't understand for burst fire, can you details more ?
3) Can we inject some high (and low) state in one dip ? The controller see that or not ?
Thanks for all
-
1) Depends on the way you code it, in my code you can increment by ~0.004sps, because I use a 0.5 interrupt with an 8bit counter for my pulse timing. (The interupt routine sets a flag, this then triggers the main routine to switch pin tristate and logic high accordingly)
2) Its really quite simple
Read the com line for trigger press > When pressed set a flag and do rapid fire > when rapid fire complete wait for trigger release > go to start. Short of coding it for you I'm not really sure how I can explain it better.
3) No, the controller reads the button/trigger only once per dip.
-
Thanks again hyper for your quick reply :tup:
1) I know how you have use interrupt (and you can set a PR2 value to have a more precise timer), I have take a look in your source code...But I'm missed here : the controller look the dip of R1 one time oer 10ms so how you can have a frequency like that ?
2) OK I think I understand : the "normal" rapid fire is sending all the times the "rapid fire" however the "burst" is sending only when the button is pressed, I was wrong ?
Thanks
-
1) it reads r1 over a period of 500uS, it reads every button on the comR line in 10mS
2) rapid fire will continue to fire for as long as the trigger is pressed, whereas burst only fires a pre set number of shots every time the trigger is pressed
-
thats what ive got so far but its still not working. i still need to mess with the leds FLASH in this post
it compiles fine but just doenst change modes correctly ive made it 7 modes of fire
I was wondering if you are still working on this? I was looking forward to having a few more modes on my controller.
-
I was wondering if you are still working on this? I was looking forward to having a few more modes on my controller.
Yes and no, I'm working to just have just rapid fire on R1 because I begin of 0 : all source code that's you see is in ASM however I don't know this language and I hate it because you cannot do a complicated code (here it isn't complicated) so I code in C. And after the code of rapid fire on R1 works, I add a lot of mode, and akimbo etc
And the code that radmiler post is wrong : you can have only 4 states in 2 bytes...
@Hyper, thanks for your reply
1)yes I understand that but that's I doesn't is how you can set a precision like that ? (with the timer I understand that) however if "it reads r1 over a period of 500uS, it reads every button on the comR line in 10mS" so you can have range 0-50 press/sec and to up speed you must up by 1 press only (the comR is read every 10ms)
2) That's I write in other words, no ? So I think I understand but how you can know that the trigger is pressed ?
Sorry if my questions is still apparently the same but if I ask them again that's I haven't understand something...
-
And the code that radmiler post is wrong : you can have only 4 states in 2 bytes...
*bits
1) The timer runs independantly of the controller signal. The signal is also not always exactly 10ms long. and yes the adjustments aren't 100% precise, say if the counter reaches 0 half way through a pulse the state of the trigger will not be changed until the next pulse, but the average speed will still be close enough.
2) set the pin to an input and read the state of the common line at the middle of the r1 pulse, using whatever method you prefer (comparator, adc etc.)
-
*bits
1) The timer runs independantly of the controller signal. The signal is also not always exactly 10ms long. and yes the adjustments aren't 100% precise, say if the counter reaches 0 half way through a pulse the state of the trigger will not be changed until the next pulse, but the average speed will still be close enough.
2) set the pin to an input and read the state of the common line at the middle of the r1 pulse, using whatever method you prefer (comparator, adc etc.)
*sorry it isn't the same^^
1) Yes I know for the signal, it changes when you are on usb or battery, I see in the previous post...I don't know your end of sentence.
But I think you haven't understand my question which is how the controller can see a pulse on R1 whith your precision (0.0005s) if it read only one times every (approximatly) 10ms ?
2) OK I understand now.
And another question how the jitter works ? (apparently it shoots and changes weapon, that's all ?)
-
1) say for example you pull the trigger for 1second, not every high and low period in that second will be exactly the same length because the counter decreases every 0.5ms but the trigger is read only every 10ms, meaning that if the counter reaches 0 just after R1 is read by the controller the first state (e.g pressed) will end up being slightly longer than intended and the second state (e.g unpressed) will end up being slightly shorter than intended, therefore over the period of a second (could be any amount of time) we end up with an average speed that can be a non integer sps rate(but won't always be 100% accurate, close but not 100%).
As for jitter all it does is rapid fire the /\ button whenever R1 is pressed, you will have to experiment with speed, I hear 20Hz is a good place to start.
-
Ok, so i have been studying this topic for two weeks now. I have a VX7 board in my controller and using my arduino as a oscope i can see the dips and timing on com1 and com2. however i cannot get a signal in. if I short the battery + to the com it does crazy stuff but if i try any external source it does nothing. any ideas here? i have been racking my brain trying to figure out what im doing wrong!! any help is appreciated.
BTW thanks everyone here! I have learned alot of different things along this road.
Edit i got it semi working on a attiny85 with arduino bootloader. if anyone is interested in jumping on board with my project please let me know and im posting the basic code i got it to rapid fire with. :))
this is just the rcommon and + & -
UDATED WITH BUTTON LIST AND TIMING
void setup()
{
}
void loop()
{
pinMode(1, INPUT);
if (digitalRead(1) == 0)
{
delayMicroseconds(50); //R2 skip
pinMode(1,OUTPUT);
digitalWrite(1,HIGH); //R1
delayMicroseconds(50);//R1
digitalWrite(1,HIGH); //X
delayMicroseconds(50);//X
digitalWrite(1,HIGH); //O
delayMicroseconds(50);//O
digitalWrite(1,HIGH); // /\
delayMicroseconds(50);// /\
digitalWrite(1,HIGH); // []
delayMicroseconds(50);// []
}
}
}
-
Man, I think you are going to get erratic results until you switch that input to analog and "read" it either via a comparator or analog-to-digital.
And I'm not even sure the ADC will work. The mod I came up with is running at 16Mhz and it wasn't fast enough to accurately sync to the controller with the ADC. I HAD to go the comparator route. (...described here.)
It's like threading a needle with all the different inputs matrixed onto the one pin. You pick up your signal even 100 uS over or under and you can run into problems.
Do you mind if I ask why you have it set to a Digital Input?
-
All Digital and it runs like a charm. i added a delay to set the sps.
void setup()
{
}
void loop()
{
delay(2);
pinMode(1, INPUT);
if (digitalRead(1) == 0)
{
delayMicroseconds(50); //R2 skip
pinMode(1,OUTPUT);
digitalWrite(1,HIGH); //R1
delayMicroseconds(50);//R1
}
}
Also if your not powering your chip from the controller itself it wll give you crazy stuff or just nothing. i have a adafruit trinkit im going to mount inside the controller replacing a rumble motor its also attiny85 based and already has usb access.
[gmod]Please click the 'modify' button and edit your posts rather than double posting, thanks.[/gmod]
-
I...don't...
You are confusing me.
Each individual input is "switched" for ~500uS not 50uS on the PS3 controller.
And you aren't driving R1 High and Low in your code. You are only driving it High.
...unless I am missing something here.
EDIT:
Ok, I am still confused, but I realize now that I may not have made myself very clear on the Digital vs Analog and the need for exact timing.
So, ultimately when you say "if (digitalRead(1) == 0)" you are essentially synchronizing the Arduino to the PS3 controller's timing. You are getting them in the same time frame. If we can do this then we know that there is a part of the frame for each button where we can first read the value and then second we can drive the button how we want...whether pressed or released. And the PS3 is consistent/exact enough with its timing that we can make statements like "Once you detect the start of the frame wait 70us for the signal to settle. Then take a reading. Then force the signal high or low as needed. Hold that for 270us then stop driving it high or low(switch back to input)..." (...which happens to be the timing that I use for my PS3 mod.) But with Digital Inputs you get a gray area where a voltage could read either High or Low. There are no guarantees because the microcontroller isn't expecting a range. It is expecting either Vdd or Vss for a 1 or a 0. So what happens is in one frame you pick up the start maybe 30uS too early. And then in the next frame you pick up the start maybe 50uS too late. So that your static values of when to do what as far as reading and overriding get skewed and happen too soon or too late missing the critical window. This is the problem that I had that forced me to use a Comparator. Granted I used a Microchip instead of Atmel like the Arduino, but I have mine running at 16Mhz. It looks like the "Due" is the only Arduino that runs faster than that. So I would expect you would have the same limitations that I did.
-
Do the rest of the buttons on the COM2 line work normally with no ill effects? R2, R1, X, O, [] and /\? because I'll wager they don't, or that pressing one or more of them will throw that all out of wack.
On the subject of connecting the B+ line to the COM line, and powering the Arduino externally with voltages that are even higher than B+ in the controller, no idea where you came up with that, but that can potentially damage the controller. You should use the 2.8v switched source in the controller to power your chip.
-
Everything works normally except r1 it rapid fires. Idk Iwas just sharing what iI've found that has worked for me everyone else has the microchip versions why not atmel lol
And I distinctly said it has to have power from the controller and. You cannot test it with the arduino at
all . program the Chip and try it in the sockect wired in the controller.
If anyone has any ideas of a better or more accurate way please and in detail as the is is my first venture in electronics. I have made a oscope from arduino and could see the voltage drops.
All this is on a vx7 board
-
What you distinctly said was..
if I short the battery + to the com it does crazy stuff but if i try any external source it does nothing. any ideas here? i have been racking my brain trying to figure out what im doing wrong!! any help is appreciated.
..and that is what I was replying to.
If that works there then great, and this isn't any kind of MC vs AT thing that's been beat to death, it's just from how everyone else has had to get the thing working that really shouldn't work, at least not without some bugs.
The falling edge of the start of the data train, R2 button, is used for the trigger event to start things off. Since that does not go low enough for a Digital IO on the PIC to register (0.8v TTL or 0.2v Schmitt) that's where difference #1 comes from. It seems the chip's Digital IO you're using is far less picky. This is why everyone has had to use either the ADC or the faster Comparator method to tell when that falling edge has begun to start things off, then it's timed up from there to drive the R1 bit Hi for 'x' number of times.
Since you only have a 50us delay after R1, that's where difference #2 is at. That code will start 'looking' at the data train pulse again right after R1 and not skip over the rest of the buttons. Press all 4 face buttons at once and hold them a few seconds, X, O, [ ] and /\, and if one of them doesn't act up with all 4 pressed I'll be extremely surprised.
-
Went through it and you sir are correct in fact O and R2. Why does this work though I thought the r2 dip went all the way to 0? And I see your point about the delay issue. The b+ was just to see if I could get some kind of interaction.
As far as the avr vs micro its all I have at this point is there a reason I shouldn't use this chip?
-
Went through it and you sir are correct in fact O and R2. Why does this work though I thought the r2 dip went all the way to 0? And I see your point about the delay issue. The b+ was just to see if I could get some kind of interaction.
As far as the avr vs micro its all I have at this point is there a reason I shouldn't use this chip?
I think the reason it works is that you are forcing the output high but with inaccurate sync so that sometimes it lands in the right spot and other times it does not...which is simulating Rapid Fire.
And "No" there is no right answer when it comes to what chip you want to use. If Arduino would have been out 10 years ago when I got started I probably would be using it today for all my projects. As it is..."some people have to learn the hard way."
But listen to RDC over me. He's the man.
-
Oh ok well i rechecked and all buttons rapid fire. any ideas like i said im just a beginner and id like to use just one wire. im assuming this is because when pressed they go low??
-
Can you do oscope screenshots while you do this testing? If not, send me the code and I will connect my Arduino up and take oscope screenshots so you can see what is going on.
-
MC or AT, it's no different than Ford or Chevy, it's all the same in the end, so there's no issues or worries there at all with the chip you're using, just how it's being used.
R2 does not go all the way down to 0v, none of the buttons do, if R2 did there would be no way for the controller to know that it was pressed, as it's Analog like every other button on the controller. They get lower, but never reach 0v, ground. This is why the ADC or Comparator is used to detect when the COM2 line starts to do it's thing.
-
Just to add a little light on this:
The following was taken from the PS3 remap code found here:https://www.acidmods.com/forum/index.php/topic,42146.0.html (https://www.acidmods.com/forum/index.php/topic,42146.0.html)
Here is a clip from the code:
WaitForTrigger BTFSS PORTC, TRIGGER, ACCESS ;wait for pulse train start
BRA WaitForTrigger
MOVLB 2
;***********************R2 pulse*************************** FIRST PULSE
bsf TRISC, COMMONR, ACCESS ;make digital inputs
bsf TRISC, COMMONL, ACCESS
movlw 0x60 ;return to comparator inputs
movwf ANSEL, ACCESS
bsf CM1CON0, C1ON, ACCESS
bsf CM2CON0, C2ON, ACCESS
BTFSC NextPressLo, C3R3, BANKED ;COM3 outputs
BSF LATB, R3WRITE, ACCESS ;force press
BTFSC NextPressLo, C3L3, BANKED
bsf LATB, L3WRITE, ACCESS ;force press
movlw 0xF6 ;setup timer
movwf TMR1H, ACCESS
movlw 0xAD
movwf TMR1L, ACCESS
bcf PIR1, 0, ACCESS
bsf T1CON, 0, ACCESS
Timer01 btfss PIR1, 0, ACCESS ;200usec interval
goto Timer01
btfsc CM1CON0, C1OUT, ACCESS ;read button presses
BSF CurPressLo, C2R2, ACCESS ;with cmparators
btfsc CM2CON0, C2OUT, ACCESS
BSF CurPressHi, C1DUP, ACCESS
BTFSC PORTC, RCLIC, ACCESS ;read stick clicks
BSF CurPressLo, C3R3, ACCESS
BTFSC PORTC, LCLIC, ACCESS
BSF CurPressLo, C3L3, ACCESS
bcf CM1CON0, C1ON, ACCESS ;turn comparators off
bcf CM2CON0, C2ON, ACCESS ;and make digital inputs
clrf ANSEL, ACCESS
movlw 0xF8 ;setup timer
movwf TMR1H, ACCESS
movlw 0x94
movwf TMR1L, ACCESS
bcf PIR1, 0, ACCESS
bsf T1CON, 0, ACCESS
Timer21 btfss PIR1, 0, ACCESS ;160usec for 360usec total interval
goto Timer21
bcf TRISC, COMMONR, ACCESS ;make commons outputs
BTFSC NextPressLo, C2R2, BANKED ;force hi or lo
bcf LATC, COMMONR, ACCESS
BTFSS NextPressLo, C2R2, BANKED
bsf LATC, COMMONR, ACCESS
bcf TRISC, COMMONL, ACCESS
BTFSC NextPressHi, C1DUP, BANKED ;force hi or lo
bcf LATC, COMMONL, ACCESS
BTFSS NextPressHi, C1DUP, BANKED
bsf LATC, COMMONL, ACCESS
movlw 0xF8 ;setup timer
movwf TMR1H, ACCESS
movlw 0x9B
movwf TMR1L, ACCESS
bcf PIR1, 0, ACCESS
bsf T1CON, 0, ACCESS
Timer11 btfss PIR1, 0, ACCESS ;160usec for 520usec total interval
goto Timer11
;***********************R1 pulse*************************** SECOND PULSE
bsf TRISC, COMMONR, ACCESS ;make digital inputs
bsf TRISC, COMMONL, ACCESS
bcf LATB, R3WRITE, ACCESS ;force stick click release
bcf LATB, L3WRITE, ACCESS
movlw 0x60 ;return to comparator inputs
movwf ANSEL, ACCESS
bsf CM1CON0, C1ON, ACCESS
bsf CM2CON0, C2ON, ACCESS
movlw 0xF6 ;setup timer
movwf TMR1H, ACCESS
movlw 0xAD
movwf TMR1L, ACCESS
bcf PIR1, 0, ACCESS
bsf T1CON, 0, ACCESS
Timer02 btfss PIR1, 0, ACCESS ;200usec
goto Timer02
btfsc CM1CON0, C1OUT, ACCESS ;read button presses
BSF CurPressLo, C2R1, ACCESS
btfsc CM2CON0, C2OUT, ACCESS
BSF CurPressHi, C1DRIGHT, ACCESS
bcf CM1CON0, C1ON, ACCESS ;turn comparators off
bcf CM2CON0, C2ON, ACCESS ;and make digital
clrf ANSEL, ACCESS
movlw 0xF8 ;setup timer
movwf TMR1H, ACCESS
movlw 0x8F
movwf TMR1L, ACCESS
bcf PIR1, 0, ACCESS
bsf T1CON, 0, ACCESS
Timer22 btfss PIR1, 0, ACCESS ;160 usec
goto Timer22
bcf TRISC, COMMONR, ACCESS
BTFSC NextPressLo, C2R1, BANKED ;force hi or lo
bcf LATC, COMMONR, ACCESS
BTFSS NextPressLo, C2R1, BANKED
bsf LATC, COMMONR, ACCESS
bcf TRISC, COMMONL, ACCESS
BTFSC NextPressHi, C1DRIGHT, BANKED ;force hi or lo
bcf LATC, COMMONL, ACCESS
BTFSS NextPressHi, C1DRIGHT, BANKED
bsf LATC, COMMONL, ACCESS
movlw 0xF8 ;setup timer
movwf TMR1H, ACCESS
movlw 0x98
movwf TMR1L, ACCESS
bcf PIR1, 0, ACCESS
bsf T1CON, 0, ACCESS
Timer12 btfss PIR1, 0, ACCESS ;160 usec
goto Timer12
;***********************TRIANGLE pulse***************************
Basically this goes like this: The stick click buttons get pulsed high at the exact same time as the pulse train executes for COM1 and COM2. Since you can tie to 12 buttons using 2 IO, sacrificing 1 IO for the 'trigger event' on a 20 pin PIC was a no brainer. You could use the comparator to see COM1 dropping, but the digital signal on the stick clicks is much faster.
So the rest of the code goes like this:
-turn on comparator
-force R3/L3 outputs (this requires trace cutting since they are digital)
-setup a timer for 200 micro seconds
-read comparator results (so you can read button presses even though you will be manipulating the signal later)
-setup timer for 160 microseconds
-change pin to output and force pulse to go high or low based upon previous logic
-setup another timer for 160 micro seconds
-return pin to input and setup comparator for next pulse
-repeat for all pulses (six all together)
I only showed 2 pulses above. This is followed by evaluating the just taken button presses read by the comparator (during the first half of each pulse) and then storing what button presses/releases will be set for the next train pulse to come. So, the train pulses repeat every 10 milliseconds (or 100Hz roughly, it changes based upon battery vs USB power) and the logic to determine what bu8ttons get pressed/released comes from the previous pulse trains comparator read.
This is well tested code. Its very important what voltage reference value is used for the comparator and the code in this project has that value set via USB utility for 2 major reasons: You can set sensitivity so it can be very touchy or require you to mash the button, and also I have found that not all controllers behave the same. I had made a mod for someone here at AM and found that I had to widen the range of values in the utility because the controller would not 'dip' low enough for the default values I was using.
-
Can you do oscope screenshots while you do this testing? If not, send me the code and I will connect my Arduino up and take oscope screenshots so you can see what is going on.
Code is on Page 15.
Im gonna work on the adc method when i get some time.
the comparators confuse the piss out of me.
-
Code is on Page 15.
Im gonna work on the adc method when i get some time.
the comparators confuse the piss out of me.
Sorry, I thought you had more and were giving us the Cliff's Notes edition. My PS3 code is just a little under 2000 lines of code.
I can help you through the Comparator part if you want and if you are still interested in doing this.
It'd probably be good to start a new thread though. Something like "PS3 code for the Arduino."
-
I've been up all morning trying different things and I think the arduino thread is an awesome idea.
Yea its not much because I'm kinda learning as I go. I did a ten mod on a rock candy controller but this Sony one is a beast. But any help is appreciated.
Link to that tread if you do make one!
Sorry, I thought you had more and were giving us the Cliff's Notes edition. My PS3 code is just a little under 2000 lines of code.
I can help you through the Comparator part if you want and if you are still interested in doing this.
It'd probably be good to start a new thread though. Something like "PS3 code for the Arduino."
I started one here
https://www.acidmods.com/forum/index.php/topic,43339.0.html (https://www.acidmods.com/forum/index.php/topic,43339.0.html)
seems im getting nowhere and im getting really frustrated with all this but i dont wanna give up, Not in me.
[admin]Please Click Modify to edit post ! Please Do not double post! [/admin]