How to Set Up Multi-Tap and Local Multiplayer in RetroArch

Local multiplayer has two layers. RetroArch assigns each physical controller to a RetroPad port; the loaded core then exposes emulated controller devices, including multitaps where the original system used them. A controller can be detected perfectly yet remain invisible to the game because the virtual accessory is absent or attached to the wrong emulated port.

Not every four-player console used a multitap. Nintendo 64, for example, provided four controller ports on the console; calling its normal four-player support a “4-player adapter” is historically and technically wrong. Follow the exact core and game documentation.

Step 1: verify the game’s original multiplayer support

Read the game’s manual or reliable documentation for maximum players, required accessory, and physical port. Some SNES games expect a Super Multitap in port 2; PlayStation games vary between port 1, port 2, or two multitaps; NES/Famicom adapters and controller protocols vary by region/game.

Confirm the exact game revision supports that mode. A title screen may not expose three/four players until the virtual accessory is present at boot.

Step 2: select a core that documents the device

Open the core’s Libretro page and inspect its User device types, core options, and multitap section. Support is not automatic merely because original hardware had an accessory.

Examples differ:

Snes9x activates Multitap by choosing a Multitap device type on the appropriate user/port;
Beetle PSX HW exposes Port 1/Port 2 Multitap Enable core options and up to eight user device types;
FCEUmm exposes a 4-Player Adapter through a documented user device choice.

Do not search for a generic “Enable Multitap” switch that every core supposedly shares.

Step 3: connect and identify physical controllers

Connect controllers before mapping. In RetroArch:

Settings → Input → RetroPad Binds → Port 1 Controls
         → Device Index

Assign a distinct physical device to Port 1, then repeat for Ports 2–N. RetroArch normally follows OS enumeration order, which can change. Use current device-reservation/profile features for stable assignment when supported.

Update controller profiles through RetroArch’s official updater and save a controller profile only after every button/axis is verified. Do not install unsigned virtual-controller drivers to make identical devices distinguishable unless the platform genuinely requires and documents them.

Step 4: separate Device Index from Device Type

Device Index selects the physical gamepad. Device Type under Quick Menu → Controls → Port N Controls selects what the emulated console sees: joypad, analog pad, mouse, multitap, light gun, and so on.

Changing Device Type does not identify a USB brand. Selecting DualShock for a digital-only PlayStation game can leave it unresponsive in analog mode; selecting Multitap on the wrong SNES port can prevent activation. Use the core’s table and the game’s manual.

Step 5: enable the accessory before the game initializes

Set core options or device types, then close and relaunch content if the documentation marks restart or the game probes controllers only at boot. For Beetle PSX, choose the correct port multitap option. For Snes9x, set the documented port’s Device Type to Multitap.

Do not load a state created under a different port topology; it may restore device state from before the accessory existed. Boot clean and load an in-game save.

Step 6: map the expanded player ports

After the accessory is active, confirm how virtual players map to RetroArch users. Assign physical controllers to all required ports, then test one at a time in the game’s player-select or controller-test screen.

Label controllers temporarily. Record physical device label, RetroArch port, emulated accessory slot, and in-game player. If Players 3 and 4 are swapped, correct assignment rather than globally rebinding buttons.

For eight-player PlayStation, test both multitap ports and all memory-card behavior before a long session. Core limits and game limits may differ.

Step 7: create core/game remaps at the right scope

Physical-to-RetroPad binding should describe the controller generally. Use Quick Menu → Controls remap files for how a core/game receives RetroPad buttons. Save a Game Remap for an exceptional layout and a Core Remap only when every title using that core shares it.

Do not use global bindings to compensate for one game’s reversed buttons; that also changes menu navigation and every other core.

Step 8: secure global hotkeys

RetroArch hotkeys are frontend-wide, not ordinary per-player game buttons. Use an Enable Hotkeys chord and bind menu, quit, reset, load state, and disk controls so Players 2–N cannot trigger them through common gameplay presses.

Test every controller. Avoid a one-button load-state or quit binding during local play. If children or public users will play, keep destructive/admin actions on a keyboard or concealed service control.

Step 9: test controller edge cases

Verify diagonals, simultaneous presses, analog range, rumble, disconnect/reconnect, identical controllers, hubs, sleep/wake, and cold reboot. Bus-powered hubs can become unstable with many wireless receivers or rumble devices; use a powered hub meeting its manufacturer’s specification if needed.

Do not hot-plug unknown adapters while diagnosing. Add one device at a time and watch RetroArch notifications/logs for reindexing.

Step 10: validate saves, achievements, and special peripherals

Back up in-game saves before changing PlayStation memory-card topology or core options. Hardcore achievement rules can restrict save states/rewind but normal local controllers are separate; confirm mode and set requirements before the session.

Mouse, light gun, and multitap combinations can be mutually exclusive on a physical port. A game supporting four joypads may not support an accessory plus a light gun simultaneously. Follow original hardware and core limits.

Step 11: save and restart the complete configuration

Save core options through their own Manage Core Options interface, remaps through Controls, and frontend differences through Overrides. These are separate files. Back up all three plus controller profiles and a short port map.

Restart RetroArch, connect devices in the normal order, launch through the playlist, and verify every player. Then disconnect one controller and ensure the remaining assignments fail predictably rather than shifting silently.

Step 12: create a session checklist

Before guests arrive: charge controllers, connect the hub, boot RetroArch, verify Device Index, launch cleanly, confirm multitap/device type, test each player, and protect hotkeys. Keep one known-good spare cable/controller.

The setup is complete when the game advertises the intended player count, each physical controller owns exactly one expected in-game player after restart, and normal play cannot trigger frontend administration.

Related:

Sources: