Well, OK, there's one other wrinkle.  Building Frotz on 4.3BSD (or whatever) on a VAX would be easy, because you have a 32-bit address space.  But the Z-machine can address 64Kwords (plus some trickiness for access strings in high memory) so you'd have to actually implement a segmented memory model or overlays or something to squeeze it into a PDP-11.  Which is obviously doable--after all, the Z-machine was designed to be implemented on 8-bit micros!--but means that porting Frotz might be more work than just writing a new interpreter, and supporting the later, larger games (Infocom used the v5 format, which doubled the size and required 128K even on 8-bit systems, and a lot of the post-Infocom community work--before the community went to Glulx, which is a 32-bit-inspired-by-the-z-machine-virtual-machine-for-text-adventures--used z8, which doubled the size again) is going to be harder.

Jimmy Maher has just been talking about the evolution of the Z-machine over on filfre.net.  It's well worth reading.

Adam

On Fri, Dec 6, 2019 at 6:22 PM Adam Thornton <athornton@gmail.com> wrote:
There was not a Z-Machine interpreter for Unix machines, as far as I know, until the release of the ITF interpreter in the early 90s.

However....

Zork was developed under ITS (when it was "mainframe Zork" and an MIT student project), and the later Infocom games were developed under TOPS-20.

As it happens, I've fairly recently ported the "Frotz" Z-Machine interpreter to TOPS-20.  https://github.com/athornton/tops20-frotz and https://github.com/athornton/gnusto-frotz-tops20

This was not all _that_ hard.  KCC on TOPS-20 is an ANSI C compiler, so there were basically two classes of problems to solve.

The first one is that the linker requires all symbols that are linked between modules to be six characters or shorter (and case is folded), so I wrote a transmogrifier (gnusto-frotz) to extract those symbols and create a mapping for them so that the object code would link.

The second problem was that the Frotz source assumes 8-bit bytes and that your word length is a multiple of 8 bits.  Since the Z-machine is a 16-bit virtual machine, that meant there was a whole lot of bit masking necessary in the opcodes and memory references in order to represent the Z-machine memory correctly within the TOPS-20 address space.  That's done with stuff like:

https://github.com/athornton/tops20-frotz/blob/0130a67fc44e0c7de1faa8f882cbc28faee76756/frotz.h#L488

So the idea is, gnusto-frotz-tops20 is semantically equivalent to regular Frotz, but with macros changed so if you build it with -DWEIRD_WORDSIZE it would build on a 36-bit system.  Then once you've modified the source, you run it through the transmogrifier (which really just generates a sed script) to get something that will _link_ on a 36-bit system.

I have vague plans to port Frotz to ITS but the problem there is that the C compiler is pre-K&R rather than ANSI, so there's a lot of deprotoization work to be done, and _then_ I need to fix the things like += being =+ and so forth, and I think I have to chop another character off the symbols, which may mean I need smarter collision detection.  So it's nontrivial.

Maybe a good first step would be unprotoizing Frotz and getting it to build on v7 or so...

Adam

On Fri, Dec 6, 2019 at 3:52 AM Gabriel Diaz <gdiaz@qswarm.com> wrote:
Hello,


Source code has been published of some early games.

Were those games playable on Unix machines at the time? What was your favourite game?


https://kryptonradio.com/2019/04/18/zork-source-code-presumed-lost-forever-has-been-uploaded-to-github/


Gabi