Indy 500

[Chris-in-NJ]

This is one game I'd like to get ahold of again. Just been looking on eBay and I'm amazed how many sellers are selling the cart by itself yet claim to have tested it. How could they test it without the driving controllers? What does the cart sell for nowadays with both controllers included?

[BigO]

This is one game I'd like to get ahold of again. Just been looking on eBay and I'm amazed how many sellers are selling the cart by itself yet claim to have tested it. How could they test it without the driving controllers? What does the cart sell for nowadays with both controllers included?

 

I guess they could say that it powered up.

 

I know people have hacked or homebrewed games to use the driving controller but has anyone hacked Indy 500 to use the paddle controller or joystick?

 

I have a spare Indy 500, but not spare controllers.

 

On a way tangential note:

I've heard that the driving controller uses quadrature encoding but I've also heard that it's just an absolute position encoder. Based on the behavior of the cars, I always assumed that it was an absolute position thing. Now that I've seen a little more of the 2600's capabilities, I'd be surprised if it could possibly handle the quadrature encoding. So, assuming that it's really an absolute position encoder, a clever person might be able to put together an adapter that would use an analog to digital conversion to enable a paddle controller to play Indy 500. You'd have to want to play Indy 500 real bad or be looking for an excuse to tinker with microcontrollers, but I think a fairly simple and inexpensive microcontroller could do the job. Of course, you couldn't spin the controller all the way around, but I don't see that as much of a loss. And, the 270 degree controller position couldn't correpond exactly to the 360 degree orientation of the car. Then again, who cares? Nobody would be silly enough to build this thing to play only one cartridge anyway.

[shadow460]

The driving controller simulates movement of the joystick. As you turn the wheel, the DC simulates, no joystick movement, then left, then left+right simultaneously, then right, then back to no movement. This happens several times throughout a single rotation, and it's reversed (of course) if the wheel is rotated the opposite way. There are two sets of contacts in the DC, one for the "left" signal and one for the "right", and they are slightly out of phase to assist the 2600 in determining which way the wheel is being turned.

Since pressing a button on the paddles generates the same signal as either pressing left or right on the joystick, you could at least steer the cars with a pair of paddles.

 

Driving controllers are $5 each around here. They're not everyday common, but they aren't too hard to get.

Edited May 30, 2007 by shadow460

[BigO]

The driving controller simulates movement of the joystick. As you turn the wheel, the DC simulates, no joystick movement, then left, then left+right simultaneously, then right, then back to no movement. This happens several times throughout a single rotation, and it's reversed (of course) if the wheel is rotated the opposite way. There are two sets of contacts in the DC, one for the "left" signal and one for the "right", and they are slightly out of phase to assist the 2600 in determining which way the wheel is being turned.

Since pressing a button on the paddles generates the same signal as either pressing left or right on the joystick, you could at least steer the cars with a pair of paddles.

 

Driving controllers are $5 each around here. They're not everyday common, but they aren't too hard to get.

 

You're sure about this? The 2600 is scanning that port fast enough to detect the slight "out of phase" condition you describe?

 

As I interpreted the schematic, the absolute position encoder would output 1 of 16 unique binary values to 4 TIA inputs. Maybe I interpreted it that way because it seemed much simpler and more like something I thought the 2600 would have the horsepower to do. I guess I could pretty easily test my theory by using the controller to point the car in a particular direction, tape the controller knob in place and then unplug the controller. If it works the way I think it works, the car will return to its "neutral" position when the controller is unplugged and then return to where I set it when the controller is plugged back in. The response should be essentially nothing when unplugged and plugged back in if the other encoding scheme is actually used.

 

I also don't think there'd need to be 4 inputs to the TIA if that quadrature encoding type scheme was used.

 

In theory, I could simulate my version of the driving controller with 4 spst toggle switches. (not counting the "fire" button).

 

[EDIT]: Just remembered that I loaned my driving controllers to a friend so can't test this right now. Yeah, I know, I know, but I did. Really. I'll test it later. I know I have one more driving controller somewhere, but can't find it right now.

 

I'll take a look at the driving controller and joystick controller schematics. I think the joystick should be able to duplicate at least a couple of the states of an absolute position encoder.

Edited May 30, 2007 by BigO

[alex_79]

The driving controller generates a 2-bit grey code (4 unique binary values) and the sequence is repeated 4 times in a complete rotation. There are 4 position of the knob which correspond to a single binary value, so it's not an absolute encoder. It uses pins 1 and 2 of the controller port, which correspond to "up" and "down" joystick directions.

 

 

as you can see in this picture there are only 3 wires connected to the encoder: black is ground, white and blue are joystick directions "up" and "down" respectively.

[holygrailvideogames.com]

This is one game I'd like to get ahold of again. Just been looking on eBay and I'm amazed how many sellers are selling the cart by itself yet claim to have tested it. How could they test it without the driving controllers? What does the cart sell for nowadays with both controllers included?

 

The last set that I sold for went for $24 including priority shipping. I haven't tried selling any of these in the last several months though I do have several driving controllers right now that I haven't gotten around to testing.

[BigO]

The driving controller generates a 2-bit grey code (4 unique binary values) and the sequence is repeated 4 times in a complete rotation. There are 4 position of the knob which correspond to a single binary value, so it's not an absolute encoder. It uses pins 1 and 2 of the controller port, which correspond to "up" and "down" joystick directions.

 

 

as you can see in this picture there are only 3 wires connected to the encoder: black is ground, white and blue are joystick directions "up" and "down" respectively.

 

Hey, thanks for the correction folks.

 

I tested my assumptions and as y'all already knew, they were wrong.

Very interesting. I've badly misinterpreted some things I've seen. Shoulda cracked open the driving controller sooner.

When put in terms of the joystick controller, the driving controller appears to do up, or down or up and down simultaneously and, assumedly, none of the above. I think I'll plug it in and run the joystick diagnostic tool on the FB2 just for grins.

 

 

A joystick will steer the Indy car one increment of rotation left and right. Those 16 increments were part of my misinterpretation as I thought they corresponded to 16 unique positions of a 4 bit encoder.

 

I guess if one were to for some reason want to, they could implement an absolute position binary encoder based controller using the 4 inputs that the joystick uses. Why would one want to do that? Beats me.

Edited May 30, 2007 by BigO

[shadow460]

The FB2 should think the driving controller is a joystick. The 2600 probably does.

[Video]

I just tried a driveing controller on my 2600, useing my Test Cart.

 

When the wheel is rotated right, it goes from off, to down, to down + up, to up, to off again.

 

Turning left does the opposite. Fire on the controller is the same as on a standard Joystic.

 

Anyhow, since that's all it's doing, I think makeing a slight mod to play with a joystic would be fairly easy, since it is reading as a joystic, just pulling functions you can't do with an unmoded joystic.

 

Also, paddles, while harder to do, would be a cool option, after all, to stop turning, you'd escentually turn the whell back to center, just like a real steering wheel controller for a more modern system. But to my understanding, makeing the atari read paddles is considerably more difficult than joystics cause of how it reads them or some such.

 

And hey, if someone can make Indy read paddles...how about a 4 player indy? that would be friggin AWESOME!! if anybody should happen to tackle altering indy that is...f

Edited May 30, 2007 by Video

[G.Whiz]

Seems to me that you could use regular paddles, but once you hit the limit, your car just ended up crashing 'cuz you couldn't make the turn. I think we played it this way once because we forgot to switch over the paddles to the racing ones. I could be wrong though...?

 

~G

[Nukey Shay]

Seems to me that you could use regular paddles, but once you hit the limit, your car just ended up crashing 'cuz you couldn't make the turn. I think we played it this way once because we forgot to switch over the paddles to the racing ones. I could be wrong though...?

 

As posted above, the signals are different...so it must be a fuzzy memory

But the hack idea was not to use the same method of turning as Indy does - where turning right indefinately rotates the sprite clockwise indefinately (even when not moving)...but more like an actual steering column - turning more degrees to the right causes the sprite to make tighter turns while in motion (with the center position causing no turn). Turning the paddle all the way to the right would mean that the sprite would be making the sharpest corner to the right in that case.

[Rob Mitchell]

yes .. the dc is a 2 bit quadrature encoder .. with 16 transitions in 360 degrees.

 

0 1

1 1

1 0

0 0

and repeat ..

 

To go the other direction:

0 0

1 0

1 1

0 1

and repeat ..

 

 

before the existence of the 2600 test cart .. I plugged the dc into the Vectrex running its test cart and finally figured what was happening. This info led to Chris Tumber programming a Tempest clone for the Vectrex using this controller. I had previously completely disassembled the dc encoder.

 

Those of us who remember the early days of the video arcade age (1975-76) encountered all kinds of driving games .. Indy 800 (8 person Indy driving!) .. Death Race .. Well in 1977 I just had to have the Indy 500 cart!

 

My dc controller is permanantly mounted in the top of a Video Pinball shell and has pennies hot glued inside its black spinner knob for some angular momentum when spun.

 

Rob

Edited May 31, 2007 by Rob Mitchell

[BigO]

yes .. the dc is a 2 bit quadrature encoder .. with 16 transitions in 360 degrees.

 

0 1

1 1

1 0

0 0

and repeat ..

 

To go the other direction:

0 0

1 0

1 1

0 1

and repeat ..

 

 

before the existence of the 2600 test cart .. I plugged the dc into the Vectrex running its test cart and finally figured what was happening. This info led to Chris Tumber programming a Tempest clone for the Vectrex using this controller. I had previously completely disassembled the dc encoder.

 

Those of us who remember the early days of the video arcade age (1975-76) encountered all kinds of driving games .. Indy 800 (8 person Indy driving!) .. Death Race .. Well in 1977 I just had to have the Indy 500 cart!

 

My dc controller is permanantly mounted in the top of a Video Pinball shell and has pennies hot glued inside its black spinner knob for some angular momentum when spun.

 

Rob

 

Now having this correct information, it would be easier to come up with a way to use a joystick to output the sequenced gray code rather than use a paddle controller to output absolute binary values. Given the $5.00 price of a driving controller, I won't be working on this any time soon. I still haven't done a microcontroller project and this would be a fairly simple one. Then again, the uC would probably be overkill for a gray code up down counter.

 

Never really looked deeply into this encoding. The software interpretation of the bit pattern should be simpler than I originally imagined. Not sure how fast it would have to be read to accomodate the fastest possible real world rotation, but shouldn't be too bad. Worse case, you'd miss a state change somewhere and misinterpret the direction for one instant. Cool.

 

I had been contemplating which controller to support in a game I'm working on. I guess I've not really narrowed the possibilities via this discussion and now I have the urge to go hack something to use the driving controller. But, I also now have a better idea how to analyze the broken Wico Command Control track ball I have. Should keep me out of trouble for a while...