DRAGON'S LAIR / SPACE ACE LASERDISC PLAYER CONVERSION
Written & developed by Robert DiNapoli - 24 September 1999
UPDATE - November 2016 - This document from 1999 explains how to add desktop PC hardware into your arcade game cabinet to allow it to use a Sony laserdisc player instead of the original Pioneer. For your consideration, there are also less bulky products that have been developed since then to perform laserdisc player upgrades. In chronological order of release, these products are: Hi-Tech, LaserAce*, LaserCon*, and Merlin. Additionally, Dexter replaces the laserdisc player entirely.
Well, 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 LDP's. Any LDP model should work, although it has only been tested on the 1450 and 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. Current price is under $200 (US) for a motherboard, AMD processor, floppy drive, memory and power supply. 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. (available from Radio Shack or Digikey.com)
A cable from the DL motherboard to the PC parallel port. You'll need a DB25 male connector and shield (available from Radio Shack), and a dip cable - Digikey.com part # c4pxt-2436m-nd
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! (75.6k)
THEORY OF OPERATION
(and other notes)
Theory of operation is pretty simple. 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:
Pin 1 on the DB-25 connector is wired to 2 wires on the Digikey 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 bi-directional mode (sometimes labeled as 'Standard').
You can usually check this in the PC's bios.
The Sony LDP player 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. (Is this %$@$! retarded, or what?)
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 player 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.|
|<arrow R>||Advance one frame (might not work on all LDP models)|
|<arrow L>||Decrease one frame (might not work on all LDP models)|
Basically, all these options are for testing purposes, except for the 'Z' command. This has to be one of my favorite options, and it's a wonder that a feature like this isn't incorporated into laserdisc players. It forces the LDP player to search for a new frame every 2 seconds. Ok, so I wouldn't leave it running for a month straight, else risk wearing out the search mechanism on your player, but it looks real cool! (You don't need the Dragon's Lair board hooked up to use this function. All you need is this program, and the LDP player connected to the PC via null modem cable.)
are also 3 command line parameters, that can be issued in any combination:
'/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:
Current Frame(19): 0032
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
player is currently at; it changes every 200ms also. You will never see the last
digit: 0032 can represent any frame from 00320 to 00329.
'/alt' flag forces the program to interpret search commands differently. Passing
this flag causes the program not to 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 me 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 inbetween 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:
(This would normally fire up the LD-V1000, and happens on the second DL
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
VGA display will show something similar:
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.
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.
- No Known Issues.
REVISIONS AND MISCELLANEOUS NOTES:
- Update. I obtained another player which doesn't exhibit the 'head slamming
routine'. Its the same Rom revision (2.0) as my 'bad' players. Maybe the 'head
slamming' is something to look forward to as the players age? I sure hope not,
but having two players from two different sources that have the same problem
doesn't seem encouraging...
- As if to give me a big "%@$! you!", my LD-V1000 died last night. How
- Got my LDP-2000 player today. Works great. Hasn't eaten a disc yet - Sony
usually gets things right the 3rd
or 4th time (Hopefully.) 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 pr7820 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.
- Tried the LDP-2000 in DL2. It doesn't work. The command protocol is the same,
but the LDP-2000 doesn't appear to support character generation. (ok, ok - this
has nothing to do with the conversion program, but I just *had* to mention it :
- So far, I'm still playing this game every day! (Has *anyone* actually won this
game on the hard setting?!?) To date, I've only seen one instance where the
player had to reseek after 4 seconds... Normally, the searches happen extremely
- No more problems with 'head-slamming' LDP-1450 so far. I guess I just had 2
bad players. The code in this version is a little more modular, and pretty
bullet-proof as far as searching. It should work with all Sony LDP players
flawlessly. All issues from Version 1.0 have been resolved.
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 7820 programming manual doesn't seem to
help. Plenty of other stuff to hack!
- New search procedure implemented.
Random frame command added. Turned display off by default. Added adjustable
Feel free to make comments or suggestions. I will respond to email as time permits. I also occasionally monitor rec.games.video.aracde.
not an English major, so don't expect this document to be perfect.
I'm not a professional coder either, so don't expect the code to be perfect.
I'm not liable for any damage you do to yourself, your computer, or your Dragon's Lair game. If you follow these directions and it doesn't work - I'm not liable. If your game catches fire because of an electrical design flaw, I'm not liable. If tornadoes simultaneously appear in Kansas and wipeout half the state coinciding with the exact moment you power up your system - I'm still not liable. (Get the picture?) Since this is free, I can't guarantee that it will work for you. (But, I haven't gotten any complaints so far!) (Whew!)
I wish to thank the following people. Without their help in one way or another this project wouldn't have succeeded.
Well,... that's it for now....
| LASER GAMES |
| TECH CENTER
This website was created by Jeff Kinder & Dave Hallock, 1997 - 2018.
All trademarks and copyrighted materials are property of their respective owners.