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(a)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/0130a67fc44e0c7de1faa8f882cb…
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(a)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-…
>
>
> Gabi
>
>
>
>
>