From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 8eff0f07 for ; Sat, 7 Dec 2019 01:29:35 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id D5C1B9BF76; Sat, 7 Dec 2019 11:29:34 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3BBCD94BF4; Sat, 7 Dec 2019 11:29:12 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="hqcH4r5s"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9CD6B94BF4; Sat, 7 Dec 2019 11:29:10 +1000 (AEST) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 17AA793D35 for ; Sat, 7 Dec 2019 11:29:10 +1000 (AEST) Received: by mail-oi1-f180.google.com with SMTP id a67so1531755oib.6 for ; Fri, 06 Dec 2019 17:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=x+XH7QgjJbNVz7IFX6lPVUVvNhZmow4PhbkmtxoNXIw=; b=hqcH4r5s2UtLauWd/0POHQkYtMQnpfLEqoCiAWn3HbVBpPj0qOpYCaZsGfbdplyQzS PFxdNOZMIxMlraY0b/r/mxsTQ+aGLmfMnWwkrL4IeW4eifwcWPuEDia+IEvGo/cKayPD /gSQM/DK4lhB+LzLNlcRZ7NvBP/kkg928zkKMfzlw+7Ra+yAXGbjvBuVxyjk98FfcvHO Jw1UEpEHoZlV+/5eTiLPe0QsvYIdfRpGMwoL7yZWhbwilBwG5TvHhqeDb/zBUgmro+vX cpG7iIMDn62auxifLhuTZUOpnXn0cZRjaR5GY9wg/0G5IC4tWaBZoa6e03kn32XeCtLY BJpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=x+XH7QgjJbNVz7IFX6lPVUVvNhZmow4PhbkmtxoNXIw=; b=h/ejpTlgcXnm1nOemxmZWFiu/QT5AP2tT8wLUT8/5YVSqjdDAlXfqCFNN70I57J5Qy NEaNfr/6I9IAek62XlZCuAQ87mjqRr8KYP27zzj+gaCk0LONopuwY4H/2bd3/4qtDKXM 1Ew/YZB/6fF7ub+2X5xwItCslCqQ8eeUMGh4mmgnSYtLS3XKdMh7G7Zk+7x0ElA/iaex 5Ba1rz51YXxb/iazlfCMMAAXGJFg1q9ErJNvVNHm7oUy6NFtsBwGHKD4lEbZFL07jY2L xanps/iMy/+v1r6UEV+9nUDynrkQyUKuJ+z8rzUcjTO1Zq7rjmSOUBvJmsFt2qLIZdnQ Ik5w== X-Gm-Message-State: APjAAAXvwwPB1W7bzC3Q/FhvH5HEDPaxtSVBoJ1U9NV2zuiQDh4aNSpm x+rxjno74pAiNQwLyxcjvl+AnT4/6LoCwE8/5FdWGQ== X-Google-Smtp-Source: APXvYqzls/CaKwsADqzRdTzfeSvE7BjrNpdMJcQnC4Uc/NoT/dpqqlnGXtN8pSDbngxKED0wEyino8OBadSJZfNdRWU= X-Received: by 2002:aca:bbc6:: with SMTP id l189mr8883602oif.53.1575682149212; Fri, 06 Dec 2019 17:29:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Adam Thornton Date: Fri, 6 Dec 2019 18:28:57 -0700 Message-ID: To: Gabriel Diaz , The Eunuchs Hysterical Society Content-Type: multipart/alternative; boundary="000000000000c865b8059913168b" Subject: Re: [TUHS] Gaming on early Unix X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000c865b8059913168b Content-Type: text/plain; charset="UTF-8" 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 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 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 >> >> >> >> >> --000000000000c865b8059913168b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, OK, there's one other wrinkle.=C2=A0 Buildi= ng Frotz on 4.3BSD (or whatever) on a VAX would be easy, because you have a= 32-bit address space.=C2=A0 But the Z-machine can address 64Kwords (plus s= ome trickiness for access strings in high memory) so you'd have to actu= ally implement a segmented memory model or overlays or something to squeeze= it into a PDP-11.=C2=A0 Which is obviously doable--after all, the Z-machin= e was designed to be implemented on 8-bit micros!--but means that porting F= rotz might be more work than just writing a new interpreter, and supporting= the later, larger games (Infocom used the v5 format, which doubled the siz= e and required 128K even on 8-bit systems, and a lot of the post-Infocom co= mmunity work--before the community went to Glulx, which is a 32-bit-inspire= d-by-the-z-machine-virtual-machine-for-text-adventures--used z8, which doub= led the size again) is going to be harder.

Jimmy M= aher has just been talking about the evolution of the Z-machine over on filfre.net.=C2=A0 It's well worth readin= g.

Adam

On Fri, Dec 6, 2019 at 6:22 P= M Adam Thornton <athornton@gmail.= com> wrote:
There was not a Z-Machine interpreter for Unix mac= hines, as far as I know, until the release of the ITF interpreter in the ea= rly 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 t= he "Frotz" Z-Machine interpreter to TOPS-20.=C2=A0 https://github.co= m/athornton/tops20-frotz and https://github.com/athornton/gnusto-fr= otz-tops20

This was not all _that_ hard.=C2=A0= 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 li= nker requires all symbols that are linked between modules to be six charact= ers or shorter (and case is folded), so I wrote a transmogrifier (gnusto-fr= otz) to extract those symbols and create a mapping for them so that the obj= ect code would link.

The second problem was that t= he Frotz source assumes 8-bit bytes and that your word length is a multiple= of 8 bits.=C2=A0 Since the Z-machine is a 16-bit virtual machine, that mea= nt 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.=C2=A0 That's done with stuff like:

So the idea is, gnusto-fro= tz-tops20 is semantically equivalent to regular Frotz, but with macros chan= ged so if you build it with -DWEIRD_WORDSIZE it would build on a 36-bit sys= tem.=C2=A0 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 +=3D being =3D+ and so= forth, and I think I have to chop another character off the symbols, which= may mean I need smarter collision detection.=C2=A0 So it's nontrivial.=

Maybe a good first step would be unprotoizing Fro= tz 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 yo= ur favourite game?


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


Gabi



<= div>
--000000000000c865b8059913168b--