********************************* ** ** ** Various NES input devices ** ** v.5 ** ** by Disch ** ** ** ********************************* Intro =================== It was often times hard to find information on the various input devices available for the NES/Famicom. So I figured why not compile a doc with all the information I've gathered. So here it is! Please excuse the crude ascii diagrams. Registers / Ports =================== The NES has two controller ports where various input devices can be plugged into. The NES also has an expansion port on its bottom side.. but I don't know of any devices that used it. On my NES, it even seems to be obstructed by a piece of plastic that you'd have to actually break off to plug something in. The Famicom has two controllers that were hardwired directly into the system instead of having ports you plugged controllers into. It also had an expansion port, which was used far more often because it lacked any normal controller ports. The 2P controller on the Famicom had no start or select buttons, but instead had a microphone. This is probably why some earlier games (like SMB) didn't allow 2P to pause by pushing start. The AV Famicom had controller ports with seperated controllers just like the NES. However its expansion port was like the normal Famicom's, not like the NES's. Writes to $4016 output data to the controllers, and reads from $4016 and $4017 get data from them. Writes to $4017 are unrelated to input devices. When reading $4016 and $4017, unused bits are open bus. $4016 Write: [.... ...C] <--- bit output to the controllers (strobe) [.... .EEE] <--- bits output to the expansion port $4016 Read (NES): [...C C..C] <-- bits read from controller 1 [...E EEEE] <-- bits read from expansion port $4017 Read (NES): [...C C..C] <-- bits read from controller 2 [...E EEEE] <-- bits read from expansion port $4016 Read (Famicom): [.... .M.C] <-- bit read from controller 1 (C), and Microphone state from controller 2 (M) [.... ..E.] <-- bit read from expansion port $4017 Read (Famicom): [.... ...C] <-- bit read from controller 2 [...E EEEE] <-- bits read from expansion port I'm not sure what happens during a conflicting read. For example... when reading $4017... bit 0 could be set by either the controller or the expansion port. Such instances rarely come up, however, as most expansion devices use bits that don't conflict with the controller. Note that bits 5-7 are *always* open bus. This usually means that an effective $40 will be or'd with any joypad data you read. (ie: getting $40 when a button isn't pressed, and $41 when it is pressed, instead of the expected $00/$01). =============================== == The Standard Controller == =============================== Everybody knows this guy. +---------------------------------------+ | | | U | | | | L R SELECT START B A | | | | D | | | +---------------------------------------+ The controller consists of an 8-bit latch (one bit for each button). When the strobe is set, the realtime state of the buttons are recorded to the latch. When the strobe is clear, the actual button states are ignored and the latch data is returned when $401x is read. To operate the controller normally, games will toggle the strobe (by writing 1, then 0 to $4016). This will record the current state of the buttons, then kill the strobe so that data can be read back. Games will then perform 8 reads, each read getting a different button state (in the order: A, B, Select, Start, Up, Down, Left, Right). 1 = button is pressed, 0 = button released. Buttons are read from bit 0, other bits are unused. Note that normally Up+Down or Left+Right can't be pressed at the same time. Some games (Battletoads, Zelda 2) assume this is impossible, and will screw up if those buttons are pressed simultaneously. An example routine for reading P1's joypad data: LDX #$09 STX $4016 ; set strobe DEX STX $4016 ; clear strobe : LDA $4016 ; get button state LSR A ; move it to C flag ROR joydata ; rotate C flag into RAM somewhere DEX BNE :- ; rinse and repeat (8 times) Details: Reading $401x when the strobe is clear will return bit 0 of the latch. The latch will then be right-shift 1 (so that the next button is read on the next read). The bit shifted in is 1... so if a game were to read more than 8 bits of controller data, it would get an infinite stream of 1's after all the button data is read. Reading $401x when the strobe is SET will still return bit 0 of the latch... however the latch is constantly being updated by the realtime state of the button presses. Therefore, when the strobe is set, reading will give you the realtime state of the A button, and won't give you info on any other buttons. Note about the Famicom: As previously mentioned, the 2P controller on the Famicom had no Start/select buttons, but instead had a microphone. I have no idea how the microphone works. It might be as simple as the 'M' bit being read as 1 when it detects sound and 0 when it doesn't. The only game I know that use the microphone is the FDS version of Kid Icarus (you use it to bargain with the shop owners)... but I have yet to examine that game to see how it works. There are also some Kareoke games which may use it. ========================= == The Zapper == ========================= Example games: Duck Hunt Hogan's Alley Gumshoe The zapper is a simple light gun. You'd aim it at the TV and pull the trigger -- there were no other buttons. The zapper essentially consists of 2 parts: a trigger, and a light sensor. The NES zapper plugged into the controller port (usually P2). The Famicom zapper plugged into the expansion port. $401x Read (NES): [...T L...] $4017 Read (FC): [...T L...] (same as the NES when plugged into P2) T = realtime trigger state (1 = trigger pulled, 0 = trigger released) L = light detection (1 = light NOT detected, 0 = light detected) No strobing is required for the zapper... all read data is the realtime state. Light is detected as the PPU renders and the video signal is output to the TV. It's been reported that the signal "fades" after a while, and light is no longer detected by the zapper ~25 scanlines or so after it is rendered. Therefore games must constantly poll the zapper during the frame -- just checking once per frame won't do. The trigger on the zapper is a 2 stage button. When you pull it part way, you hear a soft "click"... this is when T=1. When you pull it the rest of the way, you hear a very loud "CLANG"... then T=0 until you release the trigger and pull it again. Most games look for the trigger bit to transition from 1->0... rather than just looking for the bit to be 1. ========================= == Four Score == ========================= Example games: Gauntlet 2 R.C. Pro Am 2 The four score wasn't so much an input device as it was an adaptor. It plugged into both controller ports of the NES, and had four of its own controller ports... allowing you to plug in 4 controllers at once. $4016 Read (NES): [.... ...C] Controller data from P1, P3 $4017 Read (NES): [.... ...C] Controller data from P2, P4 ?No Famicom version? The first 8 bits read are controller data from P1 or P2 (just like with normal controllers), then the next 8 bits read are from P3 or P4. After that, a "signature" follows, which games check to see whether or not a four score is hooked up. Signatures are read low bit first: %1000 (P1,P3) %0100 (P2,P4) ============================ == Arkanoid Paddle == ============================ Example game: Arkanoid +-----------------+ | | | _____ | | / \ | | / \ | <--- very, very ugly diagram | | | | | | | | | | | | | \ / | | \_____/ | | | | | | B | | | +-----------------+ The paddle was basically just a little circular wheel you could turn clockwise or counterclockwise, with a single button in the corner. The wheel would only turn so far in either direction before stopping. The NES arkanoid paddle can plug into either controller port, whereas the Famicom version plugged into the expansion port. Note that the FC and NES versions operate differently. This can be seen by comparing the (J) and (U) versions of Arkanoid. $401x Read (NES): [...P B...] ------------------------------- $4016 Read (FC): [.... ..P.] $4017 Read (FC): [.... ..B.] P = Wheel position B = Button state The position is read from an 8-bit latch, one bit at a time. Strobing refills/releases the latch.. just like button presses on a standard controller. However, the position is read high bit first. The position can range from 98-242 ($62-$F2) inclusive... and is inverted when read (XOR with $FF). Therefore if a game were to read a position of $0D, that would indicate the wheel is turned all the way clockwise. Button state is read back 1 when the button is pressed, and 0 when release. I'm unsure whether or not button presses are latched like the wheel position or if games just read back the realtime state. ============================ == Arkanoid 2 Paddle == ============================ Example game: Arkanoid 2 (J) Did this ever really exist? I'm unsure whether or not Arkanoid 2 used the same paddle as Arkanoid 1. It seems to operate exactly the same, only the range is 77-227 ($4D-$E3) instead of 98-242. ============================ == Power Pad == == Family Trainer Mat == ============================ Example game: Short Order - Eggsplode (Power Pad) Family Trainer - Meiro Daisakusen (Family Trainer Mat)