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 load its previous settings from EEPROM and immediately begin emulating a laserdisc player so that the arcade hardware has something to talk to. If it has no settings in its EEPROM, then it will default to emulating a LD-V1000 using a laserdisc with a 2:2 VBI pattern. The controller will begin sending commands over the serial port to the media server, which will initially be lost while the media server boots. However, this is okay because the media server is designed to be tolerant of missed/dropped commands.
Meanwhile, the media server will be booting up. Once it finishes booting, it must send a S)tatus command to the controller to see what settings the controller is currently using. If the controller is found to be using the same settings as the media server, the media server will just start processing commands sent from the controller. This is the typical use case. If the media server finds that the controller is using different settings, then the media server will send a H)ello command which contains new information about which laserdisc player to emulate and what type of VBI patterns the emulated disc should have.
If a user modifies settings of the media server (via web browser) while it is running, the media server should send another H)ello command to change the settings of the controller to match. This will most likely require a reset of the arcade hardware too.
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. | 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 should be displayed during the next vsync on the media server. Audio, if enabled, should be played when the field is displayed. Assuming the media server's video is outputting at 60 Hz, once it gets in sync with the controller it should render a smooth stream of fields and audio because new field commands will be coming in between every field. NOTE: it doesn't matter that the media will be in effect lagged by 1 field, because the user won't notice. The main problem to avoid is displaying the wrong fields because the user will notice that. | 0x00 0x05 00 0x46 0x01 0x00 0x00 0x00 0xBB 0x55 <-- display absolute field 0x00000001 |
| H | Hello | The H byte will be sent alone and is used to tell the media server that the controller has just rebooted and may need to have its settings checked. | |
| 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 | Settings Message | This sends back a 00 byte indicating which version of the serial protocol the controller supports, followed by the 2-byte identifier that the media server sent with the last hello command (see hello command described below). If there is no previous record of this, then two 0's will be sent instead. | (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 (Apply new settings) | The ASCII 'H' byte will be followed by new settings for the controller, detailed below. |
| S | Request current settings | Requests from the controller which settings it is currently using. This is so the media server knows 1) the version of the serial protocol that the controller is using and 2) which laserdisc player and laserdisc the controller is currently emulating. |
The media server's Hello command
The media server's H)ello command will be as follows:
- 2 byte arbitrary identifier (probably a checksum) chosen by the media server which will be returned when the media server requests a status. This allows the media server to determine whether or not a reset command needs to be sent. (if the controller already has the current disc settings then a reset should not be sent because the arcade hardware would then also need to be reset)
- 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 laserdisc player behavior
- 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
- Bit 7 is clear if disc is NTSC or 1 if disc is PAL
- All other bits are reserved and should be 0
- 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 bytes of the compact VBI data will be:
| Offset | Description |
| 0 | Version identifier (will always be 0 for now) |
| 1 | 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. |
| 2-5 | The total number of fields that the VBI patterns represents, in little-endian format. |
After these bytes, 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" |
LD-V1000 Pin-Out
| LD-V1000 Pin | ATMega324P Pin | Description |
| 1 | A0 | DIO1 |
| 2 | A1 | DIO2 |
| 3 | A2 | DIO3 |
| 4 | A3 | DIO4 |
| 7 | C1 | Command Strobe |
| 11 | C0 | Status Strobe |
| 12 | GND | |
| 13 | A4 | DIO5 |
| 14 | A5 | DIO6 |
| 15 | A6 | DIO7 |
| 16 | A7 | DIO8 |
| 17 | D3 | Enter Signal (must be connected or dragon's lair will not boot) |
| 18 | GND | |
| 19 | GND | |
| 20 | GND | |
| 21 | GND | |
| 22 | GND | |
| 23 | GND | |
| 24 | GND | |
| 25 | GND |
Interface Considerations
User Goals
- Users want behavior
- Users want to be kept informed
- Just plug it in without having to configure it
- Everything needed to get up and running should be included in the box
- Users generally do not want to spend time troubleshooting
- Some users may be willing to go to extra trouble to solve problems faster
- Would prefer to use identical interface as original laserdisc player
- Minimize interaction with hardware inside of cab
- No maintenance! (hardware should last "forever")
- User will expect that the system will be able to recover gracefully from random reboots/power loss
Design based on user goals
- Pre-configure PCB to match user preferences
- Lots of LEDs on the PCB so that troubleshooting can be done visually (different colored LEDs would make it even easier)
- One power plug that matches original interface
- Bundle 1 USB stick and 1 SD card in package, with preloaded software
- Integrate with Shaun Wood's MultiROM card
- Include ethernet and USB extension cables? (so they can be accessed from the coin door)
- Minimize writes to flash drives
- Keep the user informed about the status of things
