[Z-Machine] Compilers from TADS, Alan, HUGO into Z-Machine
Daryl McCullough
The Z-machine, although designed to play Infocom adventures, has a
pretty general machine language. I've heard tell that Tetris has been
implemented in it (although that may be just a heroic legend). Is
there anything (other than lack of time, interest or skill) standing
in the way of writing compilers for non-Inform interactive fiction
systems (TADS, Alan, HUGO) that produce Z-code?
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Paul F. Snively
In article <6bsc0o$d...@drn.newsguy.com>, da...@cogentex.com (Daryl
McCullough) wrote:
> The Z-machine, although designed to play Infocom adventures
Not entirely true. The Z-machine was designed to implement a virtual
processor for a significant proper subset of a language called MDL that
enjoyed some popularity within the Lincoln Laboratory at MIT. I believe it
was Stu Galley of Infocom who characterized MDL as "Lisp 1.5 with data
types," a bit of a joke based on the (now long archaic) notion that the
only data type Lisp has is the list, "Lisp" standing for "LISt Processing."
The comment is true, though, inasmuch as the motivation for constructing
this subset of MDL was to allow Zork to be reimplemented on small machines
such as the PDP-8, and the subset was indeed named "Zork Implementation
Language," or ZIL, and the runtime for it was called the "Zork Interpretive
Processor," or ZIP. The names are misleading, though, as (I'm led to
understand) the most significant differences between ZIL and its parent,
MDL, were ZIL's relative lack of sophisticated I/O features (MDL apparently
had them, passed them on to MacLisp, and MacLisp apparently passed them on
to Common Lisp, as anyone familiar with Common Lisp's "format" function can
tell you).
>has a
> pretty general machine language.
Exactly. MIT was a hotbed of Lisp activity, of course, and the Z-machine
should rightly be considered a "Virtual Lisp Chip." MIT would also create
literal hardware Lisp chips which went into Symbolics, Inc. and Lisp
Machines, Inc. workstations.
>I've heard tell that Tetris has been
> implemented in it (although that may be just a heroic legend).
Heroic legend that happens to be literally true; you can download it from
the IF archives, I believe as part of a larger collection of Mr. Andrew
Plotkin's work--including, incidentally, a not-half-bad interactive Lisp
tutorial.
>Is
> there anything (other than lack of time, interest or skill) standing
> in the way of writing compilers for non-Inform interactive fiction
> systems (TADS, Alan, HUGO) that produce Z-code?
Without having actually investigated the source code, having played a bit
with both Inform and TADS, I strongly suspect that such a thing could be
done for TADS (that is, the semantics of Inform and TADS strike me as being
very close to begin with). Not having played with Alan or Hugo at all, I
cannot comment either positively or negatively.
> Daryl McCullough
> CoGenTex, Inc.
> Ithaca, NY
Paul Snively
Former Activision Keeper-of-the-Flame
Member, Knights of the Lambda Calculus, Los Angeles Chapter
<mailto:ch...@mcione.com>
Thomas Aaron Insel
da...@cogentex.com (Daryl McCullough) writes:
> The Z-machine, although designed to play Infocom adventures, has a
> pretty general machine language. I've heard tell that Tetris has been
> implemented in it (although that may be just a heroic legend). Is
> there anything (other than lack of time, interest or skill) standing
> in the way of writing compilers for non-Inform interactive fiction
> systems (TADS, Alan, HUGO) that produce Z-code?
It's theoretically possible. Memory (of the Z-Machine) is a limitation.
TADS games are normally much bigger than Inform games, and would need
extra code to deal with the functionality provided by the TADS runtime,
so I'm not convinced even a shortish game would fit.
I expect that the amount of labor to do this would be quite high. It
might very well be easier just to translate all know TADS games by hand.
Tom
--
Thomas Insel (tin...@jaka.ece.uiuc.edu)
"I am an agnostic; I do not pretend to know what many ignorant men are
sure of." -- Clarence Darrow
Andrew Plotkin
Daryl McCullough (da...@cogentex.com) wrote:
> The Z-machine, although designed to play Infocom adventures, has a
> pretty general machine language. I've heard tell that Tetris has been
> implemented in it (although that may be just a heroic legend).
Why, thank you. :)
> Is
> there anything (other than lack of time, interest or skill) standing
> in the way of writing compilers for non-Inform interactive fiction
> systems (TADS, Alan, HUGO) that produce Z-code?
They're all possible. Not necessarily easy. I'd expect the problem to be
size limits. Small games will be convertable, large games won't be (due
to the 64K z-code RAM limit) and it's hard to predict where the cutoff
will be.
I've heard rumors of a TADS-to-zcode compiler in progress.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Julian Arnold
In article <6bsc0o$d...@drn.newsguy.com>, Daryl McCullough
<URL:mailto:da...@cogentex.com> wrote:
> The Z-machine, although designed to play Infocom adventures, has a
> pretty general machine language. I've heard tell that Tetris has been
> there anything (other than lack of time, interest or skill) standing
> in the way of writing compilers for non-Inform interactive fiction
> systems (TADS, Alan, HUGO) that produce Z-code?
It's been brought up a few times in the past. I don't know an awful lot
about the internals of these things, but for example: Hugo allows up to
128 attributes (currently) while Z-code has a limit of about half this
(the recent thread seems inconclusive so far); Hugo support multiple
identical windows, plus a "main" window while Z-code only allows one
(restricted) window, plus the "main" one; Hugo supports graphics, and
the unreleased next version supports sound and music, while Z-code is at
best limited and at worst incapable(?) in these respects; and so on.
Anyway, I'm sure it would be possible to produce a Hugo-to-Z-code
compiler, but to do so you would have to impose restrictions on the Hugo
format, disabling or crippling certain features. The same, maybe
reversed, can probably be said of other formats (TADS' dynamic object
creation).
While Z-code is undoubtedly impressive, especially considering its age,
and will continue to be something of a standard in IF for some time to
come, it is not the ultimate format (and I'm not suggesting that Hugo's
is either).
Jools
PS, check out freefall.z5. :)
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"
Jeff Hatch
Daryl McCullough wrote:
>
> The Z-machine, although designed to play Infocom adventures, has a
> pretty general machine language. I've heard tell that Tetris has been
> implemented in it (although that may be just a heroic legend). Is
> there anything (other than lack of time, interest or skill) standing
> in the way of writing compilers for non-Inform interactive fiction
> systems (TADS, Alan, HUGO) that produce Z-code?
I haven't even bothered to look at the Z-machine specs, so maybe I don't
know what I'm talking about. But I got the impression that the
Z-machine was designed to implement certain techniques and wouldn't
necessarily be efficient for a system that used different techniques.
And my brother who looked at the Z-machine advised me to port my system
to Java instead. Some of my problems with the Z-machine: I don't like
attribute flags, I want my machine language's variable-setting function
to automatically save changes to an Undo buffer, I need my branch
command to implement quick memory allocation, and I want all text that
scrolls of the screen to be saved to an Undo buffer. Inform was
designed for the Z-machine; any other language may not be as well suited
to the Z-machine's abilities.
Besides, it seems that once Andrew Plotkin's Glk standard is widespread,
it'll be easy to port all the other systems to any platform that
supports a C compiler anyway. It'd be convenient if they all used the
Z-machine, but I don't think it's worth the trouble any more.
-Rúmil
Jason C Penney
Julian Arnold (jo...@arnod.demon.co.uk) wrote:
: It's been brought up a few times in the past. I don't know an awful lot
: about the internals of these things, but for example: Hugo allows up to
: 128 attributes (currently) while Z-code has a limit of about half this
: (the recent thread seems inconclusive so far); Hugo support multiple
: identical windows, plus a "main" window while Z-code only allows one
: (restricted) window, plus the "main" one; Hugo supports graphics, and
: the unreleased next version supports sound and music, while Z-code is at
: best limited and at worst incapable(?) in these respects; and so on.
The V6 Z-Machine supports multiple (8) windows, graphics, and sounds. The
restrictions may exist, but they aren't that bad. While it is still
not possible to make ones own graphics, it should be possible in the
near future (I hope). And with V6Lib (plug plug) it isn't that hard
to write V6 games anymore... (or it won't be once I get enough time to
finish the manual.. :( )
Later,
Jay
----
Jason C Penney (jpe...@cs.uml.edu) Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very
sophisticated idiots." -- The Doctor
Andrew Plotkin
Julian Arnold (jo...@arnod.demon.co.uk) wrote:
> > Is
> > there anything (other than lack of time, interest or skill) standing
> > in the way of writing compilers for non-Inform interactive fiction
> > systems (TADS, Alan, HUGO) that produce Z-code?
> It's been brought up a few times in the past. I don't know an awful lot
> about the internals of these things, but for example: Hugo allows up to
> 128 attributes (currently) while Z-code has a limit of about half this
> (the recent thread seems inconclusive so far)
Z-code has a limit of 48 attributes. Conclusively. I've got the spec
here...
But this isn't really a restriction for a compiler. It doesn't *have* to
use Z-code attributes to implement Hugo attributes. It could give every
object a 16-byte "attribute_list" property, and use bit-mask operations
to store the Hugo attributes there.
> Hugo support multiple
> identical windows, plus a "main" window while Z-code only allows one
> (restricted) window, plus the "main" one; Hugo supports graphics, and
> the unreleased next version supports sound and music, while Z-code is at
> best limited and at worst incapable(?) in these respects; and so on.
But these are really not critical properties of Hugo. There are existing
Hugo games which use only status window and no graphics. A cross-compiler
could handle those cases, and print a snarky error message if it found
any graphics commands.
Jason C Penney
[previous version of this article canceled...]
Julian Arnold (jo...@arnod.demon.co.uk) wrote:
: It's been brought up a few times in the past. I don't know an awful lot
: about the internals of these things, but for example: Hugo allows up to
: 128 attributes (currently) while Z-code has a limit of about half this
: (the recent thread seems inconclusive so far); Hugo support multiple
: identical windows, plus a "main" window while Z-code only allows one
: (restricted) window, plus the "main" one; Hugo supports graphics, and
: the unreleased next version supports sound and music, while Z-code is at
: best limited and at worst incapable(?) in these respects; and so on.
The V6 Z-Machine supports multiple (8) windows, graphics, and sounds.
The restrictions may exist, but they aren't that bad. While it is still
not possible to make ones own graphics, it should be possible in the
near future (I hope). I'm not sure what Hugo's windowing and graphic
capabilities are, but I would think that they could be handled by
clever cross-compiling...
Julian Arnold
In article <erkyrathE...@netcom.com>, Andrew Plotkin
<URL:mailto:erky...@netcom.com> wrote:
> Julian Arnold (jo...@arnod.demon.co.uk) wrote:
> > It's been brought up a few times in the past. I don't know an awful lot
> > about the internals of these things, but for example: Hugo allows up to
> > 128 attributes (currently) while Z-code has a limit of about half this
> > (the recent thread seems inconclusive so far)
>
> here...
>
> But this isn't really a restriction for a compiler. It doesn't *have* to
> use Z-code attributes to implement Hugo attributes. It could give every
> object a 16-byte "attribute_list" property, and use bit-mask operations
> to store the Hugo attributes there.
Good point.
> > Hugo support multiple
> > identical windows, plus a "main" window while Z-code only allows one
> > (restricted) window, plus the "main" one; Hugo supports graphics, and
> > the unreleased next version supports sound and music, while Z-code is at
> > best limited and at worst incapable(?) in these respects; and so on.
>
> But these are really not critical properties of Hugo. There are existing
> Hugo games which use only status window and no graphics. A cross-compiler
> could handle those cases, and print a snarky error message if it found
> any graphics commands.
Yes, but then why produce a cross-compiler? In effect, this would be
imposing severe restrictions on the development of IF systems: do it the
Z-machine way or not at all. This may seem OTT, but at the moment there
is little interest in Hugo (though it's growing folks!), and I can only
see this diminishing if it becomes possible to compile Hugo to Z-code,
despite the limitations this would impose.
Jools
Julian Arnold
In article <6busiu$nba$2...@ulowell.uml.edu>, Jason C Penney
> : It's been brought up a few times in the past. I don't know an awful lot
> : about the internals of these things, but for example: Hugo allows up to
> : 128 attributes (currently) while Z-code has a limit of about half this
> : identical windows, plus a "main" window while Z-code only allows one
> : (restricted) window, plus the "main" one; Hugo supports graphics, and
> : the unreleased next version supports sound and music, while Z-code is at
> : best limited and at worst incapable(?) in these respects; and so on.
>
>
> The restrictions may exist, but they aren't that bad. While it is still
> not possible to make ones own graphics, it should be possible in the
> near future (I hope). I'm not sure what Hugo's windowing and graphic
> capabilities are, but I would think that they could be handled by
> clever cross-compiling...
OK, I won't attempt to argue one way or the other. I'll leave that to
someone who knows the full facts. :)
A general problem with Z-code concerns expansion. Neither Graham nor
anyone else can expand or otherwise alter the Z-machine specs without
lots of discussion and debate among all concerned parties. And I suspect
there are a lot of concerned parties. Kent, OTOH, can do whatever the
hell he pleases with the Hugo format, as it's his.
Thus, expanding the Z-machine, if it's possible at all, takes mucho
time. Expanding Hugo, barring Act of Kent, is much easier and faster.
This, I suspect, is why Hugo got JPEG support in a few weeks, while
Inform's (modern) graphics support is still up in the air.
BTW, despite Kent's dictatorial privelege he is canny enough to take
advice before making major design decisions.
Jason C Penney
Julian Arnold (jo...@arnod.demon.co.uk) wrote:
: In article <6busiu$nba$2...@ulowell.uml.edu>, Jason C Penney
: <URL:mailto:jpe...@cs.uml.edu> wrote:
: > The V6 Z-Machine supports multiple (8) windows, graphics, and sounds.
: > The restrictions may exist, but they aren't that bad. While it is still
: > not possible to make ones own graphics, it should be possible in the
: > near future (I hope). I'm not sure what Hugo's windowing and graphic
: > capabilities are, but I would think that they could be handled by
: > clever cross-compiling...
: OK, I won't attempt to argue one way or the other. I'll leave that to
: someone who knows the full facts. :)
Do such people exist? Where can I find one? :)
: A general problem with Z-code concerns expansion. Neither Graham nor
: anyone else can expand or otherwise alter the Z-machine specs without
: lots of discussion and debate among all concerned parties. And I suspect
: there are a lot of concerned parties. Kent, OTOH, can do whatever the
: hell he pleases with the Hugo format, as it's his.
I'm not sugesting that a Hugo -> V6 Z-Machine compiler would be a good
idea, it's just a possibility. I certainly am not suggesting that
Hugo should change its format to Zcode.
: Thus, expanding the Z-machine, if it's possible at all, takes mucho
: time. Expanding Hugo, barring Act of Kent, is much easier and faster.
: This, I suspect, is why Hugo got JPEG support in a few weeks, while
: Inform's (modern) graphics support is still up in the air.
You have a very valid point there... *sigh*
Cardinal Teulbachs
On 12 Feb 1998 03:05:28 GMT, jpe...@cs.uml.edu (Jason C Penney) made
so bold as to state:
>Jason C Penney (jpe...@cs.uml.edu) Xarton Dragon -=<UDIC>=-
What I want to know is, is your name really J.C. Zorkmid? C'mon, now.
Tell the truth.
--Cardinal T
Jason C Penney
Cardinal Teulbachs (card...@cwia.com) wrote:
: On 12 Feb 1998 03:05:28 GMT, jpe...@cs.uml.edu (Jason C Penney) made
Nope sorry... JCPenney is really my name... I can't help it.
JCZorkmid would be a much cooler name though... :-)
Jay
----
Jason C Penney (jpe...@cs.uml.edu) Xarton Dragon -=<UDIC>=-
HarryH
In article <ant12182...@arnod.demon.co.uk>, jo...@arnod.demon.co.uk
says...
>> Hugo games which use only status window and no graphics. A cross-compiler
>> could handle those cases, and print a snarky error message if it found
>> any graphics commands.
>Yes, but then why produce a cross-compiler? In effect, this would be
>imposing severe restrictions on the development of IF systems: do it the
>Z-machine way or not at all. This may seem OTT, but at the moment there
>is little interest in Hugo (though it's growing folks!), and I can only
>see this diminishing if it becomes possible to compile Hugo to Z-code,
>despite the limitations this would impose.
Forgive my (lack of) English, but I'm not sure either you're for or against
limited Hugo2Z compiler.
I think it's a good idea to produce Hugo2Z compiler. Reasons being:
1. More choices, more freedom. LISP can be compiled to JVM. Great!
2. Not everyone wants/needs full capability.
3. Z-machine standard is evolving. Although we have Z8, who says we can't
have Z12?
4. Are you saying we should compile Inform to Hugo, instead? :)
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Cardinal Teulbachs
On Thu, 12 Feb 1998 04:49:32 GMT, erky...@netcom.com (Andrew Plotkin)
made so bold as to state:
>> Hugo support multiple
>> identical windows, plus a "main" window while Z-code only allows one
>> (restricted) window, plus the "main" one; Hugo supports graphics, and
>> the unreleased next version supports sound and music, while Z-code is at
>> best limited and at worst incapable(?) in these respects; and so on.
>
>But these are really not critical properties of Hugo. There are existing
>Hugo games which use only status window and no graphics. A cross-compiler
>could handle those cases, and print a snarky error message if it found
>any graphics commands.
But, Andrew, this is like saying that three-word (i.e.
verb-obj-indirectobj) command lines aren't critical properties of an
i-f system and are therefore expendable. According to one way of
looking at it, I suppose, they're not, since one can write games that
use only two-word commands (i.e. verb-obj only), but, realistically,
no one is going to stick with the old primitive method when the
capacity for having indirect objects is present. Speaking personally,
since Hugo's had windowing capability I haven't even considered doing
a game the old way--not that I despise the non-windowed style, mind
you. I just happen to like the Beyond Zork style of screen formatting
best; a style which is impossible to achieve without some sort of
windowing scheme.
(I just realized it may be well to point out that windowing and
graphics are two separate animals in Hugo, as you may be confusing
them. Windows are required in order to do graphics, true, but windows
can be used as pure, stand-alone, scrolling text areas as well. These
latter are the kind of windows I'm talking about. If the Z-Machine
can't do them or can't be made to do them, then there's little point
in even considering a Hugo to Z-code compiler, IMO.)
--CardinalT
Cardinal Teulbachs
On Fri, 13 Feb 1998 14:42:36 GMT,
har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) made so bold as to
state:
>Forgive my (lack of) English, but I'm not sure either you're for or against
>limited Hugo2Z compiler.
>
>I think it's a good idea to produce Hugo2Z compiler. Reasons being:
>1. More choices, more freedom. LISP can be compiled to JVM. Great!
No comprende. What we're talking about here is a *text adventure*
system.
>2. Not everyone wants/needs full capability.
Then give AGT a try.
>3. Z-machine standard is evolving. Although we have Z8, who says we can't
>have Z12?
I heard one guy in Iowa say we couldn't have it, but he probably
doesn't count. Seriously, though, check with your friendly
neighborhood bureaucrat of the Department of Inform and you might get
a better feel for this one.
>4. Are you saying we should compile Inform to Hugo, instead? :)
Absolutely. Every system should compile H-code. What a stupid
question, Harry.
--CardinalT
Jason C Penney
Cardinal Teulbachs (card...@cwia.com) wrote:
: Speaking personally,
: since Hugo's had windowing capability I haven't even considered doing
: a game the old way--not that I despise the non-windowed style, mind
: you. I just happen to like the Beyond Zork style of screen formatting
: best; a style which is impossible to achieve without some sort of
: windowing scheme.
But wasn't the Beyond Zork style originaly in Beyond Zork, a Z-Machine
game?? :-> Obviously it can be done, and has been.
: (I just realized it may be well to point out that windowing and
: graphics are two separate animals in Hugo, as you may be confusing
: them. Windows are required in order to do graphics, true, but windows
: can be used as pure, stand-alone, scrolling text areas as well. These
: latter are the kind of windows I'm talking about. If the Z-Machine
: can't do them or can't be made to do them, then there's little point
: in even considering a Hugo to Z-code compiler, IMO.)
The Version 6 Z-Machine can use up to 8 pure stand-alone scrolling
text areas, and it can, in fact put images in any of these windows.
What exactly are the characteristics of the Hugo Windowing system that
couldn't be achived in Z6? Is there a decent description of the
windowing system somewhere?
Andrew Plotkin
I tried to reply by email, but your address doesn't seem to work.
Cardinal Teulbachs (card...@cwia.com) wrote:
> On Thu, 12 Feb 1998 04:49:32 GMT, erky...@netcom.com (Andrew Plotkin)
> made so bold as to state:
> >> Hugo support multiple
> >> identical windows, plus a "main" window while Z-code only allows one
> >> (restricted) window, plus the "main" one; Hugo supports graphics, and
> >> the unreleased next version supports sound and music, while Z-code is at
> >> best limited and at worst incapable(?) in these respects; and so on.
> >
> >But these are really not critical properties of Hugo. There are existing
> >Hugo games which use only status window and no graphics. A cross-compiler
> >could handle those cases, and print a snarky error message if it found
> >any graphics commands.
> But, Andrew, this is like saying that three-word (i.e.
> verb-obj-indirectobj) command lines aren't critical properties of an
> i-f system and are therefore expendable.
No -- I'm saying that many of the games one might wish to translate don't
use those properties. Probably even a majority.
This is obviously not true of indirect objects.
It is, for example, true of third-object grammar lines. (Which are not in
the standard Inform library, but there's an exercise in the DM which gives
a hack to do it.) If someone was writing an Inform-to-Hugo translator
which couldn't handle the Inform hack for third-objects, they could make
the same argument as I'm making. And they could still translate almost all
Inform games.
Julian Arnold
In article <wZYE.34$Q6.7...@news1.atlantic.net>, HarryH
<URL:mailto:har...@iu.net.idiotic.com.skip.idiotic.com> wrote:
> In article <ant12182...@arnod.demon.co.uk>, jo...@arnod.demon.co.uk
> says...
> >In article <erkyrathE...@netcom.com>, Andrew Plotkin
> >> Hugo games which use only status window and no graphics. A cross-compiler
> >> could handle those cases, and print a snarky error message if it found
> >> any graphics commands.
> >imposing severe restrictions on the development of IF systems: do it the
> >Z-machine way or not at all. This may seem OTT, but at the moment there
> >is little interest in Hugo (though it's growing folks!), and I can only
> >see this diminishing if it becomes possible to compile Hugo to Z-code,
> >despite the limitations this would impose.
>
> limited Hugo2Z compiler.
I'm not *entirely* convinced by my own arguments. I have strong doubts
though.
> I think it's a good idea to produce Hugo2Z compiler. Reasons being:
> 1. More choices, more freedom. LISP can be compiled to JVM. Great!
Less choices, less freedom. There's no Mac port of Hugo, right? If it
became possible to compile Hugo to Z-code it would then be possible to
play Hugo games on a Mac, as there are plenty of Mac Z-machines. Great.
Everyone's happy.
Except that, as it is now possible to play Hugo games on a Mac there is
less demand for a Mac port of the Hugo Engine (HE). HE, though, has
capabilities the Z-machine does not. These capabilities cannot be used
if a game author wants to have a Mac audience. Does the author decide to
ignore the capabilities or to ignore the audience? I don't know.
However, I don't want this to be a dilemma at all.
Of course, there are certain platforms which can not handle all of HE's
features anyway. Thus the underlying problem does already exist. I'm
just concerned that this problem would be artificially exaggerated by a
Hugo-to-Z-code convertor (after all, the Mac, Im sure, *is* capable of
handling all of Hugo's features).
> 2. Not everyone wants/needs full capability.
No, but some people do. Why should this decision be forced in this way?
> 3. Z-machine standard is evolving. Although we have Z8, who says we can't
> have Z12?
Hugo's evolving. Faster. And may have more potential.
> 4. Are you saying we should compile Inform to Hugo, instead? :)
A fine idea! :)
No, I'm not sure converting one system's output to another is a very
good idea under any circumstances.
Julian Arnold
> I tried to reply by email, but your address doesn't seem to work.
>
> Cardinal Teulbachs (card...@cwia.com) wrote:
> > On Thu, 12 Feb 1998 04:49:32 GMT, erky...@netcom.com (Andrew Plotkin)
> > made so bold as to state:
>
> > >> Hugo support multiple
> > >> identical windows, plus a "main" window while Z-code only allows one
> > >> (restricted) window, plus the "main" one; Hugo supports graphics, and
> > >> the unreleased next version supports sound and music, while Z-code is at
> > >> best limited and at worst incapable(?) in these respects; and so on.
> > >
> > >Hugo games which use only status window and no graphics. A cross-compiler
> > >could handle those cases, and print a snarky error message if it found
> > >any graphics commands.
>
> > verb-obj-indirectobj) command lines aren't critical properties of an
> > i-f system and are therefore expendable.
>
> No -- I'm saying that many of the games one might wish to translate don't
> use those properties. Probably even a majority.
Not fair. There are only a handful of Hugo games so far. They don't use
the Hugo-only features, true[1], but it's not fair to take these as
being representative of Hugo's potential, which, I fear, is what may
happen should a Hugo-to-Z-code converter be written.
Jools
[1]: _Pirate_, for instance, uses windows but its screen model could be
achieved by Inform, I suspect[2].
[2]: Although with greater difficulty. :)
> It is, for example, true of third-object grammar lines. (Which are not in
> the standard Inform library, but there's an exercise in the DM which gives
> a hack to do it.) If someone was writing an Inform-to-Hugo translator
> which couldn't handle the Inform hack for third-objects, they could make
> the same argument as I'm making. And they could still translate almost all
> Inform games.
Precisely. They are different formats, with different capabilities. I
think it is possible that, given a Hugo-to-Z-code convertor, the Hugo
format, and thus its untranslatable qualities, could be sidelined and
ignored. I don't see the same happening to Z-code in the event of a
Z-code-to-Hugo translator, 'cause of Z-code's enormous, weighty
bandwagon. 'Tis a great steaming juggernaut of a format.
On balance though I think it is far, far better for people to port
individual systems to their platform than to convert system A to system
B for which they already have the interpreter. Of course a universal
format would be nice, but no-one has yet made a suitable proposal for
such.
Cardinal Teulbachs
On 13 Feb 1998 23:41:11 GMT, jpe...@cs.uml.edu (Jason C Penney) made
so bold as to state:
>Cardinal Teulbachs (card...@cwia.com) wrote:
>: Speaking personally,
>: since Hugo's had windowing capability I haven't even considered doing
>: a game the old way--not that I despise the non-windowed style, mind
>: you. I just happen to like the Beyond Zork style of screen formatting
>: best; a style which is impossible to achieve without some sort of
>: windowing scheme.
>
>But wasn't the Beyond Zork style originaly in Beyond Zork, a Z-Machine
>game?? :-> Obviously it can be done, and has been.
Oh, you're such a nitpicker, Zorkmid. I hate you :)
>The Version 6 Z-Machine can use up to 8 pure stand-alone scrolling
>text areas, and it can, in fact put images in any of these windows.
>What exactly are the characteristics of the Hugo Windowing system that
>couldn't be achived in Z6? Is there a decent description of the
>windowing system somewhere?
I was basing my comments on the following assertions from Jools, which
Andrew didn't contest. To wit:
"Hugo support multiple identical windows, plus a "main" window
while Z-code only allows one (restricted) window, plus the "main"
one; Hugo supports graphics, and the unreleased next version supports
sound and music, while Z-code is at best limited and at worst
incapable(?) in these respects; and so on."
I personally don't know whether the stuff about Z-code is true. I was
only arguing that *if* a suitable/compatible windowing system isn't
available in the Z-machine, then the chasm between Hugo and Z is
already too wide to be bridged, IMO.
--CardinalT
P.S. Doesn't Version 6 have memory restrictions? 256K or something
like that?
Cardinal Teulbachs
On Sat, 14 Feb 1998 13:40:11 +0000, Julian Arnold
<jo...@arnod.demon.co.uk> made so bold as to state:
>> > But, Andrew, this is like saying that three-word (i.e.
>> > verb-obj-indirectobj) command lines aren't critical properties of an
>> > i-f system and are therefore expendable.
>>
>> No -- I'm saying that many of the games one might wish to translate don't
>> use those properties. Probably even a majority.
>
>Not fair. There are only a handful of Hugo games so far. They don't use
>the Hugo-only features, true[1], but it's not fair to take these as
>being representative of Hugo's potential, which, I fear, is what may
>happen should a Hugo-to-Z-code converter be written.
Thank you, Mr. Jools. I think this is exactly the right answer. No
matter how pure everyones' intentions at the outset, we all know the
Z-code standards will follow Inform around and not Hugo, which means
that Hugo becomes at best in that scenario a useless appendage better
abandoned for the ubiquity of Inform.
>Precisely. They are different formats, with different capabilities. I
>think it is possible that, given a Hugo-to-Z-code convertor, the Hugo
>format, and thus its untranslatable qualities, could be sidelined and
>ignored. I don't see the same happening to Z-code in the event of a
>Z-code-to-Hugo translator, 'cause of Z-code's enormous, weighty
>bandwagon. 'Tis a great steaming juggernaut of a format.
Precisely. They are different formats, with different capabilities.
Oh, you said that. Well, the thing is, they're different formats, with
different capabilities, don't you see.
>On balance though I think it is far, far better for people to port
>individual systems to their platform than to convert system A to system
>B for which they already have the interpreter. Of course a universal
>format would be nice, but no-one has yet made a suitable proposal for
>such.
"'Tis a far, far better port ye do, man, than a lumpy auld Z-code
conversion."
--Charles Flathead, "A Tale of Two Bozbars"
Personally, I'm opposed to a universal format even if it's the cat's
meow as a game system. Even if it's Hugo's. Call me a rebel.
--CardinalT
Cardinal Teulbachs
On Sat, 14 Feb 1998 02:17:12 GMT, erky...@netcom.com (Andrew Plotkin)
made so bold as to state:
>It is, for example, true of third-object grammar lines. (Which are not in
>the standard Inform library, but there's an exercise in the DM which gives
>a hack to do it.) If someone was writing an Inform-to-Hugo translator
>which couldn't handle the Inform hack for third-objects, they could make
>the same argument as I'm making. And they could still translate almost all
>Inform games.
What you're talking about is a kind of legacy device, then? You seem
basically to want that any Hugo game that *might potentially* be made
to run on a Z-device actually be made to run on a Z-device? I don't
have any problem with that, if there is in fact someone out there just
dying to go to all the trouble involved in writing such a legacy
converter (for what is, in my view, very little in the way of a
potential payoff). In fact, who could stop them? Have at it, men.
--CardinalT
Andrew Plotkin
Cardinal Teulbachs (card...@cwia.com) wrote:
> >On balance though I think it is far, far better for people to port
> >individual systems to their platform than to convert system A to system
> >B for which they already have the interpreter. Of course a universal
> >format would be nice, but no-one has yet made a suitable proposal for
> >such.
> Personally, I'm opposed to a universal format even if it's the cat's
> meow as a game system. Even if it's Hugo's. Call me a rebel.
Well, I agree -- I'm *not* working on an anything-to-anything-else
compiler, I'm just speculating about it. I'm working on tools to make
porting systems easier.
(Of course that means a universal I/O API for the non-universal
systems... but that's life. :-)
Patrick Kellum
In article <34e63658...@news.cwia.com>, Cardinal Teulbachs was talking about:
>I was basing my comments on the following assertions from Jools, which
>Andrew didn't contest. To wit:
>
> "Hugo support multiple identical windows, plus a "main" window
>while Z-code only allows one (restricted) window, plus the "main"
>one; Hugo supports graphics, and the unreleased next version supports
>sound and music, while Z-code is at best limited and at worst
>incapable(?) in these respects; and so on."
Z-Machine has a maximum of eight windows, each of which can contain
graphics.
Just thought I'd mention it :-)
>P.S. Doesn't Version 6 have memory restrictions? 256K or something
>like that?
500+K (576K? some wierd number like that) more then even version 8
allows.
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry
Julian Arnold
> On 13 Feb 1998 23:41:11 GMT, jpe...@cs.uml.edu (Jason C Penney) made
> so bold as to state:
> >text areas, and it can, in fact put images in any of these windows.
> >What exactly are the characteristics of the Hugo Windowing system that
> >couldn't be achived in Z6? Is there a decent description of the
> >windowing system somewhere?
I'm not sure if this is a fair test, but here's little Hugo program:
routine main()
{
local l = 1, t = 1, r = 1, b = 1, c = 0
while true {
window l, t, r, b {
colour 0, c : cls
}
if ++c > 2: c = 0
r = ++l
if l > 80 {
l = 1 : r = 1 : t = ++b
if t > 25 {
pause
return
}
}
}
}
This opens 80 * 25 = 2000 windows (colouring the background in one of
three colours to make each window stand out). Each window is scrolling,
wrapping, graphics-capable, etc. (although as they only have an area of
1x1 characters they're not much use, except in this example). Of course
to make the windows useful you'd want to associate a window object with
each one, which would necessitate 2000 objects. I expect the maximum
number of windows is 32768 (like max. objects, and other upper limits).
Julian Arnold
In article <34e63658...@news.cwia.com>, Cardinal Teulbachs
<URL:mailto:card...@cwia.com> wrote:
> On 13 Feb 1998 23:41:11 GMT, jpe...@cs.uml.edu (Jason C Penney) made
> so bold as to state:
> >The Version 6 Z-Machine can use up to 8 pure stand-alone scrolling
> >text areas, and it can, in fact put images in any of these windows.
> >What exactly are the characteristics of the Hugo Windowing system that
> >couldn't be achived in Z6? Is there a decent description of the
> >windowing system somewhere?
>
> Andrew didn't contest. To wit:
>
> "Hugo support multiple identical windows, plus a "main" window
> while Z-code only allows one (restricted) window, plus the "main"
> one; Hugo supports graphics, and the unreleased next version supports
> sound and music, while Z-code is at best limited and at worst
> incapable(?) in these respects; and so on."
>
> only arguing that *if* a suitable/compatible windowing system isn't
> available in the Z-machine, then the chasm between Hugo and Z is
> already too wide to be bridged, IMO.
I forgot about Z6. OK, 8 windows is a lot (I don't know what Hugo's
maximum is). The 500+K limit mentioned by Patrick Kellum is not really a
limit at all, ATM. There's still the difference in graphics formats of
course: Hugo = JPEG, Z-machine = whatever weird format Infocom used,
maybe PNG in the future.
LucFrench
*ahem*
If I might sort out a part of this arguement:
People are confusing Inform with the Z-machine. The Z-machine has certain
features that Inform refuses to do for good reasons; most notably windowing.
Graphics as well, judging by the fact that a BLORB standard is even needed.
Thanks
Luc French
LucFrench
>>4. Are you saying we should compile Inform to Hugo, instead? :)
>
>question, Harry.
>
>--CardinalT
Because of a piculularity of AOL's Newsreader (at least as I use it), I got the
message [Newbie] before I got this message. I was wondering what the fuss was
about. And then I saw this.
Cardinal Teulbachs, I hereby condem thee to a visit by the Narn Bat Squad,
protectors of the inocenent newsreader, attackers of all who would make horrid
puns, post spoilers without protection, and flamers the world over.
You, by sending this post, have convicted yourself, and will therefore be
visited by them shortly. Listen for three knocks. A sample transcript from a
visit they made to me (for punning) follows:
*Knock**Knock**Knock*
>open door
(first getting out of your seat)
You open the door, and standing in front of you are five aliens, holding
baseball bats.
>run
*Tromp**Tromp**Tromp**Tromp**Tromp*
They catch up with you!
*WHAM!**WHAM!**WHAM!**WHAM!**WHAM!*
*Tromp**Tromp**Tromp**Tromp**Tromp*
You are on the floor of your living room.
>_
Thanks
Luc French
Member of Narnwatch
Jason C Penney
LucFrench (lucf...@aol.com) wrote:
: If I might sort out a part of this arguement:
Ahhh! Thanks for trying, but you seemed to have muddled it up a bit
more... :->
: People are confusing Inform with the Z-machine. The Z-machine has certain
: features that Inform refuses to do for good reasons; most notably windowing.
: Graphics as well, judging by the fact that a BLORB standard is even needed.
Inform does use both windows and graphics. Inform will compile nice
wonderful grapicsl v6 games, and my text only v6 advent uses 2
windows. One may emulate the status window, but it is a full fledged
separate Z-Machine V6 window. In fact I've written an Inform library
to handle the V6 features (*plug* V6Lib *plug*).
The Blorb standard is an attempt to make all interpreters on whatever
platform use a standard image file format, which Infocom didn't do.
Hugo uses a bunch of JPG files (I think) and the Z-Machine will (hopefully) use
a single Blorb file.
Later,
Andrew Plotkin
LucFrench (lucf...@aol.com) wrote:
> People are confusing Inform with the Z-machine.
Often, but not this time, I think.
> The Z-machine has certain
> features that Inform refuses to do for good reasons; most notably windowing.
> Graphics as well, judging by the fact that a BLORB standard is even needed.
No. Inform can compile in-line Z-machine assembly, so it can do about
anything that the Z-machine can do. (Well, not *quite* anything; there are
some exceptions. But they have nothing to do with I/O.)
((I'm thinking of stuff like initial values of local variables, which can
be anything in the Z-code file, but Inform always makes them 0. And some
obscure details of dictionary word structures. Never mind.))
Jason Penney's V6Lib is ordinary Inform source code.
The Blorb standard has nothing to do with this either. It addresses the
part of the problem which is *outside* the Z-machine specification. The
Z-spec says, for example, "The interpreter is expected to know how to
find the sound number X"; Blorb deals with how it finds it.
Julian Arnold
In article <19980215212...@ladder02.news.aol.com>, LucFrench
<URL:mailto:lucf...@aol.com> wrote:
> *ahem*
>
> If I might sort out a part of this arguement:
>
> features that Inform refuses to do for good reasons; most notably windowing.
Please expand. My understanding is that z5, z7, and z8 may have two
windows, while z6 may have up to 8 with identical capabilities.
Are these limitations Informy or Z-machiney?
> Graphics as well, judging by the fact that a BLORB standard is even needed.
I understand that the Z-machine is not strictly limited to Infocom's
graphics format. However, I would emphasize the problems with expansion
I mentioned upthread.
BTW, this discussion has evolved somewhat from its origins as a debate
about the pros and cons of a ?-to-Z-machine compiler. I hope it's not
being seen as a Hugo vs. Inform thread.
Cardinal Teulbachs
On Mon, 16 Feb 1998 11:41:38 +0000, Julian Arnold
<jo...@arnod.demon.co.uk> made so bold as to state:
>BTW, this discussion has evolved somewhat from its origins as a debate
>about the pros and cons of a ?-to-Z-machine compiler. I hope it's not
>being seen as a Hugo vs. Inform thread.
My fault. I apologize. It's just that I've always understood Andrew's
position to be that there should exist, basically, the Z-Machine and
nothing else. Given that, I'm a bit (too) defensive (I guess) when I
see a discussion about converting other-system-code to Z-code. In my
view, such an effort in Hugo's case can only result in either a) a
kind of legacy converter for those Hugo games that happen to fit into
the Z-code schema, or b) adherence to a de facto external standard
that will cramp Hugo's style and eventually result in the destruction
of Hugo altogether. I have no problem at all with the former, but the
latter eventuality gives me gas. On the other hand, seeing as how the
discussion evidently was just about whether other-system-stuff could
*theoretically* be made into Z-machine stuff, I shoulda kept a lid on
it.
Besides, now Andrew's said that he doesn't actually favor one format
for everything after all, which pretty much explodes my whole
world-view. It's going to take some time to recoup :)
--CardinalT
Julian Arnold
> > >On balance though I think it is far, far better for people to port
> > >individual systems to their platform than to convert system A to system
> > >B for which they already have the interpreter. Of course a universal
> > >format would be nice, but no-one has yet made a suitable proposal for
> > >such.
>
> > Personally, I'm opposed to a universal format even if it's the cat's
> > meow as a game system. Even if it's Hugo's. Call me a rebel.
>
> Well, I agree -- I'm *not* working on an anything-to-anything-else
> compiler, I'm just speculating about it. I'm working on tools to make
> porting systems easier.
OK, the two of you, why are you opposed to a universal format? This, I
think, is the crux of this whole debate. I worry that if people make a
load of ?-to-Z-code compilers Z-code will soon be perceived as such,
even though it is not qualified.
Would you just argue that variety is the spice of life, you can't please
all of the people all of the time, etc.? (Agreed.) Or do you have some
less cliched arguments?
Andrew Plotkin
Julian Arnold (jo...@arnod.demon.co.uk) wrote:
> > Well, I agree -- I'm *not* working on an anything-to-anything-else
> > compiler, I'm just speculating about it. I'm working on tools to make
> > porting systems easier.
> OK, the two of you, why are you opposed to a universal format? This, I
> think, is the crux of this whole debate.
Simple: some of the possible future directions that people have talked
about are projects written in Prolog and Scheme. Those don't fit well in
a particular virtual machine. ("Lists" demonstrates that, I hope.) It's
probably better to port the base language system (Prolog or Scheme) to
run native.
And then there's Java, which is fine as a high-end portable virtual
machine, although I don't like its interface library.
> I worry that if people make a
> load of ?-to-Z-code compilers Z-code will soon be perceived as such,
> even though it is not qualified.
There is no imminent danger of this.
I have heard one (1) rumor (not official announcement) of a TADS-to-Zcode
compiler in the works. There's also the ScottAdams-to-Inform converter;
that's been around for so long that it doesn't work very well with Inform
6. That's it.
L. Ross Raszewski
In article <ant16113...@arnod.demon.co.uk>,
Julian Arnold <jo...@arnod.demon.co.uk> wrote:
>
> In article <19980215212...@ladder02.news.aol.com>, LucFrench
> <URL:mailto:lucf...@aol.com> wrote:
>
> > People are confusing Inform with the Z-machine. The Z-machine has certain
> > features that Inform refuses to do for good reasons; most notably
windowing.
>
> Please expand. My understanding is that z5, z7, and z8 may have two
> windows, while z6 may have up to 8 with identical capabilities.
>
> Are these limitations Informy or Z-machiney?
Neither. The Inform Standard Library (parser/m verblib/m grammar linklpa
linklv english) has no high-level support for V6 internals, that is to say,
if you want to use the Z-machine's ability to do grpahics, sound, windowing,
menus, and soforth, the have to write the code in Z-machine assembly (which
inform will compile. You could write a whole game in Z-assembly, in fact, I
think thats how Curses was first written)
THe new v6lib offers high-level frontends for this sort of thing
>
> > Graphics as well, judging by the fact that a BLORB standard is even
needed.
>
> I understand that the Z-machine is not strictly limited to Infocom's
> graphics format. However, I would emphasize the problems with expansion
> I mentioned upthread.
Yep. Blorb has nothing to do with inform. Inform handles graphics just
dandy. It's the interpreters that don't. The spec doesn't specify the format
for pictures. Blorb is just an attempt to standardize some things that aren't
standardized in the Z-spec.
>
> BTW, this discussion has evolved somewhat from its origins as a debate
> about the pros and cons of a ?-to-Z-machine compiler. I hope it's not
> being seen as a Hugo vs. Inform thread.
>
>
Oh God, no
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Julian Arnold
In article <6c7o61$v2m$1...@ulowell.uml.edu>, Jason C Penney
<URL:mailto:jpe...@cs.uml.edu> wrote:
> The Blorb standard is an attempt to make all interpreters on whatever
> platform use a standard image file format, which Infocom didn't do.
> Hugo uses a bunch of JPG files (I think) and the Z-Machine will (hopefully) use
> a single Blorb file.
Well, Hugo can use a bunch of JPEGs, but for portability it sticks them
all into a single resource file (sound and music should go in here too).
Probably a Blorb file and a Hugo resource file a very similar.
Graham Nelson
In article <6cbfno$2el$1...@nnrp1.dejanews.com>, L. Ross Raszewski
<URL:mailto:rras...@hotmail.com> wrote:
> ...
> Neither. The Inform Standard Library (parser/m verblib/m grammar linklpa
> linklv english) has no high-level support for V6 internals, that is to say,
> if you want to use the Z-machine's ability to do grpahics, sound, windowing,
> menus, and soforth, the have to write the code in Z-machine assembly (which
> inform will compile. You could write a whole game in Z-assembly, in fact, I
> think thats how Curses was first written)
...not quite: Inform 1 was primitive, but it did have braced "if"
statements, simple "for" loops and that kind of thing.
> THe new v6lib offers high-level frontends for this sort of thing
Indeed.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Jeremy A.Smith (not affiliated with Rancid the Elf)
Julian Arnold <jo...@arnod.demon.co.uk> wrote in article
<ant16113...@arnod.demon.co.uk>...
> BTW, this discussion has evolved somewhat from its origins as a debate
> about the pros and cons of a ?-to-Z-machine compiler. I hope it's not
> being seen as a Hugo vs. Inform thread.
I had the idea of (when it's fully working) altering Disinformation so it
outputs TADS or HUGO source code. Then there's the possibility of porting
Z-machine games to other formats. It wouldn't be difficult to alter Dis in
this way. I could maybe write a TADS decompiler, but that wouldn't be
playing fair, quite frankly. :-)) Besides, most TADS games wouldn't fit in
my Psion Siena, and the only reason I'd write a TADS->Inform decompiler is
so I could play TADS games on the Siena (there is no TADS interpreter for
it). Ho hum.
Still, an Infocom->HUGO convertor would give HUGO a bit of a boost,
perhaps?
--
Jeremy A.Smith
* To reply by Email, change the 'z' in lwtcdz to i
Jason C Penney
Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
: In article <6cbfno$2el$1...@nnrp1.dejanews.com>, L. Ross Raszewski
: <URL:mailto:rras...@hotmail.com> wrote:
: > The Inform Standard Library (parser/m verblib/m grammar linklpa
: > linklv english) has no high-level support for V6 internals, that is to say,
: > if you want to use the Z-machine's ability to do grpahics, sound, windowing,
: > menus, and soforth, the have to write the code in Z-machine assembly
: > THe new v6lib offers high-level frontends for this sort of thing
: Indeed.
Whoo hoo!!! Thanks for the free plugs...
For more info on V6Lib see
<http://www.chelmsford.com/home/jpenney/V6Lib/>
Philip Bartol
In article <01bd3bd6$72bd7160$LocalHost@default>, "Jeremy A.Smith (not affiliated with Rancid the Elf)" <jeremy...@lwtcdz.prestel.co.uk> wrote:
>this way. I could maybe write a TADS decompiler, but that wouldn't be
>playing fair, quite frankly. :-)) Besides, most TADS games wouldn't fit in
>my Psion Siena, and the only reason I'd write a TADS->Inform decompiler is
>so I could play TADS games on the Siena (there is no TADS interpreter for
>it). Ho hum.
Or for those of us who would just as soon not have a TADS interpreter taking
up space on my machine.... I'd just as soon distribute *.z? files to people
and only have them use one program on them.
But then again I'm a bit wierd and tend to not take change very easily.
PHIL