Paddle reading precision

[Windless]

Hi,

 

  I don't have any hardware to test, so maybe some has the answer : if you do a calibration at start of the rom (asking the player to turn the button full left then full right), how many different positions can you reliably distinguish with you code ?

 

thank you,

w.

[+Stephen]

I'm not sure how similar the 2600 is to the 8-bit computers regarding reading the paddles, but with those, we can get values from 0 to 228.

[vdub_bobby]

Based on this comment in an earlier thread - 

Quote

On the VCS it's a completely different story. The programmer actually has to write code to charge a capacitor, wait a bit, then read the register that represents the capacitor's state to see if it has discharged yet. This waiting-and-reading sequence has to be repeated dozens or hundreds of times in game code just to get one read of the paddle's position. The time it takes to discharge the capacitor determines where the paddle knob is positioned. The thing is, it takes an achingly long time to discharge the cap, about two full video frames' worth. This amounts to 1/30 of a second, which doesn't sound like much, but in game code 1/30-second might as well be forever. If the programmer can afford the code-execution time to completely discharge the cap, the game will make use of the whole paddle.

Emphasis added.

 

As it says, the paddle doesn't return a "value" - the programmer checks the paddle and when the cap is discharged the code assigns a value based on how long since the cap was charged.  If it really takes two frames to completely discharge (?!), you could read the paddle once a line and get a value from 0 to 500.  Or you could read it twice per scanline and get a value from 0 to 1000.  Or you could check once per frame and get a value between 0 and 2    It depends!

 

In practice, I believe most games that use the paddle charge it once every frame and then read it every line during the kernel, for an effective range of something like 0-200.

 

 

 

 

[Windless]

This is why my question was "how many different positions can you reliably distinguish". I will add two informations :

- in at max 2VBL (1/30s)

- the values must be linearly distributed.

 

So imagine you use the paddle to enter a number and you want the numbers equaly spread around the rotating button, how many different numbers can you enter if you want to read at least one every 1/30s ?

Edited November 11, 2023 by Windless

[+splendidnut]

2 hours ago, Windless said:

So imagine you use the paddle to enter a number and you want the numbers equaly spread around the rotating button, how many different numbers can you enter if you want to read at least one every 1/30s ?

Simple answer: One.  The paddles are designed to provide a positioning value once per frame. 

 

The hardware is a one-shot timer and the value read from the hardware is a single bit.  The programmer controls when that one-shot timer is reset, and can be read again.  The paddles control the length of the timer, with the 'time-to-fire' spanning a full video frame or two.  So, within that time frame, you will only be able to read one value.

 

What problem are you trying to solve here?

[Windless]

49 minutes ago, splendidnut said:

What problem are you trying to solve here?

I am trying to find a fast way to enter large numbers. I currently have a solution that works very well using a custom keyboard, but this means players would have to build a custom keyboard. So I'm thinking of using the paddle as a dial.

Since I don't have my 2600 here and can code only on emulator, I'm wondering if I can realisticly use the paddle to enter a number between 0 and 999, or 0 and 255, or if the precision would be too low and I would have to enter 3 digits one after the other. The kernel of the game itself doesn't do much, so I can probably read SWCHA twice during a line, but :

- I don't know how many lines it take at most for the capacitor to discharge (if it takes the full VBL, I theorically can distinguish 524 values, but if it discharges in only 10 lines, that would be only 20 possibilities with two reads per line)

- I don't know how precise it is (if for a given position of the button the signal on SWCHA changes at a random line between 100 and 110, or if it would require too much agility and lubrification to select a position between 200 different ones, the quantity of distinguishable enterable values would be lower than the quantity of distinguishable durations)

Edited November 11, 2023 by Windless

[+grafixbmp]

Sounds like this is where a driving controller would be the better choice for accuracy and its free rotating. Though they are fewer out there. Only came with indy 500

[+SpiceWare]

2 hours ago, Windless said:

I am trying to find a fast way to enter large numbers. I currently have a solution that works very well using a custom keyboard, but this means players would have to build a custom keyboard.

 

Why custom?  Atari already has an official controller that is literally a numeric keypad:

• Atari Keypad

There's also these, which while styled differently than the Keypad are read exactly the same way in code:

• Kid's Controller
• Video Touchpad

 

I have an old demo that shows how to read the keypad plugged into the right controller port, which leaves the left port free for a different controller.

[Windless]

20 minutes ago, SpiceWare said:

Why custom?

I was making the asumption that not many people owned a numeric pad ^^.

BTW, I don't think these keypads really are a good option for a fast paced games. I made my custom keyboard compatible with them, but it uses 10 mechanical keyboard switches and the keys are in line, you just need to move your fingers one unit for 5 and 6.