[z-machine] output stream 2, input stream 1

[Thomas Thurman]

On Thu, Nov 20, 2003 at 07:04:07AM -0800, Amir Karger wrote:
> I was apparently on drugs when I said this. No, I take it back. In
> Section 15, the read_char opcode description says "Reads a single
> character from input stream 0 (the keyboard). The first operand must be
> 1 (presumably it was provided to support multiple input devices, but
> only the keyboard was ever used)."  This pretty strongly implies that
> file input is NOT allowed.
> 
> OTOH, 10.6 says "In Versions 4 and later, individual characters can be
> read from the current input stream, using read_char", which clearly
> means it's allowed to be an input from stream 1.

It's useful to be able to read keypresses from the current input stream,
for testing, and removing the ability doesn't seem to do any good.

> Aha! This wasn't working for me because I didn't put the characters on
> their own line. And I see that Dzip instead uses "<oct of ZSCII>\n" and
> nitfol says "[ZSCII VALUE]\n". I don't suppose anyone has worked up a
> standard for this since these games were released? Well, a Perl
> one-liner could always convert command scripts from the different
> languages (assuming [123] wasn't entered to a 'read' opcode!)
> 
> I think I'll go with the "[ZSCII VALUE]\n" mentioned in the Spec's
> remarks, which makes it at least quasi-standard.

FWIW, I did some tests on Frotz's behaviour in this matter while I
was specifying this for Gnusto:
   <http://www.livejournal.com/community/gnusto/11326.html>

This is what I found out:
 
: We need to support these. The format isn't specified, though an informal
: suggestion is given. Frotz appears to behave roughly according to this
: suggestion, so I think working roughly the same way as Frotz would be
: useful. I've run some black-box experiments on Frotz's behaviour, and
: I believe the rules to be:
: 
: 1. Each line in the file represents an input event, either an @read or
: an @read_char. 2. Any character may be represented by its decimal ZSCII
: code within square brackets. In practice, this is done always and only
: for:
: 
: 2a. printing characters which don't have a simple ASCII representation
: (e.g. "toup[170]e").
: 2b. characters which represent keypresses, e.g. [133] for F1. These are
: ONLY stored if they're pressed during an @read_char, never during an
: @read.
: 2c. ASCII character 91, open square bracket (to resolve the obvious
: ambiguity).
: 
: 3. A clarification to 2: If the enter key is pressed while waiting
: for an @read_char, we store an empty line, not [13] as you might
: expect.
: 
: 4. Preloaded input is treated like any other input.
: 
: 5. If an input is interrupted by timeout, the string so far is stored
: followed by a question mark. No attempt is made to disambiguate this
: from a string which happens to end with a question mark anyway. This
: seems to be the weakest part of the design.
: 
: 6. I've tested only recording, not playback. This all maps fairly
: trivially to playback, except the question of what happens if more
: than one character is present in a line received when we've reached
: an @read_char. I'm assuming we simply take the first character.
: 
: 7. Out-of-band responses such as names of savefiles aren't stored.

I then went on to make a list of suggested modifications, some of which
were specific to Gnusto and some of which were obsoleted in our design by
the time they came to be implemented.

T