Z-machine standard: unclear aspects/ambiguities

[Player701]

@cas

However, the Zoom interpreter has made use of EXT:128-131. I’ll quote its README below, but in short, EXT:130 is a store, and the rest are no store/branch. You probably won’t ever run into them unless you use the zmark benchmark program included with Zoom, but at least these have been in existence for some time, so probably worth handling EXT:130. Although, even the zmark program doesn’t use EXT:130!

Thanks, I will keep those in mind.

@zarf

The rationale is that a save here would have to contain extra information: the buffer position and length the current @read is reading into. There’s no place in the save file to put that info. So it can’t be done.

restore/restart/quit in the interrupt routine doesn’t have these problems. (The interpreter just has to forget where the current @read is reading into!) So there’s no reason for the spec to forbid these cases. However, I bet nobody’s ever tested them either. If an interpreter supports them, it’s very much going the extra mile.

Yeah, it is pretty much obvious why saving in this case is explicitly forbidden, but other actions such as restore might also need special handling if invoked while reading user input, depending on the implementation. That’s why I had to clarify this. Technically, it wouldn’t be very difficult to support them, but it would complicate the architecture a bit in my case. I would like to ensure that everything that is theoretically legal is properly implemented, although it might be hard to test corner cases in practice.

@zarf

Where’s that from?

Here are a couple examples. All dictionary words are numbered from 0 upwards.

1. sampler1_R55.z3 (from Appendix C) - word #433 (“multi”), unique;
2. zork1-r15-sUG3AU5.z2 (from eblong dot com) - word #347 (“nasty”), a duplicate of word #348; word #514 (“storm”), unique;

There is also a zork1.dat I got from somewhere I can’t actually remember (basically, by random googling) when setting up the project so that I could have something to run initial tests on (I missed the links in Appendix C at first for some unknown reason, and the site I got the 2nd file from I did not discover until much later). The file length in the header (multiplied by 2, for it is a V3 file) is 84876 bytes, and the checksum is 41257 (hex $A129). Actual file length is 92160 bytes. There are unique words #200 “fcd#” and #437 “pdp1” in the dictionary that both do not have the highest bit set in the last 2-byte word.

I first thought it was a bug somewhere in my code, and I cannot rule it out with absolute certainty even now, but it seems strange that the dictionary reader reacts to these particular words specifically, so I have to assume something is indeed wrong with the data. My suspicions are additionally corroborated by the fact that in the last case the problematic words in question are rather unusual: perhaps some kind of debugging commands or similar.