-
Notifications
You must be signed in to change notification settings - Fork 4
Command details
This is a detailed overview of all the commands listed in the JVS-I/O specification.
These commands can only be broadcast, i.e. sent to address 0xFF. They apply to all nodes, or in the case of command 0xF1 to a node determined by the sense line.
This command resets the bus to the power-on state. This means that the [address setting procedure](Address setting procedure) must be executed again.
None.
None.
This command issues an address to the node determined by the sense line. See [Address setting procedure](Address setting procedure) for more details.
The single-byte bus address to assign
Two bytes: One status byte and one report byte.
This command sets the communication mode used on the bus. This isn't useful for the basic protocol, but is part of a mechanism to support different protocols along with command 0x13 ('get communications version').
A single-byte communication method ID.
None.
None.
The reply is a status and report code, followed by a zero-terminated string identifying the addressed I/O board. This string consists of the manufacturer name, the product name, the product version and a comment field separated by semicolons.
This command requests the command format version implemented by the addressed device.
None.
A status and report code, followed by a single byte containing the version number as BCD. For example, 1.3 is encoded as 0x13.
This command requests the version of the Jamma Video Standard implemented by the addressed device.
None.
A status and report code, followed by a single byte containing the version number as BCD. For example, 3.0 is encoded as 0x30.
This command requests the version of the communications protocol implemented by the addressed device.
None.
A status and report code, followed by a single byte containing the version number as BCD. For example, 1.0 is encoded as 0x10.
This command requests a list of features supported by the addressed device.
None.
The reply for this command is fairly complex. It consists of a list of single-byte feature codes. The feature code '0' indicates the end of the sequence, any other feature code describes support for a specific feature in the JVS I/O standard and has three single-byte arguments. The feature codes and their arguments are listed in the table below.
| feature code | description | argument 1 | argument 2 | argument 3 | comments |
|---|---|---|---|---|---|
| 0x00 | exit code | N/A | Has no arguments. | ||
| Inputs | |||||
| 0x01 | number of players and switches | number of players | number of switches per player | 0 | |
| 0x02 | coin slots | no. of slots | 0 | 0 | |
| 0x03 | analog inputs | no. of channels | effective no. of bits per channel | 0 | 0 bits/ch = unknown |
| 0x04 | rotary encoders | no. of channels | 0 | 0 | |
| 0x05 | keypad input | 0 | 0 | 0 | |
| 0x06 | light gun | effective X bits | effective Y bits | no. of channels | |
| 0x07 | general-purpose switches | high byte | low byte | arg is 16-bit no. of switches | |
| Outputs | |||||
| 0x10 | card system | no. of slots | 0 | 0 | |
| 0x11 | token hopper? | no. of channels | 0 | 0 | machine translation says 'medal hopper' |
| 0x12 | General-purpose output | No. of banks | 0 | 0 | Each bank consists of 8 bits |
| 0x13 | Analog outputs | no. of channels | 0 | 0 | |
| 0x14 | Character displays | characters/line | no. of lines | encoding | encodings: 0=unknown, 1=ascii numeric, 2=ascii alphanumeric, 3=alphanumeric/katakana, 4=alphanumberic/SHIFT-JIS |
| 0x15 | Backup | 0 | 0 | 0 | Likely some sort of non-volatile memory |
This informs an I/O board of the identity of the bus master.
A zero-terminated string that gives the identify of the bus master, formatted like the reply to command 0x10.
Status byte and report byte.
This commands reads the player input switch state.
The first argument is the number of players to read data for, the second argument is the number of bytes to read
The reply consists of status and report codes, a general switch status byte, then the requested switch data. For p players and n bytes per player requested, this implies n*p+1 bytes of switch data. The lay-out of the switch data is given in the table below.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| byte 1 | TEST | TILT1 | TILT2 | TILT3 | unused | |||
| byte 2 | P1 start | P1 service | P1 up | P1 down | P1 left | P1 right | P1 push 1 | P1 push 2 |
| byte 3 | P1 push 3 | P1 push 4 | P1 push 5 | P1 push 6 | P1 push 7 | P1 push 8 | - | - |
| ... | ||||||||
| byte n | P2 start | P2 service | P2 up | P2 down | P2 left | P2 right | P2 push 1 | P2 push 2 |
| byte n+1 | P2 push 3 | P2 push 4 | P2 push 5 | P2 push 6 | P2 push 7 | P2 push 8 | - | - |
This reads information from coin processors.
One argument: the number of slots to read
For each slot, two bytes are returned. The highest two bits of the first byte contain a status code for the device. The status codes are given in the table below. The rest of the bits contain the number of counted coins for the device.
| Interpretation of coin slot status codes | |
|---|---|
| Code | Meaning |
| 0 | Normal operation |
| 1 | Coin jam |
| 2 | System disconnected |
| 3 | System busy |
This reads analog imputs information.
One argument: the number of inputs to read
For each input, two bytes are returned. The highest two bits of the first byte contain a status code for the input. The next byte contain the analog value (8 bits value).