Paddlescope

[Mike]

Hi, y'all!

To shed some light into the discussion about the Paddle jitter, here's Paddlescope (download).

It displays the POTY paddle signal with a 208x256 pixel screen mode. Start with SYS 8192, stop with STOP/RESTORE. With POKE8371,8 you can select POTX for display, POKE8371,9 switches back to POTY.

Tokra was so kind to provide these two measurements (9008 for POTX, 9009 for POTY) on YouTube.

You see a periodic, noisy signal, which is *not* jittery because of a generally bad power supply of VIC-I and/or the paddles! Rather, one can see a direct influence by the video signal itself (especially the black signal around the vertical retrace), which indicates a coupling between the video amplifier and the supply voltage of the VIC-I chip. That in turn changes the comparator threshold, and this ultimately changes the paddle readout with analog paddles.

The program uses a timer NMI to read the paddle register every 512 cycles.

With PAL, a frame needs 71x312 cycles to be displayed. On screen, this gives a period of ~43.3 pixels. Five periods nearly fit, ~216 pixels compared to 208 of the display mode, which is why the "peaks" slowly roll to the right.

The program also works with NTSC, even if the display is cropped around all sides. Here, the same calculation gives (with 65x261 cycles for a frame) a period of 33.1 pixels. Six periods correspond to 199 pixels, so any signal correlated to the video signal will roll slowly to the left.

The discussion is open!


Edit: for reference, here are older threads that discuss the paddle jitter: 'Paddle Games' and 'A Plea For A Solution To The Paddle Issue'.

[tokra]

I would specifically like to see how the Micromys V5 that groepaz mentioned earlier looks on this.

[groepaz]

shows a straight line

nice little program.... would you post the source too? i'd like to throw it into the VICE testprograms repo...

[Mike]

shows a straight line

At least a glimmer of hope.

I'm taking a thorough look at all the decoupling capacitors in the RF box in the meanwhile ... whether it's useful to replace them by MIL-STD types.

nice little program.... would you post the source too? i'd like to throw it into the VICE testprograms repo...

If you don't mind the inline assembler of BBC BASIC, here it is:

Code: Select all

REM>Paddlescope
:
REM ** Realtime sample & display of POTX or POTY on VIC-20,
REM    written 2018-01-05 by Michael Kircher
REM
REM    - sample rate 512 us (^= paddle period), done in NMI,
REM    - display height 256 pixels, *full* resolution,
REM    - display width 208 pixels, equiv. ~= 100 ms,
REM      i.e. ~5 x 20 ms in PAL, ~6 x 16,67 ms in NTSC.
REM
REM    Note: NTSC machines only show a cropped display.
:
DIM code 1024
:
zp_X    = &03
zp_X2   = &04
zp_scrn = &FB
zp_char = &FD
:
FOR pass=4 TO 7 STEP 3
P%=&2000:O%=code
[OPT pass
.Main
 JSR &E518
 LDX #6
.Main_00
 CLC
 LDA &EDE4 - 1,X
 ADC offsets - 1,X
 STA &9000 - 1,X
 DEX
 BNE Main_00:STX zp_X2
 STX &17F8:STX &17F9:STX &17FA:STX &17FB
 STX &17FC:STX &17FD:STX &17FE:STX &17FF
 LDA #&06
.Main_01
 STA &9400,X:STA &9500,X:STA &9600,X:STA &9700,X
 INX:BNE Main_01
 SEI
 LDA #&FF:STA &9122
 LDA #&00:STA &9123
 LDA #&F7:STA &9120
 LDA #&7F:STA &911E:STA &911D:STA &912E:STA &912D
 LDA #&40:STA &911B
 LDX #NMI MOD 256
 LDY #NMI DIV 256
 STX &0318
 STY &0319
 LDX #(512-2) MOD 256
 LDY #(512-2) DIV 256
 STX &9114
 STY &9115
 LDA #&C2:STA &911E
.Main_02
 LDX #0:STX zp_X
.Main_03
 LDX #8
.Main_04
 CPX zp_X2:BNE Main_04
.Main_05
 LDA buffer1-1,X:STA buffer2-1,X:DEX:BNE Main_05
 STX zp_X2
 JSR ClrScrn:JSR ClrChar:JSR Plot
 LDX zp_X:INX:CPX #26:BEQ Main_02
 STX zp_X:BNE Main_03

.NMI
 PHA
 TXA
 PHA
 BIT &911D
 BPL NMI_00
 BVC NMI_01
 LDX zp_X2
 CPX #8
 BEQ NMI_00
 LDA &9009
 EOR #&FF
 STA buffer1,X
 INX
 STX zp_X2
.NMI_00
 PLA
 TAX
 PLA
 BIT &9114
 BIT &9111
 RTI
.NMI_01
 BIT &9111
 LDA &9121
 AND #&01
 BNE NMI_00
 LDA #&7F
 STA &911E
 STA &911D
 LDA #&FE
 STA &9114
 LDA #&FF
 STA &9115
 JMP &FED2

.ClrScrn
 LDA #&FF:LDX zp_X
 STA &1800+ 0*26,X:STA &1800+ 1*26,X:STA &1800+ 2*26,X:STA &1800+ 3*26,X
 STA &1800+ 4*26,X:STA &1800+ 5*26,X:STA &1800+ 6*26,X:STA &1800+ 7*26,X
 STA &1800+ 8*26,X:STA &1800+ 9*26,X:STA &1800+10*26,X:STA &1800+11*26,X
 STA &1800+12*26,X:STA &1800+13*26,X:STA &1800+14*26,X:STA &1800+15*26,X
 STA &1800+16*26,X:STA &1800+17*26,X:STA &1800+18*26,X:STA &1800+19*26,X
 STA &1800+20*26,X:STA &1800+21*26,X:STA &1800+22*26,X:STA &1800+23*26,X
 STA &1800+24*26,X:STA &1800+25*26,X:STA &1800+26*26,X:STA &1800+27*26,X
 STA &1800+28*26,X:STA &1800+29*26,X:STA &1800+30*26,X:STA &1800+31*26,X
 RTS

.ClrChar
 LDA #&02:STA zp_char+1
 LDX zp_X:LDA char_base,X
 ASL A:ROL zp_char+1
 ASL A:ROL zp_char+1
 ASL A:ROL zp_char+1
 STA zp_char
 LDA #0:TAY:LDX #8
.ClrChar_00
 STA (zp_char),Y:INY:STA (zp_char),Y:INY:STA (zp_char),Y:INY:STA (zp_char),Y:INY
 STA (zp_char),Y:INY:STA (zp_char),Y:INY:STA (zp_char),Y:INY:STA (zp_char),Y:INY
 DEX:BNE ClrChar_00
 RTS

.Plot
 LDX #0
.Plot_00
 LDA buffer2,X:LSR A:LSR A:LSR A:TAY
 LDA line_low,Y :STA zp_scrn
 LDA line_high,Y:STA zp_scrn+1
 LDA #&02:STA zp_char+1
 LDY zp_X:LDA (zp_scrn),Y:CMP #&FF:BNE Plot_01
 TXA:ORA char_base,Y:STA (zp_scrn),Y
.Plot_01
 ASL A:ROL zp_char+1
 ASL A:ROL zp_char+1
 ASL A:ROL zp_char+1
 STA zp_char
 LDA buffer2,X:AND #&07:TAY
 LDA (zp_char),Y:ORA &8268,X:STA (zp_char),Y
 INX:CPX #8:BNE Plot_00
 RTS

.line_low
 EQUB (&1800+ 0*26) MOD 256:EQUB (&1800+ 1*26) MOD 256:EQUB (&1800+ 2*26) MOD 256:EQUB (&1800+ 3*26) MOD 256
 EQUB (&1800+ 4*26) MOD 256:EQUB (&1800+ 5*26) MOD 256:EQUB (&1800+ 6*26) MOD 256:EQUB (&1800+ 7*26) MOD 256
 EQUB (&1800+ 8*26) MOD 256:EQUB (&1800+ 9*26) MOD 256:EQUB (&1800+10*26) MOD 256:EQUB (&1800+11*26) MOD 256
 EQUB (&1800+12*26) MOD 256:EQUB (&1800+13*26) MOD 256:EQUB (&1800+14*26) MOD 256:EQUB (&1800+15*26) MOD 256
 EQUB (&1800+16*26) MOD 256:EQUB (&1800+17*26) MOD 256:EQUB (&1800+18*26) MOD 256:EQUB (&1800+19*26) MOD 256
 EQUB (&1800+20*26) MOD 256:EQUB (&1800+21*26) MOD 256:EQUB (&1800+22*26) MOD 256:EQUB (&1800+23*26) MOD 256
 EQUB (&1800+24*26) MOD 256:EQUB (&1800+25*26) MOD 256:EQUB (&1800+26*26) MOD 256:EQUB (&1800+27*26) MOD 256
 EQUB (&1800+28*26) MOD 256:EQUB (&1800+29*26) MOD 256:EQUB (&1800+30*26) MOD 256:EQUB (&1800+31*26) MOD 256

.line_high
 EQUB (&1800+ 0*26) DIV 256:EQUB (&1800+ 1*26) DIV 256:EQUB (&1800+ 2*26) DIV 256:EQUB (&1800+ 3*26) DIV 256
 EQUB (&1800+ 4*26) DIV 256:EQUB (&1800+ 5*26) DIV 256:EQUB (&1800+ 6*26) DIV 256:EQUB (&1800+ 7*26) DIV 256
 EQUB (&1800+ 8*26) DIV 256:EQUB (&1800+ 9*26) DIV 256:EQUB (&1800+10*26) DIV 256:EQUB (&1800+11*26) DIV 256
 EQUB (&1800+12*26) DIV 256:EQUB (&1800+13*26) DIV 256:EQUB (&1800+14*26) DIV 256:EQUB (&1800+15*26) DIV 256
 EQUB (&1800+16*26) DIV 256:EQUB (&1800+17*26) DIV 256:EQUB (&1800+18*26) DIV 256:EQUB (&1800+19*26) DIV 256
 EQUB (&1800+20*26) DIV 256:EQUB (&1800+21*26) DIV 256:EQUB (&1800+22*26) DIV 256:EQUB (&1800+23*26) DIV 256
 EQUB (&1800+24*26) DIV 256:EQUB (&1800+25*26) DIV 256:EQUB (&1800+26*26) DIV 256:EQUB (&1800+27*26) DIV 256
 EQUB (&1800+28*26) DIV 256:EQUB (&1800+29*26) DIV 256:EQUB (&1800+30*26) DIV 256:EQUB (&1800+31*26) DIV 256

.char_base
 EQUB  0*8:EQUB  1*8:EQUB  2*8:EQUB  3*8:EQUB  4*8
 EQUB  5*8:EQUB  6*8:EQUB  7*8:EQUB  8*8:EQUB  9*8
 EQUB 10*8:EQUB 11*8:EQUB 12*8:EQUB 13*8:EQUB 14*8
 EQUB 15*8:EQUB 16*8:EQUB 17*8:EQUB 18*8:EQUB 19*8
 EQUB 20*8:EQUB 21*8:EQUB 22*8:EQUB 23*8:EQUB 24*8
 EQUB 25*8

.buffer1
 EQUB 0:EQUB 0:EQUB 0:EQUB 0:EQUB 0:EQUB 0:EQUB 0:EQUB 0

.buffer2
 EQUB 0:EQUB 0:EQUB 0:EQUB 0:EQUB 0:EQUB 0:EQUB 0:EQUB 0

.offsets
 EQUB &FC:EQUB &EE:EQUB &04:EQUB &12:EQUB &00:EQUB &2C
]
NEXT

[groepaz]

jesus =) i have converted it to acme, see https://sourceforge.net/p/vice-emu/code/34291/

[Mike]

Thanks! (also for adding the +8K/BLK1 reminder in the readme)

[groepaz]

urks. now the VIC died on me while testing

its defective in an interesting way though: when POT1 is turned to almost "0", the video output will be garbled, as if memory fetches dont work properly anymore. that kinda supports the theory that paddles are somehow related to the video output

[Mike]

Today I took the opportunity to run Paddlescope on my own VIC-20.

Actually, the jitter is effectively non-existent there with POTX, I just saw some noise with an amplitude of +/- 3 units.

Unfortunately, the chip does show the coupling of the video signal with POTY (even if it's not that pronounced as with tokra's VIC-20), and that's bad news. I had the hope that the exchange of the external electrolytic stabilizing capacitors - for VIC-I and for the video amplifier circuit - would improve upon this. But since POTX doesn't show the jitter (and the chance that two errors cancel out each other is marginal) I came to the conclusion that the jitter indeed is generated within VIC-I, and that mainly for POTY. Hopefully, that hypothesis will be affirmed when Lance gets to analyse that part of the chip.

Three points to note:

- POTX doesn't nearly suffer as much as POTY from the jitter. When only one paddle is required, POTX should be given the favour,

- The jitter of POTY can be minimized by not reading it out at arbitrary times. Rather, the readout should be done in a screen range, where the video signal itself is not overly modulated. Best candidate seems to be during the VBLANK time.

- These considerations mainly apply to analog paddles. The digital replacements (Micromys, et alii) eliminate the impact of the comparator threshold, and thus they are not affected by the Paddle jitter.

[tokra]

Interesting! Do you have an old 2-prong-VIC-20 or a newer CR-model with the DIN-plug for power?

The digital replacements (Micromys, et alii) eliminate the impact of the comparator threshold, and thus they are not affected by the Paddle jitter.

Looking forward to this or even better a small in-between-device that just takes the analog-paddle and makes its output jitter-free for the VIC. Any takers? Take my money

[Mike]

Do you have an old 2-prong-VIC-20 or a newer CR-model with the DIN-plug for power?

It's the CR variant.

[tokra]

[...] the readout should be done in a screen range, where the video signal itself is not overly modulated. Best candidate seems to be during the VBLANK time.

Seeing how badly my VIC-20 has paddle-jitter I tried a similar approach recently. I used the stable-raster-routine to set up a raster-interrupt to read out the paddle-register at always the same time during each frame. This minimized the strong peaks that lead to the jittery effect already. My next step would be to try and apply this technique to a known game like "Clowns" to see if this may make it more playable.

now the VIC died on me while testing

Uhoh, hopefully just a random quirk and nothing to do with the Micromys?

[Mike]

- The jitter of POTY can be minimized by not reading it out at arbitrary times. Rather, the readout should be done in a screen range, where the video signal itself is not overly modulated. Best candidate seems to be during the VBLANK time.

I thought about this a bit and set the "duty cycle" of the peaks in tokra's videos in relation to the VBLANK length.

Now the visible area of the PAL VIC-I chip spans 283 raster lines, with 312 rasters total for each frame. The VBLANK happens in the remaining 312-283 = 29 rasters. This corresponds to 9.3% of the total time, or, with the 43.3 pixel period within Paddlescope, a length of only(!) 4 pixels.

However, the peaks are more like 8 or 9 pixels wide.

That 8..9 pixel width much besser corresponds with the time VIC-I does video DMA: the screen mode of Paddlescope uses 256 of the 312 raster lines, i.e. there are 56 rasters without video DMA. This corresponds to 17.9% of the total time, and with the 43.3 pixel period you get a width of 8 pixels!

So, whatever disturbs the POTY input, it must have to do with the data being read by VIC-I in the display area. The part of VIC-I that controls the video DMA must lie in the near vicinity of the POTY comparator and/or is coupled by a parasitic capacitance to the chip interconnect between POTY bonding pad and POTY comparator.

I used the stable-raster-routine to set up a raster-interrupt to read out the paddle-register at always the same time during each frame. This minimized the strong peaks that lead to the jittery effect already.

That's a good hint that my hypothesis is not too far off.

Looking forward to this or even better a small in-between-device that just takes the analog-paddle and makes its output jitter-free for the VIC.

I have an idea how to do this with an external OpAmp circuit. It'll take me some days though to wrap up a schematic.

[groepaz]

Uhoh, hopefully just a random quirk and nothing to do with the Micromys?

the micromys shouldnt be able to kill it... its just old ICs i think, and also the vic20 i have here is generally a bit quirky. no idea what happened there

[tokra]

Got my Micromys V5 today, but sadly Paddle-mode seems completely broken (at least on my device). It just gives 3-4 values (255, 11 and something like 170). It does not even work on my C128 (tried with Arkanoid). All the other features seem to work (tried some mouse-based programs, even NEOS-mouse and Amiga-mouse-modes). Hopefully I just got a bad device and this is not a (late) manufacturing error...

[tokra]

Got my Micromys V5 back from IComp today, and now Paddle-mode works like it should. I've tried Paddlescope and only get about 1 pixel jitter in the upper 30 lines or so, below that the line is rock steady. Really fun now to play Clowns and other Paddle-games without the jitter