how to use free open source code by HAZER.."GameplayRF"

[Modded Matt]

Introduction
Ok guys, today we are going to walk through use of the amazing open source rapid fire code that has been so graciously provided to us by hazer, one of acidmods elite members.

lets first talk about the code,  or I guess I should say codes. There are two codes out there each accomplishing a similar affect, but in different ways. They will both provide you with 4 mode rapid fire. both codes can be used for COD5,  both have LED indicators, and both can be used on a matrix or a CG controller

The first code and the one I will walk through in this thread is called  “GameplayRF” this code has four selectable  preprogrammed speeds. This will add a momentary switch to control each trigger. Notice I said control, rapid fire remains naturally on the triggers. You will press the added button to turn rapid fire on/off, and you will hold the same button for 2 seconds to change modes.  

The second code is called “burnmeup2” this is a complete sleeper mod. it will be discussed in full in the next thread. With the sleeper mod,  there are still four speeds, however one of them is used by the off function. Instead of using a added button to control the mod, you will use the sync button. This mod has no quick on/off function, you must cycle through the other three modes to get back to off, but it is a sleeper.

Now you should understand the difference between the two codes, and must choose, sleeper, or quick on/off. Keep in mind these codes are similar, but completely different. They are two different codes, and they wire differently. So you must choose.





Step one Needed files/ items
Ok, the first thing you need to do is download the GameplayRF zip file. It can be found here https://www.acidmods.com/Software/hazer/gameplayrf.zip  this file has four items inside. It has:

.asm file-----this is the file we need, it is the raw code before it is converted to hex
.hex file-----this has been modified from its original version for COD5 (fire rate #1)
CG picture---wiring diagram
Matrix picture---wiring diagram

I am going to teach you to change the fire rates for this chip so it can be COD 5 compatible, this will also allow you to make future adjustments for newer games.

You will also need a code compiler. I use a free program called MPLAB. You can download this free program here: (you are welcome to use your own if you have one)
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002

Now you will need another program to write the code to the chips, yet again, another free program, called winpic800 (you are welcome to use your own if you have one) winpic800 can be found free here:  http://www.winpic800.com/index.php?option=com_content&task=blogcategory&id=19&Itemid=88&lang=en

The next item you will need is a programmer,  there are a lot of choices out there. If you plan on using it for other things, by all means buy a nice one, but you can make your own cheap programmer with help from gameroms and acidmods.  Here is the schematic: https://www.acidmods.com/Software/hazer/picprogramer.gif

The last items you need are hardware items, that will be used for installation. Installation will be discussed in a later chapter, but here is the part list.
Chips----------12f683 I/P get 4 free samples from microchip direct
PIC socket---- http://www.radioshack.com/product/index.jsp?productId=2062604
10K,100ohm, 330 ohm, resistors I recommend the 500 pack
 http://www.radioshack.com/product/index.jsp?productId=2062306
momentary push button---my fav—
   http://www.radioshack.com/product/index.jsp?productId=3014504
small wire—20-30 gauge







step two code modification/code assembly

the only thing you need to change is the fire rate,
before you start, drag and drop the asm file onto your desktop

ok here we go
1) open mplab
2) click the project tab
3) click project wizard
4)click next
5)set desired chip, in this case it is the 12f683
6)hit next
7) hit next again
8) create file path (this is where most errors come from, the file path must be only so many characters
click browse, hit the drop down menu, click desktop, and name it a short name like RF it dont matter as long as the path is not too long, click next
9) import asm file, here again the file path cannot be too long, drop the asm on the desk top before you start. click next
10) click finish
11) now you are back to the mplab main screen and it looks like nothing has changed, but it has, click view
12) click project (under the view tab)
13)now you should have a small box that is the name of your file path. you will see a few tabs and one that reads "source file" and underneath it will be the asm file you dropped on the desk top. double click it. to open
14) scroll down to the part of the fire rates, it will look like this:
;**********Speed settings: change these to change speed (0x05-0xFF)
FIRERATE1      equ      0x3C
FIRERATE2      equ      0x16
FIRERATE3      equ      0x12
FIRERATE4      equ      0x0F

you will notice some stuff is colorful and some is not, the green stuff is instructions, the colored items are code. only change the fire rate!!! when you start to change the fire rate just click the end of it and backspace the last two digits and input your own...you will notice when you delete the digit, that part of the code will turn black this means that part of the code is no good, well duh you just erased it, once you input your entry it will return to its normal color

**the fire rates can get tricky to figure out. Here is a list  to convert the fire rate to hex so you can adjust the rates for your games. https://www.acidmods.com/Software/hazer/Fire-Rates-2.pdf

15)now look back at the main mplab page again and click project
16) scroll down to where it reads "build all" click it
17) a box will pop up with a status bar mine goes very fast and reads build succeeded
18) click to close mplab, it asks for save I say yes.
19) look at desktop, or wherever you saved it, find the file that ends in .hex, this will most likely be a file windows cant open, send everything else to the recycle bin you don’t need anything else keep the hex file handy you will need it in the next chapter.


***the biggest problem is the file path length as I already stated, if the file path is too long it will say build failed, and if you read the other crap it tells you it will say C:documents and settings.......file path exceeded so many characters.***







Step three programming the chip

this step is painless and very quick if you already have a programmer, if not build the one I linked above, here it is again https://www.acidmods.com/forum/index.php?topic=22283.0  or  for just schematic 
I suggest building the first diagram gameroms showed in this thread, the desktop serial programmer. I can vouch for this I use it all the time. The other ones I cannot speak for nor can I speak for a store bought programmer, but they should all be similar, and they should have directions with them

1)   Open winpic800
2)   connect your programmer and put chip in the programmer, make sure it is oriented correctly. 
3)   Click file
4)   Open the .hex file you just created
5)   Click the icon that reads “program all” or CTL+P
6)   Done








Step four installation

Inside the GameplayRF file there are two pictures we spoke of above, one for matrix, and one for CG. First find out what type of controller you have you can look here if you are having trouble. https://www.acidmods.com/forum/index.php?topic=24699.0

The install I will leave fairly open, feel free to experiment here, just connect it like shown in the pics, but placement of the chip and buttons are up to you. I like to put the control button in the face, some people like it underneath, its all just preference.

Notes:
*in the pictures provided, the chip is in the “crawling position”
*if only one side is desired, leave off the right side led, and trigger wire
*the CG controllers work flawlessly, there has been some issues with matrix controllers, this issue only affects 1% of all matrix controllers and usually only affects the older limited edition controllers,  these can be fixed, but they will be done on a case by case basis, pm me for details. Chances are most of you wont have to worry about this.

CG:
 

Matrix:
 

solder all components to the pic socket

 

Then install according to your type of controller, something like this
 








Closing:

Do NOT use this for personal gain. Hazer put a lot of work into this code and released it to the general public, as his gift to the world. Consider this a test, and the results will determine if AM will release other free codes in the future

I will modify this thread as needed

Please feel free to ask questions about any of the steps provided in this tut. 






Credits:
All credit for this code goes to hazer, he is the sole author of this code
Credit for hi-Res install pics goes out to RDC at xbox-scene
Credit for finding the programmer belongs to Gameroms
Credit for the fire rate conversion (found on internet, and I forgot the name sorry)
Credit for writing the tut goes to modded matt.
Thanks to the acidmods support staff for hosting all these files and allowing this to be posted to the community.

[jonagpa]

Great step by step guide, thank you
I notice that in one of your previous post (https://www.acidmods.com/forum/index.php?topic=22727.0) you gave a link to hazers GameRF code and diagram (http://www.microchip.com/forums/attachment.aspx?m=364122) this is the picture I have from that file for the matrix controller.

as you can see they are a little different form the pic you show in this thread.

10K,100ohm, 330 ohm, 470 ohm resistors I recommend the 500 pack
 http://www.radioshack.com/product/index.jsp?productId=2062306

What got me real confused was that you listed the 470 ohm resistor and the 100 ohm resistor as parts needed, but only the 100 ohm resistor is shown in the picture form this thread. Which one do I need?

I also notice that you called the code "GameplayRF" while in the previews thread you called it "GameRF" I am just wondering if it’s the same code or not.

I also notice that in the diagram pics form this thread the resistor looks like this: form what I understand is that first color brown represents 1, second color purple represents 7, third color brown represents number of zeros, the number I get is 170 ohm resistor but next to the resistor you got the number 100, just wondering if there is a mistake in the resistor picture(I could be wrong NOT AN EXPERT or anything)

Any clarification would be greatly appreciated
Thank you.

[Modded Matt]

good eye, the LED ressitors have been revised to make them brighter. the leds were revised after I wrote the tut. I will change the wording. use 100 ohm for cg and 170ohm for matrix. this will brighten the LED indicators.

this is GameplayRF. if I quoted it as gameRF I misspoke. I highly doubt someone else wrote a code and named it that similar, so I would bet that it is the same code.

[jonagpa]

thank you for the clarification.
I just realized that 170 ohm resistor doesn’t exist, I think it goes form 150, 160, 180 ohms, Don’t know why. either way is not that important as is only the LED brightness. Do you think the person in who revised the diagram simply forgot to change the color purple to black?

Don’t mean to be extremely picky, just trying to clarify any confusion.
thanks

[gamerdude767]

matt you made a spelling mistake here:

 The second code is called “burnmeup2” this is a complete sleeper mod. it will be discussed in full in the next thread. With the sleeper mod,  there are still four speeds, however one of them is used by the off function. Instead of using a added button to control the mod, you will use the sinc button. This mod has no quick on/off function, you must cycle through the other three modes to get back to off, but it is a sleeper.

[Modded Matt]

thank you for the clarification.
I just realized that 170 ohm resistor doesn’t exist, I think it goes form 150, 160, 180 ohms, Don’t know why. either way is not that important as is only the LED brightness. Do you think the person in who revised the diagram simply forgot to change the color purple to black?

Don’t mean to be extremely picky, just trying to clarify any confusion.
thanks

yea, its no big deal, those are for the brightness of the led. personaly, when I do this mod, I add leds to the dome to inuminate the X indicating rapid fire is on. in which case you need to measure thevoltage output of the chip and use the according resistor for your LED. hazer stated they were too high and we needed to pull the resistance down to 100ohms. it will work regarless. only a matter of preferance.

@ gamerdude..LOL if thats the only grammar mistake I made, I win!! LOL I have an accosiates degree in architectural design and engeneering, but cant spell for....uh....to save my life. LOL

[Hazer]

I get requests daily for people asking me to customize this code for them. Since I cannot possibly do that, I have gone through the task of explaining every step of this code so that if you can learn how assembly works, you can follow how how these codes work and alter it yourself.

First, before all else, you should download and skim through the datasheet for the 12F683:

http://ww1.microchip.com/downloads/en/DeviceDoc/41211D_.pdf

We start with the basic template:

Code: [Select]

list      p=12F683        ; list directive to define processor
#include <p12F683.inc>    ; processor specific variable definitions

errorlevel  -302          ; suppress message 302 from list file

__CONFIG   _FCMEN_OFF & _IESO_OFF & _CP_OFF & _CPD_OFF
& _BOD_OFF & _MCLRE_OFF & _WDT_OFF & _PWRTE_ON
& _INTOSCIO

;***** VARIABLE DEFINITIONS******************
w_temp        EQU     0x70        ; variable used for context saving
status_temp   EQU     0x71        ; variable used for context saving

;**********************************************************************
ORG     0x000             ; processor reset vector
goto    Main              ; go to beginning of program


ORG     0x004             ; interrupt vector location
movwf   w_temp            ; save off current W register contents
movf STATUS,w          ; move status register into W register
movwf status_temp       ; save off contents of STATUS register

movf    status_temp,w     ; retrieve copy of STATUS register
movwf STATUS            ; restore pre-isr STATUS register contents
swapf   w_temp,f
swapf   w_temp,w          ; restore pre-isr W register contents
retfie                    ; return from interrupt

;*************************************SUBROUTINES**********************************

;**********************************************************************************
;**********************************************************************************
;**********************************************************************************
Main

; initialize eeprom locations

ORG 0x2100
DE 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00


END                       ; directive 'end of program'

The most efficient way to handle a precise timing signal is to use the hardware interrupt of the PIC to trigger events. The hardware interrupt will execute certain code based upon the event regardless of what the code is doing inside the MAIN routine. The default speed of the chip is 4MHz which equates to an instruction execution speed of 1 MHz, or 1 MIPS (Millions of Instructions Per Second). The desired event for our interrupt is to change the RF pins output at a resolution of 1 millisecond. So we want to have a hardware interrupt occur every 1000 instruction cycles EXACTLY. This is easily handled by using the TIMER2 modules interrupt. We setup the TIMER2 module to run at 1:4 scaling and load a value of 250 (hex of 0xFA) into the PR2 register. If you follow the datasheet, you will find that this will make the TIMER2 module count up at a rate of 1 for every 4 cycles of the processor and once the counter has reached the value placed inside PR2, the PIC will stop executing the MAIN code and jump to the hardware interrupt vector (0x0004) and begin executing the interrupt service routine. So now we need to add the code to our template:

We will have to add the setup of the TIMER2 module and the PR2 register. We will also have to enable the TIMER2 interrupt flag and globally enable the PICs hardware interrupt.

Code: [Select]

;**********************************************************************************
;**********************************************************************************
;**********************************************************************************
main

bcf STATUS, RP0 ;bank 0

movlw 0x01
movwf T2CON ;timer 2, prescale 1:4, no postscale
bsf STATUS, RP0 ;bank 1
movlw 0xFA
movwf PR2 ;setup 1ms hardware interrupt
bsf PIE1, TMR2IE ;enable timer2 interupt
bcf STATUS, RP0 ;bank 0
bsf T2CON, TMR2ON ;turn on timer2
movlw 0xC0
movwf INTCON ;turn on interrupts globally


While we are at it, we should also turn the comparators off (default is on). We can also setup our output pins and make all pins digital (default is analog). We only need to execute this once when the chip powers on, so we then go into our forever looping MAIN routine and call it ‘Start’.

 

Code: [Select]

;**********************************************************************************
;**********************************************************************************
;**********************************************************************************
main

clrf GPIO

movlw 0x07
movwf CMCON0 ;comparators off
bsf STATUS, RP0 ;bank 1
movlw 0x1C
movwf TRISIO ;pin 0 & 1 & 5 out, all other inputs
clrf ANSEL ;all digital pins
movlw 0x14
movwf WPU ;enable week pullups
bcf OPTION_REG, 7 ;enable all week pullups
bcf STATUS, RP0 ;bank 0

movlw 0x01
movwf T2CON ;timer 2, prescale 1:4, no postscale
bsf STATUS, RP0 ;bank 1
movlw 0xFA
movwf PR2 ;setup 1ms hardware interrupt
bsf PIE1, TMR2IE ;enable timer2 interupt
bcf STATUS, RP0 ;bank 0
bsf T2CON, TMR2ON ;turn on timer2
movlw 0xC0
movwf INTCON ;turn on interrupts globally


;******MAIN LOOP***************
Start

goto Start

If you look through the datasheet, you can follow what is going on. By setting/clearing bits in the GPIO register, you are making the pins output voltage either 0V (for a binary value of 0) or Vdd (for a binary value of 1). By setting/clearing the bits in the TRISIO register, you are either making the PIC pins inputs (value of 1) or outputs (value of 0). If the pins are made outputs, the voltage on the pin will be whatever value is set in the GPIO register. If the pins are set as input, the pin will be tri-stated, or ‘floating’. This means that the PIC does not manipulate the voltage on that pin. You will also note the use of the STATUS register. Certain registers in the PIC reside in different memory Banks. In order to manipulate the correct register, you need to set/clear the RP0 bit in the STATUS register in order to access the registers you need to get to. If you do not do this properly, you will be manipulating the registers in the wrong bank since the bolded names used here are just declarations made in the include file at the beginning of the template. For instance, when the compiler takes your assembly code and creates the hex file, it will change all the bolded names into hex values. For this chip, the GPIO and TRISIO declarations are the exact same value. If you do not point to the correct memory bank before using these declarations, you will be changing bits in the wrong register.

READ THE DATASHEET for a better explanation.

Now that we have our 1ms timed event, we need to do something with it. What we want to do is create 2 counters that we can decrement inside of our interrupt. One is for the RF signal to be ‘on’ and one for the RF signal to be ‘off’. So we declare 2 general purpose registers for this. Also, in order to store certain ‘machine states/modes’ I always create a FLAGS register to hold flag bits that let me know certain events are in process.

Code: [Select]

;***** VARIABLE DEFINITIONS******************
w_temp        EQU     0x70        ; variable used for context saving
status_temp   EQU     0x71        ; variable used for context saving

FLAGS EQU 0x20 ;software state register
PULSER EQU 0x21 ;pulse on counter
DWELLTIMER EQU 0x22 ;pulse off counter
FREQR EQU 0x25 ;frequency value


I also created a register that would hold the count-down value so that the Main routine could replace this value as we want and the speed of the RF signal would change immediately on the next pulse. So now we need to structure how the RF signal is ‘made’ inside the hardware interrupt. First we look at how the pin is wired. Lets look at the CG. Normally, the voltage on the trigger is low, and pressing the trigger makes the voltage go high. In order to perform a ‘sleeper’ fire, we want to pulse that voltage back to low while the trigger is being held down. Some RF circuits drive the voltage high and low, and this is not a good design. The best way to handle this is to force the PIC pins output to low (bcf GPIO) and then we toggle the PIC pins state from input (allows the trigger voltage to go high as if the PIC was not there) to an output (forces the trigger voltage back to low, tricking the controller into thinking the trigger was released). This is done by setting and clearing the TRISIO bit for that pin. So the next question is this: Do we need to know when the trigger is being pressed or released? The answer is no. If we constantly toggle the pin from tri-state input to low-voltage output while the trigger is released (low voltage state), then we are not changing the voltage on the trigger anyway. It only has an effect if the trigger is pulled and the voltage goes high. So now we know we can simply forever toggle the I/O state of the pin inside the interrupt service routine. In order to make things easier to read inside the program, we need to declare names for the pins that we plan to manipulate.

Code: [Select]

;*******bits in FLAGS register***********
PULSEONR equ 0

;*********GPIO pin names*****************
TRIGGERR equ 0
TRIGGERL equ 1

;**********************************************************************
ORG     0x000             ; processor reset vector
goto    main              ; go to beginning of program

ORG     0x004             ; interrupt vector location
movwf   w_temp            ; save off current W register contents
movf STATUS,w          ; move status register into W register
movwf status_temp       ; save off contents of STATUS register

btfss PIR1, TMR2IF ;timer 2 int happened
retfie

;**************** Right trigger logic***************************************
RightTrigger
bcf GPIO, TRIGGERR

btfss FLAGS, PULSEONR ;is pulse active?
goto OffstateR
decfsz PULSER, f ;if pulse is active, count down 10ms
goto EndInterupt
bcf FLAGS, PULSEONR ;10ms is over, clear flags and output
bsf STATUS, RP0 ;bank 1
bsf TRISIO, TRIGGERR ;and reset pulse time.
bcf STATUS, RP0 ;bank 0
movf FREQR, w
movwf PULSER
goto EndInterupt
OffstateR
decfsz DWELLTIMER, f ;count down dwell time to next pulse
goto EndInterupt bsf FLAGS, PULSEONR ;if dwell is done turn on outputs
bsf STATUS, RP0 ;bank 1
bcf TRISIO, TRIGGERR ;and reset pulse time
bcf STATUS, RP0 ;bank 0
movf FREQR, w ;from frequency value
movwf DWELLTIMER

EndInterupt
bcf PIR1, TMR2IF

movf    status_temp,w     ; retrieve copy of STATUS register
movwf STATUS            ; restore pre-isr STATUS register contents
swapf   w_temp,f
swapf   w_temp,w          ; restore pre-isr W register contents
retfie                    ; return from interrupt



OK. So lets break down each piece: The first thing we do when we enter the interrupt is to store the data that is being held in the work register and the STATUS register. We halted the Main routine when the interrupt occurred and we don’t want to over-write the stuff the Main routine was doing before we got here, so we store it. At the end of the interrupt, we place this data back so that the Main routine can continue its logic.

Next we make sure that the TIMER2 interrupt was what had occurred. If we accidently enabled a different interrupt (or we plan to use another hardware interrupt function) we don’t want to execute our timed event. (this never happens as long as everything is setup properly).

So now we are in our RIGHTTRIGGER logic. First, we clear the GPIO pin TRIGGERR. I will explain later why this is done here instead of doing it in the main routine. Next we check to see if our output pulse is currently active. Btfss = bit test F skip if set. We test the bit and if it is set, we skip the next instruction. We test PULSEONR to see if it is set (pulse is active). If it is not, we execute the next instruction which is to goto the labeled code OffstateR (where we decrement the ‘off counter’). If our PULSEONR is active, we skip this goto instruction and decrement our PULSER counter. If we wanted our pulse to last 20 milliseconds, we would pre-load this counter with a value of 20. Every time our interrupt occurs, we take one away from this counter. If the counter has not reached zero, we then end the interrupt service routine and wait for the next 1ms event interrupt. Once our counter has reached zero, we skip the ‘goto endinterrupt’ and now we can change the state of our output pin. So, we change the pin from an output (pulse active) to an input. We also need to change the PULSEONR flag bit so we no longer decrement our PULSER counter and we need to reset the PULSER counter value by moving FREQR value into it.
Now, the next time we enter out interrupt routine, we will be ‘jumping’ to the OffstateR section of the interrupt. In here we decrement the counter DWELLTIMER just like the we did with the PULSER counter. By having these two separate counters, we can change the difference in ‘pulse on’ and ‘pulse off’ times independently if the need ever arises. For now, we will keep things simple by loading the value of FREQR to both counters. At this point, you can see that we just keep toggling the pin I/O state back and forth with this interrupt. The really nice part is that our Main routine can have another whole process going on and the RF signal is happening transparently at the same time. We do not have to sacrifice the timing of a separate event in order to precisely time our RF signal. Can you say macro function?
The last thing to go over is that the TIMER2 interrupt flag needs to be manually cleared by the code at the end of the interrupt before returning to our Main routine, and lastly we restore the work register and STATUS register to the state it was in before our interrupt event.

The next thing we need to do is create ‘modes’. As explained earlier, the value that is currently in FREQR is what determines the speed of the RF signal. We now need a method to change that value. In this code, the PIC monitors the sync button and changes the value in FREQR. So lets implement that.

Code: [Select]

;******MAIN LOOP***************
Start
btfsc GPIO, PROGSTATE
goto Start ;wait for the fun to begin
call Wait10ms
btfsc GPIO, PROGSTATE ;button is down for 10ms
goto Start
Release
btfss GPIO, PROGSTATE ;wait for button release
goto Release
call Wait10ms
btfss GPIO, PROGSTATE ;wait for button release
goto Release
What we are doing here is checking the sync button for a press. If it is pressed, the voltage will drop and the pin state will be ‘clear’. So we do a btfsc (bit test F skip if clear). When the pin is cleared, we skip the next instruction (which is to keep looping back to Start) and then call a subroutine called Wait10ms. For some background history on tactile switches: Most tactile switches do not create a perfect on/off switching. The button ‘bounces’ the voltage as the contacts come together causing most digital processors to ‘see’ many button presses when only one physically occurred. A simple method to overcome this is called Button De-bounce. Basically, if we think the button has been pressed, we wait a period of time and check the button again. 10 milliseconds is enough time for this bouncing to settle. That way, one press registers as one press for the chip.
Once we have a confirmed press, we keep testing the pin for the button to get released. This way, our code will not cycle back into the test for the press over and over again.

Code: [Select]

call Wait10ms
btfss GPIO, PROGSTATE ;wait for button release
goto Release

movlw 0x40
addwf STATER, f ;cyclic change in state manipulates
;last 2 bits in STATER.
movf STATER, w
call WriteEE ;store state

You can also see that a subroutine is called to write the value of STATER to the internal EEPROM to store this state and remember it even if power is turned off. We will go over the EEPROM routine later.
Now here is a trick I used to be able to store the mode. By adding the value of 0x40 to the register STATER, I can cycle through 4 states. 0x40 in binary is the same as b’0100 0000’. By adding 0x40 I switch between the following values in binary:
b’00000000’; b’01000000’; b’10000000’; b’1100000’
So I create a 4 mode STATER and use bits 6 and 7 in the register to test which state I am in:

Code: [Select]

movlw 0x40
addwf STATER, f ;cyclic change in state manipulates
;last 2 bits in STATER.
movf STATER, w
call WriteEE ;store state

btfsc STATER, 7 ;state 1 or 2
goto Continue01
btfsc STATER, 6
goto State2
movlw FIRERATE1 ;state 1, off
movwf FREQR
goto Start
State2
movlw FIRERATE1 ;state 2, 42ms cycle
movwf FREQR
goto Start
Continue01
btfsc STATER, 6
goto State4
movlw FIRERATE2 ;state 3, 30 ms cycle
movwf FREQR
goto Start

State4
movlw FIRERATE3 ;state 4, 22ms cycle
movwf FREQR
goto Start ;store state

By testing those bits, we can determine what the new mode value is and set our FIRERATE values into FREQR. Then the code returns to Start and waits for the next button press. In the meantime, the new value in FREQR will be used to reset the counters in our hardware interrupt service routine and the RF signal timing will change on the very next cycle.

If we go back to our interrupt service routine, we can see that the right trigger logic checks the value of STATER to see if it is zero. By simply moving STATER back into itself, we can test the Z bit and if STATER is zero, we force the right trigger pin to remain an input, disabling the RF signal logic.

Code: [Select]

RightTrigger
movf STATER, f ;this will trigger the zero flag
btfss STATUS, Z ;if STATER is zero, output is off.
goto ActiveR
bsf STATUS, RP0 ;bank 1
bsf TRISIO, TRIGGERR
bsf TRISIO, TRIGGERL
bcf STATUS, RP0 ;bank 0

goto EndInterupt

ActiveR

Another part of the RF logic is determining which controller output to use. During the initial section of the Main routine, we check pin 4 to see how it got wired in the controller. If it is wired to power, we set the FLAGS bit TRIGOUT. We then use this l:censored: to force the output high or low in the interrupt service routine.

Code: [Select]

btfsc GPIO, CONTROLTYPE ;if pin 4 is pulled lo
bsf FLAGS, TRIGOUT ;leave output lo


Code: [Select]

ActiveR
btfss FLAGS, TRIGOUT
bcf GPIO, TRIGGERR
btfsc FLAGS, TRIGOUT
bsf GPIO, TRIGGERR

Now, you may wonder why we just don’t simply set the output in the main routine and leave it alone. The answer is that since we are manipulating the LED pin along with the RF signal at different speeds and times, we run into a problem that is built into the PIC hardware itself. This problem is called READ-MODIFY-WRITE in the PIC datasheet. What it means is that during the internal part of an instruction cycle, a register is first read into the processor. It is then modified according to your instruction, and then written back to the register. For the output ports, the problem lies in the fact that when you read the pin, you are reading the actual voltage on that pin. When you write to a pin, you are writing to the output latch, not the actual pin. When the Read and Write occurs, it happens on the entire register (in our case the GPIO register contains all of the PICs pins). So, when our LED is blinking in our subroutine at the same time the RF pins are tri-stated, we end up reading the current voltage present on the trigger pins and rewriting the value on the output latch. So what we need to do is make sure that the output latch is always forced high or low according to our flag bit that retains the correct voltage we want to output according to the controller type every single time we cycle through the interrupt service routine.

The next thing to go over is the left trigger. If you note how the code works, only the second mode has dual trigger RF (first mode is actually just ‘off’). Lets look at the interrupt service routine for that:

Code: [Select]

ActiveL
movlw 0x40
subwf STATER, w ;test if state 1
btfsc STATUS, Z
goto Continue02
bsf STATUS, RP0 ;bank 1
bsf TRISIO, TRIGGERL
bcf STATUS, RP0 ;bank 0
goto EndInterupt
Continue02
btfss FLAGS, TRIGOUT
bcf GPIO, TRIGGERL
btfsc FLAGS, TRIGOUT
bsf GPIO, TRIGGERL

btfss FLAGS, PULSEONL ;is pulse active?
goto OffstateL
decfsz PULSEL, f ;if pulse is active, count down 10ms
goto EndInterupt

bcf FLAGS, PULSEONL ;10ms is over, clear flags and output
bsf STATUS, RP0 ;bank 1
bsf TRISIO, TRIGGERL ;and reset pulse time
bcf STATUS, RP0 ;bank 0
movf FREQR, w
movwf PULSEL
goto EndInterupt

OffstateL
decfsz DWELLTIMEL, f ;count down dwell time to next pulse
goto EndInterupt
bsf FLAGS, PULSEONL ;if dwell is done turn on outputs
bsf STATUS, RP0 ;bank 1
bcf TRISIO, TRIGGERL ;and reset pulse time
bcf STATUS, RP0 ;bank 0
movf FREQR, w ;from frequency value
movwf DWELLTIMEL

This is pretty much the same thing as the right side except we test the value of STATER by subtracting 0x40 from it and testing the Z bit in the STATUS register. This bit is a math bit built into the PIC that tells us if the computed result of an instruction turn out to be zero. If the Z bit is set, then the result was zero. So, if we subtract 0x40 and STATER is 0x40 (mode 2) then we have a set Z bit. Please note that the destination for the subtraction is the work register. We do NOT want to change the value of STATER, just test it. If it is clear, we keep the left trigger pin an input (disabling RF on that pin) and leave the interrupt service routine. If it is set, we go through our RF signal code.
Another thing to notice here is that the code is already setup to use completely different values for each trigger in case there is a need to have dual trigger firing at different speeds. This may be useful for COD WAW Zombie game where the left trigger is used to auto-aim onto the target.

The next thing to go over is the LED logic. The idea is simple: In order to manipulate the LED in both the matrix and the CG, We use a 50Hz squarewave signal to turn the LED on. The LED on each controller works backwards from each toher; One sources, the other sinks. In order to light both up, we constantly turn the output high and low so fast you cannot see it directly. This way, the output works for both LEDs. In order to turn the LED off, we make that pin an input instead of a fast switching output. Since we already have the interrupt service routine, we can place our LED code in there:

Code: [Select]

;**************** LED blinking *********************************************
;Our main routine will turn the flag bit
;LEDON on or off. The 10ms pulse is a duty cycle
;for the code to work with both CG and
;matrix controllers.

btfsc FLAGS, LEDON ;LED off
goto BlinkLed
bsf STATUS, RP0 ;bank 1
bsf TRISIO, LEDR ;tristate LED
bcf STATUS, RP0 ;bank 0
goto RightTrigger

BlinkLed
bsf STATUS, RP0 ;bank 1
bcf TRISIO, LEDR ;turn output on
bcf STATUS, RP0 ;bank 0
btfss GPIO, LEDR
goto LedLow
decfsz LEDBLINK, f ;if pulse is active, count down 10ms
goto RightTrigger
bcf GPIO, LEDR
movlw 0x0A
movwf LEDBLINK

LedLow
decfsz LEDBLINK, f ;if pulse is active, count down 10ms
goto RightTrigger
bsf GPIO, LEDR
movlw 0x0A
movwf LEDBLINK

We control the LED inside the Main routine and use a FLAG bit to condition our LED logic in the interrupt service routine. So, the first thing we do in the interrupt service routine is check the flag bit and if it is clear, we force the LED pin to an input leaving the LED off. If it is set, we turn the LED pin into an output, and cycle the the output by counting down LEDBLINK register just like the RF signal does except we always load a value of 0x0A (decimal 10) when we reset the counter.
Now, we use the LEDON bit in FLAGS to turn the LED on or off in the main code. As we can see, we turn the LED off for mode 1, turn it on for mode 2, and blink it for modes 3 and 4. If you look at where state 3 begins, we turn the LED off and then load a value of 0x0A into TEMP3 and call the Wait10ms subroutine. This simple subroutine basically takes the value in the work register (in this case 10) and lops continuously for roughly 10 milliseconds multiplied by the value in the work register (so in this case, we loop for 100 milliseconds of time). Once the subroutine is done wasting that time, it returns to the main routine. At that point, we turn the LED back on and call the subroutine again. We repeat this enough times to make the LED ‘blink’ twice to let us know we have changed the controller to mode 3. The same thing occurs in mode 4, but we blink 3 times.

Code: [Select]

;******MAIN LOOP***************
Start
btfsc GPIO, PROGSTATE
goto Start ;wait for the fun to begin
call Wait10ms
btfsc GPIO, PROGSTATE ;button is down for 10ms
goto Start
Release
btfss GPIO, PROGSTATE ;wait for button release
goto Release
call Wait10ms
btfss GPIO, PROGSTATE ;wait for button release
goto Release

movlw 0x40
addwf STATER, f ;cyclic change in state manipulates
;last 2 bits in STATER.
movf STATER, w
call WriteEE ;store state

btfsc STATER, 7 ;state 1 or 2
goto Continue01
btfsc STATER, 6
goto State2
movlw FIRERATE1 ;state 1, off
movwf FREQR
bcf FLAGS, LEDON ;turn off LED
goto Start
State2
movlw FIRERATE1 ;state 2, 42ms cycle
movwf FREQR
bsf FLAGS, LEDON ;turn on LED
goto Start
Continue01
btfsc STATER, 6
goto State4
movlw FIRERATE2 ;state 3, 30 ms cycle
movwf FREQR
bcf FLAGS, LEDON ;turn off LED 1/2 sec
movlw 0x0A
movwf TEMP3
Loop01
call Wait10ms
decfsz TEMP3, f
goto Loop01
bsf FLAGS, LEDON ;turn on LED 1/2 sec
movlw 0x0A
movwf TEMP3
Loop02
call Wait10ms
decfsz TEMP3, f
goto Loop02
bcf FLAGS, LEDON ;turn off LED 1/2 sec
movlw 0x0A
movwf TEMP3
Loop04
call Wait10ms
decfsz TEMP3, f
goto Loop04
bsf FLAGS, LEDON ;turn on LED
goto Start

State4
movlw FIRERATE3 ;state 4, 22ms cycle
movwf FREQR
bcf FLAGS, LEDON ;turn off LED 1/2 sec
movlw 0x0A
movwf TEMP3
Loop05
call Wait10ms
decfsz TEMP3, f
goto Loop05
bsf FLAGS, LEDON ;turn on LED 1/2 sec
movlw 0x0A
movwf TEMP3
Loop06
call Wait10ms
decfsz TEMP3, f
goto Loop06
bcf FLAGS, LEDON ;turn off LED 1/2 sec
movlw 0x0A
movwf TEMP3
Loop07
call Wait10ms
decfsz TEMP3, f
goto Loop07
bsf FLAGS, LEDON ;turn on LED 1/2 sec
movlw 0x0A
movwf TEMP3
Loop08
call Wait10ms
decfsz TEMP3, f
goto Loop08
bcf FLAGS, LEDON ;turn off LED 1/2 sec
movlw 0x0A
movwf TEMP3
Loop09
call Wait10ms
decfsz TEMP3, f
goto Loop09
bsf FLAGS, LEDON ;turn on LED
goto Start

Now that we have our Rapidfire signal and LED code written, we need to make sure that all of these registers have the correct values setup when the chip first powers on:

Code: [Select]

movlw 0x0A ;start with 10ms pulse width
movwf LEDBLINK
movlw FIRERATE3 ;40ms dwell for 50ms freq
movwf PULSER
movwf PULSEL
movwf DWELLTIMER
movwf DWELLTIMEL
btfsc GPIO, CONTROLTYPE ;if pin 4 is pulled lo
bsf FLAGS, TRIGOUT ;leave output lo
call ReadEE ;get state value
movwf STATER
movf STATER, f
btfss STATUS, Z
bsf FLAGS, LEDON ;get LED status


;******MAIN LOOP***************
Start

As can be seen, we first load our LEDBLINK register with a value of 10. We also load the FIRERATE3 speed into our PULSE and DWELLTIME registers just to make sure they some kind of value there. The next part checks and retains the controller type we have wired. Lastly, we call a subroutine to read the EEPROM to find the last value of STATER that got saved and load that into the controller. Finally, we check the value of STATER to see if we need to turn our LED on. We just want to make sure that when the chip powers on we setup some kind of intial value into our counters and state registers so nothing unexpected happens the first time the chip begins executing the mian routine (which loops back to Start continuously).

The final thing to look at is the subroutines. I briefly explained their functions but we can look more closely at how they work.

Code: [Select]

;*************************************SUBROUTINES**********************************

Wait10ms
clrf TEMP2
movlw 0x0D
movwf TEMP1 ;rough 10ms timer for button debounce.

Loop1
decfsz TEMP2, f ;count down 256*3=768 cycles
goto Loop1
decfsz TEMP1, f ;count down 768*13=9986 cycles
goto Loop1
return

;*************************************************************
ReadEE
bsf     STATUS    , RP0 ;Bank1
movlw 0x04
    movwf   EEADR
    bsf     EECON1    , RD ;start read
    movf    EEDAT    , W
bcf     STATUS    , RP0 ;Bank0
    return
;*************************************************************

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

Like was mentioned earlier, the Wait10ms is a rough countdown loop. The inner loop takes 3 cycles and is repeated 256 times. The outer loop takes 768 cycles of the inner loop and performs that 13 times. The overall number of cycles takes a couple more than the shown number of 9986 but it is close enough as a rough estimate. We are not using this subroutine for exact timing.
The ReadEE subroutine was taken directly from the datasheet example code. You can reference its execution there. Note that we have hardcoded the address 0x04 as the memory we are writing/reading from.
WriteEE is the same way. It is the suggested method in the PICs datasheet to write to the internal EEPROM.

And there you have it. This code leaves open the possibility of adding Macro functions and other things with very little adding to the existing code. If you take a look at GameplayRF code, you can follow along the initial main routine to see how I used the right trigger pin initially with the Analog Converter to read the trigger voltage to determine the controller type instead of dedicating a pin hardwired for this function. It is only done once when the chip powers on and then is set back as a digital pin form there on.

[Modded Matt]

once again hazer, you are the man

[robin1989]

yes you are thats a very detailed post - if you need any more of your stuff hosted on the server so it doesnt go down when you post stuff i am more than happy as nothing is worse for someone than reading a tut and the files going dead

[Hazer]

I can PDF the entire post above and send it to you if you would like.

[robin1989]

if you think that would help people i can easily do that for you

[Ben.]

I Have Looked But Cant Find A Thread Like This For 'Burnmeup2' :/

Any helpers..?

[Modded Matt]

I will try to have it ready by the end of the week.

[Ben.]

Ok thanks.. 

[Ben.]

14) scroll down to the part of the fire rates, it will look like this:
;**********Speed settings: change these to change speed (0x05-0xFF)
FIRERATE1      equ      0x3C
FIRERATE2      equ      0x16
FIRERATE3      equ      0x12
FIRERATE4      equ      0x0F

Hey, One More Question, Are These The Correct Firerates First One, Halo, Second One Cod5, And 3rd Cod4, As I'm Not To Sure.. Thanks

[Modded Matt]

there are 4 modes here, I dont play halo...so I dont really know. the autor listed the origional rate #1 for halo, which I changed for WAW. follow the tut to make your own fire rates.

halo= (hex--0x2F) (fire rate--10.64 shots per second)
cod WAW (hex-- 0x3C) (fire rate--8.33 MAX)
cod 4 best (hex--0x12) (fire rate--27.78)

the rest are random rates. try to find what you like. those are the basics

[Ben.]

Sorry, This Is Kinda On Another Subject..

But On The burnmeup2 Asm, It doesnt have a 4th firemode for rapid fire to be off, is it designed like this, I'm thinking it is something to do with it being a sleeper..

Any helpers..?

Cheersss

[jonagpa]

Does anyone know the hex code for Gears of war 2?

[Dcofer]

Ok so here is my question, i read the assembly code description (though i normally program my pics in C) and when comparing it to the board diagram (below)


(used the wrong picture, i will be using the CG board but the point is the same)

which shows two buttons added to the controller which i would rather use then the sync button however it seems that the code as described by Hazer has nothing to do with the two buttons and is only the stealth option.  Personally I would love to use the right button to cycle through the rapid fire on the right trigger (since i don't dual wield) and use the left button as a substitute for pressing the R3 (right joystick) button.  is this a logical use for this set up?

My question got a little skewed, but are the buttons in the diagram even used in the code?

[Modded Matt]

Dcofe, yes, your question is a little vauge. I will do my best

this is Gameplay RF, the first of two codes in this section. the second is called burnmeup2.. they are very similar.

gameplay uses buttons, 4 modes, hold to change modes, quick press to turn on/off..if you only want one rapid fire trigger, only wire the one side, then wire a second button as you described to the tact switch under the thumb stick.  the thumb sticks dont need coding, as they are just normally open switches.

as for using the sinc button and not any switches, go to the next topic called "How To use.............Burnme up2"

[jonagpa]

what is the speed for rainbow six Vegas 2?

[Hazer]

Ahem:
https://www.acidmods.com/forum/index.php?topic=33232.msg249415#msg249415

[EasyE]

Does anyone know what exact resistors work on the GPRF? 10kohm but is it , 1/4 watt, 1/2 watt? My LED light just stays on with the resistors i have tryed. I just have a blue 10k ohm ressistor not sure if its 1/4 or 1/2 strength. thanks

[Modded Matt]

I use 1/8 it dont matter though.

you say your led stays on....what controller type are you using? if its matrix, you should be using diodes, if its cg2 you need an optocoupler. if its cg1 you have bigger problems.

[EasyE]

Thanks for the response matt i am using a cg1.  I have a 10k ohm that i have been using and it doesn't work for me.  I think i have wired something wrong because my led stays on and i can't change modes on the chip.  Not sure any suggestions will help. thanks

[Modded Matt]

post pics

[EasyE]

This is the best way i know to post pics on here.....http://i875.photobucket.com/albums/ab315/IGL_EVOlution/DSCF2002.jpg

and The pic is with the notch facing down toward the ground.

http://i875.photobucket.com/albums/ab315/IGL_EVOlution/DSCF2003.jpg

[Modded Matt]

a few things here the pics need to be restored in this topic, but it wont let me edit it as it was from the old server.

#1 problem, your controller is CG2
player #4 led is on the wrong side
what is pin 4 and pin 5 going to? hard to see in the pic, these are activation buttons, pin 4 goes to button then vdd pin 5 goes to button then to gnd.


here is the cg pic, but you need an optocoupler for the cg2 or it will never shut off.

[EasyE]

Yes pin 4 is going to leftside button but pin 5 does it go to the button then another wire from there to the ground? Also I am wondering if everything else looked like it was in the right place sorry about the crappy photo ill try and post another soon. thanks again

[Madman340]

Should I install this mod or the GameplayRF2 from this thread? I don't own COD5 but do intend on using this on MW2. Is it the same setup, controller wiring-wise? I got these switches, will they work fine? http://www.radioshack.com/product/index.jsp?productId=2062546

The link to the PDF about changing the speed is bad. What is the range/how does it convert to shots per second? I can do the integer->hex myself, but I don't know what the numbers translate to for SPS.

PS: How do I compile the new asm code in MPLAB? Only thing I could find was Quickbuild, and it didn't make a .hex file, just a bunch of other ones...