[z-machine] Z-Spec 1.1 issues

Sat Nov 18 14:49:13 GMT 2006

I did a little more checking into the issue with V1-2 encoded text. I
have a feeling the first rule: If the truncation to 6 Z-characters
leaves a multi-

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

is indeed a bug and should not be included in the spec. In addition to
the problem with the dictionary order I mentioned in my last post, I've
discovered that typing 'get storm-' or 'get nasty-' while those things
are not present in the player's location results in a string of garbage
following the respective word. This is due directly to the fact that the
high bit is not set on the dictionary word causing the string processing
only to terminate when a random word has high enough value to kill it
(usually taking place somewhere in the next dictionary entry). This
shows that each dictionary entry was meant to be a self-contained string
and as such should follow the rules of terminating with a set high bit.
Both facts together, the incorrect order of the entry 'storm-' and the
incorrect string reading I feel is fairly strong evidence that the
failure to set the high bit was an error. At any rate, including this
rule demands the other issues be clarified. The dictionary order issue
can be solved with a simple rule that when the z-machine version is less
than 3, the dictionary is always sorted in a linear fashion; however the
string printing problem has no solution that I can see.

MikeG

________________________________

From: z-machine-bounces at feelies.org
[mailto:z-machine-bounces at feelies.org] On Behalf Of Michael S. Greger
Sent: Friday, November 17, 2006 3:49 PM
To: z-machine at feelies.org
Subject: [z-machine] Z-Spec 1.1 issues

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/20061118/9f735919/attachment-0001.htm 