Compile 1981 Zork sources

[larsbrinkhoff]

Use the MDL interpreter and Zork source code to make a runnable Zork.

[larsbrinkhoff]

[larsbrinkhoff]

About ZORK^K versus :ZORK, it could be that something senses the state of %OPCMD in the OPTION user variable.

[popeyeotaku]

I was just thinking, if the ZORK source directory was encrypted and also hidden via a patch to ITS, perhaps the executable directory was as well, and ZORK^K was a command patched into DDT to allow execution of the file that DDT couldn't otherwise find

[eswenson1]

Since I was a user of DM and MC at the time all this was happening, I can attest to the fact that the executable directory was not hidden. And zork^K was not a patched DDT command. It was a regular executable program. It did include various checks to ensure the game wasn't played outside appropriate hours and on other machines, but in most respects it was just an ordinary program. It, however, was just a launcher, and loaded a saved MDL environment from the file system and executed it. The reason why the ZORK artifacts for ITS are not easily located is because the DM system on which the resided did not perform the same kinds of backups as the other ITS machines and because we don't have any tape images of the backups it did do. And because ZORK couldn't be run on any of the other ITS machines, it didn't get backed up on those machines' backup tapes.

[larsbrinkhoff]

But some ZORK SAVE files have been backed up...

[eswenson1]

Those are just personal save files, right? Not the MADADV SAVE files that hold the dumped MDL environment. We used to copy the ZORK SAVE files to other machines for safe keeping. After spending many hours playing Zork and making progress, you never want to have to start all over again. So gotta keep those files safe from deleting fingers.

[larsbrinkhoff]

Yes, they are personal save files. But there's a theory that they actually holds the entire MDL state.

...

Checking the size of such a save file seems to refute that. It's only 13K words. And it's rather sparse at that.

[eswenson1]

Yes, it is just the save of a bunch of values.

[larsbrinkhoff]

@jclaar has the code ported to C++

https://github.com/jclaar/zork

[larsbrinkhoff]

We have two save files:

MADMAN; MADADV SAVE (1977-12-13)
MADMAN; OMADAD SAVE (1977-12-04)

[larsbrinkhoff]

Of course I get this:

<RESTORE "MADMAN;MADADV SAVE">$

*ERROR*
MUDDLE-VERSIONS-DIFFER

[larsbrinkhoff]

The LCF directory has what appears to be the December 1977 source code for Zork. At this point, it was renamed Dungeon.

<DEFINE ZORK ()
    <TELL "That word is replaced henceforth with DUNGEON.">>

[larsbrinkhoff]

According to the loader code above (trivia startup) the very first word of the SAVE file is the Muddle version number as an ASCII string. It's 54.

[larsbrinkhoff]

More of the Muddle compiler and libraries are appearing on ToTS tapes.

There are also ready built MADADV SAVE files, and a TS MUD54. I have tried to run them, but they don't work fully. I have a theory that Muddle also needs some of the SAV and/or FIX files from MUDSAV or MUDRST.

[atsampson]

If you've got a TS MUD54, you could try Zork from the ats/zork branch and see if it loads the full game without running out of memory (revert the "Reduce the amount of code" comment, and possibly the XUNAME one as well since that was a MUD56-ism)...

[larsbrinkhoff]

Various sources refer to Zork sorce code in either the LCF or CFS directory. Which one would be more appropriate here?

[larsbrinkhoff]

@ZoBoRf tested the new Muddle, and confirms GC is much more stable!

[larsbrinkhoff]

Two sets of Zork source and binary files from ToTS:

• From December 1977
• From January 1978

[larsbrinkhoff]

ToTS tape 9004083 has a file \MADADV.ITS-XXFILE:

MUDDLE^[^K
^^R
<RESTORE "MUDDLE;M55UNI">^[
<FLOAD "CFS;LITLPK FBIN">^[
<USE "CLEAN" "PURITY">^[
<SET CH <OPEN "READ" "CFS;ZORK DUNG">>^[
<RENAME "CFS;ZORK DUNG">^[
<FLOAD "LIBRM3;LSRTNS FBIN">^[
<SNAME "CFS">^[

...

<RENAME "ZORK GBIN">^[
<KILL:PURITY>^[
<FLUSH-CLEANUP>^[
<UNASSIGN X>^[
<REMOVE <GUNASSIGN PURE-LIST>>
<REMOVE <UNASSIGN FOO>>^[
<DEFINE F (BAR) <GUNASSIGN <REMOVE .BAR>>>^[
<F DROP>^[ <F L-UNUSE>^[ <F USE>^[ <F ENTRY>^[ <F PACKAGE>^[ <F ENDPACKAGE>^[ <F FIND/LOAD>^[
<F F>^[
%%<HANDLER <GET ERROR!-INTERRUPTS INTERRUPT> ,ERRH>^[
%%<SETG MUD-HAND <OFF <3 <GET ,INCHAN INTERRUPT>>>>^[
%%<SETG ZORK-HAND <OFF <HANDLER <GET ,INCHAN INTERRUPT> ,CTRL-S>>>^[
<GC 0 T>^[
<SETG DBG <>>^[
<GC-MON T>^[
<BLOAT 0 0 0 0 0 300>^[
<SAVE-IT "CFS;TEMP" <>>^[
^^J
<QUIT>^[

[larsbrinkhoff]

Since #1951 provides a runnable Zork, I'd like to repurpose this issue for compiling the 1981 Zork.

[larsbrinkhoff]

@eswenson1 has made some progress compiling Zork with the Muddle 55 compiler.

[larsbrinkhoff]

@eswenson1 confirmed the 1981 616-point Zork works and can be played to conclusion.

Users (well one: @hesam66) have been asking about getting this version. I think the binary can be put in this repository, even if the tools and build script can not. It can replace the 1978 binary in place now.

[eswenson1]

Unfortunately, the binary (MADMAN;MADADV SAVE) is dependent on MDL 55. I compiled the sources with MDL 55, and it uses the MDL 55 interpreter and runtime. Therefore, before we can commit this version of Zork to the Git repository, we'll have to get a release from the MIT archives for its dependencies.

[eswenson1]

I’m currently trying to tackle an issue getting the MDL 55 interpreter to run successfully when linked with the latest binaries from MIT. When NPCK (package manager) is loaded it loads LIB (the library system) and gets an error due to a broken implementation of OBLIST?. Taking a fix from MDL 106 (addition of a single HRLI instruction) fixes that problem and allows both NPCK and LIB to load. However, I’m currently only able to load NPCK NBIN and not NPCK FBIN. The latter is what the MUDSYS;NEWMUD > source tries to load when setting up a new MDL. I’m getting a FATAL ERROR ILLEGAL UUO. Trying to find the cause of that.

Note: I’ve successfully compiled, loaded, and dumped a ZORK with MDL 55 — but I was using interpreter, assembler, and compiler binaries from ToTS. Now I’m trying to build the interpreter, assembler, compiler, and libraries from source. This is proving difficult.

Note 2: Our MDL 56 (from MDL 106) is the bare bones interpreter — it does not include the package system, library system, pure library system, and all the runtime libraries. Before I integrate MDL 55, I’d like to have all that working from source (it works from ToTS binaries and a few recompilations).

[larsbrinkhoff]

Thanks for the note, @eswenson1.

I suggest it would be worthwhile to do a half way pull request to build Zork using the binary versions. It's not that it's urgent, but I'm sure a few intfic fans would be curious to experiment with the game in its original form.

[larsbrinkhoff]

@heasm66, maybe you want to keep an eye on this.

[heasm66]

Great progress! Are MDL 55 released by MIT now?

[eswenson1]

Yes. I don’t know if MIT has prepared (yet) an actual release, but I’ve been given permission to release it as part of the “its” GitHub repo.

[heasm66]

Will both MDL54, 55 & 56 be on the platform at the same time (is that possible?)?

[eswenson1]

Yes. I have all three running on my ITS system. However, when I make my update to the repo, it still will be the case that MDL 55 will be full-featured (interpreter, compiler, assembler, package and library system, pure library system, etc.), while MDL 54 and MDL will have their current minimal interpreter support.

MDL 54 won’t load NBINs created by the MDL 55 compiler (although MDL 56 will). And the runtime and pure library systems won’t offer support for MDL 54.

After getting MDL 55 “in” and working satisfactorily, I will try to get MDL 56 to have all the same functionality as MDL 55 — I may not be successful in this regard as I’ve had limited success so far.

I’ll probably be recommending people use MDL 55 for any MUDDLE development, as my MDL 55 on ES has been very functional for months. The other two are simply “toys” due to all the missing support.

[heasm66]

Sounds fantastic!

[larsbrinkhoff]

I'm closing this since #2150 is almost there.