Programming to tolerate paddle jitter?

[erichenneke]

Working on a program using the paddle control. The idea was for it to have access to all 0-288 positions for very quick response.

 

Everything was fine working in emulation, but when I tested it on the A8 hardware it is terrible! The actual A8 hardware paddle never seems to actually stay still/static. The values are constantly changing even when the control isn't being touched. As a result, the player on the screen is unacceptably jittery, jumping around constantly.

 

I even tried two other paddle controllers thinking it had gone bad over the years, but all three paddle controllers do the same thing.

 

Has anyone run into this? I am thinking there must be a simple way to handle this in the program but my attempts so far have only helped a little but not eliminated the jitter.

 

Thanks!

-Eric

[kenjennings]

Real pots have that jitter. Since the paddle is an analog reduced to a digital value there are potentially a lot of places where the paddle is on the edge of two values.

 

How much jitter? +/- 1 or 2 is typical.

 

Average the value of the paddle across a couple frames (or more frames depending on the need for speedy movement) and that should reduce the shaking.

[Irgendwer]

Working on a program using the paddle control. The idea was for it to have access to all 0-288 positions for very quick response.

...

Has anyone run into this? I am thinking there must be a simple way to handle this in the program but my attempts so far have only helped a little but not eliminated the jitter.

...

 

Range is 0-228.

Jitter is typical and depending on device more or less worse (old pots tend to jitter terrible, remember that scratching sound when trying to adjust the volume of an old radio).

In case of 'fresh' devices averaging samples helps to get the desired result:

 

http://atariage.com/forums/topic/169554-untangle-minimal/?do=findComment&comment=2100486

[Bryan]

With my old paddles, I sometimes have to turn them hundreds of times to get them to operate well again. The only other solution is to upgrade them with high-quality pots.

 

For Castle Crisis, I implemented a little bit of jitter control. I keep track of which direction the paddle is currently moving, and don't allow it to reverse unless the step is large enough. This means jitter can advance the position a little, but not reverse it so there's no twitching.

 

 

;**********************************************************
;**** Read Paddles  ***************************************
;**********************************************************
 
pots
 
#IFDEF debug
lda #$58 ;Light Purple
sta COLBK
#ENDIF
 
;Update the Paddle Values
ldx #$03 ;Read 4 Pots
 
potloop
lda POT0,x
 
;Adjust for a Paddle offset value (adjust where the active
;portion of the paddle is).
 
sec
sbc #POFFSET ;Subtract an offset value (26 or less)
 
;Did this generate a less-than-zero result?
 
bcs potskip1 ;No, no adjustment needed
lda #00 ;Yes, <0 becomes 0
bcc potskip2 ;skip the next test
 
;Did this generate a greater than 160 result?
 
potskip1
cmp #161 ;In range?
bcc potskip2 ;Yes, skip down
lda #160 ;No, adjust to 160 
clc ;We got here because Carry was set
 
potskip2 
sta temp0 ;Save the final value
 
;Take the new value and modify it to +1 if the momentum is forward
 
adc paddir0,x ;Get "resistance" direction (0 or 1)
 
;Now subtract the old value
 
sec
sbc pad0,x ;Subtact the old value
 
;Carry is clear if the old value was bigger (we're going backwards)
;Move the result to Y so we can use A
 
tay ;Copy of the result in Y
lda #0 ;Clear A
rol a ;A = 1 if new value is larger, 0 if not (Clears Carry!)
 
;A contains the new "paddir"
;Now see if the change is outside of the filter zone
 
cpy #2 ;Subtraction result greater than 3?
bcc nextpot ;No, ignore this change
 
;Okay, this change is valid. Save A as "paddir" and
;save the new POT value
 
sta paddir0,x
 
lda temp0
sta pad0,x
lda #$50
sec
sbc temp0
sta shldpos,x
 
nextpot
dex
bpl potloop ;Do all 4
sta POTGO ;Restart Pots!
 
 
#IFDEF debug
lda #$00 ;Black
sta COLBK
#ENDIF
 
 
rts
 

[erichenneke]

thanks ! I will definitely try both of the approaches. averaging the last few cycles and also limiting the single step movement to "forward". Working on some other logic in the program right now, so will get back to the paddle control logic again next.

[Bryan]

My gut feeling is that averaging will cause the motion to feel sluggish unless the project doesn't need fast response.

[RevEng]

Filtering jitter will absolutely impact response. The beginning of a quick turn is indistinguishable from the start of a jitter.

 

If you're going to filter jitter, using an averaging technique will leave the jitter "noise" in the signal, but reduce+smear it.

 

Using median filtering (on the current and last 2 samples) will do a much better job of removing the noise, provided the jitter event lasts for just 1 sample period. If a jitter event lasts for more than 1 sample period, I fear no filtering method will remove it without destroying the paddle response. (though your method will mask it for smaller jitters, or potentially impact subtle turns.)

 

Plan B: clean the paddle contacts, and anticipate others will do the same with jittery pots.

[Bryan]

Working paddles will either be stable or will toggle between two adjacent values. Anything worse than that probably means dirty pots.

[+JAC!]

>For Castle Crisis, I implemented a little bit of jitter control. I keep track of which direction the paddle is currently moving, and don't allow it to reverse unless the step is large enough.

That is a very good idea. And I can confirm that the paddle control in Castle Crisis is excellent.

[+CyranoJ]

Can't you just AND off the low few bits?

[+David_P]

Can't you just AND off the low few bits?

Drop one bit and your potential resolution is halved; drop two bits and your potential resolution is quartered.

[+CyranoJ]

Drop one bit and your potential resolution is halved; drop two bits and your potential resolution is quartered.

 

And so is your jitter.

[RevEng]

We have a total of 228 positions. Dividing by 2 will give you 114 positions on the screen, won't block jitter that's larger than a single position, and might look a little rough if the full horizontal range of the screen is to be covered by the paddle movement. Dividing by 4 and providing only 57 positions will be a non-starter for most games.

[Bryan]

Anding off bits won't help you at all if the value is twitching between $2F and $30.

[+CyranoJ]

Anding off bits won't help you at all if the value is twitching between $2F and $30.

 

Good point Oh well, was a quick, dirty solution if it worked.

[Irgendwer]

My gut feeling is that averaging will cause the motion to feel sluggish unless the project doesn't need fast response.

 

 

...doesn't seem so...