New: The source now includes a makefile and a project file for Watcom C/C++.
Compiles should be possible now.

The following are notes to the reviewing programmer.
This program is spread out into several modules, many of which are
themselves several files large. In general, for source code names
which are not self-explanatory:
a file prefix means it has to do with world file i/o
a ray prefix either has to do with rendering or is from an
older time when all files were ray prefixed
a scr prefix means it has to do with screen management
an spr prefix means it has to do with sprites/objects
a vox prefix means it has to do with mountain rendering

Many of the sources are commented, but a few are not. In general, its not
at all cryptic code. I've tried to adhere to the general philosophies of
structured programming.

Important files:

gamerun.cpp - overall managing file. Runs almost everything
dosrun.cpp - actual location of main() in DOS version. Just turns control
over to gamerun.cpp
rayinit.cpp - starts up and shuts down most system independent stuff
raycast.cpp + bsptree.cpp - make up the meat of the overall renderer
sprrend.cpp - the sprite renderer
voxrend.cpp - c portion of mountain renderer
filemain.cpp - overall managing file for world file i/o
player.cpp - file that controls the player
ray.h - info given to almost all files
globals.h - global variables (I used to use globals, and now don't,
but I still have relics)
rayrend.h - h file for renderer
rayfile.h - h file for world file i/o
voxel.h - h file for mountain internal files
voxinter.h - h for for mountain external files that want to use mountains
sprutils.h + rayspr.h + rayspr.h - h files for sprites 

Command-line options:

-noshade turns off mountain shading
-fastvox makes mountains render faster but not as nicely 
(does not effect shading)

I haven't tried these in a long time, so I don't know if they work:
-file uses alternate world file (will actually load DOOM wads too)
-ftex use alternate world for floor textures
-wtex same but for walls

A few idiosyncracies:

mix of the terms sprite and object- Technically, a sprite refers to a 
specific type of object, on that rendered as a moving bitmap. However,
in the program the terms are interchanged without concern for specific
definition. When sprite is used, it sometimes refers specifically to the
rendering of an object

#ifdef OS_ lines
These refer to operating system dependent portions of the code.
A windows port was actually written for the project, but unfortunately other
aspects of the project to priority before I could debug the WINDOWS version.
However, it actually compiled to windows at the time and ran, albeit in a
slightly screwed up fashion(sp?) (the color palette was messed up). At this
point, it probably will not compile cleanly to Windows, though finishing the
port would require only a day or two for an experienced Windows programmer.
(When I wrote the port, it was the first Win program I'd ever written).

code for objects & function pointers associated with them- The object model
in the program is pretty neat. Rather than defining the object types at 
compile time, object types are run-time defined in the world file. 
Orchestrating this is not easy, and sometimes it makes object code overly 
complex. However, it is interesting to note that you could now, for example,
put the camera in eye of an enemy, or change one enemies pictures to change
him form a human to a monster. You should also note that some of the later
object code was written very close to the time a prototype was needed, as is
as a result somewhat cryptic and inflexible.

the asm files
sliver.asm- code for inner loop of rendering walls & floors
voxrow.asm- one set of code for inner loop of mountains (partially shaded)
voxrowf.asm- secode set of mountain code (no shading)
vrsmooth.asm- final set of mountain code (full shading). This the one that is
almost universally used

Sorry if I missed a bunch of stuff. I tried to put what I'd want to know
if I had to look at my code.