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.
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:
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