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 2 bytes indicating length of data (little-endian) 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 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 00 0x41 0x02 0x3 0xB0 <-- right audio channel enabled, left channel muted |
| B | Blank Screen | A single ASCII 'B' will indicate to make the screen black, to simulate original behavior during seeking. | |
| E | Error log message | Same format as regular log command except it will contain an error. | None, too lazy |
| 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 00 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 00 0x48 0x00 0x99 0x6A |
| L | Log Message | The L will be followed by an ASCII string containing a log message from the controller to the media server. Since the controller's only way to communicate to the outside world is through the serial port, it will log messages through the media server. | 0x00 0x03 00 0x4c 0x48 0x69 0xdd 0xba <-- a log message that simply says "Hi" |
| S | Status Message | Same format as the log message except this will be sent in response to a status request from the media server (see below). | (none, too lazy hehe) |
Commands from media server to controller
Each command is a single ASCII letter (for now).
| Command letter | Name | Description |
| H | Hello response | The ASCII 'H' byte will be followed by the hello response, detailed below. |
| R | Reset | A single 'R' sent from the media server to the controller means to reset and send the hello command again. This can happen, for example, if the user changes some settings on the media server (through a web browser) and wants to apply them to the controller. This is the mechanism that enables the user to reset the controller without physically power cycling everything. Arcade hardware connected to the controller may be able to keep running without being reset (this is a 'nice to have' feature but is not guaranteed to be implemented). |
| S | Send status | Requests a status string from the controller. The format and contents of this string are arbitrary and intended mainly to be displayed to a user to help troubleshoot any issues. Contents of this status string may indicate the current disc that the controller thinks it is playing, the current field number, the current picture number, etc. The string will be enclosed in the same format as every other packet described on this page. |
The media server's response to the Hello command
The media server's response will be as follows:
- 1 byte indicating which type of laserdisc player to emulate
- 0 is LD-V1000 Standard
- 1 is LD-V1000 Badlands modified version
- 2 is PR-7820
- 3 is Philips VP931 (Firefox)
- 4 is PR-8210
- 5 is PR-8210A
- further definitions are forthcoming
- 1 byte indicating how laserdisc player delays should be handled.
- Bit 0 is clear if disc spin-up delay is authentic, or 1 is spin-up time is minimal
- Bit 1 is clear if seek delay is authentic, or 1 if seek delay is minimal
- Bit 2 is clear if screen should go blank during seeks or 1 if screen should hold its last frame during seeks
- All other bits are reserved and should be 0
- 1 byte indicating the length of the string containing the name of the laserdisc (0 means the name is not provided)
- Arbitrary number of bytes containing the string containing the name of the laserdisc (optional as indicated by the previous string length)
- Arbitrary number of bytes containing the compacted VBI data which is described below:
The VBI data of each laserdisc is can usually be described by a few simple patterns and thus compacted down to a small number of bytes.
The first byte of the compact VBI data will be the number of "pattern entries" needed to describe the entire VBI. As it will only be a byte, that means only 255 entries are possible. Typical cases show that only 3-5 entries are needed for each disc.
After the first byte, 1 or more "pattern entries" will follow. Each entry is 12 bytes long:
- 4 bytes describing absolute field where the pattern begins. (unsigned, little endian)
- 4 bytes describing the picture number that corresponds to the start of the pattern. This number can be negative! (signed, little endian)
- 1 byte describing the pattern itself.
- 0=no change
- 1=2:2 pattern
- 2=2:2 pattern atari styled
- 3=2:3 pattern
- 4=lead-in pattern
- 5=lead-out pattern
- 6=repeating zeroes
- 7=repeating picture number
- 2 bytes describing stop-codes and chapter numbers. Bit 15, if set, means this entry represents a stop code. Bit 14, if set, means this entry has a chapter number associated with it that will continue the duration of the entry. The lower bits (bits 0-bit 13) are the chapter number. If bit 14 is clear, it means there is no chapter number regardless of whether the pattern is "no change". In other words, if a chapter exists, it must always be specified for every entry. This 2-byte value is little endian.
- 1 byte indicating the pattern offset. 0 means there is no offset. For 2:2 patterns, this can be a 0 or a 1. For 2:3 patterns this can be a 0, 1, 2, 3, or 4. A non-zero offset means that the pattern will start later than at its usual beginning. For example, of the pattern would've been "PicNum0 Empty PicNum1 Empty" for a 2:2 pattern, and the offset was 1, then the pattern would instead be "Empty PicNum1 Empty PicNum2".
Philips VP931 Pin-Out
These need to be confirmed!
| Pin | Description |
| 9 | Ground |
| 10 | RDEN' (in) <-- confirm that this is "in" |
| 11 | DAV (out) |
| 12 | DAV' (out) |
| 13 | OPRT' (out) |
| 14 | DATA0 |
| 15 | DATA1 |
| 16 | DATA2 |
| 17 | DATA3 |
| 18 | DATA4 |
| 19 | DATA5 |
| 20 | DATA6 |
| 21 | DATA7 |
| 22 | WREN' (in) |
| 23 | DAK (out) |
| 24 | RESET' (in) <-- confirm that this is "in" |
