What games use the driving controller ?

[MaxSpeed]

I discovered Enduro can not use it. It can not be used in place of the Paddels in Circus Atari ? What does it do differently ?

[+Mitch]

Of the original Atari games only Indy 500 works with it.

 

Mitch

http://atari7800.atari.org

[SS]

Thomas Jentzsch has done some nice work with the under-utilized Driving Controllers

 

Asteroids DC+

 

Sprintmaster DC

 

Thrust Plus : DC Edition

[GrizzLee]

Yes, Thomas''s hacks work. There is however, an original game, a homebrew that uses the drving controllers as well. The game is Stella-Sketch by Bob Colbert. It not only utilizes the driving controllers, but is can be used with an ST-Mouse, Track-Ball, and others as I recall. It is a Supercharger game. Unfortunately, due to legal problems, Bob was forced to quit selling it. It is really a neat game for the 2600.

[Rob Mitchell]

I discovered Enduro can not use it. It can not be used in place of the Paddels in Circus Atari ? What does it do differently ?  

 

The driving controller is a rotary switch spinner that uses phase shifted quadrature encoding (yahoo search) .. which the Indy 500/Sears Race cart decodes for driving the cars. One pair were packed in with this cart.

 

A few games already mentioned have been hacked by Thomas Jentszch to use these special controllers. Stell-a-Sketch has an option to use these also (not that great).

 

The forthcoming Death Derby will use them.

 

Chris Tumber has hacked several original Vectrex games to use the Driving Controller. And his Omega Chase game can use them too! All these are on a Vectrex cart called Spinnerama.

 

I have hacked a Dondzila Vectrex driving game to use these also! And someday I hope to have a Death Race clone for the Vectrex.

 

Tempest 2000 for the Jaguar has an option for the driving controller.

 

A paddle is an analog potentiometer and are wired together as pairs.

 

Rob Mitchell, Atlanta, GA

[Nukey Shay]

As far as what it does differently, this can be described by showing a paddle controller as a value...like this: (note:NOT a binary representation)

0000000000000001 = minimum

1000000000000000 = maximum

The paddle controls have a stopper to keep the knob from being turned beyond the "maximum" and "minimum" value. When you turn it, a value in between those two values is sent back to the 2600.

 

The driving controllers have no stopper. They also fetch the info differently:

001001001001 = turning clockwise

010010010010

100100100100

 

001001001001 = turning counter-clockwise

100100100100

010010010010

 

As you turn the knob, the 2600 can decide on which direction you are turning it based on the flow of those "1"'s using just two sample reads.

[Jeffy Arensmeyer]

 

Nukey, you're such a nerd.

 

Thanx for that visual aid. So, the paddles just provide a valued input and the console is responsible for providing the proper movement based on the input?... So would typical-center be 0000000010000000 or 0000000100000000?

 

Thus, the driving contollers act more like a repeating circular sequence that is unique based upon the direction it is being turned, like a really cheap encoder?

 

So, if you implemented more precise movement based upon a paddle controller, couldn't they be used for driving games? For example, on typical paddle games, far left on the screen is the minimum input for the paddle and right is the maximum. What if, instead of one giant zone of min/max you had four zones that were deignated min/max...

 

1000000000000000 = min 1

0001000000000000 = max 1

0000100000000000 = min 2

0000000100000000 = max 2

...etc...

 

Each zone, from min to max would represent one revolution of the screen object. Sure, you might end up with the contoller turned all the way left or right, but wouldn't this open up driving games for people who only owned paddles?

 

ò¿ó      

 

[joeybastard]

I always thought it weird that the paddles had a stop and the driving controllers didn't. After all a steering wheel in a car has a stop on either end so shouldn't the driving controllers have it too? The paddles on the other hand probably don't need a stop.

[Nukey Shay]

Regarding the 2600, I don't know exactly...because all of my info comes from working on the 800 computer. With that system, the paddle controller reads DO get converted into a value by the hardware (ranged 1-228). So if you had it in the center, you would read 114 or so. I don't really know what you mean by "more precise" movement...since just using the value outright is about as precise you can get (though you can easily remove "jitters" by stripping off the lower bit or two). If you really wanted to divide the paddle area into more than one revolution, you could just strip off the higher bits (killing the two high bits would yield 3 1/2 turns worth...with high values of 63, 63, 63, & 35). I don't know how much of this differs on the 2600 hardware (I understand that it's not the same), but that is how it works on the 800.

[Thomas Jentzsch]

 

So, if you implemented more precise movement based upon a paddle controller, couldn't they be used for driving games? 

Yes they could (Night Driver!), but unlike the driving controllers paddle control can not be added to existing games.

 

The reason for this is, that the 2600 doesn't output a simple paddle value (e.g. 0..255). Instead you have to check one single bit very frequently. To get enough precision, this has to be done inside the display kernel and that reduces the amount of valuable CPU cycles for displaying nice graphics. Based on the time where this bit changes you can then calculate the paddle position.

 

Adding driving controller support is much easier, because it only has to be checked once per frame (just like the joystick). So all you have to do is to find the joystick code and some extra ROM space (plus at least two free bits of RAM/player) and add your new code there.

[Nukey Shay]

I always thought it weird that the paddles had a stop and the driving controllers didn't.  After all a steering wheel in a car has a stop on either end so shouldn't the driving controllers have it too?  The paddles on the other hand probably don't need a stop.

 

The problem is that you jump immediately from a very small value to a very large one (imagine turning your volume control on your stereo below the minimum!). If you really wanted to, you could remove the plastic "wedge" or the indentation on the metal that causes the paddle to stop turning. There will be a small area where no value could be read, though (the point between the two wire pads)...and the metal brushes jumping on and off the pads themselves might be hard on the controller.

[Jeffy Arensmeyer]

 

By more precise, Nukey, I mean dividing the usable region into smaller, readable sections. Instead of having only one readable zone, you would create multiple zones thus increasing the pseudo-precision into multiple zones. Hmmm... I think I'm confused now.

 

Probably the reason for continuous rotation, joeybastard, is because the way people perceive orientation. Someone might turn the controller enough to invert their on-screen object such as from facing up to down, or facing left to right. But when they begin to turn the object again, they would get confused about which way to turn. (i.e. A car facing down would turn to the left side of the screen if you turned the controller right, and vice-versa. A buit-in stop would cause them to "bottom out" the controller", so they would turn it another way.

 

Either that, or Atari saved ½¢ per one gazillion controllers by adding the stop.

 

ò¿ó        

 

[Nukey Shay]

@Thomas

Thanks for the description! It's a wonder that Atari (and 3rd parties) didn't implement the driving controllers more than just the one game. Especially since you would save more cycles to display more complex displays.

[Nukey Shay]

 

By more precise, Nukey, I mean dividing the usable region into smaller, readable sections.  Instead of having only one readable zone, you would create multiple zones thus increasing the pseudo-precision into multiple zones.  Hmmm... I think I'm confused now.  

 

That's how it works on the 800 (though it wouldn't work that way on the 2600--Thanx TZ). On the computer, you still only have 228 possible positions that the paddle can be in...you can slice them up into as many sections as you want (say 1-63 for rotation #1, 64-127 for rotation #2, etc.) More useless info for the 2600 though, since it wouldn't work that way on that hardware.

 

BTW nice explaination of the driving controller use

[Thomas Jentzsch]

The problem is that you jump immediately from a very small value to a very large one (imagine turning your volume control on your stereo below the minimum!).

This could be easily corrected in software. Just remember the position of the previous frame and calculate the difference. If you find a positive difference >= 128 or a negative difference <= -128 you would just add/subtract 256 and get the correct value.

 

Example:

previous frame: 250, current frame: 10

-> current - previous = 10 - 250 = -240

-> -240 + 256 = 16

[Nukey Shay]

True...but if the game was something like Breakout (where extreme left/right = up against the borders), the value difference would make tha onscreen paddle "jump" from one edge to the other when crossing over the previously-blocked area turning the knob. Dunno if that would be a good thing (possibly...Kaboom! maybe ).

[Rob Mitchell]

Again the driving controllers are a low resolution quadrature encoding device. Another is the trakballs (2D quadratures). An example of a high resolution 2D quadrature is your computer mouse.

 

Quadrature works like this:

 

A B

0 0

1 0

1 1

0 1

0 0 (repeats to top)

 

where A leads B in transition. This might be defined as Clockwise.

 

The other condition:

 

A B

0 0

0 1

1 1

1 0

0 0 (repeats to top)

 

where B leads A in transition. This would be Counter-clockwise.

 

The driving controllers use pins 1/2 which would be A/B as above. If you want to see this in action, plug the driving controller into the Atari with the Testcart .. or plug into the Vectrex with the Test cart in controller mode and slowly turn the driving controller one direction and then the other.

 

Games that read this code have one variable that is the past state of the two bits. The new state is then compared to the past state to see which bit has changed and then react either CW or CCW.

 

It really is clever and I'm impressed that Atari did this in both the arcades and with the Indy 500 game in 1977.

 

Imagine if Atari had decided to use the paddles for Indy 500. Then you would be correcting your steering for every turn. Not very fun as a top down driving game. Just fine for a first person driving game: Night Driver.

 

Rob Mitchell, Atlanta, GA

[MaxSpeed]

Wow, Thanks guys for all the detail. We have such mental diversity - those who like to talk about poop colors, others politics, and still others technology and all gamers. Such a great place.

[Godzilla]

if your poop is neon blue, is that bad?

[RockLobster]

On 1/24/2003 at 9:24 AM, Rob Mitchell said:

Again the driving controllers are a low resolution quadrature encoding device. Another is the trakballs (2D quadratures). An example of a high resolution 2D quadrature is your computer mouse.

 

Quadrature works like this:

 

A B

0 0

1 0

1 1

0 1

0 0 (repeats to top)

 

where A leads B in transition. This might be defined as Clockwise.

 

The other condition:

 

A B

0 0

0 1

1 1

1 0

0 0 (repeats to top)

 

where B leads A in transition. This would be Counter-clockwise.

 

@dualcam

 

I think this might be why the Atari Driving Controller doesn't work properly via the 2600dapter-D9 as a USB HID.

 

On a real 2600, the rotation is smooth enough for turning your Indy 500 car:   

https://streamable.com/cm3zzy

 

However, when the Driving Controller is plugged into a PC/Mac/linux device as a HID, it's only providing 3 step values during rotation.

https://streamable.com/c1ag4p

 

 

[RamrodHare]

"19 years ago, in a forum not so far away..." 

 

I also thought of the famous quote from Altered Beast, but I think I've  used it before.

[Bomberman94]

Just bought my first driving controller for my Atari 2600 😊

 

Because of this I wanted to add another homebrew game for this: The Core 2 (Kudos to @Thomas Jentzsch). 

[Rodney Hester]

On 1/24/2023 at 12:34 PM, RockLobster said:

@dualcam

 

I think this might be why the Atari Driving Controller doesn't work properly via the 2600dapter-D9 as a USB HID.

 

On a real 2600, the rotation is smooth enough for turning your Indy 500 car:   

https://streamable.com/cm3zzy

 

However, when the Driving Controller is plugged into a PC/Mac/linux device as a HID, it's only providing 3 step values during rotation.

https://streamable.com/c1ag4p

 

 

Not sure what, but something is set up very wrong.  The driving controller on a D9 works exactly as it does on the Atari - in fact, I played a good bit of Indy 500 on the (hacked) RetroN 77 with it.

[+Yurkie]

On 1/24/2003 at 12:46 AM, GrizzLee said:

Yes, Thomas''s hacks work. There is however, an original game, a homebrew that uses the drving controllers as well. The game is Stella-Sketch by Bob Colbert. It not only utilizes the driving controllers, but is can be used with an ST-Mouse, Track-Ball, and others as I recall. It is a Supercharger game. Unfortunately, due to legal problems, Bob was forced to quit selling it. It is really a neat game for the 2600.

I know 20 years old. The reason being, does anyone know a way to contact Bob Colbert about his game?

[+LS650]

On 1/23/2003 at 7:24 PM, SS said:

Thomas Jentzsch has done some nice work with the under-utilized Driving Controllers

Asteroids DC+

Sprintmaster DC

Thrust Plus : DC Edition

I just picked up a DC controller out of curiosity.  Yep, works great with Indy 500.

I'll have to check out the above three hacks.

 

Have any other games/hacks for the DC been developed?