This is an exercise in transparent programming. It runs Zork 1 (r88) using a modified Parchment interpreter that displays the source code for the current turn. You can also explore the world tree, the global variable list, and other game state displays.
This is really cool! I’ve been trying to write my own interpreter and for some reason on startup it’s printing Coal Mine instead of West of House. I’ve been trying to find a good way to inspect globals and compare to what an established interpreter is doing, but couldn’t find a good thing to compare against.
Encrusted is good for seeing the opcodes that are being called, but doesn’t show the globals. I tried ZORKMID, but it’s kind of clunky to use and also doesn’t clearly show globals.
This looks like exactly what I’ve been looking for!
Oh, I cringed seeing all the layers of cruft around Gnusto. Any reason you chose to hack such an old version of Parchment over a newer build? Maybe that ZVM’s JIT is actually counter productive for the introspection this needs?
I chopped most of it out! There’s just a couple of glue functions left.
Yes, it’s silly that the Gnusto engine calls the UI layer which generates a list of orders that I immediately translate into GlkOte data. But it wasn’t hard to work with, and taking out one more layer was more effort than it was worth. This is v3 so it’s using barely any display features anyhow.
I figured the older the interpreter, the simpler it would be!
I had to fix a v3 bug somewhere in Gnusto. (I get the impression that it was written in the era when all games were v5/8.) But getting into it was easy, and I was able to instrument the code without disturbing much.
Cool. I wrote Infocom way back when wondering what language they used. So I could write a game like it. Got a nice handwritten letter back, telling me no no, proprietary, and a free subscription for the Zork Times. Found Inform and Curses later (bullentin board on AOL).
I later learned they used Lisp later and I bought a book on it. And I guess there was a free compiler somewhere. While I like OOP I could not make or tail of Lisp.
Your programing is over my level, but it is intriguing to see how they did it, also considering computers had so much less memory then. Very brief. Reminds me of assembly language, a course I did not complete in college. That was main frame assembly language, the Prime 360 or something. It was like trying read hex. No thanks.
I have always been fascinated by the Infocom games.I like seeing under the hood. My favorite was Suspect. There was a lot more interactivity in that game than most realized.
I can’t resist pointing out that the work of mapping all the symbols to story file addresses would’ve been easier had you recompiled the game with ZILF and extracted them from the debug file.
But I suppose there’s nostalgia value in using the original story file.
It didn’t work. Attributes and properties came out in a different order. Ditto global variables. Also the game file was the wrong length. I suspect that was because I failed to turn on abbreviations, but it seemed like it wasn’t going to work out for multiple reasons so I abandoned that approach.
Yes, you’re not the first person to think of that.
It would be a bunch more work and somewhat less polished in the end. (The Zork app hard-codes a bunch of information which isn’t available in the debug file. Timer table format, global variable types, property types, etc.)
Note that doing that work would only benefit I6/PunyInform/ZILF users, which is a pretty small niche. The real win would be benefiting I7 users. But obviously that’s a much harder problem, because of the two-stage compilation! We’d have to update I7 to generate a lot more debug info.
(I did some work on #OrigSource directives in I7’s Inter output. But it’s very much not road-tested.)
Mm, yeah, you’d have to use the story file generated by ZILF in order for the symbol data to be useful. ZILF can produce functionally identical output from Infocom’s ZIL source (modulo some minor patching), but its internal structure will be quite different.
