Here are the nybble sequences that the driving controller generates during
rotation.
RotatingLeft
1100
1101 *
1111
1110 *
RotatingRight
1100
1110 *
1111
1101 *
* points of differences in the two tables
Since the points of differences are every other point in the rotation
sequence, the only way to determine direction is to match previous and
current values of the controller against both tables, assuming there will
never be a skip between reads.
Aside from the scanning approach I did, I can think of possibly doing a
SWITCH/CASE like approach like so (in Pcode)
switch (previous_state)
case 1100
if (currentstate == 1101) then turning left
elseif (currentstate == 1110) then turning right
else EXIT
case 1101
if (currentstate == 1111) then turning left
elseif (currentstate == 1100) then turning right
else EXIT
case 1111
if (currentstate == 1101) then turning left
elseif (currentstate == 1110) then turning right
else EXIT
case 1110
if (currentstate == 1100) then turning left
elseif (currentstate == 1111) then turning right
else EXIT
defaultcase
EXIT
This would probably be faster. Don't know how the ROM usage would
compare. What do you guys think?
BTW, as Bob Colbert demonstrated, you can read a trackball in trackball
mode on the 2600. I'd be interested to know, however, how fast you can
glide the ball before the 1/60th of a second reads are insufficient. I
would assume that even the Atari trackballs were higher resolution than the
driving controllers, but maybe they are the same. I'll have to dig up my
CX-80 trackball and test this code on one axis to see. It would be
interesting to see Missile Command get modified for trackball mode ;)
Glenn Saunders - Producer - Cyberpunks Entertainment
Personal homepage: http://www.geocities.com/Hollywood/1698
Cyberpunks Entertainment: http://cyberpunks.uni.cc
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
