[z-machine] The Z-machine and Informs 6 and 7

[Graham Nelson]

I'm cross-posting my answer to Sam's question, as I think
it has relevance to both the Z-machine and Inform. Sam
raised again an issue we'd vaguely talked about before, to
do with trickery to give the Z-machine memory map some
additional byte-accessible addresses.

The current status of the three projects in question is that
the Z-machine has just adopted Z-spec 1.1, as a long-awaited
(but sensibly cautious) clarification of 1.0 with very minor
changes - a good and useful piece of work, if I can editorialise
a little. Inform 6.31 is undergoing maintenance, and we're
looking around to see what it needs before it can be released:
testing, seems to be the answer. Inform 7 is about to have its
third semi-public beta (anyone receiving this is welcome to
take part), and is now I think powerful enough to make quite
releasable games.

On 19 Oct 2005, at 12:52, samwyse wrote:
> At the
> time, Graham said that I7 would use a lot of dynamic tables, but has
> anyone verified that fact?

It does use quite a lot of arrays, but in practice we seem not to be
bumping into limits as much as I'd expected. That may be because
we have a propensity to make uber-cool medium sized games
rather than more plausible large-game designs, though. So at
present I don't feel too bad about that, but it may be an issue
again. I'm inherently skittish about making a .z9 design which
nobody implements, and losing Z's greatest strength - its
ubiquity.

That said, I currently have three preoccupations about Inform and
the Z-machine:

(a) I would like better and more transparent Unicode support.
Ideally, I6 should read a UTF-8 input file and write a story file
which an interpreter with one of the "big" fonts would simply get
right. I've largely forgotten the issues involved, but I have a feeling
that it isn't completely trivial, and there are awkward dictionary
issues involved. I just feel that any 21st-century Z-machine ought
to understand Unicode. This might need careful thought.

(b) It is time, in my view, to make Blorb more or less compulsory.
Blorb has long hovered on the margins of the Z-spec, as a
good idea but one that never seemed urgent because there
weren't really any blorbs to be executed, and anyway, all the
interpreter writers had disappeared off into the misty woods.

For reasons to do with metadata, but also to do with looking
ahead to future possible features of I7, I want to make the
default file format created by I7 a blorb file containing a .z5
executable as its story file chunk. At present, I7 supports z5,
z6, z8 and glulx: or at least, it works by generating code for I6
which can go to any of those. Thus, I7 takes whatever
story file is made and blorbs it up with a metadata file included.
In future, it might also blorb in pictures and sounds, and
perhaps even cover artwork: who knows?

I would feel happier about this plan if more interpreters could
already read a blorb file and execute the story file inside,
especially in the Windows world. But it's a chicken and egg
thing. I propose to use the introduction of I7 to increase the
blorb population, so that there's more incentive to read blorbs:
but in the mean time, perhaps any interpreter-writers reading
this might like to think about what would be involved. I think
blorb is good news for interpreters too: good clear metadata
certainly is.

A rudimentary port of "perlBlorb" to C now exists, and we have
slightly extended the blorb format to allow a new chunk -
IFmd, for metadata. Ultimately, I suspect it would be good for
Inform 6 people also to have hot and cold running blorb;
cblorb (as it is currently called) is clearly a distinct command-line
tool, but maybe something could be rigged up whereby it will
compile either independently or (from the same source, but
with #defines, say) as a part of I6.31?  That would allow
I6 to be able to produce blorbs without mess or fuss.

If people think this a possibility, then I'll hand over the current
(really very messy and partial, but working) state of cblorb.c
to whoever would like to volunteer to look after it. It's only a
little tool, but it probably ought to go into the Inform 6 CVS.
Tidying it up would mean a couple of evenings of hacking,
but not a lot more than that, I think. It's a minimal tool that
reads a blurb file, just like perlBlorb used to be.

(c) The stack is annoyingly inaccessible in the Z-machine.
The reason I7 still doesn't have long integers or floating-point
(or lists, or proper string variables - though other issues also
make trouble there) is that one can't store local copies of
arrays on the stack without all kinds of horror.

I'm not sure I see this as being something remotely easy to
do anything about - ultimately, we just have to go to glulx,
I guess - but it's the most significant area where the limitations
of Z have imposed limitations on I7.

> Inform doesn't support any of the really nasty
> things that can potentially be done with/to properties and I'm not
> aware of any programs that do so.

I7 certainly doesn't actually rewrite property tables on the fly,
but (like lots of I6 code) it does access property addresses
and write to them as arrays at some indeterminate period
later.

--
Graham Nelson