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