What 2600 titles could/should have Trak-Ball support added?

[alex_79]

I managed to draw a schematic of the cx80 based on the pictures in this site: http://www.the-liberator.net/site-files/retro-games/hardware/Atari-2600/atari-2600-trak-ball-controller.htm

This was possible because the board is single side, so all traces are on one side and all the components on the other and the pictures are hi-res enough to follow all the connections.

It would be great if someone who owns a cx80 could check if there are errors in the schem and also read the value of the two caps circled in this picture, as the printings on those are covered in all the images I could find.

As you can see, while functionally identical, the CX80 uses a different circuit than the CX22.
cx80_schem.pdf

[BigO]

Are you sure a Trak-Ball in joystick mode generates pulses?

 

That would mean the single check per frame would miss a pulse by 50%. And then the cursor (or whatever) would move slower than with a real joystick.

To be clear, I'm not saying that it is a pulse driven protocol or anything of that sort. The directional signal is not intentionally presented a pulse. The on/off nature of the resultant directional signals is just a necessary effect of the conversion process between the encoder and the final signal. The method creates a somewhat proportional output relative to the speed of the ball spin.

 

Using a physical joystick, the analagous action would be tapping the joystick to create very short periods of activity to simulate slow movement. The time gaps between active states effectively slows down the on-screen player movement. In a one second period of time, a steady signal from the joystick would move the player farther on the screen than an intermittent signal. Therefore the average speed over that one second period would be slower with the intermittent signal than it would be with a steady signal.

 

 

Nothing particularly scientific about the following tests, but just to give you an idea of what's really happening with the signals from a trackball emulating a joystick. Tests performed using an Accuball controller.

 

Traces depicted in screen shots are, from the bottom up are: Up (white), Down (brown?), Left (red), Right (orange)

Note: the joystick signals are active LO.

 

Flick Left

 

Slow Steady Right

 

Slow Steady Up

 

 

 

This data would probably be more meaningful if I were to capture the raw encoder signals on a separate channel synchronous with the JS emulation signals. If somebody really, really wants to play with this concept, I'll see if I can rig my one JS mode trackball up to capture that data. For now, it's just a thought experiment.

Edited November 26, 2015 by BigO

[BigO]

I suspect that if the same sampling rate used for the trackball inputs in the recent adaptations were used, this intermittent faux joystick signal behavior could be detected.

 

Within certain ball speed thresholds, the signal supplied by a trackball emulating a joystick is proportional to the movement of the ball. Whether those thresholds fall within a band that can be interpreted meaningfully in software is a different matter.

 

(The narrowest JS signal pulse that I captured while testing was ~1ms. I calculated the theoretical one-shot time constant in the CX-53 to be 1.2 ms so 1 ms is in the ballpark.)

 

My basic theory is that if you increase the on-screem movement speed in response to joystick input AND sample the joystick inputs fast enough AND are using a trackball that emulates a joystick, you MIGHT be able to use a JS mode only trackball to get a more trackball-like experience.

Worth the effort? Highly unlikely.

Edited November 26, 2015 by BigO

[Thomas Jentzsch]

Worth the effort? Highly unlikely.

Why not? Instead of 2 bits required for a TB, we would have to poll 4 bits inside the kernel. Not sure if 1 ms allows for a high enough resolution, but maybe worth a try.

 

But I am still not convinced if the joystick emulation works that way. There must be some additional logic, either inside the game (I doubt that) or inside the trackball. Else t is just luck, if a pulse is happening at the same time as the joystick is checked or not. And if you stop the TB moving, while the pulse is high, the cursor (or whatever) would continue moving.

 

EDIT: I should have looked at the graphics before. Now I understand the logic: It behaves like a TB at slow speed and like a joystick at high speed.

Edited November 26, 2015 by Thomas Jentzsch

[BigO]

I managed to draw a schematic of the cx80 based on the pictures in this site: http://www.the-liberator.net/site-files/retro-games/hardware/Atari-2600/atari-2600-trak-ball-controller.htm

This was possible because the board is single side, so all traces are on one side and all the components on the other and the pictures are hi-res enough to follow all the connections.

It would be great if someone who owns a cx80 could check if there are errors in the schem and also read the value of the two caps circled in this picture, as the printings on those are covered in all the images I could find.

cx80board.JPG

As you can see, while functionally identical, the CX80 uses a different circuit than the CX22.

cx80_schem.pdf

Thanks for putting together that schematic.

 

That mechanical setup is definitely not the quality of that found in the 5200 Trak-Ball or the Wico. I don't think I want to rush out and buy one.

[BigO]

Why not? Instead of 2 bits required for a TB, we would have to poll 4 bits inside the kernel. Not sure if 1 ms allows for a high enough resolution, but maybe worth a try.

 

But I am still not convinced if the joystick emulation works that way. There must be some additional logic, either inside the game (I doubt that) or inside the trackball. Else t is just luck, if a pulse is happening at the same time as the joystick is checked or not. And if you stop the TB moving, while the pulse is high, the cursor (or whatever) would continue moving.

Since it's all the same bits whether it's a trackball or joystick. I thought you were already reading all 4 bits? (2 per axis * 2 axes). I thought you'd just have to interpret them differently, back to the old joystick way.

 

I'm afraid I don't have anything more convincing to offer than actual signals being captured from an actual device at the actual physical point where the signals feed into the console. And, those signals matched my documented predictions that were based on an analysis of the hardware used to generate the signals.

 

The net result for me is that I'm completely convinced of what is being sent to the console by this particular device.

 

 

What I'm not thoroughly convinced of is that one could meaningfully translate this information in into motion control within the software. I think the two key components are to detect and respond to those short duration events and make the maximum player movement speed faster.

As it is now, faster sampling rate might give the ability to better emulate the partial speed created by a slow roll. But once the trackball outputs 100% active joystick signals, the player speed would need to be faster than normal joystick speed to gain the apparent responsiveness available with true trackball movement.

 

Under the assumption that some of the intermittent nature of these signals is already able to be detected in an existing game, you might be able to do a quick feasibility test by just making the on-screen player move a lot faster.

 

(It's not true that the output joystick signal would stay high if you stop the trackball moving. The output is turned off if a triggering event isn't received after a given period of time. It doesn't matter what the current, steady state output of the encoder is. It's an ancient, but very interesting bit of circuitry: http://www.electronics-tutorials.ws/waveforms/monostable.html)

Edited November 26, 2015 by BigO

[BigO]

Oh, I just realized something. When I said I caught a 1 ms "pulse", that was wrong. What I was actually seeing was a 1 ms period of time in which the output was inactive during a period of activity. Stupid active low logic tripped me up.

 

The shortest period of active state that I can reliably capture with this trackball is ~9ms.

Edited November 26, 2015 by BigO

[Thomas Jentzsch]

I'm afraid I don't have anything more convincing to offer than actual signals being captured from an actual device at the actual physical point where the signals feed into the console. And, those signals matched my documented predictions that were based on an analysis of the hardware used to generate the signals.

You got me convinced. My original answer was based on not paying attention.

 

What I'm not thoroughly convinced of is that one could meaningfully translate this information in into motion control within the software. I think the two key components are to detect and respond to those short duration events and make the maximum player movement speed faster.

As it is now, faster sampling rate might give the ability to better emulate the partial speed created by a slow roll. But once the trackball outputs 100% active joystick signals, the player speed would need to be faster than normal joystick speed to gain the apparent responsiveness available with true trackball movement.

I would like to see the output when you move slow (and at different speeds). We need to know how many pulses you can generate then. Also if the number of pulses generated is linear to the speed. And how fast you have to spin until the signal becomes steady low.

 

If e.g. very slow generates 1 pulse/frame, medium slow 5 and maximum slow 10, then this would be enough information. This would allow for 12 different speeds (10 different pulses, high, low), which is probably enough for most games.

[BigO]

I'll do some more controlled samples when I get a chance and can figure out a way to get a consistent speed.

 

While we're in the neighborhood, I'll try to explain something about the concept for general purposes.

 

The circuitry enforces a minimum pulse width. No matter how short the triggering event is, the "monostable" will output a pulse of a fixed width. Call that width "x".

If the triggering events are significantly farther apart than width x, the output of the monostable will be a series of pulses of width x, with some time lapsing in between those pulses.

When the triggering events get closer together, those pulses out of the monostable become closer together, but each pulse remains the same fixed width.

When the time separating triggering events shortens so that the next trigger comes in before the monostable has output it's full pulse width, the monostable is "retriggered" from the point in time when the second trigger comes in. The result is that when two triggers come in close together, the output pulses, in effect, overlap so you end up with one wider pulse.

When you spin the ball fast enough, the final output becomes a steady state signal. That solid active signal is what is traditionally detected with a mechanical joystick.

The intermittent signal resulting from a speed below the threshold where the output becomes a solid active signal is the subject of this discussion.

[Lynxpro]

Aren't the JS only trackballs rarer than the normal ones? They might be collectible. (ducks to avoid the oncoming onslaught of thrown bricks)

 

You mean like those [expletive] over in the Facebook "Atari Collectors" group who claimed the Trak-Balls are junk and only worthy of displaying?

[Thomas Jentzsch]

Got you.

 

The code would have to count the gaps between the pulses. That's about the same effort as counting the bit changes in Gray Code.

 

No gaps would mean maximum speed, no pulse at all would mean zero speed.

[Thomas Jentzsch]

You mean like those [expletive] over in the Facebook "Atari Collectors" group who claimed the Trak-Balls are junk and only worthy of displaying?

I hope you got one cheap from those [expletive].

[BigO]

Got you.

 

The code would have to count the gaps between the pulses. That's about the same effort as counting the bit changes in Gray Code.

 

No gaps would mean maximum speed, no pulse at all would mean zero speed.

Yeah, it might make sense to count the "off" time instead of the "on" time.

 

I was thinking of it as always moving full speed when you move, but moving only in those intervals when the signal is active. But, you can only visually relocate the on-screen player once per frame so would need to accumulate readings over a frame to figure out how far to move.

 

In the trackball code, do you count up the number of state changes that occur over a number of samples (per frame?) then calculate a new location for the player?

This would be similar to that, but I think you'd be determining what fraction of the time the signal was on over the sampling period and calculating the new position using that fraction multiplied by the maximum motion allowed per frame. That's my wild guess anyway.

[Andromeda Stardust]

I managed to draw a schematic of the cx80 based on the pictures in this site: http://www.the-liberator.net/site-files/retro-games/hardware/Atari-2600/atari-2600-trak-ball-controller.htm

This was possible because the board is single side, so all traces are on one side and all the components on the other and the pictures are hi-res enough to follow all the connections.

It would be great if someone who owns a cx80 could check if there are errors in the schem and also read the value of the two caps circled in this picture, as the printings on those are covered in all the images I could find.

cx80board.JPG

As you can see, while functionally identical, the CX80 uses a different circuit than the CX22.

cx80_schem.pdf

thank you for posting this photo. I cannot identify the chips on mine without lifting the pcb. This will help immensely when i get home. With family right now. go Cowboys! Flip phone sux.

 

EDIT: I've studied your schematic further. There appears to be an error in the schematic where the outputs of the phototransistors are concerned. It appears both has a 10kohm resistor to ground. But both also has a trace between the outputs connected by dots. This implies the two outputs are shorted together which does not make logical sense.

 

Nonetheless you have confirmed something that I suspected from studying the trackball the other night. That U3 is not a quad comparator like in the first CX-22 schematic posted. I traced the leads from the encoders to the chip but the inputs and outputs did not line up properly. The gray code bits appear to be located at pins 2, 4, 10, and 12 as shown by the PDF doc, not 1, 2, 13, 14 like with the quad comparator suggested. My CX-80 PCB will not lift up from the plastic housing and I am afraid of permanently damaging this fine controller if I pry it off. I would have needed a dental mirror to check the chip IDs from underneath the PCB, which I do not have. I'll try to read you the values off the two caps but no promises. All four ceramic caps have104 (0.1μF) printed on them. Regardless, your photo and schematic saved me much trouble.

 

I also have now in my posession a Sega Sports Pad. The trackball is pretty funky so I'll be opening it up up to clean it out before use, and also attempt to document it. Hopefully the PCB is easier to access than the CX-80. I really want to convert the Sega pad for use as a MAME trackball / USB mouse.

 

Goodnight for now peeps. I need to sleep off my turkey overdose.

Edited November 27, 2015 by stardust4ever

[Thomas Jentzsch]

In the trackball code, do you count up the number of state changes that occur over a number of samples (per frame?) then calculate a new location for the player?

Yup. The changes are counted per frame and usually directly added/subtracted to the player coordinates.

 

This would be similar to that, but I think you'd be determining what fraction of the time the signal was on over the sampling period and calculating the new position using that fraction multiplied by the maximum motion allowed per frame. That's my wild guess anyway.

I don't think we need to sum up the time, because the pulses all have equal width. Therefore simply counting the gaps would be enough. If the result can be used directly or if you have modify it has to be tested.

 

My problem is, that I have no test hardware and Stella does not emulate this too. I could write a simple test program, but someone else would have to test on real hardware.

[alex_79]

[...]

There appears to be an error in the schematic where the outputs of the phototransistors are concerned. It appears both has a 10kohm resistor to ground. But both also has a trace between the outputs connected by dots. This implies the two outputs are shorted together which does not make logical sense.

[...]

All four ceramic caps have104 (0.1μF) printed on them.

[...]

You're absolutely right about the outputs. It was correct in the first had-drawn schematic I did. Since I only drawn one output and then duplicated it, the error was copyed too... Thanks for checking the caps value. Here is a (hopefully) corrected schematic.

cx80_schem.pdf

 

To trace the trackball, I first imported the original photo of the board in gimp and then I drawn over the tracks with different colors and added the components. This is the resulting picture and might be of some use if you want to tap the signals on your unit.

Note that the ICs are drawn mirrored, because the layout match the one on the solder side, while the ICs are on the back. Dotted lines represent jumpers.

Edited November 27, 2015 by alex_79

[Andromeda Stardust]

My problem is, that I have no test hardware and Stella does not emulate this too. I could write a simple test program, but someone else would have to test on real hardware.

Herein lies a big problem with emulating trackballs: Every model of trackball has conditions where L+R or U+D are actuated simultaneously. Both the Stelladaptor and the 2600daptor emulate the cardinal joystick inputs as a Dpad instead of buttons. The four leads from a joystick have 16 possible states but the Dpad has only 9 possible states. (-), (0), and (+) for both axes. Holding down opposite directions creates invalid data input, which depending on how the encoder interprets the data, will either cancel out or one direction will override the other. These 8 directions plus neutral get converted back into four discrete lines of logic in the emulation program, but because invalid combinations are discarded, there is no way to communicate to Stella that opposite directions are simultaneously actuated. The workaround would be to interface the controller to a keyboard or joystick encoder as discrete keys or buttons.

 

Furthermore is the fact that the emulator is not cycle accurate and is not pulling realtime data from the inputs as it is racing the beam. It probably computes the entire frame as quickly as possible before dumping the results to the screen. Most likely the controller input is only updated once per frame even if the USB is polling the controller at a higher refresh rate to minimize lag. Multiple clocks would get discarded.

[Thomas Jentzsch]

It probably computes the entire frame as quickly as possible before dumping the results to the screen. Most likely the controller input is only updated once per frame even if the USB is polling the controller at a higher refresh rate to minimize lag. Multiple clocks would get discarded.

Not sure for USB attached controllers, but Stella emulates the trackball pretty well when using the computer mouse. So it must update the controller input very frequently.

[Andromeda Stardust]

You're absolutely right about the outputs. It was correct in the first had-drawn schematic I did. Since I only drawn one output and then duplicated it, the error was copyed too... Thanks for checking the caps value. Here is a (hopefully) corrected schematic.

cx80_schem.pdf

 

To trace the trackball, I first imported the original photo of the board in gimp and then I drawn over the tracks with different colors and added the components. This is the resulting picture and might be of some use if you want to tap the signals on your unit.

board_cx80_sold_side.png

Note that the ICs are drawn mirrored, because the layout match the one on the solder side, while the ICs are on the back. Dotted lines represent jumpers.

Yeah I'm aware they are mirrored. I think I've got all the information I need now to tap the gray code and send it to an external DB9 header. I may even cut the trace on the right button and wire it to the otherwise unused pin 9. This would effectively disable the right button on Atari standard but enable right click support if I plug it into a trackball encoder. Also if I wanted to be neat I could remove the cable and replace it with a single DB9 female header. I could add a second toggle switch or repurpose the existing switch and use the Genesis chip select (I forget the 74xx series designation for this part offhand but I have some unused in a tube somewhere) to switch between CX-22 and ST modes rather than CX-22 and JS.

[Andromeda Stardust]

Not sure for USB attached controllers, but Stella emulates the trackball pretty well when using the computer mouse. So it must update the controller input very frequently.

I think it just uses the mouse to emulate a trackball set to JS mode. It always bugged me that Stella does that. Maybe the developers could add CX-22 and ST modes to the options in the future to get native trackball support through a desktop USB mouse.

[Thomas Jentzsch]

Hm, my USB mouse works exactly like that. Native trackball that is.

[alex_79]

Stella emulates true trackball modes (cx22, ST and Amiga) using the mouse.
You must set this in the "Game properties" for each rom which needs it.
The 2600-daptor has specific support for the cx22 and cx80 trackball in TB mode and makes them appear as a standard mouse to the PC OS. So stella can use them whenever a standard mouse is supported (which is the above trackball modes, but also paddles and driving controllers).

Basically the adapter recognize the trackball and makes it appear as a PC mouse, then stella reads the PC mouse input (and it doesn't matter if it's an actual mouse or the 2600-daptor simulating one) and generates the appropriate values at the correct cycles on the emulated VCS input ports to emulate a real trackball.

What doesn't work is the direct use of a trackball in trackball mode whit the rom set to use the joystick, because, as stardust4ever said, the usb adapter won't send the correct signals for 'impossible' joystick directions.
Moreover, stella might (I don't know for sure) just update the input once for frame when the controller type is set to joystick which is an acceptable simplification in that case.


I installed a db9 port on a cheap usb pad some years ago so I can use my konix speedking joystick with stella and it doesn't work with a driving controller for the same reason.

Edited November 27, 2015 by alex_79

[BigO]

Yup. The changes are counted per frame and usually directly added/subtracted to the player coordinates.

 

I don't think we need to sum up the time, because the pulses all have equal width. Therefore simply counting the gaps would be enough. If the result can be used directly or if you have modify it has to be tested.

 

My problem is, that I have no test hardware and Stella does not emulate this too. I could write a simple test program, but someone else would have to test on real hardware.

I'm hesitant to commit to that logic having not looked at the output from one of the Atari offerings. It's possible/probable that the pulses could be variable width, depending on hardware setup.

 

This accuball unit uses a microcontroller, so I can't check my assumptions about the hardware functionality on it.

 

I don't do this electronics stuff on a daily basis, so I could be wrong, but I believe that the CX-22 one-shot is retriggerable which means that active state pulses won't be a fixed width. A retrigger in the middle of the a pulse would just start the charge cycle over again from that point, thus yielding a pulse that was something longer than the minimum width and not an even multiple of that minimum width.

 

I can't believe I find myself in need of yet another type of trackball. Maybe I'll dig up the parts and breadboard a CX-22 .

Edited November 27, 2015 by BigO

[+SpiceWare]

Both the Stelladaptor and the 2600daptor emulate the cardinal joystick inputs as a Dpad instead of buttons. The four leads from a joystick have 16 possible states but the Dpad has only 9 possible states. (-), (0), and (+) for both axes. Holding down opposite directions creates invalid data input, which depending on how the encoder interprets the data, will either cancel out or one direction will override the other. These 8 directions plus neutral get converted back into four discrete lines of logic in the emulation program, but because invalid combinations are discarded, there is no way to communicate to Stella that opposite directions are simultaneously actuated. The workaround would be to interface the controller to a keyboard or joystick encoder as discrete keys or buttons.

 

 

Not true, at least for the Stelladaptor connected to a Mac.

 

Test Cart:

 

Starplex connected to Mac Pro via Stelladaptor:

 

All buttons on Starplex held down:

[Andromeda Stardust]

Stella emulates true trackball modes (cx22, ST and Amiga) using the mouse.

You must set this in the "Game properties" for each rom which needs it.

The 2600-daptor has specific support for the cx22 and cx80 trackball in TB mode and makes them appear as a standard mouse to the PC OS. So stella can use them whenever a standard mouse is supported (which is the above trackball modes, but also paddles and driving controllers).

 

Basically the adapter recognize the trackball and makes it appear as a PC mouse, then stella reads the PC mouse input (and it doesn't matter if it's an actual mouse or the 2600-daptor simulating one) and generates the appropriate values at the correct cycles on the emulated VCS input ports to emulate a real trackball.

Dang it. Mine only supports joysticks and paddles. I only got the 2600-daptor I. I knew I should have spent the extra $5 when I bought it.

3/22/13 - new firmware version adds trak-ball support

6/09/13 - updated Amiga mouse

12/01/14 - Mouse (for trak-ball suopport) marked as a "boot mouse" for MIST

This firmware adds what I call mouse mode. You can use a CX22 or CX80 trak-ball (as-well as some other controllers) to move the mouse pointer. While there is a lack of 2600 games for the trak-balls, this can be used with emulators that support mouse input for trak-ball emulation, such as MAME for arcade games like Missile Command, Centipede, Millipede, etc. (Note for MAME: the mouse as to be enabled in the .ini file).

Mouse mode is entered by plugging in the USB with both switches DOWN. The 'daptor will then appear to the computer as a USB HID mouse. Note: sometimes when switching controllers while the USB is plugged in, the computer may reset the USB connection and this could kick the 'daptor out of mouse mode. Avoid this by plugging in the controller you would like to use before connecting the USB.

Once in mouse mode, the switch settings are -

 

Mode Switch 1 (next to USB) Switch 2 Joystick/Paddle UP UP

Use 2600 joystick or paddles to move the mouse pointer. Paddles act as velocity control - speed of mouse pointer is determined by how far the paddle is moved off center. Center paddles to hold mouse stationary. As there are no marks on the paddles, you just have to play with it a bit to find out where center is.

Amiga DOWN UP

Amiga mouse - only button 1 supported.

CX80 UP DOWN

CX80 native mode and ST mouse (2nd button on ST mouse not supported). Also works with the Driving controller, but it's extremely low resolution does *NOT* make it a good spinner for Tempest, Arkanoid, etc. in MAME.

CX22 DOWN DOWN

CX22 native mode.

Note on CX80 - word is there are two verions. One is the true CX80, and other is a repackaged CX22, and there is not a way to visually identify which you have as they look exactly the same. So try CX22 mode if yours is not working with CX80 mode.

 

In other news, I found the logic diagram for the ST Mouse:

Source: http://info-coach.fr/atari/hardware/interfaces.php

 

Just as I suspected. It would be easy enough to reroute the right button signal on the CX-80 to use pin 9 instead of pin 6. 2600-daptor II cannot read the right button on an ST mouse however, and furthermore homebrew games on a 2600 or 7800 would need pullup resistors on pin 9 in order to detect it's presence. See also reading extra button on Genesis controllers. Switching to ST mode also requires flipping the DIP switches on the 2600-daptor after power on, but CX-22 mode can run unmodified, which would make the mod unnecessary unless I really need the extra precision.

 

Here's a hacking diagram I made to convert a "CX-22" CX-80 into an ST Mouse. A female Dsub header can be added to the controller housing for ST mode, which will preserve the original cable thus retaining functionality of the native CX-22 operation. The rewired right button would be disabled unless the cord is replaced as the original cable has no conductor for pin 9. Homebrew ROMs could be designed to read input from pin 9 however. Additionally, pin 9 could be wired into a MAME encoder for two button support. The exact pinout arrangement for pins 1-4 I'm not entirely clear on yet. X axis goes to pins 1-2; Y axis goes to pins 3-4. THIS MOD IS UNTESTED. PROCEED AT YOUR OWN RISK!