new paddle design? (Flashback 2 & 2600)

[+batari]

What I mean is that there are algorithms out there that can sense the speed at which a controller is being turned and convert it to an appropriate motion, even if the resolution is small. Slower turning=fine movement. Fast turning=fast movement. This is exactly what mice do, I believe.

 

This seems a bit odd. Say I'm playing Tempest, and I want to go all the way around the web. So you're saying if I quickly turn it a small amount I will go all the way around, but if I turn it slowly the exact same amount I might only go partially around the web? To me, this would take quite a bit of getting used to -- it would seem like you would constantly be having to change your grip on the knob....

 

I'm not exactly convinced that this is the way a mouse works either. I think the pointer moves the same distance whether I move the mouse slowly or quickly. I'll have to do some simple expirements. Not saying you're wrong or anything -- I honestly don't know....

935851[/snapback]

It's actually the mouse driver that determines the "acceleration" as it's called. To test this for yourself, move your mouse a certain distance slowly, then move it the same distance quickly. It should move further when you move it faster. In the 2600, however, this would need to be done by hardware instead of software.

 

You can disable this acceleration curves in Windows by registry hacking, and if you do, you'll find that your mouse behaves very differently. So basically, you are already used to this feature without even knowing it.

 

If you are using Mac OSX, its acceleration curves are much more pronouced than Windows.

 

Mouse speed is often expressed as DPI (Dots Per Inch). The DPI is the number of pixels the mouse cursor will move when the mouse is moved one inch. Mouse acceleration/deceleration are software tricks that can be used to make a cursor go faster or slower than its DPI.

A less common unit, the Mickey is a measure of distance reported by a mouse. It is not a traditional unit of measurement because it indicates merely the number of "dots" reported in a particular direction. Only when combined with the DPI of the mouse does it become an indication of actual distance moved. In the absence of acceleration, the Mickey corresponds to the number of pixels moved on the computer screen.

Additionally, operating systems traditionally apply acceleration, referred to as ballistics to the motion reported by the mouse. For example, versions of Windows prior to Windows XP doubled reported values above a configurable threshold, and then optionally doubled them again above a second configurable threshold. These doublings were applied separately in the X and Y directions, resulting in very nonlinear response. In Windows XP and many OS versions for Apple Macintosh computers, a smoother ballistics calculation is used that compensates for screen resolution and has better linearity.

Edited September 21, 2005 by batari

[A.J. Franzman]

It's actually the mouse driver that determines the "acceleration" as it's called.  To test this for yourself, move your mouse a certain distance slowly, then move it the same distance quickly.  It should move further when you move it faster.  In the 2600, however, this would need to be done by hardware instead of software.

 

You can disable this acceleration curves in Windows by registry hacking, and if you do, you'll find that your mouse behaves very differently.  So basically, you are already used to this feature without even knowing it.

936007[/snapback]

Windows registry hacking not required - acceleration settings are available from the Mouse Control Panel.

 

I wish my mouse output more pulses per distance moved. I often need to position objects with single-pixel accuracy on a fairly high-resolution display (1280 x 1024). Setting the speed slow enough to realize this requires the mouse to be moved too far when trying to move the pointer all the way across the screen, but if I put the acceleration above the lowest non-zero setting, then I get problems with the cursor stuttering, freezing and jumping.

[else]

This seems a bit odd.  Say I'm playing Tempest, and I want to go all the way around the web.  So you're saying if I quickly turn it a small amount I will go all the way around, but if I turn it slowly the exact same amount I might only go partially around the web? 

 

No, what he's saying is that if he twists the rotor controller all the way around over the course of a half second it will move the player the same distance if he twists the rotor controller all the way around over the course of a minute.

 

In the case of the Driving controllers, there are 16 state changes over the course of 1 revolution. This works well for driving games which feature sprites that rotate in 16 direction, but not so great for a Tempest style game where you are pushing your player around a larger area.

 

Err, you sure about that? I understand the 16 states and all. We're talking about increasing the resolution of the rotary controller to _more than 16 states_ by equating the speed that those states are being cycled through to a variable (non linear) speed of travel of the on-screen object. So I believe what I said is exactly what we are talking about....

 

Since speed itself is an analog property, you can in theory increase the states to an infinite number. If you're using an 8-bit microcontroller to accomplish this, you can in reality turn those 16 states in to 256 states. It is an interesting idea. Not sure how it would translate to actual twitch-type gameplay, but interesting none the less.

Edited September 22, 2005 by else

[appleo]

In my quest for a better paddle (and one that can be easily/cheaply interfaced with the PC), I tried making a paddle ball game using the 2600 driving controller as a paddle. This sums up the problem and why "multiplying" the resolution won't work (mainly you can't create data where there is none):

 

Newsgroups: sci.electronics.design, sci.electronics.misc, sci.electronics.basics, alt.comp.hardware.homebuilt, alt.comp.hardware.homedesigned

From: "Mad Scientist Jr"

Date: 24 Aug 2005 14:55:59 -0700

Subject: Re: analog to quadrature converter?

 

No, it's because of resolution and because of my interface (a hagstrom

keyboard controller). I have an Atari 2600 driving controller plugged

in currently and built a little paddle game, and the resolution of the

driving controller is 16 pulses per revolution - you have to turn the

dang thing 20 times to get the paddle to move across the screen, and

I'm just drawing it in text! (5 chars on a 80 column textbox) ! In

hires, it just won't do - to match the feel of regular atari

pong/breakout the entire paddle needs to move across the screen in

about 10/16 of one turn... with the screen resolution I am using, one

pulse = a move of 4 pixels. with a screen of 640 pixels wide, that is

160 screen positions, if 160 is 10/16 of the total ppr, the encoder

would have to be capable of 256 ppr. Ideally I would replace the

encoder in the driving controller with one capable of 256 ppr, but

mechanical encoders with that high res don't seem to exist (unless I'm

looking in the wrong place). I think an optical encoder may be an

answer, do they go up to 256? Also, I'm a programmer, I don't really

know electronics beyond how to solder basic switches, so designing a

circuit to drive an optical encoder may be beyond me. Also, cost is a

factor, I want to spend as little as possible, ideally under $15 per

controller. Anyway, a potentionometer to a DAC would take up 8 bits = 8

keys on my keyboard per spinner, which is too many inputs. With

quadrature the paddle only uses 3 keys = 2 bits + fire button, which is

good. A pot to a ADC to a PIC simulating quadrature at 256 ppr might do

the trick...

 

If anyone is interested, the full discussion(s) can be seen here, we really got into it.

 

http://groups.google.com/group/rec.games.v...de1c3cb9ef97515

 

http://groups.google.com/group/sci.electro...a94b7fcd18c91d8

 

http://groups.google.com/group/sci.electro...a661a3668de8984

 

http://groups.google.com/group/comp.roboti...24ac8ea51275ec3

 

 

 

 

This seems a bit odd.  Say I'm playing Tempest, and I want to go all the way around the web.  So you're saying if I quickly turn it a small amount I will go all the way around, but if I turn it slowly the exact same amount I might only go partially around the web? 

 

No, what he's saying is that if he twists the rotor controller all the way around over the course of a half second it will move the player the same distance if he twists the rotor controller all the way around over the course of a minute.

 

In the case of the Driving controllers, there are 16 state changes over the course of 1 revolution. This works well for driving games which feature sprites that rotate in 16 direction, but not so great for a Tempest style game where you are pushing your player around a larger area.

 

Err, you sure about that? I understand the 16 states and all. We're talking about increasing the resolution of the rotary controller to _more than 16 states_ by equating the speed that those states are being cycled through to a variable (non linear) speed of travel of the on-screen object. So I believe what I said is exactly what we are talking about....

 

Since speed itself is an analog property, you can in theory increase the states to an infinite number. If you're using an 8-bit microcontroller to accomplish this, you can in reality turn those 16 states in to 256 states. It is an interesting idea. Not sure how it would translate to actual twitch-type gameplay, but interesting none the less.

936144[/snapback]

[keilbaca]

well in that case, is there a place to get brand new pots to replace them in my paddles? I don't want jitter for a long time, and I know that new replacements will work.

[appleo]

Contact cleaner not working for you?

 

This stuff worked for me:

http://www.radioshack.com/product.asp?cata...ct%5Fid=64-4315

 

 

 

 

well in that case, is there a place to get brand new pots to replace them in my paddles? I don't want jitter for a long time, and I know that new replacements will work.

936654[/snapback]

[+batari]

In my quest for a better paddle (and one that can be easily/cheaply interfaced with the PC), I tried making a paddle ball game using the 2600 driving controller as a paddle. This sums up the problem and why "multiplying" the resolution won't work (mainly you can't create data where there is none):

936632[/snapback]

Interesting discussion, but I think you missed the point. As was discussed, we are not talking about "distance" but "speed" which are distinct properties. If you turn the controller 1/16th of a turn, you get one click, and I agree that only using distance as a metric, you can't increase the resolution. But if you turn 1/16th of a turn in 0.1 seconds, you move X units, but if you turn 1/16th of a turn in 0.2 seconds, you move Y units, where Y<X. Since the movement is non-linear, you can get an infinite range of motion with only 16 positions.

[appleo]

I see, so if the player only wants to move 1 pixel (or the smallest movement you might support), they turn the knob slowly 1/16 a turn and it will only send 1 pulse, but if they turn the knob 1/16 a turn but faster, it would send 2 or more pulses. How fast does the processing have to be to do this accurately (esp for 2 or more players), and maintain the feel of a linear potentionometer and smooth movement? Is this what is meant by "twitch type game play"?

 

I guess my question would be, how do you calibrate the timing? I began playing with the driving controller as an inexpensive Pong paddle for the PC, and since PCs vary in CPU speed, timing will vary. Do you time it in milliseconds? Guess it's time to break out the paddle game again and find out... (okay this is now getting off the subject of the 2600, but what the heck, without the 2600 we wouldn't be playing with driving controllers)

 

 

 

 

>Since speed itself is an analog property, you can in theory increase the states to an infinite number. If you're using an 8-bit microcontroller to accomplish this, you can in reality turn those 16 states in to 256 states. It is an interesting idea. Not sure how it would translate to actual twitch-type gameplay, but interesting none the less.

 

 

In my quest for a better paddle (and one that can be easily/cheaply interfaced with the PC), I tried making a paddle ball game using the 2600 driving controller as a paddle. This sums up the problem and why "multiplying" the resolution won't work (mainly you can't create data where there is none):

936632[/snapback]

Interesting discussion, but I think you missed the point. As was discussed, we are not talking about "distance" but "speed" which are distinct properties. If you turn the controller 1/16th of a turn, you get one click, and I agree that only using distance as a metric, you can't increase the resolution. But if you turn 1/16th of a turn in 0.1 seconds, you move X units, but if you turn 1/16th of a turn in 0.2 seconds, you move Y units, where Y<X. Since the movement is non-linear, you can get an infinite range of motion with only 16 positions.

936664[/snapback]

Edited September 23, 2005 by appleo

[supercat]

If you turn the controller 1/16th of a turn, you get one click, and I agree that only using distance as a metric, you can't increase the resolution.  But if you turn 1/16th of a turn in 0.1 seconds, you move X units, but if you turn 1/16th of a turn in 0.2 seconds, you move Y units, where Y<X.  Since the movement is non-linear, you can get an infinite range of motion with only 16 positions.

936664[/snapback]

 

If your controller starts right on a 'click' boundary and you rotate it just over 1/16 turn, there will be two 'clicks' and the controller can use the time between them to estimate speed. If you turn the controller less than 1/16 turn, however, or even if you turn it between 1/16 and 1/8 turn but don't cross two zone boundaries, there is no information the controller can use to determine your intention.

 

Trying to interpolate a finer degree of control than what's actually there is fine when there's actually some real data there. But for small rotations of only 1-3 clicks there's really not much there. Telling people they have to turn the knob at least 1/8 turn to make their object move more than one pixel is going to be considered very annoying.

[+batari]

I see, so if the player only wants to move 1 pixel (or the smallest movement you might support), they turn the knob slowly 1/16 a turn and it will only send 1 pulse, but if they turn the knob 1/16 a turn but faster, it would send 2 or more pulses. How fast does the processing have to be to do this accurately (esp for 2 or more players), and maintain the feel of a linear potentionometer and smooth movement?

I don't think it needs to be very fast, but I haven't done any calculations.

Is this what is meant by "twitch type game play"?

I'm not sure, but it sounds like it might be right. It wouldn't give linear motion like a paddle, so the "feel" would definitely be different, but I think that one could get accustomed to it.

I guess my question would be, how do you calibrate the timing? I began playing with the driving controller as an inexpensive Pong paddle for the PC, and since PCs vary in CPU speed, timing will vary. Do you time it in milliseconds? Guess it's time to break out the paddle game again and find out... (okay this is now getting off the subject of the 2600, but what the heck, without the 2600 we wouldn't be playing with driving controllers)

936723[/snapback]

For a driving controller connected to a PC, I guess you could have the driving controller trigger an interrupt (or an event) every time the value changes, and measure the elapsed time using the system timer library (IIRC, gettimeofday() or something of that sort.) Or you could set up the driver to poll the driving controller once a millisecond, and record how many milliseconds elapse between changes.

 

But for a 2600, I was thinking that a microcontroller could do all of the work. It would probably be fast enough, as even the cheap $3 ones run at something like 14 Mhz. As long as you used the same clock speed, timing wouldn't be an issue.

 

Though either way, finding the right algorithm to convert speed to a number of units moved might be a bit of work. And I should also mention that it still might not work very well.

Edited September 23, 2005 by batari

[+batari]

If you turn the controller 1/16th of a turn, you get one click, and I agree that only using distance as a metric, you can't increase the resolution.  But if you turn 1/16th of a turn in 0.1 seconds, you move X units, but if you turn 1/16th of a turn in 0.2 seconds, you move Y units, where Y<X.  Since the movement is non-linear, you can get an infinite range of motion with only 16 positions.

936664[/snapback]

 

If your controller starts right on a 'click' boundary and you rotate it just over 1/16 turn, there will be two 'clicks' and the controller can use the time between them to estimate speed. If you turn the controller less than 1/16 turn, however, or even if you turn it between 1/16 and 1/8 turn but don't cross two zone boundaries, there is no information the controller can use to determine your intention.

 

Trying to interpolate a finer degree of control than what's actually there is fine when there's actually some real data there. But for small rotations of only 1-3 clicks there's really not much there. Telling people they have to turn the knob at least 1/8 turn to make their object move more than one pixel is going to be considered very annoying.

936744[/snapback]

I think that two clicks might be necessary as a minimum for other reasons, in that if the controller is right on a boundary, it might jitter back and forth (or not, depending on how the driving controller was designed.)

 

But whether this would be "annoying" or not is questionable. I think a quick demo is required to see how good or bad such a control scheme really is. A demo that runs on a real 2600 that senses the velocity of the driving controller could be done with a little effort. It could serve as a trial balloon to see if such a design is really feasible before one starts programming microcontrollers and designing hardware.

[+batari]

But whether this would be "annoying" or not is questionable.  I think a quick demo is required to see how good or bad such a control scheme really is.  A demo that runs on a real 2600 that senses the velocity of the driving controller could be done with a little effort.  It could serve as a trial balloon to see if such a design is really feasible before one starts programming microcontrollers and designing hardware.

936768[/snapback]

OK, I found a way to write a quick demo, while reading the driving controller, all in batari Basic! Anyway, I made a quick game where you try to shoot an object that falls from a random place.

 

This WILL NOT work correctly on an emulator. Don't even bother trying. It will only work on a real 2600 with a driving controller.

 

I realize the movement isn't that great yet, as the algorithm is really simple and this is just a quick proof-of-concept hack. I guess my point is, with a little practice, it's possible to get the speed of your twisting right to position yourself below the target every time. After a while, it kind of feels like a paddle.

 

I'll post source code in case someone else wants to see if they can improve the control.

DC_demo.zip

[mos6507]

Since speed itself is an analog property, you can in theory increase the states to an infinite number.  If you're using an 8-bit microcontroller to accomplish this, you can in reality turn those 16 states in to 256 states.  It is an interesting idea.  Not sure how it would translate to actual twitch-type gameplay, but interesting none the less.

936144[/snapback]

 

The only EFFICIENT way for the 2600 to read controllers is to do it once every frame (1/60th of a second). This happens to be sufficient for the standard driving controller. Only when you twist the driving controller very quickly does this sample rate lose sync of the quadrature encoding.

 

By using a microcontroller to read a higher resolution encoder more often, you still need to present this to the 2600. There are only 4 digital bits in which to encode direction and speed.

 

So you would need to buffer some kind of multi-nybble information which the 2600 would then pull out each frame with successive reads of the port until it figures out that it's caught up.

 

I'm not saying it can't be done. I'm just saying it's not trivial.

[appleo]

That is if we directly use quadrature output from the driving controller - what about programming a PIC to constantly read the driving controller, and use the quadrature to track a value 0-255, and then use that to manipulate resistance between 1K and 1 M ohm and send that to the 2600? That way the 2600 receives an absolute value for each controller, and thinks it's reading paddles.

 

We could get really fancy and attach a switch or pot to the pic for "tolerance" so that we can tweak how far/fast the paddle value changes depending on how fast the knob is turned.

 

Since speed itself is an analog property, you can in theory increase the states to an infinite number.  If you're using an 8-bit microcontroller to accomplish this, you can in reality turn those 16 states in to 256 states.  It is an interesting idea.  Not sure how it would translate to actual twitch-type gameplay, but interesting none the less.

936144[/snapback]

 

The only EFFICIENT way for the 2600 to read controllers is to do it once every frame (1/60th of a second). This happens to be sufficient for the standard driving controller. Only when you twist the driving controller very quickly does this sample rate lose sync of the quadrature encoding.

 

By using a microcontroller to read a higher resolution encoder more often, you still need to present this to the 2600. There are only 4 digital bits in which to encode direction and speed.

 

So you would need to buffer some kind of multi-nybble information which the 2600 would then pull out each frame with successive reads of the port until it figures out that it's caught up.

 

I'm not saying it can't be done. I'm just saying it's not trivial.

940155[/snapback]

Edited September 30, 2005 by appleo

[else]

By using a microcontroller to read a higher resolution encoder more often, you still need to present this to the 2600.  There are only 4 digital bits in which to encode direction and speed.

 

Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those!

 

I also agree that it takes two clicks to measure the speed. One click gives you no information that you can use.

 

Okay, who's got the breadboard to wire this sucker up!

[mos6507]

Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those!

I also agree that it takes two clicks to measure the speed.  One click gives you no information that you can use.

 

Note that the analog lines can't be used to represent more than a 1 and a 0 unless you intend on reading them multiple times during the screen. That defeats the purpose of the microcontroller. So in theory they could be used to boost the information the microcontroller can send to the VCS to 6, or 7 if you also include the fire button.

 

So it can be done. It's just a matter of coming up with a communication protocol that isn't a total kludge. And the microcontroller needs to be told when to reset itself after the read and start aggregating again so it needs to be bidirectional or the data reads need to be automatically detected.

 

It might be easier to just use a serial protocol but that's more overhead on the part of the VCS, especially on the reading end.

[appleo]

Well, if you count pressing of the Reset button or powerup, as click #1 (LastClick=0), then you don't need two clicks to measure speed. You just compare CurrentClick to the amount of time elapsed since LastClick. Of course with limited RAM, storing a date/time variable could be expensive.

 

By using a microcontroller to read a higher resolution encoder more often, you still need to present this to the 2600.  There are only 4 digital bits in which to encode direction and speed.

 

Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those!

 

I also agree that it takes two clicks to measure the speed. One click gives you no information that you can use.

 

Okay, who's got the breadboard to wire this sucker up!

940495[/snapback]

[else]

Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those!

I also agree that it takes two clicks to measure the speed.  One click gives you no information that you can use.

 

Note that the analog lines can't be used to represent more than a 1 and a 0 unless you intend on reading them multiple times during the screen. That defeats the purpose of the microcontroller. So in theory they could be used to boost the information the microcontroller can send to the VCS to 6, or 7 if you also include the fire button.

 

So it can be done. It's just a matter of coming up with a communication protocol that isn't a total kludge. And the microcontroller needs to be told when to reset itself after the read and start aggregating again so it needs to be bidirectional or the data reads need to be automatically detected.

 

It might be easier to just use a serial protocol but that's more overhead on the part of the VCS, especially on the reading end.

940507[/snapback]

 

Analog can only represent a 1 or a 0? I think you're confused....

 

It goes like this.... Microcontroller calculates speed between two sucessive clicks of the driving controller. Microcontroller then does a D-to-A conversion on this value and outputs it on an analog pin that is connected to the VCS's analog pin.

 

So I really don't see how you say an analog value can only take on a value of 1 or 0? That's not analog by any definition I'm familiar with....

Edited September 30, 2005 by else

[else]

Well, if you count pressing of the Reset button or powerup, as click #1 (LastClick=0), then you don't need two clicks to measure speed. You just compare CurrentClick to the amount of time elapsed since LastClick. Of course with limited RAM, storing a date/time variable could be expensive.

 

By using a microcontroller to read a higher resolution encoder more often, you still need to present this to the 2600.  There are only 4 digital bits in which to encode direction and speed.

 

Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those!

 

I also agree that it takes two clicks to measure the speed. One click gives you no information that you can use.

 

Okay, who's got the breadboard to wire this sucker up!

940495[/snapback]

940513[/snapback]

 

I don't agree. There are plenty of times where the user doesn't want to move -- they want to stay in one place. So after two clicks have been seen, you stop timing. Then the user may want to make a rapid move so you want to measure the time between two clicks again.

 

If you are constantly timing like you seem to be saying, I don't see how the user can stay in one place for a while, then make a rapid movement.

Edited September 30, 2005 by else

[appleo]

Good point, but is coding for the speed of one rapid click necessary if the player is standing still?

 

In the case that the player has not moved in x (whatever the cutoff is) seconds or milliseconds we count them as standing still, and move them the minimal distance.

 

With a resolution of 16 pulses per rev, is one click far enough that it will be noticable?

 

 

 

 

Well, if you count pressing of the Reset button or powerup, as click #1 (LastClick=0), then you don't need two clicks to measure speed. You just compare CurrentClick to the amount of time elapsed since LastClick. Of course with limited RAM, storing a date/time variable could be expensive.

 

By using a microcontroller to read a higher resolution encoder more often, you still need to present this to the 2600.  There are only 4 digital bits in which to encode direction and speed.

 

Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those!

 

I also agree that it takes two clicks to measure the speed. One click gives you no information that you can use.

 

Okay, who's got the breadboard to wire this sucker up!

940495[/snapback]

940513[/snapback]

 

I don't agree. There are plenty of times where the user doesn't want to move -- they want to stay in one place. So after two clicks have been seen, you stop timing. Then the user may want to make a rapid move so you want to measure the time between two clicks again.

 

If you are constantly timing like you seem to be saying, I don't see how the user can stay in one place for a while, then make a rapid movement.

940537[/snapback]

[+batari]

Well, if you count pressing of the Reset button or powerup, as click #1 (LastClick=0), then you don't need two clicks to measure speed. You just compare CurrentClick to the amount of time elapsed since LastClick. Of course with limited RAM, storing a date/time variable could be expensive.

 

By using a microcontroller to read a higher resolution encoder more often, you still need to present this to the 2600.  There are only 4 digital bits in which to encode direction and speed.

 

Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those!

 

I also agree that it takes two clicks to measure the speed. One click gives you no information that you can use.

 

Okay, who's got the breadboard to wire this sucker up!

940495[/snapback]

940513[/snapback]

 

I don't agree. There are plenty of times where the user doesn't want to move -- they want to stay in one place. So after two clicks have been seen, you stop timing. Then the user may want to make a rapid move so you want to measure the time between two clicks again.

 

If you are constantly timing like you seem to be saying, I don't see how the user can stay in one place for a while, then make a rapid movement.

940537[/snapback]

If you have the ability to (a real 2600, a driving controller and a programmable cart) try my demo above. It times every move of the driving controller but it "times out" if no movement takes place for a certain number of frames. Also, it doesn't stop timing after two clicks - if the controller is still being rotated in the same direction, it keeps timing until the movement "times out" again, either by no rotation or a change in direction, then it stops and waits for new movement.

 

And one click does give useful information, in that one click is enough to allow you to move one pixel over, but not (yet) enough to determine the speed of rotation - we wait for another click to determine speed.

[mos6507]

Analog can only represent a 1 or a 0?  I think you're confused....

 

It goes like this....  Microcontroller calculates speed between two sucessive clicks of the driving controller.  Microcontroller then does a D-to-A conversion on this value and outputs it on an analog pin that is connected to the VCS's analog pin.

 

So I really don't see how you say an analog value can only take on a value of 1 or 0?  That's not analog by any definition I'm familiar with....

940532[/snapback]

 

The 2600 has only one way to read from the controller ports.

 

Going D-to-A-to-D is not the way to go for anything greater than 1-bit.

 

Just because you have two analog lines doesn't mean you have the ability to instantly derive a number between 0-227 or whatever the top end of pots are (its around 220 something on the Atari 8-bits, which uses the POKEY chip to offload this task).

 

The method in which the pots are read on the 2600 is highly processor intensive. The more you read the pots in a given frame, the more resolution you have to work with. But you never really get the actual value since it's an analog value.

 

That is just not the way to pass a number precisely to the 2600 other than a hard 0 or 1, in which case you just have to check the pot once or twice.

 

The whole point of the microcontroller is to save 2600 processor time. In the hack that Thomas made of Missile Command he had to sample the trackball (which is similar to a driving controller) multiple times during the screen not unlike the paddles.

 

If the microcontroller sampled the trackball multiple times per screen and then passed the data back in such a way that forces the 2600 itself to sample the controller ports multiple times per screen to derive the value then you're just right back where you started again.

 

Any communications protocol between the microcontroller and the 2600 must be accomplished within the limited timeframe of the vertical blank.

 

So that means you are limited to sending a hard analog high/low through the pot lines to turn them into pseudo digital lines so they don't take very long to read. That limits you to 7 useful bits of data (4 joystick lines, trigger, and two pots).

 

On the DB9 port there are only 9 pins to work with. You have those 7, +5V and ground.

[A.J. Franzman]

Sorry mos6507, you're absolutely wrong on this.

 

What we're discussing is a microcontroller-operated adapter to make a driving controller provide paddle-style analog signals to the 2600 console on the "paddle" lines. All timing, calculation, and conversion will be handled internally by the adaptor. This new driving controller/adapter combination will effectively form a "digitally sampled, velocity-sensitive paddle controller" which will not require any reprogramming or different reading techniques - it will be completely transparent to any existing or future game programmed to recognize paddle inputs.

Edited October 1, 2005 by A.J. Franzman

[supercat]

If the microcontroller sampled the trackball multiple times per screen and then passed the data back in such a way that forces the 2600 itself to sample the controller ports multiple times per screen to derive the value then you're just right back where you started again.

941004[/snapback]

 

That depends. If the goal is to provide a means by which a high-resolution knob (either continuous or end-stopped) can be read with minimal CPU overhead, then converting the pot signals into a paddle-style time delay makes little sense. On the other hand, if the goal is to provide a means by which a knobs can be read jitter-free by software that expects the old style paddle controllers, converting the pot signals into a paddle-style time delay makes a lot of sense.

 

Perhaps the best approach would be to have the microcontroller look for the Atari to output data on the "fire" [i.e. left/right] pin, something it would normally never do. If it sees data there, it could switch to digital-readout mode, but if not it could report data the "old-fashioned" way.

 

BTW, how quickly can the paddle caps be charged/discharged?

[mos6507]

If the microcontroller sampled the trackball multiple times per screen and then passed the data back in such a way that forces the 2600 itself to sample the controller ports multiple times per screen to derive the value then you're just right back where you started again.

941004[/snapback]

 

That depends. If the goal is to provide a means by which a high-resolution knob (either continuous or end-stopped) can be read with minimal CPU overhead, then converting the pot signals into a paddle-style time delay makes little sense. On the other hand, if the goal is to provide a means by which a knobs can be read jitter-free by software that expects the old style paddle controllers, converting the pot signals into a paddle-style time delay makes a lot of sense.

 

Perhaps the best approach would be to have the microcontroller look for the Atari to output data on the "fire" [i.e. left/right] pin, something it would normally never do. If it sees data there, it could switch to digital-readout mode, but if not it could report data the "old-fashioned" way.

 

BTW, how quickly can the paddle caps be charged/discharged?

941097[/snapback]

 

 

Nobody in this thread seems to be understanding my discussion about how inefficient the 2600 is in reading paddle signals.

 

Even the tech laymen need only look at the 2600 catalog to see how many paddle games there are that have anywhere close to fancy graphics. Just about none. Party Mix might be the fanciest but that's a Supercharger game.

 

It would be insane to waste a microcontroller by having it present data on the pot lines like this unless they were going to be read as 1 or 0 like the booster grip.

 

It really should be the other way around. That's exactly why the Atari 8-bit home computers have a whole custom chip (POKEY) that samples the pots and then merely presents a digital value in the hardware register for each pot.