Kernel Trak-Ball vs. Paddle polling

[Thomas Jentzsch]

After having done some successful Trak-Ball hacks lately, I wondered if adding paddle support might be possible too.

 

Both have (do they?) to be polled during the kernel, but I found that the Trak-Ball polling is surprisingly tolerant to irregular timing. E.g. if you poll every 8th scanline, no one will notice, if you skip some of those polls. And it doesn't matter where you skip them. So you can poll in 8,16,32,40 and then in 8,24,32,40. The intervals do not even have to be identical. A poll e.g. in 5, 14, 31 and 39 would work too. And since my hacks only poll during the main kernel, skipping a big number of scanlines is still not noticeable. I haven't tested this, but probably polling outside the kernel a number of times with not too large gaps between the polls would somehow work too.

 

You do not have that flexibility for paddle polling. There the timing has to be very strict. And the kernel is the only part of the code, where you have such a timing over a longer period.

 

I think most of the Trak-Ball flexibility results from relative positioning based on the previous position, where in case of a paddle, we start from scratch with each frame. So as of now, it seems that adding paddle support to an exiting game is much more complicated than adding Trak-Ball support. But maybe some of us can come up with some new ideas? E.g. can we do relative positioning with a paddle?

 

Awaiting your input...

[Schizophretard]

Is there a difference with driving controllers compared to paddles?

[Thomas Jentzsch]

Yes. Driving Controllers work very much like a Trak-Ball, but only in one dimension and with a much lower resolution.

[potatohead]

Relative positioning on a paddle would, at first glance, seem sloppy. But, that's also a perception based on the expectation that paddles are absolute. (in the sense that a given paddle with a given routine will do very close to the same thing for a given paddle position)

 

One data point is mouse - paddle emulation. With some games, it works pretty well. "NIGHT DRIVER" is an example of one that can work. But, a ball and paddle game, or "KABOOM!" really doesn't work well. We seem to make a mental map of that paddle position space and depend on it for faster response times, or maybe just precision.

 

Another data point was long ago I put non-linear pots in my VCS paddles. Was a kid, and just didn't realize an audio pot was different. Anyway, those were odd, but consistent. The experience was not as enjoyable, but it does suggest a consistently non-linear paddle response could make sense for some use cases. Might be possible to get enough sampling values in an irregular way, and then correct them with a lookup table of some kind...

 

**Very interesting how usability on the trac ball isn't seriously impacted by irregularities in sampling. Who would have thought?

Edited November 3, 2015 by potatohead

[CDS Games]

By paddle support do you mean for things like driving games, Thomas?

[Thomas Jentzsch]

No, I meant current joystick games like Off the Wall, which would work better with an analog paddle (like Breakout).

[Omegamatrix]

I'm not sure if this is the same idea as yours Thomas, but while writing CAA I thought about shifting the dumping of VBLANK so that you don't have to poll so many scanlines. The information we need to determine is how fast (i.e. how many scanlines) the paddles can change from frame to frame. You know if a paddle has changed a lot the previous frame then the direction will continue that way until it de-accelerates. Likewise a paddle can not start at zero movement and go to maximum rate of change in a single frame.

 

 

You end up with a certain amount of scanlines that you have poll. This will be a smaller range then normal, and what you are adjusting is when you strobe VBLANK to dump the capacitors so that you can use the same small range of scanlines. Ideally you read the paddles at the beginning of the kernel, say the first 30 lines (for example).

 

You then strobe Vblank at a certain interval after the polling later in the kernel. Doing the writes to VBLANK in the kernel is the only practical way of timing the adjusting to strobing VBLANK. Ideally you could of divide the remaining kernel into small segments (say 10 lines or so) where you could choose to strobe VBLANK or not. You might also be able to dump at every segment until you reach the one you want like:

 

poll lines 42-72, figure adjustment needed

 

dump (stobe VBLANK to dump caps) line 82

dump line 92

dump line 102

dump line 112

don't dump line 122

don't dump line 132

 

etc...

 

 

Finally, you have a small problem with people using pots with different values, i.e. 1M vs 500K. Anyhow food for thought. I ultimately didn't do a floating dump in CAA as it seemed easier to read the whole kernel.

[Thomas Jentzsch]

Very interesting idea. You limit the polling to a rather small part of the kernel, but instead you vary the timing of the caps dumping. This is no universal solution for every game, but definitely a realistic alternative approach.

 

To determine how many pixel a paddle is moved between two frames, I suggest analyzing the movement of the mad bomber of Kaboom! in highest level. I doubt a human player is much faster than him.

[BigO]

No, I meant current joystick games like Off the Wall, which would work better with an analog paddle (like Breakout).

I have often thought that a faster paced Space Invaders with paddle control might be fun.

(Not requesting. Just food for thought.)

[Thomas Jentzsch]

I wonder if the different function of the CX22 was introduced to reduce kernel times on the 2600. Unlike CX80 or Amiga Mouse (which use Gray Code), the CX22 provides a direction bit. Usually it is sufficient to check that bit once per frame (outside kernel). So that you only have to count changes of the other bit inside the kernel.

 

Does anyone know any details about that?

Edited November 7, 2015 by Thomas Jentzsch

[BigO]

I wonder if the different function of the CX22 was introduced to reduce kernel times on the 2600. Unlike CX80 or Amiga Mouse (which use Gray Code), the CX22 provides a direction bit. Usually it is sufficient to check that bit once per frame (outside kernel). So that you only have to count changes of the other bit inside the kernel.

 

Does anyone know any details about that?

I don't really know, but on reading your previous discussions about the CX22 taking on some of the decoding overhead, I had the same thought.

The scheme should require fewer console resources to decode. You don't have to keep track and compare previous states for the direction, just read it directly from the port. Essentially, you just have to monitor one pulse to detect movement.

 

It's still two bits per axis, but seems like it would be a lot less work to decode.

 

If that pulse is driven by only one of the two optical encoders per axis, you would theoretically lose resolution as you'd only have half the state changes per full revolution, but that "loss" could be a good thing.

Edited November 7, 2015 by BigO

[Thomas Jentzsch]

That's what I meant to say.

 

I wonder if they designed the CX22 on purpose like that. The extra chip logic was not for free.

[BigO]

I think what I meant to say was, "yes".

Edited November 8, 2015 by BigO

[Omegamatrix]

Very interesting idea. You limit the polling to a rather small part of the kernel, but instead you vary the timing of the caps dumping. This is no universal solution for every game, but definitely a realistic alternative approach.

 

To determine how many pixel a paddle is moved between two frames, I suggest analyzing the movement of the mad bomber of Kaboom! in highest level. I doubt a human player is much faster than him.

I was thinking about polling today. In the next rebuild of CAA the approach I'm going to take is initially find the position of the paddle. After that I will have different overlapping kernels for the reading the paddles in different places. In my last build I was fighting for time within the kernel itself to reload the temp ram for displaying the score, and repositioning all of the objects. This greatly simplifies things.

 

 

So again the question becomes how fast a person can possibly turn a paddle in 1 frame. I haven't looked at Kaboom!'s source yet.

[maiki]

It would be really interesting to see Off The Wall being reprogrammed for paddles - if that is even possible...

[Lynxpro]

I have often thought that a faster paced Space Invaders with paddle control might be fun.

(Not requesting. Just food for thought.)

 

Space Invaders, Galaxian, Spider Fighter...

 

Don't forget about this thread:

 

http://atariage.com/forums/topic/156000-games-that-should-have-used-paddle-controllers/

 

I really do think the use of alternate controllers is one of the outstanding things in the Atari retro scene compared to other brands...

 

But going back to Trak-Balls, the suggestion from the thread above about converting Turmoil for Trak-Ball support seems pretty cool. You'd have to use it with small movements though, like when using 5200 Galaxian with the Trak-Ball.