Newsgroups: comp.sys.atari.8bit
Path: utzoo!utgpu!watserv1!maytag!watdragon!trillium!rbharding
From: rbharding@trillium.uwaterloo.ca (Ron Harding)
Subject: Re: mouse
Message-ID: <1990Jun1.184907.19810@watdragon.waterloo.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
References: <1369@lectroid.sw.stratus.com> <1990May22.161958.11370@watdragon.waterloo.edu> <30251@cup.portal.com> <1990May30.024523.4608@ccu.umanitoba.ca>
Distribution: na
Date: Fri, 1 Jun 90 18:49:07 GMT
Lines: 56

In article <1990May30.024523.4608@ccu.umanitoba.ca> umhild11@ccu.umanitoba.ca (Jeff Hildebrand) writes:
>In article <30251@cup.portal.com> Chris_F_Chiesa@cup.portal.com writes:
>>In a recent article, rbharding@trillium.uwaterloo.edu (Ron Harding) writes:
>> 
>>>     As a matter of fact, the Commodore Amiga mouse will plug into the
>>> Atari (or C64) joystick ports.  I wrote a program a while back to read it.
>>> Unfortunately, the program uses a tight polling loop.  I haven't come up with
>>> a hardware-free way to put a mouse driver in the background on a VBI or
>>> anything nice like that.
>>
>>Now THAT's INTERESTING!  I'm curious as to the nature of the difficulty
>>you're having putting the mouse driver in a VBI.  If you're able to read it 
>>at all, I'd think putting it into a VBI would be only a side issue.  If 
>>you simply require help setting this up, perhaps I could help -- I KNOW I'd
>>be INTERESTED in the project.  On the other hand, if there's something about
>>the hardware (as you seem to be saying), tell us what it is and perhaps 
>>someone here can brainstorm a solution for you!
>>
>Actually, I wrote a driver for the Atari Trakball once. The routine would work
>perfectly if it was a polling loop (check the port, move, check the port, etc),
>but if I put it in a VBI, it just didn't check often enough to get the changes.

    I haven't tried it, but that is exactly the problem I expected.

>Hmm, from what I read in another message, the Trakball may work somewhat
>differently from the mice. I didn't get any docs (to speak of) with my Trakball,
>so I had to figure out what the values meant on my own. As near as I could
>determine (and this method worked great) one bit gave direction (up/down, or
>left/right) and another gave its frequency. Every time the frequency bit
>changed, I knew that I had to move the marker in the direction specified by the
>direction bit. (that may not be very clear, there are two pairs, one for
>vertical movement, and another for horizontal.) From what I understood of the
>workings of the mice (mouses? what DO they call them in the computer world?)
>this is a slightly different method. Perhaps periodic polling could work with
>the Amiga mouse.
>
>For anyone who is interested, I tried my driver with an ST mouse, and it didn't
>work worth a damn, so either the pins or the philosophy is different.
>
>Jeff Hildebrand

    I dunno.  You're explanation of the Trakball seems more or less 
equivalent to my previous description of the mice I've seen.

    I do recall that the Atari Trakball has a switch on the back to choose
either joystick or trackball mode.  Anyone know exactly what this switch
does?

    What would be real interesting is Trakball schematics.  Anyone have
any?  I seem to recall some real electronics in there from when I took one
apart many years ago.  Unlike the purely mechanical Amiga and Microsoft mice.

=============================================================================
Ron Harding                      | Nuke'Em:  Get them before they get you!
rbharding@trillium.uwaterloo.edu | Another quality home game from Butler Bros
=============================================================================