HEX CODE COMMAND PRIORITY
FX XX XX goto Frame #XXXXX & play forward 1
DX XX XX goto Frame #XXXXX & halt (first field) 1
00 00 -- play forward 1
00 10 -- play reverse 1
00 20 -- halt (frame) 1
00 30 -- reserved
00 4X XX slow forward @ XXX speed parameter 1
00 5X XX slow reverse @ XXX speed parameter 1
00 60 -- reserved
00 70 -- reserved
00 80 -- reserved
00 90 -- reserved
00 A0 -- scan forward @ 75 times normal speed 2
00 B0 -- scan reverse @ 75 times normal speed 2
00 C0 -- reserved
00 D0 -- reserved
00 EX XX jump immediately XXX tracks forward 2
00 FX XX jump immediately XXX tracks reverse 2
02 MM NN Video Audio-I Audio-II CX controls 2

Where MM is the mask for which bits to change and NN contains the new value

The bit fields are:

B7 = reserved
B6 = reserved
B5 = reserved
B4 = reserved for Display ON/OFF
B3 = CX ON/OFF
B2 = Audio-II ON/OFF
B1 = Audio-I ON/OFF
B0 = Video ON/OFF


VP931 Communications Protocol
TENTATIVE
08-AUG-83
L. Schwartz



OVERVIEW:

The VP931 is a videodisc system designed to be connected to an external controller (or controlling computer) via an 8-bit parallel interface. It incorporates an internal subcontroller for passing Manchester data and player status codes to the external controller, and for receiving commands from the external controller. Manchester data and player status codes are passed once each video field to the external controller. Commands will be accepted within a "command window", which immediately follows the Manchester data and status codes sent from the player.

Packets of three bytes are used for communications. One 3-byte packet is used for each Manchester code, one 3-byte packet for the player status code, and one 3-byte packet for the player command. The first two packets will always be sent once each video field when the videodisc is in an active operational mode (i.e. when the player is up to operating speed with the servos "LOCKED"). A command packet is not required for every "command window". Multiple commands within the same "command window" are allowed provided they do not follow a GOTO command.


CODE FORMAT:

For interactive games, a non-standard Manchester code is required, but the Manchester format of 24 bits is retained. The main difference is that the BCD frame# is encoded on both the first and second fields of video. In the first field of a picture, a hex "FXXXXX" is encoded, as is currently the standard. Also, the frame# is also encoded in the second field as a hex "AXXXXX". Lead-in and lead-out are also valid codes, but chapter code, extended status code, user's code, and auto-stop code are NOT currently accepted. Furthermore, no provisions currently exist for handling "3/2 pulldown" or CLV videodiscs.


DATA PASSING:

In a normal operating mode, the player will pass to the external controller three (3) bytes of Manchester code and three (3) bytes of player status. The Manchester data is processed and checked for validity. Then the data is passed, as read, to the external controller. If an invalid code is read, the player sends the hex code "00 00 00" in place of the Manchester. Then, following the Manchester data, the player sends out its current operating status.

These six (6) bytes must be passed to the external controller before a command will be accepted by the player. A 960 microsecond timer is active, during which the six data bytes must be accepted by the external controller. After this timeout, an error flag will be set and an error is sent in the next field. However, commands will be accepted from the external controller after a timeout has occurred.


COMMAND RECEIPT:

Following the acceptance of the 6th data byte, the "command window" opens. Within this 7-9 msec. "window", the player will accept new commands (3 bytes per command). After each command is received, it will be examined and then executed. If the command was not properly received, then an unsolicited error message is returned. Also, the entire command must be received within 960 usec. or the entire command will be rejected and an unsolicited error message will be returned. This timeout is to prevent the player from being "locked" in the command receipt routines.


ERROR MESSAGES:

Error messages are unsolicited. They are one (1) byte in length and always begin with the first bit as a zero. Furthermore, the hex value "00" is NOT considered an unsolicited error message. Instead, it it the first byte of an invalid Manchester read.

Unsolicited error messages can come at almost any time but never in the middle of the player passing Manchester data and player status codes. Error messages are usually sent immediately following a command which has been interpreted as being invalid or following a GOTO which cannot be completed.


COMMUNICATIONS SIGNALS:

The hardware control signals for communications are the DAV (active low data available) and DAK (active high data acknowledge). The player will first provide the Manchester and status packets. This is done as follows:

1. The player writes the first byte of Manchester data.
2. DAV goes low indicating the buffer contains information.
3. The external controller reads the buffer (via RDEN - read enable).
4. DAV goes high indicating the buffer has been read.

This action continues until both packets are sent (or until the 960 usec. time-out occurs.

After the player's communication to the external controller is complete, the "command window" is opened. The external controller has 7-9 msec. to pass the commands to the player. This is done in the following manner:

1. The controller writes to the buffer (via WREN - write enable)
2. The DAK goes low indicating the buffer is full.
3. The player reads the buffer; DAK goes high (approx. 15 usec.)
4. The procedure is repeated for the next two bytes of the command.

Following the third byte of the command, the player first processes and checks the command. Then the appropriate flags are set to implement the command at the next video field. If the command was a JUMP or GOTO command, the communications window is closed. Otherwise it will remain open for receiving another command (until the 7-9 msec. time-out). Note that the "command window" is 7-9 msec. but once a command has begun to be sent, it must be completed within 960 usec. or a time-out will occur. This time-out cancels the command and results in an unsolicited error message.


MANCHESTER CODES:

FIELD OF LINE ACCEPTED CODE DESCRIPTION
PICTURE # (HEX)

1 17-18 FXXXXX Std picture # 1st field (X=BCD #)
(280-281) 88FFFF Std lead-in code (Min 900 tracks)
80EEEE Std lead-out code (Min 900 tracks)

2 280-281 AXXXXX New picture # 2nd field (X=BCD #)
(17-18) 88FFFF Std lead-in code (Min 900 tracks)
80EEEE Std lead-out code (Min 900 tracks)

Note the the following codes are not currently accepted

82CFFF Auto-stop 8DCXXX Disc status code (CX ON)
8XXDDD Chapter # 8BAXXX Disc status code (CX OFF)
87FFFF CLV code 8XEXXX CLV picture # (not used)
FXDDXX Time code 8XXXXX User's code

When encountered in the Manchester read, these codes will be considered as invalid codes. They will not be passed to the external controller.

HOME | LASER GAMES | LASER COMMUNITY | TECH CENTER

Questions? Comments? Problems? CONTACT US

dragons-lair-project.com was created by Jeff Kinder & Dave Hallock, 1997 - 2024.
All trademarks and copyrighted materials are property of their respective owners.