JVS Protocol: A Practical Technical Reference (JVS-001)

What JVS covers—and what this reference covers

JVS (JAMMA Video Standard) defines interfaces for arcade systems. This independent technical reference concentrates on the conventional serial I/O protocol: discovering I/O boards, reading switch and coin inputs, reporting capabilities and controlling supported outputs. It does not replace the full original cabinet-power, audio or video electrical standard.

A game system acts as host; dedicated I/O boards act as addressed nodes. Sega, Taito, Namco and other vendors implement overlapping JVS capabilities, but manufacturer extensions and game-specific requirements cannot be assumed compatible.

Evidence labels in this article distinguish normative/reference descriptions, firmware-derived observations, external hardware captures and synthetic packet examples. Rare command-parameter contracts should be checked against the original specification and actual board revisions.

System architecture and bus roles

The host sends a request and a node sends a reply. A JVS node reports its available switches, coin slots, analog inputs and outputs rather than every host assuming a fixed cabinet layout. Boards can be chained; the sideband SENSE circuit participates in identifying which board has not yet received an address.

The practical flow is game software → JVS host → differential serial transceiver → cabinet I/O board → physical controls. Data from switches and coin counters travels back through requests and responses.

GAME / HOST (master)
   |  RS-485 data + SENSE chain
   v
JVS I/O NODE 1  [address 01]
   |  optional downstream connection
   v
JVS I/O NODE 2  [address 02]
   |
   +--> switches / coins / lamps / analog devices

Physical communication and connector hazards

The classic JVS I/O link uses half-duplex RS-485 differential signaling with a baseline UART format of 115200 baud, eight data bits, no parity, one stop bit (8N1). Only one RS-485 driver should actively transmit at a time; a node must retain its driver enable through the final stop bit.

The connector may resemble USB, but normal JVS RS-485 and SENSE are not USB signalling. Do not connect a PC USB host, ordinary USB controller or untested adapter to a JVS connector because the plugs fit. Power arrangements, cable pinout and connector direction must be confirmed for the exact board.

Termination, ESD protection, biasing and power-domain protection depend on the cabinet topology. This reference deliberately does not prescribe a universal termination resistor or an unverified connector wiring recipe.

SENSE and address assignment

SENSE is an electrical state signal involved in JVS chain discovery. A useful practical model distinguishes a high state with no effective attached unaddressed device, an intermediate voltage for an unaddressed node and a low state after an address has been accepted. These are qualitative regions, not universal comparator thresholds.

Our original Sega 838-13683-93 Rev.B work traced a passive diode SENSE path and a switched pull-to-ground path. Its SP5001-B firmware activates the latter after successful F1 address assignment. That finding concerns this identified Sega board and must not be silently generalized to every manufacturer.

Approximate 5 V / 2–3 V / 0 V observations exist in historical implementations, but the actual pull-up, voltage thresholds, downstream propagation and protection must be measured on the intended platform.

Logical JVS frame format

Every conventional packet begins with SYNC E0, followed by destination address, one-byte logical length, payload bytes and a one-byte additive SUM. Request payloads contain commands; response payloads begin with a packet-status byte and then contain per-command reports and data.

LEN counts decoded logical bytes after the LEN field, including the final checksum. Thus if a request contains N payload bytes, LEN = N + 1. The additive SUM is (destination + LEN + all decoded payload bytes) modulo 256; neither the initial SYNC nor the checksum itself participates.

The broadcast destination is FF; replies address the host at 00. The first assigned node is typically 01. An escaped physical frame can be longer than its unescaped LEN.

REQUEST  E0  DEST  LEN  CMD [ARG...] [CMD ARG...]  SUM
REPLY    E0  00    LEN  STATUS REPORT [DATA...]    SUM

LEN = number of decoded PAYLOAD bytes + 1 (SUM)
SUM = (DEST + LEN + sum(decoded PAYLOAD)) & 0xFF

SYNC E0 is not included in LEN or SUM.

Escaping reserved bytes D0 and E0

A logical E0 inside a frame body could be mistaken for another SYNC. Therefore E0 is transmitted as D0 DF; D0 is transmitted as D0 CF. The encoder applies this to fields after the initial SYNC, including an escaped checksum if necessary.

The receiver must restore the original logical values before validating length and SUM. For example, logical D0 E0 becomes physical D0 CF D0 DF; the expanded physical bytes do not change the logical LEN.

Byte-by-byte request and response

To request command-format revision 11 from node address 01, send E0 01 02 11 14. The checksum equals 01 + 02 + 11 = 14. The synthetic response assumes a node reporting revision 1.1 (BCD 11), with packet status 01 and individual report 01.

These are independently calculated examples, not traces captured by our workshop. They illustrate that packet status, command report and returned version are separate fields.

HOST -> NODE 01:
E0 01 02 11 14
   |  |  |  +-- SUM = (01+02+11) & FF = 14
   |  |  +----- command 11 (revision)
   |  +-------- LEN = 02 (command and SUM)
   +----------- destination 01

NODE -> HOST (example version 1.1):
E0 00 04 01 01 11 17
   |  |  |  |  |  +-- SUM = 04+01+01+11 = 17
   |  |  |  |  +----- BCD revision 11
   |  |  |  +-------- report 01 (success)
   |  |  +----------- packet status 01 (normal)
   |  +-------------- LEN = 04
   +----------------- reply destination 00

Reset, enumeration and identity discovery

An ordinary host resets node addressing, then assigns addresses to unaddressed devices one by one while monitoring SENSE and acknowledgments. The widely used F0 D9 reset request is broadcast to FF; F1 plus the requested address is also broadcast. Once assigned, the node is queried with commands 10 (ID), 11 (command version), 12 (JVS version), 13 (communications version) and 14 (functions).

Actual hosts may repeat the reset, use command 15 to convey their ID or perform vendor-specific setup. Timeouts, retries and RS-485 turnaround policy must be established on the target hardware; a generic single-node discovery demo is not proof of multi-node compatibility.

BROADCAST RESET:         E0 FF 03 F0 D9 CB
BROADCAST ASSIGN NODE 1: E0 FF 03 F1 01 F4
READ ID FROM NODE 1:    E0 01 02 10 13

RESET does not normally solicit an individual reply.
ADDRESS assignment normally produces an acknowledgement.

Core discovery commands 10–15

Version query responses use one packed BCD byte: command version 11 can report 11 (1.1), JVS version 12 can report 20 (2.0), communications version 13 can report 10 (1.0). These are an example of a real Sega firmware profile, not universal constants.

Command 10 returns a NUL-terminated board identification string. A host must bound-check it and not assume a manufacturer name guarantees that factory firmware is installed.

Capability tuples returned by command 14

Command 14 returns feature records formatted as CODE, P1, P2, P3; a single 00 code terminates the list. The actual interpretation depends on the feature. The host should retain the raw tuple, validate the terminator and select polling commands based on advertised functions.

For example, code 01 commonly specifies the number of players and buttons per player; code 02 specifies coin slots; code 03 specifies analog channels and effective bits. Manufacturers sometimes change the advertised functions with DIP switches or board configuration. A feature entry does not prove that a cabinet's cable is actually connected.

Digital inputs: command 20 and button mapping

Command 20 requests the number of players and bytes of digital data per player. A successful response contains one system-switch byte followed by the requested bytes for each player. The command-level report precedes those bytes, and the packet-level status precedes the report.

The first common player byte carries Start, Service, Up, Down, Left, Right, Button 1, Button 2 from bit 7 to bit 0. A following player byte carries additional buttons. The shared system byte includes Test and, on relevant profiles, tilt inputs. JVS logical reports normally set the bit for a pressed switch even when the physical switch is active-low.

Respect the capability report: a two-player board with six buttons is not automatically identical to a four-player board or a switch matrix with extra player bytes.

Digital switch polling: full example

This synthetic request asks node 01 for two players and two bytes per player. The synthetic reply encodes no system switches, P1 Start pressed, P2 Right pressed and no other input. LENGTH in the response is eight logical bytes after LEN: packet status, command report, system byte, four player bytes and checksum.

Every displayed SUM is computed modulo 256 from the decoded logical bytes. This example is a self-contained test vector, not an observation of a specific Sega, Namco or Taito cabinet.

HOST -> NODE 01:
E0 01 04 20 02 02 29
   |  |  |  |  |  +-- SUM = 01+04+20+02+02 = 29
   |  |  |  |  +----- 2 bytes per player
   |  |  |  +-------- 2 players
   |  |  +----------- command 20

NODE -> HOST:
E0 00 08 01 01 00 80 00 04 00 8E
   |  |  |  |  |  |------| |------|
   |  |  |  |  |  P1 2B    P2 2B
   |  |  |  |  +-- system switches 00
   |  |  |  +----- report 01
   |  |  +-------- packet status 01
   |  +----------- LEN = 08
   +-------------- destination 00

P1 80 00 = START pressed; P2 04 00 = RIGHT pressed.
SUM = 00+08+01+01+00+80+00+04+00 = 8E

Coin counters: read 21 and adjust 30/35

Command 21 reads the requested coin slots. Each reports a 16-bit word: the high two bits convey a device condition and the remaining 14 bits represent the counted coins. The host must interpret deltas, resets and counter wrap rather than treating coin input as an ordinary momentary button.

Command 30 decreases a coin count and 35 increases it on nodes that support these operations. The response's outer packet status is not the same as the two-bit condition encoded in each coin slot; credit and accounting policy also depend on the particular host.

Analog, rotary, keypad and position inputs

Command 22 reads analog channels; values are typically returned as a pair of bytes per channel, while the effective resolution is advertised by function 03. Width, alignment and calibration should be interpreted against the actual board instead of assuming all analog controls produce an eight-bit number.

Command 23 covers rotary encoders, 24 keycode/keypad, 25 screen-position/light-gun data, and 26 general switch inputs. These capabilities are optional. Verify their argument widths, returned channel data and interpretation with the appropriate JVS standard revision and real implementation traces.

A screen-position capability does not itself guarantee operation with a particular display, gun technology or game.

Output, payout and retransmit command families

Optional JVS functions include 2E payout state, 2F retransmission of an earlier response, 30/35 coin-count adjustment, 31/36 payout adjustment, 32 general-purpose outputs, 33 analog outputs, 34 character displays and 37/38 alternate output modes. Command F2 changes communications mode on supporting systems.

These names do not constitute a full parameter-by-parameter contract for every standard revision. The exact request payloads, output bank arrangement, access privileges and reporting must be verified against the original specification and the particular firmware. Some output commands can energize external devices: do not send them blindly to an unknown board.

Our Sega SP5001-B reconstruction has dedicated handlers for F0, F1, 10–14, 20–22, 2F, 30, 32 and 35; implementing fewer commands is not necessarily a fault when a capability was never advertised.

Packet status, reports and recovery

Responses distinguish an overall packet status from one per-command report. In standard/common implementations the packet-level status values include 01 normal, 02 command unknown, 03 checksum failure and 04 overflow or similar packet condition. Per-command report codes distinguish successful command handling from individual unsupported/parameter/busy cases; exact behaviour and extensions must be checked per firmware.

A missing reply is not equivalent to a checksum error; nor is an unsupported command evidence that a whole I/O board is disconnected. A correct host may retry, use 2F retransmission if available, re-enumerate nodes after a reset or surface a specific error depending on policy.

Capture both physical UART bytes and decoded packets when troubleshooting, especially if SUM or payload bytes were escaped.

Manufacturer differences: evidence from our research

Our Sega 838-13683-93 Rev.B SP5001-B firmware study identifies 115200 8N1 UART configuration, an E0/D0 parser, a command jump table, 14 dedicated handlers and RS-485 transmit direction. It also correlates an active SENSE sink with accepted F1 address assignment. This is first-party reconstruction of a specific original board, not an official general JVS rule.

A Taito K91X1130A response published in the Arcade-Projects JVS information-extractor thread advertises switch, coin, analog, screen-position, generic output and analog output functions. That is a THIRD-PARTY hardware capture, and the K91X1130A must not be confused with the separately acquired K91X1215A.

Our Namco WAJVIO 2.04 vs 2.1.1 host-library analysis describes different polling and multi-node scheduling policies above the same framing layer. An unknown-firmware 98701-labelled Capcom converter reported an unexpected ID in the public extractor corpus; that ID alone does not prove factory firmware provenance.

Implementer's validation checklist

Separate the RS-485 transport, escape codec, logical packet parser, JVS request/response state machine and electrical SENSE logic. Assert and release the driver using the transceiver's actual TX-complete state; a FIFO becoming empty is not necessarily completion of the final stop bit.

Reject malformed lengths, dangling D0 escapes, unchecked variable-length IDs, checksum errors, invalid destination and unsupported function counts. Bound every parsing buffer. A clean host software test suite does not qualify a 5 V board or cabinet connector.

Before declaring compatibility, log the exact host, I/O PCB and revision, firmware, chain order, cabling, power conditions and bus trace; test resets, address transitions, representative switch/coin polls, error recovery and safe outputs.

• Verify host/node identity, addresses and advertised function tuples.
• Instrument the RS-485 A/B pair, driver enable, SENSE voltage and serial timestamps.
• Record physical encoded packets alongside decoded logical packets.
• Test F0, F1, ID/version/function discovery, polling and normal responses.
• Test malformed LEN, checksum mismatch, D0 escapes, absent node and timeouts.
• Leave all external outputs in a safe default state during startup and faults.
• Treat a given product/board revision as qualified only after physical hardware testing.

Document scope, provenance and next revisions

This JVS-001 edition covers common serial framing, electrical sideband, discovery, core capabilities and major command families, not every optional command field across all JVS specification revisions or proprietary variants. The original Japanese issue and implementation-specific documentation remain authoritative for uncommon hardware.

Our Sega and Namco engineering records are held privately; this public page summarizes evidence without distributing proprietary ROMs or firmware. Any third-party hardware observations are attributed; all sample packets are synthetic and their checksums independently validated.

Changes based on future oscilloscope captures, revision-specific command responses or a corrected reading of the standard should be made with date and scope. USB2JVS is a research project, not a commercially qualified or purchasable product.