TribalTap
The Tribal Tap is a multitap made by Naki. This company still exists or at least is related to Naki-World.
There is a Tribal-Tap 5 which should be similar to a Hudson multitap (I do not own one to test), allowing four joypads to attach to one SNES controller port. Therefore with one joypad in the other controller port, this allows for five player play.
There is also a Tribal Tap which allows five joypads to attach to one SNES controller port. It has a three position switch allowing selecting the mode: 2p, 5p, 6p.
Contents
- 1 Tribal Tap 6
- 1.1 Controller connectors
- 1.2 Switch
- 1.3 IC Chip
- 1.4 Fraud Warning
Tribal Tap 6
The PCB is one sided and the only components (besides resistors, or capacitors) are two transistors, an LED, the port connectors, and a 20 pin IC. Strangely, the controller ports are mislabelled on the PCB compared to the plastic case. All reference to controller port numbers in this article will refer to the numbers on the case.
I've looked at three of these devices. On all the IC chip had been sanded to remove the identity. On one PCB the IC was in a socket for easy removal. For the device to work, all 7 lines to the SNES are used. Despite being wired to allow all lines to pass through to the 2nd port (assumedly intended for the 2p setting), all 5 input ports use the cheap connectors that only use 5 lines (the IO line and the second data line are unconnected).
Controller connectors
P2:
This is special, as it is the only controller port that has traces going to all 7 pins. It probably was designed to pass all lines through for 2p mode for compatibility, but in the end they were cheap and used a connector that only uses Gnd, d0, latch, clk, Vcc (leaves out d1, and IO).
For this port the SNES-clk is a direct connect through.
For some reason it doesn't share the latch line with the other controllers either.
Vcc connects directly to SNES line.
P3-P6:
The latch line is common between these ports.
Vcc is controlled by the switch and a transistor.
P4-P6:
The clk line is common between these ports.
Switch
pin 5, pin 7 of IC
+------+-------+
mode 2p | Vcc | Gnd |
mode 5p | Vcc | Vcc |
mode 6p | Gnd | Vcc |
+------+-------+The switch and a transistor also controls the Vcc of P3-P6 ports.
The switch connects to base of NPN transistor (part S9013).
- Collector connects to Vcc from SNES.
- Emitter connects to controller P3-P6 Vcc.
- The switch (base) line also connects through resistor then LED to Gnd. When in 2p mode, this switch line is connected through a resistor to Gnd. In 5p and 6p mode it is connected straight to SNES Vcc.
Pin 5 is pulled up to Vcc, and the switch does nothing except for 6p mode where it pulls it to Gnd.
Pin 7 is pulled up to Vcc, and the switch does nothing except for 2p mode where it pulls it to Gnd.
Note on 5p and 6p modes:
I have yet to find anything that distinguishes between 5p and 6p modes from the SNES side. Nothing seems to give data on the player 6 controller.
IC Chip
The pinout of the IC chip matches that of a simple PAL.
___ ___
SNES, clk - I0 - 1 V 20 - Vcc
SNES, IO - I1 - 2 19 - B7 - SNES, D0
P2,d0 - I2 - 3 18 - B6 - SNES, D1
P2,d1 - I3 - 4 17 - B5 - P2,latch
deals with switch - I4 - 5 16 - B4 - P2,IO
P3,d0 - I5 - 6 15 - B3 - P3,clk
deals with switch - I6 - 7 14 - B2 - P4-P6,clk
P5,d0 - I7 - 8 13 - B1 - P3-P6,latch
P4,d0 - I8 - 9 12 - B0 - P6,d0
Gnd - 10_______11 - I9 - "inverted" latch
Pins 1-9 are pulled up to Vcc using a SIP resistor pack.
pin 11 is pulled high by a resistor, and goes to a transistor.
Transistor is NPN (part S9013).
Collector connects to pin 11.
Emitter is grounded.
Base goes to two resistors, one to ground and the other
connects to the SNES-latch signal (which is also pulled high by
yet another resistor).
This is acting as an open collector inverter for the latch signal to pin 11.With tests, I found the logic table to be:
With latch line low:
IO=1
controllers 4-6 don't get clock signal
IO=0
controllers 4-6 gets clock signal
controllers 3 doesn't get clock signal
(controller 2 always gets controller signal due to
how they designed the device)
Full table for snes-d0, snes-d1:
B7 =
!I6 & I2 /* in 2p mode, just follow controller port 2, d0 */
# I6 & I1 & I2 /* in multitap mode, if IO=1 follow controller port 2, d0 */
# I6 & !I1 & I8; /* in multitap mode, if IO=0 follow controller port 4, d0 */
B6 =
!I6 & I3 /* in 2p mode, just follow controller port 2, d1 */
# I6 & I1 & I9 & I5 /* in multitap mode, if IO=1, latch low, follow controller port 3, d0 */
# I6 & !I1 & I9 & I7; /* in multitap mode, if IO=0, latch low, follow controller port 5, d0 */First, it is apparent this is not compatible with the official multitap. When the latch line is held high, SNES-d1 will be pulled low (will read as 1). However snes-d0 still responds, but since latch is held it is basically just continually reading the B button. To be compatible, snes-d0 here should be pulled high (will read as 0). This will screw up multitap detection in any game that follows Nintendo's recommended programming procedures, whenever the second player presses the B button.
Even more importantly, notice nothing depends on B0 (the p6 data line). Therefore, it appears impossible to use the sixth controller port. I asked Charles MacDonald to double check this with a device he built that automatically checks all possible input combinations. He used a different device, and got the same logic table I found.
The only possible way this device could still work is if there was some kind of 'activation sequence' that enables the true 6p mode. I tried everything I could think of, including looking for a game that actually supports 6 players using this device (which many people claim exists, some even naming specific games which clearly do NOT support 6 players).
To solve this once and for all, I decapped the logic chip to figure out its identity. It was found to be a Texas Instruments 16L8 PAL. This means the logic is completely combinatorial and thus cannot have an internal state necessary to be waiting for some activation sequence. It is physically impossible for this device to support 6-player play as it claims on the box.
Fraud Warning
To repeat the above: This device is not fully compatible with the official multitap, and is not capable of allowing all 5 connected controllers to be read. This device does not and cannot work as advertised. It is a fraud.
I called Naki who told me they underwent a restructing around 2005, and not only do they no longer support old devices, but no internal documentation for the Tribal Tap still exists at Naki. So I am not sure what exactly happenned during the design and manufacture of this device.
What is weird, is that it appears it COULD have been programmed to be fully compatible, and the circuit design is such that it COULD allow the 5th controller to be read. So I really have to wonder if at some point they changed the PAL design or something ... maybe some really old TribalTaps actually worked?
In particular, there is a switch allowing choosing between a 5player and 6player setting. The logic is currently setup so that there is no difference. Why pay for all the extra (switch, LEDs, etc) and even wire it such that it could possibly work? I am very very tempted to believe that some old TribalTaps (at least a prototype) actually worked.
Test if your TribalTap is a fraudulent device:
The way the circuit is laid out, I don't think the 6player setting (if logic is chosen so that all controllers can actually be read) can be backwards compatible (and hence why they put in a switch). So to test if you have a real device, just play a multitap game and see if it works the same in both 5p and 6p setting... if not, you probably have a real "no-fraud" device. If they are the same as with all TribalTaps tested so far (I bought several, and also cgfm2's tests), you too have a fraud device.
