rchampe@hubcap.UUCP (Richard Champeaux) (11/24/87)
I'm trying to read both joysticks for some games I want to write. I know I should go through Intuition but the manuals say that I'll have trouble getting control of port 1 from the input device, so I want to try to read straight from the registers. I remember seeing some messages a couple of weeks back about how to do this, but I didn't save them. Could someone please send me some email with information? Thanks in advance. Rich Champeaux Clemson University
cs162ffl@sdcc18.UUCP (11/25/87)
Here is a simple joystick routine in Modula-2.
When operating on the BITSET type "*" is the same as
"&" (AND) in C, and "/" is the same as "^" (XOR) in C.
For more info, refer to the Hardware Manual, Appendix_A page 13.
IMPLEMENTATION MODULE joystick;
TYPE
bitsetptr = POINTER TO BITSET;
VAR
buttonloc : POINTER TO SET OF [0..7];
joydat : ARRAY[0..1] OF bitsetptr;
PROCEDURE readjoystick(VAR x,y : INTEGER;
VAR buttonpressed : BOOLEAN;
port : CARDINAL);
BEGIN
x := CARDINAL(BITSET(CARDINAL(joydat[port]^) DIV 2) * BITSET(1)) -
CARDINAL(BITSET(CARDINAL(joydat[port]^) DIV 512) * BITSET(1));
y := CARDINAL(BITSET(CARDINAL(BITSET(CARDINAL(joydat[port]^) * 2)
/ joydat[port]^) DIV 2)
* BITSET(1)) -
CARDINAL(BITSET(CARDINAL(BITSET(CARDINAL(joydat[port]^) * 2)
/ joydat[port]^) DIV 512)
* BITSET(1));
buttonpressed := NOT((6+port) IN buttonloc^);
END readjoystick;
BEGIN
buttonloc := ADDRESS(0BFE001H);
joydat[0] := bitsetptr(0DFF00AH);
joydat[1] := bitsetptr(0DFF00CH);
END joystick.
In C:
x = (((*joydat[port]) >> 1) & 1) - (((*joydat[port]) >> 9) & 1);
y = (((*joydat[port]) << 1) ^ (*joydat[port])) >> 1) & 1) -
(((*joydat[port]) << 1) ^ (*joydat[port])) >> 9) & 1));
buttonpressed = 1 - (((*buttonloc) >> (6 + port)) & 1);
>>Haven't tested this C fragment as I don't have (or use) a C compiler<<
(M2: Was using TDI, now Benchmark from Oxxi...)
In both versions: x: left = -1, right = 1. y: up = -1, down = 1,
buttonpressed = 1 (TRUE). If the stick is centered, x and y return
0, if the button is not pressed returns 0 (FALSE).
Hope this helps.
Johnlouie@trantor.umd.edu (Louis A. Mamakos) (11/25/87)
In article <816@sdcc18.ucsd.EDU> cs162ffl@sdcc18.ucsd.edu.UUCP (John Schultz) writes: > Here is a simple joystick routine in Modula-2. > For more info, refer to the Hardware Manual, Appendix_A page 13. > buttonloc := ADDRESS(0BFE001H); > joydat[0] := bitsetptr(0DFF00AH); > joydat[1] := bitsetptr(0DFF00CH); > Hope this helps. > John This type of thing is NOT what the hardware manual is for. There are defined, supported ways to this sort of stuff which will continue to work on newer models of the hardware (if/when they come out). 'cmon guys, this ain't no Apple II or C-64 where we go PEEKing and POOKing at random places in memory. We should all consider ourselves fortunate that the A500 and A2000 are real hardware compatible with the A1000. I wonder how many games, etc have hacks like this in 'em? I suppose that these people will get what they deserve eventually. John Schultz: I suggest that you get a copy of the devices and libraries or any of a number of very good books out there. You'll find the proper way to diddle the joysticks/mice without confusing other applications that might happen to be running on your amiga at the time, and that are portable to newer Amiga products that might be available in the future. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
cs162ffl@sdcc18.ucsd.EDU (John Schultz) (11/25/87)
In article <2073@umd5.umd.edu> louie@trantor.umd.edu (Louis A. Mamakos) writes: >In article <816@sdcc18.ucsd.EDU> cs162ffl@sdcc18.ucsd.edu.UUCP (John Schultz) writes: > >> Here is a simple joystick routine in Modula-2. >c'mon guys, this ain't no >Apple II or C-64 where we go PEEKing and POOKing at random places in memory. The information I offered does the equivalent of a PEEK. No POOKs (or POKES for that matter). >I suppose that these people will get what they deserve eventually. Oh, ok. Why include such a statement? > >John Schultz: I suggest that you get a copy of the devices and libraries >or any of a number of very good books out there. You'll find the proper way >to diddle the joysticks/mice without confusing other applications that might >happen to be running on your amiga at the time, and that are portable to newer >Amiga products that might be available in the future. > 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). > >Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU >University of Maryland, Computer Science Center - Systems Programming I offer solutions, others submit suggestions. Why not show us your solutions? John (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)
rchampe@hubcap.UUCP (11/26/87)
In article <2073@umd5.umd.edu>, louie@trantor.umd.edu (Louis A. Mamakos) writes: > > This type of thing is NOT what the hardware manual is for. There are defined, > supported ways to this sort of stuff which will continue to work on newer > models of the hardware (if/when they come out). 'cmon guys, this ain't no > Apple II or C-64 where we go PEEKing and POOKing at random places in memory. > > John Schultz: I suggest that you get a copy of the devices and libraries > or any of a number of very good books out there. You'll find the proper way > to diddle the joysticks/mice without confusing other applications that might > happen to be running on your amiga at the time, and that are portable to newer > Amiga products that might be available in the future. > > > Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU > University of Maryland, Computer Science Center - Systems Programming Louis, I'm the one who requested the information about reading the joysticks. I did read the ROM Kernal and it says on the first page of the chapter on the gameport device: When the input device is operating, the left gameport connector is usually dedicated to that device. Therefore, this chapter's examples concentrate on the right connector, which is not dedicated to the input device. Note that if the input device is not started, the left connector, as gameport unit 0, can perform the same functions as shown below for the right connecter. To me, this says that unless your planning to take over the computer from intuition, you won't be able to use the left joystick. And if there is a way, it sounds like it'd take a hell of a lot of complicated code. Now, all I'm planning to do, is write a few games and in the process, learn more about programming on the amiga. None of these games will ever be sold, nor will they probably even be worthy to put out on public domain. I agree that sold programs should not use these shortcuts, but I see no problem taking shortcuts in programs for my own use, which I don't plan to distribute. As far as I concerned, if it saves me coding and debugging time, I'm all for it. After all, I'm only hacking. P.S. Thank you John Schultz, for your help. It was much appreciated. Rich Champeaux Clemson University
cmcmanis%pepper@Sun.COM (Chuck McManis) (11/28/87)
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.
cs162ffl@sdcc18.ucsd.EDU (John Schultz) (11/28/87)
Bueno, I'll use the "proper" methods as described in the joystick examples from Bob Burns (thanks, Chuck). Pero un mas pregunta, por favor Amig(a/o)s. Where does the gameport.device get the addresses it needs and when? Compile time or run time? John
peter@sugar.UUCP (Peter da Silva) (11/28/87)
Well, using the technique suggested by kodiak@amiga.UUCP (Robert R. Burns), I have successfully grabbed the mouse port, used it, and given it back. Now the problem is that when I try to do it again it doesn't work. Total mouse lockup. Not only do I do a IND_SETMPORT and a IND_SETMTYPE, but I also do a GPD_ASKTRIGGER ahead of time so I can do a IND_SETMTRIG. Doesn't help. Do I have to completely close the gameport before I give the port back to intuition, and open it again after I steal it teh second time? That's what I'm going to try next... -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
haitex@pnet01.cts.com (Wade Bickel) (11/29/87)
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
peter@sugar.UUCP (11/30/87)
cs162ffl@sdcc18.ucsd.EDU (John Schultz) writes: > (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) Even if gameport.device doesn't follow the rules (what rules would those be? It's a low-level device driver), any new hardware will come with a new version of gameport.device. That's what the device is *for*. That's what the rules are, basically. Use as high-level an interface as you can. That's why it's a bad idea to go to the hardware directly. If everyone uses gameport.device, then there's only one place that has to be changed. As for speed, I'm working on a video game. On the Amiga. I'm doing EVERYTHING through the high level drivers. I still haven't seen ANY perceptible slowdown no matter how fast I run the game. I've cranked it up so fast it's totally unplayable, and I've still got gobs of CPU time available. The Amiga is a fast enough machine you don't need to PEEK, POKE, and POOK 99% of the time. And even if you do, do it as a last resort. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
rap@dana.UUCP (Rob Peck) (11/30/87)
In article <764@hubcap.UUCP>, rchampe@hubcap.UUCP (Richard Champeaux) writes: > > Louis, > I'm the one who requested the information about reading the joysticks. > I did read the ROM Kernal and it says on the first page of the chapter > on the gameport device: > > When the input device is operating, the left gameport connector is > usually dedicated to that device. Therefore, this chapter's examples > concentrate on the right connector, which is not dedicated to the > input device. Note that if the input device is not started, the left > connector, as gameport unit 0, can perform the same functions as shown > below for the right connecter. As Bob Burns has noted in his recent posting, there was indeed a bug in the 1.1 code that, as I recall, was capable of causing a guru if you tried to use a joystick in place of a mouse as far as Intuition was concerned. Stating it this way made it more of an "unsupported feature" rather than an "interesting bug". This part of the manual was, after all, written for the 1.1 RKM. The code was already frozen by the time this was discovered but the manuals lagged behind the code release a while. Bob Burns (Kodiak) code should help those who need it though. I know I've saved it for future reference. Rob Peck ...ihnp4!hplabs!dana!rap
karl@sugar.UUCP (Karl Lehenbauer) (12/02/87)
In article <2058@crash.cts.com>, haitex@pnet01.cts.com (Wade Bickel) writes: > 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. It is widely agreed, from much study of code, that 5% of one's code is responsible for 95% of the execution time. It would be a bummer to discover that your hacked out, badly behaved joystick code made no significant improvement in the performance of your game because all the major time was being burned in some other part of your program. Further, you presumably could have used the time spent writing the fast joystick code more effectively by instead identifying and speeding up that critical 5%, leaving you with a faster game that doesn't break with new releases of the operating system. --+'
haitex@pnet01.UUCP (12/03/87)
karl@sugar.UUCP (Karl Lehenbauer) writes: >It is widely agreed, from much study of code, that 5% of one's code is >responsible for 95% of the execution time. It would be a bummer to discover >that your hacked out, badly behaved joystick code made no significant >improvement in the performance of your game because all the major time was >being burned in some other part of your program. Further, you presumably >could have used the time spent writing the fast joystick code more >effectively by instead identifying and speeding up that critical 5%, >leaving you with a faster game that doesn't break with new releases of >the operating system. >-- Please understand that I am NOT in favor of bypassing the Device Driver. However, I could not get it to work reliably for me. Now that I have the Bob Burns' article I will (when time permits) go back and try to re-write my routines. Have you written code that writes to pin 5 of the joystick port? From interrupts? I suspect that it is possible to use the Device Driver to do this, but my attempts failed. The time that I wasted were the hours spent trying to use the Device Driver, not the half hour it took me to write my own driver based upon data readily available in the appendix of the hardware manule. Also, your figures regaurding how processing time is distrubuted are based upon the average program, most of which are not really optimised for speed, many not being optimised in any way at all. If you were to limit your study to real-time programs I think you would find the numbers very different. Over the last few weeks, in the discussion of M2Amiga's linker and how it does not use interface code ("stubs") to make calls to the ROM routines, people seemed to feel that the speed savings are negligable because the interface code represents a relatively small amount of the called routines total execution time. However, I call some of these routines VERY many times to generate a display. If the stub requires only 3 instruction cycles, this could mean hundreds of cycles in a given display generation. In general, I feel that using High Level access to the hardware is worth added access time, within reason. However, THIS IS A GRAPHICS PROCESSING MACHINE, and to generate animated displays requires great attention to speed at all times! Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
cs162ffl@sdcc18.UUCP (12/05/87)
>AchoOO ==-*
Ring. Ring. Ring.
Uh, hello?
Yeah, I'm using the gameport device. Right. Ok. Yeah, got it.
Ok. Bye.
Click.