Jason Scott just posted all of the source code for Infocom's text games.
I can just leave that statement there, right? I don't have to elaborate? Jason describes it better than I could, anyhow:
So, Infocom source code is now uploaded to Github. Most people don't speak or want to speak the language it's written in, ZIL (Zork Implementation Language). You can browse through it and kind of suss out what's being done when and the choices made over the course of time.In cases where the source code had multiple revisions, and I don't know the story of what revisions came when and came why, I did a reasonable job of layering them out (this came before that, that came after that) and doing multiple "check-ins" of the code so you can see diffs.Often, there are cases that some games were built up from a previous game, allowing modification of the macros and structures and then making them work in the new game. For example, an NPC partygoer in one game was a thief in a previous one. Dungeons become stores, etc.--@textfiles (Jason Scott), from a twitter thread
This material has been kicking around for a while now. If you search for articles about "the Infocom drive", you'll see some discussion from years past. Actually, don't do that, it's mostly old arguments that don't need to be rehashed.
The point is that a great deal of historical information about Infocom has been preserved -- but it's not publicly archived. You can't go research it anywhere. Nobody admits to having it, because it's "proprietary IP", and you're not supposed to trade in that stuff because companies like Activision make the rules.
So when Jason puts this information online, he's taking a stance. The stance is: history matters. Copyright is a balance between the rights of the owner to profit and the rights of the public to investigate, discuss, and increase the sphere of culture. Sometimes the balance needs a kick.
Quite possibly all these repositories will be served with takedown requests tomorrow. I'm downloading local copies for myself tonight, just in case.
One other note: Jason's comments say "...there is currently no known way to compile the source code in this repository into a final "Z-machine Interpreter Program" (ZIP) file." This is somewhat out of date. There are long-standing open-source efforts to build a ZIL compiler. ZILF is the most advanced one that I know of. I don't know whether it's rated to compile this historical ZIL code -- but I'm sure that people are already giving it a shot.
I had a conversation with Jason years ago about "the Infocom Drive" and releasing the source code. So glad to see it has finally happened.ReplyDelete
ZILF throws a few warnings, but...ReplyDelete
$ mono ../bin/zilf.exe zork1.zil
ZILF 0.8 built 3/19/2017 12:34:17 AM
Renovated ZORK I: The Great Underground Empire
[warning MDL0417] /Users/erd/projects/Intfict/zilf/zilf-0.8/foo/GCLOCK.zil:31: ROUTINE: only 3 routine arguments allowed in V3, so last 2 "OPT" arguments will never be passed
in INSERT-FILE called at zork1.zil:19
in IFILE called at zork1.zil:41
[warning ZIL0504] /Users/erd/projects/Intfict/zilf/zilf-0.8/foo/GPARSER.zil:229: treating SET to 0 as true here
[warning ZIL0505] /Users/erd/projects/Intfict/zilf/zilf-0.8/foo/1ACTIONS.zil:2484: COND: clauses after else part will never be evaluated
[warning ZIL0502] /Users/erd/projects/Intfict/zilf/zilf-0.8/foo/1ACTIONS.zil:3283: RETURN value ignored: block is in void context
$ mono ../bin/zapf.exe zork1.zap
Wrote 94664 bytes to zork1.z3
$ frotz zork1.z3
ZORK I: The Great Underground Empire
Copyright (c) 1981, 1982, 1983 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Revision 0 / Serial number 190416
West of House
You are standing in an open field west of a white house, with a boarded front
There is a small mailbox here.
The disk is correct.
It compiles with ZILF? Great!ReplyDelete
You're welcome, guys. At least I'm in a place where I can cop to it now.ReplyDelete
I strongly maintain a Z-code interpreter must be (re)written for the PDP-10.ReplyDelete
Thanks for doing the ZILF test! But does ZILF compile the source into the same binary as Infocom shipped? That's the next question.ReplyDelete
It appears to be functionally close but it's not identical.Delete
The next level test would likely be easiest to generate some ZAP assembly and compare it to some of the files that have survived in the old Infocom development directories.Delete
Of the form...
EQUAL? RARG,M-ENTER \?ELS5
ZERO? CASTLE-ENTER \?ELS5
PRINTI "As you pass through the gate, you feel that your mind is being probed. After a moment, it is released or, perhaps, discarded as uninteresting."
That particular trivial fragment looks identical in the output of ZILF (except the specific name of the branch destination - \?ELS5 vs \?L1) but the output side matches up this way...Delete
$ ls -l
-rwxrwxrwx@ 1 erd staff 111126 Feb 14 1994 enchanter.zip
-rw-r--r-- 1 erd staff 125568 Apr 18 00:35 enchanter.z3
A difference of +13% but I have to admit I was in a bit of a hurry and didn't check my abbreviations on this run. I don't think it's that bad when you use the same *.zxap abbreviation file as the original.
Thanks for posting details!Delete
To be clear, nobody's saying that ZILF *should* produce byte-identical compiled output.
Looking at the results may tell us something about what kinds of optimization ZILCH used, and (more abstractly) how much Infocom relied on high-level code structures in ZIL vs simple if/and/or game logic.
Producing byte-identical output is a non-goal for ZILF. It is a goal for ZAPF, though - we should be able to produce identical output if we have identical assembly code.Delete
Yes. I'm not advocating byte-identical output of ZILF either, I was just pointing out that it wasn't and from my limited experience, it didn't appear to produce smaller binaries either.Delete
ZAPF _should_ be producing byte-identical output, of course.
Adam Thornton here. Something about my Chrome setup doesn't want me to post while I'm logged in, so I'm using incognito.ReplyDelete
It strikes me that if we have a good way to get from ZIL to ZAP to Z-Code, then maybe we should set aside looking for the MDL interpreter libs for the PDP-10, and just port a Z-Machine interpreter.
Now, ITS struck me as miserable, a face only a mother could love, et cetera. But both TOPS-10 and TOPS-20 were reasonable systems. TOPS-10 has Pascal; TOPS-20 has a K&R C Compiler. I don't think a Z-Machine interpreter is going to be all that hard; I mean, sure, at least initially we're talking dumb-frotz level and nothing that does interesting screen handling, but it's a place to start.
So bringing the games back to the PDP-10 is probably eminently doable. The LCM provides accounts on its systems, so running it on the real iron rather than just on an emulator is probably doable.
I encourage this line of inquiry from a safe distance. :)Delete
(I could have used the TOPS-20 system at CMU when I was an undergrad, I think. But the shiny new AIX workstations were obviously much preferable.)
I've had an account on the LCM machines for years. I've been using it to compare the output and behavior of Zdungeon with "Mainframe Zork" - found a couple of bugs in my Inform code that way.Delete
Well, here's my first stumbling block:
"However, the situation is different for symbols with external
linkage, which must be exported to the PDP-10 linker. Such names are
truncated to 6 characters and case is no longer significant."
Guess I'm writing some preprocessing macros to map the extern symbols to unique 6 character ones.
OK, I'm past that bit. I have a compiled executable that does not segfault on startup.
Unfortunately it won't run a game. I suspect I have been bitten by (as documented in "README.dumb":
"- lack of 8-bit char and 16-bit short. I didn't bother to think much about this. If you're using a 36-bit Honeywell or something, let me know."
Work so far is available at https://github.com/athornton/gnusto-frotz-tops20
Adam again, from a different machine, so maybe this will work without being anonymous.ReplyDelete
Does anyone here know where I might lay my hands on the Infocom Drive image itself? It might speed up the TOPS-20 port of Frotz to have the source to a TOPS-20 Z-Machine interpreter. The 9-to-8 bit conversion is a little tricky. (I am, however, not stuck yet.)
Adam, yet again: it's working now.ReplyDelete