In a previous video, we examined the ergonomics of two controllers for the
Nintendo Entertainment System - the original rectangular controller and the
"Dogbone" redesign. In this video, we will focus on the electronics of those
controllers, the circuit components, and the signals that go in and out of the
control ports on the system. I can recall looking at the plug for the Atari 2600
joystick in the 1980s and counting the pins. There were nine. Swapping a joystick
and a paddle controller is pretty standard fare when it comes to the Atari.
I thought that the four directions and one button of the joystick must each get
a pin - so five total - and that maybe the rest of them were used for the paddle?
I figured controllers must need one pin per signal to deliver presses to the
Atari. I wasn't too far off in this case. When the Nintendo came along, I was
confused this controller has four directions plus four buttons - eight total
things you could press, but only seven pins? How does this work?
Let's talk about it. With all of the plastic pieces and rubber membranes
removed, we can examine the circuit board, components on that board, and the wires
connected to it. This side of the board is the side that faces us when we use
the controller. When we press a button, the contacts on the rubber membrane
bridge neighboring areas of the PCB to indicate a button is being pressed. Let's
look at the back. The wires connect in the top-left corner. You can see that the
colors for the wires of the controller have matching labels on the board to
indicate where each wire should go. The colors of the wires match the
abbreviations on the labels written to the left of each hole. At the bottom, you
see the label for the corresponding system the Nintendo Entertainment System
in our case. You no doubt have also noticed the second set of colors and
system with each label in parenthesis. This color scheme is for the wires of a
Famicom along with "HVC," which stands for home video computer. Wire colors aren't
universal, and this helps anyone that is assembling this controller by hand to
know where each wire is supposed to go. The key component we see here is this
chip with a label HD14021BP. As you may have surmised, this
chip is an important component for taking signals input by us and providing
them to the Nintendo. It is an 8-bit shift register, and we are going to learn
how it works. Let's return to the side where the button presses happen. I'll
talk you through the bright lines called "traces," and explain the
various signals. For reference and convenience here is a single socket on
the control deck. The control pad only uses five of these connections. The first
two signals to talk about are power and ground. The Nintendo supplies five volts
for power. I will sometimes refer to power and ground as "high" and "low"
respectively throughout this explanation. Let's trace the ground signal first.
Ground goes to each of the buttons as well as the d-pad on the board. While you
may not consider the d-pad to be buttons, it is, in essence, a set of four buttons.
Therefore, ground goes to each of the eight buttons on the board as well as to
the shift register. The legs of that chip are soldered to the board right here. Sixteen
pins total. Ground connects to pins 8 and 11. So now we have our ground path.
Notice that each of the buttons has ground in common. As for power, the power
signal travels to the shift register as well as to one side of each of these
black areas on the board. Each of these areas is a carbon printed resistor. More
on that later. On the opposite side of each resistor is a trace that leads to
its own pin on the shift register as well as to one side of each of the
buttons. We have a pretty good layout of the traces to the sides of each button.
When a button is pressed, the side connected to the pin on the shift
register is bridged to the side connected directly to ground - therefore
grounding the signal. In other words, the signal is pulled low. So connecting the
appropriate pin to ground is what lets the shift register know which button or
buttons are being pressed. A fair question here might be "why do you need
power and these carbon printed resistors? Why not just tie the pin directly to one
side of the button, have ground on the other side like it is already, and then
when you press the button, it connects it to ground and activates the signal?" The
answer is - the pin needs to know at any given time if it is high or low. When you
tie it to ground, it is low. If you don't tie it to anything at all, then what is
it? The pin is floating. It needs to be told what to be. These resistors are used
to pull each pin high by default. The resistors are called "pull-up resistors"
as they give the pins their default state. By pulling them high, we use the
power signal as our indicator of high. The resistor between each
signal and power is important, because we would otherwise tie power directly to
ground whenever we press a button. If this happened, it would be bad.
Don't cross the streams.
We are set up quite well to tell each button that they
aren't being pressed until they are tied to ground. With the path set for both
power and ground, what about the remaining three signals? The names of
these signals are different depending on where you do your reading. I am electing
to use the terms "Latch," "Clock," and "Data." Latch and Clock are used to ask the
shift register for the state of the buttons, and the Data line is used to
communicate the state of those buttons to the Nintendo. The shift register can
be placed in parallel mode or serial mode. This is controlled by the Latch pin.
When it comes time to get the state of the buttons, the Nintendo sends a pulse
down the latch wire to tell the shift register to "latch" the state of all the
buttons. You might think of it as taking a photo of what buttons are pressed at
that exact moment in time. The latch pulse goes high to put the shift
register in parallel mode to gather the state of the buttons hooked up to each
pin, and then goes low to put the shift register in serial mode so it can send
the state of the buttons out the data line in a particular order. The shift
register *always* lines up the state of each button in the same order for serial
output - A, B, Select, Start, Up, Down, Left, Right. Eight states, always in the same
order - either high if they aren't being pressed, or low if they are. Data,
specifically the state of the "A" button as it is first in line, is immediately
output on the data line. To advance to the next button state, a pulse is sent
down our last wire - the Clock - to the controller. The clock pulses each time it
wants to get the next button in line. So think of the Nintendo as saying, "Next!"
each time it sends a clock pulse. Seven pulses plus a trailing pulse are sent
down the clock line for a single controller read. After the final clock
pulse, the single controller read has been completed for the current frame of
video. With a basic idea of how a controller read operates for the
Nintendo, let's build our own controller and examine the signals using an
oscilloscope. We'll hook it up to an early 90's
redesign of the Nintendo: a top-loading, AV Famicom. Since the point of this
controller is to allow us to press buttons and see what happens on the
scope, I'm going to substitute switches in place of the buttons when building my
own controller. This will let me activate and hold the button but still have my
hands-free. I picked up a plastic container from a home-improvement store
for a dollar and some change. This will serve as an enclosure for the switches.
I created a drilling template using a paint program, printed it out, and cut it
to fit the bottom of the container. Just like our gamepad, each button - or switch
in our case - will have the appropriate signal wire and a ground wire connected
to it. I daisy-chained the ground wire from switch to switch and ran it as well
as the signal wire for each switch out the side of the controller. Now I can
build the rest of the controller outside the enclosure.
I used 22 gauge solid core wire for all of the switch hookups. The reason for
this is so I can strip the opposite end of the wire and feed it into this -
a breadboard. Breadboards are used for prototyping circuits without the need
for continuous soldering and desoldering. Makes things easier to change throughout
the design. All of the holes on this top row X are connected together, and all of
the holes on this bottom row Y are also connected. Likewise, each column of five
holes is connected on either side of this trough. This just makes it easier to
join separate wires to the same signal. Let's build the controller. First up is
the shift register. It cost me about $0.50. It will straddle the trough like
so. The carbon printed, pull-up resistors from the gamepad are represented here by
these 39k film resistors. Each button-related input needs a pull-up resistor
with the opposite side connected to power, and each pin receives one. Both the
X and Y rows carry power, so they are bridged to share the signal.
Power is also routed to pin 16 of our chip.
Ground routes the pins 8 and 11 ground
signals meet at column 23 over here. Now the controller cable. The wires have been
extended using 22 gauge solid core wire. The colors are different than a stock
cable. Ground, Power, Latch, Clock and Data are now connected. Now all of the switch
signal wires to their appropriate pin. Cable connects to the control deck.
Launch control this is Houston, we are go for launch.
The switches are oriented opposite a light switch - therefore, the down position means on and
the up position means off. All switches are off to start. I oriented it this way
so my brain thinks "switch down" means the same as "press down" on a controller
button. Thanks to the shared columns on the breadboard, I can connect the
oscilloscope probes to Latch, Clock, and Data, and we can take a peek at what is
happening as the controller and the console communicate. Here is a screen on
an oscilloscope. This lets us view electrical signals over a period of time.
We are going to break down a controller read operation for Super Mario Bros.
Let's put a signal on the screen.
OK. This line from left to right is the
Latch signal. We'll talk about the specifics in just a bit. This line is
basically a signal's timeline. Time is moving forward as you move from the left
side of the screen to the right side of the screen. I have set up the scope to
always show the latch pulse right here on the screen. If I let the footage roll,
you can see the activity. We actually have tons of latch pulses occurring as
time is moving forward, but each one keeps landing in the same exact spot for
convenience. Otherwise, they would just keep flying by really fast, and we
couldn't really see anything. All you need to note when viewing a signal is
when it is low or high. See how the latch signal stays low and then goes up and
back down in a very short period of time? That is what the Nintendo does to signal
the 8-bit shift register to get the state of the buttons. I'll add the data
signal to the mix.
The data signal is high when a button is not pressed and
low when it is. None of the buttons are activated right now, so data remains high
for the duration of all eight button states. Remember that the state of each
button is output one at a time, and the Nintendo sends a clock pulse
each time it wants the next button state. Let's add the clock pulses.
The clock line is high. Each time it goes low, we pass the state of the next button on the
data line. Remember the order of buttons I mentioned earlier? I'll place their
order on the oscilloscope so things are easier to follow. With all three signals
on the screen, let's review. Latch switches the shift
register to parallel mode and then quickly back to serial mode effectively
saying "Let's go. Gimme "A." Let's let the footage roll, and I'll flip the switch
for "A." Now that A is active, the data output is low during A's output time.
I can now walk the line by activating B, Select, Start, Up, Down, Left, Right. Now all
buttons are active, so data remains low during the entire controller read. Note
that this is an impossible state on a real gamepad as it would require you to
press Up Down Left Right at the same time. Now let's turn off the d-pad
presses. Turn off B and A. Turn off Select. And now Start is the only button being
pressed and held. Watch the yellow data line, and I'll show you several states of
button presses.
No buttons are pressed.
All buttons are pressed.
Only Start is pressed.
All buttons except Up and Down are pressed. The entire controller read
occurs over the same period of time. The Nintendo sends the latch pulse and the
clock pulses, we step through the same order of button states each time, and
those states are fed in order across the data line. That's it. Of course in the
computing world, time is important and very relevant in computer operations.
Let's take a look at Nekketsu Hockey's controller read.
We are zoomed out a bit
on this one aren't we? The same rules apply for a controller read. Latch, Clock,
Data. But I am also monitoring a fourth signal - a signal that you already know if
you have watched other videos on this channel. The intro to this game rolls
through a few scenes and then hits the mostly white Technos screen.
This was the screen being displayed when I captured this
controller read, so...
Boom! The composite video signal from the Nintendo. You are
most likely already familiar with what is here. We have the last few scanlines
from the previous frame, the vertical sync and blanking period, and the start
of visible scanlines for the current frame. It appears that the latch signal
fires the controller read while the end of the sixth scan line is being drawn
across the CRT screen. Zooming in on the controller read area shows that the
controller read takes about two and a half scanlines to complete. This puts
time into perspective - not only does it take almost three scanlines to capture
a controller state at the requested time, that capture window is a small fraction
inside a single frame. If you haven't watched the 525-line analog video and
Luma videos yet, I recommend you do so as they will help define a few of the
terms I use - vertical blanking, sync pulses, and more. If we examine the read
as a percentage of a graphical frame, it occurs roughly inside this window when
hockey is rolling through its attract screens. Super Mario Bros. has its
controller read a bit earlier during gameplay inside the vertical blanking
interval - very close to vertical sync. Following the read, the remaining time
for drawing the current screen is typically used to process the results
from the controller read to set up the next frame. The vertical blanking period
before the next frame is used to send the new frame's graphics to the graphics
processor. It is this new frame that is the earliest moment in time where the
results of the previous frame's captured controller press can be seen on screen.
Let's talk loosely about input lag. We know that the controller capture window
happens right here. If you press a button beneath that window of time, that action
won't be seen by the Nintendo until the controller captured during the following
frame picks it up. The input captured on the next frame is processed, and the
results won't be seen until the frame after that. This is by design. Whether or
not you consider this a form of input lag is a subject for another video.
Concerning the time between controller reads and the location of those reads - it
can vary from game to game or even game function to gain function when Nekketsu
Hockey is waiting on the Start screen, the controller is
polled at the start of each frame as we saw earlier. When the game is underway,
however, player one is only pulled once every four frames.
I assume this is by design to accommodate four players.
Now for a bit of trivia.
The audio processing unit in the Nintendo has five channels, including
a delta modulation channel that can be used to play DPCM samples. Mario 3 uses
the DMC for drum samples
like the drums used with the dancing palm trees in World 2.
Super C uses it for drums and Orchestra hits.
Unfortunately there is a bug in the NTSC NES and Famicom where
if sampled data is retrieved from memory
at the same time as a controller read, a conflict could occur that corrupts the
data read from the controller. This results in the system thinking a button
was pressed when in actuality it was not. This is typically a right press - the last
bit of a controller read. To compensate for this, games that use DPCM like Super
Mario Bros. 3 perform two consecutive reads of controller data. Both reads are
compared to each other to make sure they are equal before acting upon user input.
Super C reads the controllers in a similar fashion. This bug was fixed with
the PAL CPU revision. Finally, as a bit of an addendum, I wanted to show you two
PCBs from later controllers. The Dogbone NES-039 controller I have with a PCB
from July 1993 has the same size or package type for its shift register as
the original controller, but also has two extra components on the board -
a pair of resistors. One between Power and Latch, and the other between Power
and Clock. An original rectangular controller for an NTSC NES is
incompatible with the PAL control deck. You can add two resistors to the
controller in the same places that are built into the Dogbone controller in
order to add compatibility with PAL and it will still work on your NTSC console.
It appears they added this compatibility to the Dogbone controllers for the
redesigned NTSC consoles. There is a much larger story on controller compatibility
for various international consoles - especially in Europe - however I do not
own any of those consoles.
A second Dogbone controller, HVC-102, has a PCB with a
later date - September 1993 and used a smaller chip for the shift register.
Well! I imagine we could go even further with controllers, but I think that is enough
for this video. I hope you enjoyed this examination of the electronics of the
standard controller for the Nintendo Entertainment System. I value your
feedback, and would love a thumbs up if you enjoy content like this.
Thanks for watching.