There are no other files named twenex.install in the archive.
@. Note: The file TECO.FILES describes all of the files and what
they are used for.
The TECO that supports EMACS is written in MIDAS, a dialect of assembly
language; assembling will require the MIDAS assembler, MIDAS.EXE, and the
JSYS bit definitions, TWXBTS.MID, in addition to the source file, TECO.MID.
The distribution tapes contain the assembled files TECO.EXE, TECPUR.EXE,
and EMACS.EXE, but they are assembled using a particular setting of the
many assembly switches. If the setting is not right for your installation,
you must reassemble TECO and then follow a complicated procedure for
regenerating the other files. This procedure is automated by the batch
control file EMACS.CTL.
Assembly options are specified in the file CONFIG.MID which is included
automatically in the assembly. Here follows a description of the assembly
options and how to modify CONFIG.MID specify them as you want them.
1. <EMACS> vs EMACS: and <INFO> vs INFO:
The TECO code of EMACS assumes that by specifying the directory name
EMACS it can always get at the directory on which the standard libraries
If the system configuration does not include an <EMACS> directory, and
one cannot be easily set up, it is possible to have TECO translate
references to this directory to the refer to EMACS: instead. EMACS: can
then point to any directory. If the assembly switch EMCSDV is set
non-zero, this translation is enabled; the batch control file, EMACS.CTL,
has the correct provisions for setting this switch. Likewise INFODV will
cause translation of the INFO directory into the INFO: device.
If your system has more than one structure, then you must set up system
logical names for EMACS: and INFO: and turn on the INFODV and EMCSDV
flags, in order that standard libraries be found on the correct structure
no matter which one you are connected to.
2. Terminal types
TECO has display support for various common terminal types. There are
facilities for conditionally assembling them, but unless you take special
efforts the macros in TECO will cause them all to be assembled in. The
assembler macros in TECO also assign the system's GTTYP indices to TECO
internal terminal type numbers.
In the TECO assembly, each kind of terminal that TECO has code for has a
name, such as "VT52". In CONFIG.MID, for each type of terminal that your
system has a GTTYP index for, you should set that symbol's value to the
It turns out to be unwise to use the DEC-supplied ".TT" symbols for those
GTTYP indices, because some of those symbols may have a different value
Terminal types you omit will still be supported by TECO but TECO cannot
automatically recognize them; the user will have to do M-X Set Terminal
Type to tell TECO to cater to the specific type of terminal.
The macro GLASCD is defined to tell TECO about GTTYP codes for "glass
teletypes". These are supposed display terminals which are not powerful
enough for actual screen editing (or which TECO does not have code for).
TECO treats them a little different from terminals that have real paper.
Replace the "20" in the square brackets with any number of GTTYP index
numbers, separated by spaces.
3. Files produced
After the assembly, starting the resultant program at symbolic location
PURIFY will generate two binary files, TECO.EXE.nnn, and TECPUR.EXE.nnn,
the former is a stand alone version of the TECO, and need not be kept
around after EMACS.EXE and INFO.EXE have been made, and the latter the
binary file that EMACS will load when started up. It must be on <EMACS>
or EMACS: to be found. In addition, the file TEMP.EXE is left around
deleted. It is the actual immediate output from the MIDAS assembler. If
there is any problem with the building of NEMACS.EXE by the EMACS.CTL
file, you can undelete TEMP.EXE and try things by hand starting after the
It DOES NOT WORK to restore all of the files on the EMACS tape onto one
directory! There are files with the same filenames that are different
and must be on different dirs.
It is important to use RESTORE *.*.* to load the files off the tape, and
NOT just RESTORE *.* . The third star causes the version numbers to be
copied off the tape. Otherwise the default is zero and the files all
become version 1.
The EMACS.CTL file will try to expunge old versions of the EXE files that
it produces. If anyone is using them, this cannot be done. Thus, if
anyone uses the NEMACS.EXE file while it still has that name, he must
reset his fork before the EMACS.CTL file is submitted again.
To debug EMACS, you must use IDDT, which runs the program being debugged
in a separate fork. EMACS uses its entire address space, and always uses
the area where DDT would normally live. An IDDT is supplied on the tape,
under the name <EMACS>NDDT.EXE.
The NEMACS.EXE produced by the DUMP macro (see batch control file) should
be installed as SYS:EMACS.EXE, perhaps after verifying that it basically
runs. Other EMACS binary files live in either <EMACS> or EMACS: depending
on the configuration (vide supra).
We normally make the version number of EMACS.EXE be the last two digits of
the EMACS version number, followed by the last three digits of the TECO
In addition to EMACS' self documenting features, the INFO library provides
a means of perusing the EMACS documentation (or any documentation suitably
formatted for that matter). Most files are of the form
<INFO>SUBJECT.INFO., but see above about INFO:. <INFO>TECORD..nnn is the
complete documentation of the TECO itself that supports EMACS.
INFO is intended to be invoked from within EMACS, but there is also a
"stand-alone" version of INFO which can be invoked directly from the EXEC.
The EMACS.CTL file builds a stand-alone INFO under the name NINFO.EXE.
This should be renamed to XINFO.EXE somewhere on SYS:.
D. What the batch control file does
This section is only like to be useful to people on Tenex, rather than
Tops-20, since some Tenex systems do not have a batch processor, so the
creation must be done manually. Tops-20 users may as well stop here.
Running the midas assembler and saying TEMP_TECO to the * prompt will
assemble the source TECO.MID into TEMP.EXE (or .SAV on Tenex). For each
terminal type that TECO knows about, the user is asked to specify the
number used by the GTTYP JSYS for that terminal type. If none is defined
for your system, just type return. Then on pass two, the user is asked for
the indices of "glass terminals", that is crt's without enough display
support for EMACS.
2. Running TEMP.EXE
The resultant save file from the assembly should be started at symbolic
address PURIFY. This will generate TECO.EXE (.SAV on Tenex) and
TECPUR.EXE. It will also run the TECO.INIT file to load up the default
EMACS environment. For this to work, you must be connected to EMACS when
you start up the temporary save file. Then type
(or .sav on Tenex), just like in the EMACS.CTL file. This will dump out
the default environment that got loaded up to the runnable file NEMACS.EXE.
If doing this manually, you should probably verify at this point that that
file works right for your system.
3. Making stand-alone INFO and TEACH-EMACS
The new TECO is now run twice with different EMACS init file to generate
NINFO.EXE (the stand-alone INFO program) and TEACH-EMACS.EXE (.SAV), the
EMACS tutorial. Each time, the TECO executes TECO.INIT to turn itself into
an EMACS, then stops in TECO command level. At that time the EMACS init
file for INFO or TEACH-EMACS is explicitly read in and executed. This
EMACS init file builds and dumps the EXE file for INFO or TEACH-EMACS.
The EMACS M-$ (meta-dollarsign) command uses the ISPELL program, included in
the EMACS directory. ISPELL (for ITS-type SPELL, to distinguish it from DEC's
SPELL program) runs on TENEX and TWENEX; however, the M-$ command (and related
ones in EMACS) depend on JSYS-passing techniques that do not work under TENEX.
The source for the ISPELL program is <EMACS>SPELL.MID. It is written in MIDAS,
the same PDP-10 assembly language as TECO. Copies of this assembler (and other
utility programs) are also available from MIT. The SPELL.DCT file is the
current dictionary of words for ISPELL. Documentation on ISPELL is in
ISPELL.EXE should be installed in EMACS:ISPELL.EXE or in SYS:ISPELL.EXE. SYS:
is checked first, so it will confuse EMACS if there is a program called
ISPELL.EXE that is the wrong one.