Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!think!ames!sdcsvax!ucsdhub!jack!crash!pnet01!haitex
From: haitex@pnet01.cts.com (Wade Bickel)
Newsgroups: comp.sys.amiga
Subject: Re: How do I read the Joysticks?
Message-ID: <2058@crash.cts.com>
Date: Sun, 29-Nov-87 06:36:22 EST
Article-I.D.: crash.2058
Posted: Sun Nov 29 06:36:22 1987
Date-Received: Tue, 1-Dec-87 06:03:45 EST
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon, CA
Lines: 77


  In article <34968@sun.uucp> (Chuck McManis) writes:
>
>  In article  <34968@sun.uucp><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.

      If the information were easily available, accurate, and complete, I
   MIGHT agree with C.M.  Howerver, having had experiance with trying to 
   use the joystick port in a non-standard manner I know that the reality
   of the situation is that to do so you must write your own routines. This
   is not to say that these routines should not use the device library
   if they can, but if this does not work, a non-standard method is the
   only viable solution.  Better device access via the library would 
   eliminate this problem once and for all.

>  >  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.
>  

     When you say "more than sufficient speed", I can see you must not be
   doing much real-time work.  I've seen John's "Lybians in Space" program,
   and I know that he does.  For my work, if I were able to read the port
   20 instructions faster by not using the device driver I would probably
   do so.  The speed savings are probably greater than that, but since the
   device drivers don't work for my application, it's academic.

>  >  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. 
>  

    So where is the device driver solution to this problem?  Using it,
   can you read both joysticks as the original question asker requested?
   One thing about these postings that is very discouraging is the tendancy
   for the original question to go un-answered even though it recieves many
   responses.

   Please forward me a copy of the article you mention.  Having wasted
   weeks messing with this type of problem, I would be very intrested to
   see how you are "supposed" to do it.

>  --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.

	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   						Thanks,

							Wade.


UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM