Here, through a bit of guesswork and code deduction, the last of the variables have been renamed and the often-used "sub_49" turns out to simply be a print string function, used everywhere throughout the code.

This section of code prints the current skill level and monitor type to the screen during the main menu. It is also responsible for getting the user input. Pretty straightforward overall, except a neat surprise was that while the routine is waiting for user input, it is continually seeding the random number generator, giving a very random human input variable into the randomness of the game. Nice touch.

At this section in the code, I added a check for the Escape key to allow the user to exit back to DOS.

The code labels have not been changed from loc_xxx:: because the code is fairly readable at this state and retaining the original loc_xxx labels allows me to cross reference code against previous versions in case of bugs that may have crept in.

Now that the code is in the final stages of revision, it's time to make minor enhancements and additions to the game. I first like to attempt to get full backwards compatibility for the game; I want to make it run exactly the same on an IBM XT as it does on a pentium IV 2.5GHz machine, thus the only changes will be "behind the scenes" to retain the original look and feel. Essentially, I am attempting to reproduce the game the way it originally should have been released, had the original author been able to see 20 years or more into the future of computer technology and adjusted for it.

Speed fixing and throttling:
The biggest issue in playing old games on new computers is speed. Not only have CPU clock speeds increased, but today's CPUs run smarter and more optimally than their predecessors. If you took a pentium based CPU and throttled the clock speed back to the original IBM PC speed of 4.77MHz, the pentium would still run too fast. Caching and branch prediction tricks aside, pentium CPUs simply do things in less clock cycles than the early CPUs did 20 years ago.

The trick is then providing the illusion that the game is running at the same speed on any computer. Traditionaly, if you wanted to play an old game on a fast computer, you'd reach for a slowdown program which interrupts the computer at regular intervals (several times per second) and make it delay a tiny amount, thus simulating a slower computer. As speeds have increased, the amount of delay has to increase, which eventually leads to very jerky motion and unresponsive gameplay, since the computer is doing more waiting than game processing.

By restoring the source code to the game, strategicaly placed, real-time based delays can be added to restore a game to its original playability without sacrificing responsiveness or video quality. Using delays based in real time, rather than delay loops ensure that the game will run at the proper speed on any cpu, regardless of processor speed.

The most effective area to start throttling a game is the video. I'm currently using a method that ensures that sprite movements and screen refreshes are always done in a minimum of 1ms. I start a timer at the start of a video routine, then at the end of that routine, I make sure at least 1ms has passed before returning from the procedure.

Since video updates happen often in action games, a well placed delay can have an incredible impact on overall game speed without impacting other aspects of play. Using specific delays like this results in games visually operating at the same speed regardless of CPU speed. The only thing to be careful of is running the game on an original 4.77MHz machine. The added overhead of checking the time before and after a video update may very well take over 1ms in time, which can then result it a game running too slow! A reasonable fix for this is to detect the CPU type at startup, and if running on an 8088 or 8086 processor, simply skip all delays that were added to the original code. Those folks running on an overclocked 8088 or 10MHz 8086 can just use their "turbo" button. ;)

The next hurdle in converting this game was the voice samples played over the PC speaker. The timing on the playback of these samples is extremely precise, or at least as precise as one could be back in 1985. Machines running too fast played the samples too quick; just a fast blurp of sound. If I put too much delay in, the samples draw out like satan himself was speaking. Because of the precise timing requirements, it was difficult to find a solution that worked on all speeds of machines, and in fact I'm not sure if I've even found one yet. Windows complicated matters even further. With proper timings that worked in a DOS environment, the game's sounds were simply noise under windows 2000 or XP. I believe this is due to the overhead of the hardware abstraction layer. I'm not certain if an all encompassing solution can be made for this issue.

A side-solution and game enhancement was to use the soundblaster to play samples from the original game. It was an odd solution indeed; playing 1 bit samples from a PC speaker on a sound card capabable of CD quality playback! Anything in the name of video game conservation I guess. I suppose this is no different than playing a game based on IBM PC hardware on a new Xeon 2.5G.

Adding soundblaster support opens up many possibilities for enhancing the game play in future revisions. Better voice samples, sound effects, mood music, and much more can be added to bring gameplay to another level. Of course all of the enhanced features must always have the ability to be turned off so that the game remains true to its origins.