| 1 |
8 |
arniml |
|
| 2 |
|
|
README for the SNESpad core
|
| 3 |
|
|
===========================
|
| 4 |
41 |
arniml |
Version: $Id: README 41 2009-04-01 19:58:04Z arniml $
|
| 5 |
8 |
arniml |
|
| 6 |
|
|
|
| 7 |
|
|
Description
|
| 8 |
|
|
-----------
|
| 9 |
|
|
|
| 10 |
|
|
The SNESpad core manages one or more gamepads of the Super Nintendo
|
| 11 |
|
|
Entertainment System in parallel. The button information is provided
|
| 12 |
|
|
statically at a simple interface with dedicated signal lines.
|
| 13 |
|
|
The core has to be configured to fit into the integrating system. Details
|
| 14 |
|
|
about this are given in the section "Integration" below.
|
| 15 |
|
|
|
| 16 |
|
|
|
| 17 |
|
|
Integration
|
| 18 |
|
|
-----------
|
| 19 |
|
|
|
| 20 |
|
|
The interface of the SNESpad core is straight forward. It requires:
|
| 21 |
|
|
|
| 22 |
|
|
* a clock signal which is evaluated on the rising edge by the internal
|
| 23 |
|
|
registers an asynchronous reset (active level is configurable)
|
| 24 |
|
|
* connections to the gamepad(s)
|
| 25 |
|
|
|
| 26 |
|
|
The button outputs should be self-describing.
|
| 27 |
|
|
|
| 28 |
|
|
Configuration of the core is done via generics in the instantiation. There are
|
| 29 |
|
|
four generic parameters:
|
| 30 |
|
|
|
| 31 |
|
|
* num_pads_g - Number of pads connected to this controller instance (1 to n)
|
| 32 |
|
|
* reset_level_g - Active level of the asynchronous reset at port reset_i
|
| 33 |
|
|
(0 = low active, 1 = high active)
|
| 34 |
|
|
* button_level_g - Active level of the button outputs
|
| 35 |
|
|
(0 = low active, 1 = high active)
|
| 36 |
|
|
* clocks_per_6us_g - Number of clk_i cycles that elapse during 6 us (2 to x)
|
| 37 |
|
|
|
| 38 |
|
|
Button outputs and pad data input are arrays of num_pads_g width. The
|
| 39 |
|
|
assignment is 1:1. i.e. the pad connected to pad_data_i(i) will propagate its
|
| 40 |
|
|
button status to but_a_o(i), but_b_o(i) etc. where i ranges from 0 to n-1.
|
| 41 |
|
|
|
| 42 |
|
|
The communication to the SNES gamepad relies on a timebase of approximately
|
| 43 |
|
|
6 us. It is therefore necessary to adjust the counters inside the core via the
|
| 44 |
|
|
clock_per_6us_g generic parameter. Let's assume an example where the system
|
| 45 |
|
|
clock is running at 20 MHz. There are 20 clock cycles during 1 us, so the
|
| 46 |
|
|
generic has to be set to 6 x 20 = 120.
|
| 47 |
|
|
|
| 48 |
|
|
|
| 49 |
|
|
Adapter Hardware
|
| 50 |
|
|
----------------
|
| 51 |
|
|
|
| 52 |
|
|
The required hardware setup is pretty simple if you reuse the connector of a
|
| 53 |
|
|
SNES console. It is quite robust and offers all connections centrally on the
|
| 54 |
|
|
bottom side of the PCB at the pins for the cable socket. In addition, you will
|
| 55 |
|
|
need an external 5V power source. Such a configuration is shown in the
|
| 56 |
|
|
following picture.
|
| 57 |
|
|
|
| 58 |
|
|
Pin B1 is the common Data Latch signal for Pad 1 and Pad 2. The pins B2 and T2
|
| 59 |
|
|
are the Data Clock for Pad 1 and Pad 2, respectively. They have to be
|
| 60 |
|
|
connected together to pad_clock_i as the core clocks both pads
|
| 61 |
|
|
simultaneously. Pin B3 is the Serial Data of Pad 1 and Pin B4 is the Serial
|
| 62 |
|
|
Data of Pad 2. Each data line requires a 10 kOhm pull-up resistor.
|
| 63 |
|
|
|
| 64 |
|
|
See snespad.png
|
| 65 |
|
|
|
| 66 |
|
|
|
| 67 |
|
|
Verification
|
| 68 |
|
|
------------
|
| 69 |
|
|
|
| 70 |
|
|
The SNESpad core comes with a simple testbench that simulates two SNES
|
| 71 |
|
|
gamepads. Serial information is sent to the core and the reported button
|
| 72 |
|
|
states are compared against the input.
|
| 73 |
|
|
You should normally not need to run the testbench. But in case you modified
|
| 74 |
|
|
the VHDL code the testbench gives some hints if the design has been broken.
|
| 75 |
|
|
|
| 76 |
|
|
|
| 77 |
|
|
Directory Structure
|
| 78 |
|
|
-------------------
|
| 79 |
|
|
|
| 80 |
|
|
The core's directory structure follows the proposal of OpenCores.org.
|
| 81 |
|
|
|
| 82 |
|
|
snespad
|
| 83 |
|
|
|
|
| 84 |
|
|
\--+-- rtl
|
| 85 |
|
|
| |
|
| 86 |
|
|
| \-- vhdl : VHDL code containing the RTL description
|
| 87 |
|
|
| of the core.
|
| 88 |
|
|
|
|
| 89 |
|
|
+-- bench
|
| 90 |
|
|
| |
|
| 91 |
|
|
| \-- vhdl : VHDL testbench code.
|
| 92 |
|
|
|
|
| 93 |
|
|
\-- sim
|
| 94 |
|
|
|
|
| 95 |
|
|
\-- rtl_sim : Directory for running simulations.
|
| 96 |
|
|
|
| 97 |
|
|
|
| 98 |
|
|
Compiling the VHDL Code
|
| 99 |
|
|
-----------------------
|
| 100 |
|
|
|
| 101 |
|
|
VHDL compilation and simulation tasks take place inside in sim/rtl_sim
|
| 102 |
|
|
directory. The project setup supports only the GHDL simulator (see
|
| 103 |
|
|
http://ghdl.free.fr).
|
| 104 |
|
|
|
| 105 |
|
|
To compile the code simply type at the shell
|
| 106 |
|
|
|
| 107 |
|
|
$ make
|
| 108 |
|
|
|
| 109 |
|
|
This should result in a file called tb_behav_c0 which can be executed as any
|
| 110 |
|
|
other executable.
|
| 111 |
|
|
|
| 112 |
|
|
The basic simple sequence list can be found in COMPILE_LIST. This can be
|
| 113 |
|
|
useful to quickly set up the analyze stage of any compiler or
|
| 114 |
|
|
synthesizer. Especially when synthesizing the code, you want to skip the VHDL
|
| 115 |
|
|
configurations in *-c.vhd and everything below the bench/ directory.
|
| 116 |
|
|
|
| 117 |
|
|
|
| 118 |
|
|
References
|
| 119 |
|
|
----------
|
| 120 |
|
|
|
| 121 |
|
|
* Gamepads project at OpenCores.org
|
| 122 |
|
|
http://www.opencores.org/projects.cgi/web/gamepads/overview
|
| 123 |
|
|
|
| 124 |
|
|
* The Hardware Book
|
| 125 |
|
|
http://www.hardwarebook.net/connector/userinput/snescontroller.html
|
| 126 |
|
|
|
| 127 |
|
|
* Linux gamecon driver
|
| 128 |
|
|
http://lxr.linux.no/source/drivers/char/joystick/gamecon.c?v=2.4.26
|