Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: How do I read the Joysticks?
Message-ID: <34968@sun.uucp>
Date: Fri, 27-Nov-87 16:27:01 EST
Article-I.D.: sun.34968
Posted: Fri Nov 27 16:27:01 1987
Date-Received: Mon, 30-Nov-87 00:44:13 EST
References: <760@hubcap.UUCP> <816@sdcc18.ucsd.EDU> <2073@umd5.umd.edu> <817@sdcc18.ucsd.EDU>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 53
Keywords: joysticks

In article <817@sdcc18.ucsd.EDU> (John Schultz) writes:
>>I suppose that these people will get what they deserve eventually.
>  Oh, ok.  Why include such a statement?

Because Louis feels strongly about this issue like many others do as well.
If C/A changes the hardware your program and everyone who used your example
will break. They will all bitch at *Commodore* who can them point them at
*you*. You will feel very put upon and irritated and Louis is implying that
this is what someone who suggests such a hack deserves.

>  This tells us nothing new.  I have plenty of written data, but my
>routines are as fast, compact, and efficient as possible.  Any other
>method will be slower, larger, and less efficient (but my mind is
>still open for a better method). 

One thing that you may not have considered here is that the required
speed is not that great (since humans are not that fast.) Thus the 
device driver solution provides more than sufficient speed (although
it is definitely not the fastest method), and Commodore will bend over
backward to keep the machine compatible at this level because it is the
"right thing" to do. If they break it *they* will get what they deserve.

>  I offer solutions, others submit suggestions.  Why not show us your
>solutions?

Learn to identify the difference between a hack and a solution. A solution
is valid for *all* cases by definition. One such case is that the hardware
has changed, your example fails to account for that, thus it is not a 
solution. I'm sure by now Bob Burn's article on how to use the joystick
*in all cases* has reached your site, if not send me mail and I will 
forward you a copy. 

>(Reading joydat is harmless.  If anyone can *prove* otherwise I'm
>all ears [not just hypothetical situations].  If the hardware is
>changed, then will my programs compiled today that access joydat via
>the gameport.device still work?  I seem to have heard somewhere that
>even that device does not follow the so-called rules)

Reading joydat is harmless, but if the hardware changes your program 
and anyone else who used your example will break. This will not be the 
case if you use the gameport device. A simple way to prove this is to
write your own gameport.device that talks to the parallel port (use an
adapter to make your standard joystick out of it). Replace the 
gameport.device with SetFunction() and watch. Programs using the 
device interface continue to work, those useing your hack stop working.
QED.




--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.