DRAGON'S LAIR / SPACE ACE LASERDISC PLAYER CONVERSION
Developed by Robert DiNapoli - 24 September 1999
UPDATE - November 2016 - This guide explains how to add desktop PC hardware into your arcade game cabinet to allow it to use a newer laserdisc player. There are also commercial products that have since been developed for player upgrades/replacement. An overview of these devices is on our Laserdisc Player Conversion Products page.
The purpose is simple - to replace the LD-V1000 player used in Dragon's Lair and Space Ace with one that is more reliable and doesn't break down as much. To do this, the package uses a dedicated PC motherboard. Currently, the only players supported are Sony LDPs. Any LDP model should work, although it has only been tested on the LDP-1450 and LDP-2000.
• An IBM compatible computer. I've tested with a 233mhz and 300mhz AMD K6-2 processor. It has been 3rd party tested down to 100mhz. I can't seem to get it to work with a 486, but I don't have one of these on hand to work with. (Yes, I know that the parallel port address may be different.) It may work with a slower/faster processor, it may not. I recommend getting the cheapest motherboard/chipset combo you can find that has onboard VGA. You don't even have to mount it in a case. It will need a floppy disk drive (you can use a hard drive of course, it just adds to the cost). It uses one PC parallel port and one serial port. The VGA port is optional, but the curious may wish to plug in a monitor to watch what the DL motherboard is sending to the player. I have my motherboard mounted in the cabinet, behind the coin counter. There is room for a minitower to lay on top of the laserdisc player however.
• A null modem cable, or a regular modem cable with null modem adaptor - 9 pin female to 25 pin male.
• A cable from the DL motherboard to the PC parallel port. You'll need a DB-25 male connector and shield, and a DIP cable.
WHAT'S NEW IN DLTERM V1.4
The searching has been revised again, and there is now a command line parameter to switch between 2 search modes.
There is a command line parameter to control the 'strobe' speed. This allows you to fine-tune the searching to play either more, or less frames at the end of each scene.
Debugging is turned off by default. It can be turned on by a command line parameter.
There is now a 'Random Frame' command which searches for a new frame every 2 seconds. This has nothing to do with the game, but it looks pretty darn cool. And, you don't need the DL board hooked up to use it.
Full documentation including construction, operation, theory of operation, and more are included in the download.
DOWNLOAD DLTERM14.ZIP NOW!
THEORY OF OPERATION
The DL motherboard is wired to the PC parallel port with a custom-built cable. The PC parallel port is polled, looking for commands from the DL motherboard. When it gets a command, it is translated to the equivalent command for the new player and sent out the serial port.
To complicate matters, the DL motherboard needs to see 2 signals, command and status, which the LD-V1000 sends out every 16.6 milliseconds. First the command strobe is sent. This tells the DL motherboard that it is now ok to send a command to the LD-V1000. Shortly after, the LD-V1000 sends the status strobe, meaning - "I'm not taking any more data now." If you miss the timing window, the player doesn't get the byte, and you have to wait until the next cycle to try again. (The actual process is a bit more complicated and is described in the LD-V1000 interface guide.) The PC code actually cheats on this part - it doesn't emulate the exact process. As long as the command and status strobes are flashed fast enough, the DL motherboard will pump out data at the right speed. The command and status strobe are flashed by hooking the interrupt 8 timing vector (normally called 18.2 times a second). (The clock on the PC is calculated based on this interrupt - don't expect the clock to be accurate while running this code. Of course, if you're using a dedicated PC, this shouldn't matter.)
The serial routines come from a pre-written library developed by Mike Dumdei and available in his Mcomm6 package. I'm using the small memory model code, which is available for free. The files: order.doc, license.doc, comm_s.lib, comm.h, and async.doc all refer to his code.
The DL motherboard sends out a very simple command set. The whole game uses only the 'Play', 'Search', 'Audio On', and 'Audio Off' commands. I can't find the 'audio on' and 'audio off' commands on the LDP-2000 player. Attract mode audio will always be on.
The PC code will wait up to 4 seconds for a search to complete, during which you will see either a black screen, or the last frame played. If the player doesn't seek to the requested frame within 4 seconds, the search command is repeated one more time. The gameplay is 'paused' while seeking, so as long as the seek completes, gameplay will continue normally. Usually, the search happens in a fraction of a second. If your disc is scratched, or your player isn't perfectly aligned, seeks will take longer. You can confirm what is happening by turning debug mode on, and watching the VGA monitor if it is connected to the PC. (more on this below)
After every search, the DL motherboard expects to see a return code of $d0. If it doesn't see this return code, it issues the search command again, incrementing the frame counter by one. (So, if the first search was to frame 00323, the next search will be to frame 00324). It does this up to 3 times. If it can't get to the frame it wants by the 3rd time, it just continues playing from the current frame.
Controller cable. You will have to use a razor or x-acto knife to cut apart the ribbon cable on the DIP cable. Careful when wiring! The wires on the DIP cable aren't in sequential order. 'pin 2' on the DIP cable corresponds to the 4th wire in; 'pin 6' corresponds to the 12th wire in, etc. Check continuity with a multimeter to make sure you're attaching the right wire. Connect the wires as follows:
Note: Pin 1 on the DB-25 connector is wired to 2 wires on the DIP cable. This provides both the status and command strobe signals mentioned earlier. Pins 2-9 of the DB-25 connector are used to read data from the DL motherboard. The PC parallel port must be in bidirectional mode (sometimes labeled as 'Standard'). You can usually check this in the PC's bios.
The Sony LDP must be set to 9600 baud. On the LDP-1450, set switches 1-2-3 down, and switch 4 up. On the LDP-2000, set switches 1-2-3 up, and switch 4 down.
The main program is called dlterm.exe. You can add it to autoexec.bat and it runs nicely when everything is powered up. It uses Com1: and Lpt1:, which are both hardcoded into the program. Here are the main menu options:
|ESC||Will quit the conversion program.|
|I||Turns the index counter of the Sony LDP on.|
|O||Turns the index counter off.|
|P||Pauses the game. This works great after completing the last move on a level. If you use it 'mid-level', you will die after unpausing.|
|Right Arrow||Advance one frame (might not work on all LDP models)|
|Left Arrow||Decrease one frame (might not work on all LDP models)|
Basically, all these options are for testing purposes, except for the 'Z' command, which searches for a new random frame every 2 seconds. (You don't need the Dragon's Lair board hooked up to use this function.)
There are also 3 command line parameters that can be issued in any combination:
The '/debug' flag is probably the easiest, so we'll cover this first. It basically shows the output from each search command. You will see something like:
Search: 00323 requested
Current Frame(19): 0032
00323 is the frame that the DL motherboard is requesting. The (19) represents the amount of time that it takes to perform a search. The counter starts at 20 and decrements by 1 every 200ms. 16 is probably an acceptable value for most searches. If it consistently goes lower, your player may be on its way out of alignment, or your disc may be scratched. The 0032x is the frame that the LDP is currently at; it changes every 200ms also. You will never see the last digit: 0032 can represent any frame from 00320 to 00329.
The '/alt' flag forces the program to interpret search commands differently. Passing this flag causes the program to not send the $d0 return code. As mentioned above, the DL motherboard expects to see a return code of $d0 after asking for a search. The result is that the DL motherboard asks for the frame 3x. (We used this method of searching in dlterm 1.2, as I didn't know to send the return code at that time. Why keep this option? It may be that your PC can't send the $d0 return code, either through my programming the parallel port wrong, or through your PC having an odd port design.) In any case, this option works almost as well as the default search method. You will notice an ever so slight delay at the beginning of each scene. When you have both /debug, and /alt flags set, the display will look slightly different.
Internally in the code, the actual 'Search' command is given to the player when you see 'Search (1)'. Nothing is done when 'Search (2)' is shown. On 'Search (3)', the code is checking with the player to make sure it is on the correct frame. The minimal delay between the first search command and third search command gives the laserdisc player time to seek to the correct frame.
As an example, the Dragon's Lair startup sequence, as transmitted from the DL motherboard, is as follows:
play (This would normally fire up the LD-V1000 and happens on the second DL motherboard beep.)
play (Why does it do it twice? I haven't a clue.)
0 0 3 2 3 search
0 0 3 2 4 search
0 0 3 2 5 search
The VGA display will show something similar:
Search(1): 00323 Search Requested
Search(2): 00324 Ignored
Current Frame(19): 00323
Search(3): 00325 Search Completed
The '/t:xxxx' flag is probably the most complex, hence we leave it for last. Replace xxxx with a number from 0 to 65535. This represents the delay between each strobe signal. Larger number = longer delay. Ever notice how the LD-V1000 boardset cuts off the end of almost every death scene? Not any more! Simply introduce a longer delay, and the motherboard has to wait just a wee bit longer before issuing the next search command. The end result is that animation plays a little longer. Conversely, if you set the strobe too fast, scenes will cut off slightly premature. If you don't issue a /t: parameter on the command line, the program defaults to a value of 4608 for normal searching. This value seems to work very well on my games. If you're using the /alt parameter, the strobe value is cut down to 416 by default. Why? Because the DL board is searching 3x, and we want it to complete each search as fast as possible.
You can mix and match any of the parameters:
dlterm /debug /t:300 /alt
etc, etc, etc.
By default, debug mode is off. I recommend keeping it off, unless you are testing. It helps conserve CPU cycles. Since we are polling the parallel port, any time that the PC is doing anything else (like printing to the display, which is fairly computationally expensive), we have the chance to miss a command sent by the DL board. Not that I have seen this happen, but I am running the conversion on a fairly fast CPU.
REVISIONS AND MISCELLANEOUS NOTES
5/29/99 - Got my LDP-2000 player today. Works great. The searching on this player seems a little quicker than the 1450. I haven't opened it to look inside yet. I hope it's a different mechanism, else I'll feel stupid for mentioning this. Also tried the program with the PR-7820 mode on the Space Ace ROMs. Doesn't work, but it's a timing issue. Both players use the same command set - I was seeing the commands sent from the DL motherboard, but the sequence was a little off.
6/12/99 - So far, I'm still playing this game every day! To date, I've only seen one instance where the player had to reseek after 4 seconds. Normally, the searches happen extremely quickly.
Never made it out of beta. I've been trying to get this to work with the PR-7820, but finally give up (for now!) Even the PR-7820 programming manual doesn't seem to help.
9/1/99 - New search procedure implemented. Random frame command added. Turned display off by default. Added adjustable strobe command.
I'm not liable for any damage you do to yourself, your computer, or your Dragon's Lair game. Since this is free, I can't guarantee that it will work for you. (But, I haven't gotten any complaints so far!)
I wish to thank the following people. Without their help in one way or another this project wouldn't have succeeded.
QUESTIONS? COMMENTS? PROBLEMS?
LASER GAMES |
LASER COMMUNITY |
This website was created by Jeff Kinder & Dave Hallock, 1997 - 2023.
All trademarks and copyrighted materials are property of their respective owners.