Gameport Device - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:32:20Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:32, 26 January 2025
Line 61:		Line 61:
	The I/O request used by the gameport device is called IOStdReq.		The I/O request used by the gameport device is called IOStdReq.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct IOStdReq		struct IOStdReq
	{		{
Line 212:		Line 212:
	The information needed for gameport trigger setting is placed into a GamePortTrigger data structure which is defined in the include file devices/gameport.h.		The information needed for gameport trigger setting is placed into a GamePortTrigger data structure which is defined in the include file devices/gameport.h.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct GamePortTrigger		struct GamePortTrigger
	{		{

Steven Solie: /* Gameport Device Commands and Functions */

2013-04-04T23:33:42Z

Gameport Device Commands and Functions

← Older revision		Revision as of 23:33, 4 April 2013
Line 53:		Line 53:
	\|}		\|}

		⚫	{{Note\|title=Who Runs The Mouse?\|text=When the input device or Intution is operating, unit 0 is usually dedicated to gathering mouse events. The input device uses the gameport device to read the mouse events. (For applications that take over the machine without starting up the input device or Intuition, unit 0 can perform the same functions as unit 1.) See [[Input_Device\|Input Device]] for more information on the input device.}}
	{\| class="wikitable"
⚫	\| ''Who Runs The Mouse?'' When the input device or Intution is operating, unit 0 is usually dedicated to gathering mouse events. The input device uses the gameport device to read the mouse events. (For applications that take over the machine without starting up the input device or Intuition, unit 0 can perform the same functions as unit 1.) See [[Input_Device\|Input Device]] for more information on the input device.
	\|}

	== Device Interface ==		== Device Interface ==

Steven Solie: /* Device Interface */

2012-05-22T20:56:43Z

Device Interface

← Older revision		Revision as of 20:56, 22 May 2012
Line 59:		Line 59:
	== Device Interface ==		== Device Interface ==

	The gameport device operates like the other Amiga devices. To use it, you must first open the gameport device, then send I/O requests to it, and then close it when finished. See ~~the~~ [[~~Introduction~~ to ~~Amiga System Devices~~]] ~~chapter~~ for general information on device usage.		The gameport device operates like the other Amiga devices. To use it, you must first open the gameport device, then send I/O requests to it, and then close it when finished. See [[Exec_Device_I/O\|Exec Device I/O]] for general information on device usage.

	The I/O request used by the gameport device is called IOStdReq.		The I/O request used by the gameport device is called IOStdReq.

Alexandre Balaban: Categorizing

2012-05-10T21:47:06Z

Categorizing

← Older revision		Revision as of 21:47, 10 May 2012
Line 1:		Line 1:
	{{NeedUpdate}}		[[Category:Devices\|Gameport]]{{NeedUpdate}}
	== Gameport Device ==		== Gameport Device ==

Alexandre Balaban: /* Device Interface */

2012-05-10T21:46:23Z

Device Interface

← Older revision		Revision as of 21:46, 10 May 2012
Line 59:		Line 59:
	== Device Interface ==		== Device Interface ==

	The gameport device operates like the other Amiga devices. To use it, you must first open the gameport device, then send I/O requests to it, and then close it when finished. See the ~~“Introduction~~ to Amiga System ~~Devices”~~ chapter for general information on device usage.		The gameport device operates like the other Amiga devices. To use it, you must first open the gameport device, then send I/O requests to it, and then close it when finished. See the [[Introduction to Amiga System Devices]] chapter for general information on device usage.

	The I/O request used by the gameport device is called IOStdReq.		The I/O request used by the gameport device is called IOStdReq.

Steven Solie: /* Three Step Protocol for Using the Gameport Device */

2012-05-03T18:56:05Z

Three Step Protocol for Using the Gameport Device

← Older revision		Revision as of 18:56, 3 May 2012
Line 325:		Line 325:

	==== Three Step Protocol for Using the Gameport Device ====		==== Three Step Protocol for Using the Gameport Device ====



	Send GPD_ASKCTYPE to the device and check for a GPCT_NOCONTROLLER return. ''Never'' issue GPD_SETCTYPE without checking whether the desired gameport unit is in use.		Send GPD_ASKCTYPE to the device and check for a GPCT_NOCONTROLLER return. ''Never'' issue GPD_SETCTYPE without checking whether the desired gameport unit is in use.
Line 332:		Line 330:
	If GPCT_NOCONTROLLER is returned, you have access to the gameport. Set the allocation flag to GPCT_MOUSE, GPCT_ABSJOYSTICK or GPCT_RELJOYSTICK if you use a system supported controller, or GPCT_ALLOCATED if you use a custom controller.		If GPCT_NOCONTROLLER is returned, you have access to the gameport. Set the allocation flag to GPCT_MOUSE, GPCT_ABSJOYSTICK or GPCT_RELJOYSTICK if you use a system supported controller, or GPCT_ALLOCATED if you use a custom controller.

		⚫	<pre>

		⚫	struct IOStdReq GameIO; / Must be initialized prior to using */

⚫	~~<pre>~~struct IOStdReq GameIO; / Must be initialized prior to using */

	BOOL set_controller_type(type)		BOOL set_controller_type(type)
Line 364:		Line 361:
	/* success can be TRUE or FALSE, see above */		/* success can be TRUE or FALSE, see above */
	return(success);		return(success);
			}
⚫	}</pre>
		⚫	</pre>

	The program must set the controller type back to GPCT_NOCONTROLLER upon exiting your program:		The program must set the controller type back to GPCT_NOCONTROLLER upon exiting your program:

			<pre>
	~~<pre>~~struct IOStdReq GameIO; / Must be initialized prior to using */		struct IOStdReq GameIO; / Must be initialized prior to using */

	void free_gp_unit()		void free_gp_unit()
Line 376:		Line 376:
	GameIO->io_Data = (APTR)&type; /* set to unused */		GameIO->io_Data = (APTR)&type; /* set to unused */
	DoIO( GameIO);		DoIO( GameIO);
			}
⚫	}</pre>
			</pre>

	This three step protocol allows applications to share the gameport device in a system compatible way.		This three step protocol allows applications to share the gameport device in a system compatible way.

			{\| class="wikitable"
	~~<sub>b</sub>oxA~~ Word About The Functions.The functions shown above are designed to be included in any application using the gameport device. The first function, set_controller_type(), would be the first thing done after opening the gameport device. The second function, free_gp_unit(), would be the last thing done before closing the device.		\| ''A Word About The Functions.'' The functions shown above are designed to be included in any application using the gameport device. The first function, set_controller_type(), would be the first thing done after opening the gameport device. The second function, free_gp_unit(), would be the last thing done before closing the device.
			\|}

	== Joystick Example Program ==		== Joystick Example Program ==

Steven Solie: /* Setting Gameport Event Trigger Conditions */

2012-05-03T18:55:06Z

Setting Gameport Event Trigger Conditions

← Older revision		Revision as of 18:55, 3 May 2012
Line 209:		Line 209:
	}</pre>		}</pre>
	=== Setting Gameport Event Trigger Conditions ===		=== Setting Gameport Event Trigger Conditions ===



	You set the conditions that can trigger a gameport event by passing an I/O request to the device with GPD_SETTRIGGER set in io_Command and the address of a GamePortTrigger structure set in io_Data.		You set the conditions that can trigger a gameport event by passing an I/O request to the device with GPD_SETTRIGGER set in io_Command and the address of a GamePortTrigger structure set in io_Data.
Line 216:		Line 214:
	The information needed for gameport trigger setting is placed into a GamePortTrigger data structure which is defined in the include file devices/gameport.h.		The information needed for gameport trigger setting is placed into a GamePortTrigger data structure which is defined in the include file devices/gameport.h.

			<syntaxhighlight>
	~~<pre>~~struct GamePortTrigger		struct GamePortTrigger
	{		{
	UWORD gpt_Keys; /* key transition triggers */		UWORD gpt_Keys; /* key transition triggers */
Line 222:		Line 221:
	UWORD gpt_XDelta; /* X distance trigger */		UWORD gpt_XDelta; /* X distance trigger */
	UWORD gpt_YDelta; /* Y distance trigger */		UWORD gpt_YDelta; /* Y distance trigger */
			}
⚫	}</pre>
			</syntaxhighlight>


	A few points to keep in mind with the GPD_SETTRIGGER command are:		A few points to keep in mind with the GPD_SETTRIGGER command are:

		⚫	* Setting GPTF_UPKEYS enables the reporting of upward transitions. Setting GPTF_DOWNKEYS enables the reporting of downward transitions. These flags may both be specified.
	<ul>

⚫	~~<li><p>~~Setting GPTF_UPKEYS enables the reporting of upward transitions. Setting GPTF_DOWNKEYS enables the reporting of downward transitions. These flags may both be specified.~~</p>~~
		⚫	* The field gpt_Timeout specifies the time interval (in vertical blank units) between reports in the absence of another trigger condition. In other words, an event is generated every gpt_Timeout ticks. Vertical blank units may differ from country to country (e.g 60 Hz NTSC, 50 Hz PAL). To find out the exact frequency use this code fragment:
	<p></p></li>

⚫	~~<li><p>~~The field gpt_Timeout specifies the time interval (in vertical blank units) between reports in the absence of another trigger condition. In other words, an event is generated every gpt_Timeout ticks. Vertical blank units may differ from country to country (e.g 60 Hz NTSC, 50 Hz PAL). To find out the exact frequency use this code fragment:~~</p>~~
			<pre>
	~~<pre>~~#include ~~<~~exec/execbase.h~~>~~		#include <exec/execbase.h>
	extern struct ExecBase *SysBase;		extern struct ExecBase *SysBase;

	UBYTE get_frequency(void)		UBYTE get_frequency(void)
	{		{
	return((UBYTE)SysBase-~~>~~VBlankFrequency);		return((UBYTE)SysBase->VBlankFrequency);
			}
⚫	}</pre~~></li~~>
		⚫	</pre>
⚫	~~<li><p>~~The gpt_XDelta and gpt_YDelta fields specify the x and y distances which, if exceeded, trigger a report.~~</p></li></ul>~~

		⚫	* The gpt_XDelta and gpt_YDelta fields specify the x and y distances which, if exceeded, trigger a report.

	For a mouse controller, you can trigger on a certain minimum-sized move in either the x or y direction, on up or down transitions of the mouse buttons, on a timed basis, or any combination of these conditions.		For a mouse controller, you can trigger on a certain minimum-sized move in either the x or y direction, on up or down transitions of the mouse buttons, on a timed basis, or any combination of these conditions.



	For example, suppose you normally signal mouse events if the mouse moves at least 10 counts in either the x or y directions. If you are moving the cursor to keep up with mouse movements and the user moves the mouse less than 10 counts, after a period of time you will want to update the position of the cursor to exactly match the mouse position. Thus the timed report of current mouse counts would be preferred. The following structure would be used:		For example, suppose you normally signal mouse events if the mouse moves at least 10 counts in either the x or y directions. If you are moving the cursor to keep up with mouse movements and the user moves the mouse less than 10 counts, after a period of time you will want to update the position of the cursor to exactly match the mouse position. Thus the timed report of current mouse counts would be preferred. The following structure would be used:

	<pre>~~#define XMOVE 10~~		<pre>
			#define XMOVE 10
	#define YMOVE 10		#define YMOVE 10

Line 255:		Line 256:
	XMOVE, /* for any 10 in an x or y direction */		XMOVE, /* for any 10 in an x or y direction */
	YMOVE		YMOVE
	};~~</pre>~~		};
		⚫	</pre>

	For a joystick controller, you can select timed reports as well as button-up and button-down report trigger conditions. For an absolute joystick specify a value of one (1) for the GameTR_XDelta and GameTR_YDelta fields or you will not get any direction events. You set the trigger conditions by using the following code or its equivalent:		For a joystick controller, you can select timed reports as well as button-up and button-down report trigger conditions. For an absolute joystick specify a value of one (1) for the GameTR_XDelta and GameTR_YDelta fields or you will not get any direction events. You set the trigger conditions by using the following code or its equivalent:

		⚫	<pre>

		⚫	struct IOStdReq *GameIO;

⚫	~~<pre>~~struct IOStdReq *GameIO;

	void set_trigger_conditions(struct GamePortTrigger *GameTR)		void set_trigger_conditions(struct GamePortTrigger *GameTR)
Line 268:		Line 270:
	GameIO->io_Length = sizeof(struct GamePortTrigger);		GameIO->io_Length = sizeof(struct GamePortTrigger);
	DoIO(GameIO);		DoIO(GameIO);
			}
⚫	}</pre>
			</pre>
⚫	~~<sub>b</sub>oxTriggers~~ and Reads.If a task sets trigger conditions and does not ask for the position reports the gameport device will queue them up anyway. If the trigger conditions occur again and the gameport device buffer is filled, the additional triggers will be ignored until the buffer is read by a device read request (GPD_READEVENT) or a system CMD_CLEAR command flushes the buffer.

			{\| class="wikitable"
		⚫	\| ''Triggers and Reads.'' If a task sets trigger conditions and does not ask for the position reports the gameport device will queue them up anyway. If the trigger conditions occur again and the gameport device buffer is filled, the additional triggers will be ignored until the buffer is read by a device read request (GPD_READEVENT) or a system CMD_CLEAR command flushes the buffer.
			\|}

	=== Determining the Trigger Conditions ===		=== Determining the Trigger Conditions ===

Steven Solie: /* Gameport Device Controllers */

2012-05-03T18:52:41Z

Gameport Device Controllers

@@ Line 135: / Line 135: @@
 When a gameport device unit reponds to a request for input, it creates an input event. The contents of the input event will vary based on the type of device and the trigger conditions you have declared.
-<li><p>There is currently no system software support for proportional joysticks or proportional controllers (e.g., paddles). If you write custom code to read proportional controllers or other controllers (e.g., light pen) make certain that you issue GPD_SETCTYPE (explained below) with controller type GPCT_ALLOCATED to insure that other applications know the connector is being used.</p>
+* There is currently no system software support for proportional joysticks or proportional controllers (e.g., paddles). If you write custom code to read proportional controllers or other controllers (e.g., light pen) make certain that you issue GPD_SETCTYPE (explained below) with controller type GPCT_ALLOCATED to insure that other applications know the connector is being used.
-<p><sub>b</sub>oxGPCT_NOCONTROLLERThe controller type GPCT_NOCONTROLLER is not a controller at all, but a flag to indicate that the unit is not being used at the present time.</p></li></ul>
+| ''GPCT_NOCONTROLLER'' The controller type GPCT_NOCONTROLLER is not a controller at all, but a flag to indicate that the unit is not being used at the present time.
 === Closing the Gameport Device ===

Steven Solie: /* Gameport Device Controllers */

2012-05-03T18:51:27Z

Gameport Device Controllers

← Older revision		Revision as of 18:51, 3 May 2012
Line 109:		Line 109:
	The Amiga has five gameport device controller types.		The Amiga has five gameport device controller types.

		⚫	'''Gameport Device Controllers'''
	\|l\|l\|

⚫	2c'''Gameport Device Controllers'''~~<br />~~
	'''Controller Type''' & '''Description'''<br />
⚫	~~GPCT_MOUSE &~~ Mouse controller~~<br />~~
⚫	~~GPCT_ABSJOYSTICK &~~ Absolute (digital) joystick~~<br />~~
⚫	~~GPCT_RELJOYSTICK &~~ Relative (digital) joystick~~<br />~~
⚫	~~GPCT_ALLOCATED &~~ Custom controller~~<br />~~
	GPCT_NOCONTROLLER & No controller<br />

			{\| class="wikitable"
			! Controller Type
			! Description
			\|-
			\| GPCT_MOUSE
		⚫	\| Mouse controller
			\|-
			\| GPCT_ABSJOYSTICK
		⚫	\| Absolute (digital) joystick
			\|-
			\| GPCT_RELJOYSTICK
		⚫	\| Relative (digital) joystick
			\|-
			\| GPCT_ALLOCATED
		⚫	\| Custom controller
			\|-
			\| GPCT_NOCONTROLLER
			\| No controller
			\|}

	To use the gameport device, you must define the type of device connected to the gameport and define how the device is to respond. The gameport device can be set up to return the controller status immediately or only when certain conditions have been met.		To use the gameport device, you must define the type of device connected to the gameport and define how the device is to respond. The gameport device can be set up to return the controller status immediately or only when certain conditions have been met.

Steven Solie: /* Device Interface */

2012-05-03T18:49:57Z

Device Interface

← Older revision		Revision as of 18:49, 3 May 2012
Line 63:		Line 63:
	The I/O request used by the gameport device is called IOStdReq.		The I/O request used by the gameport device is called IOStdReq.

			<syntaxhighlight>
	~~<pre>~~struct IOStdReq		struct IOStdReq
	{		{
	struct Message io_Message;		struct Message io_Message;
Line 75:		Line 76:
	APTR io_Data; /* points to data area */		APTR io_Data; /* points to data area */
	ULONG io_Offset; /* offset for block structured devices */		ULONG io_Offset; /* offset for block structured devices */
	};~~</pre>~~		};
			</syntaxhighlight>

	See the include file exec/io.h for the complete structure definition.		See the include file exec/io.h for the complete structure definition.

Line 143:		Line 146:
	WaitIO((GameIO); /* Wait for abort, then clean up */		WaitIO((GameIO); /* Wait for abort, then clean up */
	CloseDevice(GameIO);</pre>		CloseDevice(GameIO);</pre>

	== Gameport Events ==		== Gameport Events ==