Konami‘s "Dance Dance Revolution"（DDR） was one of the first "video
games" to involve its participants in a level of physical activity
beyond typical exploration and defensive thumb twiddling. Although
there is a significant amount of memorization involved with many
games （e.g.， when to use a particular weapon， where to find a
hidden prize， or how to obtain a goal）， the sedentary posture
associated with playing them isn‘t conducive to combating obesity.
DDR requires players to memorize and perform foot movements in time
with on-screen cues and "hip" soundtracks. Instead of using a
typical hand-held joystick， the player， or "dancer，" steps on a
colorful floor mat divided into pressure-sensing areas. Body weight
triggers the input. Screen cues designate which areas to step on.
Successful triggering，stepping on only the appropriate area at the
appropriate time， scores high points. This is similar to learning
to dance by following painted footprints on the floor.
It's no wonder music provides a connection to others. Our lives are
full of naturally occurring rhythmic sounds and many individuals
even carry a music player around with them. It‘s not too hard to
understand why the DDR craze has caught on. Arcades offer a string
of DDR machines. They usually have railing that not only keeps the
dancer from losing their balance，but it also provides added
leverage to accomplish tough moves. It‘s crazy to see the footwork
necessary to compete at the upper levels of these contests.
The newest variation to the dancing theme is to perform in a new
way. Activision's "Guitar Hero" （GH） lets you perform like a rock
star. Don‘t want to take years of music lessons？No problem. With
GH， you can perform like a rock star right away. Out with the floor
mat and in with the guitar controller. The controller doesn‘t have
strings； it has just five buttons for one hand and a
strummer（button） and a whammy bar （one-half of an analog joystick）
for the other hand. The on-screen cuing is similar to DDR. Pick
your song and start performing. While you aren't actually playing
the real notes （after all， you have only five buttons）， it‘s your
synchronization that produces the highest scores.
This month， I'll show you how to investigate the Sony PlayStation
2‘s（PS2） controller interface and replace a controller all with the
same circuitry. First， you'll use the circuitry in Figure 1 to
simulate the PS2 system and make inquiries about which peripheral
is plugged into it. Then， the same circuitry will be configured to
look like a PS2 peripheral controller. To begin， I will examine the
communications medium of the PS2.
SEARCH
With your favorite search engine，you can look around the ether for
information on the PS2 （or any other system you are interested in）。
Of course， everyone is trying to get you to buy something， so you
might have to work a bit to get through the ads. In this case，
although I could have hooked up a scope to the PS2 and figured out
the interface， I knew I could save some valuable time by seeing
what information was already out there. A number of sites offer the
same pinout and command reference， but I like Hardware Book
（www.hardwarebook. info） because it has a lot of information on one
site.
The next roadblock was （and often is） a special connector that
might be necessary to make a connection to proprietary equipment.
The least expensive approach is to get a controller expansion
cable. The advantage of the cable is that you get both male and
female connectors for a single price， sometimes for as low as $3.
With a connection pinout and an idea about what the communication
protocol is， drawing up a schematic and putting together a
prototype is straightforward.The PS2 interface requires five signal
lines （besides power and ground）。 The controller operations require
16 bits plus four analog inputs. That‘s a total of 25 control
lines. Some 28-pin， flash-memorybased microcontrollers have just
enough I/Os. I could have chosen to go to a 40-pin device， but I
wanted to keep it as inexpensive as possible.
The design in Figure 1 can be used to perform two different tasks.
It'll begin its life acting like a PS2 gaming system and send out
command bytes looking for a controller. When a controller is
plugged into the circuit， the controller will answer back with data
bytes indicating what it is and the status of its inputs. Because
the reply can be several bytes in length， I wanted to collect this
information and display it in an intelligent format other than on
an LED. This requires being verbose. I chose adding an LCD to the
circuit because all of the inputs would not be necessary when
acting as a system.
点击查看Figure 1
If I was doing this project without knowing the protocol，I would
first program it to look like a controller to the PS2 and display
the commands it sent. I would then ensure the system sends out two
bytes， 0x01 and 0x42. Without a real controller hooked up to answer
these commands，communication would cease. However， I would now have
the format necessary to interrogate a controller，the same
information an Internet search provided， so I could continue.
To look like a PS2 system， the microcontroller needs to communicate
with a SPI format as a master and provide an *SS （ATT） select line
to the controller （see Figure 2）。 The controller acknowledges each
byte received with an ACK. This enables the controller to signal
when it is finished processing the byte received from the system.
This includes writing a data byte （reply） to the SPI buffer.
Remember that the SPI mode uses separate data in and out
lines，enabling data to pass in both directions at the same time.
The only catch is that the data pertinent to the last command isn‘t
passed until the next command is clocked.
Figure 3 shows how the circuit is used to identify controllers that are plugged into the connector J1. （Note that the SDI and SDO need to be remapped on the connector because the SPI I/Os can not be remapped by the application. This can be done by moving the jumpers on JPx.） When I powered up the circuit， I thought I had something wired incorrectly because there was no response from any controller plugged in. Then it hit me. I wasn‘t providing the correct data. The correct data should have been 0x01， but I was sending 0x01. Is that a typo？ No it isn't. Let me explain. Had I paid sufficient attention to the specifications， I wouldn‘t have assumed the data was most significant bit （MSB） first （as in standard SPI hardware）。 In fact， it is least significant bit （LSB） first. Because I couldn't define this using the hardware SPI， I had a choice. I had to either bit bang an SPI port or transform all of the data going to or coming from the hardware SPI. I chose the latter. I simply remapped all of the data and stored it in reverse order. I originally thought I could use a routine to take the data and reverse it before writing it into the SPI buffer （or after reading a byte from the SPI buffer），but I found that this took too much time （more on this later）。
SETTING THE STAGE
Now that we‘ve identified various controllers using the circuit to
emulate a PS2， it's time to make the circuit act as a controller to
the PS2. This application has less to do with emulating the PS2，
however， because we are not "in charge" of the timings. Everything
is a lot more critical. We need to keep track of the present button
（digital）
and joystick （analog） states and apply the current status to a
table. The table is， in fact， a list of the responses that we will
use when the system sends a command to query the status of the
controller. The buttons are all tested and the data table is
updated accordingly in the main loop of the application. That‘s all
that happens in the main loop.
Converting the four joystick positions is a bit different because
the conversions take time. Although the ADC produces an interrupt
on "endof- conversion，" if an interrupt occurs during a
transmission from the PS2，the transmission will be lost. The PS2
will give up if it gets no response（ACK） in approximately 60 μs.
（That's 60 instructions running with a 1-μs instruction time.）
Instead of using the interrupt， I poll the interrupt flag in the
main loop. The main loop can then branch to a read and store the
conversion whenever the conversion is finished， yet still be
interrupted by the SPI interrupt whenever communication is
requested. The A/D routine also increments the analog channel so
the next joystick is converted， all four in round-robin fashion.
SPI communication from the PS2 controller has top priority and is
the only interrupt routine. Once a SPI interrupt has occurred （the
last of 8 bits are clocked into the receiver）， there is no time for
lollygagging around. I treat all communications （while ATT is low）
in this interrupt without leaving after each character is
processed. I look for the 0x01 （0x80 in your reverse case） and then
look for a query command（0x42）。 The data I need to reply with is
already formatted in a table and the bytes can be transmitted to
the PS2 as it continues requesting data. If at any point the ATT
line goes high， the system has discontinued communication， so the
interrupt routine is exited and the main loop continues updating
the status of the buttons and joysticks.
The documentation I found so far has not mentioned any other
commands other than 0x42. This seems rather limited. I know from
experimenting that the analog joystick has a button on it that can
change its format from "standard digital pad" to "analog
controller." When initially powered， it defaults to "standard
digital pad." This might be so it can be backward-compatible to a
PS1. On the PS2， when a game like "Guitar Hero" is used， the
controller is automatically redefined as an"analog controller."
This means that there must be other commands issued by the PS2 that
the controller can respond to. A little more fishing around on the
‘Net revealed a text file on Lynxmotion （www.lynxmotion.
com/images/files/ps2cmd01.txt） that has a bit more sketchy
information. I'll leave this for you to investigate if you are
interested. As you can see in Figure 4， I left room in the code
for"other additional commands" to be recognized and responded to.
But for my purposes， this is all that‘s necessary to achieve my
goal.
Jeff Bachiochi （pronounced BAH-key-AHkey）has been writing for
Circuit Cellar since 1988. His background includes product design
and manufacturing. He may be reached through the
magazine（jeff.bachiochi@circuitcellar.com） or his web site
（www.imaginethatnow.com）。
PROJECT FILES
To download code, go to ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2008/214.
RESOURCES
Hardware Book, www.hardwarebook.info.
Lynxmotion, Inc., www.lynxmotion.com/images/files/ps2cmd01.txt.
SOURCE
PIC16F737 Microcontroller
Microchip Technology, Inc.
www.microchip.com
;){kind=link}