Instructions for compiling and installing NetHack 3.0
on an AMIGA system
=====================================================
Last Revision: 4 February, 1991
Overview
--------
This file contains the procedure to follow when installing NetHack 3.0
on an Amiga computer system. It also includes some procedures and hints
for individuals desiring to create a binary from the source. This
document is divided into 4 sections. Section I deals with installing
already existing binaries and data files to create a working NetHack
game disk (or directory, in the case of a hard drive). Section II
describes, in general, how to produce working binaries from the source.
Section III and IV are compiler specific sections, with section III
designed for Lattice users, and section IV for Manx/Aztec users.
Requirements
------------
Amiga 500,1000,2000,2500 running WorkBench 1.3 and KickStart 1.2 or 1.3.
Amiga 3000 running WorkBench 1.3 or 2.0. For the Amiga 3000 under 2.0,
be sure to follow the directions below (don't panic, the changes are
minor.)
one meg of RAM and one floppy drive (painful, but functional)
or one meg of RAM and two floppy drives (much better)
or more than one meg of RAM and a hard disk with 2+ meg free (best)
Credits
-------
Olaf Seibert first ported NetHack 2.3 and 3.0 to the Amiga. Richard
Addison, Jochen Erwied, Mark Gooderum, Ken Lorber, Greg Olson, Mike
Passaretti, and Gregg Wonderly polished and extended the 3.0 port.
Section I - Installation Guide
-------------------------------
This section assumes you have the following handy:
* NetHack (executable code)
* Rumors file
* Oracle file
* All the various help and informational files (help, opthelp, etc)
* Special level files (castle, tower1, tower2, tower3, endgame)
* Amiga with at least 1 meg memory (may be optimistic....)
And optionally:
* Icons if WorkBench interface is to be used. These files include
+ NetHack.info
+ NewGame.info
+ NetHackScore.info
+ Guidebook.info
+ default.icon
* Special NetHack font (files hack.font and 8).
Installation Steps:
1) If you have a hard disk, create a directory named NetHack.
Assign NetHack: to be the path to this directory. If you have a
floppy, format a disk named NetHack. (If you have a hard disk
but only one meg of memory, you will probably not have enough
memory: you may need to run from a floppy.)
2) If you have a hard disk, assign HackExe: to the above directory.
If you have a floppy, format an additional disk named HackExe.
3) Copy NetHack, NetHack.info, NewGame.info, and NetHackScore.info
to HackExe. Create an empty file called NewGame (WorkBench
refuses to Duplicate a project icon without a file attached).
4) Copy the remainder of the files to NetHack:. If you are using
the optional font, create a Hack subdirectory on NetHack:, and
copy "8" into it. Be sure that Guidebook and Guidebook.info are
in the same directory, and that the Default Tool field points to
the More program (found on your AmigaDos System disk in the
Utilities directory). Depending on where you got your copy of
NetHack, the Guidebook file may be called Guidebook.mss.
5) Configure NetHack.cnf as per your configuration. Remember not
to set GRAPHICS if you are not using the optional font. If you
have only one meg of ram, do not use a ram disk.
6) AMIGA 3000 running AmigaDos 2.0 ONLY:
If you are using the optional font, you need to build a new
hack.font file. Execute the following commands from the CLI:
copy NetHack:hack FONTS: all
FixFonts
copy FONTS:hack.font NetHack:
delete FONTS:hack all
That's all there is to it! If you are using the CLI interface, make sure
that the stack is set fairly large (at LEAST 40000 bytes). Move to the
NetHack: directory, and type NetHack <cmd line options>. If you're
using the WorkBench interface, click on the NetHack directory/disk.
You should see 3 icons. Select the "NewGame" option, and "Duplicate"
from the WorkBench pull down menu. This icon now represents your
personal profile. You can now rename this icon, and tailor it to your
liking as described below. If you start a game from the WorkBench
interface, saving the game will automatically tie the personal file icon
to the saved game. So the next time you double click your icon, the game
will be restored.
As mentioned above, the icon representing your personal profile can be
customized. This is done via the the Info command available from
WorkBench. You can adjust the following using the ToolTypes from the
WorkBench info command:
* OPTIONS=<options> - Options as available in the NetHack.cnf file.
* HACKDIR=<directory> - Set NetHack working directory to be this
directory.
* RAMDISK=<ram disk> - Set up ram disk option.
* LEVELS=<levels> - Intermediate level saving device/directory.
* PATH=<path> - To search for files such as rumors, help, etc.
* CMDLINE=<args> - Arguments as passed on the CLI command line.
Note: only the following flags are valid: n, X, D, and r.
* SCORE <options> - Display the record of scores. Options as
available on the CLI command line after a -s flag.
Note that the NetHack.cnf file is read first, then the ToolTypes. This
means that the options specified in the NetHack.cnf act as defaults
which can be overridden by an individual's personal icon's ToolTypes.
Thus the system oriented entries (HACKDIR, RAMDISK, LEVELS, and PATH)
should generally be set only in NetHack.cnf. NetHack.cnf should have
default values for OPTIONS, which will generally be overridden by
ToolTypes entries.
Also, there is one additional option that may be specified in the
NetHack.cnf file or on an OPTIONS line: flush. When enabled, flush
discards all characters in the queue except the first, which limits
but does NOT completely eliminate the "accidents" which can occur if
you get ahead of the game when typing. The default setting is noflush.
Section II - General Compilation Instructions
---------------------------------------------
1) Before doing any compilation, read the README files distributed
with the source. These should familiarize you with the source tree
layout, and what files are shared with what computers. Generally,
everything in the amiga directory is used exclusively by the Amiga.
2) Create the sub-directories, and name them as indicated in the source
README file. If you have a hard drive, this is fairly trivial
(create a directory, and corresponding NetHack sub-directories).
If you have only floppies, you'll have to be a bit more clever.
The makefile (Makefile.ami) is set up to depend upon certain
assignments, providing the developer with a fairly flexible
environment. The main directory with which a floppy user will have
problems is the src directory. In order to fit all of the source on
to floppies, the src directory has been split into logical units.
For example, the makefile expects:
Src1: contains src [a-l]*.c
Src2: contains src [m-po]*.c
Src3: contains src [pr-z]*.c
See makefile.ami for assignment assumptions.
3) Edit config.h to your liking and system configuration. The following
are strong suggestions for certain #define values.
+ UNIX - DO NOT DEFINE
+ MSDOS - DO NOT DEFINE HERE, IT WILL BE DONE LATER FOR YOU
+ COMPRESS - DO NOT DEFINE
+ ZEROCOMP - DEFINE
+ CHDIR - RECOMMENDED
+ HACKDIR - "NetHack:" MANDATORY
+ BITFIELDS - DO NOT DEFINE IF YOU HAVE MANX3.6
+ CLIPPING - DO NOT DEFINE
4) Edit amiconf.h to your liking. It is recommended you leave
everything as is with the following exceptions:
+ TEXTCOLOR - Will allow the use of colors for text objects in
the game. For instance, red gems will be red. Unfortunately,
at this time this is only configurable at compile time, when
it really should be configurable at run time. Note also that
there is a slight bug when running textcolor, namely that when
you are polymorphed, the color you are is not correct because
the cursor overlays the default monster color. You can see
yourself fine, but you do not represent the correct monster color.
+ HACKFONT - Enable if you want to use the special NetHack font,
disable otherwise.
+ AMIGA_WBENCH - Enable if you want the WorkBench interface to
be compiled into the code. This does NOT preclude you from
running from CLI.
5) If you have significant spare ram, you may wish to make your
compiler resident (Lattice 5.05's lc, lc1, and lc2 need about
215K while Manx's cc and as need about 135K).
6) At this point, you're almost ready to begin a compile. Read VERY
CAREFULLY through the Makefile to familiarize yourself with which
assignments are assumed. Otherwise, you're going to get something
like "Insert O_Src1: in any drive." requestors. If you have the
uudecode program and need to uudecode the various *.uu files from
the Amiga: directory (font and icons), define the UUDEC symbol
at the appropriate place in the makefile. The first thing
Makefile.ami does is build a program called 'makedefs', which
handles a variety of data file generation, and a program called
'lev_comp' which compiles the special levels. Makedefs will then be
run to create a few files, followed by an alphabetically sorted
compilation of the entire source tree. This compilation process
will compile selected files from Amiga:, Others:, Src1:, Src2:,
and Src3: directories. If all goes well, all of the objects will
be linked together to form a binary. With all of the options
enabled, the Manx 3.6 executable runs about 790K, and the Lattice
executable runs about 750K (without debug hunks, or about 1025K
with debug hunks - see below). After building the main binary,
the makefile will build and install the auxiliary files including
help files, special levels, icons, and the font files.
SECTION III - Lattice Compilation Instructions
----------------------------------------------
If you're a Lattice user, you should be pretty well set up at this point.
If you have some spare ram, you may wish to examine the Amiga:compact.lat
script. This script will reduce your compile time by using Lattice's
lcompact utility to pre-scan the header files and place compacted copies
onto the Ram: disk. Read through the comments in that script if you
wish to utilize it.
Due to a problem with versions 5.04 and 5.05, you must make one change:
edit the file Others:lev_lex.c. At (or near) line 1003 is the definition
for the function yyunput. Delete the word "register" from this line.
Note that if you neglect to do this, you will get an Error 72 at line 319
of file lev_comp.l (this is the correct message - lev_lex.c is flex output).
Save the changed file. Later compiler versions do not need this fix.
There is one other bug available: depending on the way your versions of
lex/flex and yacc/bison generate #line statements, you may get requestors
for "Src1: (just one quote). If so, just select Cancel on the requestor.
Type 'CD NetHack:' and then type "lmk -f Amiga:Makefile.ami". If all
goes well, you'll have a working binary a couple of hours later (depending
on your hardware configuration). A couple of notes and warnings from the
Lattice users on the team:
* The primary Lattice compiler used on the Amiga port was version
5.05. Previous versions of NetHack have been successfully compiled
with 5.04 and 5.04a. Final development of PL10 was done with 5.10.
* The function monsndx, in file mondata.c, has a section of code
which Lattice 5.04 compiles incorrectly. A hack has been written
around this so that Lattice will generate the correct code. It is
recommended that you leave this in place, and not attempt to
"improve" it. This fix "does the right thing" in later versions.
* Included in the Lattice port is code for generating a SnapShot.tb
file upon catching various internal disasters. That is why the
-d1 flag is in the makefile. This adds about 270K to the disk
image, but it does not increase the run time memory requirements.
Floppy users will have to delete -d1 flag, or the binary won't
fit on a single disk.
* The optimizer seems to work, but no extensive testing has been
done with it. (Note: optimizing objnam.c takes several hours.)
* There are a large number of warnings under Lattice, which are
harmless.
SECTION IV - AZTEC/MANX Compilation Instructions
-------------------------------------------------
Note: The current version of nethack does _not_ run with the Aztec 5.0
compiler. Future releases of Nethack will remedy this, but currently
only 3.6 is supported.
NetHack 3.0 compiles and runs fine under Aztec 3.6, but a little bit
of work is necessary. The problem is that the Aztec pre-processor
is fairly stupid, and doesn't recognize the defined() pre-processor
function. Unfortunately, this function is laced throughout the NetHack
code, hence removing it would be quite a chore, and end up rendering the
code much more unreadable.
There are a couple solutions to this problem. The first solution is to
run every source file through some c pre-processor which understands
defined() (the Decus cpp works fine). The problem with this solution is
that the time it takes to compile/recompile is (at least) doubled. My
configuration is a 33 meg hard drive and 2 1/2 megs of ram, and it still
takes over 4 hours to generate a binary from scratch! Also note that
Makefile.ami was not built to support cpp, and so you'll have to modify
the makefile to add this step.
But don't despair, have we got a deal for you! The Apple NetHackers also
had a similar problem with defined, which led them to developing a
defined() hack (located in config.h). This hack basically adds
the defined() functionality to the Aztec pre-processor, with the exception
of performing this operation on strings. Fortunately, using defined() on
strings is done very rarely, and they are handled on an individual basis.
(The only one I can think of right now is WIZARD/WIZARD_NAME). What's the
catch, you ask? Well, there is one. The problem is as follows.
The Aztec compiler doesn't know how to handle const, volatile, and signed
data types. Normally, this can be fixed by sticking a #define const
before const is used, thereby rendering it disabled. Unfortunately, the
Aztec pre-processor, in its infinite wisdom, WILL NOT LET YOU REDEFINE
these strings.
The solution to this is not quite as elegant as the solution to the
defined() problem above. It requires a one time modification to the
Aztec cc binary. (DO THIS TO A BACKUP COPY OF CC!!) Find a disk zapper,
NewZap works fine. Then do a search for the string 'const'. Change
the const, signed and volatile strings to __nst, __gned and __latile.
(It's really not as bad as it sounds....)
A couple of warnings regarding the 3.6 compiler/NetHack:
* The 3.6 Manx bitfield handling is buggy at best. Though I can't
specifically cite a flaw when NetHack is compiled with it, I
don't trust it. I recommend you don't either.
* If your signal.h (in your Manx include directory) has SIGINT
commented out, go ahead and uncomment it.
* If you use the cpp method, pass -DAZTEC_C and -DMCH_AMIGA to
the cpp. These are defined automatically by Aztec C, but are
ineffective if the source is run through a filter first.
* There will be a few harmless warnings in the compile process.
These warnings will be in amidos.c, and pickup.c. There may also
be a warning when defining lev_lex.c that LEV_LEX is redefined. This
is OK. Any other warnings should be investigated.
* I haven't tried sdb on it, as I can't afford the disk space. (You'll
have to save the intermediate cpp files if you cpp). Unless you've
got a whopping amount of memory, I suspect it's going to be too large.
* There are 2 versions of lev_lex.c that are being distributed; one
generated by (unix) lex, and one generated by gnu flex. The gnu
flex lev_lex.c should work without modification. If you use the
lex lev_lex.c, you will get 4 warnings regarding ptr/int conversions.
Change the masks from (int) to (long) to generate a clean binary.
* Unfortunately, Manx 5.0 arrived too late to integrate into patch
level 7, but merging will occur in the next few weeks. Contact us
(below) for progress/hints. (Postscript for PL8: the situation is
very much improved, but there may be some problems remaining).
- - - - - - - - - - - -
If you have problems or questions, email to nethack-bugs@linc.cis.upenn.edu,
or directly to Greg Olson (golson@sundown.sun.com) for Manx questions,
to Ken Lorber (keni@dtix.dt.navy.mil) for Lattice questions, or to
Richard Addison (addison@pollux.usc.edu) for either. Have fun!!
