Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utcsri!gclark
From: gclark@utcsri.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: gameport woes (please Paula respond)
Message-ID: <4853@utcsri.UUCP>
Date: Mon, 1-Jun-87 14:10:07 EDT
Article-I.D.: utcsri.4853
Posted: Mon Jun  1 14:10:07 1987
Date-Received: Tue, 2-Jun-87 01:31:37 EDT
References: <430@milob.UUCP>
Reply-To: gclark@utcsri.UUCP (Graeme Clark)
Organization: CSRI, University of Toronto
Lines: 22
Summary: 

(Forgive this posting - I couldn't find a mail path)
>hi, this is my first posting so please forgive if i violate any customs.
I can't think of any, except that it would be helpful for you to include
your email address at the end of the posting (consult local gurus to find
this).
>reading the hardware manual i am led to believe that i can write to POTGO
>and by doing this redefine the function of the pot pins, thereby having
>two I/O pins for my use(just the right port). i have tried this directly,
>allocating resources, Disable/Enable, and Forbid/Permit with no results,
>the signals on the pins just stay where they were before(other than a spike
>at times). the only way i have been able to get the signals to work is by 
>a tight loop, which doesn't seem to be what the manual infers. 
>	what am i missing??
I had this problem too.  You must use the WritePotgo routine (described in
the RKM) to set and reset the PotGo bits.  I think that if you write to them
directly then they will be reset to their previous values whenever any other
task calls WritePotGo (e.g. Intuition talking to the mouse).  If this doesn't
solve your problem, then I'll send you some sample code.

Graeme Clark -- Dept. of Computer Science, Univ. of Toronto, Canada M5S 1A4
old: {allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsri!gclark
new: gclark@utcsri.toronto.edu