Trak-Ball Atari 2600 Trak-Ball Games

[Thomas Jentzsch]

No idea then, what's going on. Use the console switches instead.

[BigO]

Regarding the joystick emulation mode:

 

In the hardware, there's a 4538B acting as a "one shot" taking the signal from the decoder and creating a minimum pulse width. It's configured as retriggerable which means that if it gets another pulse prior to the end of the minimum pulse width, it will keep the output active or stretch the pulse by starting the minimum pulse width count again from the point in time that it receives the retriggering pulse. The net result is that until you spin the ball fast enough, the emulated joystick output will be intermittent.

 

Providing a constant up or down signal from a real joystick causes the Harmony menu to sequence through to the next item after a certain amount of time.

There *might* be a sweet spot in the trackball spinning speed that will allow the emulated joystick to be on full time, but still allow you to stop spinning before the menu software moves to the next item.

 

Might be a bit of a herky-jerky experience if you can even manage to get the speed and timing right at all.

If you can make it work, but it looks really ridiculous, please post a video.

Edited November 21, 2015 by BigO

[BigO]

I built up a "CX-22" compatible trackball so will be able to test those hacks, too.

 

I have now had the experience of using the console switches to navigate the Harmony menu. Didn't even know it did that until a couple of days ago. Cool.

Maybe my reset switch is just exceptionally crappy, but the software debouncing there doesn't quite cut it on my machine.

[BigO]

So any feedback regarding the difficulty in Colony 7?

 

Is the doubled speed (left difficulty = A) a good compensation for the better trackball control? Or should we keep the original speed?

The "CX-80" version seems more sensitive than the "CX-22" version. I can play the 80 version pretty well without ever "spinning" the ball. It's nearly all fingertip control, which I like.

 

The CX-22 version requires actively spinning the ball to get across the screen fast enough to catch some of those little rainbow saucers.

 

As a comparison test, I placed my finger on the top center of the ball then rolled the ball until my finger touched the top of the controller, both directions.

80 version moves the pointer well to the left and right of the score, maybe exceeding the edge of the score by about 25% of the score width in each direction.

In the 22 version, the pointer never exceeds the left or right edge of the score. The pointer probably only moves about 80% of the width of the score total in the same amount of ball travel.

 

If anyone actually cares, I can take actual measurements to give you a better feel of the relative sensitivities.

 

(Disclaimer: I don't know if this is relevant for real OEM hardware. I have my CX-53 now spitting out quadrature (ST Mouse) encoded signals and Direction+Clock protocol (CX-22). I'm pretty sure the real hardware will act the same way assuming that Atari used the same mechanical hardware in all the units. But will have to see if anyone has both OEM types.)

Edited November 22, 2015 by BigO

[BigO]

At the moment the code is pretty simple:

 

I am polling all three models in parallel and calculate positions from that. Then I count how far each position has moved away from start (horizontally and vertically). The first model which exceeds a minimum distance in both directions wins. For that distance I found 20-30 pixel to be sufficient, so you don't have to move the track ball a lot for detection.

 

For now, this works on an all blank screen, only the background color changes when the right model is detected. Then you can press fire and the correct version of MCTB starts. Pretty cool.

 

For doing that during a title screen I have to optimize the polling a bit.

I downloaded and ran the detection program you posted. An interesting bit of trivia: if you spin a "CX-80" trackball too fast, it's detected as an Amiga Mouse (green screen).

[Andromeda Stardust]

I have a bug to report on CX-22 Centipede. The other night I fired up the Harmony ROM, and during one of my sessions, I collided with the Spider and possibly also a Centipede fragment simultaneously. I was in the lower middle region of the screen and had initiated a movement rolling the trackball upwards and slightly towards the left (about the 11 O' Clock direction) to avoid the Spider when my ship promptly collided with the enemy sprites. My score was in the 6000 range, still early in the game. Not sure what caused the crash but my CRT screen went totally black and the TIA emmitted a dull low pitch growl sound effect that persisted until I powered off the Atari. Controls were totally unresponsive. I have no means to reproduce this glitch and it was the first such occurance.

 

On other thoughts, why is it that despite Millipede TB being so much more frantic than Centipede, I can reach much higher scores with it? I would have thought my rounds of Centipede would last longer due to fewer enemy sprites and an extra life every 10k points instead of 15k. Anyway great hacks. Please keep up the work.

[Thomas Jentzsch]

An interesting bit of trivia: if you spin a "CX-80" trackball too fast, it's detected as an Amiga Mouse (green screen).

The encoding is close enough that there are pattern which can lead to wrong detects. But I did not know about fast spinning yet.

 

How fast is very fast? The bits are checked every 4th scanline. If you can spin so fast, that the bits change faster than that, then a wrong detection is unavoidable.

[Thomas Jentzsch]

I have a bug to report on CX-22 Centipede. The other night I fired up the Harmony ROM, and during one of my sessions, I collided with the Spider and possibly also a Centipede fragment simultaneously. I was in the lower middle region of the screen and had initiated a movement rolling the trackball upwards and slightly towards the left (about the 11 O' Clock direction) to avoid the Spider when my ship promptly collided with the enemy sprites. My score was in the 6000 range, still early in the game. Not sure what caused the crash but my CRT screen went totally black and the TIA emmitted a dull low pitch growl sound effect that persisted until I powered off the Atari. Controls were totally unresponsive. I have no means to reproduce this glitch and it was the first such occurance.

No clue, but I had to change quite a lot of the game to make the TB work. Please let me know if it happens again and if you can spot any pattern.

[Thomas Jentzsch]

(Disclaimer: I don't know if this is relevant for real OEM hardware. I have my CX-53 now spitting out quadrature (ST Mouse) encoded signals and Direction+Clock protocol (CX-22). I'm pretty sure the real hardware will act the same way assuming that Atari used the same mechanical hardware in all the units. But will have to see if anyone has both OEM types.)

I would like to have such a report too. That would mean a CX22 encoded TB is less sensitive than a CX80 one.

[alex_79]

The "CX-80" version seems more sensitive than the "CX-22" version. I can play the 80 version pretty well without ever "spinning" the ball. It's nearly all fingertip control, which I like.

 

The CX-22 version requires actively spinning the ball to get across the screen fast enough to catch some of those little rainbow saucers.

 

As a comparison test, I placed my finger on the top center of the ball then rolled the ball until my finger touched the top of the controller, both directions.

80 version moves the pointer well to the left and right of the score, maybe exceeding the edge of the score by about 25% of the score width in each direction.

In the 22 version, the pointer never exceeds the left or right edge of the score. The pointer probably only moves about 80% of the width of the score total in the same amount of ball travel.

Never thought about this before, but I think that is the expected behaviour:

 

For each axis, the encoder produces 2 square waves in quadrature (A and B). The phase shift is positive or negative depending on the direction of motion. These are the signals used in case of a ST mouse compatible trackball.

The atari trackball (cx22) replaces one of the two waves with a continuous direction signal, while sends the other one unaltered as a clock pulse.

Therefore the cx22 produces half the state changes compared to a ST mouse when the ball is moving at the same speed.

 

Edited November 22, 2015 by alex_79

[Thomas Jentzsch]

So what does that mean to the hacks? Should we double the response to CX22 movement? Or cut in half the response for CX80/Amiga mouse?

Edited November 22, 2015 by Thomas Jentzsch

[alex_79]

I think the only way to decide is to have more people try the various versions and posting their feedback, including the exact model of trackball/mouse used. Anyway, after playing for a while you probably get accostumed to the sensitivity of the controller you are using, so adjusting the speed might not be necessary after all...

To complicate things, what said in my previous post applies to trackballs with the same mechanic characteristics (ball-roller diameter ratio and number of holes in the encoder wheel). For example, a CX80 acting as a ST mouse will have double the speed compared to a CX80 acting as a CX22, because only the wiring differs between the two. But what about third-party ST/Amiga trackballs and mice? Some test would be needed to measure sensivity of the most common models.

Without taking apart the controllers, an empirical method could be to slide a ruler over the trackball for a determined distance and see how far the cursor move on the screen. A test rom displaying numerical values for the movement would make things easier.

[Thomas Jentzsch]

I have an Alfa Data trackball which is switchable between Atari (CX80) and Amiga. There the resolution is identical. But that's no reference.

[BigO]

Never thought about this before, but I think that is the expected behaviour:

 

For each axis, the encoder produces 2 square waves in quadrature (A and B). The phase shift is positive or negative depending on the direction of motion. These are the signals used in case of a ST mouse compatible trackball.

The atari trackball (cx22) replaces one of the two waves with a continuous direction signal, while sends the other one unaltered as a clock pulse.

Therefore the cx22 produces half the state changes compared to a ST mouse when the ball is moving at the same speed.

 

cx22_schem.jpg

tb_waves.jpg

Agreed. I have attempted previously and failed completely at conveying this distinction.

 

You only get half the number of state changes because the state changes from only one sensor are passed through.

 

From the perspective of hardware decoding quadrature signals, I had to put together this diagram to help me make sense of it. It's pretty much the same information that Alex_79 posted.

Once you see it, it makes sense. The "Direction + Clock" (CX-22) protocol is a decoded version of the quadrature encoded signals (Amiga Mouse) that are inherent in the hardware.

 

Edited November 22, 2015 by BigO

[BigO]

So what does that mean to the hacks? Should we double the response to CX22 movement? Or cut in half the response for CX80/Amiga mouse?

Beats me. I like the quick AM version. But, I suspect that the CX-22 flavor is more the intended functionality and is more true to the arcade originals.

I haven't played an arcade trackball game and would value the opinion of those who have.

Edited November 22, 2015 by BigO

[Lynxpro]

At least the situation is clear for the Amiga mouse.

 

I'm not flaming here because the Amiga was designed mostly by ex-Atari people and it was a very powerful platform but why would anyone want to use an Amiga mouse? That thing was really unergonomic compared to the ST mouse. Perhaps the buttons are more responsive for gaming vs the clicky nature of the ST Mouse's buttons.

[Andromeda Stardust]

No clue, but I had to change quite a lot of the game to make the TB work. Please let me know if it happens again and if you can spot any pattern.

I will let you know if I encounter another crash. Could have been just a fluke though.

 

Never thought about this before, but I think that is the expected behaviour:

 

For each axis, the encoder produces 2 square waves in quadrature (A and B). The phase shift is positive or negative depending on the direction of motion. These are the signals used in case of a ST mouse compatible trackball.

The atari trackball (cx22) replaces one of the two waves with a continuous direction signal, while sends the other one unaltered as a clock pulse.

Therefore the cx22 produces half the state changes compared to a ST mouse when the ball is moving at the same speed.

 

cx22_schem.jpg

tb_waves.jpg

While I have no experience with the "CX-80" encoded ROMs, the response of my "CX-80" (CX-22) trackball feels quite solid. If you doubled the sensitivity of the game, I think it would risk becomig too "twitchy". Already I find it easy to crash my ship into the spider or 'pede just by barely rotating the ball. Increasing the sensitivity might cause the ball to rapidly jettison your character across the screen. That's one reason why I downgraded the paddles in my custom joystick to 470/500 kohm pots instead of 1meg. No game I'm aware uses more than half the travel, and many games felt so twitchy as it was. Lowering the sensitivity really helped. However, while Centipede/Millipede hacks need the precision movement due to evasion of enemy sprites, I feel the Missile Command or Colony 7 hacks could actually benefit from faster travel so that the target sight can reach the missiles more quickly.

 

And yes, there may be wide variation between varying models of mouse / trackball depending on the diameter of the ball, diameter of the rollers, and tooth count of the optical encoding wheel.

 

Overall sensitivity could be expressed as:

 

P = (π * RD) / (C * TC)

 

where P= Pitch, C = clocks per tooth, RD = Roller Diameter, and TC = Tooth Count.

 

Trackball diameter doesn't really influence the sensitivity so much as it affects the overall feel of the trackball, with larger or denser trackballs creating more rotational inertia and a more solid feel to the controller. Sensitivity or speed is inversely proportional to pitch, or the surface distance the trackball must be rotated to register an input. Higher sensitivity or smaller pitch results in tighter spacing between inputs.

 

CX-22 encoding is coarser by design than CX-80 or true gray code because with CX-22, there are 2 clocks per tooth, whereas CX-80 encoding, 4 clocks per tooth exist. The logical output for CX-22 is coarser because it omits one of the gray code channels from the output.

 

@Alex_79, thanks for the schematic for the CX-22 encoder. If someone could tell me where to tap the circuit board for the pulse traces, I would like to mod my "CX-80" by adding a 9-pin female header to the base of the controller so I can use it with "CX-80" ROMs via extension cable, or possibly make an adapter to interface it with a MAME compatible USB trackball encoder. I assume the comparator outputs would be a good place to cource the gray code signal.

[BigO]

Beats me. I like the quick AM version. But, I suspect that the CX-22 flavor is more the intended functionality and is more true to the arcade originals.

I haven't played an arcade trackball game and would value the opinion of those who have.

Sorry, I meant the ST mouse version. I haven't built the adapter to test the Amiga Mouse version. (I assume it's exactly the sensitivity, but will test on my hardware when I get time to build the cable.)

[BigO]

@ Big-O, thanks for the schematic for the CX-22 encoder.

alex_79 posted the schematic.

Edited November 22, 2015 by BigO

[Andromeda Stardust]

alex_79 posted the schematic.

Whoops!

[BigO]

The encoding is close enough that there are pattern which can lead to wrong detects. But I did not know about fast spinning yet.

 

How fast is very fast? The bits are checked every 4th scanline. If you can spin so fast, that the bits change faster than that, then a wrong detection is unavoidable.

It wasn't a monumental effort like "here's the fastest I can spin the ball", just a good solid spin. And it seems like if it's going to catch the CX-80 encoding, it does it right away. It's a longer time into the process of a fast spin when it detects Amiga Mouse.

 

Based on your comment about this mode in your trackball, you might not be able to spin the ball fast enough to induce the error on your hardware.

 

Of course, it remains to be seen if my hardware is representative of the OEM hardware, but I think it probably is. If we can get some more input from other users, maybe we can come up with a bit more objective measure of the sensitivity and come up with a consensus of how sensitive a game should be. I tend to like them on the twitchy side.

 

I played Colony 7 some more with the cx22 version. I can play it almost as well as the cx80 version, but I feel a lot more stressed out while doing it.

Edited November 22, 2015 by BigO

[BigO]

If someone could tell me where to tap the circuit board for the pulse traces, I would like to mod my "CX-80" by adding a 9-pin female header to the base of the controller so I can use it with "CX-80" ROMs via extension cable, or possibly make an adapter to interface it with a MAME compatible USB trackball encoder. I assume the comparator outputs would be a good place to cource the gray code signal.

Yes, the comparator outputs are what you want. According to the schematic, the op-amp is an LM339: output pins 1,2 = x-axis outputs, output pins 13,14=y-axis.

 

Not having a CX80, I can only suggest picking up those signals directly at the IC pin pads.

Edited November 23, 2015 by BigO

[Andromeda Stardust]

Yes, the comparator outputs are what you want. According to the schematic, the op-amp is an LM339: output pins 1,2 = x-axis outputs, output pins 13,14=y-axis.

 

Not having a CX80, I can only suggest picking up those signals directly at the IC pin pads.

I'll check it out when my 8-ball arrives in the mail. I'm going to add a 9-pin female Dsub to the exterior of the case for use with an Atari/Genesis extension cable. I'm assumng I can wire pins 1,2,3,4 straight from the comparator IC and wire pins 6,7,8 to the cable inputs? I don't have a logic analyzer to use so I'll need some way to make sure I wire it up right the first time. I don't want to wire my trackball up backwards.

[Lynxpro]

This probably isn't the right thread for this but what are the chances a Sega Sports Pad could be modded to export gray code?

[BigO]

I'll check it out when my 8-ball arrives in the mail. I'm going to add a 9-pin female Dsub to the exterior of the case for use with an Atari/Genesis extension cable. I'm assumng I can wire pins 1,2,3,4 straight from the comparator IC and wire pins 6,7,8 to the cable inputs? I don't have a logic analyzer to use so I'll need some way to make sure I wire it up right the first time. I don't want to wire my trackball up backwards.

Nothing to worry about if you wire up the first 4 pins in the wrong order. It will just act wonky or not work at all. As far as the console is concerned they're just regular old data inputs. Won't damage anything.

 

1,2 on the 9 pin are the horizontal axis, 3,4 are the vertical. If you get that much right then the worse that will happen is it will move the opposite direction.

You could study the schematics to death and get the wires right the first time, but it'd be faster to try it out and fix it if it's wrong.

 

Yep: 6,7,8 (Fire, +5v, Gnd) should be hooked up straight from the same sources that feed them to the existing cable.