Why do the controller registers work this way?

The NesDev page about the standard controller states this:



This means that when the first bit of $4016 is is set, it will keep reloading the "A" button state from the controller, right? When the first bit becomes 0 after having written 1, the state of the "A" button can be read by reading the first bit. After reading this first bit, I can read it again to get the next button. The thing is, why do I have to write 1, then 0, and only then can I read the button states? What's the significance of these first 2 writes? I mean if A is 1 in the first place, why doesn't it keep reloading the "A" button state in bit 1 of $16?

EDIT: The quote is kind of messed up, but it's supposed to point to the S, not to the 7th bit.

Forget everything you know. This is how it works.

Writes make some output pin on the controller ports the same as bit 0 in the data. That's why we write $4016 with #$01, it sets it high. This is called the "strobe" and what it does is makes it "latch" the controller data, which basically means it grabs the current data. We write 0 because it can't be read when the latch is set. Lastly, we read $4016. Each read, a different button's value "shows up" at that spot, so it's NOT always one buttons data, it cycles through it, one bit (or button state) at a time. Here is how to read a controller, in a little basic routine. Don't use this for big stuff, it can be done more efficient, this is just an example.

To add to what 3gengames said, writing the "strobe" bit of $4016 really just writes an internal latch (a storage element that stores a single bit) inside the 2A03/2A07 CPU package (remember that it contains audio, DMA, and other circuitry in addition to the 6502 core). The value of that latch is in turn connected to lines on the controller ports, which the controllers use however they want.

For the standard controller, the value from the latch controls whether the shift registers inside the controllers are in "reload" mode (bit set) or not (bit clear). While in reload mode, the shift registers mirror the button states as follows (this is what "continuously reloaded" means):



When not in reload mode, the shift registers simply hold their value.

Whenever $4016/$4017 is read, you get back the least significant bit from the corresponding shift register, and then the shift register shifts right (given the way I drew it). If reload mode is active, you can see that you'll keep getting the current state of the A button, since the state of B would immediately get overwritten if it was shifted down to A's place.

Edit: So to answer the original question, you could probably have gotten away with a simpler interface if all controllers were like the standard controller, but the interface was designed to be more general than that and latches the values.

The shift registers can be interpreted as shifting left (MSB first) or right (LSB first), and different games interpret it differently. However, the Vaus controller report, the Game Boy link cable interface, the Super NES Mouse report, and the Super NES controller interface suggest that it shifts left. Furthermore, testing A and B becomes as easy as BIT/BPL and BIT/BVC; Right and Down aren't quite as useful for that.

I didn't think it was that simple, but you guys explained it really well. I now understand what I need to understand about the whole $4016 write thing. Thanks a lot!

At first it seems inferior to the simple parallel interfaces of systems like Atari and Master System, but those don't offer endless possibilities of how to write (and optimize [and mis-optimize])) the controller reading code. And the serial interface lends itself to easy expansion, for example the SNES controller and being able to easily wire it to a NES.

The Atari protocol was extended to become the SMS protocol, which was extended to become the Genesis protocol, which was extended to become the Genesis 6-button, 4-Way Play, and Team Player protocols. That's because the Genesis controller ports are just 7-bit GPIOs. The NES, on the other hand, has one pin hardwired to clock, one pin hardwired to output shared between both ports, and three pins hardwired to input. Even running a GB/GBC style SPI master is tricky because circuitry in the cable needs to recover select and MOSI from the one output.

Actually the chain ends at the 6-pad, the multitaps are not compatible (well, except maybe EA's to some extent since it behaves as a port multiplexer). But yeah, Sega managed to extend the protocol quite far, and in fact the way the 6-pad protocol works effectively gives it infinite permutations (since it advances by bit toggling).

How can we rephrase the page on the wiki to have answered your question in the first place?

Maybe, you've should just read the HEF4021BP datasheet?

In joypad all buttons goes to GND (active level is logic 0), inside console an inverting buffer is present. Thus, pressing the button becomes a logic 1.