VLDP-HW
From DaphneWiki
(Created page with "== 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 c...") |
(→Serial Communications) |
||
| Line 16: | Line 16: | ||
=== Serial Communications === | === Serial Communications === | ||
The communication protocol used by the controller and media server is as follows: | 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 | ||
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) | 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) | ||
Revision as of 18:35, 14 March 2011
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
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)
