[z-machine] Z-Spec 1.1 issues

[Michael S. Greger]

Hi,

 

This is my first post.  I'm currently writing a z-machine interpreter.
In trying to comply with the z-machine spec I've noticed a few issues:

The 1.1 spec says this with regard to output streams:

 

Output streams

--------------

Section 7.1.2 is incorrect - output streams 3 and 4 are present only in

Version 5 and later.

 

I've dumped almost all the Infocom games and noticed that several V4
games make use of both these streams (e.g. A Mind Forever Voyaging
77.850814). Is the spec incorrect or was there a deliberate choice to
exclude these features from V4?

Secondly, the 1.1 spec has this to say about encoded text:

 

Encoded text

------------

In Version 3 and later, many of Infocom's interpreters (and some
subsequent

interpreters, such as ITF's) treat two consecutive Z-characters 4 or 5
as

shift locks, contrary to the Standard. As a result, story files should
not

use multiple consecutive 4 or 5 codes except for padding at the end of

strings and dictionary words. In any case, these shift locks are not
used in

dictionary words, or any of Infocom's story files.

 

Two extra rules apply to encoding text for dictionary words in Versions
1 and

2 only (see 3.7). If the truncation to 6 Z-characters leaves a multi-

Z-character construction incomplete, the end-bit of the last word is not
set.

Also, shift-lock Z-characters 4 and 5 are used instead of the
single-shift

Z-characters 2 and 3 when the next two characters come from the same

alphabet. These two rules affect the dictionary of Zork I, which
contains

"nasty-" (looking), "storm-" (tossed) and "pdp10". Arguably, the first
rule

could be a bug, but the 3 extant V1 and V2 files are consistent. The
games

are still winnable without access to those dictionary words.

 

I discovered while implementing this that despite keeping the final bit
unset, the word storm- is not accessible. Upon looking at the dictionary
for Zork I (2.AS000C) I discovered the entry for that word is not in the
correct order (the entry before it has a higher numerical value) making
a binary search fail to locate the entry. Should this be considered a
bug and the word remain inaccessible from any standard interpreter, or
should we forego the performance benefits of binary search lookups and
always search the dictionary in a linear fashion? I'm curious what
opinions people have on this. Additionally I'd like to know what
Infocom's original interpreter did if anyone out there still has this
version.

I have two issues regarding reading input: 1) Reads that are called
during a timeout interrupt of another read. Should the spec mention
this? One Infocom game does this (BorderZone). BorderZone never returns
to the original read (always restarting, restoring, etc.) but both my
interpreter and frotz preserve the original read and can return to it
upon completion of the 'inner' read. Anyone have any opinions here?  2)
What should happen if stream 3 is active when a read or readchar is
called?

 

Finally, I noticed that there is no mention in the spec of when the
store location of a routine is read. I'd like to suggest that it be read
after the routine has completed. This makes implementing save/restore
simpler, and removes the need to store this information in the save file
(making section 4.3.3 of Quetzal unnecessary). It seems several popular
interpreters, but not all, already behave this way. I'm not sure if
anyone would write routines that change their store location during
execution, but I don't see any reason to exclude it from the realm of
the possible, and it does have the benefits mentioned above.

Thanks to vaporware from ifmud who wrote several inform test programs to
test the input issues and the routine/store issue.

 

Any opinions or discussion is welcome.

 

Thanks,

MikeG

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.feelies.org/pipermail/z-machine/attachments/20061117/4ce6cdbd/attachment.html