|
|
||
![]() |
||
|
|
||
|
|
||
|
|
![]()
HACKING AROUND THE LAIR
- August 23, 1999
Written by
Robert DiNapoli,
Dave Hallock, and
Matt Ownby
AUTHORS' BABBLE:
Old time programmers, being sadistic creatures by nature, tried to squeeze as much performance out of a byte as possible. (Well, that coupled with the fact that memory used to be expensive.) Anyway, the DL roms were pretty darn hard to decode, and there is still a little work to go...
I've been staring at these roms for so long, I can pretty much read them in raw hex. However, after about 10 minutes of staring at raw hex, I start to get irritable. This is usually proven by my friend saying "Uh, Rob - I have to go now." I wouldn't want to expose my readers to the 'wandering friend syndrome', so included in the package is a simple utility called 'romparse'. Romparse will, well uh, parse (for lack of a better term) the Dragon's Lair rom into somewhat readable format. The best way to use it is to redirect its output to a file. Example: romparse>outputfilename.txt (Press return. Type the filename you want to parse - you won't be prompted for it - and then press return again.) Its nice to have a printout of the parsed output when hex editing. It helps keep sanity. Parsed outputs of the F revision of roms are included; they are named U2,U3 and U4.
NOTE:
The U2, U3, and U4 rom dumps have changed since V1.0 of this document. The offset addresses have been made to match up with the indexes. There probably won't be a V1.2 - other games to hack, ya'know :)
The parse program actually cheats a bit in separating the data into readable format. It relies on the fact that there is usually a '00 00' separator sequence in-between moves. There really isn't a separator sequence. The first 00 is usually part of the time from the preceding move. Note the term usually. This means that the parse will usually be correct, its not 100%. The only way to make the program 100% would be to code for each different sequence type. You'll read more about sequences soon.
You'll really need a DL disc and a laserdisc controller program to make best use of this information. (You *do* want to look up some of those frame numbers, don't you?) Some basic information follows, followed by 2 scene dissections. I tried to pick 2 scenes that have slight quirks to them, as I'm not going to type an analysis of the whole rom...
DOWNLOAD
Full documentation including Basic Information, Scene Indexing, Sequence Indexing, Sample Scene breakdowns, and more are included in the download. If you have any questions, please contact Robert DiNapoli.
DOWNLOAD ROMPARSE11.ZIP NOW! (59.7k)
SOME BASIC INFORMATION:
Each scene is divided into sequences, starting with 0 and increasing by 1 for each move, death scene, or animation sequence. The sequences are not numbered anywhere in the rom; you can use the indexing method below to find out where the sequences start. The sequences are not numbered by the parse program either. You will have to manually write them down, or count them. The resurrection always marks sequence 1, and the start of a new scene. (The resurrection will usually show as the byteset '0 2 3a', '0 2 3b', or '0 2 3c' - It's real easy to spot in the parsed output). Sequence 0 (as numbered below in the section 'Sequence indexing', is the starting move of the scene. The data contained there is usually a copy of the data at sequence 2; seems like a waste of space. I'm sure the programmers had their reasons....
Moves:
The easiest way to interpret the move byte is to break it into two halves. On a byte like 0x94, consider it as a 9 and a 4. (The 0x means the digits following are in hexadecimal format. Likewise, a $ means hexadecimal also, it just depends on the mood I was in... You can use the windows calculator to convert formats.) When you see 0x94, the second digit (4) actually represents the move.
Here's the rundown:
x0 - sword
x1 - up
x2 - down
x4 - left
x8 - right
There are also diagonal moves: 95 is nw, 99 is ne, 96 is sw, and 9a is se. There are no moves in Dragon's Lair that require diagonal moves, but some are allowed.
The first digit tells the game what type of move to count it as.
A 9x means a normal move, an 8x means a death. There is also Ax,Bx,Cx, and Dx which are used for critical timing moves. (These are used on the hard levels a lot!). So, as an example: 0x84 means jump to the death sequence if the user moves left, and 0x98 means jump to the next sequence (or end of scene), if the user moves right.
Each scene is encoded in the Roms at least two times. All the scenes are encoded on U2 and the start of U3 for the easy level. The rest of U3 and start of U4 are coded for the hard level. The very hard scenes are coded after the Dragon's Lair scene in U4.
The Dragon's Lair Sony Laser Disc Player Conversion Project is a nice complement to this, as it shows you which frame numbers are being played while the game is running. Ok, shameless plug here, but it's true! ;)
Rather than try and present some 'format' to the sequences, we merely flow through the scenes below, with me spreading comments as I think necessary. Most scenes follow a similar pattern - start with the resurrection, followed by moves and death scenes, and ending with the 'bones' death scene.
There aren't 42
scenes. Some of the 'scene' indexes point to still frames that are used in
the game.
SCENE INDEXING:
Indexes to the scenes start in Rom U2 at 0x108. Following is the list of the 'easy' level scenes. The 'hard' version of the scenes start at location 0x215c, and one more index set of 10 scenes follows at 0x21b0. There is an attached file called 'brdindex.doc'. It contains a breakdown of all the scenes and their sequence indexes.
Here's how it works:
Let's say you wanted to trace through scene #3. This happens to be the 'Mist Room'. The starting point is location 0x210c, which points to location 0x21f8.
Scene# 1: at 8456
($2108) points to sequence index at 8644 ($21c4)
Scene# 2: at 8458 ($210a) points to sequence index at 8668 ($21dc)
Scene# 3: at 8460 ($210c) points to sequence index at 8696 ($21f8)
Scene# 4: at 8462 ($210e) points to sequence index at 8716 ($220c)
Scene# 5: at 8464 ($2110) points to sequence index at 8740 ($2224)
Scene# 6: at 8466 ($2112) points to sequence index at 8780 ($224c)
Scene# 7: at 8468 ($2114) points to sequence index at 8804 ($2264)
Scene# 8: at 8470 ($2116) points to sequence index at 10246 ($2806)
Scene# 9: at 8472 ($2118) points to sequence index at 10270 ($281e)
Scene# 10: at 8474 ($211a) points to sequence index at 10300 ($283c)
Scene# 11: at 8476 ($211c) points to sequence index at 10322 ($2852)
Scene# 12: at 8478 ($211e) points to sequence index at 10334 ($285e)
Scene# 13: at 8480 ($2120) points to sequence index at 10348 ($286c)
Scene# 14: at 8482 ($2122) points to sequence index at 10368 ($2880)
Scene# 15: at 8484 ($2124) points to sequence index at 10394 ($289a)
Scene# 16: at 8486 ($2126) points to sequence index at 10422 ($28b6)
Scene# 17: at 8488 ($2128) points to sequence index at 10452 ($28d4)
Scene# 18: at 8490 ($212a) points to sequence index at 11950 ($2eae)
Scene# 19: at 8492 ($212c) points to sequence index at 11974 ($2ec6)
Scene# 20: at 8494 ($212e) points to sequence index at 12014 ($2eee)
Scene# 21: at 8496 ($2130) points to sequence index at 12040 ($2f08)
Scene# 22: at 8498 ($2132) points to sequence index at 12062 ($2f1e)
Scene# 23: at 8500 ($2134) points to sequence index at 12092 ($2f3c)
Scene# 24: at 8502 ($2136) points to sequence index at 12118 ($2f56)
Scene# 25: at 8504 ($2138) points to sequence index at 12156 ($2f7c)
Scene# 26: at 8506 ($213a) points to sequence index at 12170 ($2f8a)
Scene# 27: at 8508 ($213c) points to sequence index at 12200 ($2fa8)
Scene# 28: at 8510 ($213e) points to sequence index at 12222 ($2fbe)
Scene# 29: at 8512 ($2140) points to sequence index at 14538 ($38ca)
Scene# 30: at 8514 ($2142) points to sequence index at 14560 ($38e0)
Scene# 31: at 8516 ($2144) points to sequence index at 14588 ($38fc)
Scene# 32: at 8518 ($2146) points to sequence index at 14608 ($3910)
Scene# 33: at 8520 ($2148) points to sequence index at 14658 ($3942)
Scene# 34: at 8522 ($214a) points to sequence index at 14694 ($3966)
Scene# 35: at 8524 ($214c) points to sequence index at 14714 ($397a)
Scene# 36: at 8526 ($214e) points to sequence index at 14742 ($3996)
Scene# 37: at 8528 ($2150) points to sequence index at 14762 ($39aa)
Scene# 38: at 8530 ($2152) points to sequence index at 8830 ($227e)
Scene# 39: at 8532 ($2154) points to sequence index at 12242 ($2fd2)
Scene# 40: at 8534 ($2156) points to sequence index at 8652 ($21cc)
Scene# 41: at 8536 ($2158) points to sequence index at 26968 ($6958)
Scene# 42: at 8538 ($215a) points to sequence index at 27022 ($698e)
SEQUENCE INDEXING:
At location 0x21f8, we have the following data stream:
Scene: 3 Sequence: 0 Offset: 8696 ($21f8) at: 9263 ($242f)
Scene: 3 Sequence: 1 Offset: 8698 ($21fa) at: 9256 ($2428)
Scene: 3 Sequence: 2 Offset: 8700 ($21fc) at: 9263 ($242f)
Scene: 3 Sequence: 3 Offset: 8702 ($21fe) at: 9281 ($2441)
Scene: 3 Sequence: 4 Offset: 8704 ($2200) at: 9299 ($2453)
Scene: 3 Sequence: 5 Offset: 8706 ($2202) at: 9317 ($2465)
Scene: 3 Sequence: 6 Offset: 8708 ($2204) at: 9324 ($246c)
Scene: 3 Sequence: 7 Offset: 8710 ($2206) at: 9331 ($2473)
Scene: 3 Sequence: 8 Offset: 8712 ($2208) at: 9338 ($247a)
Scene: 3 Sequence: 9 Offset: 8714 ($220a) at: 9345 ($2481)
Meaning that there are sequences for scene #3 starting at $2428, $242f, $2441,
$2453, etc.
Vestibule / Yellow Room (crumbling ceiling) - Sequence 1:
Offset: 758 ($2f6) -
Resurrection
Frame: 4083 ($ff3) : 0 2 3b
0x00 is used to play an animation without expecting a move. 0x02 is the sequence to jump to after playing the animation (So, after playing the resurrection, we jump to sequence 2, which is the first move). The 0x3b represents how many frames to play. Take 0x3b and divide it by 1.19 to determine how many frames to play. Why divide by 1.19? I don't have a $#@!en clue. I thought I had it figured out, but then Dave told me that the disc plays at 24 frames per second, and not 30 as I had assumed. So, I'm clueless.
If you're coding Roms specifically for the LD-V1000 board, you can use a value of 1.26 to get the frame cutoff closer. Otherwise 1.19 works 'ok' for both boardsets. (Ever notice how the LD-V1000 boardset cuts off the ending of all the death scenes?)
The Castle Vestibule scene is actually a little funky - the resurrection used (starting at frame 4083) is actually taken from the Yellow Brick Road scene.
Vestibule / Yellow Room (crumbling ceiling) - Sequence 2:
Offset: 765 ($2fd) -
Start of move 1
Frame: 1887 ($75f) : 92 1 3 80 3b 3c 98 1 3 80 3b 3c 9a 1 3 80 3b 3c 81 1 5 3b
3c 84 1 5 4a 2c 1 5 77
92 1 3 80 3b 3c - The first move. 92 is the move 'down'. 1 is explained below. 3 is the sequence to jump to if the user moves down. 0x80 means do not search for the next frame (1964) if the user makes the correct move. Sometimes, you will see a 40 here, which means to search for the next frame. 0x3b (divided by 1.19) is the number of frames to play before accepting a move. 0x3c (divided by 1.19) is the number of frames to play while waiting for the user to move.
98 1 3 80 3b 3c - The user can also move right, which makes the code jump to sequence 3.
Cheater's tip: If you want to make the game pathetically simple, you can edit the moves as so: Change the 0x3b (number of frames to wait) to 0x00, and then change the 0x3c (number of frames to play while waiting for a move) to 0x77. This gives you a very large window of time to make a move. Of course, you would have to edit each move, which would take quite a bit of time...
9a 1 3 80 3b 3c - 0x9a - You can also move diagonally - SE.
81 1 5 3b 3c - 8x represents a wrong move. Jump to sequence 5 if the user moves up. The 1 is a pretty complex byte. You will need to convert it into binary to understand it. (Fortunately, its usually a one, which is pretty easy)
Taking the original
0x01 (00000001b), remove all bits except for the first and second. This
leaves us with a 01b, which is 1 in decimal. The 1 means we add 1 extra
byte to the segment after the default segment length is concluded (In our case,
the default segment length is 4 bytes on a death move). So we would add a
'3C' to the end of our segment (which as you can see above, is quite necessary
for proper operation of the map). Hypothetically, if the 0x01 had been a
0x00, then the 3C would have been assumed to the first byte of the next segment.
Onward. Take the 3rd and 4th bits and shift them two places to the
right. So, we have 00b, which is 0 in decimal (Once again, you can use the
windows calculator to convert if you don't know binary). Take the number 2
(where did I get this number? it's in the code), and add it to our result. 0 + 2
= 2. So that means when we make our move, we will jump to the sequence indexed
by 2. In our example, this would be '5'. (It is 2 bytes in from the
beginning of the sequence - we start the count at 0). Therefore, when the user
makes the move (81), use the byte at the second position as a pointer to the
next sequence.
Bits 5-8 haven't been deciphered yet. Whew! Good thing you really don't have to worry too much about this byte!
84 1 5 4a 2c - Jump to scene 5 if the user moves left.
1 5 77 - 1 is the index into the score table. The score chart starts in Rom U2 at $9a. (This is position 0, and each score is 2 bytes long). Index 1 is at position $9c and has the value 003c, or a score of 49. Look familiar? You get a score of 49, just for starting each scene. Jump to scene 5 if the user takes no action. The 0x77 is the number of frames in which to wait for the user to make an action. If the user makes no move by 0x77, the game jumps to sequence 5. The 0x77 is followed by a 0 (part of the 00 00 that romparse uses to separate sequences), which isn't shown here. (You can change the 0 to another value, and create a very long playtime!).
Vestibule / Yellow Room (crumbling ceiling) - Sequence 3: (Start of move 2)
Offset: 800 ($320)
Frame: 1964 ($7ac) : 98 1 4 80 0 1d 81 1 5 0 1d 84 1 5 0 1d 3 5 15
Only valid move is right, which takes us to sequence 4. Invalid moves are 81 (up) and 84 (left), which immediately take us to sequence 5. 3 represents the index into the score table. ou get a score of $017b (379) for making this move.
Vestibule / Yellow Room (crumbling ceiling) - Sequence 4: (Escape Sequence - Dirk completes the scene by moving right.)
Offset: 823 ($337)
Frame: 2008 ($7d8) : 3 85 2a
0x03 is unknown. 0x85 is part of the scene sequencing. The falling rocks will appear as a multiple of the 4th scene in a game (Start the counting with 0x82 - Dirk running through the gates is coded at 0x81...) (The fire ropes and filling wall are coded as 0x82, first scenes of the game. The 'drink me' potion and flying horse barding are coded as 0x83, second scenes of the game, etc.) This byte isn't actually used by the rom code.
Vestibule / Yellow Room (crumbling ceiling) - Sequence 5: (Death scene 1 - Dirk falls down the hole)
Offset: 830 ($33e)
Frame: 2085 ($825) : 10 7 31
0x10 is always used on a death scene. 0x07 is the sequence to jump to after playing this sequence. 0x31 (divided by 1.19) is how many frames to play for the death scene. (So, after playing the death scene, we jump to sequence 7, which is the 'bones' decaying scene.)
Vestibule / Yellow Room (crumbling ceiling) - Sequence 6: (Death scene 2 - Dirk is crushed by rocks)
Offset: 837 ($345)
Frame: 2156 ($86c) : 10 7 3a
Offset: 844 ($34c)
Frame: 2213 ($8a5) : 20 0 5d
0x20 is always used for the 'bones' death scene. 0x00 is unknown. 0x5d (divided by 1.19) is the number of frames to play.
The astute person, will have noticed that Sequence 6 is never used! Obviously, I'm not too astute, as this was pointed out to me by Dave. No matter what you do, Dirk will never be crushed by the rocks. While I'm not sure if this was intentional, or an oversight on the part of the designers, the 'correct' byte sequence for move 2 is as follows:
Move 2:
98 1 4 80 0 1d 81 1 5 0 1d 84 1 5 0 1d 3 6 15
This will force Dirk to
fall if the user moves up, or left. If the player does nothing, Dirk gets
crushed by the falling rocks.
Mist Room / Snakes - Sequence 1: (Resurrection)
Offset: 1064 ($428)
Frame: 3041 ($be1) : 0 2 3a
Offset: 1071 ($42f)
Frame: 3097 ($c19) : 90 1 3 80 3b 16 84 1 7 3b 16 1 7 51
Valid move is sword. Wrong move is left. The advantage to coding the 'wrong' move into the sequence is that the game will give you the beep tone when you move, and you die right away. You will notice that both the wrong move and the default death move both point to sequence 7.
Mist Room / Snakes - Sequence 3: - (Start of move 2)
Offset: 1089 ($441)
Frame: 3164 ($c5c) : 90 1 4 80 1c 16 88 1 7 1c 16 5 7 32
Offset: 1107 ($453)
Frame: 3272 ($cc8) : 90 1 9 80 1f 19 84 1 7 1e 19 a 9 37 0 80 86 c (8 89 56)
If the user presses sword, jump to sequence 9. If the user moves left, jump to sequence 7.
(The frame number $cc8 is off here, due to the way Romparse looks for the frame number relative to the '00 00'.)
NOTE: You can see that Romparse includes the data from sequence 5 as part of sequence 4. There is no '00 00' separator in-between this sequence. The sequence indexing shows us that sequence 5 starts at location $2465 : 0x08 0x89 0x56. (0x89 meaning its a multiple of the 7th scene, 0x56 is the number of frames to play).
Mist Room / Snakes - Sequence 6: - (Extra animation for death on move 4)
Offset: 1132 ($46c)
Frame: 3349 ($d15) : 0 7 32
0x00 - Play animation starting from frame 3349 for 0x32/1.19 frames, and then jump to scene 7. (This scene is shown if the user does nothing on the 4th move)
Mist Room / Snakes - Sequence 7: - (Death scene 1)
Offset: 1139 ($473)
Frame: 3397 ($d45) : 10 8 14
Offset: 1146 ($47a)
Frame: 3421 ($d5d) : 20 0 5e
Offset: 1153 ($481)
Frame: 3252 ($cb4) : 91 1 5 80 0 16 99 1 5 80 0 16 98 1 5 80 0 16 1 6 16
The move can be
up, or right, or NE. Doing nothing makes the game jump to sequence 6, for a
little 'extra' animation before the death scene.
Here's how to decode an Ax move. We've gotten kind of lazy and haven't bothered deciphering the bx,cx,dx moves...
An example datastream: a1 12 7 3 0 2f b
A1 - a move up
12 - ignore the left part (1). Well ok, maybe don't ignore it, but we don't know
what the $#@! it means. The 2 means there is coding for 2 possible 'timing
windows'.
7 - the sequence to jump to if the user moves in the first time window
3 - the sequence to jump to if the user moves in the second time window
0 - amount of time to wait before accepting a move
2f - between 0 and 0x2f is the first time window
b - between 2f and 3a (add 0x2f and 0x0b) is the second time window.
SCENE SELECTION INFORMATION (RANDOMIZATION)
The index records for randomization start at location $2035 in U2. Dragon's Lair uses a somewhat random process for selecting which scene to branch to once the current scene is finished. Once the current scene is finished, there is a possibility of going to 3 other scenes.After the 'crashing gates' animation (Selection Index 0x80 at location 0x2035) the game moves to Selection Index 0x81 (at location 2039). Each selection index is 4 bytes long. The first two bytes point to a location that holds the 3 possible scenes. Selection Index 81 points to 206e, which holds the values 83, 8b or 91. See the chart below for the meaning of these values. The 3rd byte hasn't been deciphered. The 4th byte tells the the system how many 'branches' there are. A 7 means 3 branches, a 3 means 2 branches, and 1 means 1 branch (no randomization).
| Selection Index | Branch 1 | Branch 2 | Branch 3 |
| 80 (2035) | 80 | NA | NA |
| 81 (2039) | 83 | 8B | 91 |
| 82 (203D) | 8D | 98 | 96 |
| 83 (2041) | 9F | 8F | 99 |
| 84 (2045) | A6 | A7 | A6 |
| 85 (2049) | A2 | A3 | A1 |
| 86 (204D) | 89 | 97 | 9A |
| 87 (2051) | 88 | 8A | 95 |
| 88 (2055) | 81 | 82 | 85 |
| 89 (2059) | 86 | 87 | 8C |
| 8A (205D) | 84 | 90 | 92 |
| 8B (2061) | 8E | 93 | 9D |
| 8C (2065) | 9C | A0 | 9B |
| 8D (2069) | A4 | 9E | 94 |
| Scene
Index |
Scene
Description |
Selection
Index |
| 80 | Intro (closing gates) | 81 |
| 81 | Tentacles / Halberd | 89 |
| 82 | Mist Room / Snakes | 89 |
| 83 | Ropes | 82 |
| 84 | Yellow Brick Road (pool of water / spider) | 8B |
| 85 | Wizard's Chamber / Cauldron / Slime Monster | 89 |
| 86 | Spiral Staircase / Giddy Goons | 8A |
| 87 | YMCA Room (flattening stairs) | 8A |
| 88 | Forge / Smithee | 88 |
| 89 | Grim Reaper / Socker Boppers | 87 |
| 8A | Breathing Door (wind room) | 88 |
| 8B | Bedroom / Closing Wall | 82 |
| 8C | Fire Room (lightning / bench over exit) | 8A |
| 8D | Flying Barding | 83 |
| 8E | Chapel / Robot Knight (Checkered floor) | 8C |
| 8F | Mausoleum / Crypt Creeps | 84 |
| 90 | Catwalk / Bats | 8B |
| 91 | Ropes (reverse) | 82 |
| 92 | Yellow Brick Road (pool of water / spider) (reverse) | 8B |
| 93 | Giant Bat | 8C |
| 94 | Elevator Floor (9 levels) | 81 |
| 95 | Forge / Smithee (reverse) | 88 |
| 96 | Flying Barding (reverse) | 83 |
| 97 | Lizard King / Pot of Gold | 87 |
| 98 | Wizard's Kitchen / "Drink Me" | 83 |
| 99 | Mausoleum / Crypt Creeps (reverse) | 84 |
| 9A | Grim Reaper / Socker Boppers (reverse) | 87 |
| 9B | Tilting Room | 8D |
| 9C | Throne Room | 8D |
| 9D | Chapel / Robot Knight (Checkered floor) (reverse) | 8C |
| 9E | Elevator Floor (9 levels) (reverse) | 81 |
| 9F | Pirates of the Caribbean (underground river) | 84 |
| A0 | Mudmen | 8D |
| A1 | Black Knight (on horse) | 86 |
| A2 | Boulder Trench | 86 |
| A3 | Three Caves / Geyser | 86 |
| A4 | Dragon's Lair | 81 |
| A5 | Attract Mode | 80 |
| A6 | Elevator Floor (3 levels) | 85 |
| A7 | Vestibule / Yellow Room (crumbling ceiling) | 85 |
ROM HACKS:
To replace the jittery frame after winning the game:In Rom U1 around
location $1fee, change CA 79 to CB 79
This was found by watching the output of dlterm, and then searching the rom for that frame number. Increase the frame number by 1, and no more jitter.
To add the 'Ye Boulders' sign:
In Rom U2 at location
$1c4b, change 00 18 4f to 00 18 f7 (easy level)
In Rom U3 at location $1e7d, change 00 18 4f to 00 18 f7 (hard level)
Since this is a 'play animation' sequence -notice the sequence starts with 0x00-
we just change the 3rd byte to tell the sequence to play longer.
To change the delay between beeps when starting the game:
In Rom U1 at location
$121b, change the $f0 to a lower number (ie: 10)
In Rom U1 at location $1235, change the $f0 to a lower number (ie: 10)
ADVANCED HACKS:
Want to add your own scene? Here's how: (it takes a *lot* of work!) These are just the rough steps you need to take. The actual work is left up to you!1) Print out a hexdump of rom U4. Anywhere that you see FF's is a good place to store your new scene data in. Don't use U1 to store data. It appears to have space available, but crashed the rom when scene data was stored here.
2) You will have to sacrifice one of the current game scenes; you could be clever, and combine 2 scenes into one, say the 'catwalk' and the 'giant bat' into 1 scene...
3) Point the scene index pointer to the new location in U4. If I was changing scene one, I would change the bytes at $2108 and $2109 to lets say... $6f 00
4) At the location you pointed to ($6f 00), make it point to the addresses that will hold the sequences (example: 6f02 6f09 6f02 6f14, etc).
5) At each location specified in step 4), you code your sequence data. (Its best to map out all your data in advance...)
Wanna play the
drawbridge scene? Well, be a good little varmint, and scoot on over and grab the Dragon's Lair Enhancement
ROMs, burn 'em, plug 'em in, and you're
set!
DISCLAIMER: I'm
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 available for dating, and possibly for hire…. :) (Hey, it never
hurts to plug yourself, right?)
I'm not liable for any damage you do to yourself, your computer, or your
Dragon's Lair machine. 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!)
QUESTIONS? COMMENTS?
PROBLEMS?
Contact Us
HOME
| LASER GAMES |
LASER COMMUNITY
| TECH CENTER
This website was created by
Jeff Kinder
& Dave Hallock, 1997 - 2008.
All trademarks and copyrighted materials are property of their respective
owners.