Input & link communication

Pressing a controller button and connecting two emulated consoles are different tasks. Input turns host-device events into the button state a single GBA can read. Link communication coordinates serial transfers between machines or peripherals. GBAx’s core has separate systems for those jobs, and support in a particular interface depends on more than whether the game itself runs.

From a host button to a GBA button

Your keyboard or controller sends events through the operating system. The frontend maps those events to the console’s button names: A, B, Start, Select, the directional buttons, L and R. It then supplies an active-key state to the core.

The mapping layer matters because controller labels are not universal. A button marked A on one device may occupy a different physical position from a similarly named button on another. The core ultimately needs the intended GBA button, not the printed label or host-device number.

The desktop launcher also uses controllers to navigate its own interface. Confirming a cover selection is a launcher action; pressing GBA A in a running game is an emulated-console action. They may use the same physical button but belong to different input contexts.

1. Host eventA keyboard key, controller button or axis changes.
2. MappingThe frontend translates it into a GBA button state.
3. Register readThe core exposes the expected KEYINPUT value.
4. Game logicThe game polls the state and decides how to react.

KEYINPUT and active-low behaviour

The GBA exposes its buttons through the KEYINPUT register. Its button bits are active-low: a pressed button is represented by a cleared bit. The core can keep an internal active-key mask and transform it into the hardware-facing representation when the register is read.

In the reviewed I/O code, the KEYINPUT read path can call input callbacks before producing the value. It also considers the policy for opposing directions. A real directional pad constrains which combinations can be physically pressed; a keyboard can easily request left and right simultaneously. How that is resolved needs an explicit rule rather than an accidental result from the host device.

This path explains a useful diagnostic distinction. If a game sees a stuck direction, the cause could be an active host axis, an unintended mapping, focus handling or the policy for combined inputs. It is not automatically evidence of an error in the game’s movement code.

Input can request an interrupt

The keypad control register lets software select keys and configure a condition for a keypad interrupt. The core evaluates the requested condition against the active button state and raises the keypad interrupt when appropriate. The normal interrupt-enable and CPU-mask rules still determine whether the processor services it.

This is separate from polling KEYINPUT in a loop. Both routes depend on consistent input state, so it would be incorrect to update a displayed controller overlay without also updating what the core exposes to the game.

What the link hardware does

The GBA serial interface has several modes and control/data registers. Software configures a mode, initiates a transfer and observes status, received data and possibly an interrupt on completion. In a multiplayer arrangement, the participating machines must agree on the exchange they are performing.

The reviewed serial implementation selects its mode from the control registers and delegates parts of communication to a serial driver. It also schedules transfer-completion work through the timing system. This keeps communication within the emulated machine’s timeline instead of treating it as an arbitrary exchange of host bytes.

A serial driver can represent another emulated system or a supported peripheral. The presence of those interfaces in the source establishes an architectural capability; it does not establish that every frontend exposes every mode or that every multiplayer title has been tested.

Why two consoles need coordinated time

Imagine one emulated GBA running far ahead while the other is paused. The first may reach a point where it expects data the second has not produced. A successful link implementation must coordinate progress, transfer order and the state of each endpoint.

Local link coordination and internet play add different engineering problems. Network delay and interruptions cannot be assumed to match the timing of a physical cable. A frontend needs a deliberate synchronisation strategy and a way to handle sessions, connection loss and user actions such as pausing or loading a state.

That is why adding a second controller to one game does not create link multiplayer, and placing two players on a webpage does not make trading work. The connected-machine behaviour has to be implemented and validated.

Desktop controls and the current web player

The supplied desktop interface exposes launcher shortcuts and emulator control settings. Use Controllers & launcher navigation for the practical mappings and a step-by-step test. Those shortcuts are not automatically the web player’s shortcuts.

The website currently integrates EmulatorJS with its mGBA core. It does not configure a link session or provide a GBAx trading/netplay service. Browser gamepad recognition, focus and button mapping also depend on the browser/device. GBAxJS should receive its own tested capability documentation when that project is implemented.

Report the boundary where input fails

For a useful report, note whether the controller can navigate the launcher, whether the emulator’s mapping screen recognises the input, and whether the running game reacts. Include the controller model, connection type, operating system and build. For browser problems, add the browser version and whether the player had focus.

For communication issues, identify the game revisions, intended link mode, participating instances and exact point where progress stops. That evidence distinguishes a control-mapping problem from a serial transfer or synchronisation problem.