VLDP-HW
From DaphneWiki
Contents |
VLDP-HW
Terminology
As it stands today, the VLDP-HW solution consists of two parts:
- The controller
- The media server
These two parts communicate via a serial cable running at 115200 bits per second.
The Controller
This consists of a PCB with an Atmel AVR microcontroller on it, along with RCA video input and output jacks, and interfaces matching the laserdisc players that are being replaced. Its job is to communicate with original arcade game hardware (such as a Dragon's Lair PCB) and mimic the original laserdisc player's behavior which it (the controller) is replacing.
The media server
This consists of a typical linux-based PC running a stripped-down version of DAPHNE that will listen for commands on the serial port and display fields/frames and play audio as it receives commands. The speed of the PC will be more than adequate to present the video and audio at the full speed of the original laserdisc player, and any track/field can be skipped to out of sequence in order to support tricky requirements for games such as Firefox.
Serial Communications
The communication protocol used by the controller and media server is as follows:
All communication, regardless of which direction it is going, must conform to the following structure:
An array of bytes:
1 'sync' byte: must always will be 00 1 byte indicating length of data N bytes (the data itself) 2 bytes representing CCITT CRC-16 of the preceding data
So for example, a complete "packet" might look like this:
00 01 00 E1 F0
Typical Flow
The controller upon startup will immediately begin sending "hello" messages to the media server. Each "hello" message will be spaced about 1-2 seconds apart to give the media server time to respond before another "hello" message is sent. The reason for this is to allow the media server time to finish booting. (the controller 'boots' instantly)
Once the media server has received the "hello" message, it responds by sending the laserdisc player that is to be emulated, the name of the "disc" that is to be emulated (the name is arbitrary), and the complete compact VBI data of the disc. The details of this are described in the next section.
If the media server for whatever reason restarts after having sent the "hello" message to the controller, it SHOULD notify the controller of this by sending a "reset" command to the controller. The controller, upon receiving the "reset" command, will re-send a new "hello" message to get in sync with the media server once again.
Commands from controller to media server
Each command starts with an ASCII letter and proceeds with one or more bytes.
| Command letter | Name | Description | Example |
| A | Audio Update | The A will be followed by a single byte. If bit 0 is set, it means the left audio channel is enabled. If bit 1 is set, it means the right audio channel is enabled. If either or both bits are cleared, it means the respective audio channel is muted. All other bits are reserver and must be 0. | 0x00 0x02 0x41 0x02 0x3 0xB0 <-- both audio channels should be enabled |
| F | Show Field | The F will be followed by 4 bytes in little-endian format representing which absolute field to display. The absolute field is computed by multiplying the track number 2 and adding the relative field (will either be 0 for even or 1 for odd). The field will be displayed immediately if at all possible. | 0x00 0x05 0x46 0x01 0x00 0x00 0x00 0xBB 0x55 <-- display absolute field 0x00000001 |
| H | Hello | The H will be followed by 1 byte representing the version of this serial communications protocol. The current version is 00. The response sent by the media server is detailed below. | 0x00 0x02 0x48 0x00 0x99 0x6A |
