POT Inputs Unstable with Atari Paddles Connected?

[modeler]

While trying to pin down the root cause for Issue #31, I switched the SIDKick Pico over to my C64C that does not have the issue with the 'noise' on POTX that causes the second fire button to register as down all the time. I dug out my Atari paddles to see how the analogue inputs were registering, and I found they're unstable regardless of the mode I choose in the configuration program:

https://www.youtube.com/watch?v=V29rMY_XtLM

These paddles appear to work fine when using an original SID. So I guess my question is: can anyone confirm if the results observed in the above video are expected? I am starting to think I messed something up when I built the board!

Thanks.

EDIT: I found my NEOS mouse and have tested that, works perfectly even with Pot X/Y = raw. Paddles are constantly jittering in Arkanoid regardless of the Pot X/Y mode though.

[frntc]

Hard to diagnose from here. A SID/SKpico only waits for the voltage at the POTX/Y to reach a certain threshold, nothing fancy here, but something seems to misbehave. For paddles, their resistors charge a capacitor (that's different from a mouse), maybe something's weird there. Do you have an oscilloscope?

[modeler]

I don't have an oscilloscope I'm afraid, I will so if I can borrow one. I'd really like to understand what's going on here.

Interestingly, the Commodore 568220 diagnostics cartridge also passes the control port test with my test harness attached. The User Port interface seems to generate some activity on the pot. inputs which the test program reads (not sure exactly what, will look into that or maybe just ask Sven Petersen), so the issue with my setup seems to be specific to paddles.

[modeler]

Ruled out my Kung Fu Flash cartridge and modern PSU as potentially causes. I've had my logic probe on Pin 24 of the SID socket and can see the 'flapping' when turned all the way clockwise (minimal resistance):

https://youtu.be/1xJ5tk5e73g

It doesn't flap like this when the paddle is not connected. Nor does it occur when probing an original SID or even an empty socket. I am thinking the problem is specific to Atari paddles, if this is anything to go by:

http://www.thealmightyguru.com/Wiki/index.php?title=Atari_2600_Paddle_Controller:

When Commodore International first designed their own paddle controllers, they made them nearly identical to the Atari Paddle Controller in shape, but their potentiometer used half the resistance.

I don't have a Commodore paddle to test, so I'll try to pick one up.

[modeler]

As I understand it, an Atari Paddle is essentially a 1MΩ variable resistor in between pin 7 (+5V) and pin 9 of the joystick port. I had some generic pots in my draw so made myself a 'paddle':

Same result with the SKP, in GCT and with the logic probe, so I can rule out some weirdness with these paddles themselves.

[frntc]

Yes, all these paddles are variable resistors :-) Not sure if the logic analyzer tells us much (at least not for me). The signal does change, as the capacitor is charged every 512 cycles. If it would be my C64, and if I had no oscilloscope, I'd speculatively check the SID caps (not for audio, for paddles!) and the 4066 for the control ports.

[modeler]

This seems to be an issue with the latest firmware v014. I tried out some of the earlier firmwares to see if this made any difference, and it really did. With SKpico_v013/SKpico_PWM.uf2, the jitter seemed much reduced, although I wasn't able to launch the config. tool with SYS 54301 / SYS 54333.

I tried SKpico_v012/SKpico_PWM.uf2 with Pot X/Y = smooth paddle and the difference is night and day, no jitter at all. Really not sure how I managed to hit this issue, especially if you can't recreate it.

[frntc]

Hm, interesting, no idea what should have changed back then :-) Since I'm working on a revision, write me mail, maybe I can send you some firmware versions for testing.

[modeler]

Of course, I have one of every C64 board type and would be more than happy to help with testing.

I'm not sure where I can find you e-mail address though, apologies if I'm being a bit thick.

[frntc]

... in the source code :)

[linker3000]

Confirming, C64 pots are 500K, compared to Atari 1M.

If I can help with testing, I have two shortboard C64s. One is all original chips and one has a SIDKick Pico + I have a SwinSID Nano.

I also have a full electronics lab with an oscilloscope, logic probes and analysers etc.

I don't have any paddles, but like @modeler I can probably find some suitable variable resistors.

[modeler]

Thank you @linker3000, there's no jitter unless paddles are connected except for my original board as seen in #31. Both are the same issue it seems, which only appears to affect firmware v0.14. I'm happily using v0.12 and everything works perfectly.

I simply don't know if anyone who tries v0.14 with paddles will hit this problem right away. Would be nice if at least one other user could confirm that the issue exists, but there's no rush. I just wish I had the coding skills to debug it rather than be the guy sat here posting this, that and the other isn't working.

[modeler]

This issue is consistent for me on all four different C64 board revisions I have tested so far, but I'm yet to see anyone else report the same.

Could I have used the wrong parts in my build? The resistors and caps are clearly correct, these are the other parts I ordered:

Diode:
https://www.digikey.co.uk/en/products/detail/taiwan-semiconductor-corporation/TS4148-RBG/15926409

Bus switches:
https://www.digikey.co.uk/en/products/detail/texas-instruments/SN74CBTD3861PWR/378017

The Picos themselves are the official ones from here:
https://thepihut.com/products/raspberry-pi-pico

[linker3000]

I just wish I had the coding skills to debug it rather than be the guy sat here posting this, that and the other isn't working.

I know the feeling! I'm an occasional coder and it takes me a while to get back up to speed every time I look into something.

I'll dig out some 1M and 470K-500K resistor or pots and have a probe around with V0.14 and V0.12. I have a couple of SidKICKs made up using clone RP2040 boards.

[MickGyver]

@frntc I can also do some testing, I have an oscilloscope etc. I have the same issue on all three sidkick picos I have built and thought I did something wrong when building these.

[frntc]

Thanks for offering help. I think possible experiments would convolute this thread too much and we should somehow take this offline and report the findings back (maybe not optimal, but if you're volunteering to participate, drop me a mail, the address is in the source code). The only (potential, need to reconstruct) difference in the code between 0.12 and 0.14 is that 0.12 sets the directions of more GPIOs than necessary (i.e. 0.14 does what it needs but maybe something weird is going on there). In any case, I need a few days to find time for this.

@modeler parts are ok, the diode is irrelevant here.

[modeler]

The only (potential, need to reconstruct) difference in the code between 0.12 and 0.14 is that 0.12 sets the directions of more GPIOs than necessary (i.e. 0.14 does what it needs but maybe something weird is going on there). In any case, I need a few days to find time for this.

No rush, please take all the time you need. I have learned that the RP2040 clones are fairly popular, is there a chance these might behave differently? I have a couple on order so I can see for myself.

I can also do some testing, I have an oscilloscope etc. I have the same issue on all three sidkick picos I have built and thought I did something wrong when building these.

@MickGyver thank you. I'm a fan of your work also, I wired up my 'paddle' pictured above using the DB-9 attached to a breadboard that serves as my DaemonBite USB adaptor.

[linker3000]

Ready to paddle with a 470K variable resistor. Tested on a SIDKick Pico and real SID (8580) and the static values returned in a BASIC program are very close. I'll hold off any more work or commentary - ready for 'offline' testing instructions.

Edit: Test prog here:

https://www.c64-wiki.com/wiki/Paddle

[frntc]

We had some extensive tests of the paddle handling and it should now be stable with the new firmware. For this reason I'll close the issue here (in case problems persist, please read the troubleshooting section in the readme, and if that doesn't help, open a new issue)