CHIRBot, or Computer-Human Input Relay Bot, is an input relay device with the aim of taking any input device and remapping it to any output device with tools to assist humans including input recording, playback, and realtime visualization. This combination of features supports a number of different communities and user needs, ranging from simple usecases like using modern controllers on vintage video game consoles or vice versa (while simultaneously visualizing the input) to more complex usecases such as adaptive controller support combined with macros to help individuals with disabilities interact with a wide range of devices. The project aims to provide an open source hardware, software, and documentation model to foster community expansion. The following document represents an initial design that will need to be refined.

The central core CHIRBot board physically consists of a USB port providing device power along with optional PC connectivity for software reconfiguration and input streaming, a microSD slot for storage, a simple display paired with rudimentary buttons for light configuration tasks, an input module USB Type-C port, an output module USB Type-C port, and an optional visualization display output. The core design uses SPI as a low-latency communication method and a matrix design that allows dynamically selecting the input source from stored or streamed data. Input modules are directly attached and take advantage of the USB Type-C Debug Accessory Mode to pass SPI data and provide module power while ensuring device safety.

The CHIRBot design relies heavily on input and output modules with device-specific hardware to allow native input and output connections. Native connectors such as a SNES controller connector allow a user to directly attach their existing input devices without having to create a cable or an adapter themselves; the modules serve the purpose of providing that adaptation for the user (both physically and electrically). Output modules are designed with controller cable extenders in mind, although in some cases the cable may be an off-the-shelf USB cable to a console.
Each module type has different voltage requirements, connector types, and signaling standards. Each module would be for a single device at a time outside of situations where an auxiliary device was needed to function properly, such as an authentication handshake requirement. Input and output modules are required to convert between native signaling and the SPI communication method used in the core; input and output modules are required for USB native input and output devices.

The initial CHIRBot design assumes only one human input is in use at a time (as opposed to supporting two controllers held by two humans connected to two output devices simultaneously for example). However, there are multiple input and outputs that must be configured as a matrix switch, such as defining that the human input module is the source of input with the vis board, a PC streaming the output for remote purposes or online visualization of inputs on Twitch, a recording file on the attached microSD storage, and the output module as the sink/destination of that data.
Additionally, each module may require additional configuration. For instance, if the output module is an SNES, it may be necessary to define whether the output should be treated as a normal controller, super scope, or mouse. Some matrix switches may be automatic and rapid, such as an input sequence being detected that triggers input from a stored file being played back as a macro that briefly moves the input source away from and back to the human input module.

CHIRBot uses the TASD format defined at https://tasd.io to pass packetized input data via SPI and to store macros and full runs to microSD storage for later playback. The TASD specification is not yet complete and will need additional changes to support some advanced features such as rumble and motion control packet type definitions. The goal would be to use an existing standard notation where possible while retaining the accuracy levels expected of Tool-Assisted Speedrun replay on real hardware.

While the module connected to the target device is considered the output module for flow purposes, the output device is the source of the poll edge itself. For instance, an SNES console will have a dedicated latch signal that identifies when the controller is at the edge of a frame and is requesting input. The input might be polled at 1 ms intervals but the most recent input to be sent is only forwarded on and stored based on the output device polling frequency.

CHIRBot design discussions