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
|