Nintendo 64: DragonMinded's description of the VRU
I have some preliminary information on the VRU that shipped with Hey You, Pikachu! I have hit a stumbling block as I don't have a way to sniff the wire and Mess does not currently emulate Hey You, Pikachu! correctly so I can't trade back and forth comparing query captures in Mess to real hardware responses on target. However, from the small amount that runs in Mess, I was able to figure out some very rudimentary things and can reliably detect a VRU plugged in using the detect accessory commands in libdragon.
How to identify a VRU plugged into a controller slot:
The VRU will not respond to normal controller commands (0x01). Attempting to do so will set the error bit in the command response. The VRU does respond to the status command (0x00). To identify a VRU, request status to the serial interface as you normally would. The command returns three bytes and the last two bytes are normally 0x0001 for accessory present (mempak, rumblepak, transferpak) or 0x0002 for not inserted. The VRU will return 0x0100. The first byte is normally 0x05 which identifies the type of controller. On the VRU, it appears as 0x00. This might be another reliable way to determine a VRU as I am unaware of other numbers in this location.
VRU commands:
The VRU appears to have four new commands that it supports: 0x0a, 0x0b, 0x0c and 0x0d. None of these commands are understood at this point to my knowledge, but 0x0b and 0x0d appear to be initialization or configuration commands. I watched Hey You, Pikachu! booting in mess and captured the queries it thought it was sending to the SI and replayed them on hardware to get responses but they weren't enlightening (to me at least).
- The 0x0a command sends 16 bytes to the controller and expects 1 byte in return.
- The 0x0b command sends 2 bytes to the controller and expects 3 bytes in return.
- The 0x0c command sends 6 bytes to the controller and expects 1 byte in return.
- The 0x0d command sends 2 bytes to the controller and expects 1 byte in return.
The initialization sequence I observed through mess was as follows:
0x0b, sent 0x0000, received 0x010097
0x0d, sent 0x1e0c, received 0x00
0x0c, sent 0x000000000100, received 0x97
0x0b, sent 0x0000, received 0x010097
0x0c, sent 0x000002003b00, received 0xf9
0x0b, sent 0x0000, received 0x000000
0x0a, sent all zeros, received 0x00
If the first 0x0b returns error (no controller present), the game will continuously issue this command. Similarly, if the 0x0b command succeeds and the 0x0d command fails due to no controller, the game will go back to 0x0b and try again. I have tried issuing these commands on hardware and the responses always match. It doesn't appear that the N64 has any capability to tell if there is a mic plugged in or not as none of these bits change, but maybe later in the initialization sequence it says something.
Now what?
Mess seems not to run the game as it chooses a bit depth of 0. I stubbed that out to just not draw and it got as far as capturing these commands, but no further which is a pity. If somebody has a LA and can watch the protocol in action then perhaps further progress can be made. Also, maybe if I get an arduino or a pic I can set up a sniffer that can record packets I'm interested in.
