The Programmable Stick/Pad Thread!

Tech Talk
149

This is true. Having said which, I’m pretty sure the soldering is a lot easier than most of what goes on in this forum, and the program I’d happily post if anyone actually wanted it. I think there was a thread where insanecombo.com were selling their version of it, for $185 from memory (and the customer supplies the stick). The price went down after that.

I did a breakdown of costs on TZ. Let’s see if this posts right here.

2xMayflash sticks $27x2

1xArduino Mega $65

1xLCD Screen $20

And all the soldering kit etc. I had to buy, you may not.

You could do it cheaper with one stick and a cheaper arduino for 1P testing. I wanted to have both sticks programmable.

You can fairly easily set it to do different strings to defend against, you’d just have to enter the commands for the arduino then set it to randomly choose one after an appropriate interval.

With regards to size, I think the board has about 132kb of onboard memory. The script as it is now takes about 10kb, so that’s a lot of free space. The inputs go something like

//A
if(N==){pinMode(A,OUTPUT);digitalWrite(A,LOW);}
if(N==){digitalWrite(A,HIGH);pinMode(A,INPUT);}

so they would only take up ~100 bytes each. So space wise it would be easy to fit a lot more in.

I haven’t really checked timing beyond 1-2seconds as nothing I did ever really needed it. I suspect it may get a little unreliable with longer periods, but there is also a timing script in there that could be modified to try to improve that.

150

The instructions are compiled, so those if statements would only be like 16 bytes each at most. If you are up to it, try controlling the ports directly by assigning to DDRB and PORTB (for B0-B7; similar DDR_ and PORT_ exist for each bank of pins) instead of digitalWrite and pinMode; there’s a lot of overhead in those functions, and directly controlling them would be much faster and give you better control of the timing.

151

well memory problems seem to be a problem of the past then.
http://microcontrollershop.com/product_info.php?cPath=110_159_439&products_id=3557&osCsid=3b250e4814ef162760cb16948a104aff

given this, I may want to try scripting combos on this. just a few questions

  1. is it correct to assume that basically each directional input from the joystick and each button would have to be wired to a specific pin on the board?

  2. So I’d have to splice the wire and have it going to both the console and the board?

  3. how would you script it? I assume that it’d be something basic like
    if button 6 is pressed //button 6 would be plugged into a certain pin
    then
    {
    activate pin 1 //to jump assuming pin 1 was plugged into the up direction on the joystick
    delay 30ms
    activate pin 5 //attack in air assuming pin 5 was plugged into the action button 1 on the joystick
    ]
    etc

  4. how would one scripting a combination of buttons/pins being held/activated for a certain duration?

152

http://www.megaupload.com/?d=GWMW2GBL
That has my main sketch as well as other things that I used. I’m sure one look at it would make anyone think it was written by someone with no IT experience who basically understood digitalWrite, if and pinMode commands and little more. They would be right. I don’t even really get syntax although somehow it’s in there.

  1. Yes

  2. I just soldered onto where they’d soldered the buttons onto. It seemed to work, don’t really know why.

  3. Basically I have it set so that there’s a counter that increases the value of N by 1 every frame. Then, I have the seventh and eighth buttons set so that when they are released, the counter goes back to zero and starts again.

Then, with code like

//A
if(N==1){pinMode(A,OUTPUT);digitalWrite(A,LOW);}
if(N==3){digitalWrite(A,HIGH);pinMode(A,INPUT);}

It will press A on F1 and release it on F3.

There are also 4 variables, I, J, i and j which work like

//A
if(N==I){pinMode(A,OUTPUT);digitalWrite(A,LOW);}
if(N==I+1){digitalWrite(A,HIGH);pinMode(A,INPUT);}

where you can hold the seventh button and use directions to alter the value of I. If you set I=7, then release it will press A on F7 and release it on F8.

  1. I think this should be explained by the above.

I had a look into PORTB, and had seen it in KoD’s original scripts. Not sure that it is applicable to the Mega, and don’t have the board here to try it. If someone was building from scratch it seems like a better place to start from.

153

going over your code, it seems that the extern Timer1 refuses to be seen as an object of class TimerOne. Its been too long since I did OOP lol. But other than that the code seems fine. Just a nightmare to parse through it since its all inline. Though maybe my new andurino (SP?) compiler vs .18 has had some changes that your code isn’t completely compatable anymore.

On another note I was able to acquire a 2nd ascii program pad on japanese yahoo auctions. To those still wanting one check back on this link once a week. I got lucky as I hadn’t checked in a few months but they do pop up every so often.

http://search4.auctions.yahoo.co.jp/search?sb=desc,cat&desc=��������++++++++++++&cat=25464&auccat=25464&acc=jp&apg=&f=0x52&s1=end&o1=d&alocale=0jp&mode=1

154

If you care about space, there’s basically no excuse for not using a bit fields for the pins, so, even without run length encoding, it should be 32 bits per position for 2 4 direction, 12 button joystics. (A bit bigger if you want to support analog stuff.) Beyond that, you can almost certainly save a bunch of space by making it 32 bits for pins and 8, or even 16 bits for duration.

Naively, that gives you 256 frames per k so about 7 minutes with the 132 k memory. Assuming a (honestly very conservative) 4-1 compression from run length encoding would give around half an hour.

I’m looking at doing my own thing with a C-stamp microcontroller which I had on the shelf, and, really what I find myself wondering about is how well it can synchronize with the game, and how the combo programming cycle time can be minimized.

Also, if someone else is tinkering with home-built programmable sticks, Street Fighter samples at 60/1.001 (just like the NTSC frame rate) instead of 60 Hz, so timers would be better set to .0166833 seconds per frame.

155

Ordered today

http://www.lizardlick.com/pages/boards.shtml
2x Toodles Cthulhu PC/PS3 Board

http://arduino.cc/en/Main/Hardware
1x Arduino Mega

http://www.futurlec.com.au/LCDDisp.jsp
1x4x20 LCD screen

http://www.akihabarashop.jp/catalog/AstroCity2L12B.jpg
1xAstro City Panel

Lets see how the round 2 stick goes (will hopefully overcome the issue of being okay to test things on, but crap to play on.)

Hauppauge HD PVR should be here soon too, planning to make a very capable testing box.

156

Just a quick update. I got my first generation PStick back having lent it to a friend, and went about revising the code to be neater and simpler to use, as well as testing how accurate the timing was.

The new code
http://www.megaupload.com/?d=EJ1KY0MW

The timing
http://www.megaupload.com/?d=TGZQA8AK
Basically, the code was set up to press 1+2+3+4 on F1, F101, F201, etc. all the way up to F1001. It also releases the buttons after one F.
The video shows that it achieves this with no error. This is mainly thanks to chaning from 16666 (drops 2 frames over 1000) to 16683. Thanks Rufus.

Work is progressing on the Round 2 stick, but waiting for akihabara shop to ship my panel. Stalled until that happens.

The main improvement in this code is you can now input commands as

press (starting frame, finishing frame, button/direction 1, button/direction 2, button/direction 3, button/direction 4)

so to do d+HP on frame 61 is just
press (61,62,D,C)

Makes it a lot easier to type and for other people to understand. If you need more than 4 buttons/directions, just do two press statements.

157

Glad to be of help. I’ve got a similar set-up to yours with a C-stamp and 2 SE sticks. I can put up the info - if anyone is interested, PM me.

FWIW: The frame rate seems to vary depending on the display for some games on my Xbox. I seem to get 59.94 or 60.015 fps depending on whether SFIV is on a TV or on a monitor.

158

Made my round 2 stick, it is working well. Have managed to do a few things I’d be holding off on. The Cthulhu work very well for it.

http://img72.imageshack.us/img72/9741/cimg8772.jpg

http://img18.imageshack.us/img18/8894/cimg8774.jpg

159

http://img821.imageshack.us/img821/7799/cimg8912.jpg

http://img529.imageshack.us/img529/3595/cimg8919.jpg

http://img231.imageshack.us/img231/7400/cimg8920.jpg

This is my second attempt at a programmable stick. First one was two Mayflashes, an arduino and an LCD screen. Worked well but rubbish to play on and rubbish to look at. Hence, the motivation to try again.

This one is an astro-city panel, 2xCthlhu MCs, an LCD screen, 8 LEDs, and soon a PS3eye attached for player/hand-cam.

Pretty much done for now, the only thing I would think to add would be a shutting lid, and perhaps storage for the cables. Also, the PS3eye isn’t actually attached yet, waiting til my replacement arrives before I do that. LEDs are in place now, no real functionality yet but will think of something. Wondering if I can find some opaque covers for them as they look a little small as is, and the drill holes are very obvious around them.

Will try some art for it one day. Will add GCN/PSX functionality one day.

HRAP3 for size comparison. This is no laptop stick.

Probably better to look at the videos here
http://www.youtube.com/user/noodalls

as it gives a better idea of what the stick is capable of.

P.s. Cthulhus work like a charm, they seriosuly reduced the amount of effort this took.

160

Noodles, do you have a guide on how to make one of these programmable sticks?

1 player
Using Axisdapter
LCD screen not required
EYE camera not required

161

There are two parts to it, the wiring and the programming.

I’ve not used an axisadapter before, but assuming it works in the same fashion as the MCs, I would wire it up something like this.

http://img18.imageshack.us/img18/6861/exampleimage.jpg

Perhaps toodles could let us know if there looks like there’d be a problem with this. I’m not sure how enamoured he is with the arduino though. :wink:

I suspect the only trick would be that the axisadapter looks like it hasthree sets of grounds, not sure whether you could put all of them onto a single arduino ground. The arduino duemilanove does have three sets of grounds too though.

As for programming, I’d be happy to post up my latest sketch. I noticed from your youtube profile that programming is one of your hobbies, so perhaps you could post up your take on it if you made it better.

162

Well I am a programmer, I wrote the Media Library you see here on SRK.
http://www.vbulletin.org/forum/member.php?u=110775

But I’m not much of an engineer; I depend on people like toodles to figure that stuff out, and I’ll just wire it together. Sure, I know the basics and the principles behind P=I*E and I=E/R etc, but I don’t really see the need to make use of it when there are always other people around who can do it better than me. Yes, the AXISdapter has 3 sets of grounds because the PS3 controller has 3 sets of grounds. Toodle’s Cthulhu only has one set of grounds because the Cthulhu is a glorified USB controller (the PS3 uses USB standards, unlike the 360), thats also why the Cthulhu works so well. I guess if I had to use a Cthulhu, I’m okay with that. Would just prefer an Axisdapter because I have something like 9 PS3 controllers and 4 axisdapters left over.

If you wrote a guide on how to build one of these sticks, that would be awesome.

163

Inspired by KoD of VFDC - Virtua Fighter Dot Com and helped by Slapper Joe of OzHadou, I went about building a programmable stick. The first prototype was with an old Hori Tekken 4 stick, the first round with two Mayflashes, and now my round 2 is with an Astro city panel. The features have been added and added as I went, but I thought it would probably be a good idea to write down how I made my most recent stick, in case anyone wants to follow.

Warning
A note however, from what I understand it is generally a bad idea to have the arduino connected to a console and a PC at the same time. For whatever reason the battery powering the arduino doesn?t seem to supply enough power to keep things going, so I keep mine connected via USB to power it, and I can also upload sketches repeatedly. If you chose to follow the steps in this guide, you take on responsibility for any damage incurred, whether to your computer, your game console or any other electronics or other involved.
I suspect an axis adapter might avoid this problem, if it still communicates wirelessly with the ps3.
My Materials
Astro-city panel with seimitsu parts
Extra buttons (4x24mm, 4x30mm)
Cthulhu MC x 2
Arduino Mega (duemilanove is enough for 1P, Mega for 2P)
LCD screen
LED lights
PS3 eye
Bare minimum
Arduino
Buttons/joystick
Other equipment
25W soldering iron
Flux
Wire
Header pins
Soldering stand

WIRING
The basis of this is straight forward. The arduino has the ability to write or to read through its pins. By connecting the pins to the joystick board, you are able to either read button inputs, or send outputs to the board and then on to the game console. In this way, you can very precisely control what you want your controller to do.

http://img18.imageshack.us/img18/6861/exampleimage.jpg

Here is the basis of it all. This setup involves the arduino, a Cthulhu MC and a button. There are four wires.
Red ? connects the arduino to the Axis adapter. This is the connection that lets the arduino read what is being pressed, and also write to the Axis adapter, which will then go on to the console.
Yellow ? connects the button to the Axis adapter. When the button is pressed, a signal is sent to the axis adapter and then on to the console.
White ? ground wire. Completes the circuit so that when the button is pressed the circuit flows.
Black ? ground wire to the arduino. Also needs to be there to let the arduino send its signals.

My way of connecting these was to braid the yellow and red wires together, then tin them, then solder them onto a header pin, and clamp this into the Cthulhu MC. The yellow wire is soldered onto one pin of the button, and the white wire onto the other. The white and black wire can be braided, tinned and soldered onto a header pin in the same fashion as the yellow and red. At the arduino end, I use header pins again, with the red and black wires tinned and soldered on. I try to cut very close to the end so there is little exposed wire not connected to a header pin to cause shorts.
For the rest of the buttons, the ground section can likely be daisy chained to reduce the amount of work needed. For an Axis adapter you might need to do it by groups, for my setup the astro-city came with groundwires already set up so I used those.
For the remainder of the yellow and red buttons it?s just a matter of repeating the braiding, tinning and soldering for each one.

Once you have connected a button or two, it?s probably worth uploading a simple sketch to test that everything is working. Something like when square is pressed also press triangle would test both the read and write functions fairly easily.
Then once everything is connected, you can program your full sketch, upload that and start doing whatever it is you want to do.

164

//This is the basic sketch for the programmable stick. This is uploaded to the arduino, and from there will send outputs to the MC Cthulhu and on to the PS3, allowing you to send commands
//to the PS3.
// It also has the ability to read what is being pressed on the controller, through the Cthulhu and report this to the Arduino.
//In its current form, it has two sticks attached (four directions), with eight buttons each, as well home, select and start buttons. All of these are available to be send inputs or outputs.
//There are also eight LEDs attached, on pins 54-61. These currently serve very basic functions, but could be set up to do more advanced features.
//There is also an LCD screen connected. This allows for display of the variables beings used.
//The sketch is frame accurate
//At the moment, the way the sketch works is that when you press and release the SELECT button, a value N will be reset to zero (N=0). Then, every time 16.683msec passes (1 frame at 60hz)
//N will be increased by one. So after 1 second, N should equal 60.
//This can then be used to set up the timing for commands. Lets say you want to do something on frame 20 (we will refer to this as F20 from now on). So, you would need to tell the arduino
// something like “If N is 20, press button X.”
//Remember also, that the arduino is just a dumb machine, so you also need to remind it to stop pressing the button (it would be easy to program it to release the button after a frame every
//time you tell it to do something, but this could make it harder for holding buttons for logner.

//It’s probably worth mentioning the syntax used in this sketch for sending commands to the arduino. If you input the command "press(20,25,A,B); that will press buttons A+B on F20, and release
//them on F25. It used to be a lot longer, this is I feel the ideal balance between typing too much and not having enough control.

//Remember, when you press and release SELECT, it will reset the N value to zero. Therefore, every time you press and release SELECT, it will wait 20 frames and then press A+B for a duration of
// 5 frames.

//Here are some examples of other common moves. Once you get the hang of them, it’s not to hard to work out what to type.
//Fireball - press(1,3,D); press(2,4,R); press(3,4,A);
//Shoryuken - press(1,2,R); press(2,4,D); press(3,4,R,A);
//f,F+2 in Tekken - press(1,2,R); press(3,5,R); press(4,5,B);

//You will have probably already worked out, each of the buttons is referred to by a specific name, which is defined at the start of the sketch. My way of doing this is to use capital
//letters for player 1 and lower case for player 2. This means that I can use the same letters in duplicate, but have it obvious to whom it refers.

// The directions are referred to as U,D,L,R. The buttons are
// A B C P
// X Y Z Q
//Why not A,B,C,D? Well, because D is already used by a direction. HOM, SEL and STA are fairly obvious as well.

//Now is probably the right time to introduce the four variables, I,J,i and j. Let’s look at an example to explain why we need variables. Let’s say we want to do a simple link with Ryu,
//f+HP,d+HP
//You could try inputting
//press(1,2,R,C); press(3,5,D,C); However, as you would quickly appreciate, the timing would be all wrong. This would do the d+HP motion far too soon,
//and the motion would be complete long before the input window occurs. Now, to work out the timing there are a few things you can do. You could retype the sketch, increasing the timing by one
// or a few frames each time, until you find the correct timing. This is fairly labourious, especially if you’re going to be making a combo with multiple parts (and other than James Chen,
//no one has made a good 2HIT combo movie.
//You could record the game (preferably at 60fps) and estimate when the window will occur, based on animations finishing. This works quite well for Tekken, as its hit analysis feature
//changes colour when the recovery is finished, making it quite obvious when to input the next command. There is however an easier way.
//What if we could keep f+HP as a constant, so that every time you press and release SELECT it will do it on the first frame, but then vary the timing on the f+HP portion.
//This is exactly how this sketch is set up to work. We assign d+HP a variable I, and instead of press(3,5,D,C); we just input it as “press(I,I+1,D,C);” This means that on frame I,
// it will do the listed command, and after uploading we are free to alter the value of I. For example, if we run this sketch with I equal to 40 it will still be too early, and if
//we run the sketch with I=80 it will be far too late. I believe I=63 or thereabouts is the correct value to have this combo work.

//Now, if we upload the sketch with a variable I, but then have no way to manipulate it once the sketch is uploaded, it’s no better than manually editing the sketch each time.

//The way I have it set up at the moment is to have four different variables (I,J,i,j) and control each one with a button, P,Q,p,q respectively. While holding button P, it will increase the
//value of P depending in which direction you press the stick. R will increase it by 1, U will increase it by 5, L will decrease it by 1, D will decrease it by 5, l will increase it by 10,
// u will increase it by 20 and r will increase it by 50. d will decrease it by 100. There are two additional features, holding sel and pressing c will make all the value 0, and holding sel
//and pressing z will make J one above I, i one above J and j one above i (so that they fire off one frame after the other). You can always set the values to less than zero to make
// the sketch ignore them (as it only starts counting at 0.)

//There are lots of other functions that can be programmed in as well. A control capture is not too hard to implement. The simplest way to do this is to have it read when each button
//is pressed and released, nad output this to the serial minitor. If you do this in the same syntax as that used in the normal sketch to instruct the arduino to do commands,
//then it is a simple matter of cutting and pasting into the sketch once you find what you want.

//You can also have the arduino randomly choose between different options to facilitate defense training or throw break training.

// You can also use it to practice timing, so that it will feed back (LCD or serial)
//when inputs are done at the right time (e.g. Just frames.) You can combine this with throw break training as well.

//A quick note on timing. Initially I had the sketch set up so that the arduino would do a move, then I would use the delay function to wait the required number of msec, and then increase
//N by 1. However, the problem with this is that if you want to do a lot on one frame, potentially it can take a few msec, and so if you take say 3msec to do an action, and then delay the
//normal 16msec, you will end up running slow.

//Instead of this, the way it is set up now is to have an interrupt set up, so that it should stop whatever you are doing when time is up, and advance on to the next frame.
//This seems like the more accurate way of doing it.

//What follows is the main sketch itself, with some notes to the side to explain what is going on.

165

#include “TimerOne.h” //Included sketch for timing
#include <LiquidCrystal.h> //Included for LCD screen
LiquidCrystal lcd(12,11,8,5,4,3,2); //sets up the pins for the LCD. Note, cannot use 9 or 10 as these are used by the interrupt timer
int backLight=13;

int F=16683; //Timing for one frame. Change if using PAL instead of NTSC.
int N=0; //Starts the frame counter at 0. When you upload it will start at zero and then begin counting up. After that, releasing SELECT will again reset N to 0.

int ADV=0; //Used as the trigger to move to the next frame once 16666msec have passed
int I=10;int J=20;int i=25; int j=25; //Set some inital values for the variables
int V;

int u=22;int d=24;int l=26;int r=28;int a=30;int b=32;int c=34;int x=36;int y=38;int z=40; int p=42; int q=44; int hom=48; int sta=46; int sel=50;
int U=23; int D=25;int L=27; int R=29; int A=31; int B=33; int C=35; int X=37; int Y=39; int Z=41; int P=43; int Q=45; int HOM=49; int STA=47; int SEL=51;
//Define which pins the buttons are connected to on the arduino

int LED1=54; int LED2=55; int LED3=56; int LED4=57;int LED5=58;int LED6=59;int LED7=60;int LED8=61;

int AState;int BState;int CState;int XState;int YState;int ZState;int UState;int RState;int LState;int DState;int PState;int QState;
int STAState; int SELState; int HOMState;
int aState;int bState;int cState;int xState;int yState;int zState;int uState;int rState;int lState;int dState;int pState; int qState;
int staState; int selState; int homState;

unsigned long time;

void setup(){

Timer1.initialize(F); //This is the timer function from timerone. Every 16666 msec (or whatever F is set to) one frame will tick over.
Timer1.pwm(9,900);
Timer1.attachInterrupt(FrameAdv);

Serial.begin(9600);

pinMode(backLight,OUTPUT); //Turns on the backlight for the LCD
digitalWrite(backLight,HIGH);//Write frame data testing on the LCD
lcd.begin(20, 4);
lcd.clear();

aState=digitalRead(a);// do these have to be done in setup?
bState=digitalRead(b);
cState=digitalRead©;
xState=digitalRead(x);
yState=digitalRead(y);
zState=digitalRead(z);
uState=digitalRead(u);
dState=digitalRead(d);
lState=digitalRead(l);
rState=digitalRead®;
pState=digitalRead§;
qState=digitalRead(q);
AState=digitalRead(A);
BState=digitalRead(B);
CState=digitalRead©;
XState=digitalRead(X);
YState=digitalRead(Y);
ZState=digitalRead(Z);
UState=digitalRead(U);
DState=digitalRead(D);
LState=digitalRead(L);
RState=digitalRead®;
PState=digitalRead§;
QState=digitalRead(Q);

pinMode(a,INPUT); // Sets all the arduinos pins to initially read inputs and not output unless instructed.
pinMode(b,INPUT); //* Can this be done with a <<statement
pinMode(c,INPUT);
pinMode(x,INPUT);
pinMode(y,INPUT);
pinMode(z,INPUT);
pinMode(r,INPUT);
pinMode(l,INPUT);
pinMode(d,INPUT);
pinMode(u,INPUT);
pinMode(p,INPUT);
pinMode(q,INPUT);
pinMode(sel,INPUT);
pinMode(sta,INPUT);
pinMode(hom,INPUT);

pinMode(A,INPUT);
pinMode(B,INPUT);
pinMode(C,INPUT);
pinMode(X,INPUT);
pinMode(Y,INPUT);
pinMode(Z,INPUT);
pinMode(R,INPUT);
pinMode(L,INPUT);
pinMode(D,INPUT);
pinMode(U,INPUT);
pinMode(P,INPUT);
pinMode(Q,INPUT);
pinMode(SEL,INPUT);
pinMode(STA,INPUT);
pinMode(HOM,INPUT);
pinMode(LED1,OUTPUT);
pinMode(LED2,OUTPUT);
pinMode(LED3,OUTPUT);
pinMode(LED4,OUTPUT);
}

void FrameAdv(){ADV=1;}//When the timer ticks over, set advance integer to 1 so that the next frame starts

void press (int start, int finish, int m1, int m2, int m3, int m4) //This is the function that makes it easy to input commands, instead of having to
{if(N==start){pinMode(m1,OUTPUT);digitalWrite(m1,LOW);} //Type everything each time.
if(N==finish){digitalWrite(m1,HIGH);pinMode(m1,INPUT);}//The syntax is press(frame to start on, frame to stop on, button/direction 1,2,3,4)
if(N==start){pinMode(m2,OUTPUT);digitalWrite(m2,LOW);} // If you need more than 4 buttons/directions pressed on a set frame, just set two press functions.
if(N==finish){digitalWrite(m2,HIGH);pinMode(m2,INPUT);}
if(N==start){pinMode(m3,OUTPUT);digitalWrite(m3,LOW);}
if(N==finish){digitalWrite(m3,HIGH);pinMode(m3,INPUT);}
if(N==start){pinMode(m4,OUTPUT);digitalWrite(m4,LOW);}
if(N==finish){digitalWrite(m4,HIGH);pinMode(m4,INPUT);}}
void press (int start, int finish, int m1, int m2, int m3)
{if(N==start){pinMode(m1,OUTPUT);digitalWrite(m1,LOW);}
if(N==finish){digitalWrite(m1,HIGH);pinMode(m1,INPUT);}
if(N==start){pinMode(m2,OUTPUT);digitalWrite(m2,LOW);}
if(N==finish){digitalWrite(m2,HIGH);pinMode(m2,INPUT);}
if(N==start){pinMode(m3,OUTPUT);digitalWrite(m3,LOW);}
if(N==finish){digitalWrite(m3,HIGH);pinMode(m3,INPUT);}}
void press (int start, int finish, int m1, int m2)
{if(N==start){pinMode(m1,OUTPUT);digitalWrite(m1,LOW);}
if(N==finish){digitalWrite(m1,HIGH);pinMode(m1,INPUT);}
if(N==start){pinMode(m2,OUTPUT);digitalWrite(m2,LOW);}
if(N==finish){digitalWrite(m2,HIGH);pinMode(m2,INPUT);}}
void press (int start, int finish, int m1)
{if(N==start){pinMode(m1,OUTPUT);digitalWrite(m1,LOW);}
if(N==finish){digitalWrite(m1,HIGH);pinMode(m1,INPUT);}}

int check(int V1, int V2){
if( digitalRead(V2)==LOW){digitalWrite(V1, HIGH);
if(digitalRead(U)==LOW){if(digitalRead(U)!=UState){V=V+5;}} //
if(digitalRead(L)==LOW){if(digitalRead(L)!=LState){V=V-1;}}
if(digitalRead(D)==LOW){if(digitalRead(D)!=DState){V=V-5;}}
if(digitalRead®==LOW){if(digitalRead®!=RState){V=V+1;}}
if(digitalRead(u)==LOW){if(digitalRead(u)!=uState){V=V+20;}}
if(digitalRead(l)==LOW){if(digitalRead(l)!=lState){V=V+10;}}
if(digitalRead(d)==LOW){if(digitalRead(d)!=dState){V=V-100;}}
if(digitalRead®==LOW){if(digitalRead®!=rState){V=V+50;}}
}}

void loop(){ // The start of the working part of the script
if (ADV==1){

//press(1,2,D); press(3,4,A); press(26,27,R);press(I,I+1,A);//press(I,I+1,A);
//press(1,2,R,U,B); press(I,I+1,A);
press(1,2,L); press(1,4,D);press(3,5,R); press(6,8,D,L); press(7,8,B,X);
press(I,63,d);

check(LED1, P); I=I+V; V=0; //pressing L decreases I by 1 and pressing D decreases I by 5.
check(LED2, Q); J=J+V; V=0;
check(LED3, p); i=i+V; V=0;
check(LED4, q); j=j+V; V=0;
if(digitalRead(SEL)==HIGH){if(digitalRead(SEL)!=SELState){N=0;}digitalWrite(LED1,LOW);digitalWrite(LED2,LOW);digitalWrite(LED3,LOW);digitalWrite(LED4,LOW); }

if(digitalRead(sel)==LOW){lcd.clear();
if(digitalRead(a)==LOW){if(digitalRead(a)!=aState){l=28;r=26;L=29;R=27;}}
if(digitalRead(b)==LOW){if(digitalRead(b)!=bState){r=28;l=26;L=27;R=29;}}
if(digitalRead(x)==LOW){if(digitalRead(x)!=xState){u=24;d=22;U=25;D=23;}}
if(digitalRead(y)==LOW){if(digitalRead(y)!=yState){u=22;d=24;U=23;D=25;}}
if(digitalRead©==LOW){if(digitalRead©!=cState){I=0;i=0;J=0;j=0;}}
if(digitalRead(z)==LOW){if(digitalRead(z)!=cState){J=I+1;i=I+2;j=I+3;}}}
// int r=28;int l=26;int L=27; int R=29;int u=22;int d=24;int U=23; int D=25;

UState=digitalRead(U);DState=digitalRead(D);LState=digitalRead(L);RState=digitalRead®;
PState=digitalRead§;QState=digitalRead(Q);AState=digitalRead(A); //This makes the arduino acknowledge the current state of the buttons.
uState=digitalRead(u);dState=digitalRead(d);lState=digitalRead(l);rState=digitalRead®;
pState=digitalRead§;qState=digitalRead(q);aState=digitalRead(a);bState=digitalRead(b);cState=digitalRead©;xState=digitalRead(x);yState=digitalRead(y); zState=digitalRead(z);
SELState=digitalRead(SEL);selState=digitalRead(sel);

lcd.clear();
lcd.setCursor(0,0);lcd.print(“I=”);lcd.print(I);
lcd.setCursor(0,1);lcd.print(“J=”);lcd.print(J);
lcd.setCursor(0,2);lcd.print(“i=”);lcd.print(i);
lcd.setCursor(0,3);lcd.print(“j=”);lcd.print(j);
lcd.setCursor(10,3);lcd.print(“N=”);lcd.print(N);

if(l==26){lcd.setCursor(10,0);lcd.print(“1P2P”);}
if(l==28){lcd.setCursor(10,0);lcd.print(“2P1P”);}
if(u==22){lcd.setCursor(15,0);lcd.print(“Norm”);}
if(u==24){lcd.setCursor(15,0);lcd.print(“Inve”);}
ADV=0;
N=N+1;

}
}

166

This is a computer driven stick project:
Computer Controller Project

It’s very simple, but will work with any 5V common ground controller - though there isn’t any windows-side driver software, it’s just a matter of sending bytes down the serial line with timing. I’m not sure what the operating voltage of the AXISdapter is, so the drive resistors might need to get switched out, and it will need its own power supply.

167

is there easy tutorial for mayflash fight stick :frowning:

i got confuse but im trying :confused: i dont want to make mistake :o

168

There’s not really a tutorial per se, as I worked out how to do this with a friend. Having said which, combining the pictures above on page 6 with the brief layout picture on page 7 you should be able to work it out. Probably the easiest thing to do would be to solder two wires onto a joystick direction, one active and one ground, and then run a few simple tests to get a basic idea of what’s going on. You could probably just wrap them around even if you’re worried about something going wrong.

http://img80.imageshack.us/img80/2263/cimg8015.jpg

(interesting, I initially wrote suture not solder. guess it shows my background)