Don't require players to have a home directory or not be playing in
business hours, etc.
The original code expects TS MUD54 to be in SYS1, but our SYS1 is
bursting at the seams already, so make it look at MUDSAV instead.
Both of these are from MIT's zork-1978-01 release. MADMAN; MADADV SAVE
is from 1978-01-28 (it's madadv.save_3 there), and TAA; ZORK 3 is from
an archive dated 1978-01-27. Unfortunately this isn't the final version
of Zork -- in particular, it doesn't have the endgame.
The launcher will also work with the other 1977/78 Zork images MIT have
released, provided you copy them to MADMAN; MADADV SAVE.
Note that we already have the non-DM fake Zork in SYS3; TS ZORK, but
the real Zork was in SYS2; on DM, so the recommended ZORK^K will find it
first.
These two databases contain pure code routines that Muddle images can
refer to. We don't currently have whatever tool was used to maintain
them, so this is a MIDAS program that creates and populates them.
SAV FILE includes some stubs for functions in the LSRTNS and MUDDLE
libraries -- these are the functions that the existing Muddle 54 Zork
images need.
For the FIELD function in LSRTNS, returning FALSE is equivalent to the
user not being found. I have no idea what C-FCN in MUDDLE is for, but
very early Zork calls it after a command is entered, and seems happy
enough with it doing nothing.
In the DEC Processor Reference Manual, this is documented as "result is
indeterminate", and there's a note in the ITS KL microcode implying that
the default KL behaviour was different from the KA.
Muddle 54 uses this to drop a temporary stack frame from TP in a few
places. If it doesn't work properly, one obvious result is that READing
bracketed expressions leaves garbage on the TP stack -- e.g. typing
<QUIT> at the interpreter will print a FIX instead.
Muddle 56 replaces this with MOVE TP,(TP), so do that as a new patch.
This source was reconstructed to match MUDSAV; TS MUD54 from 1977-07-02,
using a combination of all the surviving Muddle source files. The memory
layout and pure code is the same.
No AGC MUD54 has survived, so the AGC code was adjusted to match the
TOPS-20 agc.mud104 from Chicago that Rich Alderson provided (the only
ITS conditional is the page size). There's a one-instruction difference
in the symbol positions, which I've converted into a patch at the end of
the code to maintain the original layout on ITS.
The INITM code, which doesn't appear in the final executable, is
a best guess but it's probably fairly close, since it generates objects
in the right order and locations, and the symbol locations match the
original.
The 1977 executable has a very large number of patches, which I've
replicated in MUD54 INIT. The code that the patches were replacing --
marked with "XXX patched" in the source -- is also a best guess.
I haven't checked that the TOPS-20 code is correct; it could be adjusted
to match mdl104.exe in the future. It would need STENEX, which could be
linked from MUDSYS;.
Previously the first XFILE printed out some commands to run after STINK
had completed, which is awkward if you're building Muddle repeatedly.
This automates the second half of the build process.
Lars has found a couple of examples of TS MUD54 files, and they're the
initialised version (with references to internal functions filled in,
etc.). TAA's ZORK launcher also expects TS MUDxx to be the initialised
version. So it appears that the ITS version didn't generate TS MDLxx.
(Why does the initialisation process write out TS MUD56, then, if you're
only going to pdump the result over it? Because the last step in
initialisation is to invoke the GC, and getting back from the GC to the
interpreter requires mapping pages back in from the executable.)
Found from comparison with a TS MUD54 binary. The Muddle 56/106 source
came from TOPS-20 originally, and it had been extracted with newline
conversion but not ITS encoding.
Most of these are cosmetic, but there are a couple of VALRET strings
with embedded \rs -- including the one used to exit initialisation.
So successful initialisation now finishes with a *, rather than opening
a random location.
This wasn't updating UBAIFS owing to a typo ("LSH A,B" for "LSH
A,(B)"), so it always returned the first slot number. It's not actually
used anywhere in ITS 1650, so this didn't break anything.
This replaces the existing MUDSYS;STINK 2 that was installed as TS
STINKM. The bad-EXPUNGE patch in there is no longer needed now Muddle is
built with MIDAS 73.
<mdl.int>stink.mid.1 was the version of STINK used for building Muddle
106; it's STINK 121T with (not quite correct) ITS/TENEX conditionals
added. This imports all of the changes from that copy, except for those
that only altered whitespace.
It also avoids some mangling of the embedded DDT commands in our current
copy.
MACDMP MOBY1 has 340 support, but only works with the old PDP-6
microtape device. MACDMP 6U32 has both microtape and TD10 support,
but no 340 code. Both programs can be adjusted for core size.
Most of these are the same as before. For UUOH, I've taken the fixed ITS
conditionals from uuoh.mid.181 (16th March 1981). For MAPPUR, I've put
the Tenex conditional around the whole of the segment-switching code
since none of it is needed on ITS.
Note in particular that the BOT patch is no longer needed -- this
version of Muddle works happily with the pure region at 700000.
Looking at the backup dates for files in <mdl.int>, mdl106.exe is from
20th January 1981, whereas some of the source files are from a couple of
years later. Revert to the last version prior to 20th January 1981 -- in
every case, this was the earliest revision that was kept in <mdl.int>.
This undoes the changes that we'd previously made to these files, many
of which are no longer necessary now that we're using MIDAS 73.
The 1973 MUDDLE; TS MIDAS binary has these four instruction aliases with
SI at the end (and they weren't used in the 1973 Muddle at all). All
later versions of MIDAS use RI names, as does more recent Muddle source,
so this must have been patched in later.
Older versions of MIDAS expect you to type a command at them, which
makes them hard to automate with :x or XFILEs. This patch backports the
JCLINI code from later versions of MIDAS, which pre-stuffs the command
buffer with the JCL string if available.
This was edited from later versions of the source to match MUDDLE; TS
MIDAS circa 1973, which was built with MOBY==0. The program itself dates
from no later than 1971. Comments, and results when built with other
options, are probably not historically accurate.
MIDAS 73 is useful because 74 and all later versions have completely
rewritten code for relocatable output (and for IO), and they don't
support some of STINK's features correctly (or at all). A ported version
of MIDAS 73 was still being used to build Muddle in the 1980s, going by
<mdl.int>midas.exe.5.
This matches a TS MUD from 1977, and is the same as TS MUD54 with the
addition of SGC. It's nearly the same as the Tenex order we had already.
There are a few differences between 54 and 56:
- CONST is new in 56;
- Three source files in 54 were merged into others in 56: TENTAB into
READER, FLOATB into PRINT, and CHAN into FOPEN;
- DISPLA, which went between CREATE and SAVE in 54, is missing in 56.
When converting BRD pkts to RFC, use MYCHAD for the destination address, not whatever is at address MYCHAD.
Result: responses to BRD pkts use the correct source address.
BLKLDR 1 is from the IMLAC; IML DEVICE archive file dated 1976-11-02.
The archive was found in three identical copies on ToTS tapes 7006990,
701351, and 90606; they were extracted by Brad Parker. The BLKLDR 1
timestamp inside the archive is 1975-01-26. Tape database records
from DM show a BLKLDR 4 dated 1974-08-19.
To build the IMLAC; IMLAC BLKLDR file, it's first assembled with
MIDAS. Regular IMTRAN writes the block loader format, but the block
loader itself is in the "special TTY" boostrap format. IMTRAN is
runtime patched to skip the block framing.
The file IMLAC; SSV 52 dated 1973-01-07 was edited to match the Imlac
block loader format file http://www.ubanproductions.com/Imlac/ssv,
which claims to be SSV 22. SSVMSE 38 from 1977-12-13 was also helpful
in the process.
IMSRC; SSVCHR 22 is entirely from disassembly. The original file
would have been machine generated by SYMFOR.
The LOADER subroutine breaks MAZE because it pushes all code higher,
making constants and WALLS cross over 14000. It's also unnecessary
since setting the start address to 101 jumps back to SSV which will
accept the next data block sent from the PDP-10.
A possible explanation is that LOADER was added by someone running
MAZE without SSV. No other version of the MAZE source code has
LOADER.
