This is not true! I told KR155E about it yesterday and he didn’t change it! Bah!

Here’s how you process controller input on NES:

* Write a 1 to bit 0 of 0x4016. This sends a latch signal to both controllers.
* Write a 0 to 0x04016 to disable the latch signal.
* Read from 0x4016 8 times for controller 1, or 0x4017 8 times for controller 2.
* Each time, bit 0 will specify one button, in the following order: A, B, Select, Start, Up, Down, Left, Right
* You can compose a byte value for controller input by using bitwise OR and left shift each time you read.

This is how you process controller input on Virtual Boy:

* Write a 1 to bit 5 of 0x02000028. This sends a latch signal to the controller.
* Proceed to write 0 to bit 5 of, and alternating 1 and 0 to bit 4 of, 0x02000028. This will send the inverted bits (0, 1) to the controller.
* Each time a 0, 1 cycle is sent to the controller, it sends back one button. So repeat the cycle 16 times.
* Read from 0x02000010 for the low 8 bits of controller input, and from 0x02000014 for the high 8 bits of controller input.

Alternately:

* Write a 1 to bits 7 and 2 of 0x02000028. This initiates a hardware read.
* Wait until bit 1 of 0x02000028 becomes 0.
* Read from 0x02000010 for the low 8 bits of controller input, and from 0x02000014 for the high 8 bits of controller input.
* Optionally, writing a 0 to bit 7 will raise an interrupt when the hardware read completes, but only if any button(s) other than A or B are pressed.
* The hardware read is significantly slower than sending the 0, 1 signals to the controller through software.

Did you know… ? (-:

Thanks for the detailed explanation! I tried hard to remember where that info came from and I am pretty sure that it was a discovery made by DogP, but I couldn’t find anything about this anywhere… strange. Well, I am gonna remove that bit of info.

Actually, that’s quite true; you just have the wrong end of the stick, so to speak.

Notice that it says “protocol” not “subroutine”. It’s referring to the way the data physically flows from the controller to the machine, which is precisely the same on the NES, SNES, and VB (except for the length of the “packets” and the number of actually used bits). It has nothing to do with which registers are used to control the hardware or access the data once it’s inside the CPU. Obviously these are going to be different, since the VB doesn’t use a 6502-derivative.

RunnerPack wrote:

Notice that it says “protocol” not “subroutine”.

By definition, a protocol is used by software for exchanging data. The means by which data is transmitted on a wire is called an encoding.

Though the encoding on the wire may be the same or similar (I’m not sure if both use low/high cycles) on NES and Virtual Boy, the protocol by which the software communicates with the controller is different.

RunnerPack wrote:

Obviously these are going to be different, since the VB doesn’t use a 6502-derivative.

I’d just like to point out that the behavior of the input hardware is independent from the CPU being used. (-:

Guy Perfect wrote:

By definition, a protocol is used by software for exchanging data. The means by which data is transmitted on a wire is called an encoding.

From http://en.wikipedia.org/wiki/Communications_protocol (emphasis mine):

A communications protocol is a system of digital message formats and rules for exchanging those messages in or between computing systems and in telecommunications.

If we take the binary data sent by the various controllers as the “message format” and the “latch, then shift while reading” process as the “rules”, then what you call an “encoding” seems to fit Wikipedia’s definition of a protocol. And there’s more:

A protocol definition defines the syntax, semantics, and synchronization of communication; the specified behavior is typically independent of how it is to be implemented.

Syntax is the particular arrangement of symbols (in this case logic bits) and the semantics is the information carried by them (in this case, button states). The synchronization part is self-explanitory… Now, notice that part about being independent of implementation.

(This space intentionally left blank to keep from sounding smug and patronizing. ;-))

Though the encoding on the wire may be the same or similar (I’m not sure if both use low/high cycles) on NES and Virtual Boy, the protocol by which the software communicates with the controller is different.

Actually, they are precisely the same, evidenced by the fact that NES (and SNES) pads (and even mice) have been connected to the VB using only wire and connectors (link). Also, as stated above, the syntax and semantics of the data are even compatible (i.e. the equivalent button states between the three pads are represented by the same bits in the data).

RunnerPack wrote:

Obviously these are going to be different, since the VB doesn’t use a 6502-derivative.

I’d just like to point out that the behavior of the input hardware is independent from the CPU being used. (-:

Actually, since the hardware relies on being attached to said CPU via an I/O port, and these are implemented differently on each CPU (given things like size of address space, bus architecture, and endianness), I beg to differ. However, since the protocol is defined independently of the CPU, this is moot.

Now, having said all that, I’m willing to concede that the “Did you Know…” could be written less ambiguously. I propose this:

“…that NES and SNES controllers can be connected to the VB?”

I think that gets the point across without getting bogged down in the details.

And with that, I offer my (metaphorical) hand in a sign of friendship. I hope that you will (metaphorically) shake it and we can be friends 😀