Discussion Controller expansion port documentation (CNT-NUS)

Joined
Mar 17, 2022
Messages
5
Likes
0
Location
Earth
Hi

I was been breaking my nuts a few days trying to find documentation related to the expansion port of the Nintendo 64 controller, and seems that this is the best place to ask for.

Apparently the comunicación protocol between the Nintendo 64 and the CNT-NUS has been hacked a long time ago, since 1999 as I found in old web pages, in honor to my interest they describe the software protocol to identify the kind of device attached to the expansion port, from where I learned that the CNT-NUS just dump to the Controller Pak a data array of 32 bytes (looks like one per pin), and that the Rumble Pak its driven like a SRAM memory in witch the system writes "1" or "0" in order to turn it on or off. They even talk about the two missing buttons of the controller ("X" and "Y")

One said that, there is a complete lack of documentation about for example the Transfer Pak, or the own protocol of the expansion port.

Looks like Nintendo never designed the port for nothing more than the Controller Pak (maybe that's why have this name instead of "Memory Pak"), apparently seeking for cost reduction in their pre-planned 64DD, not even Super Mario 64 (one of the first games, if not the first) have rumble support.
In fact the implementation of the Rumble Pak goes through the IC VDEC-CNT, a proprietary chip that seems to fake a SRAM. And not even the PSU of the system its adapted to stand the high current of multiple Rumble Pak's at onces, that is apparently the reason of why it uses double AAA batteries when is posible make it run without batteries.
The Transfer Pak was developed by Rare focused only in Perfect Dark and with the purpose in mind of read the memory of the Game Boy Camera, that later was discarded, and was the own Nintendo who reuses this device to dump the rom and save-state of Pokemon games (and a few more games).

All the info that I can find in this forum and other webpages its only relative to the communication from the system to the controller and vice versa, with the main purpose of making a USB version of the controller presumably to use it on emulators, and after that, the hijack of the signal to make a Game Cube controller compatible with the Nintendo 64 due the problems replacing the joysticks when they get weared, or even wireless/Bluetooth versions.

On the software side the Controller Pak and Rumble Pak share the same address space, but the Rumble Pak writes go to a pretty high address, outside of the Controller Pak valid area.
Games explicitly check what accessory is currently plugged, and all games supporting multiple accessories have a screen telling you to remove the Controller Pak and insert the Rumble Pak.
As far as I know games only write/read the Controller Pak if it is in the first player controller, almost if is not to make a copy of the data from one Controller Pak to another, but Rumble Pak's can be used in all controllers simultaneously, and Transfer Pak can be used independently in whatever controller port.

All the system have proprietary components, the controllers, the Rumble Pak, and the Transfer Pak, even the cartridges, so this put very hard the challenge of understand what is going on...
My purpose is to design new hardware for the controller, but I need to know the controller expansion protocol and right practices.
Some Chinese manufactures are making Nintendo 64 copycat controllers, so that means that the specifications of the CNT-NUS are already known outside Nintendo, also since their days are Controller + Rumble Pak's that with a simple switch change the device detected, so that mean that the specifications of the VDEC-CNT are also already known.

Someone can help me to find any info about this subjet? schematics about that mentioned Controller + Rumble Pak's? or the Transfer Pak?



Update:




Pin Name
--------------
1 GND
2 A14
3 A12
4 A7
5 A6
6 A5
7 A4
8 A3
9 A2
10 A1
11 A0
12 D0
13 D1
14 Detect
15 3V3
16 D2

17 GND
18 A15
19 /CE
20 /WE
21 A13
22 A8
23 A9
24 A11
25 /OE
26 A10
27 D7
28 D6
29 D5
30 D4
31 3V3
32 D3

 
Last edited:

Gman

RTFDS
Staff member
.
.
.
.
.
Joined
Feb 25, 2016
Messages
1,435
Likes
2,873
The protocol is a parallel interface that works with the SRAM interface with data bus, address bus, chip enable, write enable. You can find the specifics of the timing in the SRAM datasheets. As you already say the rumble pak works by writing to a specific address 0 or 1 to turn on the rumble. From the console, to the controller, to the controller slot the data passes straight through.
 
Joined
Mar 17, 2022
Messages
5
Likes
0
Location
Earth
The protocol is a parallel interface that works with the SRAM interface with data bus, address bus, chip enable, write enable. You can find the specifics of the timing in the SRAM datasheets. As you already say the rumble pak works by writing to a specific address 0 or 1 to turn on the rumble. From the console, to the controller, to the controller slot the data passes straight through.

Da f... I not was expecting a so fast answer and less from a God like you.

What about the "detect" pin (14) and how this Controller + Rumble Pak's switch their identity?

Where can I find an explanation about the CRC?

And what's about the Transfer Pak?
 

Gman

RTFDS
Staff member
.
.
.
.
.
Joined
Feb 25, 2016
Messages
1,435
Likes
2,873

The hardware protocol does not change between any of these adapters. It is still a parallel interface. CRC can be done in software by the game. The actual hardware protocol is just parallel interface with data passing straight through the controller from the accessory to the console. Not much else to it.
 
Joined
Mar 17, 2022
Messages
5
Likes
0
Location
Earth
https://github.com/joeldipops/TransferBoy/blob/master/docs/TransferPakReference.md said:
0x0000 - 0x7FFF Controller Pak Data
When using a Controller Pak/Mempak the actual data stored on the Pak is read from/written to these 32kBs of address space. From what I can tell so far, The Transfer Pak does not use these addresses at all - perhaps there were plans for a combination Controller Pak/Transfer Pak or Controller Pak/Rumble Pak that never came to fruition, and they were reserved for that purpose.
There is the golden nugget...

https://github.com/joeldipops/TransferBoy/blob/master/docs/TransferPakReference.md said:
Memory Addresses and Checksum
Although TPak addresses are presented as 16bit, the lower five bits are not part of the address but are instead reserved for a Checksum. This is why the device is read from and written to in 32byte chunks because that's as precise as the address can get. I've determined that calculating the checksum is not actually necessary to do I/O with the Transfer Pak.
You're right, I dont need to care about the CRC

http://www.qwertymodo.com/hardware-projects/n64/nonvolatile-nintendo-64-controller-pak said:
The Controller Pak connects Detect to 3V3 to indicate the presence of a cart in the slot (this is true for both the Controller Pak and the Rumble Pak; the controller determines which type of cart it is by strobing a specific address and reading the response).
And thats why I'm interested in those Controller + Rumble Pak's schematics...



Thank you very much, you give me a lot to study, gonna take me days to digest this, but seems that there are a way to combine functionalities, to fake a VDEC-CNT, and even to make an IR port or an accelerometer/gyroscope.

I hope that I doesn't brother you if I come in the future with more questions.

If someone can contribute more to this thread I will be glad to check it up.
 
Last edited:
Joined
Mar 17, 2022
Messages
5
Likes
0
Location
Earth
I need to add a correction, Gman is a busy guy and was solved trough Discord.

Pin CE1 in Qwertymondo documentation is flagged, that pin should be called A15.
 
Top