Novice to Novice

On the primary Slackware disk, I found an untarred, unarchived DOOM v1.666 under /usr/games/doom. Also, I found an archived version under /sunsite/games/X11/action/doom. Eager to play, I copied the four files (a README, a sound driver, the data file and the binary) to my own /usr/games/doom. Setting my swap file active, I launched into X-Windows, opened a terminal window, went to the proper subdirectory, typed linuxxdoom and waited. The terminal window showed the familiar DOOM launch lines.

I waited. My hard drive started grinding. Terminal messages gave a variety of errors which I assumed would be related to the lack of a sound driver.

And waited. A minute passed and the hard drive was going berserk. Anxiety crept into the room and waited to pounce.

And waited. A small window appeared. The opening screen of DOOM kind of showed up. It looked horribly dark and grainy, but when I clicked the mouse button, the background to X-Windows changed colors and the DOOM window suddenly, dramatically cleared up.

I was in DOOM! The movement was, surprisingly, a little jerky. I brightened up the screen via the F11 key (gamma correction). Yes, this was DOOM. I played for a bit and then quit. DOOM without the gruesome sound is gruesome itself.

The DOOM readme suggests using version 3.0 of Hannu's sound driver but fails to tell where it can be located. The Sound HOW-TO mentions using a shell script found in /usr/src/linux/drivers/sound/Readme.linux, except that no such subdirectory or file existed in my setup. Snooping with mc (Midnight Commander) in /dev, I noticed many empty files including /dev/dsp, which is used for sound. I also noticed and read through the MAKEDEV file and decided to try it.

Entering MAKEDEV audio did nothing—at least, nothing that I could see. The files still remained at size 0. [Device files are always 0-sized. Device files are also sometimes called “special files”, for good reason—ED]

Yes, this has all the makings of a minor crisis. Re-reading the Sound HOW-TO reveals the bad news: recompile the kernel to support sound. No, no, NO! What did I do to deserve this? I just wanted to play Doom with sound. Having to recompile the kernel just to get sound had to be insane, but it seemed that this simple yearning for DOOM had to develop into a learning experience. [Actually, recompiling your very own kernel allows you to make a smaller kernel, which gives you more memory to work with, which means that more of the games will work without the massive swapping experienced here—ED]

After a day of blaspheming a variety of Linux gods (primary and many secondary), I calmed down to tackle recompiling the kernel. The first thing I did was copy the remaining kernel source code from the “D” set on the CD-ROM. The kernel had been split into three archives, and I had already copied over the third archive as a recommended part of general installation. Admittedly, I found it quite cool that I could fiddle with the source code if I so chose—something I know I'll never experience with Windows or DOS.

Next: I read the manual. It mentioned creating two links:

# ln -sf /usr/src/linux/include /usr/include/linux
# ln -sf /usr/src/linux/asm /usr/include/asm

which I changed to match what appeared under my /usr/src. I typed:

# ln -sf /usr/src/linux-1.1.59/include \
/usr/include/linux
# ln -sf /usr/src/linux-1.1.59/asm \
/usr/include/asm

which worked for me.

After setting the links, I switched to /usr/src/linux-1.1.59 and entered make config, which prompted me with a barrage of questions. For the most part, I accepted the default answers except when it came to SCSI, CD setup (I chose the Sony cdu31a option) and sound. Since I don't have any SCSI devices, I opted to eliminate that ability. For sound, I first accepted the default of all sound options, but when configuring the individual parts, a non-SoundBlaster value conflicted with something I specified for my Blaster. The program stopped because of that. I restarted the configuration and this time chose not to fully install all sound options. This way I got to pick just the SoundBlaster options and configure for them.

After the make config finished, I typed make dep which (according to the System Administration Guide) fixes all of the source dependencies. No problems here.

Finally the big moment: make Image to create the actual image. No, it stopped, saying the command wasn't supported anymore and instead to type make zImage to create a compressed version.

I did so and the computer started grinding away. About ten minutes later it crashed: lack of virtual memory. Dumb error on my part! Setting my swap file active with swapon /swap, I restarted the compiling and relaxed as the grinding began.

And continued. 5 minutes. 10 minutes. 30 minutes. About an hour later it finished and finished cleanly. No problems! My chest puffed out in manly pride, and I drank deeply from a virtual beer.

Now what to do with the two resulting files called zSystem.map and zImage? Using mc, I found a similar zSystem.map under /boot. I renamed it and copied the new one in its place. A quick perusal of the System Administrators Guide revealed that sometimes the kernel is called vmlinuz and sure enough I found such a file under /. I renamed it and copied zImage as vmlinuz to /.

[This was enough because Dean uses UMSDOS and does not use LILO. The majority of Linux users, who use LILO to boot, will need to run lilo in order to make their new kernel bootable. Many documents, including the article Dean mentions below, document how to do this—ED]

The new kernel turned out smaller—about two-thirds the size of the old kernel. Hopefully this will translate into a slight gain in speed. I also discovered—actually I remembered—that Linux Journal had an article in Issue 7 about compiling the kernel, called “Linux Performance Tuning for the Faint of Heart”. A quick review revealed that I answered the various kernel questions correctly. Very comforting and also informative. The article explained many of the default choices.

Time for the real test: shutdown Linux and reboot. The kernel loaded cleanly and apparently recognized the SoundBlaster. Great! I set up the swap file, fired up X-Windows, called up a term window, got into /usr/games/doom and ran linuxxdoom. It did its stuff, grinding and YES, YES, YES, DOOOOOOOOM WITH SOUND!!!!! It worked!

For a while, I thought it wouldn't work because there were many error messages during loading saying “can't find lumpname ( )”, but it worked!

Now, one more thing to test: whether DOOM would allow me to use an alternate .WAD file (data file) with the game. One of the great appeals of Doom is that the program allows you to use other data files, thus giving you good value for your $US40. People have created 1000s of new levels, sounds, and effects for Doom, Doom II, and the newest family member, Heretic. I doubted that I could use an alternate WAD with this shareware version of Doom because it is version 1.666. Supposedly, the earlier 1.2 version did have the external WAD support, but that meant users wouldn't necessarily buy the full version. Id Software, the publishers, removed that ability in the later shareware versions. Only registered users get to enjoy swapping WADs. I happen to have a WAD handy, so let's try it out:

doom -devparm -file acheron.wad -wart 1 3

The program starts and ends quickly. As I expected the shareware DOOM v1.666 won't run external WADs. I can vouch that the registered Unix version will allow that ability (having played it on a friend's Sun network).