Reading the Trackball

[Happy_Dude]

How?

 

Thank you

[vdub_bobby]

I think the [stella] archives have some stuff about this.

 

EDIT: Go here: http://atari2600.org/pipermail/stella/

and search.

 

EDIT II: If you can find the source for Thomas Jentzsch's Missile Command Trackball Hack then you can see how he did it.

Edited June 2, 2006 by vdub_bobby

[Happy_Dude]

Yes I'v done that but all I found was TJ's Missile Command code.

I'v been digging through it since yesterday and was just hoping someone could

post the Trackball stuff minus everything else.

 

I'll get it working either way I'd just rather ask for help and get rejected than not ask and

waste some time that I didn't need to.

[Thomas Jentzsch]

Yes I'v done that but all I found was TJ's Missile Command code.

I'v been digging through it since yesterday and was just hoping someone could post the Trackball stuff minus everything else.

Basically reading the Trakball is exactly like reading the Driving Controllers. Just on two axes and waaay more often.

[Happy_Dude]

You make it sound so easy

[djmips]

The trackball is type of controller that uses a quadrature encoder. This type of encoding is also used in the driving controller and mechanical mice.

 

There's code floating around to read various types of quadrature encoders including Atari and Amiga Mice (see Bob Colberts Stella Sketch for instance)

 

The basic idea is to have a sensor mounted on a rotating shaft to detect it's motion. If you've seen inside a mechanical mouse, you can see that this is done by passing a wheel with slot through a beam of light. The slots interrupt the light and generate an on/off state.

 

With one detector you only know that the shaft is turning and can deterimine it's speed. If however you place a second wheel / sensor that where the slots are 90 degrees out of phase with the first wheel/sensor you will be able to determine the direction by the order in which the two sets of signals go on/off.

 

There are four states 00 01 11 10 (this is where the quad in quadtrature is derived) and then it repeats. If the states happen in reverse order then the shaft is turning the other direction.

 

The output is also known as a 2 bit Gray code. A Gray code is a binary sequence where only one bit changes per change in state.

 

In the assembler listings I have seen it appears that the CX80 trackball follows the standard sequence I have listed above. However, it appears that Thomas was having some issues with the CX22 because there are several attempts at tables and the final version is very odd at 10 00 00 10 which only has a one bit encoding! Perhaps Thomas can enlighten us?

 

BTW a third signal is sometimes provided which gives an absolute reference for when the shaft passes the 'zero' point.

 

Here's the Missle command trackball source in question. It appears to also support building for mice.

 

http://www.atariage.com/pipermail/stella/2...ber/019265.html

 

For me it's attached as Missle_TC_1.2.obj but just rename it to .asm

[Thomas Jentzsch]

However, it appears that Thomas was having some issues with the CX22 because there are several attempts at tables and the final version is very odd at 10 00 00 10 which only has a one bit encoding! Perhaps Thomas can enlighten us?

Honestly, I can't remember exactly what I did back then, but I remember having some slight problems with CX22. And I am sure it's not just one bit encoding, just because it couldn't work at all.

 

Below the table for CX22, there is long comment with logical operations which should explain how it works.

[djmips]

However, it appears that Thomas was having some issues with the CX22 because there are several attempts at tables and the final version is very odd at 10 00 00 10 which only has a one bit encoding! Perhaps Thomas can enlighten us?

Honestly, I can't remember exactly what I did back then, but I remember having some slight problems with CX22. And I am sure it's not just one bit encoding, just because it couldn't work at all.

 

Below the table for CX22, there is long comment with logical operations which should explain how it works.

 

I couldn't understand from your comments and code exactly what you were doing. It's also a problem of conditional assembly which makes it hard to follow what is going on.

 

I tried to find out more information about the CX22 elsewhere. I looks like the CX22 has the direction of motion decoded in the hardware. The direction is output in one bit and the other bit is the pulses to give you the speed.

 

AtariAge has a schematic.

[Thomas Jentzsch]

I looks like the CX22 has the direction of motion decoded in the hardware. The direction is output in one bit and the other bit is the pulses to give you the speed.

That's about true (IIRC). Still you need two bits to determine movement exactly. And for programming it really doesn't matter, as long as you use the correct table. Everything else is 100% identical in my code.

[Gorf]

I got the CX-22 to read on the Jaguar. It seems to give me 00 and 11 one way and 00 and 01 the other way. IT seems to work quite smoothy, but again Im using the DSP and reading it several 100 times a frame.

 

I know it's ben awhile since this thread was active but I can post that table if you like.

I doubt the code would help you at all as it is DSP assembly.

Edited April 6, 2007 by Gorf