URL
https://opencores.org/ocsvn/gamepads/gamepads/trunk
Subversion Repositories gamepads
[/] [gamepads/] [trunk/] [gcpad/] [README] - Rev 34
Go to most recent revision | Compare with Previous | Blame | View Log
README for the GCpad core
=========================
Version: $Date: 2004-10-28 20:00:12 $
Description
-----------
The GCpad core interfaces to the gamepad used with the Nintendo Gamecube video
gaming system. The core communicates with the gamepad using its proprietary
communication protocol and offers the retrieved information for further
processing.
To suit the needs of the integrating system, two different flavors of the core
are available:
* For simple applications the basic flavor manages all communication issues
with the gamepad and provides the current status of the buttons and analog
axes at its interface. The integrating system does not need to interfere
with gamepad communication and can statically read the button and axes
status information.
* The full flavor allows full control of the gamepad communication by the
integrating system. This flavor offers a command and response interface
which is driven by the system to send arbitrary commands to the
gamepad. The response of the gamepad is available for further processing.
Connecting the Pad
------------------
Information is exchanged between the gamepad and the host side over a single
wire. Both sides seem to implement an open-collector style output
driver. Therefore, an external pull-up resistor of 1kOhm to the 3.43V supply
is required at the DATA line.
Sticking exactly to the 3.3V supply seems not to be necessary. I use the 3.3V
supply which is available from the FPGA board. Please note that the 5V supply
is required for certain controller types even if the rumble motor is not used.
The connector seems to be a special type designed for the Gamecube. It might
be hard to find a matching counterpart. If you do not want to rip up the
controller cable then your alternative option might be to reuse an extension
cable. They are quite cheap and pass through all required wires. Just remove
the connector that is plugged into the console and attach your favorite
standard connector.
See gcpad.png.
Verification
------------
The GCpad core comes with a simple testbench that includes a simulation model
of a Gamecube controller. Serial information is sent to the core and the
reported button states are compared against the input. Both flavors are tested
in parallel there.
You should normally not need to run the testbench. But in case you modified
the VHDL code the testbench gives some hints if the design has been broken.
Directory Structure
-------------------
The core's directory structure follows the proposal of OpenCores.org.
gcpad
|
\--+-- doc : Integration Manual
|
+-- rtl
| |
| \-- vhdl : VHDL code containing the RTL description
| of the core.
|
+-- bench
| |
| \-- vhdl : VHDL testbench code.
|
\-- sim
|
\-- rtl_sim : Directory for running simulations.
Compiling the VHDL Code
-----------------------
VHDL compilation and simulation tasks take place inside in sim/rtl_sim
directory. The project setup supports only the GHDL simulator (see
http://ghdl.free.fr).
To compile the code simply type at the shell
$ make
This should result in a file called tb_behav_c0 which can be executed as any
other executable.
The basic simple sequence list can be found in COMPILE_LIST. This can be
useful to quickly set up the analyze stage of any compiler or
synthesizer. Especially when synthesizing the code, you want to skip the VHDL
configurations in *-c.vhd and everything below the bench/ directory.
References
----------
* James' excellent page covering many details of the Gamecube controller
protocol
http://www.int03.co.uk/crema/hardware/gamecube/gc-control.htm
* Yet Another Gamecube Documentation
http://www.gc-linux.org/docs/yagcd/index.html
Refer to section 5.8, 9.1 and 9.2.
Go to most recent revision | Compare with Previous | Blame | View Log