Newbie Pasm questions.

IncVoid

I was throwing together my xbox modded controller back together that would probably make most of you guys go blind here(tape, hotglue, bare wires).

I needed to invert bits in asm, simple right?

But there is no not instruction, I used neg, followed by a sub 1.
but then I saw that xor with $FF_FF_FF_FF would work.
Which led me to think of having a $FF_FF_FF_FF defined always, because you can't use a literal over 512 I believe.
Are other chips similar, or the compiler changes NOT to a xor $FF_FF_FF_FF instruction?

I have seen other peoples code using the variable that only adds 1 to the s or d field, which is used when increasing the memory pointer address.

So what is a common set of "defines" you use in pasm?
sfield increment
dfield increment
task_ptr
allbits $FF_FF_FF_FF

I've also seen pin_mask and !pin_mask for ANDing and ORing of DIRA

FORGOT!

How can I use the ?var spin operator for the lfsr in asm?
using the prop manual searching lfsr, it only mentions spin code.

I would really like to add some random "noise" to calculated FRQA values to "jitter" things up. But looks like I'm going to have to "think" and do a lil reading on generating random numbers. ugh.

ratronic

I see you have removed your program I hope you saw some of your problems as I was just going to respond even though I don't know what adc you are using.

Mike Green

You're right. There is no bit invert instruction and it's common to have a 32-bit constant with all 1 bits. It's also common to have a constant $FFFF0000 and $0000FFFF. I often have a constant |<9 for incrementing the destination field. You can use an immediate value for incrementing the source field. I use |<pinNumber for changing DIRA and OUTA with OR and ANDN. The latter avoids the need to have an inverted bit mask.

Heater.

Spins random operator is an LFSR implemented in PASM in the Spin interpreter. One could no doubt write something similar or even copy the code out of the Spin interpreter the source of which is floating around here somewhere.
However it's not a particularly good pseudo random number generator and you might want to write a better one in PASM. Here is a dead simple algorithm to look at: http://forums.parallax.com/showthread.php?136975-JKISS32-High-quality-PRNG-with-RealRandom-seed-save-a-COG.


Then there is the possibility to get real random numbers out of the Prop using the RealRandom object which is in the object exchange (Edit: Just remembered, real random is include in JKISS32 above as well.) http://obex.parallax.com/objects/62/

IncVoid

Thanks Heater I'll have a look at that dead simple algo.
Thanks Mike green I forgot about the encode decode. Those are spin instructions? but they work at compile time correct?
Thanks for the tips and reaffirming my assumptions!


Maybe you replied to the wrong one ratronic? I dont think I posted a program.
It's just toggling a pin, and I wanted to add some randomness to it in asm.
I'll have to toil with "asking" the spin code on top of it to generate a random cog value.
Might be slower if I wait for it.

I'm thinking every loop just generate new random values and the cog can keep using that value until "spin" updates it.

I have a hydra. Have a cog reading a 4021 I believe it is, its in the nintendo style controllers.
It sees the presses and delivers it to the hire spin program, which has a menu on screen controlling frqa and some crude pwm stuff. I just wanna jitter frqa a lil bit.
I suppose I'll just get new "random" values everytime I look to see if the menu items have changed.
I haven't done any research on the how much a persons finger press frequency deviates, but I'll just make it a wide enough range until it is too far of a range.

turbosupra

Did you hack the 360 with the prop?

IncVoid

No it is super ghetto. just a single wire from a pin being toggled by the CTRA running in NCO mode.
Basically combined a blinking led/ counter tutorial with a nes gamepad reader, threw in some strings and gfx/tv driver and was blinking an led at different rates and duty cycle I guess, then instead of blinking the led, I put it to the right trigger pot.
The nes pad is just for button presses mounted to the underside of the controller.

I guess a DIRA toggle would be better. I don't know if setting DIRA to 0 for that pin leaves it floating.
If the button is pressed it sets dira to output and the counter toggles that pin high/low.
What would really be nice is to have the counter toggle DIRA and leave that "output" always in the high/low state required. So it looks like the trigger is swinging back to normal 1.3v that I was seeing when I metered it.
It looks very bad if the pot is going "out of range" reading low volts.
I imagine games "know" that somebody is cheating cause the pots go out of range, less than 1.3v or higher, I didn't read the "pressed" voltage.

I did see a pwm circuit in another post that outputs the voltage you need, based on duty cycle I believe. I see how you could toggle voltages between 1.3 and the pressed voltage needed.
But I wanted to keep it simple. I suppose I could get "caught" swinging voltages out of range of the hardware pot either way.
A trigger finger that is too perfect, and a pot that goes out of range.
I haven't looked to see if other brands of controllers have diff pot ranges. Or if they "normalize" on bootup, looking for the "center" position.

But thanks for the inquiry turbosupra.

Heater.

IncVoid,

No it is super ghetto.

I don't mean anything bad here but do you realize how frustrating it is for us 50 something years old guys to learn a new dialect of English every 10 years or so?

turbosupra

Hi Heater,

I agree with your point, but being almost 1/2 of that I will translate (even though you've probably googled it already). The term that might be more understandable would be "jerry-rigged" (no offense to any Jerry's around here ) or half-assed.

IncVoid, I've learned that the better English you use, the more responses you get. I have to ask for help a lot, so I make sure to TRY and make my posts as easy to read/understand as possible.

Anyway, it appears you have modded the 360 with the prop? That's pretty cool if so.

IncVoid

Just the controller. One wire from prop IO pin to a tap on the controller pot.

Sorry Heater. Yes it is rigged and horrible. There would be a much more elegant solution.
I'm thinking of getting a prop stick and replacing the hydra with it.

It would be much smaller, get power from the board.

Another question?
I got a .1uF as closest I could get it to the hydra io cards expansion pin. But I still get occasional noise, The first day I wasn't getting any phantom trigger pulls.
I also noticed when I barely squeeze the regular pot trigger(xbox controller) it rapid fires on its own, which makes me think I'm getting some rc ringing cause of the cap.
*edit* Nope, it does it even without the capacitor, not connected to the expansion card.

I was thinking putting a diode in one direction or the other to make it so the controller can only source/sink. But that would isolate the capacitor from the pot. I guess I could just put the cap closer to the pot or on the other side of the diode.

I might have a big concept error here.
I was thinking put 2 of the same caps in parallel to try to "lower" the frequency it filters, It might not be catch the lower noise? Might not be enough, I might not have the true magnitudes in proportion here.

But the diode would help me isolate the prop from the pot in one direction correct? I guess that is the fun of this is trying what works?