'Best out of 3', Average or other Stabilising code

[DrWho198]

I'm looking for some assembly code to stabilise my paddle input.

The way that I look at it now I would like to take 3 values of the past 3 frames and get an average of the byte value.

The input that I get from my paddle routine is a value of 0 to 15.

 

Does anyone have any idea how to achieve this with as little as code as possible?

[+SpiceWare]

If your paddle input isn't stable then you most likely need to clean your paddles.

 

That said, the 6507 does not have a built in divide feature, so best out of 3 isn't that easy to do. The 6507 does, however, have bit shift functions which can be used for divide by 2 or multiple by 2. Use the LSR instruction for divide by 2, use two LSRs for divide by 4.

 

Average over 2 paddle readings:

 clc
 lda PaddleReading1 ; load A with the first paddle reading
 adc PaddleReading2 ; add in the second paddle reading
 lsr ; divide by 2.  At this point A has the average

---

Average over 4 paddle readings:

 clc
 lda PaddleReading1 ; load A with the first paddle reading
 adc PaddleReading2 ; add in the second paddle reading
 adc PaddleReading3 ; add in the third paddle reading
 adc PaddleReading4 ; add in the fourth paddle reading
 lsr ; divide by 2
 lsr ; divide by 2 again, net result is divide by 4.  At this point A has the average

---

Since your paddle readings are 0-15 you don't have to worry about exceeding 255 when adding up the numbers. The first routine can handle paddle readings of 0-127, the second can handle 0-63. The routines would need to be modified to handle paddle readings larger than that.

[+SpiceWare]

Now that I think about it, there was a topic about various divide routines and I think somebody did post one for divide by 3.... Here it is - Fast divide by seven?.

[GroovyBee]

A simple moving average might work :-

 

https://en.wikipedia.org/wiki/Moving_average

[DrWho198]

Thank you for the help.

I know the paddles need a cleaning, and to be honest I already opened them up and cleaned them twice but they are still not stable.

I'm going to replace the pots in one of my sets when I get the chance.

But then I thought... wouldn't it be nice to compensate for the dying pots? So, just as an extra I wanted to add this routine.

A divide by 2 wouldn't work in case you are between 2 numbers, that would just output the lowest number... making this totally useless

I could go for the divide by 4 version. Or I could use a lookup table for a divide by 3, but using a lookup table might be too slow.

I'll give the divide by 4 a try. This would result in a slower response but if I count the last frame twice then that would give the last frame priority.

Again something to think of and play with.

Thanks again for the help.

[Omegamatrix]

The averaging between 2 frames works well. If you want a divide by 3 without a big look up table, then you can find an optimized one in my blog (18 bytes, 30 cycles).

[+SpiceWare]

Instead of replacing your pots, consider brand new paddles. They're made for the Atari Flashback and work great on a real Atari. I bought them after this happened the last time I cleaned my paddles.

[Wickeycolumbus]

What about having a subroutine that approximates a single byte divided by 3? You would individually give the routine each byte, then sum them after the results are returned.

 

Something like:

 
   lda Paddle1
   jsr Divide3
   sta Temp
   lda Paddle2
   jsr Divide3
   clc
   adc Temp
   sta Temp
   lda Paddle3
   jsr Divide3
   clc
   adc Temp
   sta Temp


 

That way, even if the bytes are all 255, no intermediate value would be larger than a single byte. The above code would spit the average into Temp, provided the subroutine that divides by 3 works correctly with remainders and such (always rounds down). Definitely a lot of room for optimization (forget the subroutine and roll it all into a loop), but I think the idea would work out pretty well.

Edited September 12, 2015 by Wickeycolumbus

[DrWho198]

If I understand you correctly then this would not work, since 4/3 would be 1. And your routine would give an average of 3 from the series (4,4,4).

Edited September 13, 2015 by DrWho198

[Wickeycolumbus]

That's true, but you're never going to be able to get the correct value for the average without using floating point or something. Keeping track of the remainders would help a bit.

[Andromeda Stardust]

Best Electronics sells paddle pot replacements. I bought a pair but my paddles are still good condition. Get some electronics contact cleaner like the kind Radio Shack sells. Open the paddle and spray inside the opening of the pot where the leads come out. Vigorously scrape the contacts back and forth across the entire length of travel several times. This should remove any dust and debris inside the paddle. It may also help to spray inside with a compressed air can to remove any dust buildup. hopefully this helps...

[tep392]

If you paddle routine outputs a value of 0-15, that's pretty course and I'm surprised you are able to see the jitter. Unless you using a very small angular range. Or maybe it's just when you are near a transition between values. If you are starting with higher resolution paddle data before down resing to 0-15, you should eliminate the jitter on the raw data. You could try adding hysteresis to mask the jitter without sacrificing response. This is what Bryan did with Castle Crisis.

http://atariage.com/forums/topic/232511-programming-to-tolerate-paddle-jitter/?do=findComment&comment=3127529

[DanOliver]

Trying to compensate for failing hardware has the drawback of working today and not tomorrow. Also unlikely other dying paddles would act the same.

[DrWho198]

I hear you guys.

I wanted to use this routine in a menu for my multicard. the menu reads the value of the cap only once in very 9 scanlines. Thats why I only have a range on 0 to 15.

What I'm doing here is actualy a bit stupid since the games themselves(after menu selection) are hard to play themselves with all this jitter. And obviously I'm not going to patch every game to compensate this.

turns out that the set of paddles that I was testing with was my worst set. I'll try to clean another set and maybe that one has a better result.

 

buying replacements is a sad story. Like many people will confirm, shipping to europe is a nightmare. A lot of US or Canadese shops won't even ship here, and when they do the cost is too high. Not to mention the fact that you might have to pay taxes on import.

I'll fix it at the hardware level, but for now it is an interesting thing to look at.

 

@tep392: The jitter is not bad... it terrible... even after cleaning the pot multiple times its a problem to hit a ball with the paddle (in the game ofcourse ).

 

 

oh, as a side note/question... any quick way to check if it's a joystick or paddle which is connected?

Right now when I connect a joystick, pressing to the right will trigger a paddle button press. Its not bad, but not perfect either.

Edited September 13, 2015 by DrWho198

[RevEng]

I agree with the general sentiment here that this shouldn't be necessary, but I think it's an interesting exercise anyway.

 

I think a median filter with 3 samples might be a better choice to remove paddle noise than an averaging filter. If the noise lasts only a single frame, averaging will dampen it, but median filtering will remove it entirely. If the noise lasts longer than a frame, the situation is pretty much hopeless anyway.

[DanOliver]

I'll fix it at the hardware level, but for now it is an interesting thing to look at.

 

 

I agree with the general sentiment here that this shouldn't be necessary, but I think it's an interesting exercise anyway.

 

These little problems are what programming so much fun imo. And doing it on the 2600 makes it even more fun.

 

Not exactly directly related to this problem but in general I rarely look to standard algorithms. In this case I would look at the data coming in, move the paddle and see how it affects data, probably displaying the data on the screen. I'd be looking for patterns. In this case I'd also be looking to see if the failing hardware is generating stable values even if wrong. If the hardware is generating pretty much random numbers that would be the end of that.

 

For a solution I still consider table lookup to be my first choice. Even on today's computers, almost unlimited bandwidth and memory I still find table lookup to be a great solution.

 

Try, tweak, test, repeat. My first step is to try whatever algorithms might work without concern for speed or memory just to see if it works. Only then work on speed and memory usage if needed.

[DrWho198]

I think RevEng might have the right idea. A median would indeed create a more accurate value. In this case with the numbers so close together I'm not sure if it would make much of a difference. But in general this might be the way to go.

[Nukey Shay]

oh, as a side note/question... any quick way to check if it's a joystick or paddle which is connected?

I don't believe so. But you could use the method present in Astroblast: always check paddle status...and on game restart if the value is out of what the range should be if it's connected, assume that the player is using a stick (setting a flag to indicate which controller routine to be used during the game).

 

 

Right now when I connect a joystick, pressing to the right will trigger a paddle button press. Its not bad, but not perfect either.

This is normal. The 4 Paddle triggers are hardwired to right and left in both nybbles of SWCHA. This is why some games feature odd glitches if a pair of paddle triggers are held down - returning an invalid controller direction if using a lookup table.