From ???@??? Tue Jun 03 16:12:23 1997
Message-Id: <199706022337.TAA04716@cow.chelmsford.com>
Comments: Authenticated sender is <jpenney@mail.chelmsford.com>
From: "Jason C Penney" <jpenney@cow.chelmsford.com>
To: z-machine@gmd.de
Date: Mon, 2 Jun 1997 19:43:04 +0000
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Formatted text and simle graphic
Reply-To: jpenney@chelmsford.com
X-Confirm-Reading-To: jpenney@chelmsford.com
X-Pmrqc: 1
Priority: normal
References: <199706022040.WAA08523@dns.speednet.it>
In-Reply-To: <Pine.SOL.3.93.970602181814.1027A-100000@ultra27.cs.lafayette.edu>
X-Mailer: Pegasus Mail for Win32 (v2.52)
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: 311d47c381fdd6a36dc1290e369bb414

> I agree that graphics should be included in the Z-Machine for the
> purposes you have named.  I, however, do not feel an extension is needed.
>  It seems to me that the existing z6 format is sufficient although new
> releases of inform should make it easier to use this format.  The other
> problem is the lack of interpreters that support it.
> 
[snip]

>      -Jesse Burneko-
>      burnekoj@cs.lafayette.edu
>      www.cs.lafayette.edu/~burnekoj


	Well, now is as good a time as any to mention that I have been working on 
a class library to make v6 features easy to use.  It has support for 
pictures, windows, and the beginnings of a way to make different areas of 
a game have different screen layouts in a simple way.  It's about 70% 
complete, but it has only been tested in Frotz.  I've made a small test 
game that uses the graphics from Zork 0 for the status line and compass 
rose.

	Unfortunately, I just started a new job today that will take up a bit of 
time, but once I settle in I hope to finish the library up.  I'll let 
everyone know.  I would like to know if anyone else thinks that this would 
be useful though.

Later,
Jay




/*-----------------------------------*--------------------------------*\
|JasonCPenney(jpenney@chelmsford.com)| http://www.cs.uml.edu/~jpenney/ |
| Xarton Dragon    --==<UDIC>==--    | (UFO 54-40, Wipers, Int-Fiction)|
*------------------------------------*---------------------------------*
|    "The trouble with computers of course, is that they're very       |
|                sophisticated idiots." -- The Doctor                  |
\*--------------------------------------------------------------------*/


From ???@??? Tue Jun 03 16:12:22 1997
Message-Id: <199706022040.WAA08523@dns.speednet.it>
X-Mailer: Microsoft Outlook Express 4.71.0544.0
From: "Giovanni Riccardi" <g.riccardi@speednet.it>
To: "z-machine mailing list" <z-machine@gmd.de>
Subject: [z-machine] Formatted text and simle graphic
Date: Mon, 2 Jun 1997 22:46:48 +0200
X-Priority: 3
X-Msmail-Priority: Normal
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: dc6cff78a82add119eb91a6ef31ab499

Lots of discussions there were during the years on the use of graphic
in text adventures. I think text adventures as interactive novels (so,
similar to books) just as I think graphic adventures as interactive 
movies. But imagine some books without images or formatted text (J.R.R.
Tolkien's "Lord of the Rings" without the map of Middle Earth or runes 
and tengwars!!!!)

I think we should do something to implement these features in the 
Z-Machine.

I imagine an HTML-like extension to Inform just like this:


  .Object At_End_Of_Road "<B>At End Of Road</B>"
.         with description 
		.                "<P>You are standing at the end of a road before a small

                .                brick building.</P> <P>Around you is a
forest. A small 
               .                stream flows out of the building and down a
gully.</P>",

where B stand for Boldface and P for paragraph.

Here is a list of some typesetting instructions that could be useful to
add:

<FONT="xyz"> 	- Use the font "xyz"
<B>		- Bold
<I>		- Italic
<U>		- Underlined text
<SIZE>		- Font size
<P>		- Paragraph


Inform should produce a specific z-code for those interpreters that 
support all of this (a new z-machine format or simply an extensions
of the old .z5 and .z8 formats).
Other istructions to include simple graphics (not too colors!! only 
for maps and this kind of things) could be implemented after the type
typesetting extension..

I hope to post as soon as possible a formal proposal.

Bye, Giovanni
 
-----------------------
  Giovanni Riccardi
g.riccardi@speednet.it
  Terracina  Italy  
-----------------------




From ???@??? Tue Jun 03 16:12:25 1997
Date: Mon, 2 Jun 1997 18:23:57 -0400 (EDT)
From: Jesse Burneko <burnekoj@ultra27.cs.lafayette.edu>
To: z-machine@gmd.de
Cc: z-machine mailing list <z-machine@gmd.de>
Subject: Re: [z-machine] Formatted text and simle graphic
In-Reply-To: <199706022040.WAA08523@dns.speednet.it>
Message-Id: <Pine.SOL.3.93.970602181814.1027A-100000@ultra27.cs.lafayette.edu>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: a1f1e0725b68e1df3fe6548b14ea4ac0

> Lots of discussions there were during the years on the use of graphic
> in text adventures. I think text adventures as interactive novels (so,
> similar to books) just as I think graphic adventures as interactive 
> movies. But imagine some books without images or formatted text (J.R.R.
> Tolkien's "Lord of the Rings" without the map of Middle Earth or runes 
> and tengwars!!!!)

I agree that graphics should be included in the Z-Machine for the purposes
you have named.  I, however, do not feel an extension is needed.  It seems
to me that the existing z6 format is sufficient although new releases of
inform should make it easier to use this format.  The other problem is the
lack of interpreters that support it.

The other thing I think one needs is a better understanding of graphics
format used by Infocom and perhaps a converter utility that will take
popular graphics formats and covert them to the one used by Infocom.  Sort
of a reverse of the existing pix2gif program.

					-Jesse Burneko-
					burnekoj@cs.lafayette.edu
					www.cs.lafayette.edu/~burnekoj


From ???@??? Sat Jun 07 15:17:10 1997
Message-Id: <3.0.32.19970603162115.0069b890@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 03 Jun 1997 18:24:51 +1200
To: z-machine@gmd.de
From: Gavin Lambert <uecasm@geocities.com>
Subject: [z-machine] Memory Space (and access thereof)
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"
X-UIDL: 548e096e840fe372da4eab45982c82b7


I was wondering what parts of the Z-Machine's memory should be
program-accessible.  I'm currently working on writing an interpreter, and
for speed and accessibility reasons I would like to shift as much as
possible (particularly object and property lists) into the interpreter's
own memory.  This means that the Z-code being executed would not be able to
modify these, or read changed values (although the initial values would
still be present).

Are there any reasons why I shouldn't do this with objects & properties?
Are there any more things which can be stored separately?

-----                                
     _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
    _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
   _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
  _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/

Gavin Lambert
uecasm@geocities.com
http://crash.ihug.co.nz/~brianc
http://www.geocities.com/SiliconValley/Heights/1987

"We now return to our regularly scheduled flame-throwing."
"PCMCIA:  People Can't Memorise Computer Industry Acronyms."
"ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."


From ???@??? Sat Jun 07 15:17:16 1997
Date: Tue, 3 Jun 1997 09:28:56 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706031328.JAA13637@wanda.vf.pond.com>
To: z-machine@gmd.de
Subject: Re:  [z-machine] Memory Space (and access thereof)
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 8f31a3652a943a1f1a2e71bc4a8b152d

} I was wondering what parts of the Z-Machine's memory should be
} program-accessible.

All of dynamic memory (including object and property lists) must be
accessible for reading and writing, and everything below high memory
must be accessible for reading.  Dynamic memory includes object and
property lists. 

From ???@??? Sat Jun 07 15:17:18 1997
From: Miron Schmidt <s590501@tfh-berlin.de>
Reply-To: miron@comports.com
To: z-machine@gmd.de
Date: Tue, 03 Jun 1997 16:17:23 +0100
Message-Id: <yam7093.1170.1205257776@mailhost.tfh-berlin.de>
In-Reply-To: <199706022040.WAA08523@dns.speednet.it>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Organization: TFH-Berlin via PPP
Subject: Re: [z-machine] Formatted text and simle graphic
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: 76bdf9996a8841370860b88de97be721

Giovanni Riccardi <g.riccardi@speednet.it> wrote:
> But imagine some books without images or formatted text (J.R.R.
> Tolkien's "Lord of the Rings" without the map of Middle Earth or runes 
> and tengwars!!!!)

With Inform 6.12 and above, it is possible to output Tengwar runes through
Unicode characters.
Currently, though, no interpreter supports Unicode; and a Tengwar font that
is usable by the interpreter would still be needed.

> I imagine an HTML-like extension to Inform just like this:
> Here is a list of some typesetting instructions that could be useful to
> add:
> <FONT="xyz"> - Use the font "xyz"
> <B>- Bold
> <I>- Italic
> <U>- Underlined text
> <SIZE>- Font size
> <P>- Paragraph

I'm not sure what you're getting at here. Inform _does_ support all text
styles you're mentioning there, and the format needed to invoke them is only
slightly less readable than HTML-like tags.

> Inform should produce a specific z-code for those interpreters that 
> support all of this (a new z-machine format or simply an extensions
> of the old .z5 and .z8 formats).

All the interpreters that I know of support text styles. As the Specification
mentions, the interpreter is free to choose different styles as long as
they're unique: Frotz PC, for example, uses white and yellow text to display
bold and underlined style.

> Other istructions to include simple graphics (not too colors!! only 
> for maps and this kind of things) could be implemented after the type
> typesetting extension..

Suitable characters for maps and the like are provided in font 3, which is
built-in in most modern interpreters.
More advanced graphics are "easily" introduced with corresponding Z6
intructions.

As Jesse Burneko pointed out in an earlier reply, it seems that there's no
need for an extension of the Z-Machine.
There _is_ need, however, for a comprehensive library of Z6 functions.

-- 
Miron Schmidt <miron@comports.com>

           "So, if _Space Aliens_ is Infocom on acid, what's this?"
                       -- C.E. Forman, _Detective: An Interactive MiSTing_



From ???@??? Sat Jun 07 15:17:34 1997
Date: Wed, 04 Jun 1997 17:17:16 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Memory Space (and access thereof)
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <3.0.32.19970603162115.0069b890@pop.ihug.co.nz>
Message-Id: <Marcel-1.09-0604161716-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: 349a49aa0809624082d2f4af169912ec

On Tue 03 Jun, Gavin Lambert wrote:
> 
> I was wondering what parts of the Z-Machine's memory should be
> program-accessible.  I'm currently working on writing an interpreter, and
> for speed and accessibility reasons I would like to shift as much as
> possible (particularly object and property lists) into the interpreter's
> own memory.  This means that the Z-code being executed would not be able to
> modify these, or read changed values (although the initial values would
> still be present).
> 
> Are there any reasons why I shouldn't do this with objects & properties?
> Are there any more things which can be stored separately?

Although few existing games tamper with these structures directly,
the possibility exists and for several quite unlikely tables in
dynamic memory it is taken up -- the table of abbreviations, for
instance, is modified at run time by numerous Inform games.  Inform 6
does some quite crafty things when reading property tables and
memory immediately after them, too.

I'm afraid I don't think your proposal is safe!  By all means cache,
but make it a read/write cache, not write-once-only.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Jun 07 15:17:27 1997
Date: Wed, 04 Jun 1997 17:33:39 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Modern V6 picture format, anyone?
To: Z-Machine Mailing List <z-machine@gmd.de>, miron@comports.com
In-Reply-To: <yam7093.1170.1205257776@mailhost.tfh-berlin.de>
Message-Id: <Marcel-1.09-0604163339-345M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: 6ca486e4898332cd0df70e6a696934ea

On Tue 03 Jun, Miron Schmidt wrote:
>
> As Jesse Burneko pointed out in an earlier reply, it seems that there's no
> need for an extension of the Z-Machine.
> There _is_ need, however, for a comprehensive library of Z6 functions.

I think there's something to this -- would anyone like to write
such a header file, to act (e.g.) as an extension to the normal Inform
library?

I personally feel that the biggest obstruction to releasing new
Z6 games is that the picture file formats are obscure and clumsy,
belonging to the dark (or at least less coloured) ages.  Now the
Standard is careful not to specify these formats, and existing
interpreters, of course, are concerned mainly to get the four
Infocom sort-of-classics running.

If anyone in the future is to get anywhere with V6, I would suggest
that it might be helpful to agree a simpler format for new games.
Rather than re-invent the wheel, and since almost every
graphics-capable machine can display JPEGs, perhaps we could try
this: the "graphics file" for a V6 game could be a zipped
directory containing pictures named 

   p1.jpg
   p2.jpg
   ...

such that p1 is the picture numbered 1 to the Z-machine, and so on.
(I suggest keeping the extensions in case anyone wants to use GIFs
instead, and for clarity.)

This would be pretty simple to put together and an interpreter could
also have an option of just reading from a directory on the host
machine rather than a zipped file, to aid development.

I can easily imagine that even authors not intending to write
properly graphical works would quite like the ability to have the
odd illustration -- a title page, a map and so on.  Introducing
JPEGs would immediately make photographic quality images available.

Opinions, anyone?  Do I underestimate the level of difficulty
involved for interpreter-writers?  I think it would only mean
needing access to some operating-system primitive like "plot a JPEG
at these coordinates", but perhaps on some machines this is not
so primitive an act.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Jun 07 15:17:42 1997
Message-Id: <199706042301.TAA07307@cow.chelmsford.com>
Comments: Authenticated sender is <jpenney@mail.chelmsford.com>
From: "Jason C Penney" <jpenney@cow.chelmsford.com>
To: z-machine@gmd.de
Date: Wed, 4 Jun 1997 19:07:33 +0000
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Reply-To: jpenney@chelmsford.com
Priority: normal
References: <yam7093.1170.1205257776@mailhost.tfh-berlin.de>
In-Reply-To: <Marcel-1.09-0604163339-345M+4%@gnelson.demon.co.uk>
X-Mailer: Pegasus Mail for Win32 (v2.52)
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: 4b06b6de8280d3dc69e5e1b91eacd1c2

On Tue 03 Jun, Miron Schmidt wrote:
>
> As Jesse Burneko pointed out in an earlier reply, it seems that there's
> no need for an extension of the Z-Machine. There _is_ need, however,
> for a comprehensive library of Z6 functions.

On Wed, 04 Jun 1997,  Graham Nelson wrote
> 
> I think there's something to this -- would anyone like to write
> such a header file, to act (e.g.) as an extension to the normal Inform
> library?

	I have been working on just such a beast.  I've been planning to do it 
for quite some time, and I hope to finish it up in by the end of the 
summer.  I'm hoping to release a z6 version of Advent as an example game.  
It would be great if there was an easy for one to make ones own graphics. 
I've been using the ones from Zork 0 in my testing.

	Are many people on the list interested in this?

Jay

/*-----------------------------------*--------------------------------*\
|JasonCPenney(jpenney@chelmsford.com)| http://www.cs.uml.edu/~jpenney/ |
| Xarton Dragon    --==<UDIC>==--    | (UFO 54-40, Wipers, Int-Fiction)|
*------------------------------------*---------------------------------*
|    "The trouble with computers of course, is that they're very       |
|                sophisticated idiots." -- The Doctor                  |
\*--------------------------------------------------------------------*/


From ???@??? Sat Jun 07 15:17:39 1997
Date: Wed, 4 Jun 1997 13:08:08 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <Marcel-1.09-0604163339-345M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.970604125600.26185A-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: db86caa37d636001d3aafcf4bbf82547

On Wed, 4 Jun 1997, Graham Nelson wrote:

> If anyone in the future is to get anywhere with V6, I would suggest
> that it might be helpful to agree a simpler format for new games.
> Rather than re-invent the wheel, and since almost every
> graphics-capable machine can display JPEGs, perhaps we could try
> this: the "graphics file" for a V6 game could be a zipped
> directory containing pictures named 
> 
>    p1.jpg
>    p2.jpg
>    ...
> 
> such that p1 is the picture numbered 1 to the Z-machine, and so on.
> (I suggest keeping the extensions in case anyone wants to use GIFs
> instead, and for clarity.)

Long ago I proposed PICKLE to fulfil this purpose. It's been roundly
ignored, and I don't feel strongly enough to argue for it. Another
proposal was the chunk format (IFF?) which is used for the
recently-discussed universal save file format. That may be better simply
because the interpreter can use the same code for save files and graphics
files. 

I would argue that either of those is better than a zipped directory. Both
PICKLE and IFF store each chunk (picture) as a continguous segment of raw
data in the file. That's easy for interpreters to pull out and use. A
zipped directory has some painful format that I don't want to deal with,
on top of the JPEG format.

(And both JPEG and GIF are already compressed formats, so zipping them
won't save much space anyway.)

> This would be pretty simple to put together and an interpreter could
> also have an option of just reading from a directory on the host
> machine rather than a zipped file, to aid development.

This is a useful option in any case.
 
> Opinions, anyone?  Do I underestimate the level of difficulty
> involved for interpreter-writers?

It's nothing compared to the difficulty of supporting V6 in the first
place. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 07 15:17:44 1997
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
Message-Id: <199706042343.JAA27096@yallara.cs.rmit.edu.au>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
To: z-machine@gmd.de
Date: Thu, 5 Jun 1997 09:43:58 +1000 (EST)
In-Reply-To: <Marcel-1.09-0604163339-345M+4%@gnelson.demon.co.uk> from "Graham Nelson" at Jun 4, 97 05:33:39 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: 2e40899a137f9fdd596ff0768335e516

> 
> On Tue 03 Jun, Miron Schmidt wrote:
> >
> > As Jesse Burneko pointed out in an earlier reply, it seems that there's no
> > need for an extension of the Z-Machine.
> > There _is_ need, however, for a comprehensive library of Z6 functions.
> 
> I think there's something to this -- would anyone like to write
> such a header file, to act (e.g.) as an extension to the normal Inform
> library?
> 
> I personally feel that the biggest obstruction to releasing new
> Z6 games is that the picture file formats are obscure and clumsy,
> belonging to the dark (or at least less coloured) ages.  Now the
> Standard is careful not to specify these formats, and existing
> interpreters, of course, are concerned mainly to get the four
> Infocom sort-of-classics running.
> 
> If anyone in the future is to get anywhere with V6, I would suggest
> that it might be helpful to agree a simpler format for new games.
> Rather than re-invent the wheel, and since almost every
> graphics-capable machine can display JPEGs, perhaps we could try
> this: the "graphics file" for a V6 game could be a zipped
> directory containing pictures named 
> 
>    p1.jpg
>    p2.jpg
>    ...

Remember that jpegs are a compressed format, and are really intended for
photographic images (although there may be newer revisions out that cater
for non-photographic comrpression). The only benefit of jpeg therefore is
the standard format.

I'd argue that the compressed nature of jpegs in any case complicates the
process for displaying pictures. Considering that the ideal of Inform is to
make games to run on as many systems as possible, will decompressing a jpeg
image be an unacceptable time period. Reasonable size jpegs still take several
seconds to uncompress on my PC Pentium Pro 200, although that's for full
sized 640x480 sized pictures. Some timings for different sized pictures/colour
resolution would be usefull.

Also a point to raise is colour density. The existing Infocom games have a
different chunk file for MCGA graphics, EGA, etc. Is it the proposal that JPEG
would contain just the one set of images. ie. if the JPEG picturies all 256
colour, are interpreters running on machines with less than 256 colours meant
to dither the palette down? Or are we meant to have several groups of JPEG
files for several different colour densities.

> 
> such that p1 is the picture numbered 1 to the Z-machine, and so on.
> (I suggest keeping the extensions in case anyone wants to use GIFs
> instead, and for clarity.)
> 
> This would be pretty simple to put together and an interpreter could
> also have an option of just reading from a directory on the host
> machine rather than a zipped file, to aid development.

I'd also argue against a ZIP file. Considering there will already be a time
lag for just uncompressing a jpeg file, compressing the image wouldn't save
any space and just increase the time lag. I know that GIFs can hold multiple
images in one file (which makes the basis for animated gifs), but can jpeg
handle this? If it could, or we use a format that does, we could put all the
pictures for one game in one file.

On the side, as well, one of the original intents of Infocom was to encode the
text so casual users couldn't see the text. Are we really sure we want to use
such a widely known format that the casual user can just boot up his/her
favorite graphic viewer and then view all the pictures for the game, and 
possibly even, well, steal them? Just something to consider.

> 
> I can easily imagine that even authors not intending to write
> properly graphical works would quite like the ability to have the
> odd illustration -- a title page, a map and so on.  Introducing
> JPEGs would immediately make photographic quality images available.
> 
> Opinions, anyone?  Do I underestimate the level of difficulty
> involved for interpreter-writers?  I think it would only mean
> needing access to some operating-system primitive like "plot a JPEG
> at these coordinates", but perhaps on some machines this is not
> so primitive an act.
> 
> -- 
> Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom
> 
> 

Well, that's my $0.02, anyway. There's problems to consider of 1) speed of
decompression of jpegs on lower end machines, 2) what colour density are
we talking about; can it be dithered (and will this increase largely the
display latency), or will several sets need to be provided, and 3) are we
sure we want to use such a common format which is so open to inspection.

-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Sat Jun 07 15:17:47 1997
X-Sender: mattack@mail.apple.com
Message-Id: <v01550109afbbafcb8264@[17.202.20.138]>
Mime-Version: 1.0
Date: Wed, 4 Jun 1997 16:53:42 -0700
To: z-machine@gmd.de
From: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"
X-UIDL: 3879f1ab70c74b5048321ebca54ebdb0

>I'd argue that the compressed nature of jpegs in any case complicates the
>process for displaying pictures. Considering that the ideal of Inform is to
>make games to run on as many systems as possible, will decompressing a jpeg
>image be an unacceptable time period. Reasonable size jpegs still take several

Yes, absolutely unacceptable.  GIF would be *almost* acceptable (for only
my personal situation) in a game with very very very few pictures.

I'd vote for just using whatever the real v6 games use.  I'm admittedly
still not sure about this -- is there a "generic" format, or do each of the
v6 games that *infocom* released have system-specific data?  If they do,
scarily, it would probably be good to support them all.

If there is a generic format, using that generic format still would be
good, as it presumably is easy to compress

>Also a point to raise is colour density. The existing Infocom games have a
>different chunk file for MCGA graphics, EGA, etc. Is it the proposal that JPEG

This presumably answers my question above??? each system has system
specific data??

--
mattack@apple.com



From ???@??? Sat Jun 07 15:18:01 1997
Date: Wed, 4 Jun 1997 17:13:17 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <199706042343.JAA27096@yallara.cs.rmit.edu.au>
Message-Id: <Pine.BSI.3.95.970604165305.26606A-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: d7af06fd257b73526db9b36c51c8427b

On Thu, 5 Jun 1997, Paul Francis Gilbert wrote:

> Remember that jpegs are a compressed format, and are really intended for
> photographic images (although there may be newer revisions out that cater

I see no reason why photographic quality images wouldn't be used, as a matter of
fact, if I were to relese a Z6 game, it *would* be photo quality.

> for non-photographic comrpression). The only benefit of jpeg therefore is
> the standard format.

And the smaller file size.  Depending on the amount of compression, the
file size could be quite small while still allowing usable pictures.

> Also a point to raise is colour density. The existing Infocom games have a
> different chunk file for MCGA graphics, EGA, etc. Is it the proposal that JPEG
> would contain just the one set of images. ie. if the JPEG picturies all 256
> colour, are interpreters running on machines with less than 256 colours meant
> to dither the palette down? Or are we meant to have several groups of JPEG
> files for several different colour densities.

JPEGs are quite capable of being dithered to different sizes and paletes.

> I'd also argue against a ZIP file. Considering there will already be a time
> lag for just uncompressing a jpeg file, compressing the image wouldn't save

Decompressing a single image from a zip is quite speedy (under two seconds on my
Amiga 1200 030/50), some machines might slowdown, but I doubt it would be
noticable.

> any space and just increase the time lag. I know that GIFs can hold multiple

It wouldn't save much space, but it would be easer to deal with.  I much prefer
a directory with a couple files in it over a directory with 200 files in it any
day :-)

> images in one file (which makes the basis for animated gifs), but can jpeg
> handle this? If it could, or we use a format that does, we could put all the

JPEG couldn't handle this like GIF, but there are workarounds.  Anyway, this
method would be very memory consuming, the entire GIF would need to be split
apart before the interpreter could find the proper picture due to how they are
encoded.  Each picture isn't placed in the GIF, insted it is stored as a
modification of the image before it in the series. 

> On the side, as well, one of the original intents of Infocom was to encode the
> text so casual users couldn't see the text. Are we really sure we want to use
> such a widely known format that the casual user can just boot up his/her
> favorite graphic viewer and then view all the pictures for the game, and 
> possibly even, well, steal them? Just something to consider.

I doubt this would be a prob, just add a copyright notice to the game and have
it apply to the pictures as well.  As for viewing them, I could easly view all
the Infocom graphics and text anyway.  Being encoded is nolonger an option
unless we want to create something on the level of PGP.  

> 1) speed of
> decompression of jpegs on lower end machines, 

I doubt this is a prob, my machine is far from high-end and I don't experance
any major slowdown on the size of pictures we're talking about (about 1-5
seconds on average).

> 2) what colour density are
> we talking about; can it be dithered (and will this increase largely the
> display latency), or will several sets need to be provided, and 

As I said above, scalling and dithering are available for JPEG.

> 3) are we
> sure we want to use such a common format which is so open to inspection.

The game text is also open to inspection, I don't see this as a prob.

All of this is just my opinion though.  Although I'd prefer using PNG as a
standard insted :-)

Patrick
---

"Every weekday morning the school bell cast its glamour over the
 surounding hills, calling the young to classes.  They came running
 down the slopes and leaping over the streams, out from caves and the
 hollows of trees and suburban tract homes, impelled by powers greater
 then their own to gain an education." 
    "The Iron Dragon's Daughter" by Michael Swanwick


From ???@??? Sat Jun 07 15:18:06 1997
Date: Wed, 4 Jun 1997 17:18:50 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <v01550109afbbafcb8264@[17.202.20.138]>
Message-Id: <Pine.BSI.3.95.970604171349.26606B-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: b437564af0758319bbf2d73d714792c2

On Wed, 4 Jun 1997, Matt Ackeret wrote:

> Yes, absolutely unacceptable.  GIF would be *almost* acceptable (for only
> my personal situation) in a game with very very very few pictures.

Well, seeing as how the copyright holders are going against their promiss and
attacking public-domain authors, many sights (including Aminet) refuse to allow
GIF images to be uploaded.  If it's speed you're woried about, how about PNG?
It has all the benifits of GIF, and them some (true-colour), without the
copyright prob. 

> I'd vote for just using whatever the real v6 games use.  I'm admittedly
> still not sure about this -- is there a "generic" format, or do each of the
> v6 games that *infocom* released have system-specific data?  If they do,
> scarily, it would probably be good to support them all.

The format by Infocom was primitive even back then, it only supports 16 colours
and uses a very low resolution (640x200?)  If this is all that's supported, I
doubt we'll ever see another Z6 game.

> If there is a generic format, using that generic format still would be
> good, as it presumably is easy to compress

It would be very easy to compress as it supports no compression AFAIKT.

> This presumably answers my question above??? each system has system
> specific data??

I answered this in another post.

Patrick
---

"Every weekday morning the school bell cast its glamour over the
 surounding hills, calling the young to classes.  They came running
 down the slopes and leaping over the streams, out from caves and the
 hollows of trees and suburban tract homes, impelled by powers greater
 then their own to gain an education." 
    "The Iron Dragon's Daughter" by Michael Swanwick


From ???@??? Sat Jun 07 15:18:09 1997
Message-Id: <33961714.758E2835@micron.net>
Date: Wed, 04 Jun 1997 19:32:04 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.0b5C (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
X-Priority: 3 (Normal)
References: <199706042343.JAA27096@yallara.cs.rmit.edu.au>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 1cd9517238b16cd43975617f5dd8e339

Paul Francis Gilbert wrote:
> 
> Remember that jpegs are a compressed format, and are really intended for
> photographic images (although there may be newer revisions out that cater
> for non-photographic comrpression). The only benefit of jpeg therefore is
> the standard format.
[snip]

I'd like to stick my neck out here and suggest PNG as a good standard
format.  It works with many different types of images (both indexed and
truecolor), and its compression is both reasonably good and fast. 

> Also a point to raise is colour density. The existing Infocom games have a
> different chunk file for MCGA graphics, EGA, etc. Is it the proposal that JPEG
> would contain just the one set of images. ie. if the JPEG picturies all 256
> colour, are interpreters running on machines with less than 256 colours meant
> to dither the palette down? Or are we meant to have several groups of JPEG
> files for several different colour densities.

JPEG only supports 24-bit truecolor AFAIK.  PNG images can contain any
type of color density, from 1-bit b&w to 16-bit-per-sample RGB+Alpha. 
Truecolor PNG images can have optional "palette" chunks so CPU time
spent dithering the image can be minimized.  Of course, the best way to
support different hardware is to make alternate images which can be
transparently selected by the interpeter.


> I'd also argue against a ZIP file. Considering there will already be a time
> lag for just uncompressing a jpeg file, compressing the image wouldn't save
> any space and just increase the time lag. I know that GIFs can hold multiple
> images in one file (which makes the basis for animated gifs), but can jpeg
> handle this? If it could, or we use a format that does, we could put all the
> pictures for one game in one file.

ZIP is a bit...overcomplicated.  I would have suggested something like
Andrew's pickle format.

> Well, that's my $0.02, anyway. There's problems to consider of 1) speed of
> decompression of jpegs on lower end machines, 2) what colour density are
> we talking about; can it be dithered (and will this increase largely the
> display latency), or will several sets need to be provided, and 3) are we
> sure we want to use such a common format which is so open to inspection.

There's not much we can do about 3.  Any format we choose--or
create--will have to be well-specified, and therefore be open to
inspection.  Choosing PNG instead of JPEG will help with 1 and 2.  JPEG
support might be a worthwile option as well, for those who really _do_
want to use photographic backgrounds.

--Galen Hazelwood

From ???@??? Sat Jun 07 15:18:11 1997
Date: Wed, 4 Jun 1997 21:58:41 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom12
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <199706042343.JAA27096@yallara.cs.rmit.edu.au>
Message-Id: <Pine.SUN.3.95.970604214342.1075C-100000@netcom12>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 9a6b0dd7826e4a647e4da0fa376a3fc6

On Thu, 5 Jun 1997, Paul Francis Gilbert wrote:

> I'd argue that the compressed nature of jpegs in any case complicates the
> process for displaying pictures. Considering that the ideal of Inform is to
> make games to run on as many systems as possible, will decompressing a jpeg
> image be an unacceptable time period. Reasonable size jpegs still take several
> seconds to uncompress on my PC Pentium Pro 200, although that's for full
> sized 640x480 sized pictures. Some timings for different sized pictures/colour
> resolution would be usefull.

This doesn't have to be a problem. A slow interpreter can choose to
decompress all the images in advance, or even decompress them at startup
and store the images on disk in a simpler format. 

Or, to take this idea to extremes of simplicity: the user runs a
"unpack-standard-format"  program first; that converts the JPEGs to GIFs
or raw color data or whatever is appropriate. The interpreter then reads
the unpacked files. This isn't any less portable than the interpreter
itself; the unpack program would be written and shipped with the
interpreter. It's just a cheap way to deal with a high-quality-image
standard.

We have interpreters running on everything from small-screen monochrome
palmtops to 1980's home computers to 1990's workstations. I'm in favor of
using the best-quality format available and letting interpreters display
as best they can. You can always throw image quality away.
 
> There's problems to consider of 1) speed of
> decompression of jpegs on lower end machines, 2) what colour density are
> we talking about; can it be dithered (and will this increase largely the
> display latency), or will several sets need to be provided, 

1) is what I'm talking about above. 2) anything can be dithered. 

When I started thinking about PICKLE long ago, I wanted at least the
ability to make several sets of images available. I'm less sure now; it
could lead to massive headaches: everyone implements display code for a
different format or color depth, and then authors have to provide all of
them. A single format is easier to manage.

> 3) are we
> sure we want to use such a common format which is so open to inspection.

As has been said, it's either open to inspection or closed to everybody.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 07 15:18:13 1997
Date: Thu, 05 Jun 1997 08:38:09 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.SUN.3.95.970604214342.1075C-100000@netcom12>
Message-Id: <Marcel-1.09-0605073809-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: d75214cb888ef23a8938ea339c341f16


1.  An interesting first crop of responses.  My original proposal was
that interpreters might support the new graphics files as well as
the old (not instead) and that the new files would be ZIPped
directories containing numbered JPEG images.

I only suggested ZIPping to try and get the whole thing into one
file -- of course it wouldn't save all that much memory.  (All the
same these files could get pretty large.)  Any sensible format
(e.g. just gluing the files together end to end, with some sort
of simple header) would do equally well, of course.  And I agree
about the clunkiness of ZIPs.

I suggested JPEGs rather than GIFs because (i) they're smaller and
(ii) the compression method isn't proprietorial.  I have a machine
on which JPEG decompression is instant, so I tend to forget that
this isn't universal: apologies.  But Andrew's remarks about
decompressing in advance (note that the picture_table opcode
exists!) make some sense.  At any rate I would like to see a good
quality and universally available format: JPEG and GIF are really
the two contenders here, thanks to HTML conventions.

I would not like to see multiple sets of images (giving alternative
forms of the same picture) simply because it's extra trouble and
extra debugging and extra memory.

Finally, we are here talking about V6 games which will perhaps be
using photographic quality artwork: we don't need to go to extremes
to accommodate relatively low-end machines.  I've always felt
strongly that text games should be accessible to everyone.  But
this is a different case and V6 games are restricted to a subset
of machines already...

If we were to proceed with such a proposal, the appropriate action
would be to draw up a simple (one-page or so with any luck)
specification for these files.  I suppose there are minor issues
too, such as making graphics files identifiable in some way.

2.  Here's a survey for interpreter-people (if you'd be so kind):

(a) What's your machine?

(b) On your machine, is it reasonably simple to plot a given
    JPEG to given coordinates?

(c) On your machine, is it reasonably simple to plot a given
    GIF to given coordinates?

(d) Would time or memory considerations make this impractical?

(e) What would be your preferred graphics format?  (Not necessarily
    either of the above.)

(f) What would be your preferred way to glue together a number of
    images into one file?

(g) Are you in favour of doing something roughly like this?

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Jun 07 15:18:15 1997
Date: Thu, 5 Jun 1997 02:52:43 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <Marcel-1.09-0605073809-d07M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.BSI.3.95.970605024816.1987B-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 8674284670f25ff426edba0acca587f9

On Thu, 5 Jun 1997, Graham Nelson wrote:

> quality and universally available format: JPEG and GIF are really
> the two contenders here, thanks to HTML conventions.

PNG is also universal, it's totally free and has been ported to many
platforms.  Also, it supports true colour graphics (GIF only allows 256
colours) and has sort-of good compression (not as good as JPEG, but 100%
lossless).  And it supports transparacy (I know, misspelled) and
interlaced pictures (great for slow machines, see a low-res version as it
loads.  JPEG also now supports this).

Patrick
---

"Every weekday morning the school bell cast its glamour over the
 surounding hills, calling the young to classes.  They came running
 down the slopes and leaping over the streams, out from caves and the
 hollows of trees and suburban tract homes, impelled by powers greater
 then their own to gain an education." 
    "The Iron Dragon's Daughter" by Michael Swanwick


From ???@??? Sat Jun 07 15:18:19 1997
Date: Thu, 5 Jun 1997 05:01:30 -0700
Message-Id: <199706051201.FAA07383@albatros.wco.com>
From: Alcibiades Petrofsky <albatros@wco.com>
To: z-machine@gmd.de
In-Reply-To: <Marcel-1.09-0605073809-d07M+4%@gnelson.demon.co.uk> (message
	from Graham Nelson on Thu, 05 Jun 1997 08:38:09 +0100 (BST))
Subject: [z-machine] picture compression patents; losslessness; resolution-independence
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: e5a7f425b2b082c399cc73967dd9bed2

GIF and the Infocom picture formats both use LZW compression, which is
covered by Unisys's 1985 U.S. patent 4,558,302.  Creating any new
standard that relies on this patent is a bad idea, especially in light
of the technically superior alternatives that exist.

Many people (but not Unisys) believe that the patent only covers
compression, not decompression.  Assuming this is true, the
interpreters that read infocom graphics are in the clear, and
"pix2gif" only violates on account of the "2gif" part, not the "pix2"
part.  A "pix2png" program would be safe.  In any case, creating new
pictures is a problem.


As for "jpeg v. gif": neither is sufficient.  They're both lossy
formats.  If you compress a 24-bit photo with gif, you get a crappy
reduced-to-256-colors image.  If you compress a piece of line art with
jpeg, you get a blurred splotchy image.

PNG provides lossless compression of up to 48-bit source images with
good compression.  It is not nearly as ubiquitous as GIF, but it's
steadily gaining.  I think it's the best candidate for the primary
standard format.  For continuous tone images (i.e. scanned photos or
ray-traced computer-generated images), for which jpeg lossiness is
hardly noticable, jpeg's much better compression ratios make it an
attractive additional format.


Another issue is resolution-independence.  On my 100dpi screen, the
Beyond Zork pictures are far too small.  Perhaps interpreters should
be free to scale images, and programs should be required to use
picture_data to determine the run-time size of their images.  Did the
infocom games make any assumptions about image sizes without checking?

How would an interpreter choose what size to scale an image to?
(Ideally, a game could set the size of an image, but I don't want to
propose a new opcode in my first mail to the list).  For PNG files, it
could read the desired size in millimeters out of the file.  For other
formats it could guess the intended resolution: for infocom format,
50dpi; for jpeg, 100dpi.

If you want to go for it all, supporting a vector format like PDF
would really liven things up.  Then scaling wouldn't have annoying
artifacts, and when a player finally gets the wizard to give him the
GUE Tech diploma, he could push his interpreter's print button to get
a 300dpi hardcopy, suitable for framing.

-al

From ???@??? Sat Jun 07 15:18:27 1997
Date: Thu, 5 Jun 1997 08:16:31 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Graham Nelson <graham@gnelson.demon.co.uk>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <Marcel-1.09-0605073809-d07M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SGI.3.96.970605081257.21968G-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 27bcaf27b1afdbe8d01a4f14a876b448

>2.  Here's a survey for interpreter-people (if you'd be so kind):
>
>(a) What's your machine?

  D'pends.  Fairly old Mac, truly archaic IBM, usually use quite recent
SGI...

>(b) On your machine, is it reasonably simple to plot a given
>    JPEG to given coordinates?

  I know Mac programming best - inasmuch as decoding the JPEG is simple,
plotting it is easy enough.

>(c) On your machine, is it reasonably simple to plot a given
>    GIF to given coordinates?

  Again, aside from decompressing and loading, yes.

>(d) Would time or memory considerations make this impractical?

  Yes.

>(e) What would be your preferred graphics format?  (Not necessarily
>    either of the above.)

  Layered bitmap with pallete prepended.  No compression.

>(f) What would be your preferred way to glue together a number of
>    images into one file?

  Use directories...

  No, if you *must*, I'm all for Pickle.  Or tarfiles.  Certainly no
compressing format.

>(g) Are you in favour of doing something roughly like this?

  Yes.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 07 15:18:23 1997
Date: Thu, 5 Jun 1997 08:17:28 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Patrick Kellum <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <Pine.BSI.3.95.970605024816.1987B-100000@ns1.syix.com>
Message-Id: <Pine.SGI.3.96.970605081708.21968H-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: a4071745682f01c92753833be51272fb

>PNG is also universal, it's totally free and has been ported to many
>platforms.  Also, it supports true colour graphics (GIF only allows 256
>colours) and has sort-of good compression (not as good as JPEG, but 100%
>lossless).  And it supports transparacy (I know, misspelled) and
>interlaced pictures (great for slow machines, see a low-res version as it
>loads.  JPEG also now supports this).

  In which case I'm not adverse to this.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 07 15:18:24 1997
Date: Thu, 5 Jun 1997 08:21:30 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Alcibiades Petrofsky <albatros@wco.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] picture compression patents; losslessness; resolution-independence
In-Reply-To: <199706051201.FAA07383@albatros.wco.com>
Message-Id: <Pine.SGI.3.96.970605081830.21968I-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 64c5bad4a3bb11ceb2fa17976e10c163

>PNG provides lossless compression of up to 48-bit source images with
>good compression.  It is not nearly as ubiquitous as GIF, but it's
>steadily gaining.  I think it's the best candidate for the primary
>standard format.  For continuous tone images (i.e. scanned photos or
>ray-traced computer-generated images), for which jpeg lossiness is
>hardly noticable, jpeg's much better compression ratios make it an
>attractive additional format.

  Rather than look up the PNG format, I'm going to ask:  Does PNG take
dramatically less space if you use dramatically fewer colors?  That is,
suppose I thought B&W graphics, or 16 colors, were enough (I do) - would
the PNG be able to store graphics data in 1/4 bits/pixel, rather than some
whole number of bytes?

>Another issue is resolution-independence.  On my 100dpi screen, the
>Beyond Zork pictures are far too small.  Perhaps interpreters should
>be free to scale images, and programs should be required to use
>picture_data to determine the run-time size of their images.  Did the
>infocom games make any assumptions about image sizes without checking?

  Perhaps images should have fixed size relative to text.

>If you want to go for it all, supporting a vector format like PDF
>would really liven things up.  Then scaling wouldn't have annoying
>artifacts, and when a player finally gets the wizard to give him the
>GUE Tech diploma, he could push his interpreter's print button to get
>a 300dpi hardcopy, suitable for framing.

  Agh, yes.  I find myself forced to agree with the benefits of drastic
measures like this.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 07 15:18:28 1997
Date: Thu, 5 Jun 1997 10:11:23 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706051411.KAA28679@wanda.vf.pond.com>
To: mattack@apple.com, z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 5b9c232b26de19a5194cfae92626e73f

} Yes, absolutely unacceptable.  GIF would be *almost* acceptable (for only
} my personal situation) in a game with very very very few pictures.

} I'd vote for just using whatever the real v6 games use.  I'm admittedly
} still not sure about this -- is there a "generic" format, or do each of the
} v6 games that *infocom* released have system-specific data?  If they do,
} scarily, it would probably be good to support them all.

The real V6 games use a format similar in capability to multiple GIF89a's. 
For the Mac, there are two major formats, the black and white one and
the color one.  The main difference is that the black and white one
doesn't include color tables, and the pictures are full size.  The
color ones have color tables (though I haven't quite figured out how
they are supposed to interact, particularly w.r.t what already plotted
pictures like the border in _Arthur_ do when the color table changes.)
and the pictures are quarter size -- the interpreter does pixel
doubling in both directions when drawing them.  

I think the Amiga format is similar to the Mac color format, and I
assume we won't be using the Apple //e format :-).

} If there is a generic format, using that generic format still would be
} good, as it presumably is easy to compress

The IBM VGA format uses the same compression as GIF (LZW).  The Mac format
uses Huffman.

From ???@??? Sat Jun 07 15:18:31 1997
Date: Thu, 5 Jun 1997 10:29:35 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706051429.KAA29851@wanda.vf.pond.com>
To: graham@gnelson.demon.co.uk, z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 2256982f2de203197713faa83a16be42

} I only suggested ZIPping to try and get the whole thing into one
} file -- of course it wouldn't save all that much memory.  (All the
} same these files could get pretty large.)  Any sensible format
} (e.g. just gluing the files together end to end, with some sort
} of simple header) would do equally well, of course.  And I agree
} about the clunkiness of ZIPs.

I'll second the idea of an IFF-based format -- it's pretty much the same
as gluing the files together end to end.

} I suggested JPEGs rather than GIFs because (i) they're smaller and
} (ii) the compression method isn't proprietorial.  I have a machine
} on which JPEG decompression is instant, so I tend to forget that
} this isn't universal: apologies.  

The nice thing about GIFs, Unisys's patent-terrorism aside, is that
they work better for non-photographic images.

} I would not like to see multiple sets of images (giving alternative
} forms of the same picture) simply because it's extra trouble and
} extra debugging and extra memory.

Nor I, but I wouldn't mind having some images in GIF and some in JPEG.

} 2.  Here's a survey for interpreter-people (if you'd be so kind):

} (a) What's your machine?

Powermac 8500

(b) On your machine, is it reasonably simple to plot a given
    JPEG to given coordinates?

I haven't done it, but I think it is on any QuickTime-equipped Mac.

} (c) On your machine, is it reasonably simple to plot a given
}     GIF to given coordinates?

Yep, not built in but I've got all sorts of code laying around to do it.

} (d) Would time or memory considerations make this impractical?

Nope.

} (e) What would be your preferred graphics format?  (Not necessarily
}     either of the above.)
JPEG for photo-quality images, GIF for drawings/icons/etc

} (f) What would be your preferred way to glue together a number of
}     images into one file?

An IFF-based format.

(g) Are you in favour of doing something roughly like this?

Yes, but I think you'd be better off asking game authors, not just
interpreter authors.

From ???@??? Sat Jun 07 15:18:35 1997
Date: Thu, 5 Jun 1997 10:36:28 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706051436.KAA00392@wanda.vf.pond.com>
To: albatros@wco.com, z-machine@gmd.de
Subject: Re:  [z-machine] picture compression patents; losslessness; resolution-independence
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c43a73fba4809321d2d8315a5cd943e9

} GIF and the Infocom picture formats both use LZW compression, which is
} covered by Unisys's 1985 U.S. patent 4,558,302.  Creating any new
} standard that relies on this patent is a bad idea, especially in light
} of the technically superior alternatives that exist.

Note that there are also patents covering LZ-1 and other LZ variants,
there's another patent covering combining RLE with Huffman(!), another
LZW patent held by IBM, etc.

} Another issue is resolution-independence.  On my 100dpi screen, the
} Beyond Zork pictures are far too small.  Perhaps interpreters should
} be free to scale images, and programs should be required to use
} picture_data to determine the run-time size of their images.  Did the
} infocom games make any assumptions about image sizes without checking?

Yes.  Changing image sizes or the screen size on Infocom V6 games
is asking for a divide-by-zero error or bizarre display behaviour. 

From ???@??? Sat Jun 07 15:18:38 1997
Message-Id: <3396DDA2.8080A2A8@micron.net>
Date: Thu, 05 Jun 1997 09:39:14 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.0b5C (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
X-Priority: 3 (Normal)
References: <Marcel-1.09-0605073809-d07M+4%@gnelson.demon.co.uk>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 64b3704af758141af6ab5aabb770f084

Graham Nelson wrote:
> 2.  Here's a survey for interpreter-people (if you'd be so kind):
> 
> (a) What's your machine?

Pentium/100, 16 Megs, running Linux and Win95.

> (b) On your machine, is it reasonably simple to plot a given
>     JPEG to given coordinates?

You bet.

> (c) On your machine, is it reasonably simple to plot a given
>     GIF to given coordinates?

Yes.

> (d) Would time or memory considerations make this impractical?

Nope.  Even relatively underpowered 486s should be able to handle it.

> (e) What would be your preferred graphics format?  (Not necessarily
>     either of the above.)

PNG.  It's well designed, well documented, and is perfect for situations
like these.  We can steal free library code to handle the format.  What
more can you ask for?  JPEG support should probably be an option as
well.

> (f) What would be your preferred way to glue together a number of
>     images into one file?

Something simple, no more than a table of contents and a bunch of images
appended together.  Something like IFF or Andrew's PICKLE.

> (g) Are you in favour of doing something roughly like this?

I see no reason not to.  :)

--Galen Hazelwood

From ???@??? Sat Jun 07 15:18:41 1997
Date: Thu, 5 Jun 1997 11:47:08 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Galen Hazelwood <galenh@micron.net>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <3396DDA2.8080A2A8@micron.net>
Message-Id: <Pine.SGI.3.96.970605114611.29452D-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 170e0ca2eaec8933b68137e026ed3583

>> (d) Would time or memory considerations make this impractical?
>
>Nope.  Even relatively underpowered 486s should be able to handle it.

  What about those of us using *old* computers?  What of a 386 or earlier?

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 07 15:18:42 1997
Message-Id: <3396E16F.148E1A6E@micron.net>
Date: Thu, 05 Jun 1997 09:55:27 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.0b5C (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: "A.K.A. TheWiz" <dankna@bergen.org>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
X-Priority: 3 (Normal)
References: <Pine.SGI.3.96.970605114611.29452D-100000@davinci.bergen.org>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: b157420a546dfc17ab0adc40ebb1f577

A.K.A. TheWiz wrote:
> 
> >> (d) Would time or memory considerations make this impractical?
> >
> >Nope.  Even relatively underpowered 486s should be able to handle it.
> 
>   What about those of us using *old* computers?  What of a 386 or earlier?

JPEGs will be really slow, but they should still work.  I don't know...I
haven't tried to decompress one on a 386.  Have you?  How long does it
take?

PNG should work just fine.  It clips along quite quickly on my brother's
486, and should even be reasonable on older machines.  Anything older
than a 386 will probably be hurting, though.

--Galen

From ???@??? Sat Jun 07 15:18:45 1997
Date: Thu, 5 Jun 1997 12:28:33 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Galen Hazelwood <galenh@micron.net>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <3396E16F.148E1A6E@micron.net>
Message-Id: <Pine.SGI.3.96.970605122745.2397A-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 037461d38f9cf4595bb87e3b5fe8ce2b

>JPEGs will be really slow, but they should still work.  I don't know...I
>haven't tried to decompress one on a 386.  Have you?  How long does it
>take?

  I have not, hence the question :)

>PNG should work just fine.  It clips along quite quickly on my brother's
>486, and should even be reasonable on older machines.  Anything older
>than a 386 will probably be hurting, though.

  Whatever happened to whatever formats were used when old machines were
current?

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 07 15:18:47 1997
Message-Id: <3396ED34.30CC@earthweb.com>
Date: Thu, 05 Jun 1997 12:45:40 -0400
From: Carl Muckenhoupt <carl@earthweb.com>
Reply-To: carl@earthweb.com
Organization: EarthWeb
X-Mailer: Mozilla 3.0 (Win95; I)
Mime-Version: 1.0
To: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
References: <199706042343.JAA27096@yallara.cs.rmit.edu.au>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: b4335828e69fd4c629a124055f650c58

Just a couple more points to be made here:

JPEG compression is lossy.  For the content it was designed for
(photographs), this doesn't matter - photographs aren't actually
composed of pixels, so precise duplication of your scanned image's
pixels is not a concern.  One could imagine situations in a game where
precise pixel-level control is important - for example, a parchment
densely covered with strange runes which the player is expected to
translate.

ZIP files don't need to be compressed.  First and foremost, ZIP is an
archiving format which can use several different forms of compression,
including none.  If we just want a way of sticking many files together
into one file along with an index, ZIP is as good a format as any.  But
in all likelihood, the same can be said for Infocom's format...

-- 
Carl Muckenhoupt		carl@earthweb.com
EarthWeb			http://www.earthweb.com/

From ???@??? Sat Jun 07 15:18:49 1997
Message-Id: <3396EDC4.ABC89B76@micron.net>
Date: Thu, 05 Jun 1997 10:48:04 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.0b5C (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: "A.K.A. TheWiz" <dankna@bergen.org>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
X-Priority: 3 (Normal)
References: <Pine.SGI.3.96.970605122745.2397A-100000@davinci.bergen.org>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: f90b9450c159a603f9b502da6ce7dd14

A.K.A. TheWiz wrote:
>   Whatever happened to whatever formats were used when old machines were
> current?

Well, I remember running a GIF viewer on my family's old 286, so GIF is
at least that old.  It worked okay, a bit slow.  The major difference
between GIF and PNG is the different (unpatented) compression
algorithm.  I haven't touched anything slower than a 386 in ages, so I
can't tell you how it would work.

Most graphics formats for games in those days were uncompressed pixmaps,
as I remember.  I was young then, so I could be wrong...

--Galen

From ???@??? Sat Jun 07 15:18:57 1997
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] resolution-independence; number of colours
Date: Thu, 5 Jun 1997 20:54:43 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <19970605204139.AAB13412@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: 72180c45082ebb6f2a8babd13c6353b2


> } Another issue is resolution-independence.  On my 100dpi screen, the
> } Beyond Zork pictures are far too small.  Perhaps interpreters should
> } be free to scale images, and programs should be required to use
> } picture_data to determine the run-time size of their images.  Did the
> } infocom games make any assumptions about image sizes without checking?
> 
> Yes.  Changing image sizes or the screen size on Infocom V6 games
> is asking for a divide-by-zero error or bizarre display behaviour. 

There's no problem with scaling pictures of Infocom V6 games.  Both Frotz
and Infocom's own interpreters do so.  For instances, the MCGA-Amiga-Mac
graphics files are designed for a resolution of 320x200 pixels.  It's no
problem to run these games under 640x200, 640x400, 1280x800 etc. as long
as you scale the pictures accordingly.  (Infocom games used PICTURE_DATA
to determine the actual size of a picture.)  

Apparently, it must be clear for which resolution a graphics file has
been designed.  I suggest our new graphics file format should provide
this information.  It would be helpful if we agreed on a standard
resolution of 640x400 pixels.  My DOS Frotz can't support everything, you
know.

I'd like to point out another problem: We should reserve some colours --
between 2 and 16 -- for text display.  Furthermore, all pictures on the
screen should share the same colour palette, at least if they use only 8
bits per pixel.  Any objections?

-- Stefan


From ???@??? Sat Jun 07 15:18:51 1997
From: Miron Schmidt <s590501@tfh-berlin.de>
Reply-To: miron@comports.com
To: z-machine@gmd.de
Date: Thu, 05 Jun 1997 21:01:55 +0100
Message-Id: <yam7095.2756.1205599216@mailhost.tfh-berlin.de>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Organization: TFH-Berlin via PPP
Subject: [z-machine] V6 picture format bulk answers
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: cfb620496218897c0d5ce468954998c3

Hi there!

OK, here's my personal views about some of the raised issues.

  - Image format:
    As several people have stated, JPEG ist simply unusable for any
    non-photographic (or scanned) pictures. GIF, on the other hand, is
    limited to 8 bitplanes, and therefore unusable for good photographic
    images.
    PNG seems to fit all needs. Deal?

  - Image archive:
    I'm not sure if IFF is really ideal for the cause, since that would
    require a new discussion about the exact format of the chunk descriptors.
    The PICKLE format, on the other hand, is perfectly suited, especially as
    it could be extended in the future, should the need arise.

  - Image compression:
    Does PNG have internal compression formats? If not, I'd suggest RLEN
    compression for non-photographic and Huffman for photographic images
    (RLEN for non-photographic because it should just about suffice and is
    much faster to decompress).

  - Speed and memory:
    I don't think memory is a major issue: decompressiom, if done at all
    sensibly, doesn't need very much; and pictures can always be so large
    that they don't fit the memory. If we choose not to specify a maximum
    picture size (as I would suggest), there can never be sufficient memory.
    Speed is probably more important, but would it really hurt that much if
    an owner of a slow machine had to wait a few seconds for the picture to
    appear? I don't think so, but I do think that we shouldn't settle for an
    inferior picture format just because it's slightly faster to display.

  - Scaling:
    _Please_, no vector-based format! These tend to become huge very fast,
    and are fairly costy (time- and memorywise) to decode.
    It should be left to the interpreter to scale pictures as it sees fit:
    the user could choose if pictures were to be displayed 1:1, 1:2 etc.
    If you encode a real-length somewhere in the picture (such as 5mm by
    11mm), I'm not sure if the pictures could still be correctly placed into
    their respective screen positions. The Peggleboz stones in Zork Zero,
    for example, are placed directly onto the game board. Each stone is
    perhaps 1.5mm x 1.5mm -- how would you encode such tiny dimensions? Two
    decimal places? What about 10000dpi screens of the next millenium then?

-- 
Miron Schmidt <miron@comports.com>

           "So, if _Space Aliens_ is Infocom on acid, what's this?"
                       -- C.E. Forman, _Detective: An Interactive MiSTing_



From ???@??? Sat Jun 07 15:19:10 1997
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
Message-Id: <199706060134.LAA08775@yallara.cs.rmit.edu.au>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
To: z-machine@gmd.de
Date: Fri, 6 Jun 1997 11:34:28 +1000 (EST)
In-Reply-To: <Marcel-1.09-0605073809-d07M+4%@gnelson.demon.co.uk> from "Graham Nelson" at Jun 5, 97 08:38:09 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: a55adf070fac89e993d3531afd9cc1bb

While we're on the subject of v6 pictures, is there any plans to limit the
picture opcodes to only version 6? I seem to recall a while ago a person
mentioning that it was a pitty we were using new version numbers to represent
doubling amount (ie. 7/8), since it meant that to allow a v6 style game with
double the memory, yet a new version number would need to be introduced.

Is that true? Are version 6 graphic opcodes limited to v6, or is it v6+. If
if the prior, then has there been any discussion of how to get around this
(I believe the person proposed a set of bitflags for advanced capabilities).


-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Sat Jun 07 15:19:13 1997
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
Message-Id: <199706060146.LAA14724@yallara.cs.rmit.edu.au>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
To: z-machine@gmd.de
Date: Fri, 6 Jun 1997 11:46:44 +1000 (EST)
In-Reply-To: <Pine.SGI.3.96.970605114611.29452D-100000@davinci.bergen.org> from "A.K.A. TheWiz" at Jun 5, 97 11:47:08 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: f54f79947c9bba24b701ca2f1de06ac8

> 
> >> (d) Would time or memory considerations make this impractical?
> >
> >Nope.  Even relatively underpowered 486s should be able to handle it.
> 
>   What about those of us using *old* computers?  What of a 386 or earlier?
> 

That was one my original points. That decompression speeds is a big deal. V6
games are already limited to the number of computers they can run on... lets
not go out of our way to decrease the number.

Someone else, I think it was Graham, suggested that the images, were they in
a compressed format like JPEG, could be decompressed at the start. The only
problem with this is 1) You'd either need a lot of disk space or memory to
store the uncompressed images, and in a lower end computer where decompression
on the fly during the game would be too slow, it's more than likely not to
have the resources to decompress them all.
2) If there are a lot of pictures, uncompressing them at the start would be
very time consuming. Imagine waiting five/ten minutes for the images to be
decompressed every time you plan [that may be exaggerating a bit, but the
point is that it could take an unacceptable amount of time for casual players].

Anyway, it's just something to be wary of. Not everyone has a supercomputer,
and we should try to keep the number of computers that can run the standard
format chosen as great as possible.

> ____________________________________________________________________________
> |The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
> |---------------|  Blip  |-------------------------------------------------|
> |   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
> ----------------------------------------------------------------------------
> 
> 


-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Sat Jun 07 15:19:16 1997
Message-Id: <33981B53.17B9@earthweb.com>
Date: Fri, 06 Jun 1997 10:14:43 -0400
From: Carl Muckenhoupt <carl@earthweb.com>
Reply-To: carl@earthweb.com
Organization: EarthWeb
X-Mailer: Mozilla 3.0 (Win95; I)
Mime-Version: 1.0
To: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
References: <199706060146.LAA14724@yallara.cs.rmit.edu.au>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: f9c87edd4a4454fe8db59f47f2f27e56

Paul Francis Gilbert wrote:
> 2) If there are a lot of pictures, uncompressing them at the start would be
> very time consuming. Imagine waiting five/ten minutes for the images to be
> decompressed every time you plan [that may be exaggerating a bit, but the
> point is that it could take an unacceptable amount of time for casual players].

Not an exaggeration at all! I remember uncompressing JPEGs on a 386, and
if I recall correctly it tended to be on the order of 30 second to a
minute for a full-screen (320x200) image.  At that rate, ten minutes is
an understatement.  It is possible that my JPEG reader was simply
inefficient, of course; anyone interested in confirming this should do
so.

-- 
Carl Muckenhoupt		carl@earthweb.com
EarthWeb			http://www.earthweb.com/

From ???@??? Sat Jun 07 15:19:20 1997
Message-Id: <199706061528.RAA00610@dns.speednet.it>
X-Mailer: Microsoft Outlook Express 4.71.0544.0
From: "Giovanni Riccardi" <g.riccardi@speednet.it>
To: "z-machine mailing list" <z-machine@gmd.de>
Subject: [z-machine] Re: Modern V6 picture format, anyone?
Date: Fri, 6 Jun 1997 17:27:10 +0200
X-Priority: 3
X-Msmail-Priority: Normal
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: 282c4303c1fe31fbb8c70e851f5a4066

On my old 486DX-33 even 640x480 pictures took 10 to 15 seconds to
uncompress.
With a dos jpeg viewer (i don't remember the name of this program) only 5
to 8 secs !!!
Now on my P166+ uncompressing such an image 
is instant.

-----------------------
  Giovanni Riccardi
g.riccardi@speednet.it
  Terracina  Italy  
-----------------------



From ???@??? Sat Jun 07 15:19:25 1997
Date: Fri, 6 Jun 1997 09:13:28 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <199706060146.LAA14724@yallara.cs.rmit.edu.au>
Message-Id: <Pine.SUN.3.95.970606083627.18645C-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: f6bf7ae0c63f2e4a816a8e9c936213c1

On Fri, 6 Jun 1997, Paul Francis Gilbert wrote:

> Someone else, I think it was Graham, suggested that the images, were they in
> a compressed format like JPEG, could be decompressed at the start. The only
> problem with this is 1) You'd either need a lot of disk space or memory to
> store the uncompressed images, and in a lower end computer where decompression
> on the fly during the game would be too slow, it's more than likely not to
> have the resources to decompress them all.

Then that game won't run on that machine. If a game has a lot of large,
detailed pictures, it will require a machine with considerable graphics
muscle power. If it has a few small images (say, pictures of cryptic 
runes), then decompression speed will not be an issue in the first place.
The format we choose should not restrict authors from this choice.

I'm looking at the PNG format:

http://www.boutell.com/boutell/png/

It seems extremely happy. It can handle pretty much everything from
monochrome to 48-bit color, and it allows progressive decompression (so
the user sees a blocky low-res image immediately, which gets more detailed
over time.) If we go with this, then display resources (speed, memory,
disk space) will only be critical for games with large images; and such a
game is going to require a hefty machine anyway.

> 2) If there are a lot of pictures, uncompressing them at the start would be
> very time consuming. Imagine waiting five/ten minutes for the images to be
> decompressed every time you play [that may be exaggerating a bit, but the
> point is that it could take an unacceptable amount of time for casual players].

One of my footnotes was that it doesn't have to be every time you play. It
can be once after you download the game. If you don't have room on your
machine for the images, again, you're not going to be able to play that
particular game with that interpreter.

>From another thread:

> Are version 6 graphic opcodes limited to v6, or is it v6+. If if the
> prior, then has there been any discussion of how to get around this
> (I believe the person proposed a set of bitflags for advanced
> capabilities).

Yes, they're limited to V6. I don't think this is fixable. It's not just
a indepedent set of opcodes. There are massive changes in the V6 format,
including different behavior of most of the output opcodes (including
text output.) Also, different encoding of many existing opcodes. There's
not much hope of a "unified" format which includes both the V5/V8 lineage
and the V6 lineage.

Obviously, this is not the ideal model to follow in any future extension
to the Z-machine, or new virtual machines. :-) 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Sat Jun 07 15:19:27 1997
Date: Fri, 6 Jun 1997 13:22:52 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706061722.NAA29239@wanda.vf.pond.com>
To: erkyrath@netcom.com, z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c76ade8bd69ac41c6fc8872086b41071

} Yes, they're limited to V6. I don't think this is fixable. It's not just
} a indepedent set of opcodes. There are massive changes in the V6 format,
} including different behavior of most of the output opcodes (including
} text output.) Also, different encoding of many existing opcodes. There's
} not much hope of a "unified" format which includes both the V5/V8 lineage
} and the V6 lineage.

For amusement purposes, change the first byte of a V5 game to 06, and
try running it on a V6 interpreter.

From ???@??? Sat Jun 07 15:19:29 1997
Date: Fri, 6 Jun 1997 11:35:56 -0700
Message-Id: <199706061835.LAA21742@albatros.wco.com>
From: Alisburysay Eakstay Petrofsky <albatros@wco.com>
To: z-machine@gmd.de
In-Reply-To: <Pine.SUN.3.95.970606083627.18645C-100000@netcom> (message from
	Andrew Plotkin on Fri, 6 Jun 1997 09:13:28 -0700 (PDT))
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 273a190626559f9c06ef2bb4593c0013

   Date: Fri, 6 Jun 1997 09:13:28 -0700 (PDT)
   From: Andrew Plotkin <erkyrath@netcom.com>

   Then that game won't run on that machine. If a game has a lot of large,
   detailed pictures, it will require a machine with considerable graphics
   muscle power. If it has a few small images (say, pictures of cryptic 
   runes), then decompression speed will not be an issue in the first place.
   The format we choose should not restrict authors from this choice.

Definitely.  It should be pointed out that there could be a program
that will take an archive of arbitrary PNGs and JPEGs and output a
smaller archive of pictures (in most cases degraded) that are suitable
for a low-power machine (e.g. no more than 4bits/pixel, no picture
bigger than 320x200 pixels, some reserved pixels unused, or whatever
your constraints are).  It could even output an infocom-format
archive.

In this approach, the author is unconstrained in how much detail he
can provide, and the player is constrained only by the inevitable
limitations of his machine.  For the sake of those too underpowered to
even run the converter program, we can choose a standard set of
low-res constraints (probably something corresponding to what the
infocom interpreters could handle) and state that the author should
provide a picture archive that meets those constraints (possibly even
in infocom format), in addition to the full-featured png/jpeg archive
(from which the constrained version was automatically generated).

The big snag is that it's very possible that in some of the degraded
images, details necessary to the play of the game will be
indiscernible.  Authors should perhaps be required to check for and
warn about this, but requiring any more would be making them slaves to
the past.  If an author wants to go the extra distance to support old
machines, he can fine-tune the low-res archive.


Further extending this line of thinking, I think that while PNG and
jpeg should be the only standard contents of an image archive, it
should be specifically allowed to provide additional archives that
have additional formats in them.  Archives should have
meta-information describing the format of each picture included,
perhaps using a MIME content-type identifier (i.e. "image/png",
"image/jpeg", "image/x-pdf", "image/x-malyon", etc.).  Again, the
author can automatically generate a standard archive, but also provide
the optimal experience for players with full-featured interpreters.

Note that I am conciously proposing multiple picture archive files
rather than a single archive with multiple image encodings per
picture.  I think this is simpler, and more importantly it means the
low-powered machine owner only downloads the short archive file.  If
everybody had to download the multimegabyte file that contained all
formats of all pictures, then we would defeat support for smaller
machines.



I think two other features are required to turn v6 pictures from a
clunky, 80's hardware-locked scheme to a fully modern one: 1) allow
dynamic screen size changes (i.e. changes to the window in which the
interpreter runs); 2) allow picture scaling.

Screen size change could be done by calling a newline-interrupt-like
routine, specified in the (extended) header.

Picture scaling could be done by extending picture_data to set the
picture size if given a negative picture number.  This is a compatible
change, since interpreters unable or unwilling to scale the image
could do nothing, just as current interpreters do when given an
invalid picture number (which a negative number is).

Scaling is needed for a game to intelligently display pictures in
accordance with the screen size it is currently running on.  Banners
across the top or side of the screen, or full-screen displays, plus
numerous other effects, are only possible by writing for a single
screen-size (as infocom did) or by having dynamic scaling.



It is often forgotten that infocom v3-5 games all had high-quality
graphics, in hardcopy form.  With these improvements, I think new v6
games could have graphics as high-quality as those of infocom
packaging, and I think that should be the goal.

-al

From ???@??? Sat Jun 07 15:19:31 1997
Date: Fri, 6 Jun 1997 11:39:20 -0700
Message-Id: <199706061839.LAA21908@albatros.wco.com>
From: Allpoxsmay Petrofsky <albatros@wco.com>
To: pfg@yallara.cs.rmit.edu.au
Cc: z-machine@gmd.de
In-Reply-To: <199706060134.LAA08775@yallara.cs.rmit.edu.au> (message from Paul
	Francis Gilbert on Fri, 6 Jun 1997 11:34:28 +1000 (EST))
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: a6afb14e68c02bab993e222d12ebe7c8


   From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>

   While we're on the subject of v6 pictures, is there any plans to limit the
   picture opcodes to only version 6? I seem to recall a while ago a person
   mentioning that it was a pitty we were using new version numbers to represent
   doubling amount (ie. 7/8), since it meant that to allow a v6 style game with
   double the memory, yet a new version number would need to be introduced.

I don't understand the problem.  V7 and V8 should just be viewed as
V5.1 and V5.2.  They provide a minor enhancement to v5 (increased
address space), and v6 provides many enhancements over them.  The only
thing in v8 that's not in v6 is a slightly more convenient and less
restrictive addressing system: they both have 512K max size, but v6
additionally requires that packed strings and routines each fit in
256K (this is slightly ameliorated by v6's less restrictive alignment
requirement: 4 bytes v. 8 bytes).  Do today's V8 games actually exceed
this restriction?

It's quite likely I'm missing something here.

-al

From ???@??? Sat Jun 07 15:19:34 1997
Message-Id: <Mutt.19970606153829.jholder@deimos.frii.com>
Date: Fri, 6 Jun 1997 15:38:29 -0600
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
References: <199706042343.JAA27096@yallara.cs.rmit.edu.au> <Pine.BSI.3.95.970604165305.26606A-100000@ns1.syix.com>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <Pine.BSI.3.95.970604165305.26606A-100000@ns1.syix.com>; from Patrick Kellum on Jun 4, 1997 17:13:17 -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: f3015d786ed9a4b3db73e77170f98416

Patrick Kellum writes:
> All of this is just my opinion though.  Although I'd prefer using PNG as a
> standard insted :-)

Personally, I'm surprised this took so long to come up.  PNG images are not
lossy, and in some cases can achieve compression as good as jpegs.  PNG
is a free format.  PNG has easy to compile and link source, easier than
JPEG IMHO.  Basically, I think PNG is the coolest image format since
sliced bread.

Just throwing in my 0.02 zorkmids.

-- 
John Holder (jholder@frii.com) /\            http://www.frii.com/~jholder/
UNIX Specialist, Paranet Inc. <--> Raytracing|Fractals|Interactive Fiction
http://www.paranet.com/        \/           Homebrewing|Strange Attractors

From ???@??? Mon Jun 09 16:20:25 1997
Date: 07 Jun 97 03:12:29 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format
Message-Id: <970607071228_104312.2206_IHS43-1@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: cf24a8dd748210954fc10910c24b6063


Graham wrote:

<< I suggested JPEGs rather than GIFs because (i) they're smaller and
(ii) the compression method isn't proprietorial.  I have a machine
on which JPEG decompression is instant, so I tend to forget that
this isn't universal: apologies.  But Andrew's remarks about
decompressing in advance (note that the picture_table opcode
exists!) make some sense.  At any rate I would like to see a good
quality and universally available format: JPEG and GIF are really
the two contenders here, thanks to HTML conventions. >>

I know the palmtops aren't typical, but I will point out that
JPEGs *are* impractical on the Psion3 (Psion's own web browser doesn't 
even attempt to handle them.)  And decompressing in advance is only an 
option if you have somewhere to put the decompressed data.
 
<< Finally, we are here talking about V6 games which will perhaps be
using photographic quality artwork: we don't need to go to extremes
to accommodate relatively low-end machines.  I've always felt
strongly that text games should be accessible to everyone.  But
this is a different case and V6 games are restricted to a subset
of machines already... >>

It is true that graphical games aren't going to work well on palmtops 
until they have colour screens.  Any graphics added to games ought to 
be 24-bit photo-quality (digitised photos could work well for some 
games) which don't work well with less than 8-bit colour.
 
(a) What's your machine?

Psion3a (+others).
 
(b) On your machine, is it reasonably simple to plot a given
    JPEG to given coordinates?
 
No. 
 
(c) On your machine, is it reasonably simple to plot a given
    GIF to given coordinates?

Assuming you narrow down the GIF format. 
(87/89/interlaced/non-interlaced/bit-depth.)
But GIFs max-out at 8-bit?

(d) Would time or memory considerations make this impractical?

Just unpleasant.
 
(e) What would be your preferred graphics format?  (Not necessarily
    either of the above.)

PNG.  Allows 24-bit.  Better compression than GIF.  Unencumbered by 
silly patent disputes.
 
(f) What would be your preferred way to glue together a number of
    images into one file?
    
Another IFF or PICKLE.
 
(g) Are you in favour of doing something roughly like this?

In principle.  But given the amount of working getting to Z6, the 
current palmtop limits, and other commitments, I'm not going to be able 
to think about until there is at least one killer game out there that 
users want to play.

    Bryan

 


From ???@??? Sat Jun 21 20:08:52 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Sat, 07 Jun 1997 13:13:31 -0000
Message-Id: <yam7097.1593.3775680@smtp.netcomuk.co.uk>
In-Reply-To: <Marcel-1.09-0605073809-d07M+4%@gnelson.demon.co.uk>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: multipart/mixed; boundary="--------geoboundary"

<x-html>

<HTML>
<BODY>
<CENTER>
<A HREF="http://www.geocities.com">Postage paid by: <IMG SRC="http://www.geocities.com/pictures/newgeobt.gif"></A></CENTER>
</BODY>
</HTML>
</x-html>

On 05-Jun-97, Graham Nelson wrote:
>I suggested JPEGs rather than GIFs because (i) they're smaller and
>(ii) the compression method isn't proprietorial.  I have a machine
>on which JPEG decompression is instant, so I tend to forget that
>this isn't universal: apologies.  But Andrew's remarks about
>decompressing in advance (note that the picture_table opcode
>exists!) make some sense.  At any rate I would like to see a good

In current implementations picture_table is not used for that. In particular,
the size of memory cache is small (5Kb in the case of the Amiga interpreter),
and the interpreter caches the _compressed_ picture data. It is implicitly
assumed that decompression is very quick, which it will be for the small images
for which picture_table was designed.

Whilst it would be possible to change this, I don't think it's worth it, and
using picture_table is not an appropriate way to go about it. It's more an
interpreter issue. An interpreter might choose to:
- load the entire picture file to memory, decompressing pictures as necessary;
- load and decompress all pictures to memory;
- implement some kind of cache for compressed or decompressed image data to
  avoid having to load the entire file.
Apart from using picture_data as it was intended to be used, the game developer
should not be concerned with this; after all, you don't know anything about
which computer system the interpreter is running, or anything about the
internal workings of the interpreter for that matter. You can assume that the
interpreter knows best.


>I would not like to see multiple sets of images (giving alternative
>forms of the same picture) simply because it's extra trouble and
>extra debugging and extra memory.

Though multiple picture files is the approach already taken by Infocom. [I'm
not suggesting that this should continue to be the case.]


>Finally, we are here talking about V6 games which will perhaps be
>using photographic quality artwork: we don't need to go to extremes
>to accommodate relatively low-end machines.  I've always felt
>strongly that text games should be accessible to everyone.  But
>this is a different case and V6 games are restricted to a subset
>of machines already...

Well, I think that any V6 game should be at least playable on a machine for
which there is already a V6 interpreter (aside perhaps from the Apple ][).
Maybe developers could produce a lowest-common-denominator (320x200, 16
colours) picture file from the high quality version.

[Any doubts about whether the player will be able to see things properly are
misplaced; after all, the graphics are just a frill aren't they? I hope nobody
is considering creating one of those lame point-and-click "adventures" where an
object in the picture may be 1 pixel in size.]


-- Mark

From ???@??? Sat Jun 21 20:09:02 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Sun, 08 Jun 1997 11:26:52 -0000
Message-Id: <yam7098.2645.4449304@smtp.netcomuk.co.uk>
In-Reply-To: <Pine.GSO.3.95.970607175457.27734E-100000@vax.area.com>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: multipart/mixed; boundary="--------geoboundary"

<x-html>

<HTML>
<BODY>
<CENTER>
<A HREF="http://www.geocities.com">Postage paid by: <IMG SRC="http://www.geocities.com/pictures/newgeobt.gif"></A></CENTER>
</BODY>
</HTML>
</x-html>

On 08-Jun-97, Matt Ackeret wrote:
>On Sat, 7 Jun 1997, Mark wrote:
>>Well, I think that any V6 game should be at least playable on a machine for
>>which there is already a V6 interpreter (aside perhaps from the Apple ][).

>Uhh, no.  This is my biggest point.  There are v6 interpreters for Apple
>IIs, and Apple IIs (especially the GS) are exactly what I want v6 games
>to continue to run on.
>--
>mattack@apple.com

Well okay. The only reason that I made the remark about the Apple ][ was that
the Infocom V6 games came on several (4?) disk sides, and it might be difficult
to get a plain .z6 file into this format. If it's not, and a utility to do this
already exists, let me know. There is probably no problem in running a V6 game
from a IIgs' hard disk, maybe with a non-Infocom interpreter.

Related to this: is there a utility for extracting .z6 files from Infocom V6
game disks?

-- Mark

From ???@??? Sat Jun 21 20:09:10 1997
Date: Sun, 8 Jun 1997 16:14:37 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706082014.QAA25079@wanda.vf.pond.com>
To: markk@netcomuk.co.uk, z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: multipart/mixed; boundary="--------geoboundary"



----------geoboundary
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



<HTML>
<BODY>
<CENTER>
<A HREF="http://www.geocities.com">Postage paid by: <IMG SRC="http://www.geocities.com/pictures/newgeobt.gif"></A></CENTER>
</BODY>
</HTML>

----------geoboundary



} Well okay. The only reason that I made the remark about the Apple ][ was that
} the Infocom V6 games came on several (4?) disk sides, and it might be difficult
} to get a plain .z6 file into this format. If it's not, and a utility to do this
} already exists, let me know. There is probably no problem in running a V6 game
} from a IIgs' hard disk, maybe with a non-Infocom interpreter.

The 4-disk format is a little bit strange, but at its heart it's just an
interleaving of a story file and a picture file.  If someone really
wants to write a V6 game for the old II interpreter, making such a
file wouldn't be impossible.  I've managed to run a derivative of
Andrew Plotkin's 'etude' on an Apple II interpreter, for instance.

} Related to this: is there a utility for extracting .z6 files from Infocom V6
} game disks?

Not that I know of.   I wrote a one-off thing to pull Zork Zero off.
There didn't seem to be much point in writing a general utility.

----------geoboundary--
From ???@??? Mon Jun 09 16:20:33 1997
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
Message-Id: <199706090259.MAA12700@yallara.cs.rmit.edu.au>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
To: z-machine@gmd.de
Date: Mon, 9 Jun 1997 12:59:38 +1000 (EST)
In-Reply-To: <199706061839.LAA21908@albatros.wco.com> from "Allpoxsmay Petrofsky" at Jun 6, 97 11:39:20 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: fde33c7dd5667a73c1beb19dee15be31

> 
> 
>    From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
> 
>    While we're on the subject of v6 pictures, is there any plans to limit the
>    picture opcodes to only version 6? I seem to recall a while ago a person
>    mentioning that it was a pitty we were using new version numbers to represent
>    doubling amount (ie. 7/8), since it meant that to allow a v6 style game with
>    double the memory, yet a new version number would need to be introduced.
> 
> I don't understand the problem.  V7 and V8 should just be viewed as
> V5.1 and V5.2.  They provide a minor enhancement to v5 (increased
> address space), and v6 provides many enhancements over them.  The only
> thing in v8 that's not in v6 is a slightly more convenient and less
> restrictive addressing system: they both have 512K max size, but v6
> additionally requires that packed strings and routines each fit in
> 256K (this is slightly ameliorated by v6's less restrictive alignment
> requirement: 4 bytes v. 8 bytes).  Do today's V8 games actually exceed
> this restriction?
> 
> It's quite likely I'm missing something here.
> 
> -al
> 

The trouble is, from what I now understand from a previous article, that the
z-machine has a great many differences between v5 and v6. Game machine versions
7, and then 8, were introduced to extended version 5's memory space. The
trouble with this is that now that it seems likely that practical games will
be compilable for version 6, that if the memory address runs out for v6, as
it did for v5, then it will be necessary to introduce yet another game version
number, say v9, to have a bigger v6 memory.

It was suggested that instead of staggering the game versions, that we keep
the versions as v5 or v6, and have a status word determining how big the
memory is.

So, for example, perhaps we could define a common .z10 format which has a 
status word which contains: 1) whether the game follows the v5 or v6 z-machine
schema, and 2) the memory size/mutliplication factor is.

Thus we could obviate the need for introducing more and more game versions as
we find the memory requirements increasing. Indeed, leave enough bits for
memory size, and the compiler could, theoretically, increase the memory
size transparently to handle bigger games without requiring an official new
game version.

Anyone want to add some comments to that?


-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Tue Jun 10 17:40:06 1997
From: olorin@world.std.com (Mark J Musante)
Message-Id: <199706091253.AA03409@world.std.com>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
To: uecasm@geocities.com (Gavin Lambert)
Date: Mon, 9 Jun 1997 08:53:00 -0400 (EDT)
Cc: pfg@yallara.cs.rmit.edu.au, z-machine@gmd.de
Reply-To: olorin@world.std.com (Mark J Musante), z-machine@gmd.de
In-Reply-To: <3.0.32.19970609162915.006af51c@pop.ihug.co.nz> from "Gavin Lambert" at Jun 9, 97 04:29:40 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: 26f57b6d5d3b688f997d6b865c624d20

> 
> At 12:59 09/06/97 +1000, Paul Francis Gilbert wrote:
> >It was suggested that instead of staggering the game versions, that we keep
> >the versions as v5 or v6, and have a status word determining how big the
> >memory is.
> >
> >So, for example, perhaps we could define a common .z10 format which has a 
> >status word which contains: 1) whether the game follows the v5 or v6
> z-machine
> >schema, and 2) the memory size/mutliplication factor is.
> [...]
> >Anyone want to add some comments to that?
> 
> Sounds like a good idea... but why z10? The version 9 slot is still
> available, isn't it?
> 
> It seems to me that a spot in the extensions table could be used for this..
> although somewhere in the header itself would be better.  Is there anywhere
> in the header available for two bytes (as should probably store the above
> information ok)?

While we're at it, can we add a "magic word" to the header? ...

 - Mark

From ???@??? Tue Jun 10 17:40:07 1997
Date: Mon, 9 Jun 1997 09:04:55 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: "J. Holder" <jholder@frii.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <Mutt.19970606153829.jholder@deimos.frii.com>
Message-Id: <Pine.SGI.3.96.970609090441.8983A-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: b2056218159cead8c7a26aedb12dde54

>Personally, I'm surprised this took so long to come up.  PNG images are not
>lossy, and in some cases can achieve compression as good as jpegs.  PNG
>is a free format.  PNG has easy to compile and link source, easier than
>JPEG IMHO.  Basically, I think PNG is the coolest image format since
>sliced bread.

  "Humble"? :)

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Tue Jun 10 17:40:09 1997
Date: Mon, 9 Jun 1997 09:34:04 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Bryan Scattergood <104312.2206@CompuServe.COM>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format
In-Reply-To: <970607071228_104312.2206_IHS43-1@CompuServe.COM>
Message-Id: <Pine.SGI.3.96.970609093029.8983I-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 503d3d9255593b631a04ed09f0b07ba5

>It is true that graphical games aren't going to work well on palmtops 
>until they have colour screens.  Any graphics added to games ought to 
>be 24-bit photo-quality (digitised photos could work well for some 
>games) which don't work well with less than 8-bit colour.

  Ah, one of my pet peeves... (I'm several hundred messages behind, so
someone could have said this already):
  I have no idea how rare this is, but apparantly fairly:  I enjoy both
action games and IF, for their own seperate qualities.  However, the
impressiveness of graphics and sounds in no way contribute to my opinion
of a game: some of the best games made used 16 colors (and some used 2!).
  Somebody has to mention that they absolutely despise games that they
can't play solely due to special effects, so...

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Tue Jun 10 17:40:10 1997
Date: Mon, 9 Jun 1997 09:43:54 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Mark <markk@netcomuk.co.uk>
Cc: Z-Machine list <z-machine@gmd.de>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
In-Reply-To: <yam7097.1593.3775680@smtp.netcomuk.co.uk>
Message-Id: <Pine.SGI.3.96.970609094133.8983J-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: bec75f0d6f934338d5eaff33d49ac106

>[Any doubts about whether the player will be able to see things properly are
>misplaced; after all, the graphics are just a frill aren't they? I hope nobody
>is considering creating one of those lame point-and-click "adventures" where an
>object in the picture may be 1 pixel in size.]

  The graphics are not, necessarily, just a frill.  It is possible to
create a graphical puzzle difficult to implement in text (I'm not, you
note, using the big I-word).  My favorite example is the lever puzzle from
shadowgate:  The correct sequence in which to move the levers was drawn in
a different room (there was a connection, a reason to look for clues in
that room - they branched from the same place, and were at the same phase
of the game) - on a staircase, in such a way as to appear to be random
breaks between rocks.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Wed Jun 11 17:02:34 1997
Date: Tue, 10 Jun 1997 00:15:36 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Consensus on picture format?
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.09-0609231536-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: c37cfff96a325412988e6ec203f8dbdb


It looks as if most people are broadly in favour of an agreed
"modern graphics format", i.e. that V6 interpreters not designed
simply and only to run old Infocom games could run from either

   (a) a directory of PNG files called p1, p2, p3, ...

or (b) some very simple collation of PNG files (consisting of
       a straightforward header plus the files glued end to end).

The principal objection to this seems to be that low-end machines
(e.g. the Apple II, or some palm-tops) won't be able to cope with
modern-style graphics -- personally I think this is a sad
inevitability, but not worth giving up the idea for.  I think it
would be something of a pointless martyrdom to restrict ourselves
to 8 colours, low-resolution and strangely formatted.

It seems to me that it ought to be legal to plot pictures with
finer resolution than the Z-machine model of pixels -- that is,
that a file could supply a 100x100 image which is supposed to
occupy a 50x50 pixel space in the Z-machine's notional screen:
interpreters could then display as they see fit.  The point of
this is not for diagrams, vital maps, etc., but for illustrations
and photos, where one simply wants "best possible resolution".
If people find this idea appealing, then the PNG files will
have to have "Z-size" data attached separately.  (This is similar
to the way colours are already handled: some V6 graphics files
already have more colours than the Z-machine theoretically
knows of.)

I also don't think there's yet any need to invent extensions to
V6: let's see how well we get on with the present one first.
  
There are probably more details to sort out.  Perhaps I could
suggest that Andrew Plotkin might like to pickle up some kind
of proper file format?  The idea ought to be to make it as easy
as humanly possible to let authors modify and play with pictures
in games under development.  At present it's almost impossible.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Tue Jun 10 17:40:12 1997
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
Message-Id: <199706092345.JAA26026@yallara.cs.rmit.edu.au>
Subject: Re: [z-machine] Modern V6 picture format, anyone?
To: z-machine@gmd.de
Date: Tue, 10 Jun 1997 09:45:07 +1000 (EST)
In-Reply-To: <3.0.32.19970609162915.006af51c@pop.ihug.co.nz> from "Gavin Lambert" at Jun 9, 97 04:29:40 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: 3f17d311ba567ef2bb8f7a0aa95917df

> 
> At 12:59 09/06/97 +1000, Paul Francis Gilbert wrote:
> >It was suggested that instead of staggering the game versions, that we keep
> >the versions as v5 or v6, and have a status word determining how big the
> >memory is.
> >
> >So, for example, perhaps we could define a common .z10 format which has a 
> >status word which contains: 1) whether the game follows the v5 or v6
> z-machine
> >schema, and 2) the memory size/mutliplication factor is.
> [...]
> >Anyone want to add some comments to that?
> 
> Sounds like a good idea... but why z10? The version 9 slot is still
> available, isn't it?
> 

Simply because it would be such a change from the current game machine version
numbering, that it wouldn't hurt to go up to 10. It's like how Microsoft went
from Word 2 straight to Word 6. A purely asthetic choice. It also deliniates
the fact that the version is not just yet another enlargement of the
multiplication factor for the v5 engine (ie. v7 and v8).

But there's certainly no reason why a .z9 (v9) insignia could be used.

> It seems to me that a spot in the extensions table could be used for this..
> although somewhere in the header itself would be better.  Is there anywhere
> in the header available for two bytes (as should probably store the above
> information ok)?
> 
> -----                                
>      _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
>     _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
>    _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
>   _/    _/  _/        _/        _/    _/        _/  _/        _/
>  _/    _/  _/        _/        _/    _/        _/  _/        _/
>  _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/
> 
> Gavin Lambert
> uecasm@geocities.com
> http://crash.ihug.co.nz/~brianc
> http://www.geocities.com/SiliconValley/Heights/1987
> 
> "We now return to our regularly scheduled flame-throwing."
> "PCMCIA:  People Can't Memorise Computer Industry Acronyms."
> "ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."
> 
> 


-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Sat Jun 21 20:09:44 1997
Date: Tue, 10 Jun 1997 09:47:36 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom4
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <Marcel-1.09-0609231536-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.970610093020.28115B-100000@netcom4>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: multipart/mixed; boundary="--------geoboundary"

<x-html>

<HTML>
<BODY>
<CENTER>
<A HREF="http://www.geocities.com">Postage paid by: <IMG SRC="http://www.geocities.com/pictures/newgeobt.gif"></A></CENTER>
</BODY>
</HTML>
</x-html>

On Tue, 10 Jun 1997, Graham Nelson wrote:

> 
> It looks as if most people are broadly in favour of an agreed
> "modern graphics format", i.e. that V6 interpreters not designed
> simply and only to run old Infocom games could run from either
> 
>    (a) a directory of PNG files called p1, p2, p3, ...
> 
> or (b) some very simple collation of PNG files (consisting of
>        a straightforward header plus the files glued end to end).
> 
> The principal objection to this seems to be that low-end machines
> (e.g. the Apple II, or some palm-tops) won't be able to cope with
> modern-style graphics -- personally I think this is a sad
> inevitability, but not worth giving up the idea for.  I think it
> would be something of a pointless martyrdom to restrict ourselves
> to 8 colours, low-resolution and strangely formatted.

And, to repeat myself agonizingly, we would certainly want a tool
that transforms a (b) archive into an Infocom-style directory of
Infocom-formatted images -- with probable loss of color and resolution. 
 
> It seems to me that it ought to be legal to plot pictures with
> finer resolution than the Z-machine model of pixels -- that is,
> that a file could supply a 100x100 image which is supposed to
> occupy a 50x50 pixel space in the Z-machine's notional screen:
> interpreters could then display as they see fit.  The point of
> this is not for diagrams, vital maps, etc., but for illustrations
> and photos, where one simply wants "best possible resolution".
> If people find this idea appealing, then the PNG files will
> have to have "Z-size" data attached separately. 

PNG is itself a chunk format, and it's possible to add extra information
like this to the image file directly. 

There is already an optional "pixel size" chunk defined for PNG. However,
the spec only defines two uses for it: to specify a pixel aspect ratio, or
to specify a physical pixel size in meters. Neither of these is exactly
what we want, although we could force the "Z-size" information in either
way. Forcing information into a format that wasn't designed for it is
rude. It would be better to define a private "Z-size" chunk, which
standard PNG viewers would properly ignore. 

> There are probably more details to sort out.  Perhaps I could
> suggest that Andrew Plotkin might like to pickle up some kind
> of proper file format?

I'm always willing to dictate standards. :) I still like IFF, because it's
what the save-file proposal is based on, and because it does almost
everything my pickle idea did (with the exception of multiple formats
per image, but we seem to have agreed that's a bad idea anyway.)

In particular, I would like to carry over a couple of ideas from PICKLE:
for example, that the IFF file can (optionally) contain the z-code file as
well as any number of PNG files. Plus any number of sound files, if the
game uses sound. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Tue Jun 17 16:13:39 1997
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
Date: Thu, 12 Jun 1997 17:34:04 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <19970612153243.AAA29521@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: fe2db811ec7af9732357d8ab83ca691f


Graham wrote:

> It seems to me that it ought to be legal to plot pictures with
> finer resolution than the Z-machine model of pixels -- that is,
> that a file could supply a 100x100 image which is supposed to
> occupy a 50x50 pixel space in the Z-machine's notional screen:
> interpreters could then display as they see fit.  The point of
> this is not for diagrams, vital maps, etc., but for illustrations
> and photos, where one simply wants "best possible resolution".
> If people find this idea appealing, then the PNG files will
> have to have "Z-size" data attached separately.  (This is similar
> to the way colours are already handled: some V6 graphics files
> already have more colours than the Z-machine theoretically
> knows of.)

I'm not quite sure if I understood the above correctly.

As I read it, we could have a 100x100 picture that has a Z-size of
50x50.  When such a picture is drawn, it must occupy 50x50 "pixels
in the Z-machine's notional screen".  If we suppose an interpreter
sets the screen format entries in the story file header to 640x400
then this picture would be quite small.  If we imagine another
interpreter that sets the screen format to 50x50 units, the same
picture would cover the entire game screen.  

I don't think this is what people want.

More likely, an author who has drawn a status bar picture wants to
make the picture as wide as the game screen, no matter what the
format of the Z-machine's notional screen or the actual game screen
size (measured in pixels) might be.  The author could say: "I have
drawn all my pictures for a standard resolution of 640x400 pixels.
Interpreters with different screen formats must scale the pictures
accordingly."  In this approach the quality of every picture drawn
depends on the minimum of the "standard resolution" and the actual
game screen format.  The standard resolution should be part of the
graphics file header; there may be alternative graphics files with
different standard resolutions.

> I also don't think there's yet any need to invent extensions to
> V6: let's see how well we get on with the present one first.

Agreed.

Besides, Inform seemingly depends on the ability to distinguish
Z-code routine addresses from "static" string addresses.  That's no
longer possible in V6/V7 since a string and a routine might have
the same packed address.  Any solutions, Graham?

> There are probably more details to sort out.  Perhaps I could
> suggest that Andrew Plotkin might like to pickle up some kind
> of proper file format?  The idea ought to be to make it as easy
> as humanly possible to let authors modify and play with pictures
> in games under development.  At present it's almost impossible.

One detail has to do with coulor palettes.

Pictures (and video modes) with 8 bits per pixels usually require
a colour palette of R-G-B values.  One problem is that at least a
few colours should be reserved for other purposes such as display
of text.  Another problem is that several pictures can be visible
at the same time.  An easy though restricitve solution would be a
global palette to be used for all pictures.  Any other proposals?


From ???@??? Tue Jun 17 16:13:41 1997
Date: Thu, 12 Jun 1997 11:55:50 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Stefan Jokisch <s.jokisch@avu.de>
Cc: --- Z-machine <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <19970612153243.AAA29521@jokisch>
Message-Id: <Pine.SGI.3.96.970612114716.2800B-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 1976d5943be3b270641de972560b91bd

>I'm not quite sure if I understood the above correctly.

  It doesn't look like you did.  The idea is to have a standard sreen
size, and for any larger screen, scaling occurs.  However, if a picture
has higher resolution, more detail would be visible on the larger screen.

  Thus the status bar picture could simply be the width of the notational
screen, and be automatically scaled to the physical screen.  If you want
to take advantage of higher screen resolution, you can simply provide more
data that shows up instead of blocky pixels.

  One potential difficulty arises, however:  one might wish to take
advantage of a larger physical screen to provide more area (probably not
for a location picture, but perhaps for a puzzle).  So there should be
some way to draw a picture to the screen, without scaling.
  One could get at the higher resolution by plotting to a fractional pixel
on the logical screen, but it would make more sense to have the option of
using either the physical or logical screens; the logical screen performs
scaling and the physical does not.  Or, perhaps, one could draw a picture
to a rectangle rather than a point - but I don't like this idea: it means
interpreters have to handle arbitrary scaling/stretching.

>> I also don't think there's yet any need to invent extensions to
>> V6: let's see how well we get on with the present one first.
>
>Agreed.

  Yes.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 21 20:09:50 1997
Date: Thu, 12 Jun 1997 10:04:45 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <19970612153243.AAA29521@jokisch>
Message-Id: <Pine.SUN.3.95.970612090723.22206B-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: multipart/mixed; boundary="--------geoboundary"

<x-html>

<HTML>
<BODY>
<CENTER>
<A HREF="http://www.geocities.com">Postage paid by: <IMG SRC="http://www.geocities.com/pictures/newgeobt.gif"></A></CENTER>
</BODY>
</HTML>
</x-html>

On Thu, 12 Jun 1997, Stefan Jokisch wrote:

> > It seems to me that it ought to be legal to plot pictures with
> > finer resolution than the Z-machine model of pixels -- that is,
> > that a file could supply a 100x100 image which is supposed to
> > occupy a 50x50 pixel space in the Z-machine's notional screen:
> > interpreters could then display as they see fit.
>
> I'm not quite sure if I understood the above correctly.
> 
> As I read it, we could have a 100x100 picture that has a Z-size of
> 50x50.  When such a picture is drawn, it must occupy 50x50 "pixels
> in the Z-machine's notional screen".  If we suppose an interpreter
> sets the screen format entries in the story file header to 640x400
> then this picture would be quite small.  If we imagine another
> interpreter that sets the screen format to 50x50 units, the same
> picture would cover the entire game screen.  
> 
> I don't think this is what people want.
> 
> More likely, an author who has drawn a status bar picture wants to
> make the picture as wide as the game screen, no matter what the
> format of the Z-machine's notional screen or the actual game screen
> size (measured in pixels) might be.  The author could say: "I have
> drawn all my pictures for a standard resolution of 640x400 pixels.
> Interpreters with different screen formats must scale the pictures
> accordingly."  In this approach the quality of every picture drawn
> depends on the minimum of the "standard resolution" and the actual
> game screen format.  The standard resolution should be part of the
> graphics file header; there may be alternative graphics files with
> different standard resolutions.

I think it's a big mistake to specify a resolution as part of the format.
What are the advantages of this, anyway? Interpreters are going to have to
draw different-size images, so it doesn't prevent mandatory rescaling
code.

What are the possible uses of V6 images? We've seen:

* "full-screen" illustrations, intended to fill the entire width of the
status window, but with different heights (in different games.)
* margin illustrations (the sidebar columns in Zork Zero), which are a
fixed width, and fixed height unless you want to allow window resizing,
which is a separate problem.
* small inset illustrations (the illuminated capital letters in Zork
Zero), which appear in-line with the text and may have to have a
particular size relative to the font size -- I don't know how they wrote
their margin-diddling code.
* patch images (double fanucci cards, pegglebox pegs, map icons,
open-closed flowers, animal shapes on the rebus), which appear over top of
another image to change part of it. These can be any size.

The simplest approach is to assume a fixed pixel size, 72 pixels per inch,
and create all your images based on that. The interpreter displays all
images at one image pixel per screen pixel, and the font and window
arrangement had better be about what the author expected.

A fancier interpreter may be able to display more resolution (both of
fonts and images) than 72 per inch. It would want to use larger windows,
larger fonts, and a higher-resolution picture. What would this interpreter
declare its z-pixel resolution to be? Er, I don't know. I think I need to
re-read the spec a lot more. 

What can a modern V6 interpreter *do*? Take advantage of a higher
resolution, as described above? Allow a larger window (the way modern V5/8
interpreters can, with more text visible?) Allow a window which is taller
but narrower? I think these questions have to be answered now. 
 
> One detail has to do with coulor palettes.
> 
> Pictures (and video modes) with 8 bits per pixels usually require
> a colour palette of R-G-B values.  One problem is that at least a
> few colours should be reserved for other purposes such as display
> of text.  Another problem is that several pictures can be visible
> at the same time.  An easy though restricitve solution would be a
> global palette to be used for all pictures.  Any other proposals?
 
Yes. Allow any kind of image -- monochrome, any 8-bit color palette, or
15- or 24-bit direct color. (Different games are certainly going to want
different color schemes, to suit mood.) Leave the interpreter to reassign
or dither colors depending on its needs. 

It might be useful to allow a color palette to be stored in the archive,
purely as a hint about what colors the game images will require. If an
interpreter knows it will be displaying on an 8-bit screen, it can load
this palette at game startup and change the video table to contain those
colors. (Not necessarily 256 colors; the palette could contain anywhere
from 1 to 256 entries.) However, this is (1) optional and (2) not binding.
An interpreter should be able to handle any valid PNG image at any time.

The flip side is that it doesn't have to be able to handle them *well*. If
the author doesn't provide a palette, he must expect that players with
8-bit screens will see his images flattened to a standard palette. (Mac
and Windows each have slightly different standard 8-bit palettes. Other
machines presumably vary as well.)  

If he provides a 256-color palette, it's up to the interpreter whether the
game gets all 256 colors and approximates standard text colors using
palette colors, or knocks a few holes in the palette (for text colors) and
approximates the game images to that. The palette is, after all, only a
hint. 

Contrariwise, if the game author provides a 240-color palette, he can
assume that he'll get those colors on any 8-bit machine. I still don't
want to say that this is *required* interpreter behavior; for example, an
interpreter written in Java using AWT may not be able to influence the
color table at all. (I think.) But this is sort of the minimum desirable
level of ability. 

How does this sound to ye supporters of V6 interpreters?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Tue Jun 17 16:13:54 1997
X-Sender: mattack@mail.apple.com
Message-Id: <v01550101afc5ebbde423@[17.202.20.138]>
Mime-Version: 1.0
Date: Thu, 12 Jun 1997 11:15:59 -0700
To: z-machine@gmd.de
From: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] Consensus on picture format?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"
X-UIDL: 642a148323fa48709b9f8feeb8ab7675

Umm, why are you guys trying to "cram" something into the Zmachine format
that wasn't there to begin with anyhow?

The "simple" improvements like doubling certain memory sizes and such were
easy and made sense.

But this kind of trying to do way high resolution graphics seems to be
getting out of the scope of Zmachine stuff, especially if nobody really
wants to even try to make it support every machine that Zmachine currently
runs on. (NO THAT'S NOT MY MAIN POINT for this message.)

It just seems like you guys are trying to fit a square peg in a round hole...

Why not invent a *new* virtual machine if Inform doesn't do what you want?

You could even make the source code a superset of Inform if you want it to,
or even exactly the same.

I would *hope* that such a new virtual machine had a "generic" interpreter
available in ANSI C so it was about as portable as the current Zmachine
interpreters..

--
mattack@apple.com



From ???@??? Tue Jun 17 16:13:56 1997
Date: Thu, 12 Jun 1997 15:33:02 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706121933.PAA04598@wanda.vf.pond.com>
To: mattack@apple.com, z-machine@gmd.de
Subject: Re: [z-machine] Consensus on picture format?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: f8e1d202baa51c8e076b762ff29cbae6

} Why not invent a *new* virtual machine if Inform doesn't do what you want?

} You could even make the source code a superset of Inform if you want it to,
} or even exactly the same.

} I would *hope* that such a new virtual machine had a "generic" interpreter
} available in ANSI C so it was about as portable as the current Zmachine
} interpreters..

Heh heh... 
> OPEN CAN OF WORMS
Opened.

> CLOSE CAN OF WORMS
Not likely.

OK, let's see, what features do we want to build in?  

1) 32 bit unified address space
2) Unicode support (I suggest strings in the Java variant of UTF-8,
possibly Huffman-compressed.  No funny Z-strings, we're just not
that constrained anymore)
3) Unlimited # of attributes (would actually be a fairly simple
extension to the current machine)
4) Similarly unlimited # of properties, to take the load off the compiler.
5) Flexible windowing system.
6) Perhaps more conventional (stack-based) calling conventions and
local variables?
7) Dynamic object creation
8) Graphics.

The Java virtual machine is tempting, but unfortunately has a few
serious problems for implementation of the current IF programming
style

1) No function-pointer support
2) Much too type-restrictive.
3) How do you handle SAVE?

From ???@??? Tue Jun 17 16:13:57 1997
Date: Thu, 12 Jun 1997 16:21:14 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Matt Ackeret <mattack@apple.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <v01550101afc5ebbde423@[17.202.20.138]>
Message-Id: <Pine.SGI.3.96.970612161810.13823C-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 4ae359fd043009a9647d09ba02baecff

>It just seems like you guys are trying to fit a square peg in a round hole...
>
>Why not invent a *new* virtual machine if Inform doesn't do what you want?
>
>You could even make the source code a superset of Inform if you want it to,
>or even exactly the same.

  Although there would be a lot of effort involved, the main objection I
can raise is that the existing z-machine is quite adequate, and extremely
good at doing what it does.  Why complicate the IF scene unnecessarily?  
Besides, this list is only for the z-machine :-).

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Tue Jun 17 16:13:59 1997
Date: Thu, 12 Jun 1997 16:28:15 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: "Matthew T. Russotto" <russotto@pond.com>
Cc: mattack@apple.com, z-machine@gmd.de
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <199706121933.PAA04598@wanda.vf.pond.com>
Message-Id: <Pine.SGI.3.96.970612162503.13823D-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 4a14fd4f7346ddcbf7af69068c3f8fc0

>1) 32 bit unified address space
  No.
>2) Unicode support (I suggest strings in the Java variant of UTF-8,
>possibly Huffman-compressed.  No funny Z-strings, we're just not
>that constrained anymore)
  God, no.
>3) Unlimited # of attributes (would actually be a fairly simple
>extension to the current machine)
  Weell...
>4) Similarly unlimited # of properties, to take the load off the compiler.
  Yah.
>5) Flexible windowing system.
  ABSOLUTELY NOT.
>6) Perhaps more conventional (stack-based) calling conventions and
>local variables?
  P'raps.  P'raps not.  No real need.
>7) Dynamic object creation
  Yes, absolutely.
>8) Graphics.
  (with a sigh) - yes.

  I'd go into more detail if I had time.  Remember, the original z-machine
had *upper* constraints, too, and for good reason.

>The Java virtual machine is tempting, but unfortunately has a few
>serious problems for implementation of the current IF programming
>style

>1) No function-pointer support
>2) Much too type-restrictive.
>3) How do you handle SAVE?

4) Doesn't run on machines older than 1-2 years.  I probably wouldn't
grouse about this if my machine were a bit newer :).  Nonetheless, it's
not much of a "universal" machine if you cut out such systems.


____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Tue Jun 17 16:14:00 1997
Message-Id: <33A069B0.71E6CB74@micron.net>
Date: Thu, 12 Jun 1997 15:27:12 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.0b5C (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: "Matthew T. Russotto" <russotto@pond.com>, z-machine@gmd.de
Subject: Re: [z-machine] Consensus on picture format?
X-Priority: 3 (Normal)
References: <199706121933.PAA04598@wanda.vf.pond.com>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: a939017e5817560ae900dccec8180ad1

Matthew T. Russotto wrote:
> OK, let's see, what features do we want to build in?
> 
[snip]

These all sound good to me.

> 
> The Java virtual machine is tempting, but unfortunately has a few
> serious problems for implementation of the current IF programming
> style
> 
> 1) No function-pointer support

Could we live without it?

> 2) Much too type-restrictive.

There are ways around that, but I can see how that would be a problem.

> 3) How do you handle SAVE?

Object serialization? :)

--Galen

From ???@??? Tue Jun 17 16:14:01 1997
From: King Dale <KingD@rnd1.indy.tce.com>
To: "Matthew T. Russotto" <russotto@pond.com>,
        "z-machine@gmd.de" <z-machine@gmd.de>,
        Galen Hazelwood <galenh@micron.net>
Subject: RE: [z-machine] Consensus on picture format?
Date: Thu, 12 Jun 97 17:07:00 CST
Message-Id: <33A0816F@MSMAIL.INDY.TCE.COM>
Encoding: 50 TEXT
X-Mailer: Microsoft Mail V3.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 5f8526229b4c22a014c7a1a3943fd2f9




 ----------
From:  Galen Hazelwood[SMTP:galenh@micron.net]
Sent:  Thursday, June 12, 1997 4:27 PM
To:  Matthew T. Russotto; z-machine@gmd.de
Subject:  Re: [z-machine] Consensus on picture format?

Matthew T. Russotto wrote:
> OK, let's see, what features do we want to build in?
>
[snip]

These all sound good to me.

>
> The Java virtual machine is tempting, but unfortunately has a few
> serious problems for implementation of the current IF programming
> style
>
> 1) No function-pointer support

Could we live without it?

Yes, you can definitely live without it. I created a Java Z-Machine   
interpreter and never needed it. Interfaces and classes work just fine   
for this kind of thing.

> 2) Much too type-restrictive.

There are ways around that, but I can see how that would be a problem.

I don't see the point here. Type-restrictive in what way? The only   
restriction I know is that there is no unsigned numeric type (except for   
char), which makes life simpler. It also puts some much needed   
restrictions like an int is always 32 bits.

> 3) How do you handle SAVE?

Object serialization? :)

Gee, maybe just good old plain I/O streams? I was implementing QUETZAL   
save files in Java with no problem.

 --Galen

I fail to see these serious problems you are talking about. Having   
programmed in Java for 9 months now, I find that anything you can do in   
C/C++ you can do easier, cleaner, faster, and more readably in Java.

From ???@??? Sat Jun 21 20:10:01 1997
Date: Thu, 12 Jun 1997 22:11:35 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706130211.WAA00567@wanda.vf.pond.com>
To: galenh@micron.net, russotto@pond.com, z-machine@gmd.de
Subject: Re: [z-machine] Consensus on picture format?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: multipart/mixed; boundary="--------geoboundary"



----------geoboundary
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



<HTML>
<BODY>
<CENTER>
<A HREF="http://www.geocities.com">Postage paid by: <IMG SRC="http://www.geocities.com/pictures/newgeobt.gif"></A></CENTER>
</BODY>
</HTML>

----------geoboundary



} > The Java virtual machine is tempting, but unfortunately has a few
} > serious problems for implementation of the current IF programming
} > style
} > 
} > 1) No function-pointer support

} Could we live without it?

Not without a serious paradigm shift, or some very, very, ugly hacks.

} > 2) Much too type-restrictive.

} There are ways around that, but I can see how that would be a problem.
Yep, it would be possible to write an Inform-style system without
being cavalier with the types.


} > 3) How do you handle SAVE?
}
} Object serialization? :)

Yes, actually, that would probably underlie any method used.  But I
think problem 1) rules the JVM out anyway.

----------geoboundary--
From ???@??? Tue Jun 17 16:14:05 1997
Date: Fri, 13 Jun 1997 09:05:27 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <199706130211.WAA00567@wanda.vf.pond.com>
Message-Id: <Pine.SUN.3.95.970613085356.13420B-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 6a10c3ca20568ceeee323b6e32212a8b

I think this little subthread is founded on a false statement. 

The Z-machine *was* intended to allow varying resolutions in its
V6 pictures.

It was intended to allow damn near *anything* in its V6 pictures. The only
restriction is that the picture must have a definite horizontal and
vertical size, and the interpreter must be able to draw it. 

Now can we at least not abandon the original discussion? I think it would
be useful to know:

1) Do existing Infocom V6 games require a particular screen size? (Screen
size in Z-pixels, I mean. That is, as given by the interpreter in the
header.) If so, what is this screen size?
2) If so, should we assume that V6 requires that screen size?
3) If yes on 1) but no on 2), should we assume that every individual V6
game will require a particular (different) screen size, determined by the
author?
4) What are the possibilities for font size, as measured in z-pixels? Do
existing Infocom games break if the font size is not what the author
expected? (I'm particularly thinking of Zork Zero, which wraps text around
left-justified images.)

If we know these, the situation of physical pixel size versus z-machine
pixel size will be a lot clearer.

Also, for authors and porters of existing V6 interpreters:

1) What do you think of what I suggested about color palettes?
2) Do you plan to actually write code to support this proposal if we agree
on it?

--Z ("grn")

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Tue Jun 17 16:14:07 1997
Date: Fri, 13 Jun 1997 12:20:31 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Andrew Plotkin <erkyrath@netcom.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <Pine.SUN.3.95.970613085356.13420B-100000@netcom>
Message-Id: <Pine.SGI.3.96.970613121937.28613N-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: a0a0edb94ac9126dcf0261d8455a508d

>1) Do existing Infocom V6 games require a particular screen size? (Screen
>size in Z-pixels, I mean. That is, as given by the interpreter in the
>header.) If so, what is this screen size?
>2) If so, should we assume that V6 requires that screen size?
  Yes.
>3) If yes on 1) but no on 2), should we assume that every individual V6
>game will require a particular (different) screen size, determined by the
>author?
  Yes.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Tue Jun 17 16:14:08 1997
Date: Fri, 13 Jun 1997 10:26:45 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <Pine.SGI.3.96.970613121937.28613N-100000@davinci.bergen.org>
Message-Id: <Pine.SUN.3.95.970613102530.172A-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 141b6be6b96aa9e5a2c83d8509847374

On Fri, 13 Jun 1997, A.K.A. TheWiz wrote:

> >1) Do existing Infocom V6 games require a particular screen size? (Screen
> >size in Z-pixels, I mean. That is, as given by the interpreter in the
> >header.) If so, what is this screen size?
> >2) If so, should we assume that V6 requires that screen size?

>   Yes.

> >3) If yes on 1) but no on 2), should we assume that every individual V6
> >game will require a particular (different) screen size, determined by the
> >author?

>   Yes.

Thanks for the response, but you contradicted yourself... 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Tue Jun 17 16:14:09 1997
Date: Fri, 13 Jun 1997 14:19:33 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706131819.OAA13793@wanda.vf.pond.com>
To: erkyrath@netcom.com, z-machine@gmd.de
Subject: Re: [z-machine] Consensus on picture format?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c699494515453be25d17b021c1b2041c

} Now can we at least not abandon the original discussion? I think it would
} be useful to know:

} 1) Do existing Infocom V6 games require a particular screen size? (Screen
} size in Z-pixels, I mean. That is, as given by the interpreter in the
} header.) If so, what is this screen size?

My experience messing with the Mac games is that they do -- changing
the screen size caused problems.  Others have reported that this isn't
the case -- could be a mistake I made, could be that PC games had to
deal with more resolutions and thus worked better.  IIRC, the Mac
games were 640*400 in color and 320*200 in B&W.  The color images were
actually stored at 1/4 size and scaled up -- if I'd modified my
interpreter to not scale up the color pictures and not report them
scaled up, they'd probably have worked at 320*200 also.  

2) If so, should we assume that V6 requires that screen size?

No.

3) If yes on 1) but no on 2), should we assume that every individual V6
game will require a particular (different) screen size, determined by the
author?

I'd expect games would require a minimum screen size.  Ideally that
wouldn't be a required size -- the game would take advantage of bigger
screens if possible.  

} 4) What are the possibilities for font size, as measured in z-pixels? Do
} existing Infocom games break if the font size is not what the author
} expected? (I'm particularly thinking of Zork Zero, which wraps text around
} left-justified images.)

No, they don't break, though the display might not be optimal.  If you
choose a font that has a height not divisible by the little picture
sizes, you get ugly results.

From ???@??? Sat Jun 21 20:10:08 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Fri, 13 Jun 1997 19:01:57 -0000
Message-Id: <yam7103.2854.4538800@smtp.netcomuk.co.uk>
In-Reply-To: <Pine.SGI.3.96.970613121937.28613N-100000@davinci.bergen.org>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] Consensus on picture format?
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: multipart/mixed; boundary="--------geoboundary"

<x-html>

<HTML>
<BODY>
<CENTER>
<A HREF="http://www.geocities.com">Postage paid by: <IMG SRC="http://www.geocities.com/pictures/newgeobt.gif"></A></CENTER>
</BODY>
</HTML>
</x-html>

On 13-Jun-97, A.K.A. TheWiz wrote:
>>1) Do existing Infocom V6 games require a particular screen size? (Screen
>>size in Z-pixels, I mean. That is, as given by the interpreter in the
>>header.) If so, what is this screen size?
>>2) If so, should we assume that V6 requires that screen size?
>  Yes.

The Infocom V6 story files DO NOT rely on a particular screen size. To
demonstrate this, you can try running Journey or Shogun on a non-standard
screen size. For example, let's use a size of 724x566, with fonts 11 pixels
high. The status bar, border graphics and picture at the beginning of Shogun
appear where they should. The hint border appears mostly where it should. (The
top right corner does not; this is probably because Infocom did not fully test
their story files on non-standard screen sizes.)

All the borders between different screen areas in Journey are scaled
appropriately.

It is up to the interpreter to scale graphics appropriately. E.g. in this
instance, a 320x200 pixel picture might be scaled to 640x400 screen pixels.
(Infocom's V6 games used picture files for a resolution of 320x200. Their
interpreter typically doubled the width for display on a 640x200 screen.)


>>3) If yes on 1) but no on 2), should we assume that every individual V6
>>game will require a particular (different) screen size, determined by the
>>author?
>  Yes.

No. The z-code program should check the screen dimensions and adjust
accordingly.


-- Mark

From ???@??? Tue Jun 17 16:14:13 1997
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
Date: Fri, 13 Jun 1997 21:44:10 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <19970614094153.AAA7560@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: 0939ffd9a15dfc29b178d1e9d0afd60a


A.K.A. TheWiz wrote (in response to my remark that I possibly 
didn't understand Graham correctly):

>   It doesn't look like you did.  The idea is to have a
> standard sreen size, and for any larger screen, scaling occurs.
> However, if a picture has higher resolution, more detail would
> be visible on the larger screen.
 
*sigh*

It's still not clear to me.  Standard screen size and scaling
for larger (or smaller) screens is basically what I proposed.
I think you propose individual standard screen sizes for each
picture, for example a game could use

- a drawn picture (A) of size 100x100 laid out for 640x400
- a hi-res photo (B) of size 150x200 laid out for 1280x800

Imagine

- an interpreter (1) that uses a game screen of 640x200 pixels
- an interpreter (2) that uses a game screen of 1280x800 pixels

This leads to the following picture sizes on the screen:

     |   (A)     (B)
-----+-----------------
 (1) | 100x 50  75x 50
 (2) | 200x200 150x200 

Question: Is this what Graham was talking about? If so, what
would the Z-size of pictures (A) and (B) be?  Let's assume I
got this right and let's take a closer look at the example.
We can replace picture (A) with a visually identical picture
(A*) and get

- a drawn picture (A*) of size 200x200 laid out for 1280x800
- a hi-res photo (B) of size 150x200 laid out for 1280x800

which leads us to a global standard resolution that is valid
for both pictures.  This is what I proposed in my previous
mail.  Apparently, my picture (A*) requires more disk storage
than picture (A), but the compression of the PNG format helps
to reduce the redundancy.

Frankly, I prefer my own proposal because it is simpler and
easier to handle for both the game author and the interpreter
writer.  My major objection to individual standard resolutions
is that we would have to store additional information for each
picture.  Andrew Plotkin wrote on this subject:

>PNG is itself a chunk format, and it's possible to add extra
>information like this to the image file directly. 

This means that every time the game author saves a picture he
would have to run an utility program to attach this extra
information to the image file.  This sounds *extremely*
inconvenient.  We shouldn't extend the PNG format in any way.

BTW, A.K.A. TheWiz proposed pictures with absolute (non-scalable)
size, but I don't think this is really useful.  First, this would
introduce picture-specific data (inconvenience!); second, a
picture with absolute size could turn out to be too small on a
high-end machine.


From ???@??? Tue Jun 17 16:14:11 1997
Date: Fri, 13 Jun 1997 15:49:21 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Andrew Plotkin <erkyrath@netcom.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <Pine.SUN.3.95.970613102530.172A-100000@netcom>
Message-Id: <Pine.SGI.3.96.970613154642.10495A-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: ad2e0b1cf6d4a9f7dc5260e5157d16a8

>> >1) Do existing Infocom V6 games require a particular screen size? (Screen
>> >size in Z-pixels, I mean. That is, as given by the interpreter in the
>> >header.) If so, what is this screen size?
>> >2) If so, should we assume that V6 requires that screen size?
>
>> >3) If yes on 1) but no on 2), should we assume that every individual V6
>> >game will require a particular (different) screen size, determined by the
>> >author?
>
>Thanks for the response, but you contradicted yourself... 

  I read it as "If we decide that V6 does not require a certain screen
zise, should we assume each game will need a different size?" - that is, I
think if all existing games use one size, we should assume it's required,
but if we decide not to do so, 3) is the logical choice.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 21 16:37:04 1997
Date: Wed, 18 Jun 1997 19:42:52 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <19970614094153.AAA7560@jokisch>
Message-Id: <Pine.SUN.3.95.970618193036.21028A-100000@netcom20>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 2d9663c74f010ca1655c2cd3577e177d

On Fri, 13 Jun 1997, Stefan Jokisch wrote:

> My major objection to individual standard resolutions
> is that we would have to store additional information for each
> picture.  Andrew Plotkin wrote on this subject:
> 
> >PNG is itself a chunk format, and it's possible to add extra
> >information like this to the image file directly. 
> 
> This means that every time the game author saves a picture he
> would have to run an utility program to attach this extra
> information to the image file.  This sounds *extremely*
> inconvenient.  We shouldn't extend the PNG format in any way.

This is a very good point.

> BTW, A.K.A. TheWiz proposed pictures with absolute (non-scalable)
> size, but I don't think this is really useful.  First, this would
> introduce picture-specific data (inconvenience!); second, a
> picture with absolute size could turn out to be too small on a
> high-end machine.

At this point, I'm thinking this is too much of a pain. One image pixel
per z-pixel is a nice easy decision. If the interpreter wishes to scale
things up, and display two screen pixels per z-pixel, then it can scale
the images to match. If not, it will have one screen pixel per z-pixel and
one screen pixel per image pixel, which should be easy for everybody.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 21 16:37:05 1997
Date: Wed, 18 Jun 1997 22:15:25 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom22
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Resource Format Proposal
Message-Id: <Pine.SUN.3.95.970618220212.22682A-100000@netcom22>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 3d2e4c9f84db28bcc2c2c3add21b4eb8

At Graham's kind invitation, I've thrown together a proposal which sums up
what's been discussed here in terms of image formats. As interpreted by
me, of course. :-) I'm calling it a resource format, rather than an image
format, because it can contain sounds and z-code too. 

Now you deluge me with comments. 

--Z

------------
Z-Machine Resource Collection Format Standard
Version 0.5
Andrew Plotkin (erkyrath@netcom.com)

This is a formal proposal for a common format for storing resources
associated with a Z-code file. Resources are data which the Z-machine
can invoke, such as sounds (in the Z-machine versions 3 and up) and
pictures (in the V6 Z-machine.) Future versions of the Z-machine may
understand other kinds of resources.

In addition, a Z-code file may itself be a resource in a resource
file. This is a convenient way to package a Z-code game and all its
resources together in one file.

[Text in this document is liberally stolen from Martin Frost
<mdf@doc.ic.ac.uk>'s proposal for a common save file format. Ideas are
liberally stolen from my own PICKLE format proposal, which is now
withdrawn in favor of this proposal.]

The only suggestion I have seen for the common save file format is
"GNUSTO". If that is adopted, the only acceptable choice for the name
of this resource collection format is "BLORB".

* Overall Structure

The overall format will be a new IFF type. The FORM type is 'IFRS'.

The first chunk in the FORM must be a resource index (chunk type
'RIdx'.) This lists all the resources stored in the IFRS FORM.

The resources are stored in the FORM as chunks; each resource is one
chunk. They do not need to be in any particular order, since the
resource index contains all the information necessary to find a
particular resource.

Several chunks may also appear by convention in any IFF FORM: '(c) ',
'AUTH', and 'ANNO'. These chunks should appear after the resource
index and all the resource chunks.

* Contents of the Resource Index Chunk

    4 bytes         'RIdx'          chunk ID
    4 bytes         n               chunk length (4 + num*12)
    4 bytes         num             number of resources
    num*12 bytes    ...             index entries

There is one index entry for each resource. Each index entry is 12
bytes long:

    4 bytes         usage           resource usage
    4 bytes         number          number of resource
    4 bytes         start           starting position of resource

The index entries should be in the same order as the resource chunks
in the file.

The usage field tells what kind of resource is being described. This
must be one of three values:
    'Pict': Picture resource (to be used by the @draw_picture opcode,
etc)
    'Snd ': Sound resource (to be used by the @sound_effect opcode,
etc)
    'Exec': Z-code resource (to be loaded and executed by the
interpreter.)

The number field tells which resource is being described, from the
game's point of view. For example, when the game calls @draw_picture
with an argument of 3, the interpreter would find the index entry
whose usage is 'Pict' and whose number is 3. For Z-code chunks
(usage 'Exec'), the number should contain 0.

The start field tells where the resource chunk begins. This value is
an offset, in bytes, from the start of the IFRS FORM (that is, from
the start of the file.)

* Picture Resource Chunks

Each picture is stored as one chunk, whose content is a PNG file. The
chunk type is 'PNG '. The PNG file format is available at

http://www.boutell.com/boutell/png/

The V6 Z-machine has the capacity to draw pictures, and determine the
size of pictures. When doing the latter (the @picture_data opcode),
the size which is reported to the game should be exactly the size of
the PNG data in pixels.

* Sound Resource Chunks

Each sound is stored as one chunk. The sound file format and chunk
type is to be determined later.

* Executable Resource Chunks

There should at most one chunk with usage 'Exec'. If present, its
number must be zero; its content is a Z-code game file, and its chunk
type is 'ZCOD'.

A resource file which contains a Z-code chunk contains everything
needed to run the Z-code. An interpreter can begin interpreting when
handed such a resource file; it sees that there is a Z-code chunk,
loads it, and runs it.

A resource file which does not contain a Z-code chunk can only be used
in tandem with a Z-code file. The interpreter must be handed both the
resource file and the Z-code file in order to begin interpreting.

If an interpreter is handed inconsistent arguments -- that is, a
resource file with no Z-code chunk, or a resource file with a Z-code
chunk plus a Z-code file -- it should complain righteously to the
user.

* The IFF Format

A description of the IFF format can be found at

http://www.cica.indiana.edu/graphics/image_specs/ilbm.format.txt

In the interests of simplicity, this proposal does not use IFF LISTs
or CATs, even though its purpose is to contain concatenated lists of
data. Therefore, the format can be quickly described as follows:

    4 bytes         'FORM'          Magic number indicating IFF
    4 bytes         n               FORM length (file length - 8)
    4 bytes         'IFRS'          FORM type
    n-4 bytes       ...             The chunks, concatenated

Each chunk has the following format:

    4 bytes         id              Chunk type
    4 bytes         m               Chunk length
    m bytes         ...             Chunk data

If a chunk has an odd length, it *must* be followed by a single
padding byte whose value is zero. (This padding byte is not included
in the chunk length m.) This allows all chunks to be aligned on even
byte boundaries.

All numbers are four-byte unsigned integers, stored big-endian
(most significant byte first.) Character constants such as 'FORM'
are stored as four ASCII bytes, in order from left to right.

When reading an IFF file, a program should always ignore any chunk
it doesn't understand.

* Other Resource Arrangements

It may be convenient for an interpreter to be able to access resources
in formats other than a resource file. In particular, when developing
a game, an author will want to load images and sounds from individual
files, rather than having to re-package all the resources whenever any
one of them changes.

Such resource arrangements are platform-specific, and the details are
left to the interpreter. However, one suggestion is to have a single
directory which contains all the resources as files, with one file per
resource. (PNG files for images, and so on.) Files would be named
something like "PIC1", "PIC2"..., "SND1", "SND2"..., and so on.
(Naturally, file suffixes would be added in platforms that require
them.) The interpreter would be started up and handed the entire
directory as an argument; or possibly the directory along with a
separate Z-code file.

* Rationales and Rationalizations

- Why have a common resource collection format?

Infocom chose not to standardize their resource formats; they had a
different picture format for each platform. This was a reasonable
choice for them, since they were writing all the games, all the art,
and all the interpreters. They therefore had the capacity to translate
the art into platform-specific formats for all the platforms they
supported.

In the modern age, an IF author does not have access to all the
platforms his game will be played on. It is therefore reasonable to
distribute art in a single format, and leave interpreter writers the
job of supporting that format.

- Why is there a "number" field in the entries in the resource index
chunk? Why not just assume chunks are numbered consecutively?

Pictures are not necessarily numbered contiguously (Z-Spec 8.8.6.1.)
Sounds are numbered consecutively, but sounds 1 and 2 are bleeps, so
the game-specific sound resources start at 3. (Z-Spec 9.2.) Rather
than jigger the numbering or require place-holder chunks, I decided
there should be an index which maps resource numbers to chunks.

- Why does the "usage" field in the resource index entries contain,
for example, 'Pict' instead of 'PNG '? The proposal requires that all
pictures be PNG files.

Why not? We may go insane someday and support more image formats.
There's no reason to complicate the lives of mentally ill individuals
by making them change the resource format as well.

- Why PNG?

The format is not burdened with patent restrictions; it is free; it's
not lossy; and it can efficiently store many types of images, from
1-bit (monochrome) images up to 48-bit color images. In contrast, GIF
is owned by twits who restrict its use; JPEG is lossy and not optimal
for images other than photographs. TIFF has been suggested, but hey,
you gotta pick something.

- Why not compress data as well as archiving it? Why just concatenate
everything together as chunks?

Any reasonable sound or image format already incorporates compression.

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

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 21 16:37:08 1997
Date: Thu, 19 Jun 1997 08:54:05 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Consensus on picture format?
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.SUN.3.95.970618193036.21028A-100000@netcom20>
Message-Id: <Marcel-1.09-0619075405-b49M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: c760dcc20f2147a7da57d5707554819a

On Thu 19 Jun, Andrew Plotkin wrote:
>
> At this point, I'm thinking this is too much of a pain. One image pixel
> per z-pixel is a nice easy decision. If the interpreter wishes to scale
> things up, and display two screen pixels per z-pixel, then it can scale
> the images to match. If not, it will have one screen pixel per z-pixel and
> one screen pixel per image pixel, which should be easy for everybody.

I'm all for nice easy decisions.  But what happens if I want a
detailed photograph to occupy half the screen?  I am unable to
arrange this, as I understand it.  If I give a detailed image,
it could easily dwarf the rest of the screen content.  If I don't,
it could look annoyingly grainy even though the interpreter's
machine is capable of much better-looking graphics.

I suppose one option is to include -- in the header of the graphics
file -- a "preferred screen size" in Z-pixels, e.g. 640 x 512.
Would this be an acceptable compromise?

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Jun 21 16:37:10 1997
Date: Thu, 19 Jun 1997 08:12:01 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Graham Nelson <graham@gnelson.demon.co.uk>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture format?
In-Reply-To: <Marcel-1.09-0619075405-b49M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SGI.3.96.970619080239.29849M-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 267e194ac96cfdb9c5cedabcd33ce54a

>I'm all for nice easy decisions.  But what happens if I want a
>detailed photograph to occupy half the screen?  I am unable to
>arrange this, as I understand it.  If I give a detailed image,
>it could easily dwarf the rest of the screen content.  If I don't,
>it could look annoyingly grainy even though the interpreter's
>machine is capable of much better-looking graphics.
>
>I suppose one option is to include -- in the header of the graphics
>file -- a "preferred screen size" in Z-pixels, e.g. 640 x 512.
>Would this be an acceptable compromise?

  No, I think if the interpreter can display more area, it should:
1)  Auto-scale to take advantage of it.
2)  Let programmers draw things "regular size" to take advantage of the
  larger area.

  Also, I suppose there are uses for arbitrary scaling (or at least
scaling to multiples of powers of two?) - so, as the interpreters will
have to handle scaling anyway (assuming they take advantage of large
monitors), why not?  (Braces for avalanche)

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 21 16:37:12 1997
Date: Thu, 19 Jun 1997 10:20:27 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: [z-machine] IFF format?
Message-Id: <Pine.SGI.3.96.970619101945.7060B-100000@davinci.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 6dfcfce92d1d7ca2bc2c50e073613720


  I have tried (and failed) to find information about the IFF format.  Can
somebody enlighten me?

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Jun 21 16:37:13 1997
From: Stephen van Egmond <svanegmo@truespectra.com>
Message-Id: <199706191509.LAA30943@plymouth.truespectra.com>
Subject: Re: [z-machine] IFF format?
To: zmachine@gmd.de
Date: Thu, 19 Jun 1997 11:08:09 -0400 (EDT)
In-Reply-To: <Pine.SGI.3.96.970619101945.7060B-100000@davinci.bergen.org> from "A.K.A. TheWiz" at Jun 19, 97 10:20:27 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: 5ebdd219d11eef6f9a733a28f6f501ee

>   I have tried (and failed) to find information about the IFF format.  Can
> somebody enlighten me?

IFF is a trick for storing structured information in a flat file.  An IFF
file can be broken up into chunks and subchunks, basically a tree of
information.  Someone reading an IFF file can pay attention only to
information they are interested in, and won't even be aware of information
they don't ask for.  There's a fairly standard way of asking for
information in an IFF file.

All this was made 'big' on the Amiga a decade ago, but the idea may
predate that.

IFF is still in use, by my company for instance for its data file format.



From ???@??? Sat Jun 21 16:37:14 1997
Date: Thu, 19 Jun 1997 08:48:48 -0700
Message-Id: <199706191548.IAA25315@albatros.wco.com>
From: Alder Petrofsky <albatros@wco.com>
To: erkyrath@netcom.com
Cc: z-machine@gmd.de
In-Reply-To: <Pine.SUN.3.95.970618220212.22682A-100000@netcom22> (message from
	Andrew Plotkin on Wed, 18 Jun 1997 22:15:25 -0700 (PDT))
Subject: Re: [z-machine] Resource Format Proposal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: eac92a4904c12dcd9c642e7978f0af94

Thanks for writing up a proposal.  Here are my comments:

First, I don't understand how we can get by without the file
containing the screen dimensions for which the images were designed.
How is the interpreter to know if a 320-pixel-wide image is intended
to be full-screen-width or half-screen-width?  You mention that the
interpreter can scale things, but without this basic information, how
is it to determine what an appropriate scaling factor is?

The header should also include the vertical and horizontal resolution
(in dots/meter for PNG compatibility) at which the images were
designed.  This way, if someone wants to include an image at
double-resolution for the sake of interpreters that are scaling up
(i.e. Nelson's request) he can just include a PNG with a resolution
chunk of twice the resolution.  Two other benefits are 1) it's
possible to deal with images designed on systems with non-square
pixels, and 2) non-raster images (which have a size in meters, but no
size in pixels) can be included.

I suggest that the picture or sound format be explicitly encoded, by
adding a 30 byte field to the index entries that contains the mime
content-type: "image/png", "image/jpeg", "audio/basic",
"audio/x-infocom" etc..  Although you could get by without this by
using magic numbers (infering the type from the first few bytes of the
resource), explicit tags are more reliable and allow for better error
reporting if the type is unknown, i.e. instead of just "unknown
picture format" the user sees "unsupported picture format:
image/rorschach" and knows to look for an interpreter that advertises
"image/rorschach" support (or to go back and download the resource
archive that contains only standard picture types, which the author is
required to provide).

Lastly, I think almost everyone agrees that if we have to live with a
single image format, PNG is the way to go.  But having jpeg support as
well could greatly decrease filesize and download times.  A typical
scanned image is much more compactly encoded in jpeg, with no
significant loss of image quality.  In the PNG authors' own words:

   Note that for transmission of finished truecolor images--especially
   photographic ones--JPEG is almost always a better choice. Although
   JPEG's lossy compression can introduce visible artifacts, these can be
   minimized, and the savings in file size even at high quality levels is
   much better than is generally possible with a lossless format like
   PNG.

(from http://www.wco.com/~png/pngintro.html).

-al

From ???@??? Sat Jun 21 16:37:16 1997
Date: Thu, 19 Jun 1997 09:23:35 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] IFF format?
In-Reply-To: <199706191509.LAA30943@plymouth.truespectra.com>
Message-Id: <Pine.SUN.3.95.970619092244.28402A-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: ab204e0866ab6109ebd223e6a12e2c7f


> >   I have tried (and failed) to find information about the IFF format.  Can
> > somebody enlighten me?

http://www.cica.indiana.edu/graphics/image_specs/ilbm.format.txt

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 21 16:37:19 1997
Date: Thu, 19 Jun 1997 10:27:48 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Picture format (resolutions)
In-Reply-To: <Marcel-1.09-0619075405-b49M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.970619094350.28402B-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: d3fac539f0c1acbacaa9b56dde1ef695

On Thu, 19 Jun 1997, Graham Nelson wrote:

> On Thu 19 Jun, Andrew Plotkin wrote:
> >
> > At this point, I'm thinking this is too much of a pain. One image pixel
> > per z-pixel is a nice easy decision.
> 
> I'm all for nice easy decisions.  But what happens if I want a
> detailed photograph to occupy half the screen?  I am unable to
> arrange this, as I understand it.  If I give a detailed image,
> it could easily dwarf the rest of the screen content.  If I don't,
> it could look annoyingly grainy even though the interpreter's
> machine is capable of much better-looking graphics.
> 
> I suppose one option is to include -- in the header of the graphics
> file -- a "preferred screen size" in Z-pixels, e.g. 640 x 512.
> Would this be an acceptable compromise?

This makes sense to me. 

(BTW, Stefan Jokisch, if my replies to you earlier seemed to totally miss
your point, it's because I *did* totally miss your point. :-) You were
suggesting a "preferred screen size" (in Z-pixels) of 640x400 for all V6
games. Right?)

TheWiz wrote:
>  No, I think if the interpreter can display more area, it should:  
> 1)  Auto-scale to take advantage of it. 
> 2)  Let programmers draw things "regular size" to take advantage of the
>     larger area. 

Do you mean scale up the ratio of screen pixels to Z-pixels, or increase
the number of Z-pixels? 

Alder Petrofsky wrote:
> First, I don't understand how we can get by without the file containing
> the screen dimensions for which the images were designed. How is the
> interpreter to know if a 320-pixel-wide image is intended to be
> full-screen-width or half-screen-width?  You mention that the
> interpreter can scale things, but without this basic information, how is
> it to determine what an appropriate scaling factor is? 

This is true. The options seem to be

1) The interpreter can create a window of any size it wants (size measured
in Z-pixels.) 
2) The interpreter must always create a window of a fixed size, say
640x400.
3) The resource file includes a chunk which specifies a window size, and
the interpreter must use that size.
4) The resource file includes a chunk which specifies a window size; the
interpreter must create a window that size or larger.
5) The resource file includes a chunk which specifies a minimum and a
maximum window size. If they're the same, this becomes case 3). (The
maximum may be infinity.)

1) runs into the difficulties that have been described.
2) is less flexible than Infocom's interpreters allowed. (According to 
Mark <markk@netcomuk.co.uk>'s description of Journey resizing itself. I
haven't tried that.)
4) puts more of a burden on game files, since they would have to allow for
different screen sizes. For example, the border decorations in Zork Zero
and Arthur probably wouldn't work right at any other window size (as
measured in z-pixels.) 

(Footnote: In case 4, the interpreter cannot scale images. Every image has
a fixed size in z-pixels, and is always drawn at that z-pixel size. If an
interpreter wants to scale images, it has scale its z-pixel size; the game
won't know this has occurred. I hope that's obvious, but I wanted to state
it anyway.) 

Of those choices, I guess I'm in favor of 5), since it allows authors the
most options without being very complicated for the interpreter author. 
(An interpreter could allow the user to pick a window size, or just create
the largest window that fits on the screen -- in both cases observing the 
the min/max limitations supplied.) 

> The header should also include the vertical and horizontal resolution
> (in dots/meter for PNG compatibility) at which the images were designed. 

Dots per meter is a bad idea. If we use that information, an interpreter
will have to juggle *four* notions of the size of an image (physical size
on screen, number of pixels on screen, number of z-pixels, and number of
source image pixels). Then all the interpreter authors will come kill me. 

I've already said that it's easiest to declare that image pixels and
z-pixels are identical.

In that case, the problem of grainy images (several screen pixels
displayed per image pixel) really only arises if the interpreter chooses
to scale up its definition of z-pixels, so that there are several screen
pixels per z-pixel. Why would an interpreter choose to do this? The only
case I know of is when there's a lot of screen space available, but the
game insists on a small z-pixel size (say 320x200.) But if the game
insists on being small, I tend to think that it should *be* small,
because it will have been designed to be small; the interpreter can still
scale it up, but graininess is going to be inevitable. 

Contrariwise, if the image has extra resolution available, such that its
full glory is only visible when it's displayed 800 screen pixels wide, the
author is probably going to want it to *always* be displayed that large.
He can do this by requesting that the game window be 800 z-pixels wide.
Again, if the screen space is too small for this, the interpreter may
choose to scale down its definition of z-pixels. Then all images will lose
detail; but this is an inevitable result of displaying a large game on a
small screen. (Or, of course, the interpreter could throw an error and say
"Your screen isn't big enough to play this game!")

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."










From ???@??? Sat Jun 21 16:37:18 1997
Date: Thu, 19 Jun 1997 10:33:58 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <199706191548.IAA25315@albatros.wco.com>
Message-Id: <Pine.SUN.3.95.970619102814.28402C-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 41cc5559d0a9fd20ec28cd17406bbf27

On Thu, 19 Jun 1997, Alder Petrofsky wrote:

> I suggest that the picture or sound format be explicitly encoded, by
> adding a 30 byte field to the index entries that contains the mime
> content-type: "image/png", "image/jpeg", "audio/basic",
> "audio/x-infocom" etc.. 

The format is already explicitly encoded, in the chunk id which contains
the resource. (Currently this is always 'PNG ' for pictures, and 'ZCOD'
for z-code files.) A MIME type is theoretically more flexible than a
4-byte character constant, but in practice I don't think there's any
advantage; we're going to be sticking with a small, explicit set of types.

> Lastly, I think almost everyone agrees that if we have to live with a
> single image format, PNG is the way to go.  But having jpeg support as
> well could greatly decrease filesize and download times.  A typical
> scanned image is much more compactly encoded in jpeg, with no
> significant loss of image quality. 

I think that has to be argued out between game authors and interpreter
authors. But I'd prefer to start with a single type per usage, and see
whether further types become necessary.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 21 16:37:22 1997
Date: Thu, 19 Jun 1997 10:41:02 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <Pine.SUN.3.95.970618220212.22682A-100000@netcom22>
Message-Id: <Pine.SUN.3.95.970619103708.28402E-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 211b645f2de23604c768ae151e24920e

Also, I completely forgot about the color palette idea I mentioned. What
did people think of that?

Also, what about an z-code file descriptor, which the interpreter can use
to tell which z-code file goes with which resource file? (Assuming the
z-code isn't actually in the resource file, of course.) This would be the
same as the IFhd chunk described in the save file format.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Sat Jun 21 16:37:23 1997
Date: Thu, 19 Jun 1997 12:40:52 -0700
Message-Id: <199706191940.MAA27581@albatros.wco.com>
From: Aloha Petrofsky <albatros@wco.com>
To: erkyrath@netcom.com
Cc: z-machine@gmd.de
In-Reply-To: <Pine.SUN.3.95.970619102814.28402C-100000@netcom> (message from
	Andrew Plotkin on Thu, 19 Jun 1997 10:33:58 -0700 (PDT))
Subject: Re: [z-machine] Resource Format Proposal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: ba36df27ca17ca68a223415bc372487d

   Date: Thu, 19 Jun 1997 10:33:58 -0700 (PDT)
   From: Andrew Plotkin <erkyrath@netcom.com>

   On Thu, 19 Jun 1997, Alder Petrofsky wrote:

   > I suggest that the picture or sound format be explicitly encoded, by
   > adding a 30 byte field to the index entries that contains the mime
   > content-type: "image/png", "image/jpeg", "audio/basic",
   > "audio/x-infocom" etc.. 

   The format is already explicitly encoded, in the chunk id which contains
   the resource. (Currently this is always 'PNG ' for pictures, and 'ZCOD'
   for z-code files.) A MIME type is theoretically more flexible than a
   4-byte character constant, but in practice I don't think there's any
   advantage; we're going to be sticking with a small, explicit set of types.

But earlier you said:

   - Why does the "usage" field in the resource index entries contain,
   for example, 'Pict' instead of 'PNG '? The proposal requires that all
   pictures be PNG files.

   Why not? We may go insane someday and support more image formats.
   There's no reason to complicate the lives of mentally ill individuals
   by making them change the resource format as well.

I agreed with you the first time: let's plan for the future.  By
having a flexible media format field (png v. jpeg), separate from the
Z-usage field (sound v. picture v. code), it is easy for people to
experiment with nonstandard games and interpreters that use new media
types.  Those experiments are useful for deciding when to add new
types to the small, explicit set.

As for screen size: I like having minimum and maximum sizes, and I
agree we can live without physical resolutions.

One question: how does an author say that the screen can be any size
from 320 to 640 pixels wide, and that picture 4 should be scaled to
the width of the screen?  Apparently, one can't.

As I advocated originally, all these questions of how to encode all
the various desired scaling behaviors in the resource file become moot
if you give the running program the power to compute and request image
sizes using whatever heuristics the author chooses: a fraction of
screen width or height, the largest square that can be displayed, a
multiple of the italic font size, etc..

I just recently joined the list (are there archives somewhere?), so I
don't understand what the accepted criteria are for justifying
optional extended behavior for a z-opcode (i.e. allowing picture_data
to be used for setting as well as getting sizes).  I don't see why
this is any worse than specifying a new picture file format.  They
both require work from interpreter-writers if they want to keep
up-to-date, and they both allow a game to be written that will work
with new or old interpreters.  Why all the resistance?

-al

From ???@??? Sat Jun 21 16:37:29 1997
Date: Thu, 19 Jun 1997 13:38:06 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <199706191940.MAA27581@albatros.wco.com>
Message-Id: <Pine.SUN.3.95.970619131530.19765A-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 322e4b1b3c7135721c36b9eaa23c4943

On Thu, 19 Jun 1997, Aloha Petrofsky wrote:

>    Date: Thu, 19 Jun 1997 10:33:58 -0700 (PDT)
>    From: Andrew Plotkin <erkyrath@netcom.com>
> 
>    On Thu, 19 Jun 1997, Alder Petrofsky wrote:
> 
>    > I suggest that the picture or sound format be explicitly encoded, by
>    > adding a 30 byte field to the index entries that contains the mime
>    > content-type: "image/png", "image/jpeg", "audio/basic",
>    > "audio/x-infocom" etc.. 
> 
>    The format is already explicitly encoded, in the chunk id which contains
>    the resource. (Currently this is always 'PNG ' for pictures, and 'ZCOD'
>    for z-code files.) A MIME type is theoretically more flexible than a
>    4-byte character constant, but in practice I don't think there's any
>    advantage; we're going to be sticking with a small, explicit set of types.
> 
> But earlier you said:
> 
>    - Why does the "usage" field in the resource index entries contain,
>    for example, 'Pict' instead of 'PNG '? The proposal requires that all
>    pictures be PNG files.
> 
>    Why not? We may go insane someday and support more image formats.
>    There's no reason to complicate the lives of mentally ill individuals
>    by making them change the resource format as well.
> 
> I agreed with you the first time: let's plan for the future. 

I'm not contradicting myself, and I agree with you both times. The
resource index entry might say:
  Usage: 'Pict'
  Number: 4
  Start: 20000

The chunk which begins at byte 20000 is picture resource 4, and it looks
like
  Chunk id: 'PNG '
  Length: 5000
  Data: ...500 bytes of PNG data...

The format is explicitly encoded as 'PNG '. If we ever choose to allow
more image formats, this could be changed to 'JPEG' to indicate that that
image is a JPEG file instead of a PNG file.

> As for screen size: I like having minimum and maximum sizes, and I
> agree we can live without physical resolutions.
> 
> One question: how does an author say that the screen can be any size
> from 320 to 640 pixels wide, and that picture 4 should be scaled to
> the width of the screen?  Apparently, one can't.

Right. The Z-machine doesn't have the ability to scale pictures to
different Z-pixel sizes. The Infocom interpreters can't do it. Note
markk's post saying that if you change the Z-pixel window size when
playing Journey, the window subdivisions change size, but the actual
graphics do not. The graphics are drawn centered in their (larger) 
rectangles, or clipped to their (smaller) rectangles. (The game is
detecting the different window size and choosing an appropriate screen
layout. It can do this by changing the text window margins and drawing
images at different locations on the screen, but it *can't* scale images.) 
 
> As I advocated originally, all these questions of how to encode all
> the various desired scaling behaviors in the resource file become moot
> if you give the running program the power to compute and request image
> sizes using whatever heuristics the author chooses: a fraction of
> screen width or height, the largest square that can be displayed, a
> multiple of the italic font size, etc..

True, but that would be a new version of the Z-machine.
 
> I
> don't understand what the accepted criteria are for justifying
> optional extended behavior for a z-opcode (i.e. allowing picture_data
> to be used for setting as well as getting sizes).

The accepted criterion is, basically, don't do it.  We've added very
little behavior that wasn't in Infocom's original machine description. In
the case of this graphics stuff, the feeling is that we should implement
and explore the full capacity of the V6 machine before we start proposing
extensions. 

>  I don't see why
> this is any worse than specifying a new picture file format.  They
> both require work from interpreter-writers if they want to keep
> up-to-date, and they both allow a game to be written that will work
> with new or old interpreters.  

I disagree with the last part. If we extend the machine (say, by allowing
the game to scale images), then games *won't* work on old interpreters.
Unless the game checks for the new extension -- effectively, checking to
see which interpreter version it's running on -- and handles both cases
separately. And that itself is more work for the game author, and produces
a game that works differently for different people. 

It's not that we never do this. But it's a drastic step, much more drastic
than creating a standard picture file format (not a *new* one, since there
never has been a cross-platform standard for V6 game art. It's a matter
which is outside the Z-machine definition, see.) 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Sat Jun 21 16:37:25 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Thu, 19 Jun 1997 20:49:54 -0000
Message-Id: <yam7109.2700.3716448@smtp.netcomuk.co.uk>
In-Reply-To: <Pine.SUN.3.95.970619094350.28402B-100000@netcom>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] Picture format (resolutions)
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: 8ebc24a70121fa89f87c93981868368c

On 19-Jun-97, Andrew Plotkin wrote:
>4) The resource file includes a chunk which specifies a window size; the
>interpreter must create a window that size or larger.
>5) The resource file includes a chunk which specifies a minimum and a
>maximum window size. If they're the same, this becomes case 3). (The
>maximum may be infinity.)

>1) runs into the difficulties that have been described.
>2) is less flexible than Infocom's interpreters allowed. (According to 
>Mark <markk@netcomuk.co.uk>'s description of Journey resizing itself. I
>haven't tried that.)

The experiment I detailed was actually using the Amiga port of Frotz. I've just
tried forcing the original Infocom Amiga interpreter to use various exotic
screen sizes, with good results. Some examples:

Game       Screen size  Comments
Journey    760x760      The title picture always appears at the top left. Other
                        than that, all areas of the screen are scaled
                        appropriately, and graphics are centred within their
                        borders.
Journey    512x200      Even with this narrow size, things are mostly okay. But
                        the game is happier with at least 640 pixels width.
                        The title picture is clipped.
Journey    640x150      The game still plays okay like this. The bottom portion
                        of some pictures is clipped to fit within the border.
Shogun     960x380      The right-hand borders are drawn assuming a screen
                        width of 640 pixels.

Note that the Infocom interpreter may in fact be 'better' than this. The
method of forcing the screen size that I used is very bad, since a program can
assume that the screen it opened is the size that it requested. It may be that
there are several references to (say) the hard-coded width of 640 pixels in
the interpreter. If these were patched appropriately, results could be better.
In particular, the Shogun border problem does not occur when using Frotz.


>4) puts more of a burden on game files, since they would have to allow for
>different screen sizes. For example, the border decorations in Zork Zero
>and Arthur probably wouldn't work right at any other window size (as
>measured in z-pixels.) 

Game files should allow for different screen sizes already. Border decorations
(like the border for the hints in Shogun) are mostly handled properly.

Infocom's own interpreter for Arthur opens a screen of either 200 or 256 pixels
in height, depending on whether it's running on an NTSC or PAL machine.
Pictures
are centred correctly.

Note that (the Amiga port of) Frotz is bugged. When playing Arthur on a
400x300 pixel screen, it should not double the width of images, but just centre
them. Anyway, the side borders in Arthur do appear in the wrong place when
using a screen wider than 320/640 pixels. Could this be because the Amiga
graphics stored as a single picture what the MS-DOS version stored as several
(i.e., banner and borders as separate pictures)? Was the story file for the
Amiga version different from the DOS version?


-- Mark


From ???@??? Sat Jun 21 16:37:37 1997
Date: Thu, 19 Jun 1997 23:19:18 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Resource Format Proposal
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.SUN.3.95.970619103708.28402E-100000@netcom>
Message-Id: <Marcel-1.09-0619221918-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: f2ea052a09fef21ac59bc6d0d7e5a2cc

On Thu 19 Jun, Andrew Plotkin wrote:
> Also, I completely forgot about the color palette idea I mentioned. What
> did people think of that?

I don't think I sufficiently understand the issue involved.
Do PNG files not specify their own palettes?  If they do, surely
there's no need for any global palette?

> Also, what about an z-code file descriptor, which the interpreter can use
> to tell which z-code file goes with which resource file? (Assuming the
> z-code isn't actually in the resource file, of course.) This would be the
> same as the IFhd chunk described in the save file format.

Careful now!  We wouldn't want to make it such that the "blorb"
file required that the Z-code file had a particular serial code,
when in the testing process -- imagine the inconvenience.

Or perhaps interpreters ought to have a "testing" mode, which
waives these tests.  Or something like that.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Jun 21 16:37:38 1997
Date: Thu, 19 Jun 1997 23:28:11 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Specification 0.99999 online
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.09-0619222811-b49M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: 9036894518d463dd9982f0b9c3f0cccf


Specification 0.99999 is now terribly close to being baptised as
1.0, after a gestation period which would put an elephant to shame.
(The only remaining technical issue is to do with V6 window
attributes, in the murky depths of the much-feared section 8.8,
and it's really a matter of finding suitable wording.)

To celebrate this event, I've converted it to HTML and lodged it at:

  http://www.gnelson.demon.co.uk/zspec/index.html

When 1.0 finally happens, I'll bundle up the various bits of HTML
into a Zip file and upload it to ftp.gmd.de: in the mean time, I'd
rather not circulate it too far.

Enjoy.  The most useful thing is probably the opcode table, which
links each opcode directly to its dictionary definition.

(As ever, my Internet service provider has a cache which means
that the new directory and its contents may not be visible externally
for a day or two.)

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Jun 21 16:37:33 1997
Date: Thu, 19 Jun 1997 20:26:06 -0700
Message-Id: <199706200326.UAA30481@albatros.wco.com>
From: Alternatives Petrofsky <albatros@wco.com>
To: erkyrath@netcom.com
Cc: z-machine@gmd.de
In-Reply-To: <Pine.SUN.3.95.970619131530.19765A-100000@netcom> (message from
	Andrew Plotkin on Thu, 19 Jun 1997 13:38:06 -0700 (PDT))
Subject: Re: [z-machine] Resource Format Proposal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c592bff9ec386b7f4281122f8fb86197

   Date: Thu, 19 Jun 1997 13:38:06 -0700 (PDT)
   From: Andrew Plotkin <erkyrath@netcom.com>

   I'm not contradicting myself, and I agree with you both times. The
   resource index entry might say:
     Usage: 'Pict'
     Number: 4
     Start: 20000

   The chunk which begins at byte 20000 is picture resource 4, and it looks
   like
     Chunk id: 'PNG '
     Length: 5000
     Data: ...500 bytes of PNG data...

   The format is explicitly encoded as 'PNG '. If we ever choose to allow
   more image formats, this could be changed to 'JPEG' to indicate that that
   image is a JPEG file instead of a PNG file.

Oh, now I get it.  Sorry about that.  So all I'm proposing is a
30-character type instead of a 4-character type.  I hardly see the
significance of the cost.  Apparently you feel the same way about the
benefit, but I think it's good to be able to leverage off the work of
the IANA registry to reduce confusion about what names to use for
formats as new ones arise.

   >  I don't see why
   > this is any worse than specifying a new picture file format.  They
   > both require work from interpreter-writers if they want to keep
   > up-to-date, and they both allow a game to be written that will work
   > with new or old interpreters.  

   I disagree with the last part. If we extend the machine (say, by allowing
   the game to scale images), then games *won't* work on old interpreters.
   Unless the game checks for the new extension -- effectively, checking to
   see which interpreter version it's running on -- and handles both cases
   separately. And that itself is more work for the game author, and produces
   a game that works differently for different people. 

Currently, the game must check the image size the interpreter gives
it, and deal with it.  I'm just proposing that the game has an
additional option of requesting a different size (and still dealing
with life if the interpreter refuses).  How is this creating more
work?

Note that my proposal was designed so that any interpreter that obeys
the old spec is also obeying the new spec.  This is why I think it's a
reasonable change to make without bumping the version number.  The
proposal again: if the picture_number argument to picture_data is
negative n, the interpreter, if willing, scales picture n using the
data in the array argument, otherwise it does nothing.  Old
interpreters will always do nothing because they'll treat the negative
number like any other invalid picture number (for which the specified
behavior is to do nothing), hence old interpreters will be compliant
with the new spec.

   It's not that we never do this. But it's a drastic step, much more drastic
   than creating a standard picture file format (not a *new* one, since there
   never has been a cross-platform standard for V6 game art.

I don't buy this at all.  We are not just creating a standard where
there wasn't one by taking one of the old formats and blessing it, we
are creating a brand-spanking *new* format that is completely
meaningless to all old interpreters, and also naming it the standard.

In general I feel that whereas versions 1-5 are elegant and widely
implemented designs that we should hesitate to disturb, version 6 is
just a half-baked, platform-dependent, resolution-dependent hack that
we shouldn't feel bad about fixing.

-al

From ???@??? Sat Jun 21 16:37:39 1997
Date: Fri, 20 Jun 1997 16:30:35 +0100 (BST)
From: Dan J Archer <D.Archer@uea.ac.uk>
X-Sender: u9537872@cpca5.uea.ac.uk
To: Andrew Plotkin <erkyrath@netcom.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <Pine.SUN.3.95.970618220212.22682A-100000@netcom22>
Message-Id: <Pine.OSF.3.91.970620161800.7756A-100000@cpca5.uea.ac.uk>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 0b5eb8b37cae78bd8a29c850525ccd87

Hi all,

I've been lurking on this list for well over a year now, but it's only 
rarely that I find I have something useful to say, or more accurately 
something useful to say which has not already been voiced by one of the 
more senior z-machiners...

On this occasion, however...

On Wed, 18 Jun 1997, Andrew Plotkin wrote:

> At Graham's kind invitation, I've thrown together a proposal which sums up
> what's been discussed here in terms of image formats. As interpreted by
> me, of course. :-) I'm calling it a resource format, rather than an image
> format, because it can contain sounds and z-code too. 
> 
> Now you deluge me with comments. 
> 

> The first chunk in the FORM must be a resource index (chunk type
> 'RIdx'.) This lists all the resources stored in the IFRS FORM.

In what sort of detail? If it's just a chunk list, then surely it's 
unnecessary as the interpreter may as well search through the chunks in 
the file as search through the RIdx chunk. This is standard IFF behaviour.

> Several chunks may also appear by convention in any IFF FORM: '(c) ',
> 'AUTH', and 'ANNO'. These chunks should appear after the resource
> index and all the resource chunks.

Again, one of the useful features of IFF is that its chunks need not be 
in any particular order: an IFF reader (human or automaton) need only hit 
the first chunk, check its type, and if it's the wrong one then add the 
chunk length to the file position and retry...order is unimportant so the 
AUTH and ANNO chunks can go anywhere.

> The start field tells where the resource chunk begins. This value is
> an offset, in bytes, from the start of the IFRS FORM (that is, from
> the start of the file.)

(See above).

I seem only to have made one point here, but it's been a long day.

	-Dan J Archer

Athankye.

 /----------------------------------------------------------------------\
/ "A friend of mine did ride astride with tattered hat and stalk of hay: \
\  He carried buckets of giraffe, and hairless errors 'pon a tray."      /
 \----------------------------------------------------------------------/
 /        D.Archer@uea.ac.uk      |   http://www.uea.ac.uk/~u9537872/   \ 
 \----------------------------------------------------------------------/


From ???@??? Sat Jun 21 16:37:43 1997
Date: Fri, 20 Jun 1997 09:42:43 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <Pine.OSF.3.91.970620161800.7756A-100000@cpca5.uea.ac.uk>
Message-Id: <Pine.SUN.3.95.970620093551.20037B-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 6e207302c07c88c18572c40cde9df96c

On Fri, 20 Jun 1997, Dan J Archer wrote:

> > The first chunk in the FORM must be a resource index (chunk type
> > 'RIdx'.) This lists all the resources stored in the IFRS FORM.
> 
> In what sort of detail? If it's just a chunk list, then surely it's 
> unnecessary as the interpreter may as well search through the chunks in 
> the file as search through the RIdx chunk. This is standard IFF behaviour.

This was the point of one of the footnotes at the end:

-------
- Why is there a "number" field in the entries in the resource index
chunk? Why not just assume chunks are numbered consecutively?

Pictures are not necessarily numbered contiguously (Z-Spec 8.8.6.1.)
Sounds are numbered consecutively, but sounds 1 and 2 are bleeps, so
the game-specific sound resources start at 3. (Z-Spec 9.2.) Rather
than jigger the numbering or require place-holder chunks, I decided
there should be an index which maps resource numbers to chunks.
-------

In other words, a resource file may need to contain picture 4, picture 8,
sound 3, sound 4, and nothing else. That's why there's an index.

Given the necessity of an index, pointers to the start of each indexed
chunk is convenient.  I could have referred to chunks by their sequence in
the file, but an interpreter might as well have the pointer available. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 21 16:37:45 1997
Date: Fri, 20 Jun 1997 10:00:02 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <Marcel-1.09-0619221918-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.970620094328.20037C-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: a0b2fbdce2ef1d490105741a7762a7a6

On Thu, 19 Jun 1997, Graham Nelson wrote:

> On Thu 19 Jun, Andrew Plotkin wrote:
> > Also, I completely forgot about the color palette idea I mentioned. What
> > did people think of that?
> 
> I don't think I sufficiently understand the issue involved.
> Do PNG files not specify their own palettes?  If they do, surely
> there's no need for any global palette?

PNG files containing indexed-color images must contain a palette. Direct-
color PNG files can contain an optional palette, which is a hint about
what colors to quantize to, pretty much the same as what I suggested.

However:

A resource file can contain a whole lot of images, and there's nothing
that says they must all contain palettes, or even that they must all have
the same palette. A given PNG tool may fail to write in optional palettes
for direct-color images. Also, if there are a lot of images with a few
colors each, their internal palettes would all be different, even though
they're all (hopefully) subsets of a single 256-color palette. 

It seems rude to make an interpreter trawl through all the images in a
file and try to combine their palettes. It's extra work for the author to
precompute this and include it as a separate chunk, but it only has to be
done once. If it's the interpreter's job, it has to be done once for every
gameplay session, and the code has to be ported for each interpreter.

(One would certainly want a special-purpose tool, for the author's use, to
do this work -- trawl through a bunch of PNG images and resolve a palette.
But even then not all authors would need to use it; I think it's more
typical to create one image and use its palette for all later art.)
 
> > Also, what about an z-code file descriptor, which the interpreter can use
> > to tell which z-code file goes with which resource file? (Assuming the
> > z-code isn't actually in the resource file, of course.) This would be the
> > same as the IFhd chunk described in the save file format.
> 
> Careful now!  We wouldn't want to make it such that the "blorb"
> file required that the Z-code file had a particular serial code,
> when in the testing process -- imagine the inconvenience.

The IFhd chunk would be optional; during testing, you could just leave it
out. 

> Or perhaps interpreters ought to have a "testing" mode, which
> waives these tests.  Or something like that.

That too.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sun Jun 22 20:02:07 1997
Date: 21 Jun 97 12:59:44 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture for
Message-Id: <970621165944_104312.2206_IHS68-1@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: e0db20eb65f8eeb9ca6f902be9b34781


I'm going to chip in my 2d on the picture format discussion.  As usual, 
these are just my opinions and may not even be worth what you paid for 
them.  (Bear in mind that every time I've looked at the Z6 spec I've 
given up and done something less challenging.)

<< It looks as if most people are broadly in favour of an agreed
"modern graphics format" ... The principal objection to this seems to 
be that low-end machines (e.g. the Apple II, or some palm-tops) won't 
be able to cope with modern-style graphics -- personally I think this 
is a sad inevitability, but not worth giving up the idea for. >>

That wasn't the impression I meant to give.  I was arguing that *JPEG* 
is a rotten format for the 'computationally-challenged' platforms.  I 
could probably handle PNG (although it might be nice if we constrained 
the format a little.  I've seen comments that PNG is as complex as 
TIFF, and a full TIFF-handling library is not a trivial proposition.)
 
<< It seems to me that it ought to be legal to plot pictures with
finer resolution than the Z-machine model of pixels -- that is,
that a file could supply a 100x100 image which is supposed to
occupy a 50x50 pixel space in the Z-machine's notional screen:
interpreters could then display as they see fit.  >>

I'm going to think out loud about image and screen sizes.  Bear with 
me.

1.  We can't fix the screen size.  That leads to games demanding 
320x200 or 640x480 which is silly *now* and is going to get worse.  I 
don't want to end up playing in a corner of the 17" monitor at work, or 
panning around a virtual screen on a palmtop.

2. We can't expect game authors to supply versions of the graphics in 
more than one size.  That's tedious for the author, leads to huge 
downloads and only solves the problem for 'standard' screen sizes 
anyway.

3. I've seen proposed uses of graphics to draw a side-bars in the style 
 of Zork0, or to provide a graphical bar across the top of the screen. 
These are reasonable uses, but I've yet to see a mechanism that will 
make them work.

Taking these together, we need to scale graphics in the interpreter.  
The problem is that given the current Z6 opcodes,

    picture_data        returns the picture geometry
    draw_picture        plots it a given position
    
the interpreter has no idea of what size a graphic should be.  Adding a 
notional 'standard resolution' record in the resource file goes someway 
towards this, but we still end up scaling *every* graphic which will be 
degrade the quality of some (the rune-filled parchments) when it may 
not have been needed.

How about a scheme where each image has data associated with it (say 
another record in the resource file, to avoid messing with the PNG 
structure) which indicate the maximum and minimum proportions of the 
screen which the image should occupy?  Call these xmin, xmax, ymin and 
ymax.  Then

a) The vertical border elements have
   ymin = ymax = 1.0 (fills the screen vertically)
   xmin = xmax = 0.1 (but only 10% across)
    
b) The title bar which fits between those has
   ymin = 0.1, ymax = 0.2
   xmin = xmax = 0.8 (so it will exactly fit)

c) A 'magnetic scrolls' picture across the top half of the screen has
  ymin = 0.4, ymax = 0.6 (roughly the top half)
  xmin = xmax = 1.0      (must be full width)
  
d) The rune-filled scroll has
  xmin = ymin = 0.1, xmax = ymax = 0.9 (not too fussy)
  
When the interpreter needs the graphic, for any of the picture opcodes, 
it should use the image as is, if that is possible, or scale it 
preserving the aspect ratio until it fits with the bounds, or if that 
is also impossible (because the screen has a weird geometry) then scale 
it without preserving the aspect ratio.

I think this works, and it avoids messing with the opcodes to add size 
requests (from game to interpreter), although that would be more 
powerful.  It does dump a lot of the screen-layout logic in the Z-code, 
but I get the impression that's the way Z6 works ...

    Bryan

 


From ???@??? Sun Jun 22 20:02:09 1997
Message-Id: <33AC253D.52E95995@micron.net>
Date: Sat, 21 Jun 1997 13:02:21 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.0b5C (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: Bryan Scattergood <104312.2206@CompuServe.COM>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture for
X-Priority: 3 (Normal)
References: <970621165944_104312.2206_IHS68-1@CompuServe.COM>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 85ef00320980fbebdc34093189c2d684

Bryan Scattergood wrote:
> That wasn't the impression I meant to give.  I was arguing that *JPEG*
> is a rotten format for the 'computationally-challenged' platforms.  I
> could probably handle PNG (although it might be nice if we constrained
> the format a little.  I've seen comments that PNG is as complex as
> TIFF, and a full TIFF-handling library is not a trivial proposition.)

Actually, PNG is significantly simpler than TIFF.  The reason that the
people who ended up creating PNG didn't go to TIFF was because they
viewed it as an overcomplicated and sprawing mess.

--Galen

From ???@??? Sun Jun 22 20:02:11 1997
Date: Sat, 21 Jun 1997 18:43:31 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom23
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <199706200326.UAA30481@albatros.wco.com>
Message-Id: <Pine.SUN.3.95.970621183318.8471A-100000@netcom23>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 31c03a74a169003486bfe4aad91cc864

On Thu, 19 Jun 1997, Alternatives Petrofsky wrote:

> Note that my proposal was designed so that any interpreter that obeys
> the old spec is also obeying the new spec.  This is why I think it's a
> reasonable change to make without bumping the version number.  The
> proposal again: if the picture_number argument to picture_data is
> negative n, the interpreter, if willing, scales picture n using the
> data in the array argument, otherwise it does nothing.  Old
> interpreters will always do nothing because they'll treat the negative
> number like any other invalid picture number (for which the specified
> behavior is to do nothing), hence old interpreters will be compliant
> with the new spec.

I agree, this is a backwards-compatible extension. 

>    It's not that we never do this. But it's a drastic step, much more drastic
>    than creating a standard picture file format (not a *new* one, since there
>    never has been a cross-platform standard for V6 game art.
> 
> I don't buy this at all.  We are not just creating a standard where
> there wasn't one by taking one of the old formats and blessing it, we
> are creating a brand-spanking *new* format that is completely
> meaningless to all old interpreters, and also naming it the standard.

Not really true. This proposal is a data transportation spec. It doesn't
change anything about how the z-machine behaves; it only gives
interpreters a common way to get at information which the z-machine
doesn't even know about.

Concrete example: it's perfectly within the spirit of the format to write
a cheap hack which translates a Blorb file into an Infocom-format
directory of Infocom-format images. If you write a small script which runs
this hack and then starts up an old Infocom interpreter, then the old
interpreter *will* effectively understand Blorb files. You may lose image
quality in the translation -- that's inevitable, because the Infocom
interpreters only displayed 8-bit color images. 

> In general I feel that whereas versions 1-5 are elegant and widely
> implemented designs that we should hesitate to disturb, version 6 is
> just a half-baked, platform-dependent, resolution-dependent hack
> that we shouldn't feel bad about fixing.

I don't think it's that bad. It may have "made a mess of the opcode
system", but it's not platform-dependent, and it's baked enough to support
Journey, Arthur, and Zork Zero (three games which span a pretty wide range
of game behavior.) 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Mon Jun 23 22:21:53 1997
Date: 22 Jun 97 08:23:35 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture for
Message-Id: <970622122335_104312.2206_IHS53-1@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: dbe86de73e807506f0f468b5d6bdce1b

Galen wrote:

<< Actually, PNG is significantly simpler than TIFF.  The reason that 
the people who ended up creating PNG didn't go to TIFF was because they
viewed it as an overcomplicated and sprawing mess. >>

That's something of a relief.  The last time I played with TIFF was a 
while ago, but I remember that it was fairly hairy.  (Although things 
weren't made any easier by the fact that I was accessing the files from 
Lisp, had file I/O operations that didn't allow random access, and 
didn't have enough memory just to pull the whole file in.)

    Bryan




 


From ???@??? Mon Jun 23 22:21:51 1997
Date: 22 Jun 97 08:23:40 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: [z-machine] Catch, throw and save
Message-Id: <970622122339_104312.2206_IHS53-2@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 146194065ddfe9a311adb80b3d3879ef


I've just spent a couple of hours examining the Quetzal (aka Gnusto, 
formerly known as CSFF) documentation.  I have a problem with 6.2, the 
section covering the encoding of the CATCH cookies.

6.2 specifies that the cookie shall be the number of frames on the 
system stack.

The current code I'm using implements the cookie as the total depth of 
the stack.

I can't read an old file and save it as Quetzal, since that will 
produce a file which is ostensibly Quetzal but may have plausible 
non-Quetzal cookies in it.  Bad move, unless I can be sure that saves 
don't occur while a CATCH is active.

So, a few questions:

1) How much use does the Inform library make of CATCH?  In particular, 
can one be active when a save occurs?

2) How about the standard Infocom games?

3) How many interpreters have shipped which support the current Quetzal 
specification?

4) If the answer to (3) is 'none', how do people feel about modifying 
6.2 to add a magic nibble at the top of the cookie to identify it as a 
Quetzal cookie?  (That would allow old->new file conversion to 'work', 
at least until the cookie was thrown and the interpreters caught the 
problem.)

I may be going to extreme measures to give users a migration path here, 
but I've managed it so far ...

    Bryan

 


From ???@??? Mon Jun 23 22:21:54 1997
Date: Sun, 22 Jun 1997 23:15:13 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Catch, throw and save
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <970622122339_104312.2206_IHS53-2@CompuServe.COM>
Message-Id: <Marcel-1.09-0622221513-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: 1d88c3c46c102f22569386e4582b7667

On Sun 22 Jun, Bryan Scattergood wrote:
> 
> ... unless I can be sure that saves 
> don't occur while a CATCH is active.  So, a few questions:
> 
> 1) How much use does the Inform library make of CATCH?  In particular, 
> can one be active when a save occurs?

None: the Inform library never uses "catch" and "throw".  That
doesn't mean that games written using Inform won't use it, of
course.  All the same I think it unlikely that catch/throw would
be used across a save, simply because saves are generally the only
thing happening in an entire turn.

It's possible to imagine a game-within-a-game, perhaps, where the
inner game terminates by performing a "throw" back to the outer
game; and a save occurring while the player is playing the inner
game?  A bit contrived as an example.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Mon Jun 23 22:21:56 1997
Date: Sun, 22 Jun 1997 20:28:17 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706230028.UAA12638@wanda.vf.pond.com>
To: 104312.2206@CompuServe.COM, z-machine@gmd.de
Subject: Re:  [z-machine] Catch, throw and save
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: b429109987af2917bde2e17e7a342ca7

} So, a few questions:

} 1) How much use does the Inform library make of CATCH?  In particular, 
} can one be active when a save occurs?

It doesn't.

} 2) How about the standard Infocom games?
Only the V6 games use "catch".  I don't know if it can be active
during a save, but my suspicion is that it can -- but that it will
never be thrown.

} 3) How many interpreters have shipped which support the current Quetzal 
} specification?

To my knowledge, one, but no "catch" support in that interpreter (ZPlet)

Unfortunately, ZIP save files cannot be converted to QUETZAL because
there's no way of knowing the # of locals :-(

From ???@??? Mon Jun 23 22:22:04 1997
Date: Sun, 22 Jun 1997 22:22:31 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture for
In-Reply-To: <970621165944_104312.2206_IHS68-1@CompuServe.COM>
Message-Id: <Pine.SUN.3.95.970622220703.29168B-100000@netcom20>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 01e0774b162c0f644d4a5e99ec1b8f19

On 21 Jun 1997, Bryan Scattergood wrote:

> (Bear in mind that every time I've looked at the Z6 spec I've 
> given up and done something less challenging.)

Amen, oh brother.

> I'm going to think out loud about image and screen sizes.  Bear with 
> me.
> 
> 1.  We can't fix the screen size.  That leads to games demanding 
> 320x200 or 640x480 which is silly *now* and is going to get worse.  I 
> don't want to end up playing in a corner of the 17" monitor at work, or 
> panning around a virtual screen on a palmtop.

Agreed.
 
> 2. We can't expect game authors to supply versions of the graphics in 
> more than one size.  That's tedious for the author, leads to huge 
> downloads and only solves the problem for 'standard' screen sizes 
> anyway.

Agreed. (But we can expect authors to make their games grok different
(z-pixel) window sizes. The Infocom v6 games do this.)
 
> 3. I've seen proposed uses of graphics to draw a side-bars in the style 
>  of Zork0, or to provide a graphical bar across the top of the screen. 
> These are reasonable uses, but I've yet to see a mechanism that will 
> make them work.

It's reasonable, but it's also reasonable to say, look, you can have a
graphical bar that is centered at the top of the screen, but there will be
gaps on either side if the window is too wide. Live with it.

If we allow the game to specify a minimum/maximum window size (in
z-pixels, via a resource file chunk) then the game author has the option
to prevent such gaps -- at the cost of fixing the window size, which may
be a mistake as monitors gets larger (and small-screen PDAs proliferate.)
As I said, it's a pretty easy thing for the interpreter to implement, so
I'm willing to give this option to the author. If it turns out to be a
mistake, well, you were warned.

> Taking these together, we need to scale graphics in the interpreter.  

Ok, here's what I'm *not* going to do: I'm not going to deal with
extensions to the Z-machine in the Blorb proposal. It's a data-transfer
specification. If people wish to discuss changes to the V6 machine, feel
free to start discussing, but I'm not in charge of that. 

That said...

> The problem is that given the current Z6 opcodes,
> 
>     picture_data        returns the picture geometry
>     draw_picture        plots it a given position
>     
> the interpreter has no idea of what size a graphic should be.  Adding a 
> notional 'standard resolution' record in the resource file goes someway 
> towards this, but we still end up scaling *every* graphic which will be 
> degrade the quality of some (the rune-filled parchments) when it may 
> not have been needed.

There could be a different resolution for each resource, though.
 
> How about a scheme where each image has data associated with it (say 
> another record in the resource file, to avoid messing with the PNG 
> structure) which indicate the maximum and minimum proportions of the 
> screen which the image should occupy?  Call these xmin, xmax, ymin and 
> ymax. [Each a real value between 0 and 1.]
>   
> When the interpreter needs the graphic, for any of the picture opcodes, 
> it should use the image as is, if that is possible, or scale it 
> preserving the aspect ratio until it fits with the bounds, or if that 
> is also impossible (because the screen has a weird geometry) then scale 
> it without preserving the aspect ratio.

But then how do you do things like the illuminated letters in Zork Zero,
which are supposed to be more or less a fixed size? I think it's safe to
say that *some* art is best displayed at its original size, not a ratio of
the window size.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Mon Jun 23 22:22:01 1997
Date: Sun, 22 Jun 1997 22:46:14 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <19970621120316.AAA19036@jokisch>
Message-Id: <Pine.SUN.3.95.970622222240.29168D-100000@netcom20>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: d485a095a62d66f9de82a8710fc2278a

On Sat, 21 Jun 1997, Stefan Jokisch wrote:

> I'd like to comment on a number of points.
> 
> (1) index chunk RIdx and general chunk structure
> 
> The question,
> however, is: Do we really need chunks, if there is an index table;
> why not just a header, the index plus some concatenated data?
 
Why not? It leverages off existing IFF tools, and it's not any harder for
the interpreter.

> (2) picture size (yet again)
> 
> We definitely should include some "preferred resolution" or, in my
> own words, "standard resolution" in our resource format. 

Again, I am confused: when you say "resolution", do I correctly understand
that you mean "window size (for the overall game display) (measured in
Z-pixels)"? In other words, the pair of values that gets written into, er,
header words 0x22 and 0x24? (I hope I've got *that* right.)

> It seems
> that this idea tends to be misunderstood.  The interpreter may use
> any resolution it likes, but it should scale pictures accordingly:
> If the standard resolution is n1*m1 and the interpreter resolution
> is n2*m2, all pictures should be scaled by n2/n1 and m2/m1.

So if the game's standard size is 640*480, and the interpreter puts up a
window which is 640*960 (screen pixels), it should tell the game that its
window is 640*960 z-pixels, and then scale all images to twice their
original height.

That means that the normal case will involve distorting all the game art,
unless the interpreter is careful to preserve the aspect ratio of the
game's standard size. I don't think I like that. As I said, I think a lot
of art is going to be best displayed at its actual size, and even more so
at its actual aspect ratio, and I'd rather make that the normal case. 

> (5) more bits and pieces
> 
> The resource file should include some release number to be stored
> in response to PICTURE_DATA 0. 

Good point.

> I also suggest to include some
> "preferred bpp" information.  This should prevent the interpreter
> from activating a true colour video mode if all the pictures have
> 16bpp or less.

Erm, hrm. I guess that's not any different from a preferred palette. Well,
wait; a palette is always 256 colors or less, so if there is a palette,
the author is telling the interpreter that 8 bpp is enough. And if the
palette is 16 colors or less, the author is saying that 4 bpp is enough.
And so on. 

How about a special case, where the palette chunk can contain -- instead
of a fixed list of colors -- a flag saying "The art in this file only
looks good at 16 bpp or better"? (Or "...32 bpp...". I think those are the
only two special cases one would need.) 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Tue Jun 24 20:46:13 1997
From: Miron Schmidt <s590501@tfh-berlin.de>
Reply-To: miron@comports.com
To: Z-List <z-machine@gmd.de>
Date: Mon, 23 Jun 1997 08:43:38 +0100
Message-Id: <yam7113.1949.1205283080@mailhost.tfh-berlin.de>
In-Reply-To: <Pine.SUN.3.95.970622222240.29168D-100000@netcom20>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Organization: TFH-Berlin via PPP
Subject: [z-machine] Z-Pixel ratios
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: e6cfa7d908f37da295a9a420e33c4c6e

Andrew Plotkin <erkyrath@netcom.com> wrote:
> On Sat, 21 Jun 1997, Stefan Jokisch wrote:
> > It seems
> > that this idea tends to be misunderstood.  The interpreter may use
> > any resolution it likes, but it should scale pictures accordingly:
> > If the standard resolution is n1*m1 and the interpreter resolution
> > is n2*m2, all pictures should be scaled by n2/n1 and m2/m1.

> So if the game's standard size is 640*480, and the interpreter puts up a
> window which is 640*960 (screen pixels), it should tell the game that its
> window is 640*960 z-pixels, and then scale all images to twice their
> original height.

I also believe that this is a good idea.

> That means that the normal case will involve distorting all the game art,
> unless the interpreter is careful to preserve the aspect ratio of the
> game's standard size.

Whoops, I don't think so! If your screen is double the height as the intended
screen, and the pictures are not scaled accordingly, *then* the game art will
be distorted. Properly scaling the pictures will *preserve* the intended
proportions.

E.g. my screen has a (real) size of 640*120, but my monitor is still 14". Now
if you put my game on your monitor (also 14"), with a resolution of 640*960,
and you don't scale the pictures, they will only take up 1/8 of the vertical
size. -- But I intended my game to be displayed on a certain *monitor*, not
a certain *number of pixels*.

-- 
Miron Schmidt <miron@comports.com>

           "So, if _Space Aliens_ is Infocom on acid, what's this?"
                       -- C.E. Forman, _Detective: An Interactive MiSTing_



From ???@??? Tue Jun 24 20:46:10 1997
Date: Mon, 23 Jun 1997 11:20:17 +0100 (BST)
From: Dan J Archer <D.Archer@uea.ac.uk>
X-Sender: u9537872@cpca5.uea.ac.uk
To: Andrew Plotkin <erkyrath@netcom.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Resource Format Proposal
In-Reply-To: <Pine.SUN.3.95.970622222240.29168D-100000@netcom20>
Message-Id: <Pine.OSF.3.91.970623111832.5860C-100000@cpca5.uea.ac.uk>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 0ac6c1bf57d630181ecf3d30c8afcbf9

On Sun, 22 Jun 1997, Andrew Plotkin wrote:

> On Sat, 21 Jun 1997, Stefan Jokisch wrote:
> 
> > I'd like to comment on a number of points.
> > 
> > (1) index chunk RIdx and general chunk structure
> > 
> > The question,
> > however, is: Do we really need chunks, if there is an index table;
> > why not just a header, the index plus some concatenated data?
>  
> Why not? It leverages off existing IFF tools, and it's not any harder for
> the interpreter.

I'd still go the other way - if we have IFF, why do we need the index? 
I'm with Stefan in that I think having both is unnecessary.

	Dan.


Athankye.

 /----------------------------------------------------------------------\
/ "A friend of mine did ride astride with tattered hat and stalk of hay: \
\  He carried buckets of giraffe, and hairless errors 'pon a tray."      /
 \----------------------------------------------------------------------/
 /        D.Archer@uea.ac.uk      |   http://www.uea.ac.uk/~u9537872/   \ 
 \----------------------------------------------------------------------/


From ???@??? Tue Jun 24 20:46:08 1997
Message-Id: <3.0.32.19970623223315.006ad9b4@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 23 Jun 1997 22:33:42 +1200
To: Andrew Plotkin <erkyrath@netcom.com>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Consensus on picture for
Cc: Z-Machine List <z-machine@gmd.de>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"
X-UIDL: 336084e5ca607a0ace833d559ebcd3fc

At 22:22 22/06/97 -0700, Andrew Plotkin wrote:
>On 21 Jun 1997, Bryan Scattergood wrote:
>> How about a scheme where each image has data associated with it (say 
>> another record in the resource file, to avoid messing with the PNG 
[...]
>> is also impossible (because the screen has a weird geometry) then scale 
>> it without preserving the aspect ratio.
>
>But then how do you do things like the illuminated letters in Zork Zero,
>which are supposed to be more or less a fixed size? I think it's safe to
>say that *some* art is best displayed at its original size, not a ratio of
>the window size.

Not getting into the debate at all (the Z6 specification gives me
nightmares :)), this could be handled by having the relative size set to 0,
indicating "not proportional to the window".  Of course, instead of a
floating point number, a single byte holding numbers from 0 to 100 would
work much better.

-----                                
     _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
    _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
   _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
  _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/

Gavin Lambert
uecasm@geocities.com
http://crash.ihug.co.nz/~brianc
http://www.geocities.com/SiliconValley/Heights/1987

"We now return to our regularly scheduled flame-throwing."
"PCMCIA:  People Can't Memorise Computer Industry Acronyms."
"ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."


From ???@??? Tue Jun 24 20:46:11 1997
Date: Mon, 23 Jun 1997 13:54:51 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Standard 1.0 finally released
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.09-0623125452-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: ab255d5ad52b8698ebf9d688d075850c


The Z-Machine Standards Document, v 1.0
---------------------------------------

After eighteen months of standardisation work and many years of
hacking by many hands, the definitive guide to the workings of
the Z-Machine (the run-time format for Infocom and Inform games)
is now released.

Initially, the HTML version is available for browsing at:

  http://www.gnelson.demon.co.uk/zspec/index.html

Section 8.8 has finally been sorted out, there's more HTML
tabulation and better navigational links have been inserted
since the draft was put on-line.  (And there are some cute pictures
as chapter heads, which will probably look awful on every browser
except my own.)

In a few days (an intentional delay to allow for people finding
bad bits of HTML, etc.) a zip archive of this, and a TeX version,
will be uploaded to ftp.gmd.de.

The credit belongs to the legion of Z-machine hackers whose work
is represented in this document.  All I did was to put it together,
and slowly at that; all the same I'm quite pleased with the result.


                                          Graham Nelson
                                          23rd June 1997

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Tue Jun 24 20:46:14 1997
Date: Mon, 23 Jun 1997 15:28:12 -0700
Message-Id: <199706232228.PAA02420@albatros.wco.com>
From: Altoid Petrofsky <albatros@wco.com>
To: z-machine@gmd.de
In-Reply-To: <Pine.SUN.3.95.970622220703.29168B-100000@netcom20> (message from
	Andrew Plotkin on Sun, 22 Jun 1997 22:22:31 -0700 (PDT))
Subject: Re: [z-machine] Consensus on picture for
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: f1610819f5aa6fd6e8ed8c2603594322


Andrew Plotkin <erkyrath@netcom.com> wrote:

   But then how do you do things like the illuminated letters in Zork Zero,
   which are supposed to be more or less a fixed size? I think it's safe to
   say that *some* art is best displayed at its original size, not a ratio of
   the window size.

What does "original size" mean?  Pixel size?  That only makes sense
for one resolution.  If your monitor has three times the resolution of
the author's, *no* art is best displayed at its original pixel size.

Do you mean Z-pixel size?  That's essentially the same thing as
Scattergood's x/y-min/max proposal.  That is, a 40-pixel high png in a
blorb file that specifies the screen height be between 200 and 400
z-pixels is equivalent to a png with ymin of 0.1 and ymax of 0.2.
Either way, the result will probably be too small on a PDA and too
big on a 24" monitor.

I think what you really want is for these pictures to have scaling
behavior similar to that of text, i.e. something reasonable that's
based on the monitor's resolution but not the game's window size.  On
a 100 dpi 4" wide PDA, a good font width might be something around 8
pixels, or 0.02 times the screen width, whereas on a 200 dpi 16" wide
monitor you'd want a width of about 16 pixels, or 0.005 times the
screen width (*).  You can't get reasonable sizes by fixing the number
of pixels or the fraction of the window size.  But this is a solved
problem for text, because it's already a function of interpreters that
they pick a reasonable font size.  If we just add a bit to the
picture's x/y-min/max data stating whether the sizes are relative to
the screen or the default font, I think the proposal gets pretty close
to covering all commonly desired scaling behaviors, without my dreaded
opcode extension.


In another message, there was talk of leveraging off existing IFF
tools, which made me start thinking about how much leverage we're
actually going to get.  Surely there are no existing IFF tools that
can be easily used to create the blorb index chunk, are there?
Another problem with the index relates to the requirement stated way
back at the beginning that it be easy to use a directory of pictures
instead of an archive.  In this directory, how do you store the usage
numbers and the window size range (or the min/max fractions) stored in
the blorb index?

If we make the index a simple plain text file and just use the
standard tar or uncompressed zip format for the archive, then there
will be an obvious and complete mapping between the archive and the
directory, and no special tools at all will be needed for development.

Reading tar format is no more difficult than reading IFF (the files
are just thrown together, each with a header containing a file name, a
size, and a bunch of information that can be ignored).  The zip spec
is a little more complicated, with a table of contents at the end that
has variable record-sizes, but it's not too bad.  Disallowing
compression of the member files is crucial, of course.  I think all
the zip creation programs out there support a no-compression option
(usually -0) so we'd still get the full benefit of it's wide
deployment.


The resource index file format might look something like this:

  RELEASE 73
  #type number filename              format dimension-type xmin xmax ymin ymax
  PICT  1      vertical-borders.png  PNG    screen         0.1  0.1  1.0  1.0
  PICT  2      title-bar.png         PNG    screen         0.8  0.8  0.1  0.2
  PICT  5      dragon.png            PNG    font           -    -    5.0  8.0
  PICT  7      fancy-A.png           PNG    font           -    -    2.0  3.0
  SOUND 1      scream.au             AU
  EXEC  0      avalon.z17            ZCODE

("-" meaning don't care.  For most pictures it will be sufficient to
specify constraints for one or the other dimension.)

-al


(*) And on a 2-dpi 30' wide stadium monitor, you might want a font
about 6 pixels wide, or 0.0083 times the screen width.  I thought this
example too far-fetched to include in the argument above, but it goes
to show that size specified in physical units (e.g. millimeters)
doesn't quite work either.  "Radians subtended in the vision of the
viewer" is better, but this unit still would not account for the
user's eyesight, viewing preferences, etc., all of which is more or
less already accounted for in the font size the interpreter chooses
(which is generally handed to it by the operating system).

From ???@??? Tue Jun 24 20:46:23 1997
Date: Tue, 24 Jun 1997 00:28:45 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Consensus on picture for
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <199706232228.PAA02420@albatros.wco.com>
Message-Id: <Marcel-1.09-0623232845-bc8M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: 6c6830336451db6246ca14b97cf0910f

On Mon 23 Jun, Altoid Petrofsky wrote:
> 
> 
> (*) And on a 2-dpi 30' wide stadium monitor, you might want a font
> about 6 pixels wide, or 0.0083 times the screen width.  I thought this
> example too far-fetched to include in the argument above, but it goes
> to show that size specified in physical units (e.g. millimeters)
> doesn't quite work either.  "Radians subtended in the vision of the
> viewer" is better...

This knotty issue is becoming almost surreal.  I'm reminded of
the passage in the TeX manual which explains that TeX measures
distance in units such that the largest integer means about
30 yards (for printing giant flags) and 1 unit is less than the
wavelength of visible light... now that's a technology-proof
solution.

Mr Amniotic Petrofsky suggests dropping the IFF stuff in favour
of a tar archive with a text file -- I can see _some_ logic in this,
but not all that much.  A simple PERL script will be able to make
Andrew's format pretty easily, I would think?  And Andrew offers
sound files and some form of interpreter ID... well.  I'm not sure
which is best, actually.

Incidentally we have not yet discussed the preferred sound format.
Does anyone object to WAV?  Does the world agree on what WAV is,
or is WAV another one of these catch-all formats which can include,
e.g., Ethiopian nose-flute sheet music sent via a fax machine?
Is there a more universal choice?

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Tue Jun 24 20:46:21 1997
Date: 24 Jun 97 02:47:12 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture for
Message-Id: <970624064712_104312.2206_IHS58-1@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 24c4123161c9118900a3f333d0ab2ff3


I rambled:

> When the interpreter needs the graphic, for any of the
> picture opcodes,  it should use the image as is, if that is possible, 
> or scale it preserving the aspect ratio until it fits with the
> bounds, or if that is also impossible (because the screen has a 
> weird geometry) then scale  it without preserving the aspect ratio.

Andrew queried
 
> But then how do you do things like the illuminated letters in Zork
> Zero, which are supposed to be more or less a fixed size? I think
> it's safe to say that *some* art is best displayed at its original
> size, not a ratio of the window size.

Easy.  I just didn't explain it very well.  Just set xmin=ymin=0 and 
xmax=ymax=1 and the graphics shouldn't need to be scaled (unless they 
won't fit on the screen, and if that happens with the letters we have 
other problems.)

Oh, and I didn't explicitly say the bounds were real numbers (I 
hadn't worried about that too much.)  I'd probably suggest a pair of 
16bit words representing a ratio or something, so xmin=0/1024, 
xmax=1024/1024 and so on.

    Bryan

 


From ???@??? Sat Jun 28 14:28:43 1997
Message-Id: <3.0.32.19970624205847.006b1184@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 24 Jun 1997 21:00:02 +1200
To: miron@comports.com
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Z-Pixel ratios
Cc: Z-List <z-machine@gmd.de>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"
X-UIDL: a62c2b31bfec3eba3ef8decf4f163dae

At 08:43 23/06/97 +0100, Miron Schmidt wrote:
>Andrew Plotkin <erkyrath@netcom.com> wrote:
>> On Sat, 21 Jun 1997, Stefan Jokisch wrote:
>> That means that the normal case will involve distorting all the game art,
>> unless the interpreter is careful to preserve the aspect ratio of the
>> game's standard size.
>
>Whoops, I don't think so! If your screen is double the height as the intended
>screen, and the pictures are not scaled accordingly, *then* the game art will
>be distorted. Properly scaling the pictures will *preserve* the intended
>proportions.
[example snipped]

Hmmm, this sounds fishy to me... I agree that in some cases (where the
graphic should appear in a particular rectangle relative to the text) doing
that would be useful, but in other circumstances (ie. most of the time)
where you have nice arty graphics, they will usually look absolutely
terrible if you stretch them out without preserving the aspect ratio.
Imagine a circle.  If you scale this within the aspect ratio, you will
still get a circle.  If, however, you double the height without a
proportional increase in the width, you get a nasty-looking elongated
ellipse, which is probably *not* what the author intended.

-----                                
     _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
    _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
   _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
  _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/

Gavin Lambert
uecasm@geocities.com
http://crash.ihug.co.nz/~brianc
http://www.geocities.com/SiliconValley/Heights/1987

"We now return to our regularly scheduled flame-throwing."
"PCMCIA:  People Can't Memorise Computer Industry Acronyms."
"ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."


From ???@??? Sat Jun 28 14:28:42 1997
Date: Tue, 24 Jun 1997 02:00:53 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Consensus on picture for
In-Reply-To: <Marcel-1.09-0623232845-bc8M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.BSI.3.95.970624015908.20600C-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: a0270dd564ea4ebef8c771ea72fe4a01

On Tue, 24 Jun 1997, Graham Nelson wrote:

> Incidentally we have not yet discussed the preferred sound format.
> Does anyone object to WAV?  Does the world agree on what WAV is,
> or is WAV another one of these catch-all formats which can include,
> e.g., Ethiopian nose-flute sheet music sent via a fax machine?
> Is there a more universal choice?

I would suggest WAV, but I have been told that it uses a number of
different compression formats, some copyright by MicroSnot.  So I suggest
uncompressed WAVs (do such creatures exist?)

Patrick
---

"Every weekday morning the school bell cast its glamour over the
 surounding hills, calling the young to classes.  They came running
 down the slopes and leaping over the streams, out from caves and the
 hollows of trees and suburban tract homes, impelled by powers greater
 then their own to gain an education." 
    "The Iron Dragon's Daughter" by Michael Swanwick


From ???@??? Sat Jun 28 14:28:45 1997
Date: Tue, 24 Jun 1997 09:37:21 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Sound formats
In-Reply-To: <Pine.BSI.3.95.970624015908.20600C-100000@ns1.syix.com>
Message-Id: <Pine.SUN.3.95.970624090403.22117B-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 44243c83cf6e36a13ff14baad727e124

On Tue, 24 Jun 1997, Patrick Kellum wrote:

> On Tue, 24 Jun 1997, Graham Nelson wrote:
> 
> > Incidentally we have not yet discussed the preferred sound format.
> > Does anyone object to WAV?  Does the world agree on what WAV is,
> > or is WAV another one of these catch-all formats which can include,
> > e.g., Ethiopian nose-flute sheet music sent via a fax machine?
> > Is there a more universal choice?
> 
> I would suggest WAV, but I have been told that it uses a number of
> different compression formats, some copyright by MicroSnot.  So I suggest
> uncompressed WAVs (do such creatures exist?)
> 

Forgive me, but my assumption is that anything that comes out of
Microsoft will be... [initial phrasing censored]... non-ideal. I'm not
going to argue about it, however.

Also one of the reasons for being able to use an uncompressed archive
format is that decent sound and image formats include compression.

I asked my collection of geek friends, and the suggestions they came back
with were AU, RealAudio, and MPEG audio (layer 3). 

I have not investigated these technically, except to note that MPEG audio
is probably monstrous overkill.

Erm, I can't find much.
http://www.cs.ruu.nl/wais/html/na-dir/audio-fmts/.html
is a FAQ from 1994.

Oh, one thought: It may be desirable to support two audio formats -- a
sample format (like WAV, AU, RA...) and a note format (MIDI or MOD). A
note format allows you to store lots of background music in very little
space.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:28:46 1997
Message-Id: <Mutt.19970624111817.jholder@deimos.frii.com>
Date: Tue, 24 Jun 1997 11:18:17 -0600
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Sound formats
References: <Pine.BSI.3.95.970624015908.20600C-100000@ns1.syix.com> <Pine.SUN.3.95.970624090403.22117B-100000@netcom>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <Pine.SUN.3.95.970624090403.22117B-100000@netcom>; from Andrew Plotkin on Jun 24, 1997 09:37:21 -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: f0758fde05b94337a5c73bd517179cad

Andrew Plotkin writes:
> I asked my collection of geek friends, and the suggestions they came back
> with were AU, RealAudio, and MPEG audio (layer 3). 

.au is probably simplest of the three.

> I have not investigated these technically, except to note that MPEG audio
> is probably monstrous overkill.

Of this I am also sure!

> Oh, one thought: It may be desirable to support two audio formats -- a
> sample format (like WAV, AU, RA...) and a note format (MIDI or MOD). A
> note format allows you to store lots of background music in very little
> space.

Yeah!  .MOD or .MID would be cool.  MIDI is probably a bit more universal,
although coding either may be a pain, there is free source examples available
for many platforms.

If we went with MODfiles, the mods include there own standards for how a sample
should look, but then we run into things like: do we allow STM extensions?
XM extensions? no extensions? 669 extensions?  There are many many MOD-based
formats.  Despite this, I really like this idea.

John

-- 
John Holder (jholder@frii.com) /\            http://www.frii.com/~jholder/
UNIX Specialist, Paranet Inc. <--> Raytracing|Fractals|Interactive Fiction
http://www.paranet.com/        \/           Homebrewing|Strange Attractors

From ???@??? Sat Jun 28 14:28:47 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Tue, 24 Jun 1997 19:04:56 -0000
Message-Id: <yam7114.2819.4540304@smtp.netcomuk.co.uk>
In-Reply-To: <Pine.SUN.3.95.970624090403.22117B-100000@netcom>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] Sound formats
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: 070a5e3c7b1da2493d97af3746892ff3

On 24-Jun-97, Andrew Plotkin wrote:
>I asked my collection of geek friends, and the suggestions they came back
>with were AU, RealAudio, and MPEG audio (layer 3). 

RealAudio is proprietary, so it will not be possible to use that.


>I have not investigated these technically, except to note that MPEG audio
>is probably monstrous overkill.

Definitely. I don't know about AU, but it would certainly be easy for authors
to convert 'industry-standard' sample formats into signed or unsigned raw 8- or
16-bit data. A format for distribution could build on this, including of course
the desired playback rate.


>Oh, one thought: It may be desirable to support two audio formats -- a
>sample format (like WAV, AU, RA...) and a note format (MIDI or MOD). A
>note format allows you to store lots of background music in very little
>space.

Midi requires either a large collection of instrument samples, or some support
in hardware.

The MOD (by which I assume you mean the format originating with the Amiga
program SoundTracker) format only allows 8-bit samples to be used. I would
suggest IFF-SMUS since people are suggesting some kind of IFF file for the
pictures. This would make it very easy to include both pictures and music in
one file. Of course, almost nobody has tools for creating IFF-SMUS music, or do
they?


-- Mark


From ???@??? Sat Jun 28 14:28:49 1997
Date: Tue, 24 Jun 1997 12:55:43 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Sound formats
In-Reply-To: <Pine.SUN.3.95.970624090403.22117B-100000@netcom>
Message-Id: <Pine.BSI.3.95.970624125132.22693B-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: c4f8bf89485e65dab8ed1dc37d53a885

On Tue, 24 Jun 1997, Andrew Plotkin wrote:

> I asked my collection of geek friends, and the suggestions they came back
> with were AU, RealAudio, and MPEG audio (layer 3). 

Well, seeing as how the RealAudio folks refuse to even allow a port to the
Amiga this would leave us out.  MPEG 3, while the best format in existance
at the moment would indeed be overkill.  I don't know much about AU (Sun
Audio I belive) but I do know that it's widely supported.

> Oh, one thought: It may be desirable to support two audio formats -- a
> sample format (like WAV, AU, RA...) and a note format (MIDI or MOD). A
> note format allows you to store lots of background music in very little
> space.

Ohhhhh, MOD would be extreamly cool, there are plenty of trackers out
there for creating them and they don't take up much space.  Perhaps MED
support as well?  I belive the two formats are similer but MED adds a few
features (although I can't remember what at the moment).

Patrick
---

"Every weekday morning the school bell cast its glamour over the
 surounding hills, calling the young to classes.  They came running
 down the slopes and leaping over the streams, out from caves and the
 hollows of trees and suburban tract homes, impelled by powers greater
 then their own to gain an education." 
    "The Iron Dragon's Daughter" by Michael Swanwick


From ???@??? Sat Jun 28 14:28:53 1997
Message-Id: <33B04986.E677C251@micron.net>
Date: Tue, 24 Jun 1997 16:26:15 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.0b5C (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: Patrick Kellum <patrick@syix.com>, z-machine@gmd.de
Subject: Re: [z-machine] Consensus on picture for
X-Priority: 3 (Normal)
References: <Pine.BSI.3.95.970624015908.20600C-100000@ns1.syix.com>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: fa19f8d4134a195a912454ce7c2f0e11

Patrick Kellum wrote:
> 
> On Tue, 24 Jun 1997, Graham Nelson wrote:
> 
> > Incidentally we have not yet discussed the preferred sound format.
> > Does anyone object to WAV?  Does the world agree on what WAV is,
> > or is WAV another one of these catch-all formats which can include,
> > e.g., Ethiopian nose-flute sheet music sent via a fax machine?
> > Is there a more universal choice?
> 
> I would suggest WAV, but I have been told that it uses a number of
> different compression formats, some copyright by MicroSnot.  So I suggest
> uncompressed WAVs (do such creatures exist?)
> 

Sure they do.  I believe (somebody correct me here) that WAV's are based
on a kind of mutant IFF format; you can specify any encoding/compression
format you like, including straight PCM.  The only thing I can say
against WAV as a format is that we might want something _slightly_
simpler.

--Galen

From ???@??? Sat Jun 28 14:28:54 1997
Message-Id: <33B04D2B.E3C01A8E@micron.net>
Date: Tue, 24 Jun 1997 16:41:47 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.0b5C (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: Andrew Plotkin <erkyrath@netcom.com>, z-machine@gmd.de
Subject: Re: [z-machine] Sound formats
X-Priority: 3 (Normal)
References: <Pine.SUN.3.95.970624090403.22117B-100000@netcom>
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 34927a0406cb41fab7e784acc29b1d63

Andrew Plotkin wrote:
> 
> Forgive me, but my assumption is that anything that comes out of
> Microsoft will be... [initial phrasing censored]... non-ideal. I'm not
> going to argue about it, however.

You're forgiven.

> I asked my collection of geek friends, and the suggestions they came back
> with were AU, RealAudio, and MPEG audio (layer 3).

*NOT* RealAudio.  We can't support RealAudio.  It's a Evil, Closed,
Proprietary format whose encoding/decoding algorithms are secret.  :(

> I have not investigated these technically, except to note that MPEG audio
> is probably monstrous overkill.

I don't know...maybe somebody wants to do a text game with a soundtrack,
and MPEG audio is about the only way you can get CD-quality audio with
decent compression.  We might offer this as an "optional" format, like
jpeg support for images.

> Oh, one thought: It may be desirable to support two audio formats -- a
> sample format (like WAV, AU, RA...) and a note format (MIDI or MOD). A
> note format allows you to store lots of background music in very little
> space.

This is probably a good idea.

--Galen

From ???@??? Sat Jun 28 14:28:57 1997
Date: Tue, 24 Jun 1997 22:02:16 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706250202.WAA22047@wanda.vf.pond.com>
To: markk@netcomuk.co.uk, z-machine@gmd.de
Subject: Re: [z-machine] Sound formats
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c368f43a23eb9680b1fff63901761338

} Definitely. I don't know about AU, but it would certainly be easy for authors
} to convert 'industry-standard' sample formats into signed or unsigned raw 8- or
} 16-bit data. A format for distribution could build on this, including of course
} the desired playback rate.

AU is the Sun audio format -- supports 8 bit PCM, 8 bit Mu-law, 8 bit
A-law, and 16 bit PCM, with various sampling rates.

From ???@??? Sat Jun 28 14:29:03 1997
Date: Tue, 24 Jun 1997 21:26:49 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom3
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] [blorb] Final comments on the resolution thing
Message-Id: <Pine.SUN.3.95.970623092945.8355A-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 1727074b9e41690572f275910fa9644d

Well, everybody has proposed a different scheme. (Including me.)

With a certain deliberate effort, I have managed to lose track of all the
issues that have been brought up. There was screen resolution, resizable
windows, non-square pixels, game-controlled image scaling,
interpreter-controlled image scaling, images that span the entire width or
height of the window, game (or resource) control over window size (in
z-pixels, real pixels, or physical size), game (or resource) control over
window aspect ratio (in z-pixels, real pixels, or physical size)... did I
miss anything? Oh, yeah, Graham's *original* desire to allow pictures
which have different amounts of detail depending on the available space.

I have pounded my head on this for a while, and simplified out a few
things. I hope. I was somewhat frightened to realize that I was using
Bryan Scattergood's min/max idea after all. :) In a somewhat modified
form.

Attend:

-----------

* Assumption: all image pixels are square.

Your images should have the correct aspect ratio when drawn with square
pixels -- that is, when the number of image-pixels-per-inch are the
same vertically and horizontally. If your art program doesn't
understand square pixels, get a real art program. There. That's
resolved.

(This means that if an image is 400 pixels wide and 200 pixels high,
the interpreter should draw it on the screen with a physical width
twice its physical height. Anything else will look distorted.)

* Assumption: images should always be drawn with the intended aspect
ratio.

In this proposal, images are never stretched vertically or horizontally.
They're always scaled evenly.

* Assumption: it's always ok to draw image pixels as screen pixels
(except for non-squareness adjustments.)

Now you think I'm crazy. It is true that many modern screens can be
adjusted to different pixel sizes; mine allows 55, 72, or 88 pixels per
inch. However, *I declare this to be an illusion.* If a user sets his
monitor to smaller pixels, it's because he wants a given image to be
smaller. So he can fit more of them on screen. That's the way web
browsers work, that's the way Adobe Photoshop works, and that's damn
well good enough for the Z-machine.

Perhaps in the future there will be monitors that break this rule --
much smaller pixels, 300 or 600 pixels per inch, for example. At that
time there will be some consensus on how to display images. (Frankly, I
expect it will be "draw them at 55, 72, or 88 pixels per inch,
depending on the user's previous preference.") Z-machine interpreters
can follow that plan when it emerges. 

Until then, it is always correct (absent other instructions) to draw
images at one image pixel per screen pixel. (If screen pixels are not
square... well, the user probably sees everything else in the universe
distorted as well. It would be nice if the interpreter corrects for it,
but probably not mandatory.)

* Options: The author may want to give images in a high resolution that
*can* be reduced on small displays. The author should also be able to
give images that are just plain big.

The simplest case is that the author makes a bunch of images, and says
"show these to the player, the same size I drew them." Since this is a
naive author, we naively interpret "the same size" to mean one image
pixel per screen pixel. That's good enough (as stated above). This
should be easy for the author to do.

A more clever author may want to put more detail in the picture, which
is optional detail, and only shows up if the player has an especially
large window. (Note: this occurs when the player *requests* an
especially large window, *not* when the interpreter detects an
especially small screen-pixel size.) The clever author should be
allowed to make this happen.

* Footnote: Perhaps you wish to write an interpreter which *does*
detect small screen-pixel sizes, and creates an especially large window
(as measured in screen pixels) in order to get more detail per inch.
That's fine. That's between your interpreter and your users. It is not
the concern of me, the game author, or the Z-machine; to us, it's still
the "especially large window" case.

* Now, how do we detect large windows? It's the interpreter doing this
detection, so -- bear with me -- the idea is that the game provides a
preferred window size in *screen pixels*. (Not Z-pixels. Z-pixels are
the *interpreter's private choice*. This standard will not refer to
Z-pixels. Yes! The key insight! Never speak to me of Z-pixels again.
Now we have a *simple* problem: for a given image, choose the ratio of
screen pixels to image pixels, in cases where the default value of 1 is
not good enough.) 

---

Here is the system. It is the simplest system which I think I can force
you all to accept without endangering my own life. Okay?

The game provides a standard window size. This is measured in screen
pixels. Since you planned your layout assuming that screen pixels and
image pixels are the same (for non-scaled pictures), this is easy to
figure.

(Say you have a map which you do not want scaled. The map image is
400x200 pixels. You want it displayed in the top third of the window,
spanning the entire window width (in the standard case). Your standard
window size is therefore 400x600. Easy.) 

Let us call the standard size (px, py).

The interpreter creates a window of some wacky size (wx, wy) (as
measured in screen pixels). This is entirely up to the interpreter
(although it may pay attention to the standard window size, and we may
also provide hints about the minimum and maximum preferrable window
sizes.)

The Elbow Room Factor (ERF) is now computed: ERF = min(wx/px, wy/py).
The idea is that you can take your standard screen layout and scale it
evenly by ERF, and it will still fit in the actual window. If the
window's aspect ratio does not match your standard aspect ratio, there
will be extra space on the right or the bottom. (What will *not* happen
is your layout overflowing outside the actual window. That's why we
take the smaller of the horizontal and vertical ratios.)

(Note that we still have not mentioned Z-pixels.)

By default, images are not scaled. However, you can mark an image as
scalable by giving it a scaling chunk (format to be defined.) This
chunk contains two real numbers, MAX and MIN. Then the image is scaled
evenly by a factor of ERF, but not less than MIN or more than MAX. In
other words...
    If ERF < MIN, the image is scaled by MIN.
    If ERF > MAX, the image is scaled by MAX.
    If MIN >= ERF >= MAX, the image is scaled by ERF.
If MIN = MAX, of course, the image will always be scaled by that value,
regardless of ERF.

[Footnote: when I say "real number", I don't mean the data will
actually be stored as an IEEE floating-point number. I'll pick a more
storable representation. But logically, MAX, MIN, and ERF are real
numbers.]

What about Z-pixels? That has now been completely determined! The
interpreter chooses any definition of Z-pixels it wants; nano-furlongs
and pico-lightseconds, this standard doesn't care. They don't have to
be square. The point is that an *actual* window size has been chosen,
and the actual sizes of all the images have been chosen. So the
interpreter can translate these values into Z-pixels, using its
definition of Z-pixels.

It is then the game's job to lay out things on the screen based on the
window size (in Z-pixels) and image sizes (in Z-pixels) that the
interpreter has handed it. The game should be smart about this,
following the example of Infocom's V6 games. It cannot make assumptions
about the sizes it's given; it has to check them. They could be
anything, because the interpreter decides how big Z-pixels are. 

In many cases, the game's first step should be to compute the ERF.
Unfortunately, there is no way for the interpreter to tell the game the
ERF in use; fortunately, the game can figure this out anyway, by
comparing the window size to the size of some scalable picture.

(What if there are no scalable pictures? Well, then the ERF is
meaningless, isn't it? It's only used to scale scalable pictures.)

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

There. I would very much like it if I didn't have to think about this any
more. (half :-) So does this leave any issues?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."





From ???@??? Sat Jun 28 14:29:06 1997
Date: 25 Jun 97 01:19:40 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:erkyrath@netcom.com" <erkyrath@netcom.com>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] Sound formats
Message-Id: <970625051940_104312.2206_IHS60-2@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 5e17247f423287ffca17b49363f29f35


Andrew wrote:

> Also one of the reasons for being able to use an uncompressed archive 
> format is that decent sound and image formats include compression.
> 
> I asked my collection of geek friends, and the suggestions they came
> back with were AU, RealAudio, and MPEG audio (layer 3). 
>
> I have not investigated these technically, except to note that MPEG
> audio is probably monstrous overkill.

I don't think RealAudio is going to be viable; the format is 
proprietary and licensing the codec involves legal departments.

AU is the simple format used by Suns, right?

    Bryan

 


From ???@??? Sat Jun 28 14:29:07 1997
Date: 25 Jun 97 01:19:46 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re:  [z-machine] Catch, throw and save
Message-Id: <970625051946_104312.2206_IHS60-4@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 65455853a70779dbd543384311bc58c1


Matthew wrote:

<snip useful info about the scarcity of catch/throw>

>} 3) How many interpreters have shipped which support the current >} 
Quetzal specification?
> 
> To my knowledge, one, but no "catch" support in that interpreter
> (ZPlet)
> 
> Unfortunately, ZIP save files cannot be converted to QUETZAL because
> there's no way of knowing the # of locals :-(

It turns out ITF has a similar problem.  The number of locals is 
recorded for the *previous* stack frame (information for the current 
frame is held in a global variable for the check_arg_count opcode).  
Alas, it is only recorded for Z5.  The <Z5 call opcodes don't seem to 
bother maintaining that information.  And the 'supplied arguments' 
bit-vector that Quetzal needs is even worse.

It looks like conversion is out, and even producing an interim release 
which can read/write both forms (but has to save the last one loaded) 
is going to mess up the source horribly.

    Bryan

 


From ???@??? Sat Jun 28 14:29:11 1997
Message-Id: <199706250703.JAA02551@dns.speednet.it>
X-Mailer: Microsoft Outlook Express 4.71.0544.0
From: "Giovanni Riccardi" <g.riccardi@speednet.it>
To: "z-machine mailing list" <z-machine@gmd.de>
Subject: Re: [z-machine] Sound formats
Date: Wed, 25 Jun 1997 09:09:23 +0200
X-Priority: 3
X-Msmail-Priority: Normal
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: 845ee49083b103f146121162f5f8ad32

Andrew Plotkin wrote: 

>Oh, one thought: It may be desirable to support two audio formats -- a
>sample format (like WAV, AU, RA...) and a note format (MIDI or MOD). A
>note format allows you to store lots of background music in very little
>space.


MOD is not properly a note format (or better, it is not only a note
format).
It is someway a mixed format containing first all the samples (depending on

the file format,  some can contain up to 30 samples) and then the notes 
divided in tracks (or channels).
If I remenber well, most of the trackers store the samples in AU or IFF
format,
so I think if  we are going to implement the MOD format a good choice for
the
sample format would be AU or IFF.
I'm not an expert programmer but I know that MOD has always been used by
demo coders to add music to their works (on every platform) being a
compact
and easily portable format.
Note that even the old Soundtracker Mod format ( 8 bit samples and 4
channels)
plays good on my PC while MID format heavily depends on machines (not all
computer has MIDI).
On my little experience on MOD, I've exeperimented that a good sound does 
depend less on bit resolution than frequency (22kHz at least).
Another note: there are lots of free mods and free samples around the
net!!!

I suggest a format (among all the mod formats avalaible) with this
features:

*    8 channels 
*    16 bit sample resolution (even if you'll use 8 bit for samples)
*    up to 44khz frequency.

bye 
Giovanni.


       \IIIII/
       (o) (o)
---oOO-- (_) --OOo----------------------------------
                          "How do you know I'm mad?"
                          said Alice. "You must be,"
  Giovanni  Riccardi      said the Cat "or you 
g.riccardi@speednet.it    wouldn't have come here."
   Terracina  Italy
                          - L. Carrol "Alice's 
                           Adventures in Wonderland"
----------------------------------------------------

   





From ???@??? Sat Jun 28 14:29:13 1997
Message-Id: <199706250910.LAA03249@dns.speednet.it>
X-Mailer: Microsoft Outlook Express 4.71.0544.0
From: "Giovanni Riccardi" <g.riccardi@speednet.it>
To: "z-machine mailing list" <z-machine@gmd.de>
Subject: [z-machine] The Infix Project Newsletter #4 
Date: Wed, 25 Jun 1997 11:15:07 +0200
X-Priority: 3
X-Msmail-Priority: Normal
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: 8ff0e83b20006dbfa220972395b66069

                        ===============================
                        THE INFIX PROJECT NEWSLETTER #4       
                        Infix Group official newsletter
                        ===============================                    
                                              
                     
                        Published by  Giovanni Riccardi
                  

No editorial or comments this time. Just a transcript from an 
adventure game that (I'm quite sure) I'll have to play next year in this 
period.
 
I can't understand how I got such a premonition (some days ago confirmed  
in a consultation of the Tarot Cards).
So go on reading this newsletter....
                                                     Giovanni  Riccardi
                                                      "The Mad Hatter"
                                                      June, 25th, 1997








    
  
                    ------------------------------------
                    |  "Twinkle, twinkle, little bat!  |
                    |   How I wonder what you're at!   |
                    |   Up above the world you fly,    |
                    |   like a tea-tray in the sky."   |
                    |                                  |
                    |  - L. Carroll "Alice's Adventures|
                    |                    in Wonderland |
                    ------------------------------------

                               THE INFIX DAY
                        [Please press SPACE to begin]




The day has come!! After so many months of hard work the project will be 
publically presented next week on rec.arts.int-fiction newsgroup.
Before that day you have organised a party with all the people involved in

the project: THE INFIX GROUP...


THE INFIX DAY
An Interactive Tea-Party.
Copyright (c) 1998 by Giovanni Riccardi
Release 1 / Serial 980621 / Inform 7.01 Library 7/2
Standard interpreter 1.0


Front of the House
 You are in front of your house, just closed the door behind your back.
 You can see a table set out under a tree and some people having tea at
 it. They're waiting for you...

> GO TO TABLE

At the table under the tree
 As you approach to the table all the people stop their conversation and 
 look at you in a strange way you don't understand. There's an empty chair

 waiting for you.

> SIT DOWN 

At the table under the tree (on the chair)
 As you sit down you can hear a voice inside you.
 The voice says: "Say some words to celebrate this day."
 You remember you have written something on a paper sheet.
 That sheet is in your pocket.

> TAKE THE SHEET

 The paper sheet is in your hands now.


> READ WORDS ON THE SHEET
 
 You beging to read: "Dear friends, this is an important day for
 all of us..." (applause) "It's the first time we are all together 
 in the same place and I want to thank you for the work you have
 done (and it was an hard work indeed)" (another applause) "It's 
 the first time so many people around the world work to the same
 project". (a little pause, then you continue to read) "But now 
 it's time to see our creature. 
 Ladies (where??) and Gentlemen I'm proud to present INFIX: The
 Inform Debugger".

 No applause this time but a voice saying "INFIX, WHAT???"




       \IIIII/
       (o) (o)
---oOO-- (_) --OOo----------------------------------
                          "How do you know I'm mad?"
                          said Alice. "You must be,"
  Giovanni  Riccardi      said the Cat "or you 
g.riccardi@speednet.it    wouldn't have come here."
   Terracina  Italy
                          - L. Carrol "Alice's 
                           Adventures in Wonderland"
----------------------------------------------------



      


From ???@??? Sat Jun 28 14:29:15 1997
Date: Wed, 25 Jun 1997 11:22:26 +0100 (BST)
From: Dan J Archer <D.Archer@uea.ac.uk>
X-Sender: u9537872@cpca5.uea.ac.uk
To: Giovanni Riccardi <g.riccardi@speednet.it>
Cc: z-machine mailing list <z-machine@gmd.de>
Subject: Re: [z-machine] Sound formats
In-Reply-To: <199706250703.JAA02551@dns.speednet.it>
Message-Id: <Pine.OSF.3.91.970625110831.22392B-100000@cpca5.uea.ac.uk>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: f3c51b5856ca16dd01d1a895521fc9ca

On Wed, 25 Jun 1997, Giovanni Riccardi wrote:

> MOD is not properly a note format (or better, it is not only a note
> format).
> It is someway a mixed format containing first all the samples (depending on
> 
> the file format,  some can contain up to 30 samples) and then the notes 
> divided in tracks (or channels).
> If I remenber well, most of the trackers store the samples in AU or IFF
> format,
> so I think if  we are going to implement the MOD format a good choice for
> the
> sample format would be AU or IFF.

Yesindeed, tracks are usually of a fixed length (60 positions), and 4 
channels in the old format. Each position can hold a a note or a space, 
with the tracker (player) walking down each track at given speed (which 
can be changed using special codes at any position in any track). 
Patterns are set up, which are lists of tracks to play in the desired 
order: repeats are therefore possible.

Samples are stored at the head of the file, in IFF or RAW format 
originally. The old SoundTracker format has been bastardised and modified 
by every single tracker since, putting in their own features. The only 
problem I see of using MODs, therefore, would be defining what codes the 
interpreter's player supports (vibrato, volume, track skip, etc.) and 
then finding a tracker out there which conforms...or authors would be 
restricted to using only those features of their tracker which the standard 
acknowledges.

Sample formats may well be a problem: I know some PC trackers stick with 
WAVs or AU nowadays rather than IFF/RAW, and that Amiga trackers don't 
know the word WAV.

Perhaps the solution is to define a ZMOD format (possibly IFF-ZMOD) along 
the same lines as existing trackers but with the advantage of being able 
to specify what the sound format is, what codes are supported, etc.

> Note that even the old Soundtracker Mod format ( 8 bit samples and 4
> channels)
> plays good on my PC while MID format heavily depends on machines (not all
> computer has MIDI).

This is true. I also personally hate MIDI, and would insist that 
interpreters permit it to be disabled by the user: without an AWE32 
soundcard (yes, I'm now a PC owner) it sounds absolutely awful. I am a 
great fan of MOD files.

> Another note: there are lots of free mods and free samples around the
> net!!!

Again, an excellent point, particularly on the sample front.

> I suggest a format (among all the mod formats avalaible) with this
> features:
> 
> *    8 channels 
> *    16 bit sample resolution (even if you'll use 8 bit for samples)
> *    up to 44khz frequency.

This might present a problem on some machines - 8 channels are only 
available on the Amiga through clever hardware manipulation, which 
interpreter writers should be best shielded from. I don't know about 
other platforms, but the PC would likely cope fine.

Taking a step back for a minute, isn't this whole process drastically 
increasing the amount of work interpreter writers have to perform? A 
while back their only (haha) task was to fully support the z-machine 
standard for versions V3-V8, and now the z-machine has this multi-media 
extravaganza idea attached to it...is the end result worth the pain it 
will cause interpreter writers? I think it's worth watching what we're 
creating here, and at each step making sure we're not aiming too 
high...

When the standard for this resource format comes out it's probably worthy 
of review by an experienced programmer on all major z-machine platforms 
(Amiga, Mac, PC, Archimedes, etc.) to ensure that no drastic hackery or 
"clever" coding is required to implement it. After all, until now the 
z-machine interpreter has been implementable in standard C.

	Dan.




Athankye.

 /----------------------------------------------------------------------\
/ "A friend of mine did ride astride with tattered hat and stalk of hay: \
\  He carried buckets of giraffe, and hairless errors 'pon a tray."      /
 \----------------------------------------------------------------------/
 /        D.Archer@uea.ac.uk      |   http://www.uea.ac.uk/~u9537872/   \ 
 \----------------------------------------------------------------------/


From ???@??? Sat Jun 28 14:29:23 1997
Date: Wed, 25 Jun 1997 13:28:40 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Sound formats
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.OSF.3.91.970625110831.22392B-100000@cpca5.uea.ac.uk>
Message-Id: <Marcel-1.09-0625122840-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: 23a543d378cf30e32090fc984fd6eb88

On Wed 25 Jun, Dan J Archer wrote:
> Taking a step back for a minute, isn't this whole process drastically 
> increasing the amount of work interpreter writers have to perform? A 
> while back their only (haha) task was to fully support the z-machine 
> standard for versions V3-V8, and now the z-machine has this multi-media 
> extravaganza idea attached to it...is the end result worth the pain it 
> will cause interpreter writers? I think it's worth watching what we're 
> creating here, and at each step making sure we're not aiming too 
> high...

I didn't intend a multimedia extravaganza when I kicked off this
thread -- only a way of realising an ability the Z-machine already
has.  We're currently in the position where many interpreters
have no problem running old games with graphics and sound (Arthur,
Sherlock, etc.) but where we can't write any new ones simply
because the existing formats are too idiosyncratic.  I only
proposed a way to bundle up pictures and sounds more easily!

I certainly think "Blorb" should be minimal in character,
consistent with making at least medium-quality graphics and sound
available.  But I also think that's what Andrew is doing, and the
next draft of the proposal will be simpler and easier to understand
than much of the debate about it...

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Jun 28 14:29:29 1997
Date: Wed, 25 Jun 1997 09:50:58 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706251350.JAA23180@wanda.vf.pond.com>
To: 104312.2206@compuserve.com, z-machine@gmd.de
Subject: Re:  [z-machine] Catch, throw and save
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 2371203ef63dcf23a8f0bdf0427d7a44

} >} 3) How many interpreters have shipped which support the current >} 
} Quetzal specification?
} > 
}> To my knowledge, one, but no "catch" support in that interpreter
}> (ZPlet)
}> 
} > Unfortunately, ZIP save files cannot be converted to QUETZAL because
}> there's no way of knowing the # of locals :-(

} It turns out ITF has a similar problem.  The number of locals is 
} recorded for the *previous* stack frame (information for the current 
} frame is held in a global variable for the check_arg_count opcode).

ZPlet does this too -- it makes the code a wee bit more complicated (all
right, it makes it a <censored> mess), but it can be handled.

} Alas, it is only recorded for Z5.  The <Z5 call opcodes don't seem to 
} bother maintaining that information.  And the 'supplied arguments' 
} bit-vector that Quetzal needs is even worse.

I think that vector is a case of unnecessary generality in Quetzal.  I
wouldn't change it now, but I currently refuse any files which have
"missing" arguments.  It's not really possible to write a call opcode to
do that according to the Standard, anyway --

4.4.3

In variable or extended forms, a byte of 4 operand types is given
next. This contains 4 2-bit fields:  bits 6 and 7 are the first field,
bits 0 and 1 the fourth. The values are operand types as above. *Once
one type has been given as 'omitted', all subsequent ones must
be.*

(emphasis mine)

} It looks like conversion is out, and even producing an interim release 
} which can read/write both forms (but has to save the last one loaded) 
} is going to mess up the source horribly.

I wouldn't try to work conversion into your ITF code, but a separate
utility IS possible -- you can use the analysis phase of txd to find all
of the 'call' instructions.  I'm not sure it would be worth the
effort.

From ???@??? Sat Jun 28 14:29:27 1997
Date: Wed, 25 Jun 1997 08:33:02 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Sound formats
In-Reply-To: <Pine.OSF.3.91.970625110831.22392B-100000@cpca5.uea.ac.uk>
Message-Id: <Pine.SUN.3.95.970625082002.22727A-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 73eb648ce56daed859bbc80191181f3a

On Wed, 25 Jun 1997, Dan J Archer wrote:

> On Wed, 25 Jun 1997, Giovanni Riccardi wrote:

> Perhaps the solution is to define a ZMOD format (possibly IFF-ZMOD) along 
> the same lines as existing trackers but with the advantage of being able 
> to specify what the sound format is, what codes are supported, etc.

Perhaps the solution is to pick a single sample format and stick with it.
IMHO. 
 
> Taking a step back for a minute, isn't this whole process drastically 
> increasing the amount of work interpreter writers have to perform? A 
> while back their only (haha) task was to fully support the z-machine 
> standard for versions V3-V8, and now the z-machine has this multi-media 
> extravaganza idea attached to it...is the end result worth the pain it 
> will cause interpreter writers? I think it's worth watching what we're 
> creating here, and at each step making sure we're not aiming too 
> high...

I am not unaware of the concern (since I'm an interpreter writer). I'm
really trying to require minimal functionality *given* that the
interpreter writer has decided to support sound (or graphics.)

If you've decided to write a V6 interpreter, you've decided to support
graphics. Sound is more general, but it's still not mandatory for an
interpreter to play sounds; the question is what format they will be
supplied in if you *do* want them.

Simplicity is the reason that I'm declaring a single graphics format and a
single sample-sound format (and I only suggested a second music-sound
format because of great potential benefit.) 

> When the standard for this resource format comes out it's probably worthy 
> of review by an experienced programmer on all major z-machine platforms 
> (Amiga, Mac, PC, Archimedes, etc.) to ensure that no drastic hackery or 
> "clever" coding is required to implement it. After all, until now the 
> z-machine interpreter has been implementable in standard C.

I've already posted a draft of the standard, and nobody complained much.
Unless my comments on resolution inspire great hatred, I'll post a final
copy tonight.

Requirements at this point are: decode IFF files (already required by the
common save file format), decode PNG images, and be able to display images
of any color depth and (possibly) arbitrary scaling. The last is the most
demanding, but there's plenty of sample code, and there's no requirement
that you handle scaling and color-downcutting *well*. An interpreter that
displays 32-bit color images badly is still a conforming interpreter. (It
may lose market share if another interpreter comes out that displays them
well. This is expected.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:29:24 1997
Message-Id: <199706251653.SAA05928@dns.speednet.it>
X-Mailer: Microsoft Outlook Express 4.71.0544.0
From: "Giovanni Riccardi" <g.riccardi@speednet.it>
To: "z-machine mailing list" <z-machine@gmd.de>
Subject: R: [z-machine] Sound formats
Date: Wed, 25 Jun 1997 18:59:08 +0200
X-Priority: 3
X-Msmail-Priority: Normal
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain;
	charset="us-ascii"
X-UIDL: 228e6aab68a346272c08ab97db56fefb

Dan J. Archer wrote
>> *    8 channels
>> *    16 bit sample resolution (even if you'll use 8 bit for samples)
>> *    up to 44khz frequency.
>
>This might present a problem on some machines - 8 channels are only
>available on the Amiga through clever hardware manipulation, which
>interpreter writers should be best shielded from. I don't know about
>other platforms, but the PC would likely cope fine.

Mod players and trackers use so many channels only because someone
can work on a file and modify it (an instrument for each channel).
We can work on 8 or more channels if we want but z-machine has only to 
play stereo sound (2 channels) so we can convert the file to a max. of
4 channels.
Amiga users could be hear that sound...

bye 
Giovanni

       \IIIII/
       (o) (o)
---oOO-- (_) --OOo----------------------------------
                          "How do you know I'm mad?"
                          said Alice. "You must be,"
  Giovanni  Riccardi      said the Cat "or you 
g.riccardi@speednet.it    wouldn't have come here."
   Terracina  Italy
                          - L. Carrol "Alice's 
                           Adventures in Wonderland"
----------------------------------------------------

 


From ???@??? Sat Jun 28 14:29:21 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Wed, 25 Jun 1997 18:19:20 -0000
Message-Id: <yam7115.1032.4465088@smtp.netcomuk.co.uk>
In-Reply-To: <Pine.SUN.3.95.970623092945.8355A-100000@netcom>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] [blorb] Final comments on the resolution thing
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: f4b44f78e964f411261cf9afeb9e9dbd

On 25-Jun-97, Andrew Plotkin wrote:
>* Assumption: all image pixels are square.

>Your images should have the correct aspect ratio when drawn with square
>pixels -- that is, when the number of image-pixels-per-inch are the
>same vertically and horizontally. If your art program doesn't
>understand square pixels, get a real art program. There. That's
>resolved.

>(This means that if an image is 400 pixels wide and 200 pixels high,
>the interpreter should draw it on the screen with a physical width
>twice its physical height. Anything else will look distorted.)

Only problem is, this is not the case for all current graphical V6 games, which
use a 320x200 pixel screen. (The screen would have had to be 320x240 for a 1:1
aspect ratio.)

-- Mark


From ???@??? Sat Jun 28 14:29:17 1997
Date: Wed, 25 Jun 1997 11:36:46 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments on the resolution thing
In-Reply-To: <yam7115.1032.4465088@smtp.netcomuk.co.uk>
Message-Id: <Pine.SUN.3.95.970625112907.27849B-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 1a6fbc70c456e2629e7f57faa1ed716b

On Wed, 25 Jun 1997, Mark wrote:

> On 25-Jun-97, Andrew Plotkin wrote:
> >* Assumption: all image pixels are square.
> 
> >Your images should have the correct aspect ratio when drawn with square
> >pixels -- that is, when the number of image-pixels-per-inch are the
> >same vertically and horizontally. If your art program doesn't
> >understand square pixels, get a real art program. There. That's
> >resolved.
> 
> >(This means that if an image is 400 pixels wide and 200 pixels high,
> >the interpreter should draw it on the screen with a physical width
> >twice its physical height. Anything else will look distorted.)
> 
> Only problem is, this is not the case for all current graphical V6 games, which
> use a 320x200 pixel screen. (The screen would have had to be 320x240 for a 1:1
> aspect ratio.)

I believe you misunderstand. I wasn't talking about screen (window) size;
I was talking about image size.

All the images in Infocom's games are drawn with square pixels (when
played on the Mac, using Infocom's Mac interpreter.) The images look fine. 
Therefore, they follow my assumption. Close enough, anyway. 

Does Frotz apply a small vertical distortion when displaying Infocom
graphics on a square-pixel screen? If not, I don't think there's any need
to start now.

--Z


"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:29:20 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Wed, 25 Jun 1997 18:56:00 -0000
Message-Id: <yam7115.45.4205336@smtp.netcomuk.co.uk>
In-Reply-To: <199706251653.SAA05928@dns.speednet.it>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: R: [z-machine] Sound formats
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: ec23b0d0c15742b3324e30eb4c7469dc

On 25-Jun-97, Giovanni Riccardi wrote:
>>This might present a problem on some machines - 8 channels are only
>>available on the Amiga through clever hardware manipulation, which
>>interpreter writers should be best shielded from. I don't know about
>>other platforms, but the PC would likely cope fine.

>Mod players and trackers use so many channels only because someone
>can work on a file and modify it (an instrument for each channel).
>We can work on 8 or more channels if we want but z-machine has only to 
>play stereo sound (2 channels) so we can convert the file to a max. of
>4 channels.
>Amiga users could be hear that sound...

Amiga users can just use AHI, a device-independent audio system. There is no
problem.

-- Mark


From ???@??? Sat Jun 28 14:29:26 1997
Date: Wed, 25 Jun 1997 13:34:43 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments on the resolution thing
In-Reply-To: <Pine.SUN.3.95.970625112907.27849B-100000@netcom>
Message-Id: <Pine.SUN.3.95.970625132345.795A-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 4de3a9bfc8261b316c4a9080e95a2bb7

On Wed, 25 Jun 1997, Andrew Plotkin wrote:

> On Wed, 25 Jun 1997, Mark wrote:
> 
> > On 25-Jun-97, Andrew Plotkin wrote:
> > >* Assumption: all image pixels are square.
> > 
> > Only problem is, this is not the case for all current graphical V6 games, which
> > use a 320x200 pixel screen. (The screen would have had to be 320x240 for a 1:1
> > aspect ratio.)
> 
> I believe you misunderstand. I wasn't talking about screen (window) size;
> I was talking about image size.

Duh, never mind, I see what you meant. The art was (more or less) designed
for old IBM displays, which had 320x200 pixels in a rectangle whose aspect
ratio was 4:3. (I forget what the Apple II pixel size was. How
embarrassing.) 

Nonetheless, this is still true:
 
> All the images in Infocom's games are drawn with square pixels (when
> played on the Mac, using Infocom's Mac interpreter.) The images look fine. 
> Therefore, they follow my assumption. Close enough, anyway. 
> 
> Does Frotz apply a small vertical distortion when displaying Infocom
> graphics on a square-pixel screen? If not, I don't think there's any need
> to start now.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:29:32 1997
Date: 26 Jun 97 01:34:43 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments o
Message-Id: <970626053443_104312.2206_IHS45-1@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c1f2b3b3ff0d8478b971a112ef0d4b0c


Andrew wrote:

<< By default, images are not scaled. However, you can mark an image as
scalable by giving it a scaling chunk (format to be defined.) This
chunk contains two real numbers, MAX and MIN. Then the image is scaled
evenly by a factor of ERF, but not less than MIN or more than MAX. In
other words...
    If ERF < MIN, the image is scaled by MIN.
    If ERF > MAX, the image is scaled by MAX.
    If MIN >= ERF >= MAX, the image is scaled by ERF.
If MIN = MAX, of course, the image will always be scaled by that value,
regardless of ERF.
 
[Footnote: when I say "real number", I don't mean the data will
actually be stored as an IEEE floating-point number. I'll pick a more
storable representation. But logically, MAX, MIN, and ERF are real
numbers.] >>

[Deep breath.]

This is kind of like the stuff I proposed, but  you've simplified it by 
insisting that the aspect ratio must be preserved and that the resource 
file supplies a canonical screen size. I think *always* locking the 
aspect ratio may be a mistake (based on the fact that I code for 
machines with weird screen geometries like 480x160), but I could be 
wrong on that.

Since MIN and MAX are bounds on the scale factor of a particular image 
(which we know the stored size of), you don't need to store them as 
"reals".  You can store them as bounds on the image size after scaling.

That means that the MAX field ought to be optional (or have a special 
'don't care' value) to prevent authors inserting random large numbers 
which turn out not to be large enough. (I avoided that problem by 
making the bounds relative the screen size not the image.  I wish I 
could claim it was intentional.)

The rules have 'ERF < MIN implies scale by MIN'.  That implies the 
image might not fit in the screen after scaling.  What happens then?  
The image is clipped?  If so, at which edges?  Refusing to plot the 
image seems unreasonable (the Z-code could calculate from information 
available that it won't fit; if it still asked to plot the image, it 
presumably meant it.)

This is all good fun, but do we have to reserve graphics for Z6?  
(Given that mentioning the Z6 machine seems to cause many of the 
interpreter writers to flinch.)  Is there any way we can implement 
simple graphics (something like the block quotes which seem so popular) 
without breaking Z5 compatibility?

    Bryan

 


From ???@??? Sat Jun 28 14:29:35 1997
Date: Wed, 25 Jun 1997 23:07:04 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom4
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Blorb proposal 0.9
Message-Id: <Pine.SUN.3.95.970625224929.16285A-100000@netcom4>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: eb62cb1573c2264660e51ecacefc6ce8

...has been uploaded to ftp.gmd.de. Currently in /incoming/if-archive,
eventually to move to /if-archive/infocom/interpreters/specification.

It's grown to a somewhat embarrassing 30K long, which is why I'm not
posting it here. However, fully a third of that is the "Rationales and
Rationalizations" section. And there are a lot of examples in there too,
particular of the scaling/resolution rules. (Icko, BTW. My earlier
proposal turned out to be just a *little* less flexible than it needed to
be. The change was fairly minor.) 

Also, all the complicated stuff is optional for the game author; he
doesn't have to give a color palette, scaling factors, release number, or
game identifier unless he wants to. 

Some of the complicated stuff is optional for the interpreter author as
well; he can ignore the palette and game identifier. 

On the other hand, the interpreter must deal with the scaling factors and
release number if they are present, so it's not a complete cakewalk.
Sorry. 

I'll give it a few days for final comments, with the usual "this had
better be earthshaking" filter. Then I'll declare it release 1.0 and
the hell with it. 

The only issue still unresolved, as far as I know, is the sound format.
There's no hurry on that, since it's a trivial addition to the spec; I'm
willing to leave it "to be determined" in the 1.0 spec.

...I was literally typing the last paragraph of this when a Blorb comment
arrived from Bryan Scattergood. I'm reeeeally tempted to hit "send"
without reading it... :-) Oh, ok.

...whew, nothing earthshaking. Heh. More comments in direct reply. Enjoy
the spec.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."




From ???@??? Sat Jun 28 14:29:37 1997
Date: Wed, 25 Jun 1997 23:30:57 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom4
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments o
In-Reply-To: <970626053443_104312.2206_IHS45-1@CompuServe.COM>
Message-Id: <Pine.SUN.3.95.970625230709.16285B-100000@netcom4>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 505fac8929fe3e058953a5e2e8246c1f

On 26 Jun 1997, Bryan Scattergood wrote:

> This is kind of like the stuff I proposed, but  you've simplified it by 
> insisting that the aspect ratio must be preserved and that the resource 
> file supplies a canonical screen size.

Yes. (Actually the canonical screen size is snarfed from Stephan Jokisch's
suggestions.) 

> I think *always* locking the 
> aspect ratio may be a mistake (based on the fact that I code for 
> machines with weird screen geometries like 480x160), but I could be 
> wrong on that.

What machine is that? I was really unaware there were any (unless it's a
dedicated game console or some WebTV-like mutation.) 

In any case, it's not exactly locking the aspect ratio. It's saying

1) If you create art on your 480x160 monitor, with bizarre elongated
pixels, it's your responsibility to squash it back to normality before you
upload it to GMD.

2) If you write an interpreter for your 480x160 machine, you'll have to
make it stretch the square-pixel images before displaying them. Or else
your users will complain a whole lot.

> Since MIN and MAX are bounds on the scale factor of a particular image 
> (which we know the stored size of), you don't need to store them as 
> "reals".  You can store them as bounds on the image size after scaling.

Could have, but I wanted a procedure which would generate a single scaling
number. Then the image display routine is handed one image and one number
and told "do it." Simpler statement of the problem. (And if there are no
scalable images, the number is always 1.0. So the simplest case is also
easy.)

> That means that the MAX field ought to be optional (or have a special 
> 'don't care' value)

Done.

> The rules have 'ERF < MIN implies scale by MIN'.  That implies the 
> image might not fit in the screen after scaling.  What happens then?  

This is not a problem caused by the scaling system; even non-scaled images
may be too big for the screen. Since the @draw_picture opcode is given the
top left corner position, the bottom and right edges are clipped.

> This is all good fun, but do we have to reserve graphics for Z6?  

Ha! Ha! Kill me. 

> (Given that mentioning the Z6 machine seems to cause many of the 
> interpreter writers to flinch.)  Is there any way we can implement 
> simple graphics (something like the block quotes which seem so popular) 
> without breaking Z5 compatibility?

Something could undoubtedly be managed. It might or might not be unusably
damaging to both the Z5 and graphics capabilities. (Interesting that you
mention block quotes. I repeat my oft-repeated rant that block quotes,
themselves, are an extremely ugly use of Z5, and cause interpreter writers
a lot of pain.) 

It would definitely require a lot of interpreter rewriting. My first-cut
guess (without studying the problem) is that it would be easier to add
some kind of graphics to MaxZip than to add full Z6 support -- but not an
order of magnitude easier.

Also, remember that many Z5 interpreters are text-terminal programs rather
than graphic-window programs. Even if the code was easy(ish) to add to
some Z5 interpreters, it would still be impossible for others.

Hi. I'm being all negative and depressing again. Sorry.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:29:40 1997
Date: Thu, 26 Jun 1997 00:00:31 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom4
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments o
In-Reply-To: <Pine.SUN.3.95.970625230709.16285B-100000@netcom4>
Message-Id: <Pine.SUN.3.95.970625235041.20740A-100000@netcom4>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 042df8ebaf29cc8c00ada00299791d11

On Wed, 25 Jun 1997, Andrew Plotkin wrote:

> On 26 Jun 1997, Bryan Scattergood wrote:

> > I think *always* locking the 
> > aspect ratio may be a mistake (based on the fact that I code for 
> > machines with weird screen geometries like 480x160), but I could be 
> > wrong on that.
> 
> What machine is that? I was really unaware there were any (unless it's a
> dedicated game console or some WebTV-like mutation.) 
> 
> In any case, it's not exactly locking the aspect ratio. It's saying
> 
> 1) If you create art on your 480x160 monitor, with bizarre elongated
> pixels, it's your responsibility to squash it back to normality before you
> upload it to GMD.
> 
> 2) If you write an interpreter for your 480x160 machine, you'll have to
> make it stretch the square-pixel images before displaying them. Or else
> your users will complain a whole lot.

Whoops, and also:

3) If you want a tall skinny image, make a tall skinny piece of art. Don't
expect the interpreter to stretch your aspect ratios for you; that's an
artistic matter. The interpreter has its hands full dealing with size,
resolution, and detail levels.

To rephrase from a different angle:

If the user picks a different window size, or a different screen
resolution, he wants to see more or less stuff. That's what the scaling
rules do; they give the game the ability to intelligently show the user
more or less stuff. However, the user does *not* want to see your art
distorted. Bigger or smaller, yes. More or less detail, yes. Distorted
aspect ratio, no.  Therefore, the scaling rules have no provision to
change the aspect ratio of a piece of art.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:29:41 1997
Message-Id: <c=US%a=ATTMAIL%p=HOECHST%l=BRW-EXC-03-970626143153Z-1508@brw-exc-02.bridgewater.ne.hcc.com>
From: "Kennedy, John ,HiServ/NA" <JKENNEDY@himail.hcc.com>
To: "'z-machine'" <z-machine@gmd.de>
Subject: RE: [z-machine] Non-V6 pictures?
Date: Thu, 26 Jun 1997 10:31:53 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 85 TEXT
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c09b41efafba246ad3824d5f98014eb6

>This is all good fun, but do we have to reserve graphics for Z6?  
>(Given that mentioning the Z6 machine seems to cause many of the 
>interpreter writers to flinch.)  Is there any way we can implement 
>simple graphics (something like the block quotes which seem so popular) 
>without breaking Z5 compatibility?
>
>    Bryan

In a sense, yes, it must be V6, because only V6 has the ability to map
text in the presense of pictures.  However, as you suggest, there are
simpler displays that could be implemented otherwise.

This is of interest to me, too; I've been toying with the idea of a
web-hosted
interpreter, not a Java-hosted interpreter, but a z-machine webserver,
with a Java applet at the client to display the text and accept input.
There would thus be no interaction between the graphics and the text
window, which eliminates the need for the full V6 feature set.

However, this involves the Z-machine standard, which is already all but
finalized, because V6 is the only version that includes a
display-graphics
instruction.  There is no interpreter-defined escape instruction that
could
otherwise be used, is there?

May I propose the following for the next version of the standard?

   Allow the interpreter to set the "pictures" bit in the header in
non-V6.

   Allow the program to use the "pictures" opcodes in non-V6, but
   require them to be segregated from the text -- that is, as far as
   the Z machine is concerned, there are two screens -- a text
   screen and a graphics screen.

   Define additional extended-header fields to provide the game
   with the graphics-screen size.

   Define an mouse-click-on-the-graphics-screen input protocol.

   Ignore the pictures if they cannot be displayed.

   Require the program to query the "pictures" bit and complain
   if the pictures are needed to play, and not pure decoration.

Here is a possible alternative:

   Instead of defining the size of the graphics screen, redefine
   the draw-picture opcode.  x is a window number, y is zero.
   Open a new host window for each new value of x.  Close
   the window if the picture in it is erased; close and recreate
    if a new picture of different size is displayed.

   However:  do we want both?  Must an interpreter support
   both?  If so, how does the game indicate which?  If not,
   must a game support both?  (The interpreter could indicate
   the multi-window support simply by passing the size of
   the graphics screen as 0x0.)

Note that, quite apart from the fact that the 1.0 standard is
supposed to be all but finalized, this apparently cannot be
done without a new version of the standard, unless it can
be clearly defined that no interpreter issued to date
implements the 1.0 standard, in which case I think this
proposal is simple enough and free enough of side effects
at the Z-machine level that it could, in theory, still be added.
The problems are the requirement to recognize and ignore
the picture opcodes outside of V6 and the requirement to
ensure that the "pictures" bit is clear in non-V6 if the
interpreter does not implement non-V6 pictures.  If existing
interpreters are regarded as implementing "1.0" and do not
do these things, then there is a danger of crashing.

A minor change might be needed for Inform, to permit these
things under non-V6, unless it already does inadventantly.

(By the way, I should introduce myself.  I created the
OS/2 versions of ITF and ZIP, and ported Inform V5 to
OS/2 -- someone else caught V6.  I also compiled
-- and partly corrected, though there's still a scrolling-if-
column-80-is-nonblank problem I don't understand UNIX
termio well enough to bring to heel -- the Silicon Graphics
version of ZIP.  I've been out of the Z-machine loop
>for a while, but I'm back now.)

From ???@??? Sat Jun 28 14:29:45 1997
Date: Thu, 26 Jun 1997 16:01:15 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] [blorb] Final comments o
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <970626053443_104312.2206_IHS45-1@CompuServe.COM>
Message-Id: <Marcel-1.09-0626150115-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: e7342b3646f9fd1a47bdb2aaccfe4511

On Thu 26 Jun, Bryan Scattergood wrote:
> 
> This is all good fun, but do we have to reserve graphics for Z6?  
> (Given that mentioning the Z6 machine seems to cause many of the 
> interpreter writers to flinch.)  Is there any way we can implement 
> simple graphics (something like the block quotes which seem so popular) 
> without breaking Z5 compatibility?

(Poking a stick right into the ants' nest and giving it a good
stir)

Interpreter writers flinch from the _reputation_ of Z6 as much as
the actuality.  For a long time Z6 has been documented only in
long, confusing wrangles, one always contradicting another one,
provoking headaches about where the cursor should go and when the
buffer flushes and...

But standard 1.0 actually has all the information in one place,
and is often simpler than 0.2, and we can look at the Z6 format
a bit more in the round.  Given that the format has to be smart
enough to handle graphics, what is difficult in Z6?  I can really
only see:

  Menus (which you don't need to provide anyway)
  Newline interrupts (which you probably already have the technology
      for if your interpreter core supports sound effect interrupts)
  Having to scroll rectangular portions of the screen downwards
      (which is a nuisance, but probably not a terrible one)

One of the nuisance factors is that Z6 is not easy to test, as the
Infocom files make too extensive a use of the format to make good
early test files -- but Inform 6 does assemble Z6 correctly and you
can set up test-one-opcode-at-a-time files.

Now that I think about it, perhaps there should be a TerpEtude.Z6
story file...

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Jun 28 14:29:43 1997
Message-Id: <19970626170832.60221@bartlet.df.lth.se>
Date: Thu, 26 Jun 1997 17:08:32 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: [z-machine] Jzexe files as input
Mime-Version: 1.0
X-Mailer: Mutt 0.64
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 011313a8328e1ccd2ebe34938e10db54

I've been lurking on this list for some time, listening with interest
to the discussion. Maybe it's time to de-lurk now, with a question
unrelated to the Z machine proper, but of interest to interpreter
writers.

You may be aware of a small utility called jzexe which I wrote as part
of the Jzip distribution. Jzexe turns Z-code files into stand-alone
DOS executables by appending the Z-code to the end of a copy of the
Jzip executable. On startup, jzip detects this and starts reading
Z-code from the end of its own file rather than prompting for a
filename. 

I'm not asking all interpreter writers to provide similar
functionality (though it would be nice to be able to produce
stand-alone exe files that run Frotz). I'm not even asking you for
your opinions, since it seems (from past discussion on r.a.i-f) that
an overwhelming majority of interpreter writers are against
stand-alone games.

What I'm asking for is this:

Would you consider letting your interpreter accept jzexe-generated
files as *input*? That is, your interpreter would accept a .exe file
produced by jzexe as input, skip the jzip part, and read just the
Z-code. 

This would be handy in two situations:

1) You have obtained a standalone game but you don't have a DOS
machine on which to run it (or you prefer to run another OS).
2) You are running DOS, but want to play the game using another
interpreter rather than the bundled version of Jzip.

Jzip already does this, and anybody interested in implementing such a
feature can check out how it is done in the Jzip source. It's very
simple, actually: the file contains a  magic string (that is hopefully
unique), directly followed by a 24-bit number that gives the offset
from the start of the file at which the Z-code starts. So you simply
scan the file for the string, read the following three bytes, convert
them to an integer, and lseek to that position. From there on you read
the file as any other Z-code file.

I think this would be a rather valuable addition to your respective
interpreters - afterall, there are a number of jzexe-generated game
files floating around, for example on the "Masterpieces" CD-ROM.

Comments? Opinions? Flames?

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sat Jun 28 14:29:47 1997
Date: Thu, 26 Jun 1997 09:57:54 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Jzexe files as input
In-Reply-To: <19970626170832.60221@bartlet.df.lth.se>
Message-Id: <Pine.SUN.3.95.970626093322.10223B-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: c5b419942de61c6f3c021a4b84a8bc7c

On Thu, 26 Jun 1997, Magnus Olsson wrote:

> You may be aware of a small utility called jzexe which I wrote as part
> of the Jzip distribution. Jzexe turns Z-code files into stand-alone
> DOS executables by appending the Z-code to the end of a copy of the
> Jzip executable. On startup, jzip detects this and starts reading
> Z-code from the end of its own file rather than prompting for a
> filename. 
>
> What I'm asking for is this:
> 
> Would you consider letting your interpreter accept jzexe-generated
> files as *input*? That is, your interpreter would accept a .exe file
> produced by jzexe as input, skip the jzip part, and read just the
> Z-code. 
> 
> This would be handy in two situations:
> 
> 1) You have obtained a standalone game but you don't have a DOS
> machine on which to run it (or you prefer to run another OS).
> 2) You are running DOS, but want to play the game using another
> interpreter rather than the bundled version of Jzip.

Skanky reply: I'll support this in MaxZip if you extend Jzip to input
MaxZip stand-alone games. And also Infocom's Mac standlone format
(which is different from MaxZip's, for unavoidable reasons.) How's that?

Serious reply: A stand-alone game is, by definition, non-portable. That
doesn't mean it *must* be confined to one platform, but it does mean that
there are going to be many stand-alone formats, because there are many
platforms. I don't see any great advantage to universally supporting just
one of them.

(MaxZip can read Infocom's Mac standalone games, but this is more luck
than effort on my part. I do think it's a good thing -- a Mac user is
likely to have Mac Infocom games that he wants to transfer. Similarly, it 
would probably be useful for a DOS/Windows interpreter to be able to read 
jzexe. It's the cross-platform support I'm wary of.) 
 
> I think this would be a rather valuable addition to your respective
> interpreters - afterall, there are a number of jzexe-generated game
> files floating around, for example on the "Masterpieces" CD-ROM.

There's also the distant, but vaguely terrifying, problem of Standards
Creep. Say a bunch of interpreters support this, but I don't. Does it
become acceptable for authors to distribute games only as jzexe files? If
so, do my users get screwed? If not, what advantage are you arguing for
universal support of jzexe?

I guess I'm just made very nervous by the prospect of *two* common game
file formats, one of which is platform-independent, and one of which is
native to IBMs in some sense. 

My solution to your situation 2) is to give standalone MaxZip games the
ability to *un*bundle themselves, generating a Z-code file. This only
works if you have a Mac, of course, but it alows people to switch from
one Mac interpreter to another. I guess the equivalent for jzip would be a
-unbundle command-line switch which can be given to any jzexe game.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:29:48 1997
Date: Thu, 26 Jun 1997 10:04:47 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments o
In-Reply-To: <Marcel-1.09-0626150115-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.970626095830.10223C-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 1d7e1c5833f73a5939547138da245934

On Thu, 26 Jun 1997, Graham Nelson wrote:

> Interpreter writers flinch from the _reputation_ of Z6 as much as
> the actuality.  For a long time Z6 has been documented only in
> long, confusing wrangles, one always contradicting another one,
> provoking headaches about where the cursor should go and when the
> buffer flushes and...

Well, I'll tell you what it is for me (which I already said last night, I
guess): I can't leverage off my existing code. My Z5 text engine
(essentially the same in xzip and MaxZip) is just not compatible with the
kind of screen control the Z6 machine has. I'd have to start over, and I
wouldn't be able to put in the kind of interface that got me into writing
Z-machine interpreters in the first place.

> Now that I think about it, perhaps there should be a TerpEtude.Z6
> story file...

Will be damn near essential if people want to write Z6 games.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:29:50 1997
Message-Id: <Mutt.19970626114303.jholder@deimos.frii.com>
Date: Thu, 26 Jun 1997 11:43:03 -0600
From: jholder@deimos.frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
References: <19970626170832.60221@bartlet.df.lth.se> <Pine.SUN.3.95.970626093322.10223B-100000@netcom>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <Pine.SUN.3.95.970626093322.10223B-100000@netcom>; from Andrew Plotkin on Jun 26, 1997 09:57:54 -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: a57819d2be57808962c60196bdbff35e

Andrew Plotkin writes:
> My solution to your situation 2) is to give standalone MaxZip games the
> ability to *un*bundle themselves, generating a Z-code file. This only
> works if you have a Mac, of course, but it alows people to switch from
> one Mac interpreter to another. I guess the equivalent for jzip would be a
> -unbundle command-line switch which can be given to any jzexe game.

The problem is, the unbundler needs to run on other platforms....
jzexe can already "detach" game files from the interpreter - in DOS.
So, if jzexe's unbundle code were ported around, anyone could
take apart a jzip .exe file.

-- 
John Holder (jholder@frii.com) /\            http://www.frii.com/~jholder/
UNIX Specialist, Paranet Inc. <--> Raytracing|Fractals|Interactive Fiction
http://www.paranet.com/        \/           Homebrewing|Strange Attractors

From ???@??? Sat Jun 28 14:29:58 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Thu, 26 Jun 1997 18:32:18 -0000
Message-Id: <yam7116.937.4652120@smtp.netcomuk.co.uk>
In-Reply-To: <19970626170832.60221@bartlet.df.lth.se>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] Jzexe files as input
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: 8dd01d5ef971ef7738c21143aeb44a0d

On 26-Jun-97, Magnus Olsson wrote:
>Would you consider letting your interpreter accept jzexe-generated
>files as *input*? That is, your interpreter would accept a .exe file
>produced by jzexe as input, skip the jzip part, and read just the
>Z-code. 

This is a bad idea, I think. It's best to discourage use of platform-specific
files. What if all authors were to use a different interpreter on a different
platform to build these 'standalone' files? It completely destroys the concept
of portability.

By all means, write a program to strip out the actual story data from such a
file. Adding support in the interpreter is a bad idea. The interpreter would
need to support all possible interpreter/platform combinations for 'standalone'
files.


>This would be handy in two situations:

>1) You have obtained a standalone game but you don't have a DOS
>machine on which to run it (or you prefer to run another OS).

Run a program to split out the story data first.


>2) You are running DOS, but want to play the game using another
>interpreter rather than the bundled version of Jzip.

Run a program to split out the story data first.

The 'bundled' interpreter will inevitably become outdated/obsolete. So it will
just end up inflating the file size.


>I think this would be a rather valuable addition to your respective
>interpreters - afterall, there are a number of jzexe-generated game
>files floating around, for example on the "Masterpieces" CD-ROM.

>Comments? Opinions? Flames?

As I said above, 'standalone' files should be discouraged. Support of them in
other interpreters is a non-starter. Ideally, anyone who does distribute
'standalone' files should include a program to split out the story data. But
then they might as well just include a separate story file in the first place.


-- Mark


From ???@??? Sat Jun 28 14:29:53 1997
X-Sender: mattack@mail.apple.com
Message-Id: <v01550101afd865431670@[17.202.20.138]>
Mime-Version: 1.0
Date: Thu, 26 Jun 1997 11:36:03 -0700
To: z-machine@gmd.de
From: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] Jzexe files as input
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"
X-UIDL: d4dcc60ba42e63723bb845e5e7b9892c

>Would you consider letting your interpreter accept jzexe-generated
>files as *input*? That is, your interpreter would accept a .exe file
>produced by jzexe as input, skip the jzip part, and read just the
>Z-code.

How do you absolutely guarantee that you can skip the jzip part?

I dunno, I like it in theory, I think I'd rather have an "extractor"
program that ripped off (and threw away, heh) the jzip part and created
a .zX file.

While I don't like making life harder, even though it involves *two* steps,
it makes the interpreters simpler.

--
mattack@apple.com



From ???@??? Sat Jun 28 14:29:56 1997
Date: Thu, 26 Jun 1997 14:54:05 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706261854.OAA03184@wanda.vf.pond.com>
To: mattack@apple.com, z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: ea8e5a85e327ae46e4a1e16c9cfb51d5

} I dunno, I like it in theory, I think I'd rather have an "extractor"
} program that ripped off (and threw away, heh) the jzip part and created
} a .zX file.

} While I don't like making life harder, even though it involves *two* steps,
} it makes the interpreters simpler.

Yep, if JZIP standalone files become popular, I'd write a little
drag-n-drop stripper before I'd modify my interpreter.


From ???@??? Sat Jun 28 14:29:54 1997
Date: Thu, 26 Jun 1997 12:00:31 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Jzexe files as input
In-Reply-To: <Pine.SUN.3.95.970626093322.10223B-100000@netcom>
Message-Id: <Pine.BSI.3.95.970626115656.2696D-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: f83c858e6efa13e564a107598f6da3ee

On Thu, 26 Jun 1997, Andrew Plotkin wrote:

> My solution to your situation 2) is to give standalone MaxZip games the
> ability to *un*bundle themselves, generating a Z-code file. This only
> works if you have a Mac, of course, but it alows people to switch from
> one Mac interpreter to another. I guess the equivalent for jzip would be a
> -unbundle command-line switch which can be given to any jzexe game.

How do jzip and the other bundled type games add the zcode to the file?
If it's just tacked on at the end, writting a simple un-bundler that
extracted this would be extreamly easy (at least in theory).  If this is
how it's done, could someone point me toward a jzexe bundled (freely
distributable of course) game so I can take a look at it?

Patrick
---

"Every weekday morning the school bell cast its glamour over the
 surounding hills, calling the young to classes.  They came running
 down the slopes and leaping over the streams, out from caves and the
 hollows of trees and suburban tract homes, impelled by powers greater
 then their own to gain an education." 
    "The Iron Dragon's Daughter" by Michael Swanwick


From ???@??? Sat Jun 28 14:29:57 1997
Date: Thu, 26 Jun 1997 12:02:16 -0700
Message-Id: <199706261902.MAA32515@albatros.wco.com>
From: Alloca Petrofsky <albatros@wco.com>
To: erkyrath@netcom.com
Cc: z-machine@gmd.de
In-Reply-To: <Pine.SUN.3.95.970626093322.10223B-100000@netcom> (message from
	Andrew Plotkin on Thu, 26 Jun 1997 09:57:54 -0700 (PDT))
Subject: Re: [z-machine] Jzexe files as input
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 3a4979a6926987dbc151cbd2a1857c10


Andrew Plotkin <erkyrath@netcom.com> wrote:

   Serious reply: A stand-alone game is, by definition, non-portable. That
   doesn't mean it *must* be confined to one platform, but it does mean that
   there are going to be many stand-alone formats, because there are many
   platforms. I don't see any great advantage to universally supporting just
   one of them.

But we could agree on a standard "universally extractable" stand-alone
format that is not platform-dependent, as far as extracting it goes.
Is there any reason that stand-alone formats for all the various
platforms couldn't use the same magic string for locating the game
file?

I heartily agree with your suggestion that any interpreter with the
ability to read an embedded game file should include an option to
write out the pure game file.  It's trivial to implement (the
extraction code is already in there (which is pretty trivial anyway)),
and it can save the user a lot of trouble in at least some cases.

-al

From ???@??? Sat Jun 28 14:30:05 1997
Date: Thu, 26 Jun 1997 12:45:13 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Jzexe files as input
In-Reply-To: <199706261902.MAA32515@albatros.wco.com>
Message-Id: <Pine.SUN.3.95.970626123127.18048A-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 357364e68074526ee594d87113b5b3ab

On Thu, 26 Jun 1997, Alloca Petrofsky wrote:

> 
> Andrew Plotkin <erkyrath@netcom.com> wrote:
> 
>    Serious reply: A stand-alone game is, by definition, non-portable. That
>    doesn't mean it *must* be confined to one platform, but it does mean that
>    there are going to be many stand-alone formats, because there are many
>    platforms. I don't see any great advantage to universally supporting just
>    one of them.
> 
> But we could agree on a standard "universally extractable" stand-alone
> format that is not platform-dependent, as far as extracting it goes.
> Is there any reason that stand-alone formats for all the various
> platforms couldn't use the same magic string for locating the game
> file?

Well, a platform may have some native file format which is not compatible
with this scheme. Or a file *layout* which is not compatible. 

Mac files are notoriously unlike other OS's files. A file contains both a
flat sequence of bytes and a set of typed resources. You can leave out the
resources; a Z-code file on the Mac is just the flat file, as you'd
expect. But a Mac *application* must have resources. So if a Mac
application is transferred to another computer, it's necessarily encoded
in some way (both the data and the resources mashed into one flat file.) I
don't think it's possible to mix magic numbers into that. Depending on the
encoding format, the Z-code may not even exist as raw data. BinHex is the
most popular encoding, and it translates both the data and the resources
into 7-bit ASCII for easier email transfer. 

(So I was being even more unrealistic than it sounded when I suggested
that jzip be able to read MaxZip standalones.)

For the record, Infocom's Mac interpreters stored the Z-code as the
application's data. (The Mac executable code was stored as resources.)
MaxZip stores the Z-code as a resource.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:30:03 1997
Message-Id: <c=US%a=ATTMAIL%p=HOECHST%l=BRW-EXC-03-970626194549Z-4028@brw-exc-02.bridgewater.ne.hcc.com>
From: "Kennedy, John ,HiServ/NA" <JKENNEDY@himail.hcc.com>
To: "'z-machine'" <z-machine@gmd.de>
Subject: RE: [z-machine] Jzexe files as input
Date: Thu, 26 Jun 1997 15:45:49 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 30 TEXT
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: ea650e6884f7f9db24aaa9a03562cfc0

>How do jzip and the other bundled type games add the zcode to the file?
>If it's just tacked on at the end, writting a simple un-bundler that
>extracted this would be extreamly easy (at least in theory).  If this is
>how it's done, could someone point me toward a jzexe bundled (freely
>distributable of course) game so I can take a look at it?

It's quite simple in the DOS world.  The first few bytes of the EXE file
have a field in a fixed position giving the size of the file.
Self-extracting
archive files and most programs like jzip simply append the data to the
EXE file.  DOS doesn't complain about the file being oversized, so the
program can then just reread the header and skip to the first data byte.

Windows and OS/2 add a further complication.  On them, an unused
field in the DOS header points to another header, while the DOS
header points to a dummy program.  That way, when DOS runs the
program, you get "Sorry, but this program needs OS/2."  (Or, back in
the days of 16-bit OS/2, the DOS header could describe a DOS
program that emulated a subset of OS/2, which would in turn load the
program described by the OS/2 header, so that a single binary could
run either way.)  In such cases, the second header and program
must also be skipped.

I get the impression, however, that this isn't the way jzip does it,
instead scanning the file for a magic string.

My knowledge of the Macintosh is limited to a few days in the 80's,
checking that the terminal program of the original Macintosh worked
with our terminal-to-mainframe gateway, but from the way I hear
it talked about (wottherell is a "fork"?), it may be a trifle nastier.

From ???@??? Sat Jun 28 14:30:09 1997
Date: Thu, 26 Jun 1997 13:00:56 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments on the resolution thing
In-Reply-To: <yam7116.1210.4565560@smtp.netcomuk.co.uk>
Message-Id: <Pine.SUN.3.95.970626125651.18048D-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 90081b6f2c6cdb40ce68f64550d7a0e2

On Thu, 26 Jun 1997, Mark wrote:

> On 25-Jun-97, Andrew Plotkin wrote:
> >All the images in Infocom's games are drawn with square pixels (when
> >played on the Mac, using Infocom's Mac interpreter.) The images look fine. 
> >Therefore, they follow my assumption. Close enough, anyway. 
> 
> This is because (so far) that graphics formats have been platform-specific. The
> Macintosh versions of the Infocom games obviously used square pixels, since the
> Mac has always had this feature. PC and Amiga (and probably Apple II) versions
> did not use square pixels.

Mmm, this is an interesting question. Did they really redo the graphics
data between PC, Amiga, Mac, etc? Obviously they changed the file formats,
but I assumed that the translation was one-pixel-to-one-pixel.
 
Can anyone do a screen dump on an old Infocom interpreter and check this?
The title screen of Arthur would be a good choice. I'd like to compare the
Mac art I have with Apple II or something like that.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:30:00 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Thu, 26 Jun 1997 20:09:24 -0000
Message-Id: <yam7116.1210.4565560@smtp.netcomuk.co.uk>
In-Reply-To: <Pine.SUN.3.95.970625112907.27849B-100000@netcom>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] [blorb] Final comments on the resolution thing
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: 31cb16b560d4844b62d93585e170e13d

On 25-Jun-97, Andrew Plotkin wrote:
>> Only problem is, this is not the case for all current graphical V6 games,
>which
>> use a 320x200 pixel screen. (The screen would have had to be 320x240 for a
>1:1
>> aspect ratio.)

>I believe you misunderstand. I wasn't talking about screen (window) size;
>I was talking about image size.

>All the images in Infocom's games are drawn with square pixels (when
>played on the Mac, using Infocom's Mac interpreter.) The images look fine. 
>Therefore, they follow my assumption. Close enough, anyway. 

This is because (so far) that graphics formats have been platform-specific. The
Macintosh versions of the Infocom games obviously used square pixels, since the
Mac has always had this feature. PC and Amiga (and probably Apple II) versions
did not use square pixels.

For creating a new format, then yes, square pixels are obviously the logical
choice.


>Does Frotz apply a small vertical distortion when displaying Infocom
>graphics on a square-pixel screen? If not, I don't think there's any need
>to start now.

Perhaps I'm being overly picky. As far as interpreters for the existing games
and picture files go, I think the best behaviour is to scale graphics
integrally so they are as near to the 'designed' aspect ratio as possible
(i.e., x1, x2, x3...). So if running on a, say, 1280x200 screen, the graphics
would be stretched horizontally by a factor of 4.

-- Mark


From ???@??? Sat Jun 28 14:30:11 1997
Date: Thu, 26 Jun 1997 13:36:50 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
In-Reply-To: <v01550101afd865431670@[17.202.20.138]>
Message-Id: <Pine.BSI.3.95.970626133530.6109D-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 84637120426056503fc5b811a7c168c1

On Thu, 26 Jun 1997, Matt Ackeret wrote:

> How do you absolutely guarantee that you can skip the jzip part?

There should be some kind of pointer of some sort, I'm gonna check out the
source when I get the time and see how it's done.

> I dunno, I like it in theory, I think I'd rather have an "extractor"
> program that ripped off (and threw away, heh) the jzip part and created
> a .zX file.

This is what i'm thinking, should be simple.

Patrick
---

"Every weekday morning the school bell cast its glamour over the
 surounding hills, calling the young to classes.  They came running
 down the slopes and leaping over the streams, out from caves and the
 hollows of trees and suburban tract homes, impelled by powers greater
 then their own to gain an education." 
    "The Iron Dragon's Daughter" by Michael Swanwick


From ???@??? Sat Jun 28 14:30:10 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Thu, 26 Jun 1997 20:36:57 -0000
Message-Id: <yam7116.2873.4565560@smtp.netcomuk.co.uk>
In-Reply-To: <199706261902.MAA32515@albatros.wco.com>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] Jzexe files as input
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: 53573f31d81c7b50247729a2b07d43c4

On 26-Jun-97, Alloca Petrofsky wrote:
>But we could agree on a standard "universally extractable" stand-alone
>format that is not platform-dependent, as far as extracting it goes.
>Is there any reason that stand-alone formats for all the various
>platforms couldn't use the same magic string for locating the game
>file?

You don't know anything about all executable file formats on all future and
existing platforms. You can never guarantee that any so-called 'magic string'
will not appear in a compiler's output object code for any existing or future
CPU family.


-- Mark


From ???@??? Sat Jun 28 14:30:12 1997
Message-Id: <19970626224544.44554@bartlet.df.lth.se>
Date: Thu, 26 Jun 1997 22:45:44 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
References: <Pine.SUN.3.95.970626093322.10223B-100000@netcom> <199706261902.MAA32515@albatros.wco.com>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <199706261902.MAA32515@albatros.wco.com>; from Alloca Petrofsky on Thu, Jun 26, 1997 at 12:02:16PM -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 90f2d2d967786b3eac43324b2972c715

On Thu, Jun 26, 1997 at 12:02:16PM -0700, Alloca Petrofsky wrote:
> 
> Andrew Plotkin <erkyrath@netcom.com> wrote:
> 
>    Serious reply: A stand-alone game is, by definition, non-portable. That
>    doesn't mean it *must* be confined to one platform, but it does mean that
>    there are going to be many stand-alone formats, because there are many
>    platforms. I don't see any great advantage to universally supporting just
>    one of them.
> 
> But we could agree on a standard "universally extractable" stand-alone
> format that is not platform-dependent, as far as extracting it goes.

I intend to propose such a standard before I go on vacation. 

> Is there any reason that stand-alone formats for all the various
> platforms couldn't use the same magic string for locating the game
> file?

No, not as long as nobody else uses the same magic string for some
other purpose, in which case we're SOL.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sat Jun 28 14:30:14 1997
Date: Thu, 26 Jun 1997 14:43:35 -0700
Message-Id: <199706262143.OAA01761@albatros.wco.com>
From: Allowsgay Petrofsky <albatros@wco.com>
To: z-machine@gmd.de
In-Reply-To: <yam7116.2873.4565560@smtp.netcomuk.co.uk> (message from Mark on
	Thu, 26 Jun 1997 20:36:57 -0000)
Subject: Re: [z-machine] Jzexe files as input
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: f35978b9bea89f4ec5c22ca4bb02ab0e


To address the concerns about its implementability, let me elaborate a
little on what a standard for embedded z-machine gamefiles might look
like:

  A z-machine game file can be embedded in any byte sequence as follows:

    arbitrary     "ZMACHINE MAGIC"     more        standard         even more
     data          + offset of         arbitrary   z gamefile       arbitrary
                   gamefile from       data        (or blorb file   data
                   here                            that includes
                                                   a gamefile)

  The first block of data must not contain the string "ZMACHINE MAGIC".
  The other blocks are unconstrained.

  On most platforms (DOS, UNIX, CP/M...), the executable format is a
  byte sequence.  On those platforms, a self-contained executable should
  take the above form.  On the macintosh, the data fork of the
  executable (which is a byte sequence) should take the above form.

I am fairly certain it is possible on all common platforms (and most
of the obscure ones) to make an executable containing an interpreter
and a z file in the specified form.  I'd be interested in hearing
counter-examples.

Creating these files might be tricky, but I think it's reasonable to
ask intrepreter writers in general that they write the very simple
code for reading these files.

Mark <markk@netcomuk.co.uk> wrote:

   You can never guarantee that any so-called 'magic string'
   will not appear in a compiler's output object code for any existing or future
   CPU family.

True, but we don't really need to.  If your compiler actually compiles
part of your interpreter to the machine code represented by the bytes
"ZMACHINE MAGIC", you still have two possible outs: 1) arrange for the
real magic string (the one with the offset) to occur before this part
of the object code.  2) tweak that part of your interpreter until it
compiles to something different.  Also, if we make the string a little
longer, the chances of it just popping up somewhere become extremely
low.  (The string doesn't have to be that long to make the odds less
than one in the number of atoms in the universe, or whatever your
favorite low probability is.)

(If the problem is that the embedded-file-reading part of your
interpreter is compiling to something containing the magic string
because the magic string is a constant in your code, then just replace
the constant with "ZMACHINE FOO" and "MAGIC FOO" and cut and paste
them together at run time.)

Even if there are a couple platforms on which this scheme can not be
used, that just means that any self-contained executables for those
platforms (if anybody really wants to make them) will suffer from
being difficult for anyone else to extract useful information from
(just as jzexe executables do today) and people should take extra
precautions to ensure the pure form of the game is also available.
Standardizing the format for all the other platforms is still useful.

-al

From ???@??? Sat Jun 28 14:30:18 1997
Date: 27 Jun 97 02:44:46 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:erkyrath@netcom.com" <erkyrath@netcom.com>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments o
Message-Id: <970627064446_104312.2206_IHS62-1@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 6a38cd916da61e2ce9c116b0f127e3b3


Andrew wrote:
>I rambled:
>> I think *always* locking the 
>> aspect ratio may be a mistake (based on the fact that I code for 
>> machines with weird screen geometries like 480x160), but I could be 
>> wrong on that.
> 
> What machine is that? I was really unaware there were any (unless > 
it's a dedicated game console or some WebTV-like mutation.) 
> 
> In any case, it's not exactly locking the aspect ratio. It's saying
> 
> 1) If you create art on your 480x160 monitor, with bizarre elongated
> pixels, it's your responsibility to squash it back to normality > 
before you upload it to GMD.

Blast.  Didn't make things clear enough (again).  The screen is 480x160 
but has square pixels.  (Think LCD panels in palmtops: the snazzy new 
machine will have 640x240.)  In either case, preserving the aspect 
ratio on images designed for a traditional monitor will produce small 
pictures with lots of space to the right.  In some cases squishing the 
images vertically might be preferable.

    Bryan

 


From ???@??? Sat Jun 28 14:30:23 1997
Message-Id: <19970627102521.47686@bartlet.df.lth.se>
Date: Fri, 27 Jun 1997 10:25:21 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
References: <19970626170832.60221@bartlet.df.lth.se> <Pine.SUN.3.95.970626093322.10223B-100000@netcom>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <Pine.SUN.3.95.970626093322.10223B-100000@netcom>; from Andrew Plotkin on Thu, Jun 26, 1997 at 09:57:54AM -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: ebd683b2439576efb6d8300aab57a594

On Thu, Jun 26, 1997 at 09:57:54AM -0700, Andrew Plotkin wrote:
> Skanky reply: I'll support this in MaxZip if you extend Jzip to input
> MaxZip stand-alone games. And also Infocom's Mac standlone format
> (which is different from MaxZip's, for unavoidable reasons.) How's that?

Sounds fair - but the world isn't fair :-). Anyway, you'd have to ask
John Holder, since jzip is his interpreter. 

And we have the usual problem with Mac files: there are two ways of
transferring them to non-Mac systems, MacBinary and plain binary. 

> Serious reply: A stand-alone game is, by definition, non-portable. That
> doesn't mean it *must* be confined to one platform, but it does mean that
> there are going to be many stand-alone formats, because there are many
> platforms. I don't see any great advantage to universally supporting just
> one of them.

Actually, I think you misunderstand my point. The non-portable part of a
jzexe file is the bundled jzip interpreter - but what I was asking is that
your interpreters be able to read the Z-code part of the file.

> There's also the distant, but vaguely terrifying, problem of Standards
> Creep. Say a bunch of interpreters support this, but I don't. Does it
> become acceptable for authors to distribute games only as jzexe files? If
> so, do my users get screwed? If not, what advantage are you arguing for
> universal support of jzexe?

This could be a problem. However, as I see it, some people will want to
distribute their games as stand-alone executables to keep things easy
for the users. These people either don't care that (in the case of
jzexe) non-DOS users won't be able to run the game, or they are
willing to take the trouble of producing multiple versions (I have
gone to that trouble with "Zebulon": there exist stand-alone PC and
Mac versions in addition to the plain .gam file).

Now, I'm not asking you to provide extra interpreter functionality as
a service to game writers, but to game _players_; to the people who
have obtained, say, the stand-alone PC executable of "A Change in the
Weather" from the Masterpieces CD, but want to run it on, say, an
Amiga. 

> My solution to your situation 2) is to give standalone MaxZip games the
> ability to *un*bundle themselves, generating a Z-code file. This only
> works if you have a Mac, of course, but it alows people to switch from
> one Mac interpreter to another. I guess the equivalent for jzip would be a
> -unbundle command-line switch which can be given to any jzexe game.

The problem with this is that it requires that you have access to the
computer for which the game was packaged. You can't unbundle the
Z-code from a MaxZip stand-alone on a PC, can you?

In the case of jzexe, the unbundling is done with the jzexe utility,
which is portable to Unix-like systems. If people are unwilling to
provide this functionality in their interpreters, perhaps a solution
would be to make jzexe (or its functionality) widely available?


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sat Jun 28 14:30:27 1997
Message-Id: <19970627103106.23481@bartlet.df.lth.se>
Date: Fri, 27 Jun 1997 10:31:06 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
References: <v01550101afd865431670@[17.202.20.138]>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <v01550101afd865431670@[17.202.20.138]>; from Matt Ackeret on Thu, Jun 26, 1997 at 11:36:03AM -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: fd97db8adde874b9359c81b44727939b

On Thu, Jun 26, 1997 at 11:36:03AM -0700, Matt Ackeret wrote:
> >Would you consider letting your interpreter accept jzexe-generated
> >files as *input*? That is, your interpreter would accept a .exe file
> >produced by jzexe as input, skip the jzip part, and read just the
> >Z-code.
> 
> How do you absolutely guarantee that you can skip the jzip part?

The file is simply a direct concatenation of the jzip interpreter and
the Z-code file. Z-code files, as they are stored in the IF archive,
are simply byte streams (Unix files). If your interpreter is to be
able to play those files, it must be able to read the file as a byte
stream, or you must have some way of converting it to a file that can
be read byte-for-byte (conceivably, some hypothetical OS may require
you to convert the Z-code file to a file of 1-word records, each of
which contains one byte of Z-code, or whatever). In that case, it can
read the jzip part byte-for-byte as well, and that is all that is
required.

> I dunno, I like it in theory, I think I'd rather have an "extractor"
> program that ripped off (and threw away, heh) the jzip part and created
> a .zX file.

The program exists: it's jzexe, and you're welcome to
steal^H^H^H^H^Hport the code. 

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sat Jun 28 14:30:25 1997
Message-Id: <19970627110945.51358@bartlet.df.lth.se>
Date: Fri, 27 Jun 1997 11:09:45 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
Mime-Version: 1.0
X-Mailer: Mutt 0.64
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: f3e4a1fd7b2fa9da3a0f07b3bfa051e7

On Thu, Jun 26, 1997 at 06:32:18PM -0000, Mark wrote:
> On 26-Jun-97, Magnus Olsson wrote:
> >Would you consider letting your interpreter accept jzexe-generated
> >files as *input*? That is, your interpreter would accept a .exe file
> >produced by jzexe as input, skip the jzip part, and read just the
> >Z-code. 
> 
> This is a bad idea, I think. It's best to discourage use of platform-specific
> files. What if all authors were to use a different interpreter on a different
> platform to build these 'standalone' files? It completely destroys the concept
> of portability.
 
No, it doesn't.

Firstly, I think that your argument is based on a misunderstanding:
the executable part of a jzexe-file (short for "jzexe generated stand-alone
executable") is of course platform dependent, since it's a copy of 
the DOS executable of Jzip. But *when viewed as a data file* it's not
any more platform dependent than any other Z-code file, it's just that
there's a bunch of useless data in front of the Z-code.

Secondly, my proposal (actually, not so much a proposal as a
suggestion) is aimed at *overcoming* the platform-dependence, by
allowing people to play standalone DOS games on non-DOS platforms.

Thirdly, what if everybody used different interpreters on different
platforms to build mutually incompatible standalone games? Well, this
is a legitimate concern. One way to counter it would be to adopt the
jzexe format as a standard. Not the interpreter part, of course, but
as a platform-independent (yes, you heard me right:
platform-independent) way of specifying where the Z-code starts. 

Fourthly,  several people (not you, others) have
put forth an argument that making non-DOS interpreters able to read
and play games created by jzexe would somehow encourage people to
produce more standalone games. I don't think this is true at all. 


>Adding support in the interpreter is a bad idea. The interpreter would
> need to support all possible interpreter/platform combinations for 'standalone'
> files.

This is simply not true. The jzexe format is simply a way of telling
your interpeter where the interpreter part of the file ends and the
Z-code part starts, no more, no less. 

And it doesn't follow at all that you would have to support any other
format at all. Especially not if we make the jzexe format some kind of
standard. 

> >Comments? Opinions? Flames?
> 
> As I said above, 'standalone' files should be discouraged. 

There are different opinions on this issue. But even if you think they
should be discouraged, do you really discourage people from making
standalone files for the PC, by refusing to handle the format on an
Amiga (or whatever)?

People (such as Activision, on their Masterpieces CD) are making and
releasing standalone executables today. This does cause some "damage"
in that platform specific files are released and distributed.  As I
see it, allowing these files to be read on other platforms will
diminish the "damage", not aggravate it.

> Support of them in
> other interpreters is a non-starter.

With all respect, I think this is a knee-jerk reaction. "If I refuse
to acknowledge this file format, it will go away".

> Ideally, anyone who does distribute
> 'standalone' files should include a program to split out the story data. But
> then they might as well just include a separate story file in the first
> place.

Indeed. But some of us prefer to minimalize the number of files
included in a distribution. There was some discussion on r.a.i-f some
time ago about the fact that many IF writers are extremely reluctant
to put any documentation etc. outside the .gam or .z? file - they feel
that as soon as a game distribution contains more than one file, it's
too difficult. 

I have no difficulty with distributing more than one file. It's just
that I think there are situations where it is sub-optimal to
distribute the game and the interpreter as separate files.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.


From ???@??? Sat Jun 28 14:30:32 1997
Date: Fri, 27 Jun 1997 11:18:00 +0100 (BST)
From: Dan J Archer <D.Archer@uea.ac.uk>
X-Sender: u9537872@cpca5.uea.ac.uk
To: Magnus Olsson <mol@df.lth.se>
Cc: z-machine@gmd.de
Subject: [z-machine] Jzexe files as input: Proposal
In-Reply-To: <19970627110945.51358@bartlet.df.lth.se>
Message-Id: <Pine.OSF.3.91.970627105511.9322A-100000@cpca5.uea.ac.uk>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: cc76fd71c9d14051f5b6ff1d558e04fa

Hi all,

I think the main point here is that as the z-machine is portable we have 
to look at a universal approach to this problem, rather than one which 
will just work with PC-exe/z-machine concatinated files.

> > >Would you consider letting your interpreter accept jzexe-generated
> > >files as *input*? That is, your interpreter would accept a .exe file
> > >produced by jzexe as input, skip the jzip part, and read just the
> > >Z-code. 
> > 
> > This is a bad idea, I think. It's best to discourage use of platform-specific
> > files. What if all authors were to use a different interpreter on a different
> > platform to build these 'standalone' files? It completely destroys the concept
> > of portability.
>  
> Firstly, I think that your argument is based on a misunderstanding:
> the executable part of a jzexe-file (short for "jzexe generated stand-alone
> executable") is of course platform dependent, since it's a copy of 
> the DOS executable of Jzip. But *when viewed as a data file* it's not
> any more platform dependent than any other Z-code file, it's just that
> there's a bunch of useless data in front of the Z-code.

I don't think this is a misunderstanding: the point is that even as a 
data file we've got a foreign file format here. How do you specify it 
detail?

    POSITION        CONTENT
    0               <random sequence of bytes meaningless to z-machine>
    ?               start of z-machine header
    LOF             end of z-machine file

Now though there may well be a note of the length of the file somewhere 
in the <random sequence of bytes...> chunk, this is not useful, as in 
global terms we need to be able to rip out the z-code without platform 
dependant problems.

Now, there wouldn't be a problem here if it were possible to tell from 
the _end_ of the z-machine .zx format files how long those files are: in 
theory interpreters or a universal conversion program could count back 
from the end to strip out the z-data, and pay no attention to the .exe in 
front.

> > Secondly, my proposal (actually, not so much a proposal as a
> suggestion) is aimed at *overcoming* the platform-dependence, by
> allowing people to play standalone DOS games on non-DOS platforms.

I think we probably all want that, it's just a question of approach...

> Thirdly, what if everybody used different interpreters on different
> platforms to build mutually incompatible standalone games? Well, this
> is a legitimate concern. One way to counter it would be to adopt the
> jzexe format as a standard. Not the interpreter part, of course, but
> as a platform-independent (yes, you heard me right:
> platform-independent) way of specifying where the Z-code starts. 

Ok. I have a proposal which may obviate this problem: why don't we define 
a "wrapper" file format which will permit the encapsulation of the 
executable and the z-machine in the same file?

The basic principal is this: any executable file is just (as has already 
been noted) a sequence of consecutive bytes of a certain size. The 
z-machine is the same.

All we need, therefore, is a universal file format which has a header at 
the start along these lines (forgive me if I use C):

struct PortableHeader
{
	long lMagicNumber;      // means of identififying this data format 
	int iPlatformID;

	long lStartOfExe;
	long lExeSize;

	long lStartOfZMachine;
	long lZMachineSize;
};

An extraction program can then be written in ANSI C (or virtually any 
other language) to rip out the z-machine code and place it in a separate 
file.

Optionally, the iPlatformID could be the same as the platform identifier 
in the z-machine header: a version of the extraction program for a 
specific platform could check against this code, and if the platform is 
the same as that on which it is running it could also extract the 
interpreter executable, or just remove the PortableHeader from the start 
of the file, thus leaving the jzexe (or other format) intact.

Interpreters could support this extraction process without difficulty.

Alternative:

If yet another file format seems excessive to the z-machine community, 
then why don't we wrap up the executable and the z-machine into an IFF file?

	Dan.



Athankye.

 /----------------------------------------------------------------------\
/ "A friend of mine did ride astride with tattered hat and stalk of hay: \
\  He carried buckets of giraffe, and hairless errors 'pon a tray."      /
 \----------------------------------------------------------------------/
 /        D.Archer@uea.ac.uk      |   http://www.uea.ac.uk/~u9537872/   \ 
 \----------------------------------------------------------------------/


From ???@??? Sat Jun 28 14:30:34 1997
Message-Id: <19970627133112.04926@bartlet.df.lth.se>
Date: Fri, 27 Jun 1997 13:31:12 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: [z-machine] Proposal: A format for including Z-code in binary files
Mime-Version: 1.0
X-Mailer: Mutt 0.64
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 1ec5050de813c9b7db8157c854715d46

Rationale: This proposal is based on the current discussion on the
Z-machine mailing list about the possibility of making Z-code
interpreters recognize standalone executable games produced by other
tools. Such files typically consist of an executable program (for some
arbitrary platform) with Z-code appended or otherwise included.

The desirability of standalone games, and of supporting them on other
platforms than that for which they were created, is a contentious
one. However, *if* standalone games are to be supported in any way,
there are distinct advantages to agreeing on a common format, so that
standard tools can be used to extract the Z-code from the files.

This proposal is *not* intended to imply that interpreter writers
should be in any way forced to support this format, or even to express
their approval of the practice of making standalone games. Its purpose
is *not* to encourage platform-dependence, but rather to reduce it.

***
What is being proposed: A standard, platform independent file format,
tentatively called JZE1.0, that allows Z-code to be embedded in a
binary file in such a way that it can be easily extracted from the
file. 
***

Specification:

JZE1.0 files are binary files that are considered as byte streams
without any imposed record structure. This is the file model used in
Unix. 

A JZE1.0 file shall contain consist of two parts: native data and
Z-code. The native data can contain any binary data, the only
restrictions being those described in the next section. The Z-code
part shall be a contiguous byte stream placed after the native data
and extending to the end of the file. The format of the Z-code part
shall be such that if it is copied byte-for-byte to a new file, that
file shall be accepatable as input for a Standrad Z-code interpreter.

A JZE1.0 file shall contain exactly one instance of the magic string 
"JZip/magic (mol)", terminated by an ASCII NULL (a zero byte). The
quotation marks are not considered part of the string and should not
occur in the file. If the magic string does not occur exactly once in
the file, the file shall be considered invalid.

The three bytes immediately following the terminating zero shall be
interpreted as an unsigned, 24-bit binary number, stored in
little-endian format (that is the number is (byte1) + 256*(byte2) +
65536*(byte3)). This number gives the offset from the start of the
file to the start of the z-code, an offset of 0 meaning that the
z-code starts at the beginning of the file. If the number is greater
than the length of the file, the file shall be considered invalid.

***

Note:

This format describes the format produced by the existing jzexe
program. In this case, the native data part of the file is a copy of
the Jzip 2.01g DOS executable. Such files are being distributed today,
for example on Activision's "Masterpieces" CD-ROM.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sat Jun 28 14:30:36 1997
Date: Fri, 27 Jun 1997 13:42:30 +0100 (BST)
From: Dan J Archer <D.Archer@uea.ac.uk>
X-Sender: u9537872@cpca5.uea.ac.uk
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input: Proposal (fwd)
Message-Id: <Pine.OSF.3.91.970627134151.16551B-100000@cpca5.uea.ac.uk>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 2e704905877ed551e223b2c45df90e64

Date: Fri, 27 Jun 1997 12:37:03 +0200
From: Magnus Olsson <mol@df.lth.se>
To: Dan J Archer <D.Archer@uea.ac.uk>
Subject: Re: [z-machine] Jzexe files as input: Proposal

On Fri, Jun 27, 1997 at 11:18:00AM +0100, Dan J Archer wrote:
> I think the main point here is that as the z-machine is portable we have 
> to look at a universal approach to this problem, rather than one which 
> will just work with PC-exe/z-machine concatinated files.

Definitely.

> > Firstly, I think that your argument is based on a misunderstanding:
> > the executable part of a jzexe-file (short for "jzexe generated stand-alone
> > executable") is of course platform dependent, since it's a copy of 
> > the DOS executable of Jzip. But *when viewed as a data file* it's not
> > any more platform dependent than any other Z-code file, it's just that
> > there's a bunch of useless data in front of the Z-code.
> 
> I don't think this is a misunderstanding: the point is that even as a 
> data file we've got a foreign file format here. 

The point is that the relevant part of the file format is not foreign,
but platform independent. The only thing that is required is that the
file's contents can be read as a byte stream.

> How do you specify it 
> detail?
> 
>     POSITION        CONTENT
>     0               <random sequence of bytes meaningless to z-machine>
>     ?               start of z-machine header
>     LOF             end of z-machine file
> 
> Now though there may well be a note of the length of the file somewhere 
> in the <random sequence of bytes...> chunk, this is not useful, as in 
> global terms we need to be able to rip out the z-code without platform 
> dependant problems.

You jump to conclusions. This is not how it is supposed to work. I'll post a
detailed proposal shortly.

> Now, there wouldn't be a problem here if it were possible to tell from 
> the _end_ of the z-machine .zx format files how long those files are: in 
> theory interpreters or a universal conversion program could count back 
> from the end to strip out the z-data, and pay no attention to the .exe in 
> front.

This is one idea that would work as well.

> > > Secondly, my proposal (actually, not so much a proposal as a
> > suggestion) is aimed at *overcoming* the platform-dependence, by
> > allowing people to play standalone DOS games on non-DOS platforms.
> 
> I think we probably all want that, it's just a question of approach...

Actually, I get the distinct impression that we don't all want that,
but that some people are rather vehemently opposed to supporting
standalone game files as all.

> > Thirdly, what if everybody used different interpreters on different
> > platforms to build mutually incompatible standalone games? Well, this
> > is a legitimate concern. One way to counter it would be to adopt the
> > jzexe format as a standard. Not the interpreter part, of course, but
> > as a platform-independent (yes, you heard me right:
> > platform-independent) way of specifying where the Z-code starts. 
> 
> Ok. I have a proposal which may obviate this problem: why don't we define 
> a "wrapper" file format which will permit the encapsulation of the 
> executable and the z-machine in the same file?
> 
> The basic principal is this: any executable file is just (as has already 
> been noted) a sequence of consecutive bytes of a certain size. The 
> z-machine is the same.
> 
> All we need, therefore, is a universal file format which has a header at 
> the start along these lines (forgive me if I use C):
> 
> struct PortableHeader
> {
> 	long lMagicNumber;      // means of identififying this data format 
> 	int iPlatformID;
> 
> 	long lStartOfExe;
> 	long lExeSize;
> 
> 	long lStartOfZMachine;
> 	long lZMachineSize;
> };
> 
> An extraction program can then be written in ANSI C (or virtually any 
> other language) to rip out the z-machine code and place it in a separate 
> file.

The problem is that you can't put any extra stuff at the beginning of an
excetuable file under most OS's. Unix and MS-DOS/Windows use the first few
bytes of the file as a magic number to identify executables, and then
assume that data is stored in a certain format directly after this. So this
would only aggravate the problem of platform dependence.

> If yet another file format seems excessive to the z-machine community, 
> then why don't we wrap up the executable and the z-machine into an IFF file?

The same problem applies: how do you make DOS recognize an IFF file and start
executing the enclosed executable?

As I see it, both your proposals require either OS extensions or extra software
in order to run the exectuable part of the file. This is solvable, but AFAIK
only in extremely platform-dependent ways. Which takes us back to square one
as far as platform-dependence is concerned.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.


From ???@??? Sat Jun 28 14:30:39 1997
Date: Fri, 27 Jun 1997 09:47:24 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706271347.JAA28086@wanda.vf.pond.com>
To: erkyrath@netcom.com, z-machine@gmd.de
Subject: Re: [z-machine] [blorb] Final comments on the resolution thing
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 4211ec12ef6f779a5aab65134ab0ae79

} Can anyone do a screen dump on an old Infocom interpreter and check this?
} The title screen of Arthur would be a good choice. I'd like to compare the
} Mac art I have with Apple II or something like that.

The Apple II art isn't even close, due to the limits of that
machine. I don't know if it was a mechanical reduction or they
actually re-did the art.  

From ???@??? Sat Jun 28 14:30:40 1997
Message-Id: <19970627155602.06210@bartlet.df.lth.se>
Date: Fri, 27 Jun 1997 15:56:03 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal: A format for including Z-code in binary files
References: <19970627133112.04926@bartlet.df.lth.se> <Pine.OSF.3.91.970627135615.16551E-100000@cpca5.uea.ac.uk>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <Pine.OSF.3.91.970627135615.16551E-100000@cpca5.uea.ac.uk>; from Dan J Archer on Fri, Jun 27, 1997 at 02:09:24PM +0100
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 671446b8fbc3de90b9a7ea59892eb512

On Fri, Jun 27, 1997 at 02:09:24PM +0100, Dan J Archer wrote:
> > Specification:
> > 
> > JZE1.0 files are binary files that are considered as byte streams
> > without any imposed record structure. This is the file model used in
> > Unix. 
> 
> Fair enough - best leave the Mac out of this...

The Mac is a bit of a difficult beast in this context, with its forks
and resources. However, AFAIK JZE files will be easily readable on a
Mac - standard binary transfer will simply put the entire file into
the data fork. I'd like to hear comments from the Mac experts on the
list about the possibility of going in the other direction.

> > A JZE1.0 file shall contain consist of two parts: native data and
> > Z-code. The native data can contain any binary data, the only
> > restrictions being those described in the next section. The Z-code
> > part shall be a contiguous byte stream placed after the native data
> > and extending to the end of the file. The format of the Z-code part
> > shall be such that if it is copied byte-for-byte to a new file, that
> > file shall be accepatable as input for a Standrad Z-code interpreter.
> 
> I personally only have a couple of problems with this. The first is that 
> of file typing (and is admittedly perhaps a minor one): if the file is 
> executable (eg. pc extension .exe, or with the Unix executable attribute 
> set), how does the user tell it is a JZE1.0 file, short of searching for 
> the "JZip/magic (mol)" string by hand?

That's clearly a problem. To be fair, exactly the same applies to
Z-code files. How do you know that the file "borderzone.dat" is a Z-code
file and not a data file generated by some entirely different program?


> If a separate distribution file 
> format is used, there are two benefits: firstly, its type can be told 
> either by its extension (whatever we were to choose to call it), or by 
> examining the _first few bytes of the file_, for IFF-ZDST, or
> similar. 

This is true, but such a format would address a different problem. See
my reply to your earlier comments.

> > A JZE1.0 file shall contain exactly one instance of the magic string 
> > "JZip/magic (mol)", terminated by an ASCII NULL (a zero byte). The
> > quotation marks are not considered part of the string and should not
> > occur in the file. If the magic string does not occur exactly once in
> > the file, the file shall be considered invalid.
> 
> I don't know about anyone else, but this doesn't seem very "clean" to me 
> - if there's going to be a standard file format I like it to be easily 
> defined and (to some extent) human readable: at least to be 
> human-typable.

If you can come up with such a scheme that is platform-independent and
doesn't require that the end user run special software, I'd be
interested in seeing it.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sat Jun 28 14:30:42 1997
Date: Fri, 27 Jun 1997 10:08:30 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706271408.KAA29305@wanda.vf.pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal: A format for including Z-code in binary files
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c52d259c635921b445b2a4cef4f2343e

}The Mac is a bit of a difficult beast in this context, with its forks
}and resources. However, AFAIK JZE files will be easily readable on a
}Mac - standard binary transfer will simply put the entire file into
}the data fork. I'd like to hear comments from the Mac experts on the
}list about the possibility of going in the other direction.

Standalone Infocom applications, transferred as plain binary, get
magically transformed into plain story files. 

}That's clearly a problem. To be fair, exactly the same applies to
}Z-code files. How do you know that the file "borderzone.dat" is a Z-code
}file and not a data file generated by some entirely different program?

If it begins with 00-08, I try to run it.  If it runs like a Z-machine
game, it is a Z-machine game :-)  Otherwise, the poor user gets a
fatal error.

IMO, the distribution of standalone games should be discouraged.

From ???@??? Sat Jun 28 14:30:43 1997
Message-Id: <19970627161547.27665@bartlet.df.lth.se>
Date: Fri, 27 Jun 1997 16:15:47 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input: Proposal
References: <19970627123703.02427@bartlet.df.lth.se> <Pine.OSF.3.91.970627134823.16551C-100000@cpca5.uea.ac.uk>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <Pine.OSF.3.91.970627134823.16551C-100000@cpca5.uea.ac.uk>; from Dan J Archer on Fri, Jun 27, 1997 at 01:55:17PM +0100
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 4c3723157f8d51635dfc6e6950d3dbf0

On Fri, Jun 27, 1997 at 01:55:17PM +0100, Dan J Archer wrote:
> > The problem is that you can't put any extra stuff at the beginning of an
> > excetuable file under most OS's. Unix and MS-DOS/Windows use the first few
> > bytes of the file as a magic number to identify executables, and then
> > assume that data is stored in a certain format directly after this. So this
> > would only aggravate the problem of platform dependence.
> 
> Not at all - I am not proposing a new _executable_ format. My suggestion 
> is based on the principal that an IF author may want to distribute his 
> story in executable form, but that he must recognise that many (if not 
> most) people playing his story will be doing so on a different platform. 
> Consequently, a method of distribution which can include both the 
> executable and the z-machine story file in a method useful to all 
> platforms permits the author to distribute an executable story whilst 
> also allowing the rest of the IF community to run his story, without the 
> burden of having the executable for a different platform permentantly 
> attached.

This idea has considerable merit. However, you're addressing a
slightly different problem. 

The reason for having stand-alone games, as I see it, is to make it
*really* easy for the user. You give the user *one* file, and tell
him/her to run it. There's no need to explain how an archive program
(like pkzip, or like your proposed program) works, there's no need to
explain that "you need these four files in the same directory", there
are no conflicts caused by multiple versions of the same program
residing on the same machine.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sat Jun 28 14:30:45 1997
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: [z-machine] Infocom images files
Date: Fri, 27 Jun 1997 16:17:24 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <19970627150241.AAA4268@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: 5721b86d3f653484a23069959baceba4


The artwork exists in four different versions:

1) Amiga, DOS (MCGA), Mac: 320x200, 14 (not 16!) colours [*]
2) DOS (EGA): 640x200, 16 colours [**]
3) DOS (CGA): 640x200, b/w
4) Apple II: unknown (though different from the above)

The images were first drawn on an NTSC Amiga (200 lines).

[*]  The screen is supposed to have 16 colours. The first two colours
     are reserved for text foreground and background (i.e. you cannot
     have several different text colours at the same time). Every
     picture can supply a colour palette; however, this palette takes
     global effect and applies to the entire screen.

[**] Colours are fixed to the standard EGA palette. No EGA images were
     drawn for Arthur and Journey; instead Infocom included a tool for
     converting the MCGA image files to EGA, with mediocre results.

-- Stefan
 

From ???@??? Sat Jun 28 14:30:47 1997
Date: Fri, 27 Jun 1997 16:11:27 +0100 (BST)
From: Dan J Archer <D.Archer@uea.ac.uk>
X-Sender: u9537872@cpca5.uea.ac.uk
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input: Proposal
In-Reply-To: <19970627161547.27665@bartlet.df.lth.se>
Message-Id: <Pine.OSF.3.91.970627155252.22108B@cpca5.uea.ac.uk>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 3441cfc8e490845580ab7f60351b44c1

On Fri, 27 Jun 1997, Magnus Olsson wrote:

> On Fri, Jun 27, 1997 at 01:55:17PM +0100, Dan J Archer wrote:
> > > The problem is that you can't put any extra stuff at the beginning of an
> > > excetuable file under most OS's. Unix and MS-DOS/Windows use the first few
> > > bytes of the file as a magic number to identify executables, and then
> > > assume that data is stored in a certain format directly after this. So this
> > > would only aggravate the problem of platform dependence.
> > 
> > Not at all - I am not proposing a new _executable_ format. My suggestion 
> > is based on the principal that an IF author may want to distribute his 
> > story in executable form, but that he must recognise that many (if not 
> > most) people playing his story will be doing so on a different platform. 
> > Consequently, a method of distribution which can include both the 
> > executable and the z-machine story file in a method useful to all 
> > platforms permits the author to distribute an executable story whilst 
> > also allowing the rest of the IF community to run his story, without the 
> > burden of having the executable for a different platform permentantly 
> > attached.
> 
> This idea has considerable merit. However, you're addressing a
> slightly different problem. 
> 
> The reason for having stand-alone games, as I see it, is to make it
> *really* easy for the user. You give the user *one* file, and tell
> him/her to run it. There's no need to explain how an archive program
> (like pkzip, or like your proposed program) works, there's no need to
> explain that "you need these four files in the same directory", there
> are no conflicts caused by multiple versions of the same program
> residing on the same machine.

Indeed - but this can only ever apply to 1 platform out of the many the 
z-machine supports. Concatinating a Mac interpreter and story file may be 
very handy for Mac users, but not so for PC, Archimedes, Amiga and other 
users.

Now admittedly an author could theoretically release an 
executable/interpreter combo for each major platform, but what then is 
the point of a compact, portable z-machine?

I'm not arguing against distributing exe/z-machine concatinated 
files, but I think that we need to balance ease of use for users of one 
platform against ease of use for the entire community - and any 
concatinated files need to be easily separable (as you say, ideally 
without special tools) for people who want to play the .exe on a 
different platform. After all, what happens when WinFrotz '99 is 
released, with a 2MB executable and one of Graham's massive (and 
incidentally extremely playable) story files? Archimedes users (for example) 
can't be expected to have to cart around a 2.2MB file just to play a 200k 
story file under their interpreter. And smaller machines (such as the 
Psion and similar organisers) can play story files, but would die if fed 
an interpreter/z-machine combo of any size.

If there is to be a stand-alone format, I think it needs the following 
features in an ideal world:

-	to be identifiable to the user as a stand-alone format without
	the user having to search through the file for magic constants.
	Whether by extension or header, the file should be identifiable.

-	be easily separable from any platform into executable and z-machine
	story file

- that's about it, to be honest. As a user of Win95 nowadays I would 
probably not produce or make great use of concatinated story files - and 
from a speed point of view I would always prefer to download a 200k 
z-machine story than a 500k executable with story.

	Dan.

Athankye.

 /----------------------------------------------------------------------\
/ "A friend of mine did ride astride with tattered hat and stalk of hay: \
\  He carried buckets of giraffe, and hairless errors 'pon a tray."      /
 \----------------------------------------------------------------------/
 /        D.Archer@uea.ac.uk      |   http://www.uea.ac.uk/~u9537872/   \ 
 \----------------------------------------------------------------------/



From ???@??? Sat Jun 28 14:30:49 1997
Date: Fri, 27 Jun 1997 16:24:28 +0100 (BST)
From: Dan J Archer <D.Archer@uea.ac.uk>
X-Sender: u9537872@cpca5.uea.ac.uk
To: z-machine@gmd.de
Subject: [z-machine] Blorb Format comments
Message-Id: <Pine.OSF.3.91.970627161936.23507A-100000@cpca5.uea.ac.uk>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: bc81f5353d599d844be3e70ec4b1b319

Hi all (again)

I appear to be tied up in file format discussions at the moment...

I've just taken a proper look at the proposal at gmd.de, and in my 
opinion the resource index chunk is entirely pointless. All it contains 
is information which is easily gathered by simply traversing the IFF 
file. If such traversal is undesirable then IFF is not a good choice for 
the format - what the reousrce index chunk facilitates is just a binary 
concatination of the resource files, with an index at the head. 

Either IFF or a binary concat. is file by me - (though I prefer IFF as it's 
already in use by the savegame format, I'm used to it and it's clean...) 
but I don't see the point in the index chunk.

Maybe I'm missing something - if so please feel free to flame me. (Either 
way, I'd better sign off as our network here at UEA goes down in 20 
minutes for the weekend, and all machines left connected get fried...)

	Dan.



Athankye.

 /----------------------------------------------------------------------\
/ "A friend of mine did ride astride with tattered hat and stalk of hay: \
\  He carried buckets of giraffe, and hairless errors 'pon a tray."      /
 \----------------------------------------------------------------------/
 /        D.Archer@uea.ac.uk      |   http://www.uea.ac.uk/~u9537872/   \ 
 \----------------------------------------------------------------------/


From ???@??? Sat Jun 28 14:30:50 1997
Date: Fri, 27 Jun 1997 09:19:40 -0700
Message-Id: <199706271619.JAA11309@albatros.wco.com>
From: Almudtay Petrofsky <albatros@wco.com>
To: mol@df.lth.se
Cc: z-machine@gmd.de
In-Reply-To: <19970627133112.04926@bartlet.df.lth.se> (message from Magnus
	Olsson on Fri, 27 Jun 1997 13:31:12 +0200)
Subject: Re: [z-machine] Proposal: A format for including Z-code in binary files
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 663e2ae7747a082b04886e16bd006f52

I have three problems with the proposal.  All of them only require
minor revisions.

   A JZE1.0 file shall contain exactly one instance of the magic
   string "JZip/magic (mol)", terminated by an ASCII NULL (a zero
   byte).

This places a restriction on the contents of the z-code itself
(i.e. it can't contain the magic string), which is unnecessary.  Why
not just say "at least one instance" and in the next paragraph
"...immediately following the terminating zero of the first
instance..."?

   The Z-code part shall be a contiguous byte stream placed after the
   native data and extending to the end of the file.

This is also overly restrictive.  If the platform requires the z-code
to be properly embedded in the executable's data segment, rather than
just tacked on, then there may need to be some bytes after the z-code.
The length of the z-code is self-evident from its header, so why not
allow extra data to occur after it?

Lastly, the string "JZip/magic (mol)" belies the fact that this is
intended to be a cross-platform, cross-interpreter standard.  Without
breaking compatibility with the old files, we could use the more
generic "Zip/magic (XXX)" where the XXX may be anything.  Similarly,
the name JZE1.0 creates the wrong impression.

-al

From ???@??? Sat Jun 28 14:30:51 1997
From: "Robert A. Pelak" <pelak@msc.cornell.edu>
Message-Id: <199706271659.QAA21452@sage.msc.cornell.edu>
X-Originated-From: sage.msc.cornell.edu
X-Msc-Version: IDA Client - Linux
Subject: Re: [z-machine] Jzexe files as input: Proposal
To: z-machine@gmd.de
Date: Fri, 27 Jun 1997 12:59:56 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: a8463c23b661ab0440f983b7346de4ab

> The reason for having stand-alone games, as I see it, is to make it
> *really* easy for the user. You give the user *one* file, and tell
> him/her to run it. There's no need to explain how an archive program
> (like pkzip, or like your proposed program) works, there's no need to
> explain that "you need these four files in the same directory", there
> are no conflicts caused by multiple versions of the same program
> residing on the same machine.
> 
> 
> -- 
> Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
> ------    http://www.pobox.com/~zebulon   ------
>      Not officially connected to LU or LTH.
> 

Actually, I see it as being more confusing for the user.  Consider the
following between and Mac user and a PC user:

PC user:  Hey, want to try ny new game?

Mac user: Sure.  (He/She tries it and likes it).  Can I get a copy?

PC user: Yes.  Just copy the file game.exe.

Mac user:  Now wait a minute.  I'm no computer genius but I know that
  even though my Mac can read PC disks, it can't run PC programs 
  without an emulator that I don't own.

PC user:  Well, this executable is JZEXE1.0 compliant so if your interprter
  is as well, it will be able to ignore the built in interprter and
  extract the data file.

Mac user:  Fascinating.  Is my interprter JZEXE1.0 compliant?

PC user:  I have no idea.
 

 
In order to make use of this feature, one has to 

a) appreciate the nature of being JZEXE1.0 compliant so that the executable
   nature of the file does not lead to an immediate dismissal of the idea
   that it can be useful.

b) already have an interprter and know that it is JZEXE1.0 compliant.

c) have a means of getting the file across platforms.  If one is going to
   use the net, you might as well just get the platform independant datafile.



The current situation seems to be ideal in it's elegance; adding this feature
just becomes more things to worry about and thus undermines simplicity,
not enhancing it.  Given its limited applicability, I don't think its
worth the trade off.

Robert



From ???@??? Sat Jun 28 14:30:54 1997
Date: Fri, 27 Jun 1997 11:34:41 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Blorb Format comments
In-Reply-To: <Pine.OSF.3.91.970627161936.23507A-100000@cpca5.uea.ac.uk>
Message-Id: <Pine.SUN.3.95.970627112757.10787B-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 19db00ec02de0c1b123ef86a07575195

On Fri, 27 Jun 1997, Dan J Archer wrote:

> Hi all (again)
> 
> I appear to be tied up in file format discussions at the moment...
> 
> I've just taken a proper look at the proposal at gmd.de, and in my 
> opinion the resource index chunk is entirely pointless. All it contains 
> is information which is easily gathered by simply traversing the IFF 
> file.

Not precisely true. It contains the usage and number of each chunk. If
there were no index, that information would have to be included in the
chunk itself, which seems sort of inelegant -- a PNG chunk would not be a
legal PNG file, but would instead have these eight bytes tacked on the
beginning. (Don't even suggest including them as an internal PNG chunk --
the same eight bytes have to go in a Zcode chunk and whatever sound
format we choose.)

That objection aside -- yes, the index chunk is redundant. I think that's
a good thing. Writing happens once, reading happens many times. Give the
interpreters a choice of traversing or not; some people may have IFF
reading libraries, but I don't. 

It's easy to do, it costs practically nothing, I don't think it's a big
deal.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:30:56 1997
Date: Fri, 27 Jun 1997 11:42:06 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Infocom images files
In-Reply-To: <19970627150241.AAA4268@jokisch>
Message-Id: <Pine.SUN.3.95.970627113536.10787C-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: af7a57b104fc3383cc07064a6dff82ba

On Fri, 27 Jun 1997, Stefan Jokisch wrote:

> 
> The artwork exists in four different versions:
> 
> 1) Amiga, DOS (MCGA), Mac: 320x200, 14 (not 16!) colours [*]
> 2) DOS (EGA): 640x200, 16 colours [**]
> 3) DOS (CGA): 640x200, b/w
> 4) Apple II: unknown (though different from the above)
> 
> The images were first drawn on an NTSC Amiga (200 lines).

Oookay. This being true, anyone who writes a Infocom-native-to-Blorb
translator -- or a Blorb-to-Infocom-native translator -- is going to have
to perform some scaling as well as format conversion. And the nature of
the scaling will depend on which native format is being translated.

I'm not greatly bothered by this. Yes, it would be easier for the
translator if Blorb allowed arbitrary pixel ratios. But then it would be
harder for the interpreter author. I prefer simpler standards anyhow.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:30:57 1997
Date: Fri, 27 Jun 1997 11:44:13 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments o 
Message-Id: <Pine.SUN.3.95.970627114356.10787D-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: eeef65548f75c882af370f59a89e0832

On 27 Jun 1997, Bryan Scattergood wrote:

> > 1) If you create art on your 480x160 monitor, with bizarre elongated
> > pixels, it's your responsibility to squash it back to normality > 
> before you upload it to GMD.
> 
> Blast.  Didn't make things clear enough (again).  The screen is 480x160 
> but has square pixels.  (Think LCD panels in palmtops: the snazzy new 
> machine will have 640x240.)

Check.

>  In either case, preserving the aspect 
> ratio on images designed for a traditional monitor will produce small 
> pictures with lots of space to the right.  In some cases squishing the 
> images vertically might be preferable.

True. It is legal for the interpreter to do this. What I'm trying to make
clear is that if the interpreter does this, it *is* distorting the art.
There is a right way to draw the image, and the interpreter is doing it
wrong, for the sake of other advantages which the user thinks are
worthwhile.

I'll see if I can clarify the blorb file on this. On stuff like colors and
resolution and aspect ratio, I'm not saying what the interpreter *must*
do, only what's *right*. :-) In other words, what would be best to do to
transmit the author's ideal vision. Ars longa, vita rigidis, or something
like that.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:30:59 1997
Date: Fri, 27 Jun 1997 12:19:04 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal: A format for including Z-code in binary files
In-Reply-To: <199706271619.JAA11309@albatros.wco.com>
Message-Id: <Pine.SUN.3.95.970627114535.10787F-100000@netcom>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 7e46835400457d6d5ed2ec2196ec77f9

Oh, my, my. I shall pontificate on many topics without quoting anything
directly.

I think standalone games are a good idea. I make them for the Mac, and I
upload them to the big Mac FTP archive. I think they very greatly increase
the number of Mac people who try IF games. 

I think standalone games are not, not, not a substitute for plain Z-code
files. Whenever I upload a standalone game, I include an introduction
which gives the location of the GMD archive. For example, see

http://hyperarchive.lcs.mit.edu/HyperArchive/Abstracts/game/adv/so-far-r6.hqx.abs

Also, a MaxZip standalone game contains built-in docs which explain the
nature of interpreters and Z-code games. It also has a menu option to
unbundle the Z-code into a plain file. It is true that this is only of
value if you already have a Mac, not if someone has (for some reason)
given a Mac application to a non-Mac-user.

(However, if a Mac user wishes to do this, it's not impossible. He just
has to unbundle the Z-code before he hands his friend the floppy, as
opposed to after.) 

Also:

It is stupid to design a "standard standalone" format which is not
actually executable on its home platform. An IFF bundle containing Z-code
and an interpreter is useless, because most OSs (probably, all of them)
don't know how to execute an IFF file.

Magnus's proposal does not make this mistake. I have no specific objection
to it (except that I agree that there might be arbitrary data after the
Z-code as well as before it.) 

But I still think (regardless of whether this proposal flies) that an
author should *never* distribute a standalone game without either
including the Z-code file, or a self-unbundling option, or including
instructions on how to get the Z-code file. Or preferably two or more of
the above.

I also still think (regardless of whether this proposal flies) that a
jzexe standalone game should have an option to unbundle itself, *without* 
requring you to have the jzexe utility. If it had this, then any
Masterpieces CD owner with a Mac or PC could extract the Z-code from
either the MaxZip or jzexe stand-alones. That would solve a large fraction
of the problem we're talking about. I understand it would not solve the
entire problem (ie, an Acorn user who bought the Masterpiecs CD would
still be unable to get the Z-code out from the competition games.)

Now, as to Macs:

A Mac application cannot be represented as a simple stream of bytes. If
you have a MaxZip standlone application on a non-Mac filesystem, it is
either damaged or encoded in either the MacBinary or BinHex formats.

If it's damaged (resources lost), the Z-code is gone.

If it's in BinHex format, the Z-code (along with all the other data) has
been encoded in 7-bit ASCII, and you'll never mind it.

If it's in MacBinary format, I'm not sure what state it's in. I'm not sure
the Z-code is unencoded. I'm not even certain that the Z-code is in a
contiguous segment, although I think it probably is. It's possible that I
could get a magic string to be readable.

However, this case is so rare that it's not worthwhile to cover it. The
fact is that nobody *does* transfer Mac apps to other filesystems, except
for storage/transfer, to be returned to a Mac for use. Because everyone
knows it'll either be damaged or encoded. (And anyway BinHex is much more
common than MacBinary, because if you're transferring files across the
net, a 7-bit-clean format is safer.) 

Footnote: If you transfer an Infocom standalone to a non-Mac naively, so
that it's damaged, the damage very conveniently strips away everything but
the Z-code, leaving you with, well, a valid Z-code file. It's a useful
trick, but MaxZip doesn't work that way (and can't be made to.)

So MaxZip standalones will not be readable by other interpreters. I have
not decided whether I would add the capacity for MaxZip to read
standalones from other platforms.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sat Jun 28 14:30:55 1997
From: Mark <markk@netcomuk.co.uk>
To: Z-Machine list <z-machine@gmd.de>
Date: Fri, 27 Jun 1997 19:27:27 -0000
Message-Id: <yam7117.1398.4138720@smtp.netcomuk.co.uk>
In-Reply-To: <19970627161547.27665@bartlet.df.lth.se>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] Jzexe files as input: Proposal
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain
X-UIDL: 99a41de11053d9820d7cf3e256eb741a

On 27-Jun-97, Magnus Olsson wrote:
>The reason for having stand-alone games, as I see it, is to make it
>*really* easy for the user. You give the user *one* file, and tell
>him/her to run it. There's no need to explain how an archive program
>(like pkzip, or like your proposed program) works, there's no need to

If you're distributing over the Internet, it's quite likely that some kind of
archiver will be used anyway; pkzip in the case of PCs, I imagine.


>explain that "you need these four files in the same directory", there
>are no conflicts caused by multiple versions of the same program
>residing on the same machine.

If you have multiple (Infocom-type) story files, you can potentially use a
single interpreter program.

When a new version of the interpreter program is available, and the user wants
to use that version, all the interpreters in the standalone files will just be
wasting disk space.


Also, it would not even be possible to support the proposed 'specification' for
standalone files on all platforms. Imagine an OS which requires each code/data
hunk to be <=64Kb in length, and does not allow 'garbage' data to be appended
to executable files. Didn't 68000 (not 68020 or higher) Mac programs have a
feature like this?


-- Mark


From ???@??? Sat Jun 28 14:31:00 1997
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Jzexe files as input
Date: Fri, 27 Jun 1997 22:09:09 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <19970627200709.AAA5595@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: 6ed6cd43ed97246c72b2f2f90a134ddb


Magnus Olsson wrote:

> Anyway, you'd have to ask John Holder, since jzip is his interpreter. 

90% (or more) of jzip was written by Mark Howell, not John Holder.
 
Besides, I'm not going to add any kind of support for standalone games to
Frotz, for reasons which have already been mentioned on this thread.
People who want to distribute an Inform game for DOS are asked to add the
Frotz executable and a simple batch file, e.g. CURSES.BAT.

-- Stefan


From ???@??? Sat Jun 28 14:31:02 1997
Date: Fri, 27 Jun 1997 17:02:31 -0400 (EDT)
From: russotto@pond.com (Matthew T. Russotto)
Message-Id: <199706272102.RAA27168@wanda.vf.pond.com>
To: erkyrath@netcom.com, z-machine@gmd.de
Subject: Re: [z-machine] Infocom images files
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 350e21aa968b9675f42e49557dedf1b9

}> The artwork exists in four different versions:
}> 
}> 1) Amiga, DOS (MCGA), Mac: 320x200, 14 (not 16!) colours [*]
}> 2) DOS (EGA): 640x200, 16 colours [**]
}> 3) DOS (CGA): 640x200, b/w
}> 4) Apple II: unknown (though different from the above)
}> 
}> The images were first drawn on an NTSC Amiga (200 lines).

}Oookay. This being true, anyone who writes a Infocom-native-to-Blorb
}translator -- or a Blorb-to-Infocom-native translator -- is going to have
}to perform some scaling as well as format conversion. And the nature of
}the scaling will depend on which native format is being translated.

The sane thing would be to use the Amiga/MCGA/Mac pictures.  There's
really no reason to use either of the other formats, unless you like
playing with prehistoric pictures (in which case just consider it a
labor of love).  No aspect ratio change required-- those are all
close-enough-to-square formats. 

From ???@??? Sat Jun 28 15:08:44 1997
Date: Fri, 27 Jun 1997 19:49:32 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
In-Reply-To: <19970627110945.51358@bartlet.df.lth.se>
Message-Id: <Pine.BSI.3.95.970627194313.6694D-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 253cf1e015b8dbce99004fa2432d3b26

On Fri, 27 Jun 1997, Magnus Olsson wrote:

> Thirdly, what if everybody used different interpreters on different
> platforms to build mutually incompatible standalone games? Well, this
> is a legitimate concern. One way to counter it would be to adopt the
> jzexe format as a standard. Not the interpreter part, of course, but
> as a platform-independent (yes, you heard me right:
> platform-independent) way of specifying where the Z-code starts. 

I don't belive that jzexe itself should be the standard (no offense) but I
belive that if we are going to do this that a header giving the following
info should be a standard.

Magic Word

Pointer to the start of the zcode.

>From these two entries a splitter program could easly be written for just
about any platform, even the C64 (I think).  I Don't belive that
interpreters need to load these stand alone games, this would be rather
pointless IMO.  

Patrick
---

"Every weekday morning the school bell cast its glamour over the
 surounding hills, calling the young to classes.  They came running
 down the slopes and leaping over the streams, out from caves and the
 hollows of trees and suburban tract homes, impelled by powers greater
 then their own to gain an education." 
    "The Iron Dragon's Daughter" by Michael Swanwick


From ???@??? Sun Jun 29 11:42:22 1997
Message-Id: <19970628150851.47654@bartlet.df.lth.se>
Date: Sat, 28 Jun 1997 15:08:51 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input: Proposal
References: <199706271659.QAA21452@sage.msc.cornell.edu>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <199706271659.QAA21452@sage.msc.cornell.edu>; from Robert A. Pelak on Fri, Jun 27, 1997 at 12:59:56PM -0400
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 027fea3732ee9d058aae2e0355006636

On Fri, Jun 27, 1997 at 12:59:56PM -0400, Robert A. Pelak wrote:
> > The reason for having stand-alone games, as I see it, is to make it
> > *really* easy for the user. You give the user *one* file, and tell
> > him/her to run it. 

> Actually, I see it as being more confusing for the user.  Consider the
> following between and Mac user and a PC user:

[ dialogue deleted to save bandwidth ]

> In order to make use of this feature, one has to 
> 
> a) appreciate the nature of being JZEXE1.0 compliant so that the executable
>    nature of the file does not lead to an immediate dismissal of the idea
>    that it can be useful.
> 
> b) already have an interprter and know that it is JZEXE1.0 compliant.
> 
> c) have a means of getting the file across platforms.  If one is going to
>    use the net, you might as well just get the platform independant datafile.


Well, this is true; I can only say that it's hard to satisfy all the
conflicting needs of all users at once. 

Stand-alone game executables by necessity have to target a particular
architecture (at least with the current state-of-the-art. When all
machines come bundled with Java interpreters, we can start compiling
our games into Java bytecode rather than Z-code. In an ideal world,
all machines would come bundled with Z-code interpreters, but somehow
I don't see that as very likely).

If you want to make your game easy to move between machines, then you
shouldn't make it a standalone executable; you should distribute it as
a Z-code file and trust that your users are sufficiently net-savvy to
find an interpreter to run it.

However, as a game author, if I think that distributing a standa-alone
DOS executable can increase the number of people playing my game, I
will probably do it. I'm not alone in reasoning like that.

Anyway, while I agree with you that making, say, an Amiga interpreter
able of reading stand-alone DOS games won't make things easier for
total beginners on the Amiga side, it will at least enable Amiga users
to play the stand-alone DOS file without having to hunt for a "naked"
Z-code file. (To us, as devoted IF fans, that hunt will seem a small
price to pay, but to someone slightly less devoted, it may very well
be the difference between "OK, I'll give it a try now that I have a
copy on my CD" and "Why bother? There are zillions of other games out
there."

There are really two issues here: why people make stand-alone
games to begin with, and why anybody would want to play such a
stand-alone game on the "wrong" platform rather than go looking for
the pure Z-code on the net. We should keep those two issues separate.


> The current situation seems to be ideal in it's elegance

I think the key word here is "seems". Its elegant to us, who have all
the relevant information, but not necessarily to people who don't.

Besides, I think we're arguing far too much how things *should* be in
an ideal world. It's better to think about the way things are: there
are stand-alone games out there, people (perhaps misguidedly) will
continue to produces them, and users will sometimes want to play them
with another interpreter than the built-in one.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sun Jun 29 11:42:24 1997
Message-Id: <19970628151645.20451@bartlet.df.lth.se>
Date: Sat, 28 Jun 1997 15:16:45 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal: A format for including Z-code in binary files
References: <199706271619.JAA11309@albatros.wco.com> <Pine.SUN.3.95.970627114535.10787F-100000@netcom>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <Pine.SUN.3.95.970627114535.10787F-100000@netcom>; from Andrew Plotkin on Fri, Jun 27, 1997 at 12:19:04PM -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 6d5bd6b7903f6540c48963572f1711a3

On Fri, Jun 27, 1997 at 12:19:04PM -0700, Andrew Plotkin wrote:
> Also, a MaxZip standalone game contains built-in docs which explain the
> nature of interpreters and Z-code games. 

This is excellent. Unfortunately, it's a bit harder to do in a nice,
user-friendly fashion with a command-line interface. (Of course, you
could have a command-line option, but how do you tell the user it's
there? Users *never* read README files :-). You could tack on an
informational screen when the program is started, before control is
passed to the Z-code, but that's rather uglu, I think).

> But I still think (regardless of whether this proposal flies) that an
> author should *never* distribute a standalone game without either
> including the Z-code file, or a self-unbundling option, or including
> instructions on how to get the Z-code file. Or preferably two or more of
> the above.

Agreed. 

> I also still think (regardless of whether this proposal flies) that a
> jzexe standalone game should have an option to unbundle itself, *without* 
> requring you to have the jzexe utility. If it had this, then any
> Masterpieces CD owner with a Mac or PC could extract the Z-code from
> either the MaxZip or jzexe stand-alones. That would solve a large fraction
> of the problem we're talking about. I understand it would not solve the
> entire problem (ie, an Acorn user who bought the Masterpiecs CD would
> still be unable to get the Z-code out from the competition games.)

Again, agreed. In retrospect, it was a design mistake (by me) not to
build the unbundling functionality into the jzip interpreter. If John
H. is reading this: could you consider making a new release of Jzip
with this functionality added?
 
-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sun Jun 29 11:42:25 1997
Message-Id: <19970628153001.22837@bartlet.df.lth.se>
Date: Sat, 28 Jun 1997 15:30:01 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input: Proposal
References: <19970627161547.27665@bartlet.df.lth.se> <yam7117.1398.4138720@smtp.netcomuk.co.uk>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <yam7117.1398.4138720@smtp.netcomuk.co.uk>; from Mark on Fri, Jun 27, 1997 at 07:27:27PM -0000
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 95390adaa70b022fc286fb6131b17222

On Fri, Jun 27, 1997 at 07:27:27PM -0000, Mark wrote:
> On 27-Jun-97, Magnus Olsson wrote:
> >The reason for having stand-alone games, as I see it, is to make it
> >*really* easy for the user. You give the user *one* file, and tell
> >him/her to run it. There's no need to explain how an archive program
> >(like pkzip, or like your proposed program) works, there's no need to
> 
> If you're distributing over the Internet, it's quite likely that some kind of
> archiver will be used anyway; pkzip in the case of PCs, I imagine.

Not necessarily. In the Good Old Days (tm), four years ago or so,
among the first things people learned when venturing onto the net was
using archive programs. Not so anymore. People expect just being able
to click an HTML link and receive a runnable program (or at least a
runnable installation program) without having to bother with
technicalities. Windows programs are usually distributed as
self-extracting exe files, for example.

And an increasing number of FTP sites handle compression
transparently. If I'm not mistake, ftp.gmd.de stores files gzipped,
but automatically unzips them when you download them.

> >explain that "you need these four files in the same directory", there
> >are no conflicts caused by multiple versions of the same program
> >residing on the same machine.
> 
> If you have multiple (Infocom-type) story files, you can potentially use a
> single interpreter program.

Of course. But the proposed alternative to stand-alone games is to
distribute the game together with the interpreter, so the user doesn't
have to download the interpreter separately. So for each game you
download, you get a separate copy of Frotz or whatever.

Big deal, you say, when you download standalone games you *also* get a
lot of copies of the interpreter, bundled within the game file. But
the difference is that in the first case, all these separate
interpreters will be called frotz.exe (or whatever), leading to
potential confusion.

> Also, it would not even be possible to support the proposed 'specification' for
> standalone files on all platforms. Imagine an OS which requires each code/data
> hunk to be <=64Kb in length, and does not allow 'garbage' data to be appended
> to executable files. Didn't 68000 (not 68020 or higher) Mac programs have a
> feature like this?

If your OS doesn't allow "garbage" to be appended to executables, then
the program that builds the standalone executable must handle this by
making the Z-code an actual part of the executable (adding an extra
data segment to the program, for example). Simple concatenation won't
be sufficient, but the resulting file can still satisfy the
specification, provided the file is readable as a byte stream.

Of course, not all OS's allow all files to be read as byte
streams. And there are file systems that put watertight bulkheads
between data files and executables (so that you require special
privileges to modify or read an executable). But these file systems
mostly occur on old, mainframe OS's, that aren't very likely candidates
for standalone Inform games anyway (IF, of course, but distributed in
different ways). 

The Mac OS does pose some problems, as Zarf describes in another
article, but I think we can live with those. Mac users are used to not
being compatible, and I don't see any need to throw out the baby with
the bathwater and rejecting a proposed standard just because some
systems can't conform to it (unless you can come up with a standard
that *everyboy* can conform to, of course!).

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sun Jun 29 11:42:28 1997
Message-Id: <19970628153343.11645@bartlet.df.lth.se>
Date: Sat, 28 Jun 1997 15:33:43 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input
References: <19970627200709.AAA5595@jokisch>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <19970627200709.AAA5595@jokisch>; from Stefan Jokisch on Fri, Jun 27, 1997 at 10:09:09PM +0200
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 43f42d4b6cd8c1f7ffc138bed91ebd1b

On Fri, Jun 27, 1997 at 10:09:09PM +0200, Stefan Jokisch wrote:
> 
> Magnus Olsson wrote:
> 
> > Anyway, you'd have to ask John Holder, since jzip is his interpreter. 
> 
> 90% (or more) of jzip was written by Mark Howell, not John Holder.

Which John also is careful to point out, both in the source and the
docs. But what's your point? This doesn't give me the moral right to
modify John's program (it's still his project, even if only 20% of the
code is his) without his permission.


> Besides, I'm not going to add any kind of support for standalone games to
> Frotz, for reasons which have already been mentioned on this thread.

This is entirely your privilege to decide. Let me point out again that
the purpose of my proposal is *not* to force everybody to produce or
even to read standalone games, only to encourage those who do to do so
in a compatible way.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sun Jun 29 11:42:29 1997
Message-Id: <19970628154625.51309@bartlet.df.lth.se>
Date: Sat, 28 Jun 1997 15:46:25 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal: A format for including Z-code in binary files
References: <19970627133112.04926@bartlet.df.lth.se> <199706271619.JAA11309@albatros.wco.com>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <199706271619.JAA11309@albatros.wco.com>; from Almudtay Petrofsky on Fri, Jun 27, 1997 at 09:19:40AM -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: ddea7d15919027712574928befe683d8

On Fri, Jun 27, 1997 at 09:19:40AM -0700, Almudtay Petrofsky wrote:
> I have three problems with the proposal.  All of them only require
> minor revisions.
> 
>    A JZE1.0 file shall contain exactly one instance of the magic
>    string "JZip/magic (mol)", terminated by an ASCII NULL (a zero
>    byte).
> 
> This places a restriction on the contents of the z-code itself
> (i.e. it can't contain the magic string), which is unnecessary.  Why
> not just say "at least one instance" and in the next paragraph
> "...immediately following the terminating zero of the first
> instance..."?

I can't really see any problems with doing as you suggest.

>    The Z-code part shall be a contiguous byte stream placed after the
>    native data and extending to the end of the file.
> 
> This is also overly restrictive.  If the platform requires the z-code
> to be properly embedded in the executable's data segment, rather than
> just tacked on, then there may need to be some bytes after the z-code.
> The length of the z-code is self-evident from its header, so why not
> allow extra data to occur after it?

Sorry, I was a bit sloppy here. My definition really means that the
Z-code part consists of the actual Z-code, *plus* possible additional
garbage at the end (since the interpreter will know not to read that
"garbage" anyway). The definition should be updated to make this
clear, or possibly changed so that the Z-code portion is defined to
have a length defined by the Z-code header (invalid if no header is
found).


> Lastly, the string "JZip/magic (mol)" belies the fact that this is
> intended to be a cross-platform, cross-interpreter standard.  Without
> breaking compatibility with the old files, we could use the more
> generic "Zip/magic (XXX)" where the XXX may be anything.  

This is quite clever. Omitting the "J" simply didn't occur to me. The
only potential drawback to this is that by decreasing the specificity
of the string, we increase the probability that it will occur by
random in the file (for example, in the Z-code generated by some
arcane new library routine). The probability is still astronomically
small, of course!

We could also reserve som combinations of the letters XXX to allow for
future expansions of the format. For example, if the XXX string starts
with a '*', the bytes following the terminating zero may contain the
offsets of _several_ Z-code data segments.

>Similarly, the name JZE1.0 creates the wrong impression.

I simply couldn't think of anything better at short notice. On the
other hand, "JZE" needn't mean something in particular (there are lots
of acronyms that started out meaning something and rapidly lost all
connection to the original meaning).

I'm leaving on vacation tomorrow, so I won't have much more
opportunity to participate in this discussion during July. If you
like, feel free to present an updated proposal.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Sun Jun 29 11:59:50 1997
Date: Sat, 28 Jun 1997 16:35:43 -0700 (PDT)
From: Matt Ackeret <mattack@vax.area.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzexe files as input: Proposal
In-Reply-To: <19970628153001.22837@bartlet.df.lth.se>
Message-Id: <Pine.GSO.3.95.970628163017.13017E-100000@vax.area.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 922d17aa8be9703180716c9f89b22870

On Sat, 28 Jun 1997, Magnus Olsson wrote:
>And an increasing number of FTP sites handle compression
>transparently. If I'm not mistake, ftp.gmd.de stores files gzipped,
>but automatically unzips them when you download them.

Only if you "get" them without the .gz extension.  So this requires
(1) that you know about the capability (but it is often mentioned in 
the tons of junk spewed at you when you log onto an ftp site)
(2) that you're using a CLI-based ftp program.  (Since Fetch, for example,
just lets you drag files out or double-click on them to download them..
it gets them in their entirety I highly highly suspect.)

So basically this really makes it *more* complex for most people.

(I agree in general that you can click on a file when you're downloading
it with a *web browser* [which is like using a sledgehammer to screw in a
screw], then stuffit expander or something else takes over..  obviously
I'm talking about with GUI web browsers..  Lynx doesn't do any of this.)


From ???@??? Sun Jun 29 12:09:15 1997
Message-Id: <3.0.32.19970629115908.006aaf40@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 29 Jun 1997 11:59:37 +1200
To: Magnus Olsson <mol@df.lth.se>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Proposal: A format for including Z-code in
  binary files
Cc: z-machine@gmd.de
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"
X-UIDL: beea7b94ed52763d00e3f4349f539f9d
Status: U

At 15:46 28/06/97 +0200, Magnus Olsson wrote:
>This is quite clever. Omitting the "J" simply didn't occur to me. The
>only potential drawback to this is that by decreasing the specificity
>of the string, we increase the probability that it will occur by
>random in the file (for example, in the Z-code generated by some
>arcane new library routine). The probability is still astronomically
>small, of course!

I don't see that as a problem with the Z-code; if the other suggestion
(snipped out of this reply) that more than one occurance is allowed and
only the first is relevant, then any occurance of this string appearing in
the Z-code will occur *after* the real information stored in the
interpreter's code, which of necessity appears in the file *before* the
Z-code.

I still don't really see too much point in this specification, however; if
an author wants to distribute files as self-executable, they should accept
that it limits their possible user base.  If they want to distribute an
executable but still allow other platforms to run it, they should either
include the Z-code file or tell the user where they can find it (web site,
etc).  In either case they should probably also refer people to the IF site
so they can get an interpreter for their platform if they don't already
have one.

-----                                
     _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
    _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
   _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
  _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/

Gavin Lambert
uecasm@geocities.com
http://crash.ihug.co.nz/~brianc
http://ue.home.ml.org/

"We now return to our regularly scheduled flame-throwing."
"PCMCIA:  People Can't Memorise Computer Industry Acronyms."
"ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."


From ???@??? Sun Jun 29 21:57:58 1997
Date: 29 Jun 97 03:07:16 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] [blorb] Final comments o
Message-Id: <970629070716_104312.2206_IHS50-1@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: b8f165e8d3613799047beaa399b9a805
Status: U


Graham wrote:
> Interpreter writers flinch from the _reputation_ of Z6 as much as
> the actuality.  For a long time Z6 has been documented only in
> long, confusing wrangles, one always contradicting another one,
> provoking headaches about where the cursor should go and when the
> buffer flushes and...

Andrew replied:
> Well, I'll tell you what it is for me (which I already said
> last night, I guess): I can't leverage off my existing code. My Z5 
> text engine (essentially the same in xzip and MaxZip) is just not
> compatible with the kind of screen control the Z6 machine has.

Snap.  I've spent a lot of time hammering on the ITF screen model to 
get it to support proportional text and dynamic resizing (even with the 
blasted block quotes).  Z6 screen handling means going back to square 
one, and won't actually *permit* resizing.  That may sound a minor 
problem, but it isn't.  The Psion 3a introduced the notion of 'zooming' 
where the window size remains fixed but the font size can be scaled up 
and down whenever the user wants.  When reading an LCD panel in varying 
light conditions, this soon becomes indispensable ... so much so that I 
find it hard to take seriously those programs which don't support it.

    Bryan

 


From ???@??? Sun Jun 29 21:58:05 1997
Date: 29 Jun 97 03:07:20 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: RE: [z-machine] Non-V6 pictures?
Message-Id: <970629070720_104312.2206_IHS50-2@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: b1e57c5b86db8f672586b1de732b81fd
Status: U


I apparently opened a potential ant's nest with:

>This is all good fun, but do we have to reserve graphics for Z6?  
>(Given that mentioning the Z6 machine seems to cause many of the 
>interpreter writers to flinch.)  Is there any way we can implement 
>simple graphics (something like the block quotes which seem so 
>popular) without breaking Z5 compatibility?

John Kennedy replied:

>This is of interest to me, too; I've been toying with the idea of a
>web-hosted interpreter, not a Java-hosted interpreter, but a z-machine 
>webserver, with a Java applet at the client to display the text and 
>accept input.

Fun.  Did something like this at work last year: replaced the Tix GUI 
on a product with a Java version.  Hasn't been used yet, but it means 
we can deploy a demo across the Web if we ever find someone willing to 
host the multiple 32M+, compute-and-swap-intensive backend processes 
they would need to connect to.
  
>May I propose the following for the next version of the standard?
> 
>Allow the interpreter to set the "pictures" bit in the header in
>non-V6.
> 
>Ignore the pictures if they cannot be displayed.
> 
>Require the program to query the "pictures" bit and complain
>if the pictures are needed to play, and not pure decoration.

Sounds okay to me, assuming of course the picture bit is handled 
correctly on older interpreters.  I'd add 'ignore the picture being 
missing' as an extreme version of 'cannot be displayed'.

>A [Pictures all on a separate "graphics screen"]
>
>or
>
>B [One picture per window with the interpreter asking for windows]

I had a vague notion in mind that was simpler than either of those ... 
pictures centred over the 'top' of the text display and being cleared 
when a key was hit.  Alas, that has the same problem as (B) in that the 
games can't build complex images (like updating a map) by overplotting 
small images on a larger backdrop.

(A) probably works quite well, but I have doubts about detecting clicks 
on the graphic window ... it assumes the machine has a pointing device.

>Define additional extended-header fields to provide the game
>with the graphics-screen size.

Or we could just overload the picture_data opcode to return this, say 
for picture_number=$FFFF.

    Bryan

 


From ???@??? Sun Jun 29 21:58:10 1997
Date: 29 Jun 97 03:07:23 EDT
From: Bryan Scattergood <104312.2206@CompuServe.COM>
To: "internet:D.Archer@uea.ac.uk" <D.Archer@uea.ac.uk>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Subject: Re: [z-machine] Jzexe files as input: Pr
Message-Id: <970629070722_104312.2206_IHS50-3@CompuServe.COM>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: deffd060772a34ce39fe78dd251da362
Status: U


Dan Archer wrote:

> smaller machines (such as the Psion and similar organisers) can play 
> story files, but would die if fed an interpreter/z-machine combo of > 
any size.

'Die' may be putting it a little strongly, but lugging round 30k+ of 
useless attached interpreter (per game file) on machines with less than 
1M of total storage makes no sense whatsoever.  I'm opposed to 
attaching interpreters to game files on general principle: I can't see 
the point when (1) the games are inherently multi-platform and (2) even 
on a specific platform there is generally a choice of interpreters.  If 
you must ship the game with an interpreter, what's wrong with using a 
batch file (or equivalent glue) to tie the parts together?

If the Masterpieces CD does have some games *only* in embedded form, 
then I could be convinced of the need for tools to split out the data 
file on all the CD-reading platforms (Acorn, Amiga, Atari, DOS, Mac, 
BeOS, Unix ...) but *not* that the functionality should be in the 
interpreter.  (Although if I can get the tools to split the files from 
the net, surely I can just pull the data files from gmd.de?)

    Bryan

 


From ???@??? Sun Jun 29 21:58:11 1997
Message-Id: <19970629093336.32764@bartlet.df.lth.se>
Date: Sun, 29 Jun 1997 09:33:36 +0200
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal: A format for including Z-code in binary files
References: <3.0.32.19970629115908.006aaf40@pop.ihug.co.nz>
Mime-Version: 1.0
X-Mailer: Mutt 0.64
In-Reply-To: <3.0.32.19970629115908.006aaf40@pop.ihug.co.nz>; from Gavin Lambert on Sun, Jun 29, 1997 at 11:59:37AM +1200
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: c56164c1cc371cb96737c3f3cb47d973
Status: U

On Sun, Jun 29, 1997 at 11:59:37AM +1200, Gavin Lambert wrote:
> 
> I still don't really see too much point in this specification, however; if
> an author wants to distribute files as self-executable, they should accept
> that it limits their possible user base.  If they want to distribute an
> executable but still allow other platforms to run it, they should either
> include the Z-code file or tell the user where they can find it (web site,
> etc).  In either case they should probably also refer people to the IF site
> so they can get an interpreter for their platform if they don't already
> have one.

All this is true, but again I think we're getting sidetracked
discussing how things *should* be. My proposal is simply aimed at
making the world a little less complicated given the fact that some
people _are_ releasing stand-alone games, regardless of whether they
"should" or not. If these game files all share a basic structure, then
it will at least be possible to extract the Z-code from them with minimal
effort.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

From ???@??? Mon Jul 07 16:21:08 1997
Message-Id: <XFMail.970703110217.kessinger@szs.ira.uka.de>
X-Mailer: XFMail 1.1 [p0] on Linux
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
In-Reply-To: <199706251350.JAA23180@wanda.vf.pond.com>
Date: Thu, 03 Jul 1997 10:57:46 +0200 (CEST)
From: kessinger@szs.ira.uka.de
To: z-machine@gmd.de
Subject: [z-machine] Update on InCorrect
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: 5babda5e1f6c7c49c93f0335e3321141
Status: U


I think after this time I can make a final judgement on
the demand for a source debugger for inform on Linux and 
will invest my time proportional to the feedback I got.


--------------------------------------------
Love is the victory of imagination over intelligence - Mencken
Ingo Kessinger kessinger@szs.ira.uka.de

From ???@??? Thu Jul 10 16:16:38 1997
Newsgroups: rec.arts.int-fiction
Date: Mon, 07 Jul 1997 00:22:16 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Inform Designer's Manual on line
Message-Id: <ant062316d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Organization: none
X-Newsreader: ANT RISCOS Marcel [ver 1.09]
Apparently-To: <z-machine@gmd.de>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: fc0ed001063d236605a2ea5963e3531c


The Inform Designer's Manual is finally available for on-line
browsing from the Inform home page.  The URL to bookmark (which
I intend to be stable) is:

  http://www.gnelson.demon.co.uk/dman/index.html

which corresponds to the title-page-and-brief-contents of the
printed version.  The text was translated mechanically (by an
unspeakable Perl script) and is up to date with the current
edition (including errata).  This process is still a little
experimental and please feel free to report anything that looks
like an error.

Once again, as I always say at times like this, there may be a
slight delay before my ISP makes the files accessible to people
across the rest of the Internet: if you can't see a file there at
all, please try again a little later.

Many thanks to Richard Stamp, who showed me how this translation
could be done and went to the trouble of making a rough cut of
several sections.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Thu Jul 10 16:16:41 1997
Date: Mon, 07 Jul 1997 23:55:56 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Windows 32 interpreter?
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.09-0707225556-313M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.09]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
X-UIDL: 18fa10be5adfeac21c6f2b7eba56af94


Can anyone help this man with his enquiries?  I'm afraid the
world of Microsoft is a closed book to me (or perhaps that
should be a closed giant clam -- but I was never very good at
identifying bivalves).

If anyone could email Mr Dobbs with a sensible reply, I'd be
grateful.  Thanks,

  Graham

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom
---------- Forwarded message ----------
Date: Fri, 27 JUN 1997 11:35:49 +0000
From: Christopher Richard Dobbs <dobbsc@omc.bt.co.uk>
To: graham@gnelson.demon.co.uk
Subject: Win32

Graham,

            I don't suppose you know of any  interpreters (inc. source
code) that I could
            get hold of which are for Win32 and written using microsoft
Visual C?
            (preferably a full windows app using straight C...hate MFC)

                                -Regards,

                                                            -Chris




From ???@??? Tue Jul 22 19:45:41 1997
Message-Id: <199707181753.TAA03956@dns.speednet.it>
X-Mailer: Microsoft Outlook Express 4.71.0544.0
From: "Giovanni Riccardi" <g.riccardi@speednet.it>
To: "z-machine mailing list" <z-machine@gmd.de>
Subject: [z-machine] IS THERE ANYONE AT HOME???
Date: Thu, 17 Jul 1997 16:16:01 +0200
X-Priority: 3
X-Msmail-Priority: Normal
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: 7dbfa954174bd28496495c2baad6aee4

What do you think of restarting to write down something about Infix???
Next year tea party is approaching (read last infix newsletter) ...

       \IIIII/
       (o) (o)
---oOO-- (_) --OOo----------------------------------
                          "How do you know I'm mad?"
                          said Alice. "You must be,"
  Giovanni  Riccardi      said the Cat "or you 
g.riccardi@speednet.it    wouldn't have come here."
   Terracina  Italy
                          - L. Carrol "Alice's 
                           Adventures in Wonderland"
----------------------------------------------------



From ???@??? Tue Jul 22 19:46:01 1997
Message-Id: <AFb67CAF67zzEwcD@elvw.demon.co.uk>
Date: Fri, 18 Jul 1997 20:05:41 +0100
To: z-machine@gmd.de
From: John Wood <John@elvw.demon.co.uk>
Subject: Re: [z-machine] IS THERE ANYONE AT HOME???
In-Reply-To: <199707181753.TAA03956@dns.speednet.it>
Mime-Version: 1.0
X-Mailer: Turnpike Version 1.12 <iAlJJHde64yJEPSoUQngOCV0T3>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 0d785cc5aadbc35edf17bb38544a86bd

Giovanni Riccardi <g.riccardi@speednet.it> wrote,
>What do you think of restarting to write down something about Infix???
>Next year tea party is approaching (read last infix newsletter) ...

Well, I decided to just carry on on my own and adapt WinFrotz as my
"Winfix" interpreter.  Life seems to get in the way of my actually
doing very much on it, though - for instance, I have no free weekends
until the end of September(!), and I'm working long hours during the
week to try and get things under control before my belated honeymoon end
of August.  Rest assured, I've spent 100% of my fun programming time on
it this last couple of months...which amounts to a few hours. 8-(

Talk about biting off more than you can chew...
 
John G. Wood  |  john@elvw.demon.co.uk  |  Oxford, United Kingdom

From ???@??? Tue Jul 22 19:45:51 1997
From: Stephen van Egmond <svanegmo@truespectra.com>
Message-Id: <199707201728.NAA30117@plymouth.truespectra.com>
Subject: [z-machine] Infix proposal
To: z-machine@gmd.de
Date: Sun, 20 Jul 1997 13:28:00 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: fd66221330a9e1e58ccc037e1b15f108

I would like to revive it myself.  At the moment I am going bonkers
putting together some stuff for Boston Macworld.  If anyone is from that
area, come by the BeOS booth and visit me (TrueSpectra pedestal).

Meanwhile, I've lost the most recent proposal.  Where are they archived,
Giovanni?

/Steve


From ???@??? Fri Aug 08 16:50:49 1997
Message-Id: <33E6FF02.91659756@doc.ic.ac.uk>
Date: Tue, 05 Aug 1997 11:22:59 +0100
From: Daniel Collins <dwc1@doc.ic.ac.uk>
Organization: Imperial College
X-Mailer: Mozilla 4.01b6C [en] (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: z-machine@gmd.de
Subject: [z-machine] Few queries on Standard 1.0
X-Priority: 3 (Normal)
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: c0a8aafcb95ab6d95be1e3a4c881d27a

Just a few questions I wanted to raise that I have noticed...

>3.8.5.3 The default Unicode translation table
>
>ZSCII	Unicode		character
>162	0x0ab		>>
>163	0x0bb		<<

On checking my Unicode spec, (and by printing the two characters) it
seems that these two have got reversed. According to my information 
	<< is Unicode 0x0bb and
	<< is Unicode 0x0ab

or at least this is what Java prints!

Can someone confirm/deny this, and does it just mean reversing the two
unicodes in the table (I seem to remember there was some problem with
these two characters being reversed in Standard 0.2, it might be left
over from that?)

> 11.1.7.1
> 
> If the interpreter needs to read a word which is beyond the length of the extension table, or the extension table doesn't exist at all, then
> the result is 0. 
> 
> 
> 11.1.7.2
> 
> If the interpreter needs to read a word which is beyond the length of the extension table, or the extension table doesn't exist at all, then
> the result is that nothing happens. 

Er, is it my imagination or do these sections contradict each other?
Well, maybe contradict is not the right word, but are they both
necessary?


Lastly, two points which are just due to my inept reading/understanding
of the specification.

Is Object 0 a valid Object? Should calls to get_parent 0, get_property 0
x, ... be allowed? I think my understanding is that they should, but
they would generally return 0 (i.e. no parent, no properties,...)

Am I right in assuming that versions 7 and 8 are not linked in any way
to version 6? So when in the specification is says version 5 and later,
that means 5,6,7,8, but '6 and later' means only 6? (Just checked the
relevant part is to do with the filesize as stored in the header, the
multiplier is 4 for versions 4 and 5 and 8 for versions 6 and later,
think jzip assumes 8 for version 8 but doesn't mention v7)

Thanks for the help,

Daniel Collins
MSc Computing Science
(d.w.collins@ic.ac.uk)

From ???@??? Fri Aug 08 16:50:52 1997
Message-Id: <33E70027.80D7A835@doc.ic.ac.uk>
Date: Tue, 05 Aug 1997 11:27:51 +0100
From: Daniel Collins <dwc1@doc.ic.ac.uk>
Organization: Imperial College
X-Mailer: Mozilla 4.01b6C [en] (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: z-machine@gmd.de
Subject: [z-machine] Oops - queries on Standard 1.0
X-Priority: 3 (Normal)
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-UIDL: b6795f517f62d8a56390339ac4843567

Doh!, Apologies but I just spotted a mistake in the last mail..

> >3.8.5.3 The default Unicode translation table
> >
> >ZSCII  Unicode         character
> >162    0x0ab           >>
> >163    0x0bb           <<
> 
> On checking my Unicode spec, (and by printing the two characters) it
> seems that these two have got reversed. According to my information 
>         << is Unicode 0x0bb and
>         << is Unicode 0x0ab
> 
> or at least this is what Java prints!

Managed to get those two reversed (again!)

That should have read:
According to my information 
         >> is Unicode 0x0bb and
         << is Unicode 0x0ab

Yeah, that's better, managed to get it right this time.

Sorry about that,

Daniel Collins

From ???@??? Fri Aug 08 16:50:53 1997
Date: Tue, 05 Aug 1997 11:59:21 +0100 (BST)
From: Kevin Bracey <kbracey@acorn.com>
Subject: [z-machine] Beyond Zork and "blow circlet"
To: z-machine@gmd.de
Message-Id: <Marcel-1.20-0805105921-b49LJLo@ether313.acorn.co.uk>
Mime-Version: 1.0
X-Organization: Acorn Risc Technologies, Cambridge, United Kingdom
X-Mailer: ANT RISCOS Marcel [ver 1.20a]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-UIDL: b1e61bfcc80fcdfc82ad8cf6766da406

Apologies for the spoiler, but mere players of games shouldn't be on
this list :)

I recently had a complaint that Zip 2000 crashes when the player
types "blow circlet" to create a mirror in the endgame. On investigation,
this appears to be a bug in the Beyond Zork game file.

As the circlet is blown, the game executes the equivalent of the following
Inform code:

           give circlet ~loaded;
           SwapNoun("circlet", "film", "zzzp");
           SwapAdjective("circlet", "swirling", "zzzp");

where the swap routines look up the object's array of nouns and adjectives
and replace, say, the word "film" by "zzzp". But note the mistake. The
swap routines do GET_PROP_ADDR on their first parameter - they're expecting
an object number, not a dictionary word!

Has anyone else spotted this bug? What do you reckon the interpreter
should do when given a bogus object number? Define "bogus" :) The
original ZIP survived because its routine to find the address of an
object wrapped within a 16-bit range - GET_PROP_ADDR ends up returning
0 and the Swap routines fail silently. Zip 2000 ends up accessing memory
way outside the game file and bombs out with an abort on data transfer
error. Plugh.

I think we need a Standard ruling on how to cope with this.
Any suggestions? And no, I don't want start adding special behaviour
for certain game files. That way madness lies...

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725901
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Fri Aug 08 16:50:56 1997
From: h0142kdd@rz.hu-berlin.de ()
Message-Id: <199708051316.PAA03069@joker.rz.hu-berlin.de>
Subject: Re: [z-machine] Beyond Zork and "blow circlet"
To: z-machine@gmd.de
Date: Tue, 5 Aug 1997 15:16:42 +0200 (MET)
In-Reply-To: <Marcel-1.20-0805105921-b49LJLo@ether313.acorn.co.uk> from "Kevin Bracey" at Aug 5, 97 11:59:21 am
X-Mailer: ELM [version 2.4 PL23]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 4d839c15a7772895c09bde02af64f0da

> Has anyone else spotted this bug? What do you reckon the interpreter
> should do when given a bogus object number? Define "bogus" :) The
> original ZIP survived because its routine to find the address of an
> object wrapped within a 16-bit range - GET_PROP_ADDR ends up returning
> 0 and the Swap routines fail silently. Zip 2000 ends up accessing memory
> way outside the game file and bombs out with an abort on data transfer
> error. Plugh.

This bug was found by Matthias Pfaller in 1994; a fix for the
"zterp" interpreter was circulated in 1995, and Mark Howell said
he would put the same fix in the ZIP sources. I'm not sure
whether this fixed version of ZIP was ever released though.
Anyway, it's a known bug.

-- Dave


From ???@??? Mon Aug 11 16:24:26 1997
Date: Sat, 09 Aug 1997 11:07:26 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Few queries on Standard 1.0
To: Z-Machine Mailing List <z-machine@gmd.de>,
        Daniel Collins <dwc1@doc.ic.ac.uk>
In-Reply-To: <33E6FF02.91659756@doc.ic.ac.uk>
Message-Id: <Marcel-1.26-0809100726-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-UIDL: f7b8e1e6366fe854e83273808ab0f09c

On Tue 05 Aug, Daniel Collins wrote:
> Just a few questions I wanted to raise that I have noticed...
> 
> >3.8.5.3 The default Unicode translation table
> >
> >ZSCII	Unicode		character
> >162	0x0ab		>>
> >163	0x0bb		<<
> 
> On checking my Unicode spec, (and by printing the two characters) it
> seems that these two have got reversed. According to my information 
> 	>> is Unicode 0x0bb and
> 	<< is Unicode 0x0ab
> 
> or at least this is what Java prints!

Yes, you're right: this is a misprint.  0x00ab is << and 0x00bb is >>.
ZSCII 162 is >> and ZSCII 163 is <<.  I will correct this.

> (I seem to remember there was some problem with
> these two characters being reversed in Standard 0.2, it might be left
> over from that?)

I think this is a quite unrelated blunder, but that's how much fun it is
working on standards documents.

> > 11.1.7.1
> > 
> > If the interpreter needs to read a word which is beyond the length of the extension 
> table, or the extension table doesn't exist at all, then
> > the result is 0. 
> > 
> > 11.1.7.2
> > 
> > If the interpreter needs to read a word which is beyond the length of the extension 
> table, or the extension table doesn't exist at all, then
> > the result is that nothing happens. 
> 
> Er, is it my imagination or do these sections contradict each other?
> Well, maybe contradict is not the right word, but are they both
> necessary?

Section 11.1.7.2 is supposed to refer to writing a word, not reading:
unfortunately the crucial verb "write" seems to have come out as "read".
Another misprint.

> Lastly, two points which are just due to my inept reading/understanding
> of the specification.
> 
> Is Object 0 a valid Object? Should calls to get_parent 0, get_property 0
> x, ... be allowed? I think my understanding is that they should, but
> they would generally return 0 (i.e. no parent, no properties,...)

Object 0 is not a valid object.  Formally it is undefined what the
get_... opcodes do with object number 0, and some speed-hungry interpreters
might just crash.  Certainly it's formally illegal for a Z-machine program
to contain, say, get_parent 0.  I think it's probably best to produce an
error message, if you can spare the cycles to check the case in the first
place.  Returning 0 might mask a serious mistake in the program from its
author, causing trouble when the game file is given to other people and
other less forgiving interpreters.

> Am I right in assuming that versions 7 and 8 are not linked in any way
> to version 6?

Yes.

> So when in the specification is says version 5 and later,
> that means 5,6,7,8, but '6 and later' means only 6? (Just checked the
> relevant part is to do with the filesize as stored in the header, the
> multiplier is 4 for versions 4 and 5 and 8 for versions 6 and later,
> think jzip assumes 8 for version 8 but doesn't mention v7)

I think there's a general declaration after section 1 that V7 and V8
are exactly like V5 for all specification purposes except the
translation of packed addresses and the usage of the size slot in the
header.  Anyway, that's the case.  "Version 5 or later" does mean
"V5, 6, 7, 8": almost everything introduced in Version 6 is quite
unique to Version 6.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Mon Aug 11 16:24:30 1997
Date: Sat, 09 Aug 1997 11:24:10 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Call for Inform bug reports
To: Z-Machine Mailing List <z-machine@gmd.de>, FemaleDeer@aol.com
Message-Id: <Marcel-1.26-0809102410-bc8M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-UIDL: f6cae68a67d0cd64370f9370e8211dcc


Dear All,

I am now back from a climbing holiday in the Swiss Alps and would
like to apologise to all those who've emailed me in the last few
weeks and heard nothing in reply.  (Cynics will say this is pretty
much business as usual...)  I am now going through the backlog.

I intend to make a "maintenance" release of Inform -- i.e., to fix
the known bugs -- in the next week or so.  (I'll be seeing to both
compiler and library.)  If anyone out there has a bug report to
send, I'd be very pleased to have it...

The compiler seems to be in generally good shape and few bugs have
been reported in it, _but_ I am concerned about the possible bug
(which has been discussed on rec.arts.int-fiction, following
FemaleDeer@aol.com's unhappy experiences) when the Z-code area of
a game exceeds 256K, causing backpatching errors.  This seems to
be happening as a result of intensive use of print and print_ret
rather than quoting text in property values (not that that's bad
behaviour in any way!).  I suspect it can be fixed simply by making
Inform quietly move print and print_ret text into the static
strings area when the Z-code area gets to a certain size, or
something like that.  However, any information anyone can give me
of a more specific nature -- any confirmation that the above is
indeed the nature of the problem, for instance -- would be
welcomed.

Of course "backpatch errors" should never be seen at any time if
the compiler is working properly, so something is definitely awry.
Obviously I was hoping to fall into a crevasse and thus not have
to come to home and fix this, but since I seem to have survived,
I do now regard this error as being urgent.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Mon Aug 11 16:24:33 1997
Date: Sun, 10 Aug 1997 07:57:24 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom13
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Beyond Zork and "blow circlet"
In-Reply-To: <199708051316.PAA03069@joker.rz.hu-berlin.de>
Message-Id: <Pine.SUN.3.95.970810075200.11165A-100000@netcom13>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: b9c0be59a080ab63ef63a3bfae13631d

On Tue, 5 Aug 1997 h0142kdd@rz.hu-berlin.de wrote:

> > Has anyone else spotted this bug? What do you reckon the interpreter
> > should do when given a bogus object number? Define "bogus" :) The
> > original ZIP survived because its routine to find the address of an
> > object wrapped within a 16-bit range - GET_PROP_ADDR ends up returning
> > 0 and the Swap routines fail silently. Zip 2000 ends up accessing memory
> > way outside the game file and bombs out with an abort on data transfer
> > error. Plugh.
> 
> This bug was found by Matthias Pfaller in 1994; a fix for the
> "zterp" interpreter was circulated in 1995, and Mark Howell said
> he would put the same fix in the ZIP sources. I'm not sure
> whether this fixed version of ZIP was ever released though.

If I understand the problem correctly, it shouldn't occur in ZIP 2.0.7,
because all the work in get_property_addr() is done with 16-bit variables. 
The get_object_address() routine works with an "int" variable but then
casts it to 16 bits when returning it.

I'm pretty sure I've played Beyond Zork through with MaxZip, which is
207-based.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Mon Aug 11 16:24:35 1997
From: h0142kdd@rz.hu-berlin.de ()
Message-Id: <199708101727.TAA02492@joker.rz.hu-berlin.de>
Subject: Re: [z-machine] Beyond Zork and "blow circlet"
To: z-machine@gmd.de
Date: Sun, 10 Aug 1997 19:27:48 +0200 (MET)
In-Reply-To: <Pine.SUN.3.95.970810075200.11165A-100000@netcom13> from "Andrew Plotkin" at Aug 10, 97 07:57:24 am
X-Mailer: ELM [version 2.4 PL23]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: c93575c4165da20809871165352a7e8b

> > This bug was found by Matthias Pfaller in 1994; a fix for the
> > "zterp" interpreter was circulated in 1995, and Mark Howell said
> > he would put the same fix in the ZIP sources. I'm not sure
> > whether this fixed version of ZIP was ever released though.
> 
> If I understand the problem correctly, it shouldn't occur in ZIP 2.0.7,
> because all the work in get_property_addr() is done with 16-bit variables. 
> The get_object_address() routine works with an "int" variable but then
> casts it to 16 bits when returning it.
> 
> I'm pretty sure I've played Beyond Zork through with MaxZip, which is
> 207-based.

It might be that the problem never materializes on a Mac for some 
reason, but a fix is definitely needed for other platforms. Frotz,
BTW, has such a fix as part of object.c (snippet appended).

-- Dave

PS: For the record, there is no "ZIP 2.0.7". The version number is 
2.0, and the '7' is part of the date when 2.0 was released.


Addendum: get_property_address implementation in Frotz/object.c

/*
 * z_get_prop_addr, store the address of an object property.
 *
 *	zargs[0] = object
 *	zargs[1] = number of property to be examined
 *
 */

void z_get_prop_addr (void)
{
    zword prop_addr;
    zbyte value;
    zbyte mask;

    /* Beyond Zork accidently uses the address of the vocabulary entry
       "circlet" instead of its object number */

    if (story_id == BEYOND_ZORK)

	if (zargs[0] > MAX_OBJECT) {
	    store (0);
	    return;
	}

    /* Property id is in bottom five (six) bits */

    mask = (h_version <= V3) ? 0x1f : 0x3f;

    /* Load address of first property */

    prop_addr = first_property (zargs[0]);

    /* Scan down the property list */

    for (;;) {
	LOW_BYTE (prop_addr, value)
	if ((value & mask) <= zargs[1])
	    break;
	prop_addr = next_property (prop_addr);
    }

    /* Calculate the property address or return zero */

    if ((value & mask) == zargs[1]) {

	if (h_version >= V4 && (value & 0x80))
	    prop_addr++;
	store (ZWORD (prop_addr + 1));

    } else store (0);

}/* z_get_prop_addr */


From ???@??? Sat Aug 23 15:28:20 1997
Date: Thu, 21 Aug 1997 11:50:40 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Who called it the "Z-Machine"?
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.26-0821105040-1cbM+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-UIDL: 6d409ae63a19245529f1928de082ad2d


>From a reader's query on rec.arts.int-fiction:

> Hi.  I have a question, and it's just out of curiosity.  Why is the
> imaginary machine in which all Infocom and Inform games are executed 
> called "The Z Machine?"  I know that the Inform files have extentions
> like ".Z5", ".Z8", etc, but where did the name come from?

It's actually a good question.  Infocom didn't call the object-code
format "the Z-machine": they had an assembler called ZAP which took
the assembly-language output from the compiler, ZILCH, and converted
it to ZIP.

Unfortunately they used the term ZIP to mean both the architecture
of the virtual machine and its interpreter (the "Zork Implementation
Program"), and even sometimes to mean story files.  This carried on
through EZIP, YZIP, etc., which we would now call Version 4
interpreters or the V4 virtual machine, and so on.

The problem was complicated for us, meaning Infocom hackers in the
early 1990s, by Mark Howell's ground-breaking interpreter Zip -- which
came to include ZIP, EZIP, etc. -- and the fact that there was a
file-compression format called ".zip", leading to confusion with
filenames at ftp.gmd.de.

The useful term "Z-Machine", meaning the architecture of the virtual
machine only, was (I'm pretty sure) not in circulation when I began
Inform in 1993 -- although people had written programs related to the
Z-Machine, they hadn't really written documents about it, with the
exception of some scraps by Mike Threepoint and a few others (mostly
listing the header format).  So the term had not then been needed.
I think the earliest document trying to specify the whole thing,
collating a lot of work by other people, was by me, but I was still
calling it "the ZIP".

I have a feeling that Marnix Klooster may have coined the term, but
there are numerous other suspects -- Stefan Jokisch?  Dave Doherty?
Mark Howell?  At any rate, it wasn't me.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Sat Aug 23 15:28:23 1997
Message-Id: <199708211910.PAA31766@plymouth.truespectra.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Who called it the "Z-Machine"?
Date: Thu, 21 Aug 97 15:09:21 WAT
From: "Stephen van Egmond" <svanegmo@truespectra.com>
Reply-To: svanegmo@truespectra.com
X-Mailer: BeMail [version 2.0]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="iso-8859-1"
X-UIDL: d7228bdc4d78ed9db6dac9bfe75974ea

>The useful term "Z-Machine", meaning the architecture of the virtual
>machine only, was (I'm pretty sure) not in circulation when I began
>Inform in 1993 -- although people had written programs related to the
>Z-Machine, they hadn't really written documents about it, with the
>exception of some scraps by Mike Threepoint and a few others (mostly
>listing the header format).  So the term had not then been needed.
>I think the earliest document trying to specify the whole thing,
>collating a lot of work by other people, was by me, but I was still
>calling it "the ZIP".

I found an occurrence of this term in the Infocom Fact sheet, version 4.2, 
posted to r.a.i-f in January 1993, and there is reference to the interpreter
"zmachine" from November 1992.

/Steve

From ???@??? Sat Aug 23 15:28:22 1997
Date: Thu, 21 Aug 1997 14:46:27 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Graham Nelson <graham@gnelson.demon.co.uk>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Who called it the "Z-Machine"?
In-Reply-To: <Marcel-1.26-0821105040-1cbM+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SGI.3.95.970821144550.18206G-100000@vangogh.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: ad712d1626498de8ea20e4f4389ecdd7

On Thu, 21 Aug 1997, Graham Nelson wrote: 
>> Hi.  I have a question, and it's just out of curiosity.  Why is the
>> imaginary machine in which all Infocom and Inform games are executed 
>> called "The Z Machine?"  I know that the Inform files have extentions
>> like ".Z5", ".Z8", etc, but where did the name come from?

<fascinating information snipped>

... although I suppose what he actually wanted to know was that 'Z' stands
for "Zork".

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Aug 23 15:28:25 1997
Message-Id: <m0x1qCS-000474C@machinecop.doc.ic.ac.uk>
Date: Fri, 22 Aug 97 10:40 BST
From: Martin Frost <mdf@doc.ic.ac.uk>
To: z-machine@gmd.de
Subject: [z-machine] Save-file format.
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: dacff3466a86f724ec399b86d383aa20

This was posted in raif, and I was interested in whether anyone is actually
doing anything with the Quetzal format (all appears to have gone quiet)..

From: michael.baum@nist.gov (Michael Baum)
Subject: Whatever happened to standard Z-machine save format?
Date: 19 Aug 1997 20:13:14 GMT
Organization: National Institute of Standards & Technology
Lines: 15
NNTP-Posting-Host: 129.6.176.38
X-Newsreader: IBM NewsReader/2 2.0

So I was just sitting around the conversation pit the other night 
thinking what a nuisance it was that z-machine games saved on 
one of my computers could not be run on another because I have to
use different interpreters. By purest serendipity, while trying to do
something else on the net I came across what would seem to be a
standards doc from last March proposing a common save-file format,
apparently named "Quetzal" (?????)

Does anyone know the status of this? Has it been incorporated in any
multi-platform z-machine interpreters? Specifically, I'm looking for
interpreters for OS/2, MS-DOS, and Windows 95. Pretty much that 
order.

----- MAB, Gaithersburg, Maryland, U.S.


--
Martin

From ???@??? Sat Aug 23 15:28:28 1997
Message-Id: <c=US%a=ATTMAIL%p=HOECHST%l=BRW-EXC-03-970822143044Z-9483@brw-exc-02.bridgewater.ne.hcc.com>
From: "Kennedy, John ,HiServ/NA" <JKENNEDY@himail.hcc.com>
To: "'z-machine'" <z-machine@gmd.de>
Subject: RE: [z-machine] Save-file format. and OS/2
Date: Fri, 22 Aug 1997 10:30:44 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 69 TEXT
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: f76170a3ce61ef4234ed44f5446ad683

I'm working on bringing JZIP to OS/2, and bringing it up to 1.0; about
all
that's left is to implement the Unicode opcodes  At this point I've made
enough changes that I suppose Quetzal could be done, too; I had already
half determined to give it a new designation (say, KZIP) because of all
the
changes I've made from the base JZIP.  I'll be supplying the source, of
course, so any experience ZIP hacker should be able to update the
non-OS/2 drivers to work at the same level.  (If anyone wants to do this
_before_ KZIP 1.0 is uploaded to ftp.gmd.de, please contact me now --
but I dare say everyone is happy with Frotz.)

I'm not sure what's going on with Frotz for OS/2.  If the current port
remains
as it is, I may tackle doing that, but I don't know the status of the
current
porter, and don't want to step on his toes.  (I also don't want to get
involved
with Version 6 in OS/2 full-screen mode.)  Unfortunately, WinFrotz is
written
using MFC, so I can't port it using Open32, and I really don't feel I
have
enough free time (it's not just a matter of hours, but of finding the
large
blocks of time necessary to do serious heads-down programming) to
create a PMFrotz from scratch.

Has anyone considered porting WinFrotz to Java 1.1?  Zplet is cute,
but it would be V6 support that would make the added overhead of
Java justifiable, seeing that every system capable of running Java
already seems to have native interpreters for V1-V5 and V8 anyway.
Java 1.1 would also make full implementation of Unicode fairly simple.

>----------
>From: 	Martin Frost[SMTP:mdf@doc.ic.ac.uk]
>Sent: 	Friday, August 22, 1997 6:40 AM
>To: 	z-machine@gmd.de
>Subject: 	[z-machine] Save-file format.
>
>This was posted in raif, and I was interested in whether anyone is actually
>doing anything with the Quetzal format (all appears to have gone quiet)..
>
>From: michael.baum@nist.gov (Michael Baum)
>Subject: Whatever happened to standard Z-machine save format?
>Date: 19 Aug 1997 20:13:14 GMT
>Organization: National Institute of Standards & Technology
>Lines: 15
>NNTP-Posting-Host: 129.6.176.38
>X-Newsreader: IBM NewsReader/2 2.0
>
>So I was just sitting around the conversation pit the other night 
>thinking what a nuisance it was that z-machine games saved on 
>one of my computers could not be run on another because I have to
>use different interpreters. By purest serendipity, while trying to do
>something else on the net I came across what would seem to be a
>standards doc from last March proposing a common save-file format,
>apparently named "Quetzal" (?????)
>
>Does anyone know the status of this? Has it been incorporated in any
>multi-platform z-machine interpreters? Specifically, I'm looking for
>interpreters for OS/2, MS-DOS, and Windows 95. Pretty much that 
>order.
>
>----- MAB, Gaithersburg, Maryland, U.S.
>
>
>--
>Martin
>

From ???@??? Sat Aug 23 15:28:30 1997
Date: Fri, 22 Aug 1997 13:16:00 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199708221716.NAA14844@pond.com>
To: z-machine@gmd.de
Subject: RE: [z-machine] Save-file format. and OS/2
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 8744feb0d53693481031b4093477f532

} Has anyone considered porting WinFrotz to Java 1.1?  Zplet is cute,
} but it would be V6 support that would make the added overhead of
} Java justifiable, seeing that every system capable of running Java
} already seems to have native interpreters for V1-V5 and V8 anyway.
} Java 1.1 would also make full implementation of Unicode fairly simple.

I believe the current ZPlet on my web page implements the Unicode
escapes properly... or at least close.  The problem I've found is that
the Java interpreters tend to have spotty support for Unicode,
particularly for input.  This seems to be true for both Windows and
Mac.  I believe we'll see improvement in that area soon, though.

Extending ZPlet to V6 is something I've wanted to do for a while, but
as I mentioned on the newsgroup, good weather has been pre-empting
interpreter programming.  ZPlet was mostly done in 3 rainy weekends (2
for basic support, the third for V5)

From ???@??? Sat Aug 23 15:28:31 1997
From: King Dale <KingD@rnd1.indy.tce.com>
To: "Matthew T. Russotto" <russotto@pond.com>
Cc: "z-machine@gmd.de" <z-machine@gmd.de>
Subject: RE: [z-machine] Save-file format. and OS/2
Date: Fri, 22 Aug 97 14:09:00 CST
Message-Id: <33FDF2DC@MSMAIL.INDY.TCE.COM>
Encoding: 49 TEXT
X-Mailer: Microsoft Mail V3.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: ac73da717b3f3efc890c9bbf5d20584a


I have written a Java based interpreter in Java 1.1 that runs V1-3   
(except the screen I/O is still rather simple and I never finished   
save/restore, which to fit in with another discussion was planned to use   
Quetzal). I began with the idea of porting Frotz (the source code to   
WinFrotz isn't publicly available as far as I know). I abandoned this   
idea because, like most implementations of the Z machine, Frotz isn't   
object-oriented and relies too much on global data. I had to invent a way   
to do the implementation in an object-oriented way. I actually found that   
the Z-Machine fit rather nicely into an object-oriented framework (Now   
that I think about it maybe I can use this Java Z-Machine as a project in   
my O-O analysis and design class this semester).

The problem is that implementing V6 games is a huge undertaking, one that   
even I hadn't planned to do. Not to mention, there aren't that many V6   
games to justify it. And as you said most machines already have a native   
interpreter.

I wish I had the time to finish my program off to distribute. It really   
is an elegant way to handle the various versions of interpreters using   
polymorphism. I tried to take the 1.1 version and make a 1.02 applet out   
of it on my Mac at home and discovered that the state of Java on the Mac   
in a word, stinks. I am supposed to get an NT machine at home soon, so   
maybe I can finish it in my spare time (whatever that is). Maybe if I use   
it in my O-O class I can get it done.

 ----------
From:  Matthew T. Russotto[SMTP:russotto@pond.com]
Sent:  Friday, August 22, 1997 12:16 PM
To:  z-machine@gmd.de
Subject:  RE: [z-machine] Save-file format. and OS/2

} Has anyone considered porting WinFrotz to Java 1.1?  Zplet is cute,
} but it would be V6 support that would make the added overhead of
} Java justifiable, seeing that every system capable of running Java
} already seems to have native interpreters for V1-V5 and V8 anyway.
} Java 1.1 would also make full implementation of Unicode fairly simple.

I believe the current ZPlet on my web page implements the Unicode
escapes properly... or at least close.  The problem I've found is that
the Java interpreters tend to have spotty support for Unicode,
particularly for input.  This seems to be true for both Windows and
Mac.  I believe we'll see improvement in that area soon, though.

Extending ZPlet to V6 is something I've wanted to do for a while, but
as I mentioned on the newsgroup, good weather has been pre-empting
interpreter programming.  ZPlet was mostly done in 3 rainy weekends (2
for basic support, the third for V5)


From ???@??? Sat Aug 23 22:18:42 1997
Date: Fri, 22 Aug 1997 21:57:44 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199708230157.VAA16391@pond.com>
To: KingD@rnd1.indy.tce.com
Subject: RE: [z-machine] Save-file format. and OS/2
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 28714d261c9a415f024310186c4d35d7
Status: U

} I wish I had the time to finish my program off to distribute. It really   
} is an elegant way to handle the various versions of interpreters using   
} polymorphism. I tried to take the 1.1 version and make a 1.02 applet out   
} of it on my Mac at home and discovered that the state of Java on the Mac   
} in a word, stinks. I am supposed to get an NT machine at home soon, so   
} maybe I can finish it in my spare time (whatever that is). Maybe if I use   
} it in my O-O class I can get it done.

Mac Java isn't in such a bad state -- there's actually two halfway-decent
interpreters (Apple's MRJ and CodeWarrior), and two Java-supporting
browsers which work pretty much OK -- at least, they seem to be just
as bad on Windows.  The Sun JDK is in a bad state, though -- if you
want Java programming on the Mac, Metrowerks Codewarrior 11 or later
is necessary.

From ???@??? Wed Aug 27 17:22:06 1997
Message-Id: <c=US%a=ATTMAIL%p=HOECHST%l=BRW-EXC-03-970825141705Z-18932@brw-exc-02.bridgewater.ne.hcc.com>
From: "Kennedy, John ,HiServ/NA" <JKENNEDY@himail.hcc.com>
To: "'z-machine'" <z-machine@gmd.de>
Subject: RE: [z-machine] Save-file format. and OS/2
Date: Mon, 25 Aug 1997 10:17:05 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 84 TEXT
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 6adc41878429684aabd511790a151798
Status: U

WinFrotz source is available (although a bit down-level, the last I
looked) from the WinFrotz homepage.

ZPlet displays, in its class structure, what is probably about all that
can be done with O-O in implementing
the Z machine; I suspect you have come to roughly the same conclusions.
My specific reference to
porting WinFrotz was more along the lines of a hope to see (for the most
part) a clone of the existing
WinFrotz screen and sound handling.  As I said before, every machine
that supports Java already has
a first-rate V1-5,8  interpreter (am I correct in my belief that V7 is
stillborn?), making Java a little
superfluous except for applet purposes, but, as you say, implementing V6
is very difficult, and there,
a good Java application containing all the features of WinFrotz, plus
1.0, Blorb and Quetzal, would be
a real contribution to the state of the art.

Especially since I suspect pressure for a V9 may soon arise.  A
hypothetical Inform V6 game would,
as I understand it, be limited to 320K, rather than the 576K of ZILCH
V6, and I'm working on a game
for which even V8's 512K is beginning to look dangerously small.  A
do-everything Java application
would considerably ease the introduction of any new versions.

>----------
>From: 	King Dale[SMTP:KingD@rnd1.indy.tce.com]
>Sent: 	Friday, August 22, 1997 4:09 PM
>To: 	Matthew T. Russotto
>Cc: 	z-machine@gmd.de
>Subject: 	RE: [z-machine] Save-file format. and OS/2
>
>
>I have written a Java based interpreter in Java 1.1 that runs V1-3 (except
>the screen I/O is still rather simple and I never finished save/restore,
>which to fit in with another discussion was planned to use Quetzal). I began
>with the idea of porting Frotz (the source code to WinFrotz isn't publicly
>available as far as I know). I abandoned this idea because, like most
>implementations of the Z machine, Frotz isn't object-oriented and relies too
>much on global data. I had to invent a way to do the implementation in an
>object-oriented way. I actually found that the Z-Machine fit rather nicely
>into an object-oriented framework (Now that I think about it maybe I can use
>this Java Z-Machine as a project in my O-O analysis and design class this
>semester).
>
>The problem is that implementing V6 games is a huge undertaking, one that
>even I hadn't planned to do. Not to mention, there aren't that many V6 games
>to justify it. And as you said most machines already have a native
>interpreter.
>
>I wish I had the time to finish my program off to distribute. It really is an
>elegant way to handle the various versions of interpreters using
>polymorphism. I tried to take the 1.1 version and make a 1.02 applet out of
>it on my Mac at home and discovered that the state of Java on the Mac in a
>word, stinks. I am supposed to get an NT machine at home soon, so maybe I can
>finish it in my spare time (whatever that is). Maybe if I use it in my O-O
>class I can get it done.
>
> ----------
>From:  Matthew T. Russotto[SMTP:russotto@pond.com]
>Sent:  Friday, August 22, 1997 12:16 PM
>To:  z-machine@gmd.de
>Subject:  RE: [z-machine] Save-file format. and OS/2
>
>} Has anyone considered porting WinFrotz to Java 1.1?  Zplet is cute,
>} but it would be V6 support that would make the added overhead of
>} Java justifiable, seeing that every system capable of running Java
>} already seems to have native interpreters for V1-V5 and V8 anyway.
>} Java 1.1 would also make full implementation of Unicode fairly simple.
>
>I believe the current ZPlet on my web page implements the Unicode
>escapes properly... or at least close.  The problem I've found is that
>the Java interpreters tend to have spotty support for Unicode,
>particularly for input.  This seems to be true for both Windows and
>Mac.  I believe we'll see improvement in that area soon, though.
>
>Extending ZPlet to V6 is something I've wanted to do for a while, but
>as I mentioned on the newsgroup, good weather has been pre-empting
>interpreter programming.  ZPlet was mostly done in 3 rainy weekends (2
>for basic support, the third for V5)
>
>

From ???@??? Wed Aug 27 17:22:11 1997
Date: Mon, 25 Aug 1997 10:56:57 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom18
To: Z-Machine List <z-machine@gmd.de>
Subject: RE: [z-machine] Save-file format. and OS/2
In-Reply-To: <3401CEE6@MSMAIL.INDY.TCE.COM>
Message-Id: <Pine.SUN.3.95.970825104821.18305A-100000@netcom18>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: c8ce52e7b03a58c530b50f31fff79c7a
Status: U

On Mon, 25 Aug 1997, King Dale wrote:

> One advantage I see to a good Java implementation is standardizing to one   
> interpreter that can run on any machine with a JVM.

Infocom, and now we, have gone to incredible amount of effort to make sure
that there *is* no advantage to standardizing on one interpreter. 

There are also GUI concerns; MaxZip, for example, is very much a Mac
program, and xzip is (to a lesser extent) an X windows program. The Java
GUI kit is not intended for that kind of platform-native behavior. 

The advantage of writing Z-machine interpreters in Java is (1) another
interpreter option on a given platform is always good, and (2) if a new
platform comes out which supports Java, you have an interpreter ready for
it. And (2b), I guess, if there was a V6 interpreter in Java then more
existing platforms would suddenly support V6. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Wed Aug 27 17:22:09 1997
From: King Dale <KingD@rnd1.indy.tce.com>
To: "'z-machine'" <z-machine@gmd.de>,
        "Kennedy, John ,HiServ/NA" <JKENNEDY@himail.hcc.com>
Subject: RE: [z-machine] Save-file format. and OS/2
Date: Mon, 25 Aug 97 12:24:00 CST
Message-Id: <3401CEE6@MSMAIL.INDY.TCE.COM>
Encoding: 133 TEXT
X-Mailer: Microsoft Mail V3.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 6f0d6a19128f22258b7326bd5c36f415
Status: U


The last I looked I only saw source code for frotz, not Winfrotz.

Actually I found Zplet a pretty poor conversion to O-O. <Looking at Zplet   
code again>. What I did was have several classes for different parts

Zmachine (the execution part)
Zmemory (the memory interface)
ZTextManager (conversion to/from Zscii, lies between the Zmachine and the   
memory)
ZObjectManager (object handling, lies between the Zmachine and the   
memory)
ZIOCard (I/O)
Zscreen (screen management)
Zstack (Execution stack)

One thing I do that really takes advantage of the O-O is that several of   
these are abstract classes. They then have subclasses for the individual   
versions. So instead of a bunch of exceptions within a class for   
variations in versions, it is simply a subclass that overrides the   
methods providing different functionality for the new version. So I have   
a V3Machine which is a subclass of the V1Machine and inherits all of its   
functionality and only adds what changes for V3.

One advantage I see to a good Java implementation is standardizing to one   
interpreter that can run on any machine with a JVM.

 ----------
From:  Kennedy, John ,HiServ/NA[SMTP:JKENNEDY@himail.hcc.com]
Sent:  Monday, August 25, 1997 9:17 AM
To:  'z-machine'
Subject:  RE: [z-machine] Save-file format. and OS/2

WinFrotz source is available (although a bit down-level, the last I
looked) from the WinFrotz homepage.

ZPlet displays, in its class structure, what is probably about all that
can be done with O-O in implementing
the Z machine; I suspect you have come to roughly the same conclusions.
My specific reference to
porting WinFrotz was more along the lines of a hope to see (for the most
part) a clone of the existing
WinFrotz screen and sound handling.  As I said before, every machine
that supports Java already has
a first-rate V1-5,8  interpreter (am I correct in my belief that V7 is
stillborn?), making Java a little
superfluous except for applet purposes, but, as you say, implementing V6
is very difficult, and there,
a good Java application containing all the features of WinFrotz, plus
1.0, Blorb and Quetzal, would be
a real contribution to the state of the art.

Especially since I suspect pressure for a V9 may soon arise.  A
hypothetical Inform V6 game would,
as I understand it, be limited to 320K, rather than the 576K of ZILCH
V6, and I'm working on a game
for which even V8's 512K is beginning to look dangerously small.  A
do-everything Java application
would considerably ease the introduction of any new versions.

>----------
>From:  King Dale[SMTP:KingD@rnd1.indy.tce.com]
>Sent:  Friday, August 22, 1997 4:09 PM
>To:  Matthew T. Russotto
>Cc:  z-machine@gmd.de
>Subject:  RE: [z-machine] Save-file format. and OS/2
>
>
>I have written a Java based interpreter in Java 1.1 that runs V1-3   
(except
>the screen I/O is still rather simple and I never finished save/restore,
>which to fit in with another discussion was planned to use Quetzal). I   
began
>with the idea of porting Frotz (the source code to WinFrotz isn't   
publicly
>available as far as I know). I abandoned this idea because, like most
>implementations of the Z machine, Frotz isn't object-oriented and relies   
too
>much on global data. I had to invent a way to do the implementation in   
an
>object-oriented way. I actually found that the Z-Machine fit rather   
nicely
>into an object-oriented framework (Now that I think about it maybe I can   
use
>this Java Z-Machine as a project in my O-O analysis and design class   
this
>semester).
>
>The problem is that implementing V6 games is a huge undertaking, one   
that
>even I hadn't planned to do. Not to mention, there aren't that many V6   
games
>to justify it. And as you said most machines already have a native
>interpreter.
>
>I wish I had the time to finish my program off to distribute. It really   
is an
>elegant way to handle the various versions of interpreters using
>polymorphism. I tried to take the 1.1 version and make a 1.02 applet out   
of
>it on my Mac at home and discovered that the state of Java on the Mac in   
a
>word, stinks. I am supposed to get an NT machine at home soon, so maybe   
I can
>finish it in my spare time (whatever that is). Maybe if I use it in my   
O-O
>class I can get it done.
>
> ----------
>From:  Matthew T. Russotto[SMTP:russotto@pond.com]
>Sent:  Friday, August 22, 1997 12:16 PM
>To:  z-machine@gmd.de
>Subject:  RE: [z-machine] Save-file format. and OS/2
>
>} Has anyone considered porting WinFrotz to Java 1.1?  Zplet is cute,
>} but it would be V6 support that would make the added overhead of
>} Java justifiable, seeing that every system capable of running Java
>} already seems to have native interpreters for V1-V5 and V8 anyway.
>} Java 1.1 would also make full implementation of Unicode fairly simple.
>
>I believe the current ZPlet on my web page implements the Unicode
>escapes properly... or at least close.  The problem I've found is that
>the Java interpreters tend to have spotty support for Unicode,
>particularly for input.  This seems to be true for both Windows and
>Mac.  I believe we'll see improvement in that area soon, though.
>
>Extending ZPlet to V6 is something I've wanted to do for a while, but
>as I mentioned on the newsgroup, good weather has been pre-empting
>interpreter programming.  ZPlet was mostly done in 3 rainy weekends (2
>for basic support, the third for V5)
>
>


From ???@??? Wed Aug 27 17:22:15 1997
From: Matt Kimmel <matt@javanet.com>
Message-Id: <199708260455.AAA10662@kona.javanet.com>
Subject: [z-machine] ANNOUNCE: Zax v0.9 - Java-based Z-Machine for V1-5,V7-8
To: z-machine@gmd.de
Date: Tue, 26 Aug 1997 00:55:24 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: d18625ad990dfabd1a3970f1d42f01e0
Status: U

(Crossposted from r.a.i-f, thought folks on the list would be interested)

Hi all,

After many months and lots of time conflicts, I've finally finished and
uploaded the first full release of Zax, my Java implementation of the
Z-Machine.  Zax conforms to Graham Nelson's Z-Machine specification v0.2
(v1.0 planned for the next release), and plays V1-V8 games (except for
V6).  It's fast and robust and runs all of the non-graphical Infocom games
except Beyond Zork, as well as all of the Inform games I've been able to
try with it.

Zax is written for Java 1.0.2, and should run on any Java 1.0.2 virtual
machine on any platform (I've tested it under Windows 95/NT and various
Unixes).  It may also run under Java 1.1, though I haven't tried it.  Zax
is a Java application, not an applet, so it won't run under
browsers--anyone interested in a Z-Machine applet should check out ZPlet.

I've uploaded Zax to the IF Archive at ftp.gmd.de.  Right now it can be
found at:
ftp://ftp.gmd.de/incoming/if-archive/zax-0.9.zip
It will probably be moved to /if-archive/infocom/interpreters soon.

-Matt
matt@javanet.com
No web page or fancy .sig as of yet....



From ???@??? Wed Aug 27 17:22:27 1997
From: Martin.Jerabek@siemens.at
X-Openmail-Hops: 1
Date: Tue, 26 Aug 97 09:29:42 +0200
Message-Id: <H000196c00759292@MHS>
Subject: [z-machine] Z assembler and linker
Mime-Version: 1.0
To: z-machine@gmd.de
Content-Disposition: inline; filename="Z"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII; name="Z"
X-UIDL: 414d91c0f822af7d874677cb8b711bc7
Status: U

Hello sailors! [1]

I just subscribed to this mailing list so please forgive me if I ask
something already discussed to death recently (is there an archive of
this list?).

During my futile attempt to port Inform 6.13 to 16-bit DOS, I thought
about the possibility of a stand-alone Z assembler and linker. What do
you Z experts think about it? Do you think that the existence of Inform
obviates the need for these tools? Any ideas for a standard for
assembler directives (mnemonics seem to be defined already well) and for
an object file format?

>From the four posts I received so far I gather that there is a 1.0
Z-machine specification. I looked just yesterday at GMD but no such
thing caught my eye. Where is it available from?

Any input is welcome!

Jerry

[1] Sorry for my attempt at humour; I'm pretty new to the Infocom world
and I find things funny which you old hands probably don't laugh about
any more. Smack me and I'll shut up. :-)

-- 
Martin "Jerry" Jerabek
mailto:martin.jerabek@siemens.at

From ???@??? Wed Aug 27 17:22:18 1997
Date: Tue, 26 Aug 1997 12:12:42 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Blorb: an open letter
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.26-0826111242-06cM+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-UIDL: 579f4cfb4b50b8b93b08d1eae7fd4c61
Status: U

[An open letter to Andrew Plotkin, who wrote up the "Blorb"
proposal for a much easier Version 6 image file format, which
can also accommodate sound samples.]

Dear Andrew,

  I write in connection with your new spell...
  
    blorb: ignore even cogent or much-needed proposal

...as it seems a pity that nobody has yet incorporated it into
the mainstream interpreters.  The proposal would make Version 6
games possible to write, and for myself I think that many authors
would like to be able to write basically textual games with the
occasional image appearing -- such images could serve as title
pages, or supplementary clues in the style of the old Infocom
box-lid booklets.  When rec.arts.int-fiction was polled, there
seemed to be plenty of interest.

  Our problem is that Blorb isn't yet in place because there are
no games to use it, and vice versa.  Perhaps we could ease this
log-jam by making a test file available to interpreter writers,
so that at least there's something to practice with.  What I
suggest is that someone should convert the Infocom-format picture
file for Zork Zero to a Blorb picture file.  (Rough translation
will be enough -- it doesn't much matter if the pictures are
mauled a bit in transfer, as long as they stay more or less the
same size.)  People will then be able to test out Blorb-compliance
on the combination

        Infocom's (DOS, say) "Zork Zero" story file
  and   the Blorb conversion of its pictures.

This would at least be a start.

  Would anyone volunteer to put together this Blorb file?  The
"Ztools" already contain a program to translate Infocom picture
files to GIFs, which should be most of the work.

     Graham

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Wed Aug 27 17:22:19 1997
Date: Tue, 26 Aug 1997 08:06:35 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom15
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Blorb: an open letter
In-Reply-To: <Marcel-1.26-0826111242-06cM+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.970826080052.16360C-100000@netcom15>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: fe3571e2432ea6cf4d8b224eaddfe021
Status: U

On Tue, 26 Aug 1997, Graham Nelson wrote:

> ...as it seems a pity that nobody has yet incorporated it into
> the mainstream interpreters. 

The mainstream V6 interpreter (hasnt pluralname), you mean...

>   Our problem is that Blorb isn't yet in place because there are
> no games to use it, and vice versa.  Perhaps we could ease this
> log-jam by making a test file available to interpreter writers,
> so that at least there's something to practice with.  What I
> suggest is that someone should convert the Infocom-format picture
> file for Zork Zero to a Blorb picture file. 

This is a perfectly reasonable idea, but I'm not sure if the spirit will
move me to do it very soon. I'll look into what software I'd need to
diddle with this stuff on my Mac.

A tiny little test file would also be good. One image, plus a Z-code file
which just draws the image and quits.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Wed Aug 27 17:22:20 1997
From: Jason C Penney <jpenney@cs.uml.edu>
Message-Id: <199708261530.LAA07363@jupiter.cs.uml.edu>
Subject: Re: [z-machine] Blorb: an open letter
To: erkyrath@netcom.com (Andrew Plotkin)
Date: Tue, 26 Aug 1997 11:30:05 -0400 (EDT)
Cc: z-machine@gmd.de
In-Reply-To: <Pine.SUN.3.95.970826080052.16360C-100000@netcom15> from "Andrew Plotkin" at Aug 26, 97 08:06:35 am
X-Mailer: ELM [version 2.4 PL25]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: a78d2053290f0939dd303bd98f243fff
Status: U

> >   Our problem is that Blorb isn't yet in place because there are
> > no games to use it, and vice versa.  Perhaps we could ease this
> > log-jam by making a test file available to interpreter writers,
> > so that at least there's something to practice with.  What I
> > suggest is that someone should convert the Infocom-format picture
> > file for Zork Zero to a Blorb picture file. 
> 
> This is a perfectly reasonable idea, but I'm not sure if the spirit will
> move me to do it very soon. I'll look into what software I'd need to
> diddle with this stuff on my Mac.
> 
> A tiny little test file would also be good. One image, plus a Z-code file
> which just draws the image and quits.
> 

	I have a v6 test file that uses the Zork 0 images and lets you
walk around a very boring area and it draws (and updates) the compass
rose.  It works in Frotz, and I have been using it to test my v6 class
library (which will not be finished by the end of the month as I had
hoped, but should be done some time soon).  

	If someone specs out what they want the test file to do and
supplies some blorbing tools I'd be able to get a test suite set up in
about a weeks time.

Jay

/*----------------------------------*--------------------------------*\
|Jason C. Penney(jpenney@cs.uml.edu)| http://www.cs.uml.edu/~jpenney/ |
| Xarton Dragon    --==<UDIC>==--   | (UFO 54-40, The Mathoms, Wipers)|
*-----------------------------------*---------------------------------*
|    "The trouble with computers of course, is that they're very      | 
|                sophisticated idiots." -- The Doctor                 |
\*----------------------------------*--------------------------------*/

From ???@??? Wed Aug 27 17:22:22 1997
Date: Tue, 26 Aug 1997 12:05:39 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Martin.Jerabek@siemens.at
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Z assembler and linker
In-Reply-To: <H000196c00759292@MHS>
Message-Id: <Pine.SGI.3.95.970826120342.24904H-100000@vangogh.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 5d5cb79e11b90499a6570c3284ac6d18
Status: U

>During my futile attempt to port Inform 6.13 to 16-bit DOS, I thought
>about the possibility of a stand-alone Z assembler and linker. What do

  Yesplease.  Just because C++ can do inline asm, that doesn't mean we
don't need assemblers...

>you Z experts think about it? Do you think that the existence of Inform
>obviates the need for these tools? Any ideas for a standard for
>assembler directives (mnemonics seem to be defined already well) and for
>an object file format?

  The object file format should be Inform's "module format" - it's just a
zcode file with some header stuff twiddled.  Portable, convenient, the
code already exists.

>>From the four posts I received so far I gather that there is a 1.0
>Z-machine specification. I looked just yesterday at GMD but no such
>thing caught my eye. Where is it available from?

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Wed Aug 27 17:22:23 1997
Date: Tue, 26 Aug 1997 12:10:53 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Graham Nelson <graham@gnelson.demon.co.uk>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Blorb: an open letter
In-Reply-To: <Marcel-1.26-0826111242-06cM+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SGI.3.95.970826121025.24904J-100000@vangogh.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 296308e12df7108f9acada3d9e21a843
Status: U

>  Our problem is that Blorb isn't yet in place because there are
>no games to use it, and vice versa.  Perhaps we could ease this
>log-jam by making a test file available to interpreter writers,

>This would at least be a start.

  Ah, yes, sounds good.

>  Would anyone volunteer to put together this Blorb file?  The
>"Ztools" already contain a program to translate Infocom picture
>files to GIFs, which should be most of the work.

  What about copyrights?

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Aug 30 11:05:28 1997
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: [z-machine] Flags 1, Bit 2, Version 3 and Flags 1, Bit 5, Version 6
Date: Tue, 26 Aug 1997 20:39:07 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <19970827085849.AAD1127@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: 8dd01ef6fc3f2bec7e586ad93f2806f3
Status: U


Hello,

  I think I discovered the meaning of bit #2 in the configuration
  byte at offset 1 in v3 games.  I believe it is set to indicate
  that a story file occupies more than one disk.  The smallest V3
  games, for instance, took only one Atari 800 disk; these games
  don't have this bit set.  The majority occupied two disks with
  the resident part stored on the first and the rest of the story
  file stored on the second disk; in this case the bit is always
  set.  PC versions never have this bit set, since the story file
  would always fit on one disk.
 
  I hope this information is added to the Spec and to the infodump
  utility.  Speaking of the Spec, is there hope to remove flags 1, 
  bit #5, Version 6: "Sound effects available"? I guess this comes
  from the original paper, but

  a) it's obsolete since flags 2, bit #7 already covers sound
  b) it's unreliable since Infocom's V6 Zip sets this bit [*]

  I suggest to leave this flag unspecified.

-- Stefan

  [*] Infocom's V6 interpreter did not support sound effects.


From ???@??? Wed Aug 27 17:22:29 1997
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.EDU.AU>
Message-Id: <199708262335.JAA02764@yallara.cs.rmit.EDU.AU>
Subject: Re: [z-machine] Z assembler and linker
To: z-machine@gmd.de
Date: Wed, 27 Aug 1997 09:35:14 +1000 (EST)
In-Reply-To: <H000196c00759292@MHS> from "Martin.Jerabek@siemens.at" at Aug 26, 97 09:29:42 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: a4613f02db1279988c1cceb90f07da84
Status: U

> 
> Hello sailors! [1]
> 
> I just subscribed to this mailing list so please forgive me if I ask
> something already discussed to death recently (is there an archive of
> this list?).
> 
> During my futile attempt to port Inform 6.13 to 16-bit DOS, I thought
> about the possibility of a stand-alone Z assembler and linker. What do
> you Z experts think about it? Do you think that the existence of Inform
> obviates the need for these tools? Any ideas for a standard for
> assembler directives (mnemonics seem to be defined already well) and for
> an object file format?
> 
> >From the four posts I received so far I gather that there is a 1.0
> Z-machine specification. I looked just yesterday at GMD but no such
> thing caught my eye. Where is it available from?
> 
> Any input is welcome!
> 
> Jerry
> 
> [1] Sorry for my attempt at humour; I'm pretty new to the Infocom world
> and I find things funny which you old hands probably don't laugh about
> any more. Smack me and I'll shut up. :-)
> 
> -- 
> Martin "Jerry" Jerabek
> mailto:martin.jerabek@siemens.at
> 

I think that would a useful addition to the Inform world. Just because Inform
can handle Inline asm, is no reason why there can't be a separate tool. Take
Borland C++, for example. It has a full inline assembler (BASM), but still
includes a separate assembler (TASM), which which you can do a lot more, such
as having assembly macros, finely control code generation, etc. 

An assembler for Inform which had all this would certainly be a good project.

-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Sat Aug 30 11:05:21 1997
Message-Id: <3.0.32.19970827173616.0079fe00@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 27 Aug 1997 17:38:46 +1200
To: "A.K.A. TheWiz" <dankna@bergen.org>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Blorb: an open letter
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset="us-ascii"
X-UIDL: 5f2e927de206fb88c447a6464bab2c20
Status: U

At 12:10 26/08/97 -0400, you wrote:
>>  Would anyone volunteer to put together this Blorb file?  The
>>"Ztools" already contain a program to translate Infocom picture
>>files to GIFs, which should be most of the work.
>
>  What about copyrights?

Simple solution:  use pix2gif to convert into a GIF format and gif2png (or
whatever the tool is called) to convert the GIF file into a PNG file, which
I think everybody has agreed would be the best to use for V6 graphics.

That way, the GIF file is just an intermediate step and not being
distributed; copyrights shouldn't be a problem then.

Kick me if I stupid.  :-)


-----                                
     _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
    _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
   _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
  _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/

Gavin Lambert
uecasm@geocities.com
http://crash.ihug.co.nz/~brianc
http://ue.home.ml.org/

"We now return to our regularly scheduled flame-throwing."
"PCMCIA:  People Can't Memorise Computer Industry Acronyms."
"ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."


From ???@??? Sat Aug 30 11:05:23 1997
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.EDU.AU>
Message-Id: <199708270716.RAA08493@yallara.cs.rmit.EDU.AU>
Subject: Re: [z-machine] Blorb: an open letter
To: z-machine@gmd.de
Date: Wed, 27 Aug 1997 17:16:10 +1000 (EST)
In-Reply-To: <3.0.32.19970827173616.0079fe00@pop.ihug.co.nz> from "Gavin Lambert" at Aug 27, 97 05:38:46 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain; charset=US-ASCII
X-UIDL: 9f97b3005b28c4c6a33e3c92806d0882
Status: U

> 
> At 12:10 26/08/97 -0400, you wrote:
> >>  Would anyone volunteer to put together this Blorb file?  The
> >>"Ztools" already contain a program to translate Infocom picture
> >>files to GIFs, which should be most of the work.
> >
> >  What about copyrights?
> 
> Simple solution:  use pix2gif to convert into a GIF format and gif2png (or
> whatever the tool is called) to convert the GIF file into a PNG file, which
> I think everybody has agreed would be the best to use for V6 graphics.
> 
> That way, the GIF file is just an intermediate step and not being
> distributed; copyrights shouldn't be a problem then.
> 
> Kick me if I stupid.  :-)
> 

I think the question of copyright was not so much as the copyright problems
associated with GIF, but the legalities of making a test file generally
available which has pictures of a copyrighted work in it (ie. the Zork 0
pictures).

As whether there will be a problem. I doubt it. Activision recognises the
IF forum as a major audience for it's IF products / re-releases, and I doubt
they'd mind a test file containing some of the Zork 0 art to exist. If they
did object, it could always be held by someone, and distributed to people
after prechecking that they own a version of Zork 0 already, perhaps.



> 
> -----                                
>      _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
>     _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
>    _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
>   _/    _/  _/        _/        _/    _/        _/  _/        _/
>  _/    _/  _/        _/        _/    _/        _/  _/        _/
>  _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/
> 
> Gavin Lambert
> uecasm@geocities.com
> http://crash.ihug.co.nz/~brianc
> http://ue.home.ml.org/
> 
> "We now return to our regularly scheduled flame-throwing."
> "PCMCIA:  People Can't Memorise Computer Industry Acronyms."
> "ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."
> 
> 


-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Sat Aug 30 11:05:25 1997
Date: Wed, 27 Aug 1997 00:42:02 -0700 (PDT)
From: Patrick Kellum <patrick@syix.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Blorb: an open letter
In-Reply-To: <199708270716.RAA08493@yallara.cs.rmit.EDU.AU>
Message-Id: <Pine.BSI.3.95.970827003738.17677A-100000@ns1.syix.com>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 21935e39d7153873b44f6b862499dd03
Status: U

On Wed, 27 Aug 1997, Paul Francis Gilbert wrote:

> I think the question of copyright was not so much as the copyright problems
> associated with GIF, but the legalities of making a test file generally
> available which has pictures of a copyrighted work in it (ie. the Zork 0
> pictures).

Well, if the test file contained a notice stating that the graphics were
copyrighted by Activision and perhaps information on how to contact them
then I doubt they would mind and it would be free advertising :-)  But to
be safe, it might be best to ask them first.  

Although, why bother using the Zork graphics, it's a test game it doesn't
have to be pretty, it would be easer to just draw up a few rough images
for the game.  I'll admit I was tempted to use the Dungeon Master
graphics, but I feared a lawsuit :-)

Patrick
---

"Pity there are no Martians to witness the spectacle of a kind of 15-foot
 beach ball suddenly falling out of the sky and bouncing all about."

   - Description of the Mars Pathfinder landing on Mars.
     From a New York Times News Service story by John Noble Wilford


From ???@??? Sat Aug 30 11:05:29 1997
Message-Id: <199708271037.MAA21889@dns.speednet.it>
From: "Giovanni Riccardi" <g.riccardi@speednet.it>
To: "Z-Machine" <z-machine@gmd.de>
Subject: [z-machine] Infix: an open letter
Date: Wed, 27 Aug 1997 12:41:14 +0200
Mime-Version: 1.0
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1008.3
X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.1008.3

X-Mime-Autoconverted: from 8bit to quoted-printable by dns.speednet.it id MAA21889
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text/plain;
	charset="x-user-defined"
X-UIDL: a8e0580282536f740a91e2e3c16eab67
Status: U

[An open letter to the Infix Group, who wrote up
a proposal for an Inform source-level debugger.]

Dear friends,

I know that something have brought your mind far away the Infix project,
this letter has been written to revive discussions.
Actually I've produced 4 newsletters. If someone lost some of those I'll
post them privately.

To finish...

THE INFIX GROUP
---------------

1. John Wood <john@elvw.demon.co.uk>
   Self-appointed Grand Nabob.
   Design work & documentation, some generic code, can work on
   DOS/Windows versions, likes C++ but happy with C.

2. Giovanni Riccardi <g.riccardi@speednet.it>
   Group Secretary and Gopher.
   Newsletter & documentation, editing and organising ideas,
   arbiter of non-technical disputes.

3. Graham Nelson <graham@gnelson.demon.co.uk>
   Compiler Supporter and Patron Saint.
   Providing debug output from Inform.

4. Matthew T. Russotto <russotto@pond.com>
   Macintosh programmer, prefer C++ without the STL, can deal with C
   Could probably adapt the txd disassembler for use with Infix.

5. Martin Frost <mdf@doc.ic.ac.uk>
   Amiga programmer, no C++ compiler (only C). Have other projects but
   could do an Amiga port.

6. Stephen Van Egmond <svanegmo@undergrad.math.uwaterloo.ca>
   Amiga Programmer. Preferred language is C (although he can do C++
   equally well, thinks C is a better choice for this project).



P.S. Sorry Graham for this plagiarised letter


         `'´
        (. .)
---oOO-- (_) --OOo------------------------------------
                            "How do you know I'm mad?"
                            said Alice. "You must be,"
  Giovanni  Riccardi        said the Cat "or you
g.riccardi@speednet.it      wouldn't have come here."
   Terracina  Italy
                            - L. Carrol "Alice's
                             Adventures in Wonderland"

Visit P.O.V. Online, a place for your stories & poems:
http://www.geocities.com/Athens/Delphi/8758/index.html
------------------------------------------------------



From ???@??? Sat Aug 30 11:05:31 1997
Date: Wed, 27 Aug 1997 09:18:12 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199708271318.JAA04584@pond.com>
To: z-machine@gmd.de
Subject: Re:  [z-machine] Flags 1, Bit 2, Version 3 and Flags 1, Bit 5, Version 6
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: b27a3a33c14536060d15824ed7c0f1c4
Status: U

}   I think I discovered the meaning of bit #2 in the configuration
}   byte at offset 1 in v3 games.  I believe it is set to indicate
}   that a story file occupies more than one disk.  The smallest V3

I think you may have it.  The Apple II games don't have this bit set,
even in versions identical to the Atari versions.  Furthermore,
the Apple II V4 games Trinity and Bureaucracy DO have it set.

From ???@??? Sat Aug 30 11:05:33 1997
Date: Wed, 27 Aug 1997 09:41:01 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Gavin Lambert <uecasm@geocities.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Blorb: an open letter
In-Reply-To: <3.0.32.19970827173616.0079fe00@pop.ihug.co.nz>
Message-Id: <Pine.SGI.3.95.970827093926.28309B-100000@vangogh.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: f82a5d40b892698c3ba9ab94937a6d51
Status: U

>>  What about copyrights?
>
>Simple solution:  use pix2gif to convert into a GIF format and gif2png (or
>whatever the tool is called) to convert the GIF file into a PNG file, which
>I think everybody has agreed would be the best to use for V6 graphics.

  Uh, you're allowed to have a GIF file (assuming the author(s) of pix2gif
and gif2png got proper licensing).  I meant Infocom's (Activision's)
copyright on the actual picture... you know, the reason I can't just have
someone give me all those old games I haven't played.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Sat Aug 30 11:05:35 1997
Date: Wed, 27 Aug 1997 10:11:05 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199708271411.KAA07983@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Blorb: an open letter
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 82150e39e0dfcb8a6a725da22bf6728f
Status: U

}   Uh, you're allowed to have a GIF file (assuming the author(s) of pix2gif
} and gif2png got proper licensing).  I meant Infocom's (Activision's)
} copyright on the actual picture... you know, the reason I can't just have
} someone give me all those old games I haven't played.

If it wasn't an issue when the perfectly usable MCGA file was posted
on gmd (it's still there, too, along with other copyrighted bits such
as Sherlock's sound), it shouldn't be an issue for a test file.

From ???@??? Sat Aug 30 11:05:36 1997
Date: Wed, 27 Aug 1997 10:21:17 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: "Matthew T. Russotto" <russotto@pond.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Blorb: an open letter
In-Reply-To: <199708271411.KAA07983@pond.com>
Message-Id: <Pine.SGI.3.95.970827102043.27868G-100000@vangogh.bergen.org>
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 622eb19f9d82d5e5eefcc6c515c9f09d
Status: U

>If it wasn't an issue when the perfectly usable MCGA file was posted
>on gmd (it's still there, too, along with other copyrighted bits such
>as Sherlock's sound), it shouldn't be an issue for a test file.

  Good, I nead Trinity, Bureaucracy, ... :-)  (Nobody actually send me
these as I don't wish to be tempted)
____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------


From ???@??? Thu Sep 04 19:12:11 1997
To: z-machine@gmd.de
Subject: [z-machine] Quetzal patches for Zip
Message-Id: <E0x6GZH-0002LF-00@machinecop.doc.ic.ac.uk>
From: Martin Frost <mdf@doc.ic.ac.uk>
Date: Wed, 3 Sep 1997 15:38:03 +0100
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 645566b4eabec04217112c38638f01dd

As promised, the long-awaited patches for Zip to support the Quetzal format
have finally been made available.

These are patches on the original UNIX/Amiga/VMS/MS-DOS version, but the
changes should be applicable to any version.

They can be downloaded from

	http://www.geocities.com/SiliconValley/Vista/6631/zip-quetzal.html

I have also collected together some example Quetzal files and a utility to
check the sanity of generated ones; this can be got from

	http://www.geocities.com/SiliconValley/Vista/6631/test-quetzal.html

Hopefully these will be useful, and can speed the adoption of the Quetzal
format--mail me if there are any problems with them.

Martin

From ???@??? Thu Sep 04 19:12:12 1997
To: z-machine@gmd.de
Subject: [z-machine] New version of Quetzal format
Message-Id: <E0x6JkQ-0002NA-00@machinecop.doc.ic.ac.uk>
From: Martin Frost <mdf@doc.ic.ac.uk>
Date: Wed, 3 Sep 1997 19:01:46 +0100
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
Content-Type: text
X-UIDL: 53c02fee4c94cc3dc653fee54ca6d19f

Along with all the stuff now available on my web page, I have released a new
version of the Quetzal spec, incorporating the MacOS chunk definition and
various corrections and clarifications.

It can be obtained from

	http://www.geocities.com/SiliconValley/Vista/6631/

and should be available at

	/if-archive/infocom/interpreters/specification/savefile_13.txt

in a few days' time.

Hopefully there are no errors (no-one noticed the ones there were).

Martin

From ???@??? Tue Sep 09 20:34:05 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 08 Sep 1997 15:15:53 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] "Blorb" sound format: opinions?
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.26-0908141553-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c1a97620e150c932659b115ca7deb68a

Kevin Bracey, who's beginning work on implementing "Blorb" for his
Acorn RISC OS interpreter Zip2000, comments that the "Blorb" standard
does not currently specify a sound format.

Would it be appropriate to discuss this now?

I have just read the latest version I can find of the audio-formats
FAQ, which although pretty old (mid 1994) suggested to me that:

(i)   All sound formats are basically similar _except_ in their
      usage of compression techniques;
(ii)  Almost all formats were devised for one specific computer;
(iii) Programs to convert one format to another are widely
      available;
(iv)  But since almost every format may employ a wide variety
      of different compression algorithms, it's seldom absolutely
      possible to claim that any given player-program can always
      play any sound expressed in that format.

For the Z-machine, I suggest that we don't need to have any worries
about the compression techniques being potentially lossy, and that
the main aim should simply be to pick the easiest format for people
to use in practice -- i.e., the format most understood by utility
programs on a range of operating systems and computers.  

I suggest WAV.  It may have originated with Microsoft and IBM,
but then the devil is supposed to have all the best tunes.  It's
reasonably old, which is an advantage since it means that utility
programs on non-IBM machines have caught up with it: and it seems
to be the most popular format for archiving sounds on the Internet,
at least according to my cursory survey.  (RealTime Audio is
newer but unplayable on some machines as yet.)

["Blorb" is an agreed but largely still unimplemented format for
conveniently grouping subsidiary resource files, such as graphics
and sound effects, to Z-machine games.  The hope is that it will
make it practicable for today's designers to make use, modest or
extravagant as they prefer, of the Z-machine technology invented
by Infocom for sound and images.]

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Tue Sep 09 20:34:15 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <3414A128.79EBDE78@micron.net>
Date: Mon, 08 Sep 1997 19:06:49 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.01b6C [en] (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: z-machine@gmd.de
Subject: Re: [z-machine] "Blorb" sound format: opinions?
X-Priority: 3 (Normal)
References: <Marcel-1.26-0908141553-0b0M+4%@gnelson.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 731b9f79ad91238618711f48309a979d

Graham Nelson wrote:

> I suggest WAV.  It may have originated with Microsoft and IBM,
> but then the devil is supposed to have all the best tunes.  It's
> reasonably old, which is an advantage since it means that utility
> programs on non-IBM machines have caught up with it: and it seems
> to be the most popular format for archiving sounds on the Internet,
> at least according to my cursory survey.  (RealTime Audio is
> newer but unplayable on some machines as yet.)

WAV is fine, it's pretty well documented and understood.  My only
comment is that it should be strongly suggested (rather than mandated)
that audio be stored as straight PCM samples.  WAV's can hold audio
compressed a number of ways, but many of those ways are proprietary.

For those who want _really_ compressed audio, we could offer optional
support for mp3.  I have no idea who would want to use it, but we could.

--Galen


From ???@??? Wed Sep 17 22:04:13 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <3.0.32.19970909205209.007d4bf0@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 09 Sep 1997 20:54:16 +1200
To: Graham Nelson <graham@gnelson.demon.co.uk>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] "Blorb" sound format: opinions?
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 57fbc64289dfc017829d676702eb1e8b
Status: U

At 15:15 08/09/97 +0100, you wrote:
>Kevin Bracey, who's beginning work on implementing "Blorb" for his
>Acorn RISC OS interpreter Zip2000, comments that the "Blorb" standard
>does not currently specify a sound format.
[...]
>I suggest WAV.  It may have originated with Microsoft and IBM,

Yes, I think WAV is a good choice.  Something else that I thought I heard
mentioned earlier that might not be a bad idea is support for some kind of
music file, as background or something.  These files could be given
@sound_effect numbers just like the sampled sound files.

For music files (if such a thing is deemed a good idea) I would be inclined
to go with either MIDI or MOD formats; there are advantages and
disadvantages to both.

I think this discussion was posted in greater detail earlier, so I'll be
brief:
 - MIDI is a single format, while MOD has many flavours
 - MOD is widely supported across different platforms
 - MOD contains its own samples, unlike MIDI which relies on the samples
provided by the system.

Taking all that into account, probably a MOD file would be the best way to
go (S3M format perhaps?), unless anyone else has another idea....?

-----                                
     _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
    _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
   _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
  _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/

Gavin Lambert
uecasm@geocities.com
http://crash.ihug.co.nz/~brianc
http://ue.home.ml.org/

"We now return to our regularly scheduled flame-throwing."
"PCMCIA:  People Can't Memorise Computer Industry Acronyms."
"ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."

From ???@??? Wed Sep 17 22:04:09 1997
Return-Path: mdf@doc.ic.ac.uk
Message-Id: <m0x8NMJ-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Tue, 9 Sep 1997 11:17:23 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] "Blorb" sound format: opinions?
Cc: z-machine@gmd.de
X-UIDL: 502519b6ec44765d506b971333649d26
Status: U

>>I suggest WAV.  It may have originated with Microsoft and IBM,

>Yes, I think WAV is a good choice.

WAV is a very big, complicated, proprietary format. Although it is used
mainly to store 8- and 16-bit PCM data it must support many other types.
It also suffers from a lack of easily-available official documentation
(last time I looked, Micro$oft wanted something like $50 for the complete
description), so the only real documentation is based on various peoples'
reverse-engineering efforts, or cut-down descriptions from the main version.

It is also not as common as might be thought from looking at the PC world
(including all the computers that now keep trying to promote themselves as
more PC-like than PCs). Good software to convert to and from it is sadly
lacking on many platforms--I have yet to see a reliable converter in both
directions for any flavour of UNIX, Amigas, or Atari STs (and I haven't tried
for many other platforms).

As might be expected from the above diatribe, my vote goes against WAV.
Instead, I suggest something like AIFF, which is simpler and was designed
to handle the different variations on PCM (basically different numbers of
samples/second and bits/sample) in a consistent way (since they are fairly
easy to convert between once the parameters are known). A copy of the official
standard is available on the Web:

	http://www.mediatel.lu/workshop/audio/fileformat/aiff13/h_aiff13.html

AIFF only supports PCM; as this is the most common encoding and others tend
to be hardware-specific I believe this is a worthwhile limitation. AIFF is
well-supported by many sound-processing packages (it is one of the few
formats saved by Akai samplers, for example).

What do other people think?

Martin

From ???@??? Wed Sep 17 22:04:15 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 9 Sep 1997 13:40:36 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199709091740.NAA02742@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] "Blorb" sound format: opinions?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: dba25c57a953e5a9364ca1336a5fa271
Status: U

} AIFF only supports PCM; as this is the most common encoding and others tend
} to be hardware-specific I believe this is a worthwhile limitation. AIFF is
} well-supported by many sound-processing packages (it is one of the few
} formats saved by Akai samplers, for example).

} What do other people think?

I think I've mentioned before that I support AIFF for purely selfish
reasons -- it's supported by library calls on the Mac.

From ???@??? Wed Sep 17 22:04:16 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <34158A3D.A5D1DE5A@micron.net>
Date: Tue, 09 Sep 1997 11:41:18 -0600
From: Galen Hazelwood <galenh@micron.net>
X-Mailer: Mozilla 4.01b6C [en] (X11; I; Linux 2.0.30 i586)
Mime-Version: 1.0
To: z-machine@gmd.de
Subject: Re: [z-machine] "Blorb" sound format: opinions?
X-Priority: 3 (Normal)
References: <m0x8NMJ-000FayC@kea.doc.ic.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e34c6dc3d26c925bc4bab4fe53b6ed68
Status: U

Martin Frost wrote:

> AIFF only supports PCM; as this is the most common encoding and others
> tend
> to be hardware-specific I believe this is a worthwhile limitation.
> AIFF is
> well-supported by many sound-processing packages (it is one of the few
>
> formats saved by Akai samplers, for example).

Is that so?  I never had any experience with AIFF; I had assumed it was
like "WAV++", with lots of different encoding/compression options.  If
it only supports PCM, it might be a better choice.  I can't think of any
sound-capable hardware which can't handle PCM.

I can live with whatever is chosen, as long as I can get tools to
convert it with on linux.

--Galen


From ???@??? Wed Sep 17 22:04:30 1997
Return-Path: owner-z-machine@mail2.gmd.de
To: z-machine@gmd.de
Subject: [z-machine] IMPORTANT: Bug in Quetzal patches.
Message-Id: <E0x96V0-00052N-00@machinecop.doc.ic.ac.uk>
From: Martin Frost <mdf@doc.ic.ac.uk>
Date: Thu, 11 Sep 1997 11:29:22 +0100
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a0a0033de82124139ed58971f1108de1
Status: U

It has been brought to my attention that there is a bug in the quetzal.c file
that forms the majority of the patches to use Quetzal on Zip.

The bug takes the form of a missing line of code (when it disappeared I do
not know).

To fix this bug, simply find lines 117-120. They will look like this:

    /* frames is a list of FPs, most recent first */
    frames[0] = sp-5;   /* what FP would be if we did a call now */
    for(init_fp=fp, n=0; init_fp <= STACK_SIZE-5; init_fp=stack[init_fp+2])
    init_fp = frames[n] + 4;

The bug is that line 120 is missing. To fix the bug, simply insert the line,
so that the code looks like:

    /* frames is a list of FPs, most recent first */
    frames[0] = sp-5;   /* what FP would be if we did a call now */
    for(init_fp=fp, n=0; init_fp <= STACK_SIZE-5; init_fp=stack[init_fp+2])
        frames[++n] = init_fp;
    init_fp = frames[n] + 4;

Thanks to John Kennedy <JKENNEDY@himail.hcc.com> for pointing this out.

My apologies for any inconvenience this may have caused.

Martin

From ???@??? Wed Sep 17 22:04:38 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 11 Sep 1997 22:23:25 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom6
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] ZIP bug
Message-Id: <Pine.SUN.3.95.970911220253.29435B-100000@netcom6>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: fac984b22153fcf12e267e9d6790dace
Status: U

While updating MaxZip, I came across some places where the original ZIP
source behaves wrong. Other ZIP derivatives may wish to take note. I don't
have patch files but I can describe what to do, I think.

A bunch of header data is supposed to be set when the game is started,
restarted, or restored. ZIP fails to do this after restoring.

Look in control.c, in the restart() procedure. There is a clot of code
commented "Restart the interpreter state"; it sets the scripting flag, the
screen width and heigh fields in the header, and (in V1-3) clears the
status line.

This code should be chopped out into a separate procedure. I have it like
this:

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

/*
 * restart_interp
 *
 * Do all the things which need to be done after startup, restart, and
 * restore commands.
 *
 */

#ifdef __STDC__
void restart_interp (int scripting_flag)
#else
void restart_interp ()
#endif
{
    if (scripting_flag)
        set_word (H_FLAGS, (get_word (H_FLAGS) | SCRIPTING_FLAG));

    set_byte (H_INTERPRETER, h_interpreter);
    set_byte (H_INTERPRETER_VERSION, h_interpreter_version);
    set_byte (H_SCREEN_ROWS, screen_rows); /* Screen dimension in 
characters */
    set_byte (H_SCREEN_COLUMNS, screen_cols);

    set_byte (H_SCREEN_LEFT, 0); /* Screen dimension in smallest
addressable units, ie. pixels */
    set_byte (H_SCREEN_RIGHT, screen_cols);
    set_byte (H_SCREEN_TOP, 0);
    set_byte (H_SCREEN_BOTTOM, screen_rows);

    set_byte (H_MAX_CHAR_WIDTH, 1); /* Size of a character in screen units
*/
    set_byte (H_MAX_CHAR_HEIGHT, 1);

    /* Initialise status region */

    if (h_type < V4) {
        set_status_size (0);
        blank_status_line ();
    }

}/* restart_interp */

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

You can then call restart_interp(scripting_flag) from the restart()
procedure, in place of the code you just chopped out.

Then, at the end of save_restore(), change this:

----------------
    /* Close the save file and restore scripting */

    if (flag == GAME_SAVE || flag == GAME_RESTORE) {
        // close file
        if (scripting_flag)
            set_word (H_FLAGS, get_word (H_FLAGS) | SCRIPTING_FLAG);
    }
---------------
to this:
---------------
    /* Close the save file and restore scripting */

    if (flag == GAME_SAVE) {
        // close file
        if (scripting_flag)
            set_word (H_FLAGS, get_word (H_FLAGS) | SCRIPTING_FLAG);
    }
    else if (flag == GAME_RESTORE) {
        // close file
        restart_screen();
        restart_interp(scripting_flag);
    }
----------------

(The "close file" command is fclose() in the original, I guess; I've
changed it to Mac file calls in my source.)

Once this is done, you can remove the set_status_size/blank_status_line
calls from restore(); they have become redundant. 

What good does this do? Well, try running a game with a complicated status
line. Save your game; quit and restart the interpreter with a different
window size; and reload the game. In ZIP, the status line becomes
confused, because the old window size gets loaded in with the saved-game
data. With the above changes, no confusion.

This is particularly noticeable with Martin Frost's Quetzal save examples
(this is of course how I noticed it.) His three sample save files (for
Jigsaw) have different screen widths. When I restored them sequentially,
the status line got messed up. I spent quite a while trying to figure out
what was wrong with his quetzal.c, before I realized that the bug had been
in ZIP all along.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Wed Sep 17 22:04:41 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 12 Sep 1997 09:17:29 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] "Blorb" sound format again
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.26-0912081729-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 880ac83d37756f5acb9929579b3708f9
Status: U


Well, so far we have had two suggestions for a common sound format:

   WAV    A Microsoft/IBM creation, widely used on the Internet
          but with enough variety in possible encoding methods
          that it may possibly cause trouble;

   AIFF   An Apple II format which, though now very old (AIFF 1.3
          dates from the mid 1980s some time) is simple and
          easily defined, and I don't think it restricts the range
          of (e.g.) possible sound sample resolutions.

Do I hear any votes either way?

If AIFF really is simple and widely accessible, then I'm drawn to
it!  As I said in my previous post, I think our criteria ought to
be to go for the easiest format all round (rather than necessarily
the technically "best").  Would anyone who has experience offer
a comparison?  Are AIFF files of the same sample much larger than
typical WAVs, for instance?

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Wed Sep 17 22:04:42 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <c=US%a=ATTMAIL%p=HOECHST%l=BRW-EXC-03-970912133845Z-87632@brw-exc-02.bridgewater.ne.hcc.com>
From: "Kennedy, John ,HiServ/NA" <JKENNEDY@himail.hcc.com>
To: "'z-machine'" <z-machine@gmd.de>
Subject: RE: [z-machine] "Blorb" sound format again
Date: Fri, 12 Sep 1997 09:38:45 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 25 TEXT
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3881977a3bb73f9f89b19d11118ec4fa
Status: U

Both AIFF and WAV are planned for Java.  (Present support is for only
Sun AU, but that's only in applets [Java programs embedded in web
pages],
not applications [full-function Java programs] in the first place, a
unique
instance in which applets have more support than applications, rather
than less.)  I do think it important to make sure that Blorb is not
defined
in such a way as to make a portable interpreter written in Java
impossible,
so I'd say that anything other than AU, AIFF and WAV should be excluded
out of hand, and I gather AU is a non-starter.

I believe that relying on any "standard" controlled by Microsoft is a
_big_
mistake.  Microsoft "standards" are invariably confusing, ill-defined,
and
in constant flux.  On the other hand, I know _nothing_ of multimedia
programming, so the obvious question arises, what environments (that
support sampled sound in the first place) support AIFF and WAV,
respectively?  I dare say all modern environments will soon suport both,
for the sake of supporting Java, but what of the rest?


>

From ???@??? Wed Sep 17 22:04:44 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 12 Sep 1997 08:47:03 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom8
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <Marcel-1.26-0912081729-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.970912083413.16579A-100000@netcom8>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e9dd480fc486fa634f8ea361fab68ebc
Status: U

On Fri, 12 Sep 1997, Graham Nelson wrote:

> If AIFF really is simple and widely accessible, then I'm drawn to
> it! 

Ditto. (And I generally assume that the devil can't play tunes worth
crap.) 

It looks like both WAV and AIFF support various compression mechanisms. At
least, the converter I just tried asked me whether I was converting to
AIFF with PCM, AIFF with mu-law, WAV with PCM, WAV with mu-law... etc. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Sep 17 22:05:06 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 15 Sep 1997 11:33:00 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Converting Amiga-format Infocom games
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <341C7336.3401@wolf-uk.com>
Message-Id: <Marcel-1.26-0915103300-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3b3916b5cd092de238971bc485f9e320
Status: U


Can anyone help Mr Wolf?  I'd be grateful if someone could email
him at simon@wolf-uk.com if so.

   G.

On Mon 15 Sep, Simon Wolf wrote:
> Hi.  I have The Lost Treasures of Infocom for my old Amiga and would
> like to play the games on either my PC or Psion.  The only problem I
> have is that I have no idea how to convert the Amiga's data files to the
> Z format!  Each of the Infocom games seems to be a separate executable
> file with a data file.  Any ideas would be greatly appreciated.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Wed Sep 17 22:05:08 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 15 Sep 1997 14:01:05 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] "Blorb" sound format again
To: Z-Machine Mailing List <z-machine@gmd.de>,
        Kevin Bracey <kbracey@acorn.co.uk>
In-Reply-To: <Pine.SUN.3.95.970912083413.16579A-100000@netcom8>
Message-Id: <Marcel-1.26-0915130105-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f8fd5fafcd360781514b4d0250253929
Status: U

On Fri 12 Sep, Andrew Plotkin wrote:
> 
> It looks like both WAV and AIFF support various compression mechanisms. At
> least, the converter I just tried asked me whether I was converting to
> AIFF with PCM, AIFF with mu-law, WAV with PCM, WAV with mu-law... etc. 

Nobody has spoken out against AIFF, and it increasingly sounds
like a good idea.  Unless anyone has any objections, shall we
ask Andrew to add AIFF-with-PCM (the minimal configuration, as I
understand it) to the Blorb document?

I actually have an Acorn program capable of converting Infocom-
format sound to AIFF, so I could fairly easily put together a
Blorb file for (say) "Sherlock" for use in testing.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Wed Sep 17 22:05:07 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xAeqf-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Mon, 15 Sep 1997 18:22:09 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Graham Nelson <graham@gnelson.demon.co.uk>,
        Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Converting Amiga-format Infocom games
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f9c34b2b669d05d7a77a6a0842268355
Status: U

>Can anyone help Mr Wolf?  I'd be grateful if someone could email
>him at simon@wolf-uk.com if so.

Done. (This posted here to avoid everyone mailing him).

Martin

From ???@??? Wed Sep 17 22:05:09 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 15 Sep 1997 11:46:12 -0700
X-Sender: mattack@mail.apple.com
Message-Id: <v01550101b042cfda5d4c@[17.202.20.138]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: z-machine@gmd.de
From: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] "Blorb" sound format again
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 27c416d21e5491eed0a690513ff9386c
Status: U

>On Fri 12 Sep, Andrew Plotkin wrote:
>>
>> It looks like both WAV and AIFF support various compression mechanisms. At
>> least, the converter I just tried asked me whether I was converting to
>> AIFF with PCM, AIFF with mu-law, WAV with PCM, WAV with mu-law... etc.
>
>Nobody has spoken out against AIFF, and it increasingly sounds

There's probably some "better" AIFF info available, but here's a couple of
links to get people started..  These are Apple II filetype notes, but it
looks like they describe the contents of the file just fine..

http://www.visi.com/~nathan/a2/tn/ftn/d8-0000.html

Err, there's just one now.  I saw reference to "AIFF-c", but can't find the
link at the moment.

--
mattack@apple.com


From ???@??? Wed Sep 17 22:05:11 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xAhSu-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Mon, 15 Sep 1997 21:09:48 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] "Blorb" sound format again
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 76b859c23025ea7ce023991c6c29dba0
Status: U

>Err, there's just one now.  I saw reference to "AIFF-c", but can't find the
>link at the moment.

A PostScript version (45 pages; 104681 bytes compressed) can be obtained from

	ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z
	ftp://ftp-europe.sgi.com/mirrors/ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z

(The latter being a European mirror site).

AIFF-C is the enhancement to support compression. This document appears to
be a draft, but I haven't found any newer ones.

There is also the URL I mentioned when advocating AIFF, but I've managed to
delete my archive of posts on this thread and can't remember what I typed
into AltaVista to get it (first attempt; it was second on the list!). Anyone
remember it?

Martin

From ???@??? Wed Sep 17 22:05:12 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 15 Sep 1997 16:31:53 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199709152031.QAA27271@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] "Blorb" sound format again
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a8871ac805c4ccf19959fda025a37be3
Status: U

} There's probably some "better" AIFF info available, but here's a couple of
} links to get people started..  These are Apple II filetype notes, but it
} looks like they describe the contents of the file just fine..

} http://www.visi.com/~nathan/a2/tn/ftn/d8-0000.html

} Err, there's just one now.  I saw reference to "AIFF-c", but can't find the
} link at the moment.

AIFF-C is for the Mac's 3:1 and 6:1 compression modes, as well as the
IIgs's 8:1 mode.  Probably of no relevance to Blorb


From ???@??? Mon Sep 22 17:08:38 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <01BCC280.5FA89F20.davidk@monis.co.uk>
From: David Kinder <davidk@monis.co.uk>
To: Z-Machine Mailing List <z-machine@gmd.de>,
        "'simon@wolf-uk.com'"
	 <simon@wolf-uk.com>
Subject: RE: [z-machine] Converting Amiga-format Infocom games
Date: Tue, 16 Sep 1997 09:10:26 +0100
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9f63e3f2ecd92946791beb5f8b243569

On Monday, September 15, 1997 11:33 AM, Graham Nelson [SMTP:graham@gnelson.demon.co.uk] wrote:
> 
> Can anyone help Mr Wolf?  I'd be grateful if someone could email
> him at simon@wolf-uk.com if so.

> On Mon 15 Sep, Simon Wolf wrote:
> > Hi.  I have The Lost Treasures of Infocom for my old Amiga and would
> > like to play the games on either my PC or Psion.  The only problem I
> > have is that I have no idea how to convert the Amiga's data files to the
> > Z format!  Each of the Infocom games seems to be a separate executable
> > file with a data file.  Any ideas would be greatly appreciated.

On the Amiga the "Story.dat" file is just the ZCode file, so it just needs
to be copied across to the PC and it will work straight away.

David


From ???@??? Wed Sep 17 22:05:19 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xAtsw-000Fb1C@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Tue, 16 Sep 1997 10:25:30 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: "Matthew T. Russotto" <russotto@pond.com>
Subject: Re: [z-machine] "Blorb" sound format again
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f651fb103f54a8e79ceea0673524ca02
Status: U

>AIFF-C is for the Mac's 3:1 and 6:1 compression modes, as well as the
>IIgs's 8:1 mode.  Probably of no relevance to Blorb

Quite. Having read the AIFF-C document last night, Apple seemed (at the time
the document was written, in 1990-1) very keen for people to dump the old
AIFF spec and use the AIFF-C spec instead, but in a quick search of random
websites I have not found any files claiming to be AIFF that were in fact
AIFF-C; all were based on the 1.3 AIFF spec. This is probably because AIFF-C
simply adds extra overhead for uncompressed samples, and the compression
provided (at least in the draft document I found) appears to all be various
fixed-ratio lossy algorithms (presumably some kind of delta-coding (Fibonacci
deltas?)). The one-time popular sound encoding of Huffman-compressed deltas
does not seem to be provided for, which is a pity (it compressed well and was
non-lossy).

Hence I propose that we specify the 1.3 AIFF spec (FORM type AIFF) for the
sound format. Now we just need to find it. Did anyone store my post with
the URL, or bookmark the site?

Martin

From ???@??? Mon Sep 22 17:08:40 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 14:40:03 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] "Blorb" sound format again
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <m0xAtsw-000Fb1C@kea.doc.ic.ac.uk>
Message-Id: <Marcel-1.26-0916134003-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: bbe5850645424ae9b42e788230b34d35

On Tue 16 Sep, Martin Frost wrote:
> Quite. Having read the AIFF-C document last night, Apple seemed (at the time
> the document was written, in 1990-1) very keen for people to dump the old
> AIFF spec and use the AIFF-C spec instead, but in a quick search of random
> websites I have not found any files claiming to be AIFF that were in fact
> AIFF-C; all were based on the 1.3 AIFF spec. This is probably because AIFF-C
> simply adds extra overhead for uncompressed samples, and the compression
> provided (at least in the draft document I found) appears to all be various
> fixed-ratio lossy algorithms (presumably some kind of delta-coding (Fibonacci
> deltas?)). The one-time popular sound encoding of Huffman-compressed deltas
> does not seem to be provided for, which is a pity (it compressed well and was
> non-lossy).
> 
> Hence I propose that we specify the 1.3 AIFF spec (FORM type AIFF) for the
> sound format.

I second the motion.  Is anyone unhappy about this prospect?

> Now we just need to find it. Did anyone store my post with
> the URL, or bookmark the site?

  http://www.mediatel.lu/workshop/audio/fileformat/aiff13/h_aiff13.html

worked for me.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Wed Sep 17 22:05:31 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
Date: Tue, 16 Sep 1997 18:11:46 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19970916165846.AAD4603@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 920ce8e8d2de9098eb9cec76e67fc1c1
Status: U


A side note:

The "Lurking Horror" sound files contain a flag that indicates whether
a sample has to be played once or in a loop. This information doesn't
fit in most standard formats, which is why I decided to use Infocom's
own format for Frotz. (Back then Frotz was DOS only, and I thought no-
one else would want to support this gimmick, let alone write new games
with sound support.) Since Frotz 2.3 this information has been wired
into the interpreter and need not be taken from the sound file itself.

-- Stefan

From ???@??? Wed Sep 17 22:05:32 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 09:25:14 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom18
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <m0xAtsw-000Fb1C@kea.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.970916092418.4745B-100000@netcom18>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 4ac88be3aa5e994a9940c7811809e5ed
Status: U

On Tue, 16 Sep 1997, Martin Frost wrote:

> >AIFF-C is for the Mac's 3:1 and 6:1 compression modes, as well as the
> >IIgs's 8:1 mode.  Probably of no relevance to Blorb
> 
> Quite. Having read the AIFF-C document last night, Apple seemed (at the time
> the document was written, in 1990-1) very keen for people to dump the old
> AIFF spec and use the AIFF-C spec instead, but in a quick search of random
> websites I have not found any files claiming to be AIFF that were in fact
> AIFF-C; all were based on the 1.3 AIFF spec.
> 
> Hence I propose that we specify the 1.3 AIFF spec (FORM type AIFF) for the
> sound format. Now we just need to find it. Did anyone store my post with
> the URL, or bookmark the site?

I found it at 
http://www.mediatel.lu/workshop/audio/fileformat/aiff13/h_aiff13.html

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Sep 17 22:05:34 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 09:32:50 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom18
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] extended-save and quetzal behavior
Message-Id: <Pine.SUN.3.95.970916092548.4745C-100000@netcom18>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e72fd2d1587d3e24b0b152cb621756de
Status: U

Two questions:

In the extended save and restore opcodes, there is a suggested filename
argument. Should the interpreter prompt the user for a filename and give
that as a default, or should it immediately start writing the file as
named?

I assumed the former, but it was stated on the newsgroup that
extended-save was used in Zork Zero to store user preferences. That would
presumably be checked every time the game starts up, so it would be bad to
prompt the user. 

Second: in the save-file spec, how exactly is an ANNO chunk treated? If I
want to save a user annotation ("got past troll"), can I just stick in an
ANNO? Conversely, if I load a save file which contains an ANNO chunk, can
I assume that it contains that kind of data (user notation describing the
game position)? What if there's more than one ANNO (which seems to be
legal)?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Sep 17 22:05:25 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xB2Z8-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Tue, 16 Sep 1997 19:41:37 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Andrew Plotkin <erkyrath@netcom.com>
Subject: Re: [z-machine] extended-save and quetzal behavior
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d621d86a33f1d1524e50ee2fc136d640
Status: U

>Second: in the save-file spec, how exactly is an ANNO chunk treated? If I
>want to save a user annotation ("got past troll"), can I just stick in an
>ANNO?

Yes.

7.5 says ``interpreters could prompt the user for an annotation when saving''.

>Conversely, if I load a save file which contains an ANNO chunk, can
>I assume that it contains that kind of data (user notation describing the
>game position)?

Well, at the moment other things are suggested as possibly being suitable
to put in an ANNO chunk (various automatically-generated info). However,
there is not really much point in doing so (few users would be interested).
I was discussing this with Miron Schmidt recently, in fact, and we came to
the decision that this is a Bad Thing. Hence a future version of the spec
will remove those suggestions, and only mention the idea of prompting the
user for a string.

The quetzal.c I distributed treats ANNOs by displaying the contents (using
Zip's normal buffered printing routines).

>What if there's more than one ANNO (which seems to be legal)?

The IFF standard does not specify what ANNO is to be used for, other than
it is a ``user annotation''. It depends what you want to do with it. If
(for example) you want to display a directory of save-files along with a
single-line comment (one of the ideas I had for ANNO) on OSs with severe
filename restrictions (cf MSDOS) then you could take the first chunk that
is less than 60 characters or whatever.

If you tell me exactly what you had in mind I could suggest something
(possibly a new chunk, although I'd prefer not to go that far).

Martin

From ???@??? Mon Sep 22 17:08:37 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 15:09:33 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199709161909.PAA11725@pond.com>
To: z-machine@gmd.de
Subject: Re:  [z-machine] extended-save and quetzal behavior
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 33c44f8d8858ed4c01c263507f5e1205

} I assumed the former, but it was stated on the newsgroup that
} extended-save was used in Zork Zero to store user preferences. That would
} presumably be checked every time the game starts up, so it would be bad to
} prompt the user. 

Infocom's Mac interpreters always prompt -- try saving the function
keys in Shogun, for example.  I don't believe they automatically load
the prefs, either.  Also, the Infocom interpreters save the suggested
name as part of the save file, and will refuse to load a save file
with a different suggested name.  This behavior is not in the spec.

From ???@??? Wed Sep 17 22:05:21 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 12:23:39 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] extended-save and quetzal behavior
In-Reply-To: <m0xB2Z8-000FayC@kea.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.970916121714.8713B-100000@netcom20>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 59de7bcfa6c504d8fc8923a3462767bb
Status: U

On Tue, 16 Sep 1997, Martin Frost wrote:

> >Conversely, if I load a save file which contains an ANNO chunk, can
> >I assume that it contains that kind of data (user notation describing the
> >game position)?
> 
> Well, at the moment other things are suggested as possibly being suitable
> to put in an ANNO chunk (various automatically-generated info). However,
> there is not really much point in doing so (few users would be interested).
> I was discussing this with Miron Schmidt recently, in fact, and we came to
> the decision that this is a Bad Thing. Hence a future version of the spec
> will remove those suggestions, and only mention the idea of prompting the
> user for a string.

Ok. That makes things clearer.
 
> The quetzal.c I distributed treats ANNOs by displaying the contents (using
> Zip's normal buffered printing routines).
>
> >What if there's more than one ANNO (which seems to be legal)?
> 
> The IFF standard does not specify what ANNO is to be used for, other than
> it is a ``user annotation''. It depends what you want to do with it. If
> (for example) you want to display a directory of save-files along with a
> single-line comment (one of the ideas I had for ANNO) on OSs with severe
> filename restrictions (cf MSDOS) then you could take the first chunk that
> is less than 60 characters or whatever.

Right. I'm doing a similar thing in MaxZip; the load-game file dialog will
have a space at the bottom for annotations. As you navigate around, any
save file you highlight will have its annotation displayed. 

It's more of a gimmick than a truly useful feature, since MacOS doesn't
have filename restrictions, and "Got past troll" is a valid filename. But
it's pretty easy to implement. (Except for some wackiness in the
standardfile dialog manager, which I can't figure out. Sigh.)
 
> If you tell me exactly what you had in mind I could suggest something
> (possibly a new chunk, although I'd prefer not to go that far).

I didn't have anything in mind; I was just wondering what I should do if I
encounter a Quetzal file with two ANNO chunks. The current plan is to read
the first and ignore any later ones.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Sep 17 22:05:20 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 15:24:35 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Graham Nelson <graham@gnelson.demon.co.uk>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <Marcel-1.26-0916134003-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SGI.3.95.970916152358.16502C-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 82d7118a605304968c2858499698159a
Status: U

>> Hence I propose that we specify the 1.3 AIFF spec (FORM type AIFF) for the
>> sound format.
>
>I second the motion.  Is anyone unhappy about this prospect?

  Well, yes.  I still prefer MIDI as being more versatile.  But AIFF is
fine.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------

From ???@??? Mon Sep 22 17:08:32 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 12:33:47 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <19970916165846.AAD4603@jokisch>
Message-Id: <Pine.SUN.3.95.970916122525.8713C-100000@netcom20>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 352b8dd86cde9fc2ca99156a59306882

On Tue, 16 Sep 1997, Stefan Jokisch wrote:

> 
> A side note:
> 
> The "Lurking Horror" sound files contain a flag that indicates whether
> a sample has to be played once or in a loop. This information doesn't
> fit in most standard formats, which is why I decided to use Infocom's
> own format for Frotz. (Back then Frotz was DOS only, and I thought no-
> one else would want to support this gimmick, let alone write new games
> with sound support.) Since Frotz 2.3 this information has been wired
> into the interpreter and need not be taken from the sound file itself.

Hm. In an ideal world, the Blorb file would be able to specify this flag.

However, it's only necessary for V3 games. (In V5+, the @sound_effect
opcode has an argument for whether the sound should play once, N times, or
repeat forever. So this info isn't stored in the sound file at all.)

Shall we just punt on this?  I don't expect there will be any new V3
sound-using games created.  Interpreters that wish to play Lurking Horror
will have to hard-wire the flag, the way Frotz does.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Sep 17 22:05:28 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 12:53:27 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <Pine.SGI.3.95.970916152358.16502C-100000@vangogh.bergen.org>
Message-Id: <Pine.SUN.3.95.970916124146.17719A-100000@netcom20>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6331db0ff6339bde8429ded2e6cea8d2
Status: U

On Tue, 16 Sep 1997, A.K.A. TheWiz wrote:

> >> Hence I propose that we specify the 1.3 AIFF spec (FORM type AIFF) for the
> >> sound format.
> >
> >I second the motion.  Is anyone unhappy about this prospect?
> 
>   Well, yes.  I still prefer MIDI as being more versatile.  But AIFF is
> fine.

Once upon a time, I suggested having two sound formats for Blorb: a sample
format like AIFF, and a note format like MIDI or Amiga MOD.

This is more work for the interpreter writer, but the benefits of a note
format are very large for anyone who wants music in a game. You can fit
lots of minutes of music into a few thousand bytes.

Comments? I know there's lots of MOD sample code out there; I'm not sure
about MIDI, but I know that (for example) MacOS now includes MIDI support.
(Although it kind of sucked the last time I tried to use it, two years
ago.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Sep 17 22:05:27 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Sep 1997 17:15:44 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199709162115.RAA20170@pond.com>
To: erkyrath@netcom.com, z-machine@gmd.de
Subject: Re: [z-machine] "Blorb" sound format again
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0ed5b9c8f60b4a596e687fac0ff75929
Status: U

} Hm. In an ideal world, the Blorb file would be able to specify this flag.

I thought AIFF had the ability to specify a loop.

From ???@??? Mon Sep 22 17:08:35 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Sep 1997 08:45:26 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] extended-save and quetzal behavior
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.SUN.3.95.970916121714.8713B-100000@netcom20>
Message-Id: <Marcel-1.26-0917074526-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 45d717fe9306a8b7b43800ea1b5f33c8

On Tue 16 Sep, Andrew Plotkin wrote:
> On Tue, 16 Sep 1997, Martin Frost wrote:
> 
> > >Conversely, if I load a save file which contains an ANNO chunk, can
> > >I assume that it contains that kind of data (user notation describing the
> > >game position)?

As an altogether evil and dangerous suggestion, the interpreter
could persuade the game to perform a <<Fullscore>> action and
record the output in an ANNO chunk...

No, no, forget I said that.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Mon Sep 22 17:08:42 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xBHYl-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Wed, 17 Sep 1997 11:42:15 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Andrew Plotkin <erkyrath@netcom.com>
Subject: Re: [z-machine] "Blorb" sound format again
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 777f8dfd3b303978527b495d129095ea

Andrew Plotkin wrote:

>Once upon a time, I suggested having two sound formats for Blorb: a sample
>format like AIFF, and a note format like MIDI or Amiga MOD.

>This is more work for the interpreter writer, but the benefits of a note
>format are very large for anyone who wants music in a game. You can fit
>lots of minutes of music into a few thousand bytes.

>Comments? I know there's lots of MOD sample code out there; I'm not sure
>about MIDI, but I know that (for example) MacOS now includes MIDI support.
>(Although it kind of sucked the last time I tried to use it, two years
>ago.)

MODs are quite restrictive, which is probably exactly what we want with
this sort of thing. They are also well known, with lots of freely available
source. The downside is that there are a number of different incompatible
variants floating about, usually to get over particular restrictions (such
as being limited to 4 channels). I still think MODs are better than MIDI
for these purposes, provided we pick one of the variants (I'd suggest the
Protracker one, since it's probably the most widely used) and stick with it.

It might be an idea to have a ``supports music'' flag separate from the
``supports sound'' flag.

Matthew Russotto wrote:

>I thought AIFF had the ability to specify a loop.

It does. The INST chunk contains (among other things) a sustain loop and
a release loop. There doesn't seem to be a simple loop chunk, however, so
you'd have to fill in random values for the others (which shouldn't be too
bad, as we can ignore them on playback). How about saying that compliance
to Blorb requires understanding of the looping data in an INST but ignoring
the rest?

Martin

From ???@??? Mon Sep 22 17:08:54 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Sep 1997 16:38:09 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] @set_colour: our only 3OP instruction
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.26-0917153809-bc8M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b6aef1f72fce2bd999ce502ddfbc256a


Just a note to alert other Z-machine people to a minor anomaly in
the specification which may cause problems.  Until about five
minutes ago, Inform was unable to compile the instruction

   @set_colour fg bg wind;

inside a Version 6 game, because the assembler insisted that a 2OP
opcode should have two and only two opcodes.  This is true across
all versions of the Z-machine _except_ for set_colour (2OP:27)
under Version 6 only, which can take an optional third opcode.
Such a usage is necessarily encoded in 2OP-as-VAR form.

Since "txd" 7.2 is also fooled by this...

  Routine R0002, 0 locals

       1b 01 02                SET_COLOUR      #01,#02

  Warning: Unexpected Parameter #2 near 00501
       db 57 01 02 03          SET_COLOUR      #01,#02,#03
       b0                      RTRUE           

...I thought it was worth mentioning to interpreter-writers that
the possibility exists.  I would have missed it myself if Jason
Penney hadn't sent me it as a bug report.  I hope I haven't
misunderstood the whole situation.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Mon Sep 22 17:08:47 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Sep 1997 11:09:02 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom12
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] extended-save and quetzal behavior
In-Reply-To: <Marcel-1.26-0917074526-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.970917110641.17519B-100000@netcom12>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ca150e6d87ac046b1aad8f5686c2f2c3

On Wed, 17 Sep 1997, Graham Nelson wrote:

> On Tue 16 Sep, Andrew Plotkin wrote:
> > On Tue, 16 Sep 1997, Martin Frost wrote:
> > 
> > > >Conversely, if I load a save file which contains an ANNO chunk, can
> > > >I assume that it contains that kind of data (user notation describing the
> > > >game position)?
> 
> As an altogether evil and dangerous suggestion, the interpreter
> could persuade the game to perform a <<Fullscore>> action and
> record the output in an ANNO chunk...
> 
> No, no, forget I said that.

Bad, BAD Graham. No Acorn treat for *you*.

(I can just see, say, the Zork 1 game file crashing and burning as the
interpreter tries to find a "fullscore" verb in it. Never mind how
Freefall would react.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Sep 22 17:08:49 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Sep 1997 14:26:06 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Andrew Plotkin <erkyrath@netcom.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] extended-save and quetzal behavior
In-Reply-To: <Pine.SUN.3.95.970917110641.17519B-100000@netcom12>
Message-Id: <Pine.SGI.3.95.970917142519.851E-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 94a6f7644694a94ff12d96aa39c3a8e8

>Bad, BAD Graham. No Acorn treat for *you*.
>
>(I can just see, say, the Zork 1 game file crashing and burning as the
>interpreter tries to find a "fullscore" verb in it. Never mind how
>Freefall would react.)

  I liked the idea, actually.  Games with no fullscore verb would just not
get the ANNO text.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------

From ???@??? Mon Sep 22 17:08:50 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Sep 1997 11:36:29 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom12
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <m0xBHYl-000FayC@kea.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.970917110915.17519C-100000@netcom12>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: beacbd6a70afbb77f9a0873cd60af00e

On Wed, 17 Sep 1997, Martin Frost wrote:

> >Once upon a time, I suggested having two sound formats for Blorb: a sample
> >format like AIFF, and a note format like MIDI or Amiga MOD.
>
> MODs are quite restrictive, which is probably exactly what we want with
> this sort of thing. They are also well known, with lots of freely available
> source. The downside is that there are a number of different incompatible
> variants floating about, usually to get over particular restrictions (such
> as being limited to 4 channels). I still think MODs are better than MIDI
> for these purposes, provided we pick one of the variants (I'd suggest the
> Protracker one, since it's probably the most widely used) and stick with it.

I've found "Protracker 2.3A Song/Module Format" at 
ftp://ftp.cwi.nl/pub/audio/MOD-info
 
Is that the most up-to-date? (Or least obsolete? :-)

> It might be an idea to have a ``supports music'' flag separate from the
> ``supports sound'' flag.

Ooo, tricky. The advantage of the Blorb system is that the game doesn't
care what format a given resource is in; they're all just "sounds" to the
game. But it is useful for the game author to be able to tell whether
music will work. 

I think I'll leave it to the bearers of the Z-spec whether to pollute that
holy document with the crass AIFF/MOD distinction. Heh.

> Matthew Russotto wrote:
> 
> >I thought AIFF had the ability to specify a loop.
> 
> It does. The INST chunk contains (among other things) a sustain loop and
> a release loop. There doesn't seem to be a simple loop chunk, however, so
> you'd have to fill in random values for the others (which shouldn't be too
> bad, as we can ignore them on playback). How about saying that compliance
> to Blorb requires understanding of the looping data in an INST but ignoring
> the rest?

Again, this is *different* for the V3 game (Lurking Horror) and all V5+
games. 

In V3, the game expects the interpreter to know whether a given sound
loops. Infocom handled this by putting a loop flag in each sound file.
Frotz handles this by hardwiring which LH sounds are supposed to loop.

In V5+, the game tells the interpreter whether to loop each sound. 

This leaves us with options:

In V5+, we could
1A) require the interpreter to check the loop data in the INST chunk, and
use that to fulfil the game's requests. (If the loop data says "loop from
X to Y", use that information if the game so requests. If the loop data
says "don't loop", just replay the entire sound if requested.) 
1B) ignore the loop data, and always replay the entire sound if requested.

In V3, we could
2A) require the interpreter to check the loop data; if it says "don't
loop" then don't loop, otherwise loop using that information.
2B) ignore the loop data, and hardwire the loop flags for LH.

Now, if we choose 1B, I'm also choosing 2B; I'm not going to make
interpreter slog through AIFF data in search of loop data, for the sake of
a single V3 game. 

I guess the question is: can interpreters plausibly make use of loop data
in choice 1A? That is, if you're going to play AIFF sounds on your OS, is
it hard to tell your sound routine "play this sound and follow the
'sustain' loop three times"? Or do most sound routines just allow you to
play the AIFF once, no fooling around? I've never tried it, so I don't
know. 

(Footnote: for MOD sounds, we cheerfully punt the whole problem, since LH
has no music sounds.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Sep 22 17:09:00 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: Miron Schmidt <s590501@tfh-berlin.de>
Reply-To: miron@comports.com
To: Z-List <z-machine@gmd.de>
Date: Wed, 17 Sep 1997 19:41:26 +0100
Message-Id: <yam7199.1326.1205535584@mailhost.tfh-berlin.de>
In-Reply-To: <Pine.SUN.3.95.970916124146.17719A-100000@netcom20>
X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck
Organization: TFH-Berlin via PPP
Subject: Re: [z-machine] "Blorb" sound format (MIDI or MODs?)
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 40ac2a7bd06fccb48155d363b96f2ce3

Andrew Plotkin <erkyrath@netcom.com> wrote:
> Once upon a time, I suggested having two sound formats for Blorb: a sample
> format like AIFF, and a note format like MIDI or Amiga MOD.

> Comments? I know there's lots of MOD sample code out there; I'm not sure
> about MIDI, but I know that (for example) MacOS now includes MIDI support.
> (Although it kind of sucked the last time I tried to use it, two years
> ago.)

Well, the current Amiga OS doesn't support MIDI. MIDI also has the
disadvantage that the composer doesn't really have any control about how his
song will sound on a particular machine, as the played instruments heavily
depend on the sound card or synthesizer used.

The problem with MODs, obviously, is that there are dozens of formats that
all call themselves MOD, many of which are not identifyable by their first
few bytes.

I'd suggest to settle for MOD anyway, possibly an extended format such as S3M
or XM: those two can play more than the original four channels (something
like a maximum of 64).

Generally, I like the idea of a song format a lot. I'd like to provide
special rooms with some background music, for example.

-- 
Miron Schmidt <miron@comports.com>

           "So, if _Space Aliens_ is Infocom on acid, what's this?"
                       -- C.E. Forman, _Detective: An Interactive MiSTing_


From ???@??? Mon Sep 22 17:08:56 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xBPu5-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Wed, 17 Sep 1997 20:36:49 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: "A.K.A. TheWiz" <dankna@bergen.org>
Subject: Re: [z-machine] extended-save and quetzal behavior
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e5c7d8dcd760237c95b337375f0d7f86

>>(I can just see, say, the Zork 1 game file crashing and burning as the
>>interpreter tries to find a "fullscore" verb in it. Never mind how
>>Freefall would react.)

>  I liked the idea, actually.  Games with no fullscore verb would just not
>get the ANNO text.

But how is the interpreter to find the verb? Does it wait until the game
next calls READ and then returns ``fullscore'' while trapping output? Does
it try to find the parsing tables in Z-machine RAM and feel its way through
them assuming them to be in the Inform format? There isn't any way for the
interpreter to get the game to execute particular verb actions without a
lot of assumptions made about the format of the game's data structures.

Now, if we used the extension table (aka the mouse data table), we could
define a word in it as pointing to a particular block of data the game
wants added as an ANNO if the interpreter supports it... This has the
advantage of being backward-compatible, both with old games and old
interpreters...

It's either that or do incredibly hacky things like looking for the known
format of, say, the Inform library banner message and assuming the parse
tables are in the Inform format if it finds it... Personally, I'd regard
this as something of an evil hack.

Martin

From ???@??? Mon Sep 22 17:08:58 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Sep 1997 15:52:23 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Martin Frost <mdf@doc.ic.ac.uk>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] extended-save and quetzal behavior
In-Reply-To: <m0xBPu5-000FayC@kea.doc.ic.ac.uk>
Message-Id: <Pine.SGI.3.95.970917155140.6917B-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1dde0a473fb74f0bd1e9ebb585f53ab6

>But how is the interpreter to find the verb? Does it wait until the game
>next calls READ and then returns ``fullscore'' while trapping output? Does
>it try to find the parsing tables in Z-machine RAM and feel its way through
>them assuming them to be in the Inform format? There isn't any way for the
>interpreter to get the game to execute particular verb actions without a
>lot of assumptions made about the format of the game's data structures.

  No, it sees if it's in the dictionary, and if so it just fake-enters the
text at the command prompt...

>Now, if we used the extension table (aka the mouse data table), we could
>define a word in it as pointing to a particular block of data the game
>wants added as an ANNO if the interpreter supports it... This has the
>advantage of being backward-compatible, both with old games and old
>interpreters...

>It's either that or do incredibly hacky things like looking for the known
>format of, say, the Inform library banner message and assuming the parse
>tables are in the Inform format if it finds it... Personally, I'd regard
>this as something of an evil hack.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------

From ???@??? Mon Sep 22 17:09:06 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xBQcZ-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Wed, 17 Sep 1997 21:22:47 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Andrew Plotkin <erkyrath@netcom.com>
Subject: Re: [z-machine] "Blorb" sound format again
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7c02c57ec97fa18169440c8f4d952cf2

Andrew Plotkin wrote:

>I've found "Protracker 2.3A Song/Module Format" at 
>ftp://ftp.cwi.nl/pub/audio/MOD-info

>Is that the most up-to-date? (Or least obsolete? :-)

Protracker 2.3 is actually more recent than the most portable version,
which is the 2.0 release. However, as long as we restrict ourselves to
MODs with only 64 patterns (ones with the magic word being 'M.K.' rather
than 'M!K!') it should be OK. (I'm thinking here more of easy availability
of playroutine source. If people are happy to modify existing players
to handle the >64 pattern versions I have no fundamental objections). ;)

>I think I'll leave it to the bearers of the Z-spec whether to pollute that
>holy document with the crass AIFF/MOD distinction. Heh.

Actually, I'm already having second thoughts as to whether it is really
necessary to distinguish, as long as every Blorb-compliant interpreter
supporting sound handles both AIFFs and MODs, since they will be played
the same way from Z-code anyway.

A possible alternative to modules are Protracker ``songs'', which are
basically the sequencing data from the modules without the samples
tacked on the end.

Explanation: a Protracker module has vague structure:

	Song header
	Instrument header (31)
	Pattern data (up to 64)
	Samples (up to 31)

The song format is exactly the same, but the player is expected to find the
samples from the filenames stored in the instrument headers. This could fit
in with Blorb by having a special format for these filenames, such as
filename ``blorb023'' being sample resource 23 from the Blorb file, allowing
people to have modules with better quality samples than the 8-bit linear
PCM that modules support. I'm really rambling a bit here, but I'd be
interested in what people think.

>In V3, the game expects the interpreter to know whether a given sound
>loops. Infocom handled this by putting a loop flag in each sound file.
>Frotz handles this by hardwiring which LH sounds are supposed to loop.

Possibly the easiest solution for interpreter-writers would be to add a
flag in each sound chunk in the Blorb file to specify looping, since we
seem to only require simple end-to-end looping. IMHO adding story-
specific behaviour to interpreters is a Very Very Bad Thing, and I'd much
prefer to have the info stored with the sounds (like Infocom did); if
using the loop info from the AIFF files is too hard, then we should add
a flag to Blorb.

Martin

From ???@??? Mon Sep 22 17:09:09 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Sep 1997 13:42:54 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom17
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] extended-save and quetzal behavior
In-Reply-To: <m0xBPu5-000FayC@kea.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.970917133306.1199C-100000@netcom17>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a4beae6a84018007454286d607bc02f5

On Wed, 17 Sep 1997, Martin Frost wrote:

> >>(I can just see, say, the Zork 1 game file crashing and burning as the
> >>interpreter tries to find a "fullscore" verb in it. Never mind how
> >>Freefall would react.)
> 
> >  I liked the idea, actually.  Games with no fullscore verb would just not
> >get the ANNO text.
> 
> But how is the interpreter to find the verb? Does it wait until the game
> next calls READ and then returns ``fullscore'' while trapping output? Does
> it try to find the parsing tables in Z-machine RAM and feel its way through
> them assuming them to be in the Inform format? There isn't any way for the
> interpreter to get the game to execute particular verb actions without a
> lot of assumptions made about the format of the game's data structures.

Right. Pardon me while I insert the text of some email I just sent on the
subject...

---------

There is no such thing as a verb. The arrangement of dictionaries and
verb-action procedures is entirely up to the compiler; there's no
"Z-machine standard" on how to do it. It's different between Infocom
games, Inform 5, Inform 6, not to mention entirely new libraries like
"Space Under the Window". So the interpreter can't just jump in to a
particular Z-machine routine. 

It would have to be implemented by feeding the text "fullscore" into the
standard input routine. Now, the first problem is that during the @save
opcode the program counter isn't *at* the standard input routine. It's in
the middle of saving, and the game expects that to return a fail/success
flag before it returns to the input loop. So you have to screw around with
the undo state; effectively have the save opcode finish, fake a "fulltext"
string, record the results, and then "undo" back to the middle of the save
opcode. Which may not be possible. I'm not even positive it's meaningful;
quite a lot might happen after the save opcode before the game reaches an
input prompt. 

> [if the game does something weird in response to "fullscore", the
> interpreter can have an option to turn off fullscore-annotating]

Now you have a game which does not work on a particular intepreter unless
an interpreter option is set. Bad precedent. 

> [game shouldn't crash in response to "fullscore"]

I'm not worried about crashing. What about a game where you're at a
"conversation" prompt, where anything you type is parsed as a statement,
and any non-understood response makes the dragon angrier? Or a password
prompt? (Most games wouldn't allow you to save at a password prompt, but a
clever one might.)

What about non-English games, where the fullscore command is some other
string?

What about a game which implements a "Do you want to save after quitting?"
prompt. The next thing that happens after *that* save opcode is that the
interpreter shuts down. Have fun performing "undo" after that.

What about a game which responds to "fullscore" by quitting?  Sure, you
can say that's a lousy idea. But it is a *legal* idea, and there's no
reason to screw over the author by making "save" stop working. 

What about games with no input prompt, like the REXX-to-Inform conversions
we've seen?

The problem is not solvable in general. It's rather like the idea of an
automated "inventory" window, which went by a few years ago. The game can
be written to support it, but there's no way to extend it to games that
don't support it.

---------
 
> Now, if we used the extension table (aka the mouse data table), we could
> define a word in it as pointing to a particular block of data the game
> wants added as an ANNO if the interpreter supports it... This has the
> advantage of being backward-compatible, both with old games and old
> interpreters...

Agreed on all counts. 

BTW, this sort of thing (a game-generated annotation) should be in
addition to a user-typed annotation, not instead of it. A fullscore
listing can be pretty huge, and sometimes I really do just want to type
"Bat room, with two gems."

That makes two ANNO chunks, of course--

My final conclusion is still "Bad Graham."

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Mon Sep 22 17:09:13 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Sep 1997 14:01:42 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom17
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Yet another ZIP bug
Message-Id: <Pine.SUN.3.95.970917134317.1199D-100000@netcom17>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9d269848674085ccda8475e853629daf

This is a particularly icky one; it's been causing endless hell of the
form 

> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I don't recognize that verb.
> PUT ROD
(in what?)
> BOX
You can't see any such thing here.

...even when there is a box there.

The problem is that tokenise() expects the character buffer to be
zero-terminated, which is wrong in V5+.

At the end of get_line(), replace

------
    /* Zero terminate line */
    buffer[read_size] = '\0';

    if (h_type > V4)
        cbuf[1] = (char) read_size;
------
with
------
    if (h_type > V4) {
        cbuf[1] = (char) read_size;
    }
    else {
        /* Zero terminate line (V1-4 only) */
        buffer[read_size] = '\0';
    }
------

At the beginning of tokenise_line(), add:
------
    int slen; char *str_end; 
------

And a few lines later, just before the "/* Initialise word count and
pointers */" comment: 

------
    /* Find the string length */
    if (h_type > V4) {
        slen = (unsigned char)(cbuf[1]);
        str_end = cbuf + 2 + slen;
    }
    else {
        slen = strlen(cbuf+1);
        str_end = cbuf + 1 + slen;
    }
------

Then change the signature of next_token to

------
static const char *next_token (const char *s, const char *str_end, const
char **token, int *length, const char *punctuation)
------

(adding the str_end parameter.) And go through and add str_end as argument
to each next_token call, in the appropriate place.

And finally, near the top of next_token(), change the line

------
    for (; *s; s++) {
------
with
------
    for (; s < str_end; s++) {
------

This bug exists in MaxZip up to version 1.7.0. I'll try to have a 1.7.1
out soon. Graham should also be able to fix libraries 6/7 to work
correctly even on interpreters which have the bug. However, it's still
worth fixing.

I'm told Frotz does not have this bug, which is no surprise. :) I also
find that Zip Infinity (on the Mac) doesn't have it. Other ZIP porters,
well, you know whether you've fixed this. Have fun.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Sep 22 17:09:25 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
Date: Thu, 18 Sep 1997 12:24:09 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19970918102000.AAA2071@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 22d036d5d3e0d2a9cf8d14eb01d8246d

 
> > It might be an idea to have a ``supports music'' flag separate from the
> > ``supports sound'' flag.
 
> Ooo, tricky. The advantage of the Blorb system is that the game doesn't
> care what format a given resource is in; they're all just "sounds" to the
> game. But it is useful for the game author to be able to tell whether
> music will work. 

The SOUND_EFFECT opcode should be for sound effects only.  I like the idea
of having a separate MUSIC opcode, and a separate header flag as well.

I'd also like to vote for the MIDI format rather than MOD.  Although I had
a great time producing horrible MOD music on my Amiga, MIDI appears to be
the more professional solution.  The MIDI file is small as it contains no
samples and a lot of sound hardware is especially designed to produce high
quality MIDI sound.  Today's PC games use MIDI much more often than MOD...

-- Stefan

From ???@??? Mon Sep 22 17:09:27 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xBegr-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Thu, 18 Sep 1997 12:24:09 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: s.jokisch@avu.de (Stefan Jokisch)
Subject: Re: [z-machine] "Blorb" sound format again
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 689605850a9fe8a1d9845acca25e0d23

>I'd also like to vote for the MIDI format rather than MOD.  Although I had
>a great time producing horrible MOD music on my Amiga, MIDI appears to be
>the more professional solution.  The MIDI file is small as it contains no
>samples and a lot of sound hardware is especially designed to produce high
>quality MIDI sound.

The trouble with MIDI is that is is hardware-dependent to a ridiculous
degree. It is perfect if you are sitting in a recording studio making a
record where you control every piece of equipment and all the connections,
but where you are going to be distributing the music as a sequence it is
preferable if you can control all the instruments.

>Today's PC games use MIDI much more often than MOD...

Today's PC games tend to target their music at one particular soundcard,
or provide multiple music files for different soundcards and select one
based on what the soundcard identified itself to Windoze as. Neither of
these is suitable for a Z-machine music format (unless you plan to define
a computer capable of running Blorb games as a PC with Windoze and an
expensive soundcard, which kinda defeats the point).

My personal preference is to use the MOD format for sequencing, but store
the samples as separate 'Snd ' resources in the Blorb file, which allows
games with several music files with a subset of samples in common to save
space over duplicating all the samples (see my post of yesterday for how
this could work).

Martin

From ???@??? Mon Sep 22 17:09:29 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 18 Sep 1997 07:37:32 -0400 (EDT)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: miron@comports.com
Cc: Z-List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format (MIDI or MODs?)
In-Reply-To: <yam7199.1326.1205535584@mailhost.tfh-berlin.de>
Message-Id: <Pine.SGI.3.95.970918073624.11848A-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 4733d50915e02497960c704648c87ae4

>I'd suggest to settle for MOD anyway, possibly an extended format such as S3M
>or XM: those two can play more than the original four channels (something
>like a maximum of 64).
>
>Generally, I like the idea of a song format a lot. I'd like to provide
>special rooms with some background music, for example.

  Right.  Personally, I'm interested in a sort of dynamic-song format,
whereby there's only a few background songs, but the themes change and
gain and lose prominence depending on what the mood is supposed to be.
But that's far in the future for *any* system.

____________________________________________________________________________
|The Mauve Baron|  Beep  |dankna@bergen.org * http://www.bergen.org/~dankna|
|---------------|  Blip  |-------------------------------------------------|
|   Dan Knapp   |  Bonk  |     This notice copyright (C)1997 Dan Knapp     |
----------------------------------------------------------------------------

From ???@??? Mon Sep 22 17:09:43 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 18 Sep 1997 11:49:15 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom15
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <19970918102000.AAA2071@jokisch>
Message-Id: <Pine.SUN.3.95.970918113608.27959A-100000@netcom15>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 891a18ca4c539d24c895fc72a0d0c5c0

On Thu, 18 Sep 1997, Stefan Jokisch wrote:

>  
> > > It might be an idea to have a ``supports music'' flag separate from the
> > > ``supports sound'' flag.
>  
> > Ooo, tricky. The advantage of the Blorb system is that the game doesn't
> > care what format a given resource is in; they're all just "sounds" to the
> > game. But it is useful for the game author to be able to tell whether
> > music will work. 
> 
> The SOUND_EFFECT opcode should be for sound effects only.  I like the idea
> of having a separate MUSIC opcode, and a separate header flag as well.

Music is a sound effect. What do you want to do with music? Play some,
play some on repeat, or change the volume. And possibly pre-load it,
for efficiency. This is what SOUND_EFFECT does. I don't see any difference
between sound intended to be melodious and backgroundy and sound intended
for, well, any other purpose. 

It's really just two different compression schemes, one very well suited
for a particular variety of noise.

(In fact, graphical games I've played have convinced me that background
noise can be *either* music or sampled sound. In Myst, some rooms had
background music, and some had background wind or waves or machinery
sound. Both were very effective.)

I can see one counterargument: you might want to leave music playing while
other sounds occur. And the spec says that only one sound can be playing
at a time. But, as I said, you might want to leave non-music (ie, wind)
playing while other sounds occur. So I think that discussion should be
about how to extend the SOUND_EFFECT opcode so that *any* sounds can be
mixed or overlapped. 
 
--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Sep 22 17:09:45 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 18 Sep 1997 11:56:15 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom15
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <m0xBQcZ-000FayC@kea.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.970918115039.27959B-100000@netcom15>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: fabee314dbcc8f2419ca3abff5ee59df

On Wed, 17 Sep 1997, Martin Frost wrote:

> My personal preference is to use the MOD format for sequencing, but
> store the samples as separate 'Snd ' resources in the Blorb file, which
> allows games with several music files with a subset of samples in common
> to save space over duplicating all the samples (see my post of yesterday
> for how this could work).

>From yesterday:
> A possible alternative to modules are Protracker ``songs'', which are
> basically the sequencing data from the modules without the samples
> tacked on the end.
> 
> Explanation: a Protracker module has vague structure:
> 
> 	Song header
> 	Instrument header (31)
> 	Pattern data (up to 64)
> 	Samples (up to 31)
> 
> The song format is exactly the same, but the player is expected to find the
> samples from the filenames stored in the instrument headers. This could fit
> in with Blorb by having a special format for these filenames, such as
> filename ``blorb023'' being sample resource 23 from the Blorb file, allowing
> people to have modules with better quality samples than the 8-bit linear
> PCM that modules support. I'm really rambling a bit here, but I'd be
> interested in what people think.

Questions:

Does the typical MOD composition tool allow you to write out songs in this
format? In other words, can authors actually generate this stuff?

What about the MOD-playing source code that's available? It's presumably
hard-wired for 8-bit linear samples; how hard is it to modify for other
sample qualities? If we allow other qualities, we're requiring all 
sound-supporting interpreters to *handle* other qualities.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Mon Sep 22 17:09:52 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xC3dL-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Fri, 19 Sep 1997 15:02:11 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Andrew Plotkin <erkyrath@netcom.com>
Subject: Re: [z-machine] "Blorb" sound format again
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f18b0742fcc3ce633c5f3f83e679ba70

Andrew Plotkin wrote:

>Does the typical MOD composition tool allow you to write out songs in this
>format? In other words, can authors actually generate this stuff?

All versions of Protracker that I know of on the Amiga can, and the couple
of PC-based Protracker clones all can. The format originated as a typical
composition will have the fixed 1084 byte header, followed by twenty to
thirty 1024 byte patterns repeated in various ways, followed by anything
up to the order of 300K of samples. Clearly, a 20-30K file is preferable
to a 320-330K one when composing, especially off floppies.

Stripping the samples out is trivial too: it requires a piece of code
snipped from the initialisation routine of the playroutine which finds
the first sample.

>What about the MOD-playing source code that's available? It's presumably
>hard-wired for 8-bit linear samples; how hard is it to modify for other
>sample qualities? If we allow other qualities, we're requiring all 
>sound-supporting interpreters to *handle* other qualities.

I expect it is hardwired, but I can see two ways round it.

The better way (which may or may not be possible depending on how the
existing code plays samples) would be to alter the code. I have seen
two methods for playing samples used by such code: most modern ones
use the computer's PCM playback capabilities (possibly with mixing to
increase number of channels). These should be simple to modify (assuming
the underlying hardware can actually support more than 8 bits/channel;
if not, there's no need to do anything). The other type I have seen have
been on PCs without a soundcard. All PCs have an internal speaker, which
is effectively a 1-bit output device; however, by toggling the speaker
faster than it can physically move a reasonably smooth wave can be
simulated via PWM. Any PC over about 8-10 Mhz can produce 4 channels of
mixed, fairly low-quality sound by this method. These playroutines are
somewhat harder to modify, due to their nature as low-level hacks.

The less good but probably easier method is to normalise all samples to
8 bits on loading. This is trivial; simply a logical shift. This could
result in suboptimal sound quality (if a machine can support 16-bit sound,
and the file contains 16-bit samples, but the player doesn't understand
them so reduces them to 8 bits).

By application of the second method, the modifications to the player can
be limited to the initialisation code. MOD init code is basically finding
the addresses of the samples and storing them in an array for later
reference. It should not be difficult to modify this to instead load the
samples from the Blorb file and if necessary reduce or promote them to 8
bits.

The more I think about my idea, the more I like it. ;) It allows people
to use better quality samples than would otherwise be possible; it allows
people to reduce the size of the Blorb files (by removing redundant
samples); and allows people to reuse the code they'll already have for
loading simple samples to load the samples for the MOD, possibly with a
small amount of extra processing.

All this for a small amount of extra work in the Blorb compiler (which
may not even be necessary if enough MOD-saving programs support the song
format). This is of the order of 10 lines of code, much of which would be
in the player anyway. When is a choice ever so clear? ;)

Martin

From ???@??? Mon Sep 22 17:10:01 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
Date: Fri, 19 Sep 1997 23:45:42 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19970919214302.AAA24954@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 39cf85417709fed5688ae8fe4304ba9f


[Andrew Plotkin on my proposal for a separate "music" opcode:]

> Music is a sound effect. What do you want to do with music? Play some,
> play some on repeat, or change the volume. And possibly pre-load it,
> for efficiency. This is what SOUND_EFFECT does. I don't see any
difference
> between sound intended to be melodious and backgroundy and sound intended
> for, well, any other purpose. 

Sound effects and music are technically different for the interpreter
who implements them, and for the author who creates them.  We might
want to change the specification of SOUND_EFFECT to allow several
sound effects at the same time, but we certainly wouldn't want more
than one MOD (or MIDI?) piece at a time.  Our definition of what can
be played at the same time would be much simpler if we had separate
opcodes for music and sound effects.

Furthermore, I doubt it makes sense to pre-load a piece of music the
same way you pre-load a sample.  The latter might be needed for, say,
a Z-code version of Space Invaders, when the explosion sounds mustn't
be delayed by tenths of a second.  Starting a piece of music usually
isn't that urgent.  And you don't need to keep a piece of music in
memory once it's finished, thus the SOUND_EFFECT operation #4 (finish
with sample) doesn't make sense with music, either.  The syntax of a
MUSIC opcode would be simple:

MUSIC 0 -- stop music
MUSIC n vol ... -- play piece #n at volume "vol" ...

Finally, a new opcode would help Inform to detect music support, and
so Inform would be able to set our new "music flag" automatically.

And we certainly want a new header flag, right?

-- Stefan

From ???@??? Mon Sep 22 17:10:03 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom8.netcom.com: erkyrath owned process doing -bs
Date: Fri, 19 Sep 1997 19:47:14 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom8
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <m0xC3dL-000FayC@kea.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.970919193906.1496A-100000@netcom8>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d91140c6594c54e6bb4eace21da01919

On Fri, 19 Sep 1997, Martin Frost wrote:

> Andrew Plotkin wrote:
> 
> >What about the MOD-playing source code that's available? It's presumably
> >hard-wired for 8-bit linear samples; how hard is it to modify for other
> >sample qualities? If we allow other qualities, we're requiring all 
> >sound-supporting interpreters to *handle* other qualities.
> 
> I expect it is hardwired, but I can see two ways round it.
> [useful technical discussion snipped]
> The more I think about my idea, the more I like it. ;) It allows people
> to use better quality samples than would otherwise be possible; it allows
> people to reduce the size of the Blorb files (by removing redundant
> samples); and allows people to reuse the code they'll already have for
> loading simple samples to load the samples for the MOD, possibly with a
> small amount of extra processing.

Ok. For the record, this is actually two ideas (keeping the samples
separate from the song data, and allowing samples to be in formats other
than the 8-bit one used in MOD files.)
 
> All this for a small amount of extra work in the Blorb compiler (which
> may not even be necessary if enough MOD-saving programs support the song
> format). This is of the order of 10 lines of code, much of which would be
> in the player anyway. When is a choice ever so clear? ;)

I'm definitely convinced about the idea keeping the samples separate. 
(BTW, it's obvious that the samples would be AIFF resources in the Blorb
file, right? With resource numbers not used by the game file.) (Well,
probably not used. I suppose the game *could* use a piano "plonk" as a
sound effect as well as a music note. :)

The format idea sounds good, and I agree with your [snipped] technical
comments. But someone should try actually making some modified MOD code
work before we take any decision as final. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Sep 22 17:10:06 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 20 Sep 1997 10:49:43 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom16
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <19970919214302.AAA24954@jokisch>
Message-Id: <Pine.SUN.3.95.970920102118.28694A-100000@netcom16>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 17356dff5f9f87fb33abe54086f0fa46

On Fri, 19 Sep 1997, Stefan Jokisch wrote:

> [Andrew Plotkin on my proposal for a separate "music" opcode:]
> 
> > Music is a sound effect. What do you want to do with music? Play some,
> > play some on repeat, or change the volume. And possibly pre-load it,
> > for efficiency. This is what SOUND_EFFECT does. I don't see any
> difference
> > between sound intended to be melodious and backgroundy and sound intended
> > for, well, any other purpose. 
> 
> Sound effects and music are technically different for the interpreter
> who implements them, and for the author who creates them.

The status window and the story window are technically different, and the
ability to print text to a memory array even more so. But the print
opcodes are used for all of them.

>  We might
> want to change the specification of SOUND_EFFECT to allow several
> sound effects at the same time, but we certainly wouldn't want more
> than one MOD (or MIDI?) piece at a time.

How certain are you?

>  Our definition of what can
> be played at the same time would be much simpler if we had separate
> opcodes for music and sound effects.

I think the *interface* for that operation should be made fully general,
even if we "really" know that only one music track will be playing at a
time. That's the best way to avoid having to change it again later.
 
> Furthermore, I doubt it makes sense to pre-load a piece of music the
> same way you pre-load a sample.  The latter might be needed for, say,
> a Z-code version of Space Invaders, when the explosion sounds mustn't
> be delayed by tenths of a second.  Starting a piece of music usually
> isn't that urgent.

You're making way too many assumptions here. Loading music can be a fairly
lengthy operation, since it involves many samples. Pre-loading is well
within the realm of what an author *might* want to do.

>  And you don't need to keep a piece of music in
> memory once it's finished, thus the SOUND_EFFECT operation #4 (finish
> with sample) doesn't make sense with music, either. 

Maybe. Probably, in fact, since the music itself is fairly short compared
to the note samples, and the note samples are likely shared between
different music pieces. But that's maybe and probably, and the efficiency
of how music is loaded and run is OS-dependent. 

> Finally, a new opcode would help Inform to detect music support, and
> so Inform would be able to set our new "music flag" automatically.

I never was that thrilled with the compiler-on-interpreter-off method of
header flags. If there was a music flag, I'd say just have the interpreter
set it "yes" if music can be played, "no" if not. The initial value
(compiled in by Inform) is always zero, and ignored.

> And we certainly want a new header flag, right?

You may recall that I wasn't certain even of that. I thought it was
probably a useful idea, too useful to leave out -- but it deserved a lot
of heavy argument, like any other change to the Z-machine definition. 

I don't *want* to propose a change to the Z-machine. I want to propose a
possible sound format, just as Blorb already contains an image format
(PNG) which has no impact on the Z-machine at all. It fits within the
sound_effect opcode syntax; it seems to me that it fits within the
sound_effect opcode *semantics*, since sound is sound. Purpose and intent
is the author's problem.

The issue of more than one sound at a time means that we'd probably need
*some* kind of Z-machine change. But I would be much happier if that was
encapsulated as "playing more than one sound at a time". More general, as
I said. In fact that can encompass the music-available header flag as
well. Say, a two-word header field which gets filled in "1, 3" if the
interpreter can play one music sound and three sampled sounds at a time;
or "-1, 4" if the interpreter can play 4 sounds total at a time,
regardless of how many are music. If the interpreter doesn't fill in
anything, of course, we assume "0, 1". 

Or maybe a new opcode to set channels, or sound-replacement priorities.
Various ways to handle it. But that's what I'm thinking.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Sep 22 17:10:19 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
Date: Sun, 21 Sep 1997 04:09:46 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19970921132241.AAA3791@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c65dd1fee65bb3ac881de15d84ce0ace


Andrew Plotkin wrote:

> I never was that thrilled with the compiler-on-interpreter-off method of
> header flags. If there was a music flag, I'd say just have the interpreter
> set it "yes" if music can be played, "no" if not. The initial value
> (compiled in by Inform) is always zero, and ignored.

The flags are useful to me. For instance, if the sound flag is set, DOS
Frotz reserves memory for sample data which would otherwise be used for
multiple undo. If the mouse flag is set, DOS Frotz activates the mouse
driver (if it is available) and turns the mouse pointer on. If the
graphics flag is set ("Beyond Zork"), DOS Frotz defaults to a graphics
mode that makes it possible to print font #3. If the undo flag is clear,
an interpreter need not allocate memory for an undo buffer (though it
should do because of early Inform files). Even the colour flag may be
important to interpreters that otherwise prefer a monochrome video mode.

Anyway, I don't think I have the time to implement the Blorb format. I
can see a demand for images and sounds in Inform games, though, and the
next release of Frotz hopefully provides a simple mechanism to include
PNG and WAV/AIFF files. This will be quite restrictive, e.g. all images
must have 256 colours and must be laid out for a resolution of 640x400.
Nevertheless, Frotz will grow in size, and its next version will need a
386+ to run.

-- Stefan
 

From ???@??? Mon Sep 22 17:10:16 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sun, 21 Sep 1997 09:59:19 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] "Blorb" sound format again
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.SUN.3.95.970920102118.28694A-100000@netcom16>
Message-Id: <Marcel-1.26-0921085919-b49M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c939eaad0a43f65c22be21361d8dfa74

On Sat 20 Sep, Andrew Plotkin wrote:
> ...
> I don't *want* to propose a change to the Z-machine. I want to propose a
> possible sound format, just as Blorb already contains an image format
> (PNG) which has no impact on the Z-machine at all. It fits within the
> sound_effect opcode syntax; it seems to me that it fits within the
> sound_effect opcode *semantics*, since sound is sound. Purpose and intent
> is the author's problem.

I entirely agree, and I think we should try hard to make Blorb compatible
with the existing Z-machine standard (1.0).  The whole idea of Blorb was,
indeed is, to supplement and assist the existing Z-machine, in a way
which would be simple for all parties to introduce.  I'm loath to force
people into a Z-machine 1.1, with all the debate and fuss that would mean,
for relatively little gain.

Similarly, I'm a little reluctant to see Blorb use a form of, say, MOD
which is unique to Blorb: the whole idea was to move to a standard and
established format.  And the perfect can be the enemy of the good.
Clearly the Z-machine _could_ be given a speech synthesiser, a MIDI
sequencer, a drum-kit, etc., but the idea of Blorb is to enable us to
use what it already has, which will be quicker and easier.

As to the point about wanting sound and effects simultaneously, couldn't
we just say to authors that if you start a MOD sound effect (and you'll
know which is which, because you're creating them) then it may carry
on playing until explicitly "finished"?  And I can certainly live with
not having two music files playing simultaneously.

Perhaps Andrew would like to draft a version of Blorb which incorporates
the AIFF stuff and offers some guidance on what to do with MOD or MIDI?
And then we can see how much that would be missing out on.  I suspect
not very much.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Tue Sep 23 21:00:28 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
Date: Mon, 22 Sep 1997 22:09:20 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19970922203721.AAA15708@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b0fbf20708013c14c55c730c0dbe75d5


Graham Nelson wrote:

> ...I think we should try hard to make Blorb
> compatible with the existing Z-machine standard (1.0).  The whole
> idea of Blorb was, indeed is, to supplement and assist the existing
> Z-machine, in a way which would be simple for all parties to
> introduce. 

*GASP*  HE DARES TO CALL THIS "_SIMPLE_ FOR _ALL_ PARTIES"!

> Clearly the Z-machine _could_ be given a speech synthesiser, a MIDI
> sequencer, a drum-kit, etc., but the idea of Blorb is to enable us
> to use what it already has, which will be quicker and easier.
 
%#@?*!  HE EVEN SPEAKS OF "_QUICK_" AND "_EASY_"!  ARGH!!!

THIS IS... [several paragraphs censored] ...LOOK AT WHAT POOR ME MUST
DO TO SUPPORT THIS [censored] FILE FORMAT UNDER THAT [censored] DOS!


(1) Say goodbye to my C compiler

    Infocom's sounds are restricted in size to 64KB, and thus I can
    afford to hold them completely in memory. The new sound format is
    unrestricted in size. This would either require some complicated
    double buffering method (i.e. load the next part of sample data
    while the current one is being played) or more memory. Now, we're
    talking about MS-DOS, and memory is usually limited to 600KB or
    so. The best way to get rid of this limitation is a 32-bit
    compiler like DJGCC.

    More memory is also needed to incorporate the PNG library, which
    makes my executable grow by roughly 200%.

(1)(a) download DJGCC
(1)(b) install DJGCC
(1)(c) get familiar with it
(1)(d) find some editor or IDE to use with it
(1)(e) get familiar with the above
(1)(f) re-write the DOS front end for use with DJGCC

(2) Support Blorb file structure

(2)(a) download Blorb specification
(2)(b) read it
(2)(c) write code to load any desired chunk

(3) Support PNG file structure

(3)(a) download PNG specification and libary
(3)(b) read PNG specification for an overview
(3)(c) compile and install PNG library
(3)(d) read PNG library documentation
(3)(e) download zlib library
(3)(f) compile and install zlib libray
(3)(g) write code to load a picture using PNG library

(4) Use SVGA video modes

    Frotz currently supports up to 14 colours for pictures - not        
quite sufficient...

(4)(a) download VESA specification (1.2 or 2.0 or 3.0?)
(4)(b) read it
(4)(c) write low-level code for scrolling/erasing areas
(4)(d) write low-level code printing characters
(4)(e) write low-level code for getting the colour of a pixel
       (colour -1)

    ...and find a way to squeeze that colour value into the Z-machine
    window properties...

(4)(f) write low-level code for displaying bitmaps
(4)(g) repeat steps (b) to (f) for all bits-per-pixel-types supported
(4)(h) search Internet for a mouse driver

    ...as standard drivers don't support SVGA video modes.  If this
    succeeds, then:

(4)(i) read its documentation
(4)(j) link it into the program

    Otherwise goodbye mouse support.

(5) Complete support for paletted SVGA modes (8BPP)

(5)(a) search Internet for an ideal 256 colour palette
(5)(b) map arbitrary 24/48 bit RGB values onto this palette

(6) Complete support for non-paletted SVGA modes (16/24BPP)

    The following is only necessary for running Infocom's own games
    in non-paletted modes.  This raises some problems; for example,
    borders in 'Arthur' change colours with the current picture.

(6)(a) research how some pictures affect other pictures on the screen
(6)(b) provide code that automatically re-draws affected pictures

(7) Scale pictures

(7)(a) dig out that info on Rothstein codes
(7)(b) implement scaling algorithm

    Sure, there are better ways to scale a picture, don't tell me.

(8) Support AIFF (or WAV) file structure

(8)(a) download specification of sound format
(8)(b) read it
(8)(c) write code to load a sample

(9) Play 16bit or stereo samples (are these supported by AIFF?)

(9)(a) dig out info on Soundblaster 16 registers
(9)(b) implement code for 16bit and/or stereo samples

(10) Support MOD/MIDI file structure

    Far too horrible to list.

(11) Combine above ingredients

    Still a lot of work to be done.  New switches to select the new
    video modes, #ifdefs to exclude multimedia stuff from text-only
    Frotz ports, longer manual etc.


I'd be grateful for any hints on (1)(d), (4)(h), (5)(a) and (5)(b).

-- Stefan

From ???@??? Thu Sep 25 22:00:09 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 22 Sep 1997 21:40:28 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom19
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "Blorb" sound format again
In-Reply-To: <19970922203721.AAA15708@jokisch>
Message-Id: <Pine.SUN.3.95.970922213527.28605D-100000@netcom19>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: acad3301132fa9adf086ba171c6f7ade
Status: U

On Mon, 22 Sep 1997, Stefan Jokisch wrote:

> *GASP*  HE DARES TO CALL THIS "_SIMPLE_ FOR _ALL_ PARTIES"!

We're all evil geniuses in this pack. MUA-HA-HA-HA!

Discussion has more or less ceased, I see, so I'll write up some spec this
week. I'm willing to accept Graham's hack that sampled sound can overlay
music, and music is interrupted only by other music... on the condition
that we get back to this later. Z-machine header flags for music would be
nice. A more complete Z-machine API for overlaying and interrupting sounds
would be even better. For now, we'll default to something cheap and
reasonable.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Thu Sep 25 22:00:11 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <c=US%a=ATTMAIL%p=HOECHST%l=BRW-EXC-03-970923134134Z-9006@brw-exc-02.bridgewater.ne.hcc.com>
From: "Kennedy, John ,HiServ/NA" <JKENNEDY@himail.hcc.com>
To: "'z-machine'" <z-machine@gmd.de>
Subject: [z-machine] Further emendation to ZIP base code
Date: Tue, 23 Sep 1997 09:41:34 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 21 TEXT
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e4cee30e5ce5abf72f844a101e5e727b
Status: U

Andrew Plotkin's change to get_line and tokenize seems to require this
further change in osdepend.c

In routine get_file_name, find line

    strcpy (file_name, (h_type > V4) ? &buffer[2] : &buffer[1]);

and replace it with

    if (h_type > V4) {
       memcpy (file_name, &buffer[2], buffer[1]);
       file_name[buffer[1]] = '\0';
    } else
       strcpy (file_name, &buffer[1]);

This is not the result of extensive study of the code or of expertise in
ZIP
(although I'm slowly developing something like the latter).  While I am
quite
certain that this patch is correct, it may not be the only domino in the
train.

From ???@??? Thu Sep 25 22:00:23 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom2.netcom.com: erkyrath owned process doing -bs
Date: Tue, 23 Sep 1997 10:40:46 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom2
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Further emendation to ZIP base code
In-Reply-To: <c=US%a=ATTMAIL%p=HOECHST%l=BRW-EXC-03-970923134134Z-9006@brw-exc-02.bridgewater.ne.hcc.com>
Message-Id: <Pine.SUN.3.95.970923102054.20547B-100000@netcom17>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3dcdc1b4a8f50f3124ebac668ebc0322
Status: U

On Tue, 23 Sep 1997, Kennedy, John ,HiServ/NA wrote:

> Andrew Plotkin's change to get_line and tokenize seems to require this
> further change in osdepend.c
> 
> In routine get_file_name, find line
> 
>     strcpy (file_name, (h_type > V4) ? &buffer[2] : &buffer[1]);
> 
> and replace it with
> 
>     if (h_type > V4) {
>        memcpy (file_name, &buffer[2], buffer[1]);
>        file_name[buffer[1]] = '\0';
>     } else
>        strcpy (file_name, &buffer[1]);
> 
> This is not the result of extensive study of the code or of expertise in
> ZIP
> (although I'm slowly developing something like the latter).  While I am
> quite
> certain that this patch is correct, it may not be the only domino in the
> train.
 
I haven't looked through the original ZIP code for a while. The problem is
that I changed get_line() to fill the buffer properly according to
z-machine version: null-terminated in V1-4, length-byte in V5+.
get_file_name() calls get_line(), so it has to be jiggered. Any other
place that calls get_line() also has to be jiggered. I think that will
cover it.

(I didn't catch this in MaxZip because I'm not calling get_line() for the
file name; I'm calling the Mac file dialog routines.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Sat Sep 27 15:46:28 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 25 Sep 1997 09:20:11 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Query from a blind PC user
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <199709250039.RAA10829@ccibsd.cci-internet.com>
Message-Id: <Marcel-1.26-0925082011-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d91468fa6392cd3abc6aa4e930897793
Status: U


I would very much like it if we could help Mr de Lioncourt.  Would
someone who knows about PCs be good enough to look into the matter?

There really are blind IF players: I once received a rather moving
letter from a player of Curses who was both blind and deaf, and
was playing by braille.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom
---------- Forwarded message ----------
Date: Wed, 24 SEP 1997 17:33:30 -0700
From: Josh de Lioncourt <lion99@celeritysystems.com>
To: graham@gnelson.demon.co.uk
Subject: Good day

Good day to you...	
  I am a blind fan of adventure games...have been playing them for
years...have written a few and am now sitting down to write some with the
help of Inform...
  I am in need of some assistance regarding an interpreter...
  The adventure games...especially those originally made by Infocom and the
like, are excessively popular among blind users of a palmtop specificly
designed for use by a vision impaired person...however, other than the
"enchanter.com" and "sorcerer.com" files which I can't get to run any story
files but their own, I can not find a suitable interpreter...none of the
ones in the IF-Archive at ftp.gmd.de work...
  It needs to be VERY VERY basic...and write to the bios...something for an
old-fashioned PC running DOS basically.  If you could help with this is
would be very very much appreciated.
   Thank you for your time,
      Josh


From ???@??? Sat Sep 27 15:46:36 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 25 Sep 1997 11:02:17 -0700
X-Sender: mattack@mail.apple.com
Message-Id: <v01550101b04ff46ad5bc@[17.202.20.138]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: z-machine@gmd.de
From: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] Query from a blind PC user
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b40041c69ec3224c0ea73b1c1486c752
Status: U

>  It needs to be VERY VERY basic...and write to the bios...something for an
>old-fashioned PC running DOS basically.  If you could help with this is
>would be very very much appreciated.


Hmm, isn't there a DOS based FROTZ or ZIP?


But I'm curious.. Does anybody know how this type of interpreter or a
player using this interpreter would deal with the status line?  (I would
presume something like Beyond Zork would be basically un-playable..)  But
you even need/want the current room you're in..  and I don't quite see how
a braille pad could do this..  or even a talking interpreter might get
"confused".

--
mattack@apple.com


From ???@??? Sat Sep 27 15:46:56 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Query from a blind PC user
Date: Fri, 26 Sep 1997 11:53:00 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19970926121619.AAA23994@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 2818558d42acac48716e83acd79d96a4
Status: U


I've mailed Josh a response that recommended DOS Frotz. :-)

I don't know exactly how Braille readers work, but several
blind users told me that DOS Frotz cooperates pretty well.
Unlike Jzip (*), DOS Frotz uses BIOS calls to print to the
screen in text mode. I believe Braille reader software is
smart enough to display only new lines of text; the status
line (== the part of the screen which never gets scrolled,
similar to menu bars) might be detected as such and won't
be displayed on the Braille reader unless the player tells
the software to do so. (In case of programs which write to
the hardware directly, the blind user would have to scan
the screen line by line searching for the start of the new
text.)

Beyond Zork shouldn't be a problem. By default, DOS Frotz
will run this game in graphics mode, but it can be forced
to text mode using the -d1 switch. The game itself can be
set to a "plain" screen layout by typing MODE. A similar
strategy works for Arthur, the only V6 game that runs in
text mode. (Actually, since Infocom's own V6 interpreters
for DOS have no text mode, blind users were unable to play
Arthur before.) Another difficulty for blind users is that
many Infocom games cannot be solved without clues from the
documentation. Luckily, I have a collection of ASCII files
that cover the vital bits for most games.

-- Stefan

(*) Jzip uses CONIO routines from the Borland C library.
    I'm a bit confused since these routines should use
    BIOS calls by default unless "directvideo" is set to
    non-zero.

From ???@??? Sun Sep 28 09:12:27 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 27 Sep 1997 11:02:54 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] MOD and "Blorb"
In-Reply-To: <m0xC3dL-000FayC@kea.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.970927102052.1550A-100000@netcom20>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9d0aa41d9967a14f5cce14f69a138ba9

On Fri, 19 Sep 1997, Martin Frost wrote:

> Andrew Plotkin wrote:
> 
> >Does the typical MOD composition tool allow you to write out songs in this
> >format? In other words, can authors actually generate this stuff?
> 
> All versions of Protracker that I know of on the Amiga can, and the couple
> of PC-based Protracker clones all can. The format originated as a typical
> composition will have the fixed 1084 byte header, followed by twenty to
> thirty 1024 byte patterns repeated in various ways, followed by anything
> up to the order of 300K of samples. Clearly, a 20-30K file is preferable
> to a 320-330K one when composing, especially off floppies.

I grabbed the two most complete Mac MOD-composition apps and started
looking at them. I don't believe either of them supports songs
(the no-samples format.) Given that, and some comments that modules
(songs-plus-samples) are much more widely used, I think it's necessary to
support modules.

I'm willing to support songs as well, but again, the MOD-playing libraries
I found for the Mac don't handle them. And I couldn't find any MOD source
code on Mac archives. Can you point me at some? (Preferably C; I don't
want to spend the next week translating 68000 assembly. :-) 
 
If I can fool around with that, and make it work on songs and on different
sample formats, then we can have source code samples and it will all work
nicely. However, the Mac MOD libraries I've got seem to be completely
black-box; as they stand I can't do anything to the initialization code,
much less screw with the sample formats which the engine uses. 

> Stripping the samples out is trivial too: it requires a piece of code
> snipped from the initialisation routine of the playroutine which finds
> the first sample.

Yes, got that. 
 
> Protracker 2.3 is actually more recent than the most portable version,
> which is the 2.0 release. However, as long as we restrict ourselves to
> MODs with only 64 patterns (ones with the magic word being 'M.K.' rather
> than 'M!K!') it should be OK. (I'm thinking here more of easy
> availability of playroutine source. If people are happy to modify
> existing players to handle the >64 pattern versions I have no
> fundamental objections). ;)

*I'm* happy to. Dunno about anyone else. (But it looks like the format is
otherwise identical, right? If it's 'M!K!' then there may be up to 128
patterns, but everything in else in the spec stays the same. That should
be easy to deal with.)

I think we can live without MAD, MED, OKTA, and whatever the hell all
these other thingies are. That limits us to four notes at a time, but I
can survive.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sun Sep 28 13:57:33 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 27 Sep 1997 20:27:54 -0500 (CDT)
From: Michael Alexander Cumings-Steen <macuming@gloria.cord.edu>
Reply-To: Michael Alexander Cumings-Steen <macuming@gloria.cord.edu>
To: Z-machine <z-machine@gmd.de>
Subject: [z-machine] [zmachine] Help: Apple// Infocom Interpreter
Message-Id: <Pine.BSI.3.95.970927201207.18789A-100000@gloria.cord.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c55963f3c4ba676e4d96d4d9d8548a63

Ever since I bought _Masterpieces_, I dreamed of playing them on my
Apple //e as God intended, and after having a great deal of fun mucking
about with the means of transferring files from the internet to my
//e, I thought the InfocomPro collection on ftp.gmd.de might help me
out.  I think that I'm on track, but need help with a simple step.
I quote from the docs of the package:


Once you've located a game disk with Interpreter B, boot it, and when the 
game asks "80 COLUMNS (Y/N)?", press reset.  Move 800.8FF temporarily 
with *4000<800.8FFM (the asterisk indicates that this command should be 
typed from the monitor), boot a DOS 3.3 disk without a hello program, 
restore 800.8FF with *800<4000.40FFM, and save the interpreter to disk 
with "BSAVE INTERPRETER,A$800,L$1BE6".  Then use Copy ][ Plus to copy it 
over to a ProDOS disk.


I tried to follow these instructions as well as I could, but the 
Interpreter file (I think) still turns out bad, so I ask this question.  
What is in fact a DOS 3.3 boot disk without a hello program?  I've used 
INIT STARTUP with a one-line program '10 END'; is this kosher, or is a 
hello program any startup program?  Or am I on the wrong track
altogether?

Also, if I do get this working, would I be able to use Inform games with
this Interpreter B direct from Infocom? 

Try to help a newbie out on this one, I'm confused.

Thanks,
Mike

Michael Alexander Cumings-Steen             Senior, Concordia College
   Orare est laborare,                 Joshua 1:8--Revelation 3:20
   laborare est orare.                 2 Timothy 3:16-Isaiah 41:10
This message brought to you via a *sweet* Apple //e--A dream machine!


From ???@??? Sun Sep 28 15:57:24 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom8.netcom.com: erkyrath owned process doing -bs
Date: Sat, 27 Sep 1997 20:15:27 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom8
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [zmachine] Help: Apple// Infocom Interpreter
In-Reply-To: <Pine.BSI.3.95.970927201207.18789A-100000@gloria.cord.edu>
Message-Id: <Pine.SUN.3.95.970927201105.9568D-100000@netcom8>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6922ceb2733062b1b6dbbdee2a42be06

On Sat, 27 Sep 1997, Michael Alexander Cumings-Steen wrote:

> Ever since I bought _Masterpieces_, I dreamed of playing them on my
> Apple //e as God intended [...] 
> 
> Once you've located a game disk with Interpreter B, boot it, and when the 
> game asks "80 COLUMNS (Y/N)?", press reset.  Move 800.8FF temporarily 
> with *4000<800.8FFM (the asterisk indicates that this command should be 
> typed from the monitor), boot a DOS 3.3 disk without a hello program, 
> restore 800.8FF with *800<4000.40FFM, and save the interpreter to disk 
> with "BSAVE INTERPRETER,A$800,L$1BE6".  Then use Copy ][ Plus to copy it 
> over to a ProDOS disk.
> 
> I tried to follow these instructions as well as I could, but the 
> Interpreter file (I think) still turns out bad, so I ask this question.  
> What is in fact a DOS 3.3 boot disk without a hello program?  I've used 
> INIT STARTUP with a one-line program '10 END'; is this kosher, or is a 
> hello program any startup program? 

Maybe delete the STARTUP file after you format the disk? That should work;
BASIC programs are stored in memory at 800, so even your one-liner will
be overwriting some of the data. If there is no startup file at all I
think it will be ok. Or, at least, that's what the instructions imply.

> Also, if I do get this working, would I be able to use Inform games with
> this Interpreter B direct from Infocom? 
 
If the game's Z-machine version matches the interpreter's. I believe
Infocom's interpreters each only ran a single version (v3, 4, 5, or 6.) 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Oct 01 20:17:50 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199709291429.KAA25324@cow.chelmsford.com>
Comments: Authenticated sender is <jpenney@mail.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine List <z-machine@gmd.de>
Date: Mon, 29 Sep 1997 10:29:44 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] [Blorb] A question of machine types
Reply-To: jpenney@chelmsford.com
X-Confirm-Reading-To: jpenney@chelmsford.com
X-Pmrqc: 1
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v2.52)
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: bcf7486a523e5b4dfb3078849d5b457a

Hi,

	I've been thinking that maybe Blorb merits its own machine type number.  
As it stands Blorb has a few differences with that things always worked 
(variable screen size in V6, more than one sound at a time).  All of these 
seem to be differences in interpreter behaviour.  This made me think of the 
way the Dos Frotz can emulate Amiga mode, making the games behave as they 
would have on an Amiga.  The interpreter reports its machine number as 4 
(Amiga), instead of 6.  

	Some of the games have code to behave differently based on this 
number.  Try the "color" command in Beyond Zork in some of the different 
modes (Amiga and IBMPC modes have different pallet options, and in some a 
tech. nymph tells you that you can't do that).  Currently colour #10 
is different in Amiga mode than any other, and #11-#12 only exist in Amiga 
mode.  The V6 code I've written and tested with Frotz uses the machine 
type number to decide what colours are available.  Since Blorb 
interpreters will work slightly differently than interpreters designed by 
Infocom for any of the machines they supported, I feel it should have its 
own machine type number.  

Jay

/*-----------------------------------*--------------------------------*\
|JasonCPenney(jpenney@chelmsford.com)| http://www.cs.uml.edu/~jpenney/ |
| Xarton Dragon    --==<UDIC>==--    | (UFO 54-40, Wipers, Int-Fiction)|
*------------------------------------*---------------------------------*
|    "The trouble with computers of course, is that they're very       |
|                sophisticated idiots." -- The Doctor                  |
\*--------------------------------------------------------------------*/

From ???@??? Wed Oct 01 20:17:46 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xFdb8-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Mon, 29 Sep 1997 12:02:42 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Andrew Plotkin <erkyrath@netcom.com>
Subject: Re: [z-machine] MOD and "Blorb"
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d8e429b4a521e0d9914fae0f54f623cc

Andrew Plotkin wrote:

>On Fri, 19 Sep 1997, Martin Frost wrote:

>> Andrew Plotkin wrote:

[...]

>I grabbed the two most complete Mac MOD-composition apps and started
>looking at them. I don't believe either of them supports songs
>(the no-samples format.) Given that, and some comments that modules
>(songs-plus-samples) are much more widely used, I think it's necessary to
>support modules.

>I'm willing to support songs as well, but again, the MOD-playing libraries
>I found for the Mac don't handle them. And I couldn't find any MOD source
>code on Mac archives. Can you point me at some? (Preferably C; I don't
>want to spend the next week translating 68000 assembly. :-) 

I haven't got any for anything other than the Amiga, and that's all in
assembly. Since much of the playroutine is the effects handling, which
is very hardware-dependent, it wouldn't be much use to you, I'm afraid.

>If I can fool around with that, and make it work on songs and on different
>sample formats, then we can have source code samples and it will all work
>nicely. However, the Mac MOD libraries I've got seem to be completely
>black-box; as they stand I can't do anything to the initialization code,
>much less screw with the sample formats which the engine uses. 

One possible way would be to construct a temporary module file and then play
it. Simply concatenate the song data with the samples (converted to 8 bit
signed linear PCM, padded to be an even number of samples, first two bytes
zeroed) and pass the new temporary file to the player. If the player accepts
a module loaded into a memory buffer, it's even easier as you can bypass
the temporary file. I can write code to do this if it is required.

>> Protracker 2.3 is actually more recent than the most portable version,
>> which is the 2.0 release. However, as long as we restrict ourselves to
>> MODs with only 64 patterns (ones with the magic word being 'M.K.' rather
>> than 'M!K!') it should be OK. (I'm thinking here more of easy
>> availability of playroutine source. If people are happy to modify
>> existing players to handle the >64 pattern versions I have no
>> fundamental objections). ;)

>*I'm* happy to. Dunno about anyone else. (But it looks like the format is
>otherwise identical, right? If it's 'M!K!' then there may be up to 128
>patterns, but everything in else in the spec stays the same. That should
>be easy to deal with.)

As far as I can tell, yes. I was never sure why the format was restricted
to 64 patterns anyway. It allows one very small optimisation in the
playroutine which hasn't been used in any players since the original
SoundTracker 1.0 routine, (generally pretty poor (15 instruments and about
3 effects)). Any decently-written playroutine *should* be able to handle
the 128-pattern version without change. It is just a case of ensuring that
arithmetic is done with sufficient headroom (16 bits is not sufficient even
unsigned, as 128 patterns == 128 kb).

The problem is if people are forced to use `black box' playroutines they
cannot modify them easily.

Martin

From ???@??? Wed Oct 01 20:18:13 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199709291930.PAA29699@cow.chelmsford.com>
Comments: Authenticated sender is <jpenney@mail.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: z-machine@gmd.de
Date: Mon, 29 Sep 1997 15:30:23 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] [Blorb] A question of machine types
Reply-To: jpenney@chelmsford.com
Priority: normal
In-Reply-To: <m0xFl0w-000FayC@kea.doc.ic.ac.uk>
X-Mailer: Pegasus Mail for Win32 (v2.52)
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a45ef7423d6c53bf6e55f41c6805a8c5

On Mon, 29 Sep 1997, I (Jason C Penney) wrote:
> I've been thinking that maybe Blorb merits its own machine type
> number.
	[snip a bunch of stuff]

Andrew Plotkin replied with:
> Final note: It is, in any case, a bad idea to group all the Blorb
> proposals together with a single flag saying "This interpreter is
> reading from a Blorb file." They are separate Z-machine changes, and
> should be dealt with one at a time. It may be appropriate to have a new
> header flag for the music capacity, but leave the image-scaling
> situation alone.
 
And then Martin Frost stated:
> I think you may have misunderstood what was intended. To me, it looked as
> though he was suggesting a special interpreter version number, to block
> the special machine-dependent behaviours which currently plague V6 
> games. It is meaningless for a fully Blorb-compliant interpreter to claim 
> to be interpreter number 4 (Amiga), for example, as the game may then do
> special Amiga-specific things, such as assuming that all the text will be
> drawn in certain colours when there are pictures on the screen. (I
> believe this to be true for Zork Zero).
 
> The point is not to let the game know that it is running under Blorb as
> much as to make sure old games do *not* know what they are running on,
> and hopefully force them to assume there are no limitations on what can
> be done.
 
[bit about beyond zork sniped] 
> I think it would be useful to use a new number, say either 0 or 255, for
> `this interpreter does not require or seek special treatment in any way'.


And here comes the new bit:

	Mr. Frost is correct as to what my intentions were.  Let's say Frotz 
never implements anything besides reading the Blorb data and using it in 
PC or Amiga mode.  I'm writing a V6 game, and I find a few tweaks that 
make the game look nicer in Frotz Amiga mode, since it isn't fully 
supporting all the other Blorb stuff.  I need my _code_ to know if it's 
running in Amiga mode or not.  Currently I check the machine type header 
flag, but what if some other interpreter, ZMint, has full scaling Blorb 
support, but sets the machine type to Amiga?  Bah!!!

	I was also trying to point out that there are currently at least two
different v6 pallets used by @set_colour x.  I think it would be nice to 
know two fully Blorb compliant interpreters would use the same pallet.

Jay

/*-----------------------------------*--------------------------------*\
|JasonCPenney(jpenney@chelmsford.com)| http://www.cs.uml.edu/~jpenney/ |
| Xarton Dragon    --==<UDIC>==--    | (UFO 54-40, Wipers, Int-Fiction)|
*------------------------------------*---------------------------------*
|    "The trouble with computers of course, is that they're very       |
|                sophisticated idiots." -- The Doctor                  |
\*--------------------------------------------------------------------*/

From ???@??? Wed Oct 01 20:18:00 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: King Dale <KingD@rnd1.indy.tce.com>
To: Z-machine <z-machine@gmd.de>,
        Michael Alexander Cumings-Steen <macuming@gloria.cord.edu>
Subject: RE: [z-machine] [zmachine] Help: Apple// Infocom Interpreter
Date: Mon, 29 Sep 97 11:05:00 CST
Message-Id: <342FDFBA@MSMAIL.INDY.TCE.COM>
Encoding: 66 TEXT
X-Mailer: Microsoft Mail V3.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6aa20cf70b461e8a52141f172713b3d1


Instead of trying to get the images from your Masterpieces CD to your   
apple and build an apple 2 disk by hacking it together, it would probably   
be a lot easier to download the disk image used for the Apple 2 emulators   
and writing that to the disk. I'm not sure of the process here, but I   
know it can be done. So search the web for apple emulator and should be   
able to find the information to get these images to your Apple and use   
them. Here is one place to start:   
http://www.cs.uregina.ca/links/faq/alt.emulators/Apple_][_Emulator_Resourc  
es_Guide_1.3_(1_1)

Most of the infocom disk images can be found at:   
http://www.apple.asimov.net/site/images/games/adventure/infocom/ with a   
few in  http://www.apple.asimov.net/site/images/games/adventure/. This   
site also can be accessed through ftp to ftp.apple.asimov.net.

By owning the Masterpieces CD, I think that would give you the legal   
right to obtain these disk images and use them on your Apple, but I'm an   
engineer not a lawyer so what do I know? The Masterpieces CD at least   
gives you the needed documents to play the game.

 ----------
From:  Michael Alexander Cumings-Steen[SMTP:macuming@gloria.cord.edu]
Sent:  Saturday, September 27, 1997 8:27 PM
To:  Z-machine
Subject:  [z-machine] [zmachine] Help: Apple// Infocom Interpreter

Ever since I bought _Masterpieces_, I dreamed of playing them on my
Apple //e as God intended, and after having a great deal of fun mucking
about with the means of transferring files from the internet to my
//e, I thought the InfocomPro collection on ftp.gmd.de might help me
out.  I think that I'm on track, but need help with a simple step.
I quote from the docs of the package:


Once you've located a game disk with Interpreter B, boot it, and when the   

game asks "80 COLUMNS (Y/N)?", press reset.  Move 800.8FF temporarily
with *4000<800.8FFM (the asterisk indicates that this command should be
typed from the monitor), boot a DOS 3.3 disk without a hello program,
restore 800.8FF with *800<4000.40FFM, and save the interpreter to disk
with "BSAVE INTERPRETER,A$800,L$1BE6".  Then use Copy ][ Plus to copy it
over to a ProDOS disk.


I tried to follow these instructions as well as I could, but the
Interpreter file (I think) still turns out bad, so I ask this question.
What is in fact a DOS 3.3 boot disk without a hello program?  I've used
INIT STARTUP with a one-line program '10 END'; is this kosher, or is a
hello program any startup program?  Or am I on the wrong track
altogether?

Also, if I do get this working, would I be able to use Inform games with
this Interpreter B direct from Infocom?

Try to help a newbie out on this one, I'm confused.

Thanks,
Mike

Michael Alexander Cumings-Steen             Senior, Concordia College
   Orare est laborare,                 Joshua 1:8--Revelation 3:20
   laborare est orare.                 2 Timothy 3:16-Isaiah 41:10
This message brought to you via a *sweet* Apple //e--A dream machine!


From ???@??? Wed Oct 01 20:18:06 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom3.netcom.com: erkyrath owned process doing -bs
Date: Mon, 29 Sep 1997 11:09:01 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom3
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [Blorb] A question of machine types
In-Reply-To: <199709291429.KAA25324@cow.chelmsford.com>
Message-Id: <Pine.SUN.3.95.970929105358.18120A-100000@netcom3>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d6c821f404a7a502b5aee1093b1a47af

On Mon, 29 Sep 1997, Jason C Penney wrote:

> 	I've been thinking that maybe Blorb merits its own machine type number.  
> As it stands Blorb has a few differences with that things always worked 
> (variable screen size in V6, more than one sound at a time).  All of these 
> seem to be differences in interpreter behaviour.  This made me think of the 
> way the Dos Frotz can emulate Amiga mode, making the games behave as they 
> would have on an Amiga.  The interpreter reports its machine number as 4 
> (Amiga), instead of 6.  

First of all, remember that Blorb is a data storage format outside the
Z-machine. It's not really connected to the machine at all. You could
write an interpreter to support music without supporting Blorb; it would
load data from individual music files, the way Frotz loads from individual
sound files.

In any case: we've been careful to construct the default behaviors so that
existing games will work the same out of Blorb files as out of Infocom
data files: 
 
You can't have more than one sampled sound at a time, and existing games
only use sampled sounds. (Future Z-machine versions may allow more than
one sampled sound at a time; but the game will have to request this, so it
still won't happen to old games.)

The variable-size screen thing is also backwards-compatible. It
doesn't allow the user to resize the window while the game is
running; it allows for different *initial* screen sizes.

Journey and Zork Zero already understand different initial screen sizes.
If their images are transferred to a Blorb file (and correctly marked
"non-scalable"), then the behavior of a Blorb-compliant interpreter is the
same as Infocom's interpreters.

If you're asking for a way for the game to tell if it's coming from a
Blorb file, that's mostly taken care of. The @picture_data opcode tells
what size images will be compared to the main window; this includes any
scaling factors, which means the game has all the information it needs. 

There is currently (in the proposal) no way to tell if the interpreter
supports music. This is a flaw, but again, it may be changed in a future
Z-machine version.

Final note: It is, in any case, a bad idea to group all the Blorb
proposals together with a single flag saying "This interpreter is reading
from a Blorb file." They are separate Z-machine changes, and should be
dealt with one at a time. It may be appropriate to have a new header flag
for the music capacity, but leave the image-scaling situation alone.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Oct 01 20:18:09 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <m0xFl0w-000FayC@kea.doc.ic.ac.uk>
From: "Martin Frost" <mdf@doc.ic.ac.uk>
Date: Mon, 29 Sep 1997 19:57:50 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Andrew Plotkin <erkyrath@netcom.com>
Subject: Re: [z-machine] [Blorb] A question of machine types
Cc: z-machine@gmd.de
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f8c20df0f0484051a5e39b8f9b5cd88a

Andrew Plotkin wrote:
>On Mon, 29 Sep 1997, Jason C Penney wrote:

>> I've been thinking that maybe Blorb merits its own machine type number.

[...]

>Final note: It is, in any case, a bad idea to group all the Blorb
>proposals together with a single flag saying "This interpreter is reading
>from a Blorb file." They are separate Z-machine changes, and should be
>dealt with one at a time. It may be appropriate to have a new header flag
>for the music capacity, but leave the image-scaling situation alone.

I think you may have misunderstood what was intended. To me, it looked as
though he was suggesting a special interpreter version number, to block
the special machine-dependent behaviours which currently plague V6 games.
It is meaningless for a fully Blorb-compliant interpreter to claim to be
interpreter number 4 (Amiga), for example, as the game may then do special
Amiga-specific things, such as assuming that all the text will be drawn
in certain colours when there are pictures on the screen. (I believe this
to be true for Zork Zero).

The point is not to let the game know that it is running under Blorb as
much as to make sure old games do *not* know what they are running on,
and hopefully force them to assume there are no limitations on what can be
done.

A similar thing would be very useful for interpreters running Beyond Zork,
with its amazing (cough) font behaviour (witness the lengths Zip goes to
to handle BZ correctly with interpreter number 6 on non-PCs).

I think it would be useful to use a new number, say either 0 or 255, for
`this interpreter does not require or seek special treatment in any way'. ;)

Martin

From ???@??? Wed Oct 01 20:18:11 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom3.netcom.com: erkyrath owned process doing -bs
Date: Mon, 29 Sep 1997 12:27:49 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom3
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [Blorb] A question of machine types
In-Reply-To: <m0xFl0w-000FayC@kea.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.970929122202.9202A-100000@netcom3>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 04cb9ab5482f0f356aaaac00e035428d

On Mon, 29 Sep 1997, Martin Frost wrote:

> Andrew Plotkin wrote:
> >On Mon, 29 Sep 1997, Jason C Penney wrote:
> 
> >> I've been thinking that maybe Blorb merits its own machine type number.
> 
> [...]
> 
> >Final note: It is, in any case, a bad idea to group all the Blorb
> >proposals together with a single flag saying "This interpreter is reading
> >from a Blorb file." They are separate Z-machine changes, and should be
> >dealt with one at a time. It may be appropriate to have a new header flag
> >for the music capacity, but leave the image-scaling situation alone.
> 
> I think you may have misunderstood what was intended. To me, it looked as
> though he was suggesting a special interpreter version number, to block
> the special machine-dependent behaviours which currently plague V6 games.

Ah. Well, that's a reasonable idea, assuming that Infocom game files
really do react conservatively to an unknown interpreter number.

> It is meaningless for a fully Blorb-compliant interpreter to claim to be
> interpreter number 4 (Amiga), for example, as the game may then do special
> Amiga-specific things, such as assuming that all the text will be drawn
> in certain colours when there are pictures on the screen. (I believe this
> to be true for Zork Zero).

Blorbness per se is still irrelevant to this discussion. 

What you (someone) should do is go through the spec and the games, and
list all the places where an Infocom game assumes non-1.0-spec behavior.
(The text-color effect you mention is such a place.) Then make sure the
games *don't* assume such variances when the interpreter number is
unknown. 

Then we can say, ok, an interpreter which desires to ignore all the goofy
Infocom hacks is allowed to, as long as it writes in 255 (or whatever) as
the interpreter numbers. 

> I think it would be useful to use a new number, say either 0 or 255, for
> `this interpreter does not require or seek special treatment in any way'. ;)

"...and will not provide any."

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Oct 01 20:18:15 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <c=US%a=ATTMAIL%p=HOECHST%l=BRW-EXC-03-970929200142Z-31407@brw-exc-02.bridgewater.ne.hcc.com>
From: "Kennedy, John ,HiServ/NA" <JKENNEDY@himail.hcc.com>
To: "'z-machine'" <z-machine@gmd.de>
Subject: RE: [z-machine] [Blorb] A question of machine types
Date: Mon, 29 Sep 1997 16:01:42 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 5 TEXT
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b9fad27277da54b71989dcf5273ce16b

I don't really see what this extra type is good for.  Surely a game
will either have Blorb content or not.  If it does, it doesn't need
to be told so.  If it doesn't, it may not (i;e., all games up to the
time Blorb is introduced _will_ not), even consider the possibility.
Either way, it doesn't seem to have any point.

From ???@??? Wed Oct 01 20:18:36 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 30 Sep 1997 18:02:40 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Opcode queries
To: Z-Machine Mailing List <z-machine@gmd.de>,
        Bryan Scattergood <104312.2206@compuserve.com>
In-Reply-To: <199709290139_MC2-2226-70A@compuserve.com>
Message-Id: <Marcel-1.26-0930170240-313M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0270fc41d7474f603933eb6ae0112213

On Mon 29 Sep, Bryan Scattergood wrote:
> 
> I'm part way through the latest rewrite of an interpreter which started 
> out as the ITF source code, and a couple of minor issues have come to 
> light.
> 
> First, in the implementation of get_prop_len I have a patch that checks 
> for an argument of zero and stores zero as the result in this case.  
> (The argument in question presumably comes from get_prop_addr and means 
> 'no such property'.)  The code is commented as being a workaround for 
> Curses.  Can anyone remember which version had that problem?

Inform used to implement .# (the get property length operator)
by simply

            get_prop_addr obj prop -> sp
            get_prop_len sp -> sp

thus assuming that such a property was provided.  So the problem
isn't in "Curses" so much as in any story file surviving from the
very early days of Inform -- but that basically means "Curses",
as Inform didn't catch on until 5.5 or so.

Unfortunately I've lost my records of the early modification history
of Inform, and can't put my finger on the point where this bug was
fixed.  It may well be recorded in the Inform 5 "header.h" file,
which may well still be at ftp.gmd.de somewhere.  It's probably a
problem in the old Version 3 forms of "Curses", which are only half
the size of the final game, but are still played on machines too
small to accommodate a 256K story file:

                Release 7 / 930428   (the original and still the worst)
                Release 8 / 930603   (much enhanced, slightly larger)
                Release 9 / 931111   (extended by about 20%)
                Release 10 / 940120  (tidied up a little)

The bug is probably in some or all of those.

> Second, the ITF code had separate implementations for the Z4/Z5+ 
> versions of scan_table.  (The Z4 version omits the 'form' argument and 
> so always scans successive words.)  Unfortunately, the code has a 
> slight difference in that the Z4 version uses 32bit arithmetic when 
> offsetting into the table, while the Z5+ version uses 16bit arithmetic. 
> The Z-machine spec is unclear if scanning a table which crosses the 64K 
> boundary should (a) wrap back to zero, (b) scan addresses above the 
> boundary, or (c) be totally illegal.

I have no idea what the ideal behaviour is here.  My inclination
would be for (b), for safety reasons (some of Infocom's games do
have data tables lurking low in what we would call the "Z-code
area").  But I doubt if there is any existing game which requires
this.  Stefan?

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Wed Oct 01 20:18:40 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Opcode queries
Date: Wed, 1 Oct 1997 01:51:24 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19970930234657.AAA17860@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0bc5a6513fd0b4080e46d26154f74265


> Second, the ITF code had separate implementations for the Z4/Z5+ 
> versions of scan_table.  (The Z4 version omits the 'form' argument and 
> so always scans successive words.)  Unfortunately, the code has a 
> slight difference in that the Z4 version uses 32bit arithmetic when 
> offsetting into the table, while the Z5+ version uses 16bit arithmetic. 
> The Z-machine spec is unclear if scanning a table which crosses the 64K 
> boundary should (a) wrap back to zero, (b) scan addresses above the 
> boundary, or (c) be totally illegal.

In theory opcodes like LOADB or SCAN_TABLE could address up to 128KB,
but no game makes use of this, and it wouldn't make a good design.
Frotz uses a 16bit counter for all Z-code versions, and I expect that
Infocom's own interpreters do the same.

-- Stefan

From ???@??? Sat Oct 04 23:08:05 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 3 Oct 1997 10:25:24 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Blorb additions for sound
Message-Id: <Pine.SUN.3.95.971003102318.3113A-100000@netcom20>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 50199af1e3ffb22234bba2b531ee139f

Here's what I'm sticking in the Blorb spec:

-----------

* Sound Resource Chunks

Each sound is stored as one chunk, whose content is either an AIFF file, a
MOD file, or a song file. (Note that these are three possible formats for
a single resource. It is not possible to have an AIFF sound and a MOD
sound with the same sound resource number.)

An AIFF (Audio IFF) file has chunk type 'FORM', and formtype 'AIFF'. The
AIFF format is available at

http://www.mediatel.lu/workshop/audio/fileformat/aiff13/h_aiff13.html

A MOD file has chunk type 'MOD '. This is the Amiga-originated format for
music synthesized from note samples. The specification, such as it is, is
available in the files

http://hyperarchive.lcs.mit.edu/HyperArchive/Archive/gst/snd/mod-form.txt
http://hyperarchive.lcs.mit.edu/HyperArchive/Archive/gst/snd/mod-info.txt

For generality, MOD files in Blorb are limited to the ProTracker 2.0
format: 31 note samples, up to 128 note patterns. The magic number at byte
1080 should be 'M.K.' or 'M!K!'. 

A song file has chunk type 'SONG'. This is similar to a MOD file, but with
no built-in sample data. The samples are instead taken from AIFF sounds in
the resource file. For each sample, the 22-byte sample-name field in the
song should contain the string "SND1" to refer to sound resource 1,
"SND953" to refer to sound resource 953, and so on. Any sound so referred
to must be an AIFF, not a MOD or song. (You can experiment with fractal
recursive music on your own time.) Remember that sample-name strings are
null-terminated. 

Each sample record in a MOD or song contains six fields: sample name,
sample length, finetune value, volume, repeat start, repeat length. In a
MOD file, the sample name is ignored by Blorb (it is traditionally used to
store a banner or comments from the author.) In a song file, the sample
name contains a resource reference as described above; but the sample
length, repeat start, and repeat length fields are ignored. These values
are inferred from the AIFF resource.  (The repeat start and repeat length
are taken from the sustainLoop of the AIFF's instrument chunk. If there is
no instrument chunk, or if sustainLoop.playMode is NoLooping, there is no
repeat; the repeat start and length values are then considered zero.)

Note that an AIFF need not contain 8-bit sound samples, as a sound built
into a MOD would. A clever sound engine may take advantage of this to
generate higher-quality music. An unclever one can trim (or pad) the
AIFF's data to 8 bits before playing the song. In the worst case, it is
always possible to trim the AIFF data to 8 bits, append it to the song
data, fill in the song's sample records (with the appropriate lengths,
etc, from the AIFF data); the result is a complete MOD file, which can
then be played by a standard MOD engine. 

The intent of allowing song files is both to allow higher quality, and to
save space. Note samples are the largest part of a MOD file, and if the
samples are stored in resources, they can be shared between songs.
(Typically note samples will be given high resource numbers, so that they
do not conflict with sounds used directly by the game. However, it is
legal for the game to use a note sample as a sampled-sound effect, if it
wants.)

There are also the problems of how the game knows the interpreter can play
music, and how sampled sounds are played over music. See the section
"Z-Machine Compatibility Issues" later in this document. 

* Z-Machine Compatibility Issues

The image system presented in this document is fully backwards-compatible
with Infocom's interpreters. Infocom V6 games, such as Arthur, Journey,
and Zork Zero, contain only non-scalable image resources. The game files
are written to deal with both variations in window size and variations in
image size (since the interpreters for different platforms had different
window sizes and different art.) Therefore, if you construct a Blorb file
containing the images from a particular platform (say, the Mac) and give
it the suggested window size of the Infocom Mac interpreter, the game file
will deal with it correctly. 

The image system is also sort of forwards-compatible, in the following
sense. If you take a Blorb file whose standard (intended) window size is
the same as the Infocom interpreter's, and break it out into Infocom image
files, the Infocom interpreter should display it correctly. The
interpreter will not scale images, but since the window size is equal to
the standard size, the Blorb rules require the images to be displayed
unscaled anyway. 

Also, of course, if you take a Blorb file which contains only non-scalable
images, an Infocom interpreter will act correctly, since it will not scale
the images regardless of the standard size. 

The sound system is slightly more problematic. A game file can announce
that it uses sound, by setting a header bit; the interpreter can announce
that it does not support sound, by clearing that bit. But there is no way
to distinguish a game that uses sampled sound only, from one that uses
sampled sound and music.  (And similarly for the interpreter's support of
samples versus music.) This may be addressed in a future revision of the
Z-machine. In the meantime, games should set that header bit if any kind
of sound is used (samples or music or both.) And interpreters should clear
that bit only if *no* sound support is available. If the interpreter
supports sampled sound but not music, it should leave the header bit set,
announcing that it does "support sound." It should then ignore any request
to play a music resource. 

There is also the question of overlapping sounds. The Z-Spec (9.4.2) says
that starting a new sound effect automatically stops any current one. But
it is not desirable that a sound effect such as footsteps should interrupt
the playing of background music. Therefore, the interpreter should amend
this rule, and consider sampled sounds and music to be in seperate
"channels". Samples interrupt samples, and music interrupts music, but one
form of sound does not interrupt the other. 

This is an actual variance in the behavior of the Z-machine, and worse, a
variance which depends on data format. (One sound will either stop
another, or not, depending on whether the sound is stored in AIFF or MOD
format.) We apologize for the ugliness. 

Again, future versions of the Z-machine may address this issue, and allow
a more general system where any sound can be overlaid on any other sound,
or interrupt it, as the game desires and regardless of storage format.
(After all, there can be background *sounds* as well as background
*music*.) Such a system would also allow the interpreter to announce its
limitations and capabilities -- whether it can play music, whether it can
play two pieces of music at once, how many sampled sounds it can play at
once, etc. 

A final, ah, note: The remark at the end of Z-Spec chapter 9, about
sequencing sound effects to simulate the slow Amiga version of "The
Lurking Horror", should not be applied to music sounds. New music should
interrupt old music immediately, regardless of whether keyboard input has
occurred since the old music started. 

-----------

I have still not found (or heard of) any publically-readable source for
MOD playing, except for 68000 assembly. I may wind up writing some. In the
very indefinite future. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Sat Oct 04 23:08:20 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19971003141110.jholder@deimos.frii.com>
Date: Fri, 3 Oct 1997 14:11:10 -0600
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Blorb additions for sound
References: <Pine.SUN.3.95.971003102318.3113A-100000@netcom20>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <Pine.SUN.3.95.971003102318.3113A-100000@netcom20>; from Andrew Plotkin on Oct 3, 1997 10:25:24 -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5b271b9ccd195405413f09f968169a9e

Andrew Plotkin writes:
> I have still not found (or heard of) any publically-readable source for
> MOD playing, except for 68000 assembly. I may wind up writing some. In the
> very indefinite future. 

I invite you to check out:

ftp://ftp.cdrom.com/pub/demos/code/audio/

Enough code that we can probably get this all working.

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/

From ???@??? Sun Oct 19 16:23:51 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom8.netcom.com: erkyrath owned process doing -bs
Date: Sat, 18 Oct 1997 10:32:38 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom8
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Opcode queries
In-Reply-To: <Marcel-1.26-0930170240-313M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.971018101857.3807A-100000@netcom8>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 52371df0a2781759c0015e2c8596667a

On Tue, 30 Sep 1997, Graham Nelson wrote:

> > First, in the implementation of get_prop_len I have a patch that checks 
> > for an argument of zero and stores zero as the result in this case.  
> 
> Inform used to implement .# (the get property length operator)
> by simply
> 
>             get_prop_addr obj prop -> sp
>             get_prop_len sp -> sp
> 
> thus assuming that such a property was provided.  So the problem
> isn't in "Curses" so much as in any story file surviving from the
> very early days of Inform -- but that basically means "Curses",
> as Inform didn't catch on until 5.5 or so.

I'm encounting a similar problem with get_prop and put_prop. That is, some
games call them with a first argument of 0. That's the object number. In
other words, the Inform code is trying to do something with the properties
of the "nothing" non-object; essentially
  Property number; ! common property, not individual
  x = 0;
  y = x.number;
or
  x.number = y;

In dealing with crashes in the middle of the "Sylenius" competition entry,
I tried putting in tests for this error. Very simple tests -- at the
beginning of the "get_prop" opcode handler, I put "if (obj == 0) 
fatal_error();" and similar code for put_prop and get_prop_addr.

Lo, and behold, "Sylenius" threw this error at the *beginning*. So did
"Edifice". I haven't tried all the others. But apparently this kind of
game file error is not completely unknown.

I am very unhappy with this situation. 

I think we should either (A) declare this to be illegal, make all
interpreters throw a fatal error, and tell authors to fix their buggy
games, or (B) declare this to be legal, and make all interpreters accept
it. (@get_prop 0 always returning 0, and @put_prop 0 always doing
nothing.) 

I prefer A over B. But if we don't do either, there will be a steadily
increasing number of game files that do this, and which therefore do
strange things on some interpreters, including not work at all. And as
authors drift in and out of contact, it will be harder to make them fix
things. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Thu Oct 23 16:50:09 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 20 Oct 1997 06:33:27 +0100
X-Mailer: Virtual Access by Ashmount Research Ltd, http://www.ashmount.com
Message-Id: <VA.00000071.02d0eda0@butterfly.fsel.com>
To: z-machine@gmd.de
Cc: 104312.2206@compuserve.com
Subject: [z-machine] Beautifully simple
From: Bryan Scattergood <104312.2206@compuserve.com>
Reply-To: 104312.2206@compuserve.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f746e534f78fb505eb875b37c7608ccc

Across in raif, Andrew offered:

<< Heh. The central machine is beautifully simple -- that's how Graham 
is able to keep redesigning Inform without changing the binary game 
file format. >>

I'm going to take objection to the 'beautifully simple' in that 
sentence. The Z-machine may be well-documented, stable and effective, 
but surely not beautifully simple. To my eye it strongly resembles CISC 
chips like the Z80/8086: instructions bolted in because there were 
opcodes available.

With a light-weight call mechanism, a lot of the Z-machine 
functionality could be moved into a thin library layer with only 
minimal impact on the story-file size. For instance the object, 
property and tokenising routines could just as easily be implemented by 
library code as by the current opcodes. (Basic efficient arithmetic 
opcodes need to remain of course, as does an I/O model.)

Pure fantasy of course. The problem with the installed base means it 
could never happen, and the existence of the JVM makes redesigning the 
Z-machine from the ground up a dubious proposition.

    Bryan

PS: "The mountains are singing, and the Lady comes."  Susan Cooper? Not 
OSUS or TDIR which narrows it down to one of three ... all of which are 
hundreds of miles away.



From ???@??? Thu Oct 23 16:50:07 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 20 Oct 1997 01:36:13 -0400
From: Bryan Scattergood <104312.2206@compuserve.com>
Subject: Re: [z-machine] Opcode queries
To: "internet:erkyrath@netcom.com" <erkyrath@netcom.com>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Message-Id: <199710200138_MC2-2478-C3FB@compuserve.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f69d81c427ec4742fb15ca1f623203e5



Andrew,

<< I'm encounting a similar problem with get_prop and put_prop. That 
is, some games call them with a first argument of 0 ... I am very 
unhappy with this situation ... >>

<< I think we should either (A) declare this to be illegal, make all
interpreters throw a fatal error, and tell authors to fix their buggy
games, or (B) declare this to be legal, and make all interpreters 
accept it. >>

<< I prefer A over B. But if we don't do either, there will be a 
steadily increasing number of game files that do this, and which 
therefore do strange things on some interpreters, including not work at 
all. And as authors drift in and out of contact, it will be harder to 
make them fix things. >>

I agree that, in an ideal world, A would be the preferred solution. 
However, we have a choice between fixing the interpreters or fixing the 
game files.  The number of interpreter cores is still in single 
figures.  The number of games is well into three figures.  Most 
interpreters are still actively maintained.  The source for some games 
is no longer available.

I'm afraid we are probably stuck with B.

    Bryan

 

From ???@??? Thu Oct 23 16:50:19 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom10.netcom.com: erkyrath owned process doing -bs
Date: Mon, 20 Oct 1997 15:29:23 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom10
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Opcode queries
In-Reply-To: <199710200138_MC2-2478-C3FB@compuserve.com>
Message-Id: <Pine.SUN.3.95.971020152259.18185A-100000@netcom10>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c8b42db8f9d100ae59901f4ab73ae6d3

On Mon, 20 Oct 1997, Bryan Scattergood wrote:

> << I'm encounting a similar problem with get_prop and put_prop. That 
> is, some games call them with a first argument of 0 ... I am very 
> unhappy with this situation ... >>
> 
> << I think we should either (A) declare this to be illegal, make all
> interpreters throw a fatal error, and tell authors to fix their buggy
> games, or (B) declare this to be legal, and make all interpreters 
> accept it. >>
> 
> << I prefer A over B. But if we don't do either, there will be a 
> steadily increasing number of game files that do this, and which 
> therefore do strange things on some interpreters, including not work at 
> all. And as authors drift in and out of contact, it will be harder to 
> make them fix things. >>
> 
> I agree that, in an ideal world, A would be the preferred solution. 
> However, we have a choice between fixing the interpreters or fixing the 
> game files.  The number of interpreter cores is still in single 
> figures.  The number of games is well into three figures.  Most 
> interpreters are still actively maintained.  The source for some games 
> is no longer available.
> 
> I'm afraid we are probably stuck with B.

Your logic is lucid. :-) We'd better hear from all the interpreter-core
maintainers, though.

I certainly wouldn't go for option A any *later* than Jan 1, 1998. (It
couldn't be any earlier, because at least two competition games do
get_prop 0 or get_prop_addr 0, and competition games can't be updated
until the competition is over.) 

So we have about two months to argue about it, if nothing else.

To be formal, option B is to extend the Z-Spec to say that "get_prop 0 p" 
and "get_prop_addr 0 p" always return 0, regardless of what p is, and
"put_prop 0 p v" is legal and has no effect. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Thu Oct 23 16:50:22 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom15.netcom.com: erkyrath owned process doing -bs
Date: Mon, 20 Oct 1997 18:47:44 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom15
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Opcode queries
In-Reply-To: <Marcel-1.26-1021002621-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.971020182720.6157A-100000@netcom15>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 80c181ba29ec266dd4f4c18a8e54856c

On Tue, 21 Oct 1997, Graham Nelson wrote:

> On Mon 20 Oct, Andrew Plotkin wrote:
> > On Mon, 20 Oct 1997, Bryan Scattergood wrote:
> > 
> > > << I'm encounting a similar problem with get_prop and put_prop. That 
> > > is, some games call them with a first argument of 0 ... I am very 
> > > unhappy with this situation ... >>
> 
> As am I.  Does the fault belong to the Inform library, so far as
> we can tell?  If so, I would like to remove it.

It seems to occur in most of the library 6/7 game I try.  (AGB, Bear,
Edifice, ) But not every one. (Legacy, TDragon, and Mimesis are fine, at 
least at startup.) 

In particular, a "get_prop_addr 0 ..." opcode seems to occur sometime
after the opening banner is printed.

The same thing seems to happen in House, Pintown, and Sylenius, which are
6/6 games. And Reflect, which is 6/4. 

Clear as cocoa yet? You may want to compile your own interpreter with the
appropriate error-checking. 

> But what is the origin of the bugs in the competition games?  Do
> similar bugs proliferate existing Inform games?  I think we should
> be told...

All the 6/7 games I have are competition games, for obvious reasons. I
have not tried plowing through every Inform game I have lying around.

...but I have just tried starting up every Inform game I have lying around
-- mostly library 5 games. None of them displayed the same error on
startup. Of course I don't know whether it would occur during the course
of the game.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Thu Oct 23 16:50:34 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Opcode queries
Date: Tue, 21 Oct 1997 13:16:23 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19971021111145.AAA14554@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 17007ef384f36abcb09c88b3f4c5c8c5


Andrew Plotkin wrote:

> I'm encounting a similar problem with get_prop and put_prop. That is, some
> games call them with a first argument of 0. That's the object number. In
> other words, the Inform code is trying to do something with the properties
> of the "nothing" non-object; essentially
>   Property number; ! common property, not individual
>   x = 0;
>   y = x.number;
> or
>   x.number = y;
> 
> In dealing with crashes in the middle of the "Sylenius" competition entry,
> I tried putting in tests for this error. Very simple tests -- at the
> beginning of the "get_prop" opcode handler, I put "if (obj == 0) 
> fatal_error();" and similar code for put_prop and get_prop_addr.
> 
> Lo, and behold, "Sylenius" threw this error at the *beginning*. So did
> "Edifice". I haven't tried all the others. But apparently this kind of
> game file error is not completely unknown.
> 
> I am very unhappy with this situation. 

One or two years ago I made Frotz check for object #0. This didn't work
with "Curses" so I removed this check. A foolish decision! Now it's too
late, it seems every Inform game (except "Freefall") fiddles with object
#0 in a number of ways. (I suspect the Inform library itself contains
this bug.) Most popular are

  get_parent 0,
  jin 0 x,
  get_prop_addr 0 x

It's very sad but I think we need to define

  * object #0 has no parent/child/sibling
  * object #0 is not included in any other object (jin)
  * object #0 has no properties (get_prop_addr)

and modify appendix E of the Spec which suggests to report any access to
object #0 as an error.

However, I think we can consider the following operations illegal:

  * set_attr / get_attr / test_attr 0 x
  * get_prop / put_prop 0 x

At least one game ("Sylenius") won't pass this test, but if it's only a
few games then we can ask the authors to fix it.

We should be aware that legalizing error conditions makes writing games
*harder*, because some logical mistakes in the code remain unnoticed.

-- Stefan

From ???@??? Thu Oct 23 16:51:12 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Opcode queries
Date: Tue, 21 Oct 1997 15:28:29 +0200
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19971022142745.AAA25540@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 4fef9c2288f9afae30994df45e596c62


My collection of Inform games is a bit out-dated since I haven't
played Z-code games lately. Anyway, I checked a number of them.
The results are shown in the table below (I hope you view this
mail with a fixed with font).

Jin   == game tried @jin 0 x
GC    == game tried @get_child 0
GP    == game tried @get_parent 0
GS    == game tried @get_sibling 0
GPA   == game tried @get_prop_addr 0 x
GProp == game tried @get_prop 0 x
PProp == game tried @put_prop 0 x y
GA    == game tried @clear_attr 0 x
SA    == game tried @set_attr 0 x
TA    == game tried @test_attr 0 x
MO    == game tried @move_object 0 x or @move_object x 0
RO    == game tried @remove_object 0

                   Jin  GC GP GS  GPA  GProp PProp  CA SA TA  MO RO
------------------+---++--+--+--++---++-----+-----++--+--+--++--+--
Christminster R1  |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Spiritwrak R3     |   ||* |  |  ||   ||     |     ||  |  |* ||  |
Godot R1          |   ||* |  |  ||   ||     |     ||  |  |  ||  |
BSE R3            |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Inhumane R2       |   ||  |  |  ||   ||     |     ||  |  |  ||  |
Night at the... R1|   ||* |  |  ||   ||     |     ||  |  |  ||  |
Windhall Chron. R1|   ||* |  |  ||   ||     |     ||  |  |  ||  |
Vindaloo R1       |   ||  |* |  ||*  ||     |     ||  |  |  ||  |
Return to Karn R2 |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Museum of Infm. R1|   ||* |  |  ||   ||     |     ||  |  |  ||  |
Time R7           |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Ralph R6          |   ||  |  |  ||   ||     |     ||  |  |* ||  |  [1]
The Underoos...   |   ||  |* |  ||*  ||     |     ||  |  |  ||  |
Cheater R1        |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Tube Trouble R0   |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Magic Toyshop     |   ||* |  |  ||   ||     |     ||  |  |  ||  |
A Change In... R6 |   ||  |  |  ||   ||     |     ||  |  |  ||  |
Delusions R3      |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Competition 96 R1 |   ||  |  |  ||   ||     |     ||  |  |* ||  |  [1]
Adventure R5      |   ||  |  |  ||   ||     |     ||  |  |  ||  |
Quest for... R2   |   ||* |  |  ||   ||     |     ||  |  |  ||  |
All Quiet on... R1|   ||* |  |  ||   ||     |     ||  |  |  ||  |
The Meteor... R2  |*  ||  |* |  ||*  ||     |     ||  |  |  ||  |
Adventureland R1  |   ||  |  |  ||   ||     |     ||  |  |  ||  |
Freefall          |   ||  |  |  ||   ||     |     ||  |  |  ||  |
Curses R10        |   ||  |  |  ||   ||     |     ||  |  |  ||  |
Curses R16        |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Theatre R1        |   ||* |  |  ||   ||     |     ||  |  |  ||  |
So Far R5         |   ||  |* |  ||*  ||     |     ||  |  |  ||  |
Jigsaw R4         |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Balances R2       |   ||  |  |  ||   ||     |     ||  |  |  ||  |
Busted R3         |   ||  |  |  ||   ||     |     ||  |  |  ||  |
Frozen R1         |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Time Killer 1 R1  |   ||* |  |  ||   ||     |     ||  |  |  ||  |
Zork Underground  |   ||* |  |  ||   ||     |     ||  |  |  ||  |

[1] For these games, type "EAST" as first command.

Notes:

- All errors occured before the first input (except for the ones
  marked [1]).
- I checked a few Infocom games as well. They appeared to be OK.
- It's not clear how frequent errors occur during the course of a
  game. For instance, none of the games I checked tried to get_prop
  or put_prop 0 during startup. Nevertheless, Andrew reports this
  bug in the middle of "Sylenius".
- I still think interpreters should report GProp/PProp and CA/SA/TA
  and MO/RO as errors. (DOSFrotz has a command line switch to ignore
  run-time errors; buggy story files would still be playable.)
- Situation is worse for Jin/GC/GP/GS/GPA. Maybe interpreters could
  offer a "pedantic" mode which checks for these errors as well.
  By default the interpreter should try to work-around these bugs.

-- Stefan

From ???@??? Thu Oct 23 16:50:39 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 21 Oct 1997 11:55:14 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199710211555.LAA06089@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Opcode queries
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a43c49eb5ab43bb718f2e4f33d64af56

OK, I've done a little investigation of one game.  Here's what seems
to be happening with AGB, anyway.

The crash occurs in the routine HasLightSource.  The offending code is
   if (i has enterable || IsSeeThrough(i)==1)
   {   objectloop (i in i)
           if (HasLightSource(i)==1) rtrue;
   }
   ad = i.&add_to_scope;

Unfortunately, when i is enterable or see through, but contains no light
sources at the start of this section, it becomes 0 at the end of this
section.  Thus this is a library bug -- I think
   if (i has enterable || IsSeeThrough(i)==1)
   {   objectloop (j in i)
           if (HasLightSource(j)==1) rtrue;
   }
   ad = i.&add_to_scope;
will work properly.

If this is the only cause of the situation, I'd like to see interpreters
which do so continue to object to uses of object 0, precisely to catch
bugs like this.  It looks like this bug has been there since 6/4
(earliest version I have laying around).  Fortunately an object code
patch could fix it if necessary.

From ???@??? Thu Oct 23 16:50:38 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 21 Oct 1997 11:57:33 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199710211557.LAA06262@pond.com>
To: z-machine@gmd.de
Subject: [z-machine] Quetzal PC
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 946f0a77329304111b44d57f04a14fe4

I think this was discussed once before, but I missed the conclusion of the
discussion.  Is the PC in the IFhd segment the address of the next instruction,
or that of the store variable/branch offset in the save instructions?  O
Originally I thought this made little difference, but now I've realized that
the branch offset can be two bytes...

From ???@??? Thu Oct 23 16:50:44 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom7.netcom.com: erkyrath owned process doing -bs
Date: Tue, 21 Oct 1997 09:41:03 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom7
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Quetzal PC
In-Reply-To: <199710211557.LAA06262@pond.com>
Message-Id: <Pine.SUN.3.95.971021093116.14089A-100000@netcom7>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d05c2e8dbc4125c76433d4daaa8b5d0e

On Tue, 21 Oct 1997, Matthew T. Russotto wrote:

> I think this was discussed once before, but I missed the conclusion of the
> discussion.  Is the PC in the IFhd segment the address of the next instruction,
> or that of the store variable/branch offset in the save instructions?

Try one, load the sample save file, and see if it crashes. :-)

It's the... am I reading this right? It's the address of the operand
specifier byte (v4+) or the conditional jump specifier byte (v1-3), in the
save instruction.

In the ZIP code, this is the natural place for the "pc" variable to be
during the body of the save() and restore() functions.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Thu Oct 23 16:50:45 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 21 Oct 1997 13:42:45 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199710211742.NAA15694@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Quetzal PC
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 78e4e4c72e602f22b83cb09e6b96636f

On Tue, 21 Oct 1997, Matthew T. Russotto wrote:

} > I think this was discussed once before, but I missed the conclusion of the
} > discussion.  Is the PC in the IFhd segment the address of the next instruction,
} > or that of the store variable/branch offset in the save instructions?

} Try one, load the sample save file, and see if it crashes. :-)

Wiseguy.  That's a bit circular.  The sample save file jigsaw0.sav has
it pointing to the instruction after the save, of this I am fairly
certain.  The two ZIP saved ones have it pointing to the byte of the
store variable, if I read the patches correctly.

} It's the... am I reading this right? It's the address of the operand
} specifier byte (v4+) or the conditional jump specifier byte (v1-3), in the
} save instruction.

The standard I have says only "initial PC on restore", which I took to
mean the next instruction after the restore -- for V4+ games, this
means the interpreter has to back up one byte to find the store
variable.  For V3 games, the interpreter doesn't know how far to back
up to find the jump specifier... though the problem could be avoided
by having the SAVE code place the destination of the branch in that
slot if appropriate.  Did I miss a discussion?

From ???@??? Thu Oct 23 16:50:57 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 21 Oct 1997 17:20:17 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199710212120.RAA03945@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Quetzal PC
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5be40b486e0f446581938037fbdd52de

[Forwarding message at the request of the original author -- MTR]
>From mdf@doc.ic.ac.uk  Tue Oct 21 15:37:53 1997
>From: mdf@doc.ic.ac.uk (Martin Frost)
>Date: Tue, 21 Oct 1997 20:35:52 +0100
>To: "Matthew T. Russotto" <russotto@pond.com>
>Subject: Re: [z-machine] Quetzal PC
>Message-Id: <E0xNk5o-0006CG-00@oak3.doc.ic.ac.uk>

>On Tue, 21 Oct 1997, Matthew T. Russotto wrote:

>} > I think this was discussed once before, but I missed the conclusion of the
>} > discussion.  Is the PC in the IFhd segment the address of the next instruction,
>} > or that of the store variable/branch offset in the save instructions?

>} Try one, load the sample save file, and see if it crashes. :-)

>Wiseguy.  That's a bit circular.  The sample save file jigsaw0.sav has
>it pointing to the instruction after the save, of this I am fairly
>certain.  The two ZIP saved ones have it pointing to the byte of the
>store variable, if I read the patches correctly.

I was about to dispute the assertion about the Zip ones, until I realised
that it is in fact true. The behaviour in question is wrong, however.
The jigsaw0.sav file conforms correctly to the standard, and the other
two don't (which is somewhat embarassing as I wrote the standard and the
non-conformant code).

>} It's the... am I reading this right? It's the address of the operand
>} specifier byte (v4+) or the conditional jump specifier byte (v1-3), in the
>} save instruction.

>The standard I have says only "initial PC on restore", which I took to
>mean the next instruction after the restore -- for V4+ games, this
>means the interpreter has to back up one byte to find the store
>variable.

It was intended to mean the address of the next instruction, for
consistency with the format of saved PCs in stack frames. I'm sure that
the jigsaw[12].sav files break this, thinking back to how they're written.
Damn. This is actually a problem with me modifying Zip (the store/branch
gets hidden away in the main interpreter loop, so I'd forgotten it). ;)

>For V3 games, the interpreter doesn't know how far to back
>up to find the jump specifier... though the problem could be avoided
>by having the SAVE code place the destination of the branch in that
>slot if appropriate.  Did I miss a discussion?

No. There wasn't a discussion, as noone has noticed it till now.
It's surprising, really, that the bug didn't show itself earlier (Zip
with patches loads the jigsaw0.sav file fine). Maybe there's a safe
instruction immediately following, so the misaligned PC doesn't crash
things.

The problem now arises as to how to rectify this situation. One of these
behaviours must be defined as correct, and the other must be corrected
in all code exhibiting it.

Going for option (a), the PC pointing to the next instruction, involves
modifying my patches to Zip (and the interpreters which have incorporated
them). It also introduces the problem of how much to backtrack. This could
be got around by extending the IFhd chunk to contain an extra 2 bytes
for the branch/store value.

Going for option (b), the PC pointing to the branch or store byte(s),
involves modifying the specification (and the interpreters which have
implemented their own Quetzal support). It also makes the storage of
saved PCs slightly inconsistent within the format (making it more
confusing than it already was; and from some of the remarks I've heard
it's obviously not entirely as clear as could be desired).

My instincts point to option (b). Although it would require changing
the standard, and would mean that the only currently correct interpreters
become incorrect, it does avoid either uncertainty over how far to back up,
or the need for more clutter in the header chunk (which is stored in the
save file anyway).

It's irritating. I should have noticed this when we had the discussion over
storage of PCs in the saved stack (this problem does not arise in exactly
the same way there, though, as only stores can be present, so it is always
one byte). 

This kinda takes the gloss off the announcement I actually started up my
mailreader to make, that I have created some patches adding Quetzal support
to Frotz (currently only versions using fastmem.c). These patches are
available at the usual place:

	http://www.geocities.com/SiliconValley/Vista/6631/

I would not advise using these patches yet, however, until we sort out
which of options (a) and (b) to take. These patches contain the same
behaviour as the Zip ones (namely falling into option (b)).

On a related note, in implementing the Frotz patches I fell into a similar
problem to that Andrew Plotkin had with restoring a game with a different
screen width (and the associated status line corruption). This didn't seem
to affect the UNIX version of Zip (which I tested the Zip patches on), but
the curses version of Frotz had a badly damaged status line. The way I
fixed this was to put

	if (h_version > V3 && h_version != V6)
	    erase_window (1);

just after the call to reload the header variables. This is intended to
clear the status line only. My questions are: Can anyone see any problems
with this? It works on V5, and V8 games (all I have around here). In
particular, does V6 need special treatment in a similar way, and will
this break any other games? V3 does not need this, as we unsplit the screen
before we get this far.

Well, here we end what has become really quite a long post. I'd like to know
what people think about which of options (a) and (b) to take, so I can make
the necessary changes.

Sigh.

Martin

From ???@??? Thu Oct 23 16:50:53 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 21 Oct 1997 17:48:39 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199710212148.RAA05954@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Quetzal PC
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9f5d1e04739d5b4a35ad5f5c19894a4d

} It was intended to mean the address of the next instruction, for
} consistency with the format of saved PCs in stack frames. I'm sure that
} the jigsaw[12].sav files break this, thinking back to how they're written.
} Damn. This is actually a problem with me modifying Zip (the store/branch
} gets hidden away in the main interpreter loop, so I'd forgotten it). ;)
[...]
} The problem now arises as to how to rectify this situation. One of these
} behaviours must be defined as correct, and the other must be corrected
} in all code exhibiting it.

} Going for option (a), the PC pointing to the next instruction, involves
} modifying my patches to Zip (and the interpreters which have incorporated
} them). It also introduces the problem of how much to backtrack. This could
} be got around by extending the IFhd chunk to contain an extra 2 bytes
} for the branch/store value.

There's no need to modify IFhd, if you note that the decision of
whether the branch will be taken or not can be made at the time of the
save.  Thus the IFhd PC field may either contain the address of the
instruction following the save, or the address of the instruction
following the branch (depending on the negate branch bit in the
instruction).  This has the disadvantage of making more of a mess out
of ZIP-based save routines (since ZIP doesn't finish decoding the
instruction until the very end), but doesn't change the format.  I
think this method would have to be noted in the standard, though.

FWIW, the trick I'd probably use in ZIP is to save the PC, call
conditional_jump(TRUE), do the QUETZEL save, then restore the PC and
call the conditional_jump with the result of the save.  It's a kludge,
but not too bad as kludges go.

} On a related note, in implementing the Frotz patches I fell into a similar
} problem to that Andrew Plotkin had with restoring a game with a different
} screen width (and the associated status line corruption). This didn't seem
} to affect the UNIX version of Zip (which I tested the Zip patches on), but
} the curses version of Frotz had a badly damaged status line. The way I

I had mostly fixed ZIP separately, but note that some games won't work
properly if you change the screen size even if you do all the right
things -- Plantefall Solid Gold, for instance, caches the screen size
and won't change the status line format even if the screen has been
widened.

From ???@??? Thu Oct 23 16:51:09 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 21 Oct 1997 19:24:24 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Quetzal PC
In-Reply-To: <199710212120.RAA03945@pond.com>
Message-Id: <Pine.SUN.3.95.971021191120.18670B-100000@netcom20>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1632670d54bf0a5132b096738ac1579a

On Tue, 21 Oct 1997, Matthew T. Russotto wrote:

> From: mdf@doc.ic.ac.uk (Martin Frost)

> I was about to dispute the assertion about the Zip ones, until I realised
> that it is in fact true. The behaviour in question is wrong, however.
> The jigsaw0.sav file conforms correctly to the standard, and the other
> two don't (which is somewhat embarassing as I wrote the standard and the
> non-conformant code).

Now my head hurts. Why does MaxZip successfully restore from all three
files (jigsaw0,1,2.sav)? If the PCs are different, I mean? Sheer stinking
good luck? I *hate* good luck.

> >} It's the... am I reading this right? It's the address of the operand
> >} specifier byte (v4+) or the conditional jump specifier byte (v1-3), in the
> >} save instruction.

When I wrote the above, I was analyzing your patches for ZIP, which is
what I stuck into MaxZip. As you say, non-conformant code.

> Going for option (a), the PC pointing to the next instruction, involves
> modifying my patches to Zip (and the interpreters which have incorporated
> them). It also introduces the problem of how much to backtrack. This could
> be got around by extending the IFhd chunk to contain an extra 2 bytes
> for the branch/store value.
> 
> Going for option (b), the PC pointing to the branch or store byte(s),
> involves modifying the specification (and the interpreters which have
> implemented their own Quetzal support). It also makes the storage of
> saved PCs slightly inconsistent within the format (making it more
> confusing than it already was; and from some of the remarks I've heard
> it's obviously not entirely as clear as could be desired).
> 
> My instincts point to option (b). Although it would require changing
> the standard, and would mean that the only currently correct interpreters
> become incorrect, it does avoid either uncertainty over how far to back up,
> or the need for more clutter in the header chunk (which is stored in the
> save file anyway).

I tend to agree. Ideally, because I don't like the idea of backing up, and
even more so the idea of backing up an uncertain amount.  (In practice, of
course, because I don't want to chop at my source code *again*. :-) 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Oct 24 16:54:29 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: Miron Schmidt <s590501@tfh-berlin.de>
Reply-To: miron@comports.com
To: Z-List <z-machine@gmd.de>
Date: Wed, 22 Oct 1997 09:19:16 +0100
Message-Id: <yam7234.836.1206251904@mailhost.tfh-berlin.de>
In-Reply-To: <199710212120.RAA03945@pond.com>
X-Mailer: YAM 1.3.5 [020] - Amiga Mailer by Marcel Beck
Organization: TFH-Berlin via PPP
Subject: Re: [z-machine] Quetzal PC (Which part to correct?)
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 580adc175d98ad80039cc5929b8214b5

Martin Frost wrote through Matthew T. Russotto:
> Going for option (a), the PC pointing to the next instruction, involves
> modifying my patches to Zip (and the interpreters which have incorporated
> them). It also introduces the problem of how much to backtrack. This could
> be got around by extending the IFhd chunk to contain an extra 2 bytes
> for the branch/store value.

> Going for option (b), the PC pointing to the branch or store byte(s),
> involves modifying the specification (and the interpreters which have
> implemented their own Quetzal support). It also makes the storage of
> saved PCs slightly inconsistent within the format (making it more
> confusing than it already was; and from some of the remarks I've heard
> it's obviously not entirely as clear as could be desired).

> My instincts point to option (b). Although it would require changing
> the standard, and would mean that the only currently correct interpreters
> become incorrect, it does avoid either uncertainty over how far to back up,
> or the need for more clutter in the header chunk (which is stored in the
> save file anyway).

I don't know. My own instincts point to option (a): all prior versions of the
standard corrected inconsistencies or clearly mistaken assumptions -- so this
one would be the first (to my knowledge) to change the standard itself.
This would mean that interpreters written using standard 1.3 or below would
behave differently from ones using standard 1.4 or above.
When the standard contradicts itself in different versions (in a way that
makes two versions of the standard completely incompatible to each other),
then there's no need for a standard at all, is there?
I mean, isn't this the behaviour that the standard was written to prevent in
the first place?

-- 
Miron Schmidt <miron@comports.com>

           "So, if _Space Aliens_ is Infocom on acid, what's this?"
                       -- C.E. Forman, _Detective: An Interactive MiSTing_


From ???@??? Thu Oct 23 18:48:27 1997
Return-Path: owner-z-machine@mail2.gmd.de
X-Authentication-Warning: netcom16.netcom.com: erkyrath owned process doing -bs
Date: Wed, 22 Oct 1997 22:03:01 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom16
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Opcode queries (fwd)
Message-Id: <Pine.SUN.3.95.971022151546.28185A-100000@netcom17>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 52ad4f6ef67502bd8ec52771c782038c
Status: U

(Forwarded at request of author) (my comment at end. --Z)

Date: Wed, 22 Oct 1997 17:14:34 +0200
From: Magnus Olsson <mol@df.lth.se>
Subject: Re: [z-machine] Opcode queries

On Tue, Oct 21, 1997 at 07:31:13PM -0700, Andrew Plotkin wrote:
> Alternative (3), which I should have thought of much earlier, is to have
> the interpreter print a *non-fatal* error message. That way old games will
> still be playable, but there will be no doubt that the error lies in the
> game file.

And, once you've determined that your game file contains such bug, it
should be possible to turn off the error reporting. If it's possible
to play the game despite the bugs, it's great, and it's even better
if it's possible to play it without having ot worry about bugs you
can't correct anyway (because you were only given the z-code file).

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------
     Not officially connected to LU or LTH.

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

Zarf sez:

My comment is... good point, but please make the default to *show* the
errors. Even for "ordinary", game-playing, non-programming users.
Otherwise we're right back where we started.

--Z





From ???@??? Fri Oct 24 16:54:31 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Thu, 23 Oct 1997 17:16:36 +0100
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: miron@comports.com
Subject: Re: [z-machine] Quetzal PC (Which part to correct?)
Cc: z-machine@gmd.de
Message-Id: <E0xOPw4-0007cI-00@oak73.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 862e1821c0e6b41a326bc08950b776af

Miron Schmidt wrote:
>Martin Frost wrote through Matthew T. Russotto:

[...]
>> option (a), the PC pointing to the next instruction
[...]
>> option (b), the PC pointing to the branch or store byte(s)
[...]

>My own instincts point to option (a): all prior versions of the
>standard corrected inconsistencies or clearly mistaken assumptions -- so this
>one would be the first (to my knowledge) to change the standard itself.

True.

>This would mean that interpreters written using standard 1.3 or below would
>behave differently from ones using standard 1.4 or above.

True. The idea is that standard 1.3 would be declared wrong if we chose option
(b), and interpreters using it would be declared to not be Quetzal compliant.
If we choose option (a) we declare my code to have bugs in and release new
versions of interpreters using it.

>When the standard contradicts itself in different versions (in a way that
>makes two versions of the standard completely incompatible to each other),
>then there's no need for a standard at all, is there?

There is the question that there are currently two incompatible families of
intepreters out there; interpreters following the standard and intepreters
using my buggy code. When I put it in those terms it seems rather clearer
(it seems rather Micro$oftish to change standards just because of a bug in the
code). I'm drifting back towards option (a)... (This way people can just
blame it on me, too, saving face for everyone else). ;)

>I mean, isn't this the behaviour that the standard was written to prevent in
>the first place?

There would still be a standard; it would just have changed. I'm starting to
agree with you, however, that it is probably better merely to clarify the
standard on this point, and use the method of precalculating the target of the
branch for V3 games, and backing up on V4+ games.

I'd like to gather some information on how far Quetzal in these two mutually
incompatible forms has spread. If you have *released* a version of an
interpreter with Quetzal support then please mail me, listing the interpreter
name, version and platform, whether it was released as source, binary or both,
and whether you wrote your own Quetzal code or used mine. (If you're wondering
why I want quite so much information, it's to fill in the unwritten section
9.5 in the standards document when this has all been resolved; I'm trying to
kill two birds with one stone). ;) I'll summarise the results to the list.

Martin

From ???@??? Fri Oct 24 16:54:33 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 23 Oct 1997 11:09:08 -0700
X-Sender: mattack@mail.apple.com
Message-Id: <v01550101b074e07e6356@[17.202.20.138]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: z-machine@gmd.de
From: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] Quetzal PC (Which part to correct?)
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 78d28dc6b00b93db967026d8e2ac36c6

>>When the standard contradicts itself in different versions (in a way that
>>makes two versions of the standard completely incompatible to each other),
>>then there's no need for a standard at all, is there?
>
>There is the question that there are currently two incompatible families of
>intepreters out there; interpreters following the standard and intepreters
>using my buggy code. When I put it in those terms it seems rather clearer

What do the Infocom interpreters do?  Did they follow the since-created
standard (with some bugs, definitely) or what?

--
mattack@apple.com


From ???@??? Thu Oct 23 19:17:38 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <3.0.32.19971023185514.007e4680@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 23 Oct 1997 18:55:40 -1200
To: s.jokisch@avu.de (Stefan Jokisch)
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Opcode queries
Cc: "Z-machine" <z-machine@gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: fbcf66cc1bbe6a42e72d41fe72c0691b
Status: U

At 15:28 21/10/97 +0200, Stefan Jokisch wrote:
>- Situation is worse for Jin/GC/GP/GS/GPA. Maybe interpreters could
>  offer a "pedantic" mode which checks for these errors as well.
>  By default the interpreter should try to work-around these bugs.

I agree.  I think in normal circumstances an interpreter will just quietly
do something sensible about such things (like returning 0 etc), but it
should also have an option to turn on "development mode", where the
interpreter tries to pick up as many non-spec items in the code as possible
and display non-fatal warnings about them, in order for a game author to
fix their code up more easily.

Any other ambiguities or non-spec behaviour should be checked in
development mode, too.

-----                                
     _/    _/  _/_/_/_/  _/_/_/_/   _/_/_/     _/_/_/   _/_/  _/_/
    _/    _/  _/        _/        _/    _/  _/        _/   _/   _/
   _/    _/  _/_/_/    _/        _/_/_/_/    _/_/    _/   _/   _/
  _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/    _/  _/        _/        _/    _/        _/  _/        _/
 _/_/_/   _/_/_/_/  _/_/_/_/  _/    _/  _/_/_/    _/        _/

Gavin Lambert
uecasm@geocities.com
http://crash.ihug.co.nz/~brianc
http://ue.home.ml.org/

"We now return to our regularly scheduled flame-throwing."
"PCMCIA:  People Can't Memorise Computer Industry Acronyms."
"ACRONYM:  Abbreviated Coded Rendition Of Name Yielding Meaning."

From ???@??? Sun Oct 26 09:46:37 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 21 Oct 1997 19:31:13 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Opcode queries
In-Reply-To: <199710211555.LAA06089@pond.com>
Message-Id: <Pine.SUN.3.95.971021192557.18670C-100000@netcom20>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d8bfe6d3b5da8b940f45a21949738d8d
Status: U

On Tue, 21 Oct 1997, Matthew T. Russotto wrote:

> If this is the only cause of the situation, I'd like to see interpreters
> which do so continue to object to uses of object 0, precisely to catch
> bugs like this. 

Unfortunately (but obviously), the library bug you found isn't the only
cause of this situation -- only the most common we've seen. It's not too
hard for the game author to generate illegal code all on his own. (Trivial
examples available upon request. :-) Basically it's an analog of the
famous "dereferencing the NULL pointer" mistake in C, and we all know how
easy it is to do it.

Alternative (3), which I should have thought of much earlier, is to have
the interpreter print a *non-fatal* error message. That way old games will
still be playable, but there will be no doubt that the error lies in the
game file.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Oct 27 20:23:41 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 27 Oct 1997 01:56:03 -0500
From: Bryan Scattergood <104312.2206@compuserve.com>
Subject: Re: [z-machine] Quetzal PC
To: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Message-Id: <199710270157_MC2-2544-910E@compuserve.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0cca29436b556436801979eef371be05



Andrew offered:
 
<< I tend to agree. Ideally, because I don't like the idea of backing 
up, and even more so the idea of backing up an uncertain amount.  (In 
practice, of course, because I don't want to chop at my source code 
*again*. :-) >>

I'm tempted to agree with that.  As I understand the problem (and it 
has been a *long* weekend, so I'm even more tired than usual) the 
Quetzal spec says the saved PC should point *after* the save 
instruction whereas any natural Z-machine implementation has the PC 
pointing to the final field inside the save instruction.

We have two ways of fixing that.  Option (b) declares that the PC 
should be saved pointing to the natural place.  Option (a) declares 
that we need to add an extra word for Z<5 to the header so we can 
figure out where to go on restore, but we can hack Z>=5.

Both of these require changes to the spec.  Both of them potentially 
break compatibility with any existing Quetzal save files.  As far as I 
can tell, the only difference is that (a) makes save files bigger and 
complicates the save/restore logic in the interpreter.

I'd go for option (b).  (And if option (a) happens, I'd suggest using 
the header word to store the byte behind the PC (for Z>=5) to avoid and 
need to back up.)

    Bryan

 

From ???@??? Tue Nov 04 21:39:26 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Oct 1997 09:49:01 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199710311449.JAA08468@pond.com>
To: z-machine@gmd.de
Subject: [z-machine] QUETZAL
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 583bde29e27fdbc9e8194315c17baa37
Status: U

I'm withdrawing my support for the idea of pre-calculating branches in V3
games -- since branches can be rtrue or rfalse, it becomes far too ugly a kludge

From ???@??? Tue Nov 04 21:43:01 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Mon, 3 Nov 1997 15:01:19 +0000
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: z-machine@gmd.de
Subject: [z-machine] Quetzal PC: a decision...
Cc: mdf@doc.ic.ac.uk
Message-Id: <E0xSO0G-00010G-00@oak63.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0650a5d6ad1ff43af9219920d6cca6bc
Status: U

What do people think of this to add to the Quetzal spec to clear up the
problem with the saved PCs? 5.4.6 is a change; the others are new.

5.4.6           3 bytes         ...             PC (see 5.8)

5.8     The value of the PC saved in the chunk depends on the version of the
        Z-machine which the story runs on.

5.8.1   On Z-machine versions 3 and below, the SAVE instruction takes a
        branch depending on the success of the save. The saved PC points to
        the one or two bytes which describe this branch.

5.8.2   On versions 4 and above, the SAVE instruction stores a value
        depending on the success of the save. The saved PC points to the single
        byte describing where to store the result.

5.8.3   This behaviour differs from that specified by previous versions of this
        standard, but the behaviour expected there would be difficult to
        implement in existing interpreters. The situation has been complicated
        as the patches available for the Zip interpreter did not correctly
        implement the previous standard; instead, they behaved as specified
        here.

As can be seen, I have decided that the PC should point inside the instruction
as the current patches for Zip and Frotz do. I realised over the weekend that
fixing existing interpreters to obey the old standard (with Matthew Russotto's
suggestion of precalculating the branch offsets) is substantially messier than
it first appears.

The problem arises as a branch may do a return, which apart from upsetting
the stack may also do a store. Although it would be possible to work around
this by remembering the previous contents of the variable stored into, and
restoring these afterward, this seems unnecessarily messy.

My decision was then made complete when Matthew Russotto withdrew his support
for precalculating the branches (for this very reason); to the best of my
knowledge he is the only person other than myself to have implemented
Quetzal handling from scratch, and all other interpreters fortuitiously obey
the new standard anyway (due to the bug in my code that started this whole
discussion in the first place).

The overall effect of this is that if you have added Quetzal support to your
interpreter using my patches you have nothing to worry about. If you have
implemented it yourself you must change it to conform to the new standard.

If people have any comments please mail me as soon as possible. I'd like
to publish a new version of the standard and clear this sorry mess up before
too long. One thing that occurs to me is whether we should add a version
number (using the byte currently written as a pad on the end of the IFhd
chunk, for example) to enable interpreters to warn users when they load old
save-files (which seems preferable to either declaring all old files unusable
or not telling users at all (resulting in useless bug reports when some game
or other crashes after restoring an outdated file)).

I hope this matter can be resolved soon, and that people don't think I'm being
too autocratic by making sweeping decisions like this all by myself. ;)

Martin

From ???@??? Wed Nov 05 20:28:14 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199711042206.RAA26495@mail.chelmsford.com>
Comments: Authenticated sender is <jpenney@mail.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: z-machine@gmd.de
Date: Tue, 4 Nov 1997 17:00:39 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] Advent.z6 available...
Reply-To: jpenney@chelmsford.com
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v2.52)
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9fcd52e4ae9896d3458e758adeabe089

Hi,

	I've made V6 version of advent available at 
<http://www.cs.uml.edu/~jpenney/if/advent.z6> (GMD isn't responding right 
now, or it would be there).  It's a text only Version 6 game file.  It 
might be of use to interpreter writers wanting to have their interpreters 
run text only v6 games.  It uses my V6Lib, and I'm hoping that it works 
ok.

	It makes one call to @picture_data 0 tmp ...  
Frotz returns tmp-->0 (last image number) and  tmp-->1 (image file 
version) both as 0, and the file seems to run just fine.  WinFrotz 
complains about the file advent.mg1 missing, but then it also runs fine.  
I got it to run under Infocom's DOS Arthur interpreter (6D) in all three 
modes, and it ran fine except for the cursor jumping to the top of the 
main window at startup.  I have no idea what other interpreters will do, 
so if anyone could let me know I'd appreciate it.

Thanks,
Jay

p.s.  I hope to have V6Lib ready for release by the time the competition 
is all over. (Why do I feel I'm going to regret saying that?)

/*-----------------------------------*--------------------------------*\
|JasonCPenney(jpenney@chelmsford.com)| http://www.cs.uml.edu/~jpenney/ |
| Xarton Dragon    --==<UDIC>==--    | (UFO 54-40, Wipers, Int-Fiction)|
*------------------------------------*---------------------------------*
|    "The trouble with computers of course, is that they're very       |
|                sophisticated idiots." -- The Doctor                  |
\*--------------------------------------------------------------------*/

From ???@??? Fri Nov 07 21:19:27 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199711052046.PAA07727@mail.chelmsford.com>
Comments: Authenticated sender is <jpenney@mail.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: z-machine@gmd.de
Date: Wed, 5 Nov 1997 15:39:53 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Advent.z6 available...
Reply-To: jpenney@chelmsford.com
Priority: normal
In-Reply-To: <199711042206.RAA26495@mail.chelmsford.com>
X-Mailer: Pegasus Mail for Win32 (v2.52)
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1d1ec45e74c45686c0f5d86cb377a386

Hi again,

 I was able to get the file up on the archive. 
It's currently at:
 <ftp://ftp.gmd.de/incoming/if-archive/advent.z6>
It will probably be at:
 <ftp://ftp.gmd.de/if-archive/games/infocom/advent.z6>
sometime soon.

 I do have a version that uses the Zork 0 compass rose and status bar, but
I'd rather not release it until I can make original images.  Since I've
spent a rather large amount of time on my V6Lib (Advent does not even begin
to show this, it wasn't meant to), I've been wondering if many people are
actually interested in it or not.  So if you are interested, please just
send me an e-mail (no need to spam the list) letting me know.  If any
interpreter authors need test files to do certain things (with windows,
images, sounds, etc), just let me know.

Thanks,
Jay

/*-----------------------------------*--------------------------------*\
|JasonCPenney(jpenney@chelmsford.com)| http://www.cs.uml.edu/~jpenney/ |
| Xarton Dragon    --==<UDIC>==--    | (UFO 54-40, Wipers, Int-Fiction)|
*------------------------------------*---------------------------------*
|    "The trouble with computers of course, is that they're very       |
|                sophisticated idiots." -- The Doctor                  |
\*--------------------------------------------------------------------*/

From ???@??? Thu Nov 13 17:09:42 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199711071954.OAA08746@plymouth.truespectra.com>
To: z-machine@gmd.de
Subject: [z-machine] State of sound support?
Date: Fri, 07 Nov 97 14:44:19 EST
From: "Stephen van Egmond" <svanegmo@truespectra.com>
Content-Type: text/plain; charset="iso-8859-1"
Reply-To: svanegmo@truespectra.com
X-Mailer: BeMail [version 2.0]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7bf70eff3f440ca051797eecaae60215
Status: U

Believe it or not, there may be a game coming out soon that uses sound.
I confess that any disucssions about sound I deleted without reading, 
since I
had no opinion on the subject.

So, now I'm inquiring about the result of those discussions.

- Has a file format and directory structure been agreed upon?
  I recall AIFF being recommended for a sound format, and IFF being 
recommended
  to glom all the sounds for a game into one file.
  There was also Andrew's PICKLE; what became of it?

- What's the state of interpreter support on the various platforms for 
said
  sound format?

/Steve

From ???@??? Thu Nov 13 17:09:43 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 7 Nov 1997 12:01:22 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom6
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] IF API
Message-Id: <Pine.SUN.3.95.971107114852.2609D-100000@netcom6>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6426d12071fbf3a4e151914dcee837bb
Status: U

The following is an informational announcement:

I've been working on an interface API for IF games and systems. 

The idea is to have an I/O API for *new* adventure systems and virtual
machines, which has the *same* user interface we currently use.
Potentially with some graphics added, but as little functionality as
possible -- in particular, no graphics mixed with text. Text styles might
be a little more advanced than Inform's "bold, italics, or fixed-width" 
but not much. Support for multiple text windows. API calls to handle
selecting, opening, reading and writing disk files.

It abstracts out as much as possible -- so that the game can look
Maxzip-like on Macs, Xzip-like on X windws machines, JZip-like in terminal
windows, and so on. 

(This is the kind of platform-independence that Java *fails* at. There
would have to be separate interface library for each machine, but new
games or new VMs could be compiled, linked with the library, and run right
away. A half-hour porting job, as opposed to the many days I spent on (for
example) MaxTADS.)

This comes about because I think there's more interest in new game engines
than in new interfaces, and I dread the thought of porting new game
engines -- all of which have essentially the same interface, but different
API and different guts.

Now, I already know more or less what the API looks like. I'm doing a Mac
implementation, to assume myself that the API actually does what I want
and is feasible to implement. A terminal-window version would be the more
important second port.

I am not releasing anything *or accepting suggestions* until I have a Mac
version done, and a spec is written. (Both jobs about half-done.) 

Then I will post the API and the spec document, as a rough draft of a
proposal. And then you can tear it to pieces. But not yet.

I'm only announcing it now because I've told a few people already, and
mentioned it in a discussion of TADS folk, so it's only fair to mention it
here too.

Again, I'm not taking suggestions at this time. I can't tell you not to
discuss the subject, but I've got my fingers in my ears, la la la la la.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Thu Nov 13 17:09:45 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 7 Nov 1997 12:03:22 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom6
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] State of sound support?
In-Reply-To: <199711071954.OAA08746@plymouth.truespectra.com>
Message-Id: <Pine.SUN.3.95.971107120126.2609E-100000@netcom6>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 872b410de87904a543665001b3662bd3
Status: U

On Fri, 7 Nov 1997, Stephen van Egmond wrote:

> Believe it or not, there may be a game coming out soon that uses sound.
> I confess that any disucssions about sound I deleted without reading, 
> since I
> had no opinion on the subject.
> 
> So, now I'm inquiring about the result of those discussions.
> 
> - Has a file format and directory structure been agreed upon?
>   I recall AIFF being recommended for a sound format, and IFF being 
> recommended
>   to glom all the sounds for a game into one file.

Yes. The Blorb proposal is done, or at least stable. It's on ftp.gmd.de,
er, somewhere, I think.

>   There was also Andrew's PICKLE; what became of it?

Turned into Blorb.

> - What's the state of interpreter support on the various platforms for 
> said
>   sound format?

Nil. Nil support for PICKLE, I should quickly add. Some interpreters
support Infocom's sound scheme, and that's it.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Thu Nov 13 17:09:49 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 7 Nov 1997 18:08:23 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199711072308.SAA22209@pond.com>
To: svanegmo@truespectra.com, z-machine@gmd.de
Subject: Re:  [z-machine] State of sound support?
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6eb0b3e4890830c64855bd9990552eac
Status: U

Zip Infinity, Macintosh, can handle Infocom-format sounds only (either using
the original naming scheme or the scheme devised by Stefan Jokisch, I believe)

From ???@??? Thu Nov 13 17:09:50 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: rri0189@ibm.net
Message-Id: <199711080238.VAA000.39@MYHOSTNAME>
Mime-Version: 1.0
Date: Fri, 07 Nov 97 21:33:50 -0500
To: z-machine@gmd.de
Reply-To: rri0189@ibm.net
Subject: Re: [z-machine] Is it possible....
X-Mailer: Ultimedia Mail/2 Lite, IBM T. J. Watson Research Center
Content-Id: <29_104_4_878956430>
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d7052f681004d5799907a8c41bb0c0ad
Status: U

No, it is not possible to build a functional Z-machine emulator
using only portable code.  Truly portable code cannot move the
cursor from one point to another on the screen, and that means
that the status line and many other functions are out of the
question.  Truly portable code also cannot set colors, or
underscoring, or brightness, or anything else.

You might be able to build an adequate system for version-1
through version-3 games, omitting the status line altogether,
but it wouldn't look very good.

// John W Kennedy

From ???@??? Thu Nov 13 17:09:51 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 7 Nov 1997 19:21:48 -0800
Message-Id: <199711080321.TAA03118@albatros.wco.com>
From: Alloplast Petrofsky <albatros@wco.com>
To: burnekoj@ultra27.cs.lafayette.edu
Cc: z-machine@gmd.de
In-Reply-To: 
	<Pine.SOL.3.93.971107205928.23585B-100000@ultra27.cs.lafayette.edu>
	(message from Jesse Burneko on Fri, 7 Nov 1997 21:03:41 -0500 (EST))
Subject: Re: [z-machine] Is it possible....
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 715fbaa0b6e87988ae5b7b5bde108d7b
Status: U

Jesse Burneko <burnekoj@ultra27.cs.lafayette.edu>:
> My question is: Is it possible to write a z-machine
> interpreter using ONLY the functions defined in the ANSI C standard
> library?

Yes.  I've written a dumbio.c file for zip that uses only getchar and
putchar.  Here's some sample output:

   West of House
   You are standing in an open field west of a white house, with
   a boarded front door.
   There is a small mailbox here.

   [ West of House                  Score: 0        Moves: 0      ]
   >n
   North of House
   You are facing the north side of a white house. There is no
   door here, and all the windows are boarded up. To the north a
   narrow path winds through the trees.

   [ North of House                 Score: 0        Moves: 1      ]
   >

As you can see, it prints out the upper window before each input. It
tries to deal well with multi-line upper windows.  You can have it
only display lines that changed since the last input or display the
whole window, or (the default) display lines from the first one that
changed to the last one that changed.  You can enter single keys for
read_char by preceeding the following newline with a backslash.  Input
timeouts are unimplemented.

All told, it handles Curses block quotes and the Bureaucracy form
pretty well, makes the solid gold hints usable, and even allows you to
play robots if you don't mind wasting a lot of output.

I use it as my primary interpreter and run it inside an emacs shell
buffer.  This gives me unlimited scrollback and a gazillion
input-editing features, and the mixing of the two z windows makes the
scrollback richer in information.

Of course, it's also indispensible when you're playing adventures from
a printing teletype as God intended.

If anyone wants it, just ask.  Even if noone else wants to actually
use it, it might be good to include it in zip just so that porters can
get something running immediately.

-al

From ???@??? Thu Nov 13 17:09:53 1997
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199711080335.WAA12391@plymouth.truespectra.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Is it possible....
Date: Fri, 07 Nov 97 22:25:50 EST
From: "Stephen van Egmond" <svanegmo@truespectra.com>
Content-Type: text/plain; charset="iso-8859-1"
Reply-To: svanegmo@truespectra.com
X-Mailer: BeMail [version 2.0]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1840a7b0537fd4b18fd6fa469d4fea3e
Status: U

Did the originator of this thread see Andrew's most recent post?  (Not the 
one
to me, the other one.)

You know, the one where he says (paraphrasing)
	"One of these days, I'm going
	to release a library which makes writing portable interpreters that 
	look like their native platform easy as hell."
?

Since you're hankering for some fun portable work you can sink your teeth 
into,
how about a portable Inform debugger?  Mr. Riccardi has some documents he 
can
hand you...

/Steve

From ???@??? Thu Nov 13 17:10:04 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: "Giovanni Riccardi" <g.riccardi@speednet.it>
To: "Z-Machine" <z-machine@gmd.de>
Subject: R: [z-machine] Is it possible....
Date: Sat, 8 Nov 1997 08:05:03 +0100
Message-Id: <01bcec14$a3722880$b3aaf7c2@sn0024>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="x-user-defined"
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3

X-Mime-Autoconverted: from 8bit to quoted-printable by mail.gmd.de id IAA21510
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 4ac1d88f11f7a6ddbe65a345cd7b784f
Status: U



>Did the originator of this thread see Andrew's most recent post?  (Not the
>one
>to me, the other one.)
>
>You know, the one where he says (paraphrasing)
> "One of these days, I'm going
> to release a library which makes writing portable interpreters that
> look like their native platform easy as hell."
>?
>
>Since you're hankering for some fun portable work you can sink your teeth
>into,
>how about a portable Inform debugger?  Mr. Riccardi has some documents he
>can
>hand you...


All the informations about the Inform Debugger (A.K.A. Infix) was published
in the four newsletters, but now the project seems dead. Maybe John Wood
<John@elvw.demon.co.uk> could help you. If I remember well, he's working on
something like "Winfix", Infix version for Windows machines.
bye
Giovanni

P.S. Some of the members of the Infix Group have some interest to begin a
new discussion about Infix either on this list or privately???

         `'´
        (. .)
---oOO-- (_) --OOo------------------------------------
                            "How do you know I'm mad?"
                            said Alice. "You must be,"
  Giovanni  Riccardi        said the Cat "or you
g.riccardi@speednet.it      wouldn't have come here."
   Terracina  Italy
                            - L. Carrol "Alice's
                             Adventures in Wonderland"
Visit P.O.V. Online, a place for your stories & poems:
http://www.geocities.com/Athens/Delphi/8758/index.html
------------------------------------------------------

From ???@??? Thu Nov 13 17:10:22 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 10 Nov 1997 07:32:29 -0500 (EST)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Jesse Burneko <burnekoj@ultra27.cs.lafayette.edu>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Is it possible....
In-Reply-To: <Pine.SOL.3.93.971107205928.23585B-100000@ultra27.cs.lafayette.edu>
Message-Id: <Pine.SGI.3.95.971110073119.2873A-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ea21db57b04587ec29216c5aedcd83c5
Status: U

> I understand this entirely for GUI systems but what about plain old boring
> terminal interfaces.  My question is: Is it possible to write a z-machine
> interpreter using ONLY the functions defined in the ANSI C standard
> library?  Or is it nescessary to use things like conio.h on dos systems
> and curses.h on unix?

  It's probably *better* to do it that way.  Bear in mind that the z-machine
defines a way for part of the text to go unscrolling; raw i/o would have to
repeat that part every line.
  Note that there are versions of curses for DOS and (!) Macintosh.


___Dan_Knapp____The_Mauve_Baron______________________Beep Blip Bonk_______
<dankna@bergen.org><dankna@brain.mics.net> http://users.bergen.org/~dankna
Visit ftp://ftp.gmd.de/if-archive/ and find out about text adventures!
If only one marker works, it will be yellow. -- Dr. Nevard

From ???@??? Wed Nov 19 14:07:28 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Sat, 15 Nov 1997 16:52:48 +0000
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: z-machine@gmd.de
Subject: [z-machine] Quetzal finalised...
Message-Id: <E0xWlSi-0006pA-00@oak70.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 84c8957b767ee6fd99daa52cd8e72949

No-one's mailed me about the proposed changes to the Quetzal spec, so I'm
assuming you're all happy with them and am incorporating them.

The latest version is available from

 http://www.geocities.com/SiliconValley/Vista/6631/savefile_14.txt

and should appear at the IF-archive as

 ftp://ftp.gmd.de/if-archive/infocom/interpreters/specification/savefile_14.txt

in a few days.

This version fixes the problem with the saved PC values and also incorporates
some minor consmetic changes to the formatting of later sections which have
been available as versions 1.3a, 1.3b, 1.3c (although never officially
announced).

Martin

From ???@??? Wed Nov 19 14:07:30 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sun, 16 Nov 1997 00:15:14 -0800
Message-Id: <199711160815.AAA00503@albatros.wco.com>
From: Albococcus Petrofsky <albatros@wco.com>
To: Z-Machine Masochists <z-machine@gmd.de>
Subject: [z-machine] "A tremendous pain in Andrew Plotkin's butt"
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7e1242fe256a7018ad0b4625faf8f5e1

I've been trying to implement everybody's least favorite z-machine
feature (reads to non-empty buffers), and I'm afraid I can't quite
make sense of it.  The spec says:

    Moreover, if byte 1 contains a positive value at the start of the
    input, then read assumes that number of characters are left over from an
    interrupted previous input, and writes the new characters after those
    already there.  Note that the interpreter does not redisplay the
    characters left over: the game does this, if it wants to.

In the usage that I've seen and think I understand, the characters are
on the screen just before the cursor and they should become editable.
So if the buffer contains "foo" and the screen looks like this (where
"_" is the cursor):

   blahfoo_

Then if the user types <delete> <delete> g <return>, we should
successively see:

   blahfo_
   blahf_
   blahfg_

and the call should return with "fg" in the buffer.  But now suppose
that the buffer contains "foo" and the screen looks like:

   blahbar_

Should the behavior for <delete> <delete> g <return> be:

   blahbar_     <BEEP!> (or whatever you do for <delete> at the start of input)
   blahbar_     <BEEP!>
   blahbarg_

and the return value be "foog"?  What if there's a partial match
between the screen and the buffer ("blahbao_")?  Does just the
matching part become editable?

Can someone point me to an example of an infocom game calling read
when the buffer contents are not displayed just before the cursor?

If there aren't any, then it seems there's no point in the spec
allowing it.  Maybe the spec doesn't allow it, and I've just
misunderstood what exactly the line "the game does this, if it wants
to" is talking about.

-al

From ???@??? Wed Nov 19 14:07:38 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sun, 16 Nov 1997 16:36:43 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199711162136.QAA18473@pond.com>
To: z-machine@gmd.de
Subject: Re:  [z-machine] "A tremendous pain in Andrew Plotkin's butt"
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e53e81f20a15784b98d970585e141878

} Can someone point me to an example of an infocom game calling read
}when the buffer contents are not displayed just before the cursor?

Border Zone, part 2, after a timeout.  I think.  It might have been a
bug in my interpreter causing that.

From ???@??? Wed Nov 19 14:07:39 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sun, 16 Nov 1997 15:55:02 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom18
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] "A tremendous pain in Andrew Plotkin's butt"
In-Reply-To: <199711160815.AAA00503@albatros.wco.com>
Message-Id: <Pine.SUN.3.95.971116154814.24076A-100000@netcom18>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 379f22c846cffd12f60903eafafa8ca1

On Sun, 16 Nov 1997, Albococcus Petrofsky wrote:

> I've been trying to implement everybody's least favorite z-machine
> feature (reads to non-empty buffers), and I'm afraid I can't quite
> make sense of it.  The spec says:
> 
>     Moreover, if byte 1 contains a positive value at the start of the
>     input, then read assumes that number of characters are left over from an
>     interrupted previous input, and writes the new characters after those
>     already there.  Note that the interpreter does not redisplay the
>     characters left over: the game does this, if it wants to.

I think this is a little misleading. The game *must* do this (redisplay
the characters), if it wants to have any (that is, if byte 1 is a
positive value.)
 
> In the usage that I've seen and think I understand, the characters are
> on the screen just before the cursor and they should become editable.
> So if the buffer contains "foo" and the screen looks like this (where
> "_" is the cursor):
> 
>    blahfoo_
> 
> Then if the user types <delete> <delete> g <return>, we should
> successively see:
> 
>    blahfo_
>    blahf_
>    blahfg_
> 
> and the call should return with "fg" in the buffer. 

Right.

> But now suppose
> that the buffer contains "foo" and the screen looks like:
> 
>    blahbar_

This should be illegal behavior on the game's part. I'm pretty sure
Infocom's interpreters do something screwy at this point. I *know* that
MaxZip does something screwy, and furthermore that it will always do so;
there's no sensible way I can see for the interpreter to behave.

> Can someone point me to an example of an infocom game calling read
> when the buffer contents are not displayed just before the cursor?

Matt Russotto:

> Border Zone, part 2, after a timeout.  I think.  It might have been a
> bug in my interpreter causing that.

No, that's the place I always test my code, and it doesn't do this.

You may be thinking of a *different* case, which is where a timeout
routine runs and prints something *but does not return true to abort the
input*. In that case, it is the *interpreter's* responsibility to
re-display what the player is editing. No new call to @read has occurred;
it's still in the middle of the original @read opcode.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sun Dec 14 07:36:32 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 12 Dec 1997 22:20:08 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom19
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Glk Spec 0.1
Message-Id: <Pine.SUN.3.95.971212220324.5092A-100000@netcom19>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 52ae885c2d7e5b4da9d1ad82977cbb9d

Once, many moons ago, I started talking about a universal I/O library for
IF games and IF systems. (And generally any program which uses text input
and output.) The idea is that the library contains *all* the
platform-specific code for the interface, whether MacOS, X Windows,
curses.h terminal window, PalmPilot PDA, or whatever. The *hope* is to
solve, once and for all (or at least the next several years) the problem
of porting new IF systems to new platforms, *without* fixating to a
common-denominator interface such as a terminal window or the Java
toolkit.

I now have something solid to mouth off about.

http://www.edoc.com/zarf/glk-spec-01.txt

I have implemented everything in that document for MacOS. Actual working
code. (Ok, not working perfectly -- but close.)

The spec is very much a rough draft. I would be pleased to hear your
thoughts on what I've done wrong, what I've forgotten, why I'm insane, or
other compliments. 

There are a few areas I haven't tried to think about; notably, graphics,
sound, and other multimedia enhancements. I haven't even thought about how
text styles will work. (My Mac version uses the Z-machine system of
bold/italic/reverse/fixedwidth, but that's purely until something better
gets decided on.) 

After the screaming over the spec dies down, the obvious next step is to
build a curses.h terminal-window implementation. That's the lowest common
denominator interface for Unix, DOS/Windows, and RiscOS. It should be
pretty easy -- I've tried to make the API as abstract as possible. (I
could even see an Emacs mode interface... heh.) But don't start that yet.
First, comments.

Comments?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Sun Dec 14 07:36:34 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 12 Dec 1997 22:44:24 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom19
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Glk Spec 0.1
In-Reply-To: <Pine.SUN.3.95.971212220324.5092A-100000@netcom19>
Message-Id: <Pine.SUN.3.95.971212224222.13548A-100000@netcom19>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c783930df5bd906c56ddc725dccb4081

On Fri, 12 Dec 1997, Andrew Plotkin wrote:

> Once, many moons ago, I started talking about a universal I/O library for
> IF games and IF systems. 
> 
> http://www.edoc.com/zarf/glk-spec-01.txt

Oops, first comment from me: this is not at all Z-machine related. I'm
posting it here because we've all spent time thinking about virtual
machines and portable interfaces, and because I'm not on any TADS mailing
lists. Possibly I should post to r.a.i-f too, but I don't want two
independent discussions going on. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Dec 17 07:16:49 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 15 Dec 1997 07:46:21 -0500 (EST)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Andrew Plotkin <erkyrath@netcom.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Glk Spec 0.1
In-Reply-To: <Pine.SUN.3.95.971212220324.5092A-100000@netcom19>
Message-Id: <Pine.SGI.3.95.971215074516.20307E-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 551dec58ce89044f7df04a6e27c5905d

> Once, many moons ago, I started talking about a universal I/O library for
> IF games and IF systems. (And generally any program which uses text input
> and output.) The idea is that the library contains *all* the
> platform-specific code for the interface, whether MacOS, X Windows,
> curses.h terminal window, PalmPilot PDA, or whatever. The *hope* is to
> solve, once and for all (or at least the next several years) the problem
> of porting new IF systems to new platforms, *without* fixating to a
> common-denominator interface such as a terminal window or the Java
> toolkit.

  Ahhh, YES...

> There are a few areas I haven't tried to think about; notably, graphics,
> sound, and other multimedia enhancements. I haven't even thought about how
> text styles will work. (My Mac version uses the Z-machine system of
> bold/italic/reverse/fixedwidth, but that's purely until something better
> gets decided on.) 

  How about handling graphics like X does?  Of course, you'd have to find
out how that is...

> Comments?

  Very nice!


___Dan_Knapp____The_Mauve_Baron______________________Beep Blip Bonk_______
<dankna@bergen.org><dankna@brain.mics.net> http://users.bergen.org/~dankna
Visit ftp://ftp.gmd.de/if-archive/ and find out about text adventures!
Schooling is not to impart knowledge, but to impart ability.

From ???@??? Wed Dec 17 07:16:59 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 15 Dec 1997 11:50:14 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom17
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Glk Spec 0.1
Message-Id: <Pine.SUN.3.95.971215114955.4776A-100000@netcom17>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a76034a4e609d7585a4fdbb4c472bf17

On Mon, 15 Dec 1997, A.K.A. TheWiz wrote:

>   How about handling graphics like X does?  Of course, you'd have to find
> out how that is...

What, X Windows? Wouldn't that mean implementing an entire X server inside
the Glk library? That's a little upscale of what I was thinking of...

> > Comments?
> 
>   Very nice!

Thanks.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Dec 17 07:17:02 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 15 Dec 1997 16:25:22 -0500 (EST)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Andrew Plotkin <erkyrath@netcom.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Glk Spec 0.1
In-Reply-To: <Pine.SUN.3.95.971215114955.4776A-100000@netcom17>
Message-Id: <Pine.SGI.3.95.971215162451.20787E-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e7a0602fff45fe1514bd588232ff09b4

> >   How about handling graphics like X does?  Of course, you'd have to find
> > out how that is...
> 
> What, X Windows? Wouldn't that mean implementing an entire X server inside
> the Glk library? That's a little upscale of what I was thinking of...

  Probably, yes... (ill-considered.  :-)
  If only there were an ANSI gui!


___Dan_Knapp____The_Mauve_Baron______________________Beep Blip Bonk_______
<dankna@bergen.org><dankna@brain.mics.net> http://users.bergen.org/~dankna
Change Nomic!   http://funnelweb.utcc.utk.edu/~chatham/nomicfaq.html
Turn on, or I'll boot you downstairs!

From ???@??? Fri Dec 19 07:31:57 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Dec 1997 14:34:53 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom15
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Glk Spec
Message-Id: <Pine.SUN.3.95.971216143207.162B-100000@netcom15>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e1cca93c316e4acb953c33e84f9d5d3a

Ok, lack of discussion here. Either I'm perfect or you're all gone for the
holiday. :)

I'm going to bring the subject up on rec.arts.int-fiction, and see what
happens there.

I'm fiddling around with a Glk version of Agility, by the way. It's a
slight pain since I think I have to peel off an entire layer of code
(which assumes terminal-window-style output.) We'll see. If nothing else,
I've got a status line, unlike my "cheapass Mac Agility port." 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Dec 19 07:31:59 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Dec 1997 17:48:31 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199712162248.RAA00780@pond.com>
To: erkyrath@netcom.com, z-machine@gmd.de
Subject: Re:  [z-machine] Glk Spec
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f9ab5b27a3b79b704fcdc9c130d49541

So when's the Hugo port?

From ???@??? Fri Dec 19 07:32:00 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 16 Dec 1997 15:14:00 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom15
To: Z-Machine List <z-machine@gmd.de>
Subject: Re:  [z-machine] Glk Spec
In-Reply-To: <199712162248.RAA00780@pond.com>
Message-Id: <Pine.SUN.3.95.971216151056.5417A-100000@netcom15>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ce4d40ca6f2a3c7c4b3168554cbde2ea

First, I'd better note that the URL has changed:

http://www.edoc.com/zarf/glk/index.html

Text and HTML versions now available.

On Tue, 16 Dec 1997, Matthew T. Russotto wrote:

> So when's the Hugo port?

In the future. Somewhere.

I would really like to do a Glk port of Hugo. However, I haven't even
looked at the Hugo spec, so there's almost certainly some aspect of Hugo
which can't be supported by Glk's interaction model. 

I do want to take Hugo into account when deciding what Glk's sound and
graphics capacities should be.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Dec 19 07:32:14 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 17 Dec 1997 01:59:10 -0500
From: Bryan Scattergood <104312.2206@compuserve.com>
Subject: Re: [z-machine] Glk Spec
To: "internet:erkyrath@netcom.com" <erkyrath@netcom.com>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Message-Id: <199712170200_MC2-2C43-C126@compuserve.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: abee4a9c2abe3754d9dfa0cde37c68b5



Andrew,

<< Ok, lack of discussion here. Either I'm perfect or you're all gone 
for the holiday. :) >>

I'm still here.  Still reading the documentation and gathering a few 
thoughts before I reply later in the week.  Could well be others in he 
same position.
 
<< I'm going to bring the subject up on rec.arts.int-fiction, and see 
what happens there. >>

Immediately, or can I persuade you to wait a few days?

    Bryan
    



 

From ???@??? Fri Dec 26 11:10:19 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: rri0189@ibm.net
Message-Id: <199712242246.RAA000.47@MYHOSTNAME>
Mime-Version: 1.0
Date: Wed, 24 Dec 97 16:46:43 -0500
To: z-machine@gmd.de
Reply-To: rri0189@ibm.net
Subject: [z-machine] Standard issues
X-Mailer: Ultimedia Mail/2 Lite, IBM T. J. Watson Research Center
Content-Id: <31_95_4_883000003>
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e25bfd4546064c80f330f37e757fa536

I've been spending some time developing an interpreter from scratch
(since someone else owns the Frotz-for-OS/2 franchise and I don't
really feel like pulling my ZIP derivative all the way up to 1.0),
and found I had a few difficulties.

1.  The standard is sometimes far from adequately clear in vacuo.
An implementor isn't going to _want_ to believe, for example, that
there are so many silly operations defined.  (Such as compare
immediate to immediate and branch.)  The op-code section should
be expanded to make clear just what each variation does.

2.  Terms like "next" are used too freely; I had to write experimental
code to verify that 'get_next_prop' proceeds in ascending order (and
therefore in reverse memory order); the reason why becomes evident
when one comes to writing the actual implementing code, but it is
counterintuitive at first.

3.  I cannot for the life of me reason out what 'throw' and 'catch' do,
and I am very familiar with languages that possess such a concept.

4.  It is not clearly specified for v-format instructions what is to
be done when too many operands are supplied, or too few, nor is it
specified just what instructions have multiple possibilities.  (Are
'je' and 'call...' the only ones?)  (By the way, Inform does not
seem to be able to assemble je with >2 operands, although it will
compile it at need.)

5.  The exact meaning of "current PC" for 'jump' is unclear.

All of the above can be solved by reference to current interpreters,
experimental programs, and TXD, but the following appear to be
genuine holes in the standard.

6.  Parsing involves folding uppercase to lowercase, but these terms
are given no definition.  I half suspect that a thorough solution
for non-English may involve an additional table to be specified,
although an interpreter written in a language with locale support
may very well solve the problem for the local language by default.
What does German Zork do?  What do current non-English Inform users
expect?

7.  In a windowed environment (as nearly all are, nowadays), just
what is to be done when the user changes (or attempts to change) the
size of the window containing the Z-machines's screen?

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

None of which changes the fact that I could not have done even
remotely so good a job....  Graham's hobbit-like labors to "set [it]
out fair and square with no contradictions" are, as Charles II
remarked to Christopher Wren when touring new St. Paul's, "awful...
[and] artificial".

By the way, does anyone have V1 and V2 fossils that I can test with?
I have original Infocom packages of everything, but I have nothing
older than 1982.

Happy Dismembur 25th to all!

// John W Kennedy

From ???@??? Sun Dec 28 11:17:59 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 26 Dec 1997 21:59:52 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom4
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Standard issues
In-Reply-To: <199712242246.RAA000.47@MYHOSTNAME>
Message-Id: <Pine.SUN.3.95.971226214950.3129B-100000@netcom4>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7b77b7ac033a1e2c77c6a92cea67d538

On Wed, 24 Dec 1997 rri0189@ibm.net wrote:

> 6.  Parsing involves folding uppercase to lowercase, but these terms
> are given no definition.  I half suspect that a thorough solution
> for non-English may involve an additional table to be specified,
> although an interpreter written in a language with locale support
> may very well solve the problem for the local language by default.
> What does German Zork do?  What do current non-English Inform users
> expect?

The Infocom standard (before Graham's Unicode extension) can be understood
if you take upper- and lower-case to have the usual definitions; all the
accented characters have sensible lower-case equivalents.

In the wider world of Unicode, I don't know whether it's possible to
determine whether a character is "upper case" based solely on its Unicode
code. 
 
> 7.  In a windowed environment (as nearly all are, nowadays), just
> what is to be done when the user changes (or attempts to change) the
> size of the window containing the Z-machines's screen?

Update the header bits containing the screen size. The z-program, of
course, will not be able to do anything with this information right away;
almost certainly it is in the middle of a @read or @read_char instruction
and is waiting for player input. 

It is the z-program's responsibility to watch this info and (for example)
redraw the status line, based on the current screen size, pretty quickly.
The Inform library does it before every input, which is sensible. 

There was a suggestion at some point to have an interrupt if the screen
changes size, and run an optional Z-code routine *during* the interrupted
@read or @read_char. This is a massive headache. (Note that I neatly
dodged the issue in my Glk proposal, by requiring the program to run an
event loop for any input. End plug.) 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Dec 31 09:50:23 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: rri0189@ibm.net
Message-Id: <199712281525.KAA000.96@MYHOSTNAME>
Mime-Version: 1.0
Date: Sun, 28 Dec 97 10:23:36 -0500
To: KingD@rnd1.indy.tce.com
Reply-To: rri0189@ibm.net
Cc: z-machine@gmd.de
Subject: RE: [z-machine] Standard issues
X-Mailer: Ultimedia Mail/2 Lite, IBM T. J. Watson Research Center
Content-Id: <59_98_4_883322616>
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8dbfe621247d8ff49349983463780b5e

Thanks for the V1 and V2 samples.

// John W Kennedy

From ???@??? Wed Dec 31 09:50:24 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: rri0189@ibm.net
Message-Id: <199712281544.KAA000.97@MYHOSTNAME>
Mime-Version: 1.0
Date: Sun, 28 Dec 97 10:25:52 -0500
To: z-machine@gmd.de
Reply-To: rri0189@ibm.net
Subject: Re: [z-machine] Standard issues
X-Mailer: Ultimedia Mail/2 Lite, IBM T. J. Watson Research Center
Content-Id: <59_98_4_883322752>
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 600649207dddb76f031e15e723d5daae

>The Infocom standard (before Graham's Unicode extension) can be understood
>if you take upper- and lower-case to have the usual definitions; all the
>accented characters have sensible lower-case equivalents.

This may be true from a human viewpoint, but how is an emulator to know this?
Except for purely accidental solution via locale support in the emulator
writer's C compiler, how does the binary code of the emulator know that
"This game is in German, so that 'AE' lowercases to 'ae'"?  By always
lowercasing everything in the 155-252 range?  Does any emulator actually
do so?

>It is the z-program's responsibility to watch this info and (for example)
>redraw the status line, based on the current screen size, pretty quickly.
>The Inform library does it before every input, which is sensible. 

And on the other hand, as I recall, many Infocom games get the collywobbles.
Perhaps the ideal solution is (as in some other cases) to recognize these
and handle them differently?


// John W Kennedy

From ???@??? Wed Dec 31 09:50:25 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sun, 28 Dec 1997 10:00:11 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom12
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Standard issues
In-Reply-To: <199712281544.KAA000.97@MYHOSTNAME>
Message-Id: <Pine.SUN.3.95.971228094104.17693A-100000@netcom12>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8ab561283efa0e415c8d1eac036b2627

On Sun, 28 Dec 1997 rri0189@ibm.net wrote:

> >The Infocom standard (before Graham's Unicode extension) can be understood
> >if you take upper- and lower-case to have the usual definitions; all the
> >accented characters have sensible lower-case equivalents.
> 
> This may be true from a human viewpoint, but how is an emulator to know this?
> Except for purely accidental solution via locale support in the emulator
> writer's C compiler, how does the binary code of the emulator know that
> "This game is in German, so that 'AE' lowercases to 'ae'"?  By always
> lowercasing everything in the 155-252 range? 

Ok, I understand the question. The answer is that it's necessary to
translate the local machine's character set. On the Mac, key code 174 is
'AE' and key code 190 is 'ae'; a Mac interpreter must translate both of
those to value 211 before handing it to @read_char or the @read buffer,
because 211 is 'ae' in the Z-machine character set. In X windows, I
believe that key events always arrive using the ISO 8859 Latin-1 character
set, so 'AE' will be 198 and 'ae' will be 230, so an X interpreter should
translate both of *those* to 211 and put the 211 in the @read buffer.

In other words, the problem of downcasing non-ASCII characters is no worse
than the problem of accepting non-ASCII characters as input in the first
place.

> Does any emulator actually do so?

Mine don't accept accented characters for @read, and don't do any
translation when accepting them for @read_char. (Which is to say, they
return completely wrong results for @read_char.) 

I don't know how smart Frotz is, or how careful its porters were.

> >It is the z-program's responsibility to watch this info and (for example)
> >redraw the status line, based on the current screen size, pretty quickly.
> >The Inform library does it before every input, which is sensible. 
> 
> And on the other hand, as I recall, many Infocom games get the collywobbles.
> Perhaps the ideal solution is (as in some other cases) to recognize these
> and handle them differently?

Or just tell the user "If resizing the screen screws up the status line,
then *don't do that.*" :-)

Geez, maybe I'll get MaxZip down to one window after all.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Dec 31 09:52:01 1997
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 30 Dec 1997 09:39:47 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199712301439.JAA08024@pond.com>
To: rri0189@ibm.net, z-machine@gmd.de
Subject: Re:  [z-machine] Standard issues
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8210b86b96e94bfecc1779f54958c89b

} 3.  I cannot for the life of me reason out what 'throw' and 'catch' do,
} and I am very familiar with languages that possess such a concept.

I don't know why the Z-machine calls it "throw" and "catch", unless it
is because they are vital for implementation of those high-level
constructs.  Think of them as more like restricted versions of C's
"longjmp" and "setjmp".  I believe earlier versions of ZIP called them
"unwind" and "get_fp" respectively, which may make more sense.

From ???@??? Wed Dec 31 09:52:04 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Standard issues
Date: Tue, 30 Dec 1997 19:52:53 +0100
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19971230194255.AAA21117@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 29c1b2979b46a5c1797fdc3260a39a1d


> In other words, the problem of downcasing non-ASCII characters is no worse
> than the problem of accepting non-ASCII characters as input in the first
> place.

And it's quite easy for ISO Latin-1 characters:

if (c >= 0xc0 && c <= 0xde && c != 0xd7)
  c += 0x20;

Note that 0xd7 and 0xdf aren't uppercase letters.

> I don't know how smart Frotz is, or how careful its porters were.

The portable Frotz core supports the ISO Latin-1 set and lowercases all
letters.  However, some ports simply reject non-ASCII characters on the
input line.

-- Stefan

From ???@??? Wed Dec 31 09:52:05 1997
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Standard issues
Date: Tue, 30 Dec 1997 20:51:53 +0100
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Message-Id: <19971230194255.AAB21117@jokisch>

X-Mime-Autoconverted: from 8bit to quoted-printable by mail.gmd.de id UAA27458
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 74ae7b78bb64a82a878a83642bb73037


> 1.  The standard is sometimes far from adequately clear in vacuo.
> An implementor isn't going to _want_ to believe, for example, that
> there are so many silly operations defined.  (Such as compare
> immediate to immediate and branch.)  The op-code section should
> be expanded to make clear just what each variation does.

I don't get your point.  Why do you want to explain each variation?
After the operands have been evaluated, the operation is always the
same.  It doesn't require any extra work for the interpreter author
to implement them all.  And yes, all "silly" variations are legal,
and the Spec is quite clear about this.

> 2.  Terms like "next" are used too freely; I had to write experimental
> code to verify that 'get_next_prop' proceeds in ascending order (and
> therefore in reverse memory order); the reason why becomes evident
> when one comes to writing the actual implementing code, but it is
> counterintuitive at first.

My intuition points to the opposite direction, but I admit that the
term "next" is slightly ambiguous.

> 3.  I cannot for the life of me reason out what 'throw' and 'catch' do,
> and I am very familiar with languages that possess such a concept.

CATCH stores the current stack frame pointer in a suitable format;
THROW restores it and returns the given value.  The effect is close,
yet slightly different from the common catch/throw mechanism you're
used to.  Here's some pseudo code to illustrate its use:

  global frame = 0;

  main {
    ...
    call func1 -> result;
    if (result != 0)
      print "Failed.";
    ...
  }

  func1 {
    catch -> frame;
    ...
    call func2;
    ...
    return 0;
  }

  func2 {
    ...
    call func3;
    ...
  }

  .
  . // some complicated, possibly recursive mess
  .

  func561 {
    ...
    if (error_condition)
      throw frame 1;
    ...
  }

    
> 4.  It is not clearly specified for v-format instructions what is to
> be done when too many operands are supplied, or too few, nor is it
> specified just what instructions have multiple possibilities.  (Are
> 'je' and 'call...' the only ones?)  (By the way, Inform does not
> seem to be able to assemble je with >2 operands, although it will
> compile it at need.)

The Spec leaves this behaviour unspecified.  Most interpreters don't
care to check these error conditions.  As a result, extra arguments
will be ignored whereas missing arguments cause unpredictable results.

All 2-OP instructions exist in the v-format.  Once again, I think the
Spec is clear about this.  In particular, 4.4.2 points out that the VAR
form must be used if a 2-OP instruction requires a large constant as
operand.

I seem to recall that "vje" was used for the VAR form of JE, but I'm
not sure if this is still true.
 
> 5.  The exact meaning of "current PC" for 'jump' is unclear.

Because of the scheme 

  "read opcode & operands - evaluate operands - apply opcode" 

the natural position of the PC is at the start of the following opcode.
 
> 6.  Parsing involves folding uppercase to lowercase, but these terms
> are given no definition.  I half suspect that a thorough solution
> for non-English may involve an additional table to be specified,
> although an interpreter written in a language with locale support
> may very well solve the problem for the local language by default.
> What does German Zork do?  What do current non-English Inform users
> expect?

Uppercase letters include non-English uppercase letters.

German Zork (as most games) doesn't care about the input buffer; it
only looks at the token buffer.  Of course, the interpreter should
match "TUER" (TÜR) with the dictionary entry "tuer" (tür).
 
> 7.  In a windowed environment (as nearly all are, nowadays), just
> what is to be done when the user changes (or attempts to change) the
> size of the window containing the Z-machines's screen?

Changing screen sizes don't happen in the Z-machine screen model, and
therefore the Spec doesn't mention this issue.  However, game authors
are asked to check the screen format frequently.  In any case, making
the interpreter window resizeable is one of the trickiest parts of
interpreter design.  Good luck to you.

-- Stefan

From ???@??? Fri Jan 02 17:46:35 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 31 Dec 1997 20:51:07 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Standard issues
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <19971230194255.AAB21117@jokisch>
Message-Id: <Marcel-1.26-1231205107-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c813521b46f31c5039bed0f9fd6a185e

On Tue 30 Dec, Stefan Jokisch wrote:
> 
> > 1.  The standard is sometimes far from adequately clear in vacuo.
> > An implementor isn't going to _want_ to believe, for example, that
> > there are so many silly operations defined.  (Such as compare
> > immediate to immediate and branch.)  The op-code section should
> > be expanded to make clear just what each variation does.
> 
> I don't get your point.  Why do you want to explain each variation?
> After the operands have been evaluated, the operation is always the
> same.  It doesn't require any extra work for the interpreter author
> to implement them all.  And yes, all "silly" variations are legal,
> and the Spec is quite clear about this.

Indeed, some early Inform games may even contain "compare immediate
to immediate and branch", because the best way to write an infinite
loop in early versions of Inform (which didn't implement conditions
very elegantly) was something like this:

   while (1==1)
   {  ...
   }

So an interpreter which disdains to implement this opcode may even
fail on a few early games.  All combinations are legal!

> > 3.  I cannot for the life of me reason out what 'throw' and 'catch' do,
> > and I am very familiar with languages that possess such a concept.

The terms "throw" and "catch" were used by Infocom's own
implementors, but anyway predate them: I've seen them in
earlier languages.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Sun Jan 04 10:30:06 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: jwkenne@ibm.net
Message-Id: <199801020250.VAA000.70@MYHOSTNAME>
Mime-Version: 1.0
Date: Thu, 01 Jan 98 17:29:22 -0500
To: z-machine@gmd.de
Reply-To: jwkenne@ibm.net
Subject: Re: [z-machine] Standard issues
X-Mailer: Ultimedia Mail/2 Lite, IBM T. J. Watson Research Center
Content-Id: <58_95_4_883693762>
Content-Type: text/plain; charset="ISO-8859-1"

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 669254e7c97475914d6b6ae2dd5896ae

>> 1.  The standard is sometimes far from adequately clear in vacuo.
>> An implementor isn't going to _want_ to believe, for example, that
>> there are so many silly operations defined.  (Such as compare
>> immediate to immediate and branch.)  The op-code section should
>> be expanded to make clear just what each variation does.

>I don't get your point.  Why do you want to explain each variation?
>After the operands have been evaluated, the operation is always the
>same.  It doesn't require any extra work for the interpreter author
>to implement them all.  And yes, all "silly" variations are legal,
>and the Spec is quite clear about this.

I'm old enough to have worked with literally a dozen or more machine
architectures (prior to 1964, IBM alone had six or seven incompatible
mainframe designs at once), and I've spent considerable time laboring
in the Z-machine vineyard (porting ITF, ZIP, and JZIP to OS/2, and
fixing some bugs in the ZIP and JZIP ports for Unix), but until now
my Z-machine work has been entirely in the area of screen/keyboard
support.  So all I can say, in the end, is that if I found the
standard confusing, others will, too, if they approach it with
tabulae rasae.

I _think_ the standard reflects its origins. It was (was it not?)
written by and for experienced Z hackers as a tool to formally work
out known problems.  This is where the attention was focused.  But
it is not yet a full and clear statement that someone who doesn't
know the Z machine at all can use to write an interpreter, or
code in assembler -- not without a certain amount of experimentation
and reverse engineering.

I'm 49 years old, and I've been working with computers since 1965
(I was a teenage hacker many years before it became fashionable!).
So I'm going to have to ask you to trust me here; I know my own
abilities, and if I find an archtecture description incomplete, it
is.

All of which is not to say that I don't feel like a smutty-nosed,
wet-bottomed, nasty little fanboy to be bringing this up, because
Graham Nelson is a Living God at whose shrine I worship and I'm
nothing but a mass of semi-sentient puke not worthy to be living
on the same planet.  I grant that.  Really, I do.  <grin!>

Maybe "Z-machine Architecture for Dummies" is the answer?

>> 3.  I cannot for the life of me reason out what 'throw' and 'catch' do,
>> and I am very familiar with languages that possess such a concept.

>CATCH stores the current stack frame pointer in a suitable format;
>THROW restores it and returns the given value.  The effect is close,
>yet slightly different from the common catch/throw mechanism you're
>used to.  Here's some pseudo code to illustrate its use:

Let's see if I have it right.

CATCH stores a z-word which is a "magic cookie" or "handle" for the
current frame, understandable only by the current interpreter.
(Call it frame F.)

THROW X F, executed in the context of frame F + n, unwinds the stack to
frame F, and then executes an effective RET X in the context of frame
F, so that the machine actually ends up in frame F - 1.

And a brief experiment seems to confirm this.

>> 4.  It is not clearly specified for v-format instructions what is to
>> be done when too many operands are supplied, or too few, nor is it
>> specified just what instructions have multiple possibilities.  (Are
>> 'je' and 'call...' the only ones?)  (By the way, Inform does not
>> seem to be able to assemble je with >2 operands, although it will
>> compile it at need.)

>The Spec leaves this behaviour unspecified.  Most interpreters don't
>care to check these error conditions.  As a result, extra arguments
>will be ignored whereas missing arguments cause unpredictable results.

>All 2-OP instructions exist in the v-format.  Once again, I think the
>Spec is clear about this.  In particular, 4.4.2 points out that the VAR
>form must be used if a 2-OP instruction requires a large constant as
>operand.

My point is that I don't see where the standard endorses the use of
JE with more than tw> operands, or where it disallows the use of any
other instruction with more than two operands.

>I seem to recall that "vje" was used for the VAR form of JE, but I'm
>not sure if this is still true.
 
Inform 6.14 does not accept "vje" and TXD does not emit it.

>> 5.  The exact meaning of "current PC" for 'jump' is unclear.

>Because of the scheme 

>  "read opcode & operands - evaluate operands - apply opcode" 

>the natural position of the PC is at the start of the following opcode.
 
Except, as a matter of fact, the operand of JUMP is biased by -2, just
like all the conditional jumps.  (Which raises the question, do operands
0000 and 0001 for JUMP act as long-form RFALSE and RTRUE?)

>> 6.  Parsing involves folding uppercase to lowercase, but these terms
>> are given no definition.  I half suspect that a thorough solution
>> for non-English may involve an additional table to be specified,
>> although an interpreter written in a language with locale support
>> may very well solve the problem for the local language by default.
>> What does German Zork do?  What do current non-English Inform users
>> expect?

>Uppercase letters include non-English uppercase letters.

>German Zork (as most games) doesn't care about the input buffer; it
>only looks at the token buffer.  Of course, the interpreter should
>match "TUER" (TÜR) with the dictionary entry "tuer" (tür).

I meant the Infocom-written engine(s) that (I suppose) accompanied
German Zork.
 
>> 7.  In a windowed environment (as nearly all are, nowadays), just
>> what is to be done when the user changes (or attempts to change) the
>> size of the window containing the Z-machines's screen?

>Changing screen sizes don't happen in the Z-machine screen model, and
>therefore the Spec doesn't mention this issue.  However, game authors
>are asked to check the screen format frequently.  In any case, making
>the interpreter window resizeable is one of the trickiest parts of
>interpreter design.  Good luck to you.

The Standard seemed to me both to demand and to forbid this.

// John W Kennedy
From ???@??? Sun Jan 04 10:30:15 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 2 Jan 1998 16:20:17 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom6
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] stricter z-code error checking
Message-Id: <Pine.SUN.3.95.980102155744.23039A-100000@netcom6>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3854d8f6638cb9f526f038b5db574426

Several months ago there was some discussion about z-code errors in modern
games, which were being silently ignored by modern interpreters. Most of
these were passing 0 to an object opcode such as @get_prop.

I've written a simple patch for the original ZIP source, which watches for
these errors. It then either reports the error, silently ignores it, or
fatal-errors out of the interpreter (depending on a command-line option.)
It can be set to report every error, or only report the first instance of
each type of error. (The latter lets you play the game with minimal
disruption; usually the game gets the errors out of the way during the
first turn. I think that this is the best default for a general-purpose
interpreter.) 

If it doesn't shut down the interpreter, it recovers from the error as
safely as possible. (This generally means doing nothing, or returning 0,
whichever is appropriate for the opcode.)

I think that changes of this sort should be put in all supported
interpreters. The changes in my patch are all #ifdef'd, so you can compile
them in or out by changing one line in ztypes.h. But leaving them in is
not expensive -- at most one or two "if (obj)" tests per opcode, unless an
error actually materializes. Even if error reporting is turned off, game
behavior should become saner, because erroneous opcodes recover and do
nothing instead of manipulating meaningless values. And the incidence of
these errors in Z-code games will not decrease unless authors see warnings
from the interpreters they use during development.

I'll kick out new versions of XZip and MaxZip over the weekend, I hope.

This patch checks for the following cases:

@jin 0 x
@get_child 0
@get_parent 0
@get_sibling 0
@get_prop_addr 0 x
@get_prop 0 x
@put_prop 0 x y
@clear_attr 0 x
@set_attr 0 x
@test_attr 0 x
@move_object 0 x
@move_object x 0
@remove_object 0

Stefan Jokisch posted a message dated "Tue, 21 Oct 1997" listing
the presence of these errors in existing games.

Uuencoded context diff at
http://www.edoc.com/zarf/zip_zstrict_patch.uu

(I know, uuencoding is silly, but my web browser munged long lines when I
tried it as plain text.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Sun Jan 04 10:30:23 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 2 Jan 1998 22:38:24 -0800
Message-Id: <199801030638.WAA06219@albatros.wco.com>
From: Allomerism Petrofsky <albatros@wco.com>
To: jwkenne@ibm.net
Cc: z-machine@gmd.de
In-Reply-To: <199801020250.VAA000.70@MYHOSTNAME> (jwkenne@ibm.net)
Subject: Re: [z-machine] Standard issues
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 15c314745f2c843cf0857523c1794af9

   From: jwkenne@ibm.net
   Date: Thu, 01 Jan 98 17:29:22 -0500

   Let's see if I have it right.

   CATCH stores a z-word which is a "magic cookie" or "handle" for the
   current frame, understandable only by the current interpreter.
   (Call it frame F.)

   THROW X F, executed in the context of frame F + n, unwinds the stack to
   frame F, and then executes an effective RET X in the context of frame
   F, so that the machine actually ends up in frame F - 1.

Yes, with n >= 0.  But referring to frames by numbers gives the
false impression that you can catch a handle, return twice, call four
times, and then be in a valid frame (F + 2) for throwing the handle.

I don't see that you're being much clearer than the current spec:

    |2OP:28  1C 5/6 throw           value stack-frame|
    
    Opposite of |catch|: resets the routine call state to the state it
    had when the given stack frame value was `caught', and then
    returns.  In other words, it returns as if from the routine which
    executed the |catch| which found this stack frame value.

I would expand this to something like:

    Opposite of |catch|: resets the routine call state to the state it
    had when the given stack frame value was `caught', exiting any
    intervening frames, and then returns the value.  In other words,
    it returns as if from the routine which executed the |catch| which
    found this stack frame value.  The given frame must not have
    previously been exited or returned from.

I'm sure it could be worded less awkwardly, but I think it at least
says everything that needs to be said.

Perhaps your confusion has been caused or aggravated by the fact that
zip and most of its derivatives have broken code for throw.  Here's
the patch:

--- zip-2.0/control.c	Fri Jan  2 21:25:17 1998
+++ al-zip/control.c	Fri Jan  2 21:17:26 1998
@@ -303,7 +303,7 @@
 #endif
 {
 
-    if (new_fp > fp)
+    if (new_fp < fp)
         fatal ("Bad frame for unwind");
 
     fp = new_fp;

Presumably this has gone unnoticed because the only infocom games to
use catch and throw are v6, which zip doesn't handle at all.

I've included below some inform source that shows how to implement a
lisp-like catch/throw with user-chosen tags, which I'm guessing is one
of the versions of catch/throw that you're familiar with (because it's
at least half as old as you are[1]).  The opcodes are also sufficient
for extending inform to have a java-like try/catch/finally feature
(but that would be a lot more work).

   >Changing screen sizes don't happen in the Z-machine screen model, and
   >therefore the Spec doesn't mention this issue.  However, game authors
   >are asked to check the screen format frequently.  In any case, making
   >the interpreter window resizeable is one of the trickiest parts of
   >interpreter design.  Good luck to you.

   The Standard seemed to me both to demand and to forbid this.

I'm also confused.  If infocom games do not check the screen size for
changes, then it seems that if standard interpreters are to be able to
run infocom games correctly, the standard must disallow changes unless
the game states that it will check for them by setting a header bit or
something.  (And if such an extension is to be added, then it might as
well be done right and include a screen-size-change terminating
character so that changes during line input can be handled.)

However, in versions other than 6, the lower window is just a
write-only stream of words, newlines, and screen-erases.  There's not
much reason for a game to know it's real size on screen, so an
interpreter can just let the game think it's a fixed size like 24x80
(minus the height of the upper window) while actually allowing the
user to resize it.  If you want to get fancy, you can store the output
as a series of words and newlines going back to the last screen-erase,
and always keep the screen updated to show as many lines as fit after
word-wrapping to the current width.

Allowing the lower window to be resized and not the upper one means
you'll have to treat them as truly separate windows.  There's an ugly
part of window-splitting semantics that violates this concept and
allows a game to write to the upper window, shrink the upper window to
no longer include the lines written to, and then expect those lines to
be visible (overlayed on the lower window) until they are scrolled off
or the lower window is erased.  This can be handled by leaving the
lines in the upper window and not really shrinking it until the lower
window is erased, or until one input after the shrink request is made
(this will give the user a chance to see it once, which is all the
game will count on since it doesn't control scrolling).  You can find
an example of this technique in Andrew Plotkin's xzip.

It's all so simple, isn't it?

-al

[1] Catch/throw was added to MacLisp[2] in 1972.

[2] No, you darn whippersnappers[3], MacLisp had nothing to do with the
    Apple Macintosh.

[3] This condescension is completely phony.  I was born less than a
    year before the unix epoch, but I try to know my CS history so as
    not to be doomed to repeat it.


! An Inform implementation of lisp-like catch/throw

! a tag can be any 16-bit value except not_a_tag
Constant not_a_tag -1;

! the value returned by the most recent catch that's still valid.
Global catch_frame;

! Set to a tag during a throw.
Global tag_being_thrown = not_a_tag;

! helper for catch_tag
[setup_catch func arg;
  @catch -> catch_frame;
  return func(arg);
];

! call a function with an argument.
! If the function returns normally, return the returned value.
! If a throw occurs with a matching tag, return the value thrown.
[catch_tag  tag func arg
    saved_catch_frame result;

  saved_catch_frame = catch_frame;
  result = setup_catch(func, arg);
  catch_frame = saved_catch_frame;

  ! If the function exited due to a throw, then check if the tag matches and
  ! pass it on if it doesn't.
  if (tag_being_thrown ~= not_a_tag) {
    if (tag_being_thrown ~= tag)
      @throw result catch_frame;
    tag_being_thrown = not_a_tag;
  }

  return result;
];


! throw a value to a catch with a matching tag
[throw_to_tag tag value;
  tag_being_thrown = tag;
  @throw value catch_frame;
];



! An example using catch_tag and throw_to_tag.

! Two arrays: numbers in the first are matched to strings in the second.
Array numbers table 1 5 3 7;
Array strings table "foo" 0 "bar" "baz";

! a couple tags
Constant not_found 1;
Constant abort_to_top 2;

! Search for n in numbers and return the corresponding string.
! If not found, throws false to tag not_found.
! If the value is zero, throws "Eek!  A zero!" to tag abort_to_top.
[search n
    i;

  for (i = 1 : i <= numbers-->0 : i++)
    if (numbers-->i == n) {
      if (strings-->i == 0)
        throw_to_tag(abort_to_top, "Eek!  A zero!^");
      return strings-->i;
    }
  throw_to_tag(not_found, false);
];

! search for a number, print it's corresponding string, and return true.
[search_and_print n
    value;

  value = search(n);
  print "    search_and_print: matching string for ", n ," is: ",
        (string) value, ".^";
  rtrue;
];

! call search_and_print for 1 to n, catching not_found.
! return "done";
[search_and_print_1_to_n n
    k;

  for (k = 1 : k <= n : k++) 
    if (~~catch_tag(not_found, search_and_print, k))
      print "  search_and_print_1_to_n: ", k, " not found.^";
  return "done";
];

[main
    s;

  print "main: calling catch_tag(abort_to_top, search_and_print_1_to_n, 3)^";
  s = catch_tag(abort_to_top, search_and_print_1_to_n, 3);
  print "main: catch_tag returned: ", (string) s , "^";

  print "main: calling catch_tag(abort_to_top, search_and_print_1_to_n, 10)^";
  s = catch_tag(abort_to_top, search_and_print_1_to_n, 10);
  print "main: catch_tag returned: ", (string) s , "^";
];


! Output:
!
! main: calling catch_tag(abort_to_top, search_and_print_1_to_n, 3)
!     search_and_print: matching string for 1 is: foo.
!   search_and_print_1_to_n: 2 not found.
!     search_and_print: matching string for 3 is: bar.
! main: catch_tag returned: done
! main: calling catch_tag(abort_to_top, search_and_print_1_to_n, 10)
!     search_and_print: matching string for 1 is: foo.
!   search_and_print_1_to_n: 2 not found.
!     search_and_print: matching string for 3 is: bar.
!   search_and_print_1_to_n: 4 not found.
! main: catch_tag returned: Eek!  A zero!

From ???@??? Wed Jan 07 13:42:33 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 6 Jan 1998 17:25:08 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom10
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Quetzal bug
Message-Id: <Pine.SUN.3.95.980106171647.12794A-100000@netcom10>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 133e897db385838f63af0c74a78adf46

Yeah, another teeny little detail. :)

In the sample quetzal.c file, line 308, we see

  if (h_version != 6) {
    /* dummy stack frame for stack used before call */

This is supposed to represent the difference in stack usage between V6
games and the other Z-machine types. Unfortunately, in Mark Howell's ZIP
source, "h_version" is the *release number* (bytes 2-3) from the header,
not the Z-machine version number (byte 0).

This line should be changed to

  if (h_type != 6) {

The error manifests itself if you try to save and restore a V5/8 game
which happens to be release 6. You get a "wrong variable number on stack"
error, followed by a fatal ZIP error. Presumably it would also screw up in
any V6 game which was *not* release 6. 

Note that "h_version" occurs in two other places in quetzal.c, and there
it is correct. (Quetzal saves the game release number in the IFhd chunk.) 

Good thing _So Far_ is at release 6, huh?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Thu Jan 08 08:20:09 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Wed, 7 Jan 1998 13:52:49 +0000
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Andrew Plotkin <erkyrath@netcom.com>
Subject: Re: [z-machine] Quetzal bug
Cc: z-machine@gmd.de
Message-Id: <E0xpvub-0007ID-00@oak72.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5fa71159d344a1819e51904ecee25948

Andrew Plotkin wrote:

>In the sample quetzal.c file, line 308, we see

>  if (h_version != 6) {
>    /* dummy stack frame for stack used before call */

[...]

>This line should be changed to

>  if (h_type != 6) {

Damn. That code seems to have more bugs in it than Windows 95.

I've also noticed an unrelated (I guess) bug in the Quetzal patches for
Frotz, which means that one cannot restore files saved from Zork II or
III (although Zork I seems to work).

I'm still trying to track this one down (only noticed it late last night).

Has anyone used the Quetzal patches for Frotz?

I'm trying to decide which of three things is causing these bugs.
Either the Quetzal format is excessively complex and bugs are inevitable,
or my code is just very bad all the time, or I hadn't had enough sleep at
the time I wrote each set of patches, making my normally perfect code go
wrong. I hope it's the third.

Martin

From ???@??? Thu Jan 08 08:20:23 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 7 Jan 1998 10:25:33 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom11
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Quetzal bug
In-Reply-To: <E0xpvub-0007ID-00@oak72.doc.ic.ac.uk>
Message-Id: <Pine.SUN.3.95.980107102255.12969A-100000@netcom11>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5ed323797fe616672f7c23768d3d2bae

On Wed, 7 Jan 1998, Martin Frost wrote:

> Damn. That code seems to have more bugs in it than Windows 95.

Don't exaggerate. We're up to, what, four or five bugs?
 
> I'm trying to decide which of three things is causing these bugs.
> Either the Quetzal format is excessively complex and bugs are inevitable,
> or my code is just very bad all the time, or I hadn't had enough sleep at
> the time I wrote each set of patches, making my normally perfect code go
> wrong. I hope it's the third.

In the case of the one I found, it's just insufficient testing. Nobody
tested it with a V6 game or release 6 of a V5/8 game. It is axiomatic that
a piece of code doesn't work before you've seen it running.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Thu Jan 08 08:20:25 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Standard issues
Date: Wed, 7 Jan 1998 19:22:47 +0100
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19980107181443.AAA7798@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7fa2893c6d8435f4f47094cd6c4c2363


John Kennedy asked how Infocom's own Zip for German Zork (Dos Zip 5h)
treats accented letters.  Quite simple: The interpreter rejects any
accented letters on the input line.  After all, it was only a beta,
and US keyboards don't have any keys for accented characters, anyway.

A side note: There are debugging information attached to Zip 5h.  Is
anybody willing to send me Microsoft C 4.0 (or its debugger, if it's
a separate program)?

-- Stefan

From ???@??? Thu Jan 08 08:20:28 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: jwkenne@ibm.net
Message-Id: <199801071925.OAA002.31@MYHOSTNAME>
Mime-Version: 1.0
Date: Wed, 07 Jan 98 14:15:42 -0400
To: z-machine@gmd.de
Reply-To: rri0189@ibm.net
Subject: Re: [z-machine] Standard issues
X-Mailer: Ultimedia Mail/2 Lite, IBM T. J. Watson Research Center
Content-Id: <120_123_4_884200542>
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 566d3d35f7575b109e059707e8300576

My essential problem with the present description of catch/throw is
that it is not stated that what actually happens in "catch" is that
a 16-bit "magic cookie" or "handle" is stored, which "throw" can
subsequently use to refer to the now-current stack.

But enough of these matters for the present.  I'm working on a
detailed document that (I hope) can be merged into the next version
of the Standard, or provide a springboard for discussion.

// John W Kennedy

From ???@??? Tue Jan 13 10:25:57 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Mon, 12 Jan 1998 16:51:16 +0000
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: z-machine@gmd.de
Subject: [z-machine] Quetzal bug fixes
Message-Id: <E0xrn52-0001b6-00@oak63.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1238bd0b3522388bcefd010727c92333

Right. I have fixed the two bugs that have been discovered in the various
Quetzal patches.

To remind you, the bugs were:

        In the ZIP patches, restore would crash the interpreter if the story
        had release exactly 6. Cause: an occurrence of `h_version' in the
        file `quetzal.c' should have been `h_type'.

        In the Frotz patches, restore would not work on Infocom's own V3
        games. Cause: a line `currlen -= tmpw*2;' had gone missing from the
        file `quetzal.c'.

Both of these are fixed, and new versions of the patch archives are available
from

        http://www.geocities.com/SiliconValley/Vista/6631/

If you have used the Quetzal patches but have not changed the quetzal.c file,
simply download the relevant archive and replace the whole file. If you have
changed this file, mail me and I'll explain exactly what the differences are.

Also, I can't remember ever announcing the existence of the patches to add
Quetzal support to Frotz; the time I wrote them was overshadowed by the bug
in the standard itself. They are now available from the above web page...

Please mail me if there are any further questions.

Martin

From ???@??? Wed Jan 14 11:21:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Tue, 13 Jan 1998 16:11:17 +0000
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: z-machine@gmd.de
Subject: [z-machine] Quetzal bug fixes
Cc: mdf@doc.ic.ac.uk
Message-Id: <E0xs8vu-0005Af-00@oak75.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c92cbfd1e83b001e27ef102567a54f65

Sorry if you have already received this: I didn't receive the last post
so I am resending it.

I have fixed the latest two bugs to have been found in the patches adding
Quetzal support to ZIP and Frotz.

To remind you, these bugs were:

	In the ZIP patches: the interpreter would crash after restoring a
	file saved from a story of release exactly 6. Thanks to Andrew
	Plotkin for finding this.

	In the Frotz patches: the interpreter was unable to restore files
	saved from Infocom's own V3 stories.

Both of these bugs are now fixed. New versions of the patches are available
from

	http://www.geocities.com/SiliconValley/Vista/6631/

If you have used the patches in your interpreter port, and have not modified
the quetzal.c file, then you can simply replace the old file with the new,
since both of these bugs were exclusively found in this file.

If you did modify the file, then please mail me and I'll give you exact
details of what changes need making.

I should also point out that both of these bugs only affect restoring. The
files saved are fine, which means that players need only upgrade to an
interpreter with the bugs fixed, and need not delete all their save files.

Lastly, I cannot remember if I actually announced the existence of the
Quetzal patches for Frotz. They are available from the above web site.

Martin

From ???@??? Fri Jan 16 14:32:23 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199801152239.RAA03024@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: z-machine@gmd.de
Date: Thu, 15 Jan 1998 17:45:58 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] V6 and Machine Types
Reply-To: jpenney@chelmsford.com
X-Confirm-Reading-To: jpenney@chelmsford.com
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1d3f8411e529144fb63cf60eafbd2dba

Hi

A while ago (September) there was some discussion about introducing a 
new machine type that could be used to signify a machine independent V6 
interpreter (see messages with the subject "[Blorb] A question of 
machine types").  I'd like to expand upon that a bit, as there are some 
features present in Infocom's Dos V6 interpreters missing from the Amiga 
interpreters and vice versa.  (NOTE:  I know very little about the Mac 
V6 interpreters, or any others for that matter).  I think that the 
machine independent V6 interpreter should be based on the best features 
of the existing interpreters.

I see three (semi-resonable) options for the machine 
type/interpreter number idea (not counting "just forget it"):  

A)
Create some sort of standardish, non machine specific V6 behavior, and 
assign a machine type (both 255 and 0 have been suggested) that can be 
used by all interpreters that support this.  Other interpreters can 
still claim the machine type that there V6 support is based on.

B)
If all ports of a given interpreter (Frotz for example) that have V6 
support are going to behave the same across platforms, assign a machine 
type to that interpreter (i.e.  machine type 11 means that the 
interpreter is Frotz).

C)
We could define a sort of standard V6 header extension.  Adding some 
more flags which could state flat out what is and what isn't supported.  
I still think a new interpreter number should be used to signify that 
this extension is present.


The behaviors I am currently worried about are the following ones:

Font Styles:
============
This one isn't that important, but I'm throwing it in there anyway.
The Spec states:

"In some interpreters (though this is not required) a combination of
styles is possible (such as reverse video and bold). In these, changing
to Roman should turn off all the other styles currently set." 

Maybe it's best not to worry about this, but if we take option C above, 
then I think this should be thrown in there.

Window Height Changes:
======================
In V6 Frotz (at least Dos and Win) handles these very elegantly.  In
Infocom's own Dos interpreters, they are a mess.  I wish I knew how 
Infocom's Amiga interpreter behaved.  I'm not 100% sure on the details 
behind this, but basically, I think it would be nice if all modern 
interpreters could handle changes the way Frotz currently does. I realize 
this is hard to follow.  If I can find a nice Dos screen capture 
programs, I'll put some examples on a web page or something.

Colour Palette
===============
Text
---------------
Section 8.3 of the spec states:

"Under Versions 5 and later, text printing has a current foreground and
background colour. In Version 6, each window has its own pair. (Note that
a Version 6 interpreter going under the Amiga interpreter number must use
the same pair of colours for all windows. If either is changed, then the
interpreter must change the colour of all text on the screen to match.
This simulates the Amiga hardware, which used two logical colours for
text and switched palette to change their physical colour.) "

The same pair of colours for all windows thing should not be necessary 
on most systems.  One of the nicer features of V6 is that each window 
has it's own set of values (for text colour and fonts and such).  The 
Amiga interpreter disallows certain words being in a different colour 
(you should see the Terpetude colour test run on Dos Frotz in Amiga 
mode... lot's of flashing colours.)

Pre-defined Colours
-------------------
Section 8.3.1 states:

"The following codes are used to refer to colours: 

    -1 =  the colour of the pixel under the cursor (if any)
    0  =  the current setting of this colour
    1  =  the default setting of this colour
    2  =  black   3 = red       4 = green    5 = yellow
    6  =  blue    7 = magenta   8 = cyan     9 = white
    10 =  darkish grey (MSDOS interpreter number)
    10 =  light grey   (Amiga interpreter number)
    11 =  medium grey  (ditto)
    12 =  dark grey    (ditto)

Colours 10, 11, 12 and -1 are available only in Version 6. In Version 6
the pictures in some graphics files use colours beyond the above: if so
the result of "the colour under the cursor" is permitted to be stored
with value 16 or greater. "

I feel that the Amiga colour ought to be available in new modern V6 
interpreters.  Should colours 13-15 be defined to anything (probably 
not, but I might as well ask)?

Other Thoughts
==============
If we go with option C, I also think we might as well put a field that 
holds the colour depth available to the interpreter.  An author may want 
to have control over whether certain images are displayed or skipped 
over if the colour depth is too low.

Any thoughts? comments?

Later,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Fri Jan 16 14:32:25 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199801152239.RAA03027@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: z-machine@gmd.de
Date: Thu, 15 Jan 1998 17:45:58 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] V6, Standard 1.0, and @set_font
Reply-To: jpenney@chelmsford.com
X-Confirm-Reading-To: jpenney@chelmsford.com
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f68eb56e3487c828d9293ba63b913583

Hi

While working on V6Lib and going through the standard I found the 
following under set_font:

"The opcode had an optional extra window operand in Version 6, but this 
has never been used and is now withdrawn from the Standard."

Why?  This seems like a perfectly reasonable thing to have to me.  We 
have it for set_colour (even if inform can't currently compile it).  Is 
there any reason this has been withdrawn other than that it has never 
been used?

Later,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Jan 24 21:27:11 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 23 Jan 1998 17:37:34 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom7
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Blorb spec
Message-Id: <Pine.SUN.3.95.980123173453.26180C-100000@netcom7>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 95e5b42b64ee14f0e73e4460bcc4721b

I just uploaded the Blorb 1.0 spec to ftp.gmd.de, /if-archive/incoming,
will live in /if-archive/infocom/interpreters/specification.

It's the same as it was back in October when I wrote the sound bits, with
one exception: I gave up and added a 'Loop' chunk to hold the "repeat
forever" flag in Lurking Horror sound files. This chunk is *only*
meaningful in V3 games that use sound. In V5, it's ignored, since the
@sound_effect opcode controls the repeat factor.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Sat Jan 24 21:27:40 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 24 Jan 1998 04:33:36 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] On perlBlorb and blurb
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <199801232122.QAA08675@ns.chelmsford.com>
Message-Id: <Marcel-1.26-0124043336-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 010b70a61419f6a56102084c5c4b9e01


                         On perlBlorb and blurb
                         ----------------------

  Jason Penney's recent "V6Lib", an Inform 6 class library providing
support for the graphical features in V6 of the Z-machine, has
highlighted the problem that it continues to be very difficult to
create pictures and sound effects for an Infocom interpreter to use.

  Andrew Plotkin's "blorb" format, which has been agreed (bar some
debate about sound formats) for a considerable time now, would change
all of this at once -- but it has yet to be supported by any
interpreter-writer.

  There is a vicious circle here -- there are no Blorb interpreters
because there are no Blorb files, and vice versa.  At the very least
it would be useful for interpreter-writers to have some Blorb files
to practice on.  Blorb files are not easy to make by hand: at some
point, programmers will need a tool to create them.  This note is just
to let people know that I've written such a program, and that I'll be
making it available very shortly, at least in rudimentary form.

  At present the program is a Perl script called "perlBlorb", and it
does the following:

      one blurb file
      picture files in PNG format   --->   one Blorb file
      sound files


  "blurb" is a language for describing Blorb files, and its syntax
is as follows.  With one exception (palette) each command occupies
one and only one line of text.  Lines are permitted to be empty or
to contain only white space.  Lines whose first non-white-space
character is an exclamation mark are treated as comments, that is,
ignored.  ("White space" means spaces and tab characters.)

   <string>   means any text within double-quotes (not containing
              either double-quote or new-line characters)

   <number>   a decimal number in the range 0 to 32767
                 
   <dim>      screen dimensions: must take the form
              <number>x<number>

   <ratio>    a fraction in the form <number>/<number>
              (0/0 is legal but otherwise numbers must be positive)

   <colour>   a colour expressed as six hexadecimal digits, as in
              some of Netscape's HTML tags: for instance F5DEB3
              is the colour of wheat, with red value F5 (on a
              scale 00, none, to FF, full), green value DE and
              blue value B3.  Hexadecimal digits may be given in
              either upper or lower case.

With the exception of "picture" and "sound", each type of command
can only occur at most once in any blurb file.  Commands can be used
in any order or not at all: an empty "blurb" file results in a
perfectly legal, if useless, Blorb file.

*  copyright <string>

   Adds this copyright declaration to the file.  It would normally
   consist of the author's name and the date.

*  release <number>

   Gives this release number to the file.  (This is the number
   returned by the opcode "@picture_data 0" within any game using
   the Blorb file, and might be used when printing out version
   information.)

*  palette 16 bit
   palette 32 bit
   palette { <colour-1> ... <colour-N> }

   Blorb allows designers to signal to the interpreter that a
   particular colour-scheme is in use.  The first two options simply
   suggest that the pictures are best displayed using (at least)
   16-bit, or 32-bit, colours -- no special palette is in use.
   The third option specifies colours used in the pictures
   in terms of red/green/blue levels, and the braces allow the
   sequence of colours to continue over many lines.  At least
   one and at most 256 colours may be defined in this way.  This is
   only a "clue" to the interpreter -- see the Blorb specification
   for details.

*  resolution <dim>
   resolution <dim> min <dim>
   resolution <dim> max <dim>
   resolution <dim> min <dim> max <dim>

   Allows the designer to to signal a preferred screen size, in real
   pixels, in case the interpreter should have any choice over this.
   The minimum and maximum values are the extreme values at which
   the designer thinks the game will be playable: they're optional,
   the default values being 0x0 and infinity x infinity.

*  sound <number> <string>

   Tells perlBlorb to take a sound sample from the named file and
   make it the sound effect with the given number.

*  picture <number> <string>
   picture <number> <string> scale <ratio>
   picture <number> <string> scale min <ratio>
   picture <number> <string> scale <ratio> min <ratio>
   ...etc.

   Similarly for pictures: the named file must be a PNG-format image.
   Optionally, the designer can specify a scale factor at which the
   interpreter will display the image -- or, alternatively, a range
   of acceptable scale factors, from which the interpreter may choose
   its own scale factor.  (The default situation is that an image is
   not scaleable and an interpreter must display it pixel-for-pixel.)

   There are three optional scale factors given: the preferred
   scale factor, the minimum and the maximum allowed.  The minimum
   and maximum each default to the preferred value if not given.
   The default preferred scale factor is 1.
   
   Scale factors are expressed as fractions: so for instance,
   
         picture 1 "flag/png" scale 3/1
         
   means "always display size", whereas

         picture 2 "backdrop/png" scale min 1/10 max 8/1
         
   means "you can display this anywhere between 1/10th normal size
   and eight times normal size, but if possible it ought to be
   just its normal size".


Here then is a simple "blurb" example file:

   !  Example "blurb" file
   
   copyright "Angela M. Horns 1998"
   release 17

   palette 16 bit

   resolution 600x400

   sound    1  "sounds/creaking.snd"
   sound    2  "sounds/wind.snd"

   picture  1  "flag.png"      scale 3/1
   picture  2  "backdrop.png"

Comments welcomed.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Sat Jan 24 21:27:48 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199801240724.CAA15189@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Sat, 24 Jan 1998 02:31:19 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] On perlBlorb and blurb
Reply-To: Z-Machine Mailing List <z-machine@gmd.de>
X-Confirm-Reading-To: Z-Machine Mailing List <z-machine@gmd.de>
X-Pmrqc: 1
Priority: normal
References: <199801232122.QAA08675@ns.chelmsford.com>
In-Reply-To: <Marcel-1.26-0124043336-0b0M+4%@gnelson.demon.co.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a6f7ac8bee11e80c55467ad132d0834e

Graham Nelson send message across the ether on 24 Jan 98 (4:33) stating:

>   There is a vicious circle here -- there are no Blorb interpreters
> because there are no Blorb files, and vice versa.  At the very least
> it would be useful for interpreter-writers to have some Blorb files
> to practice on.  Blorb files are not easy to make by hand: at some
> point, programmers will need a tool to create them.  This note is just
> to let people know that I've written such a program, and that I'll be
> making it available very shortly, at least in rudimentary form.

Am I right in thinking that the next logical step would be to create 
Blorb files for Lurking Horror, Sherlock, Zork Zero, Shogun, 
Journey, and Arthur and putting them on the archive?  Would there be any 
legal problems with this, since the image and sound files for these 
games are on the archive already?

>   At present the program is a Perl script called "perlBlorb", and it
> does the following:
> 
>       one blurb file
>       picture files in PNG format   --->   one Blorb file
>       sound files

What about the game file itself?  The Blorb Spec allows, but does not 
require that to be in the Blorb file if I'm not mistaken.

It looks great to me!  A big thanks to you Mr. Nelson.
 
Later,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Jan 24 23:18:48 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: kessinger@szs.ira.uka.de
Message-Id: <XFMail.980124120009.kessinger@szspc2.ira.uka.de>
X-Mailer: XFMail 1.1 [p0] on Linux
Date: Sat, 24 Jan 1998 12:00:09 +0100 (CET)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Organization: Studienzentrum fuer Sehgeschaedigte
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Receipt: Re: [z-machine] On perlBlorb and blurb
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 146b53dce308a84baa8ca7409cbb90da

Message opening confirmation:

The message you sent to: Z-Machine Mailing List <z-machine@gmd.de>
has been received and opened.

----------Original message header follows----------------
X-RDate: Sat, 24 Jan 1998 10:13:12 +0100 (CET)
Return-Path: <owner-z-machine@mail2.gmd.de>
Message-Id: <199801240724.CAA15189@ns.chelmsford.com>
Date: Sat, 24 Jan 1998 02:31:19 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Reply-To: Z-Machine Mailing List <z-machine@gmd.de>
X-Confirm-Reading-To: Z-Machine Mailing List <z-machine@gmd.de>
X-Pmrqc: 1
Priority: normal
References: <199801232122.QAA08675@ns.chelmsford.com>
In-Reply-To: <Marcel-1.26-0124043336-0b0M+4%@gnelson.demon.co.uk>
Precedence: bulk
XFMstatus: 0002
Sender: owner-z-machine@mail2.gmd.de
From: Jason C Penney <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] On perlBlorb and blurb

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

From ???@??? Sun Jan 25 12:22:02 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: Miron Schmidt <s590501@tfh-berlin.de>
Reply-To: miron@comports.com
To: Z-List <z-machine@gmd.de>
Date: Sat, 24 Jan 1998 10:58:25 +0100
Message-Id: <yam7328.1287.1207428312@mailhost.tfh-berlin.de>
In-Reply-To: <Marcel-1.26-0124043336-0b0M+4%@gnelson.demon.co.uk>
X-Mailer: YAM 1.3.5 [020] - Amiga Mailer by Marcel Beck
Organization: TFH-Berlin via PPP
Subject: Re: [z-machine] On perlBlorb and blurb
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 11eff670f760fb18f25d1b9ce03ef869

Graham Nelson <graham@gnelson.demon.co.uk> wrote:

This is really cool. Are you planning to compile a Zork Zero Blorb file? If
so, how? (I mean, is there a tool like pix2png?) [*]

> *  palette 16 bit
>    palette 32 bit
>    palette { <colour-1> ... <colour-N> }

>    Blorb allows designers to signal to the interpreter that a
>    particular colour-scheme is in use.  The first two options simply
>    suggest that the pictures are best displayed using (at least)
>    16-bit, or 32-bit, colours -- no special palette is in use.

I don't get that. 24-bit colours have 16.8 million possible values. The human
eye can distinguish about 3 billion colours. 32 bit allow 4.3 billion
colours. Why would I suggest that -- also taking into account that I define
the colours using a 24-bit palette anyway?

I'm obviously misunderstanding something. What?

>    The third option specifies colours used in the pictures
>    in terms of red/green/blue levels, and the braces allow the
>    sequence of colours to continue over many lines.  At least
>    one and at most 256 colours may be defined in this way.  This is
>    only a "clue" to the interpreter -- see the Blorb specification
>    for details.

The syntax for which is
        palette {
                000000
                040404
                a3c4d5
                b0b0c5
        }
Right?

[*]  I have started to index all the Zork Zero pictures. *Someone* has to do
     it. Anyone interested? Should I mail it to this list?

-- 
Miron Schmidt <miron@comports.com>

           "So, if _Space Aliens_ is Infocom on acid, what's this?"
                       -- C.E. Forman, _Detective: An Interactive MiSTing_


From ???@??? Sun Jan 25 12:22:04 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199801241800.NAA19089@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Sat, 24 Jan 1998 13:06:23 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] On perlBlorb and blurb
Reply-To: Jason C Penney <jpenney@chelmsford.com>
Priority: normal
In-Reply-To: <yam7328.1287.1207428312@mailhost.tfh-berlin.de>
References: <Marcel-1.26-0124043336-0b0M+4%@gnelson.demon.co.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ad63b2f6b3ba1df8badca71345019e7c

Miron Schmidt send message across the ether on 24 Jan 98 (10:58) 
stating:

> [*]  I have started to index all the Zork Zero pictures. *Someone* has to do
>      it. Anyone interested? Should I mail it to this list?

I'm confused about why you would need to do this.  Assuming one 
uses pix2gif, and then converts the gifs to png files, wouldn't you 
just do a blurb file with 

picture 1 "pix001.png"
picture 2 "pix002.png"
...
picture 504 "pix504.png"

I'm probably missing the point...  :(

Jay


----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sun Jan 25 12:22:07 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 24 Jan 1998 11:23:34 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom20
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] On perlBlorb and blurb (fwd)
Message-Id: <Pine.SUN.3.95.980124112320.22699D-100000@netcom20>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: aaf64e0eea6f5989a99653996a3a8e95

On Sat, 24 Jan 1998, Miron Schmidt wrote:

> Graham Nelson <graham@gnelson.demon.co.uk> wrote:
> 
> This is really cool. Are you planning to compile a Zork Zero Blorb file? 

Someone should start doing Blorb files for Lurking Horror and the
graphical games, yes. 

> If so, how? (I mean, is there a tool like pix2png?) 

http://www.boutell.com/boutell/png/PNG-Resources.html
and start looking around.

> > *  palette 16 bit
> >    palette 32 bit
> >    palette { <colour-1> ... <colour-N> }
> 
> >    Blorb allows designers to signal to the interpreter that a
> >    particular colour-scheme is in use.  The first two options simply
> >    suggest that the pictures are best displayed using (at least)
> >    16-bit, or 32-bit, colours -- no special palette is in use.
> 
> I don't get that. 24-bit colours have 16.8 million possible values. The human
> eye can distinguish about 3 billion colours. 32 bit allow 4.3 billion
> colours. Why would I suggest that -- also taking into account that I define
> the colours using a 24-bit palette anyway?

32-bit color means 8 bits per color component, and 8 bits unused (or used
for an alpha channel, which is meaningless in setting the color depth of a
display.) 16-bit means 5 bits per color component, 1 bit unused. 

You can call these "24-bit color" and "15-bit color" if you want, but I
didn't. :-) Actually "32-bit" and "16-bit" are the terms usually used for
color hardware, since the video memory really does allocate 32 and 16 bits
per pixel respectively. Some bits are unused, but it's more important to
keep the pixels memory-aligned. 

While I'm at it, saying "the human eye can distinguish 3 billion colors" 
isn't that meaningful for real applications. In a greyscale ramp in 32-bit
color -- as I defined it -- there are only 256 color bands, and the high
and low ranges show distinct edges on a CRT display. If you invented a
11-bit-per-color-component display, which is 8.6 billion colors, it's
still only 2048 bands in a greyscale ramp. I'm told that computer-stored
X-ray images really want 65536 grey levels to be useful diagnostic
information. X-rays are all greyscale, of course, so that's 16 bits per
pixel, but this implies that you'd need 48 bits per pixel in a color
image to really make the human eye happy.

--Z 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Sun Jan 25 12:22:12 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: Stephen van Egmond <svanegmo@truespectra.com>
Message-Id: <199801242031.PAA04903@plymouth.truespectra.com>
Subject: Re: [z-machine] On perlBlorb and blurb
To: miron@comports.com
Date: Sat, 24 Jan 1998 15:31:52 -0500 (EST)
Cc: z-machine@gmd.de
In-Reply-To: <yam7328.1287.1207428312@mailhost.tfh-berlin.de> from "Miron Schmidt" at Jan 24, 98 10:58:25 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cfbf3cee6c2b1b274e45888ce9dcff36


> I don't get that. 24-bit colours have 16.8 million possible values. The human
> eye can distinguish about 3 billion colours. 32 bit allow 4.3 billion
> colours. Why would I suggest that -- also taking into account that I define
> the colours using a 24-bit palette anyway?

> I'm obviously misunderstanding something. What?

My understanding of a "32-bit" colour depth (from developing for the BeOS)
is that the pallette is RGBA, where A is alpha.

/Steve

From ???@??? Sun Jan 25 12:22:16 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 24 Jan 1998 17:15:42 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199801242215.RAA08959@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] General Failure Staying on Topic.
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ea1af7bb4f0b9ffc02e906215f279099

} still only 2048 bands in a greyscale ramp. I'm told that computer-stored
} X-ray images really want 65536 grey levels to be useful diagnostic
} information.

Medical CT images use 12 bits of grayscale (nominally -1000 to 3000,
though of course the actual range is more often -1024 to 3072).  But
this is just what is stored -- what is presented to the viewer on film
or on the scanner/workstation display is still 8 bits.  The user
chooses a "window" and "level" defining the part of the 12 bit range
he wants to see.

Some low-end X-ray units store only 8 bits; most store more, but again only 8
bits are presented at a time.

We now return you to your regular discussion.

From ???@??? Sun Jan 25 12:22:24 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 24 Jan 1998 22:58:40 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] THE BLORB FILE: or, The Spy Who Came In From The Garden
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.26-0124225840-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cffcb0919fd07d23b2adfc25757bf209


I've updated perlBlorb to cover the changes in the Blorb
specification since yesterday (anything to sound dramatic: all
that happened was that Andrew uploaded v 1.0 to ftp.gmd.de) and
made it available from my Web page, at the URL

  http://www.gnelson.demon.co.uk/blorb/

There's also a better specification of "blurb", which I've tidied
up a little... and (short fanfare) an example game with a supplied
Blorb file, called "The Spy Who Came In From The Garden".  This
contains AIFF sound effects but no music or images, and is a
straightforward Version 5 file making only the simplest possible
use of the "sound_effect" opcode.  The idea is that interpreter
maintainers can get basic Blorb support working fairly easily and
quickly, without worrying about pictures for the time being;
and even interpreters which don't handle Version 6 can still
usefully support Blorb, as this game demonstrates.

I'd say this is my best game since "The Tempest", so be sure
not to miss it.

As ever with Demon Internet Services PLC, these pages just may take
a short while to appear from your point of view, depending on where
you live on the Internet.  (I don't pretend to understand this.)

Blorb now!

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Sun Jan 25 16:21:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 24 Jan 1998 20:09:36 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom8
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] THE BLORB FILE: or, The Spy Who Came In From The Garden
In-Reply-To: <Marcel-1.26-0124225840-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.980124200235.18364E-100000@netcom8>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9d864e1fabfb81c4592c963a9177b6e9

On Sat, 24 Jan 1998, Graham Nelson wrote:

> I've updated perlBlorb to cover the changes in the Blorb
> specification since yesterday (anything to sound dramatic: all
> that happened was that Andrew uploaded v 1.0 to ftp.gmd.de) and
> made it available from my Web page, at the URL
> 
>   http://www.gnelson.demon.co.uk/blorb/

Just to make Graham update this page, I've put up my own Blorb page:

http://www.edoc.com/zarf/blorb/
  
This includes the spec in text, HTML, and PostScript format. Now *that's*
sexy.

Actually, please tell me if the HTML and PS look right. I'm generating all
three versions from a common source file, using my own wacky tool, and the
PS part has never been seriously tested. It's nice clean PS though. Barely
three times the size of the raw text file. Gloat, gloat.

(The text file isn't exactly the one I posted to ftp.gmd.de. I fixed one
typo, added a "rationale" note about the different sound formats, and the
wacky tool changed the indentation a bit. But the actual format
specification is unchanged.) 

> Blorb now!

Indubitably.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Sun Jan 25 17:51:54 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 24 Jan 1998 21:41:52 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom11
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] THE BLORB FILE: or, The Spy Who Came In From The Garden
In-Reply-To: <Marcel-1.26-0124225840-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.980124213751.24194A-100000@netcom11>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6730aef1593853a1f310e0658e7b34dd

On Sat, 24 Jan 1998, Graham Nelson wrote:

> and (short fanfare) an example game with a supplied
> Blorb file, called "The Spy Who Came In From The Garden". 

You're a dead man, Graham Nelson. A dead man.

--Z (although it doesn't seem to interfere with your Perl coding)

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Jan 26 11:08:28 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sun, 25 Jan 1998 09:39:26 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom8
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Blorb spec
In-Reply-To: <v03110700b0f104e5892b@[130.244.108.143]>
Message-Id: <Pine.SUN.3.95.980125093337.15314B-100000@netcom8>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 56fd138ac85e8a47120b18a52eff9209

On Sun, 25 Jan 1998, Petter [iso-8859-1] Sjölund wrote:

> One more question for section 14: Rationales and Rationalizations.
> 
> -Why not MPEG Audio Layer-3 support?
> 
> Aiff is really too bulky to transport across the Internet, and mp3 is the
> closest so far to an Internet standard format for CD-quality music.

I asked around (both on this mailing list and among friends.) Nobody
actually understood what the MPEG-3 spec *was*. Except that it was
monstrous and huge and unwieldy.

Maybe someday.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Jan 26 11:08:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980125210703.1350.qmail@hotmail.com>
X-Originating-Ip: [144.126.195.141]
From: "Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Blorb spec
Content-Type: text/plain
Date: Sun, 25 Jan 1998 16:07:03 EST
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b4b92459dbc38aed3668fb5b980c0aaa



>Date: Sun, 25 Jan 1998 09:39:26 -0800 (PST)
>From: Andrew Plotkin <erkyrath@netcom.com>
>To: Z-Machine List <z-machine@gmd.de>
>Subject: Re: [z-machine] Blorb spec
>
>On Sun, 25 Jan 1998, Petter [iso-8859-1] Sj=F6lund wrote:
>
>> One more question for section 14: Rationales and Rationalizations.
>>=20
>> -Why not MPEG Audio Layer-3 support?
>>=20
>> Aiff is really too bulky to transport across the Internet, and mp3 is 
the
>> closest so far to an Internet standard format for CD-quality music.
>
>I asked around (both on this mailing list and among friends.) Nobody
>actually understood what the MPEG-3 spec *was*. Except that it was
>monstrous and huge and unwieldy.

THat about sums it up.  Mpeg3 is a pretty marvelous format, yes, but 
you're still talking about the kind of file that takes my LAN connection 
a few minutes to download.  Not to mention that they're hardware 
intensive.  Any computer slower than a 100+ Mhz Pentium is SOL playing 
them, and (as my personal experience has shown) if your soundcard 
doesn't use a wavetable, even a Pentium 2 has a little trouble 
multitasking while playing high-quality mp3.

But there's a point ot be made here; AIFF certainly is unweildy as a 
format.  So far, I've worked mostly with Infocom's Amiga format (which, 
lemmetellya is not the way to go...)and I wrote a treitse a few years 
back on the common audio formats.  I've I'm growing to be of the opinion 
that we're up something as far as audio formats go.

This may sound like treaspon, but maby we should start looking ar the 
more arcane audio formats; something with the specific limitations and 
capabilities we need.

As soon as we work out what we need.



______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From ???@??? Mon Jan 26 11:08:32 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: Miron Schmidt <s590501@tfh-berlin.de>
Reply-To: miron@comports.com
To: Z-List <z-machine@gmd.de>
Date: Sun, 25 Jan 1998 11:03:17 +0100
Message-Id: <yam7329.865.1207582496@mailhost.tfh-berlin.de>
In-Reply-To: <199801241800.NAA19089@ns.chelmsford.com>
X-Mailer: YAM 1.3.5 [020] - Amiga Mailer by Marcel Beck
Organization: TFH-Berlin via PPP
Subject: Re: [z-machine] Indexing Zork Zero pictures?
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: fb6386202399cd609736f4f0036af26e

Jason C Penney <jpenney@chelmsford.com> wrote:
> Miron Schmidt send message across the ether on 24 Jan 98 (10:58) 
> stating:

> > [*]  I have started to index all the Zork Zero pictures. *Someone*
> >      has to do it. Anyone interested? Should I mail it to this list?

> I'm confused about why you would need to do this. [...]
> I'm probably missing the point...  :(

Yes. I mean I have started to list all Zork Zero pictures with a short
description of each picture's purpose. I found it rather tedious having to
look through a huge bunch of GIFs every time I was looking for a specific
picture.

Now the real question is: Does that make sense? How did *you* find the
compass rose pictures? Is there already such an index? (Or why doesn't
anybody seem to need one?)

-- 
Miron Schmidt <miron@comports.com>

           "So, if _Space Aliens_ is Infocom on acid, what's this?"
                       -- C.E. Forman, _Detective: An Interactive MiSTing_


From ???@??? Mon Jan 26 11:08:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
X-Sender: mv27846@venus.swip.net (Unverified)
Message-Id: <v03110700b0f104e5892b@[130.244.108.143]>
In-Reply-To: <Pine.SUN.3.95.980123173453.26180C-100000@netcom7>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Date: Sun, 25 Jan 1998 17:55:10 +0200
To: "Recipient.List.Suppressed":  ;
From: Petter Sjölund  <petter.sjolund@swipnet.se>
Subject: Re: [z-machine] Blorb spec
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 2ba3a2e747e3e754a23a2aa19de406cd

One more question for section 14: Rationales and Rationalizations.

-Why not MPEG Audio Layer-3 support?

Aiff is really too bulky to transport across the Internet, and mp3 is the
closest so far to an Internet standard format for CD-quality music.

Somehow that would make the idea of including music in interactive fiction
less horrible.

Petter Sjölund
----------------------------------------------------
Stockholmsvägen 53
S-182 74 Stocksund
Sweden
Phone +46 (8) 85 43 34
----------------------------------------------------


From ???@??? Mon Jan 26 15:17:44 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199801260259.VAA05199@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Sun, 25 Jan 1998 22:05:28 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] V6 Menus
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6aa8cdd8654c5728040c2dcdf9c5e1f4

Hi,

I'm trying to figure out how V6 Menus work.  The ZSPec explains how to 
use make_menu to create a new menu, but after that I don't know what to 
do.  Is make_menu supposed to display the menu? if not how is this done? 
Maybe I'm misunderstanding the whole thing...  Does anyone have any 
info/ideas about how V6 menus work?

Thanks,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Mon Jan 26 18:58:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sun, 25 Jan 1998 22:41:08 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom5
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Menus
In-Reply-To: <199801260259.VAA05199@ns.chelmsford.com>
Message-Id: <Pine.SUN.3.95.980125223314.12645A-100000@netcom5>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 4ec78d7cb2c15d6f3ac8485d462b48e0

On Sun, 25 Jan 1998, Jason C Penney wrote:

> I'm trying to figure out how V6 Menus work.  The ZSPec explains how to 
> use make_menu to create a new menu, but after that I don't know what to 
> do.  Is make_menu supposed to display the menu?

If I'm reading this thing right (Z-Spec 10.4), yes, make_menu displays the
menu in the menu bar. (The GUI's menu bar -- well, the Mac's menu bar,
since Infocom only implemented this stuff on the Mac. I guess in Windows
it would be the window menu bar.)

When the player chooses a menu option, if a @read_char is pending, the
interpreter should return keycode 252. If @read is pending, and 252 is a
terminating character, the line input terminates. Either way, you
determine the menu option by calling @read_mouse.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Jan 26 19:39:24 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199801260711.CAA07721@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Mon, 26 Jan 1998 02:18:01 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] V6 Menus
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <199801260259.VAA05199@ns.chelmsford.com>
In-Reply-To: <Pine.SUN.3.95.980125223314.12645A-100000@netcom5>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1bb9c42312c1c79bd784d4d3debf44c4

Andrew Plotkin send message across the ether on 25 Jan 98 (22:41) 
stating:

> On Sun, 25 Jan 1998, Jason C Penney wrote:
> 
> > I'm trying to figure out how V6 Menus work.  The ZSPec explains how to 
> > use make_menu to create a new menu, but after that I don't know what to 
> > do.  Is make_menu supposed to display the menu?
> 
> If I'm reading this thing right (Z-Spec 10.4), yes, make_menu displays the
> menu in the menu bar. (The GUI's menu bar -- well, the Mac's menu bar,
> since Infocom only implemented this stuff on the Mac. I guess in Windows
> it would be the window menu bar.)

Well there's something else to add to my portable version 6 machine type 
proposal/discussion with myself:  a way to tell if the interpreter will 
handle these menus or not.

> When the player chooses a menu option, if a @read_char is pending, the
> interpreter should return keycode 252. If @read is pending, and 252 is a
> terminating character, the line input terminates. Either way, you
> determine the menu option by calling @read_mouse.

Oddly enough, I understood all that.  I didn't realize that these were 
outside of game menus.  I knew I was doing something wrong when I saw 
the note in the spec about it only being used on Macs right after I had 
send the mail off (unfortunately the note in the spec is nowhere near 
where I was looking for info on @make_menu... :(  ).

So, new question:  Would anyone ever implement these in an interpreter?  
Is there any point?  Might be a nice place to put sound toggles or 
something... but is the novelty worth the effort?

Thanks,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Mon Jan 26 21:31:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 26 Jan 1998 01:14:13 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Menus
In-Reply-To: <199801260711.CAA07721@ns.chelmsford.com>
Message-Id: <Pine.BSI.3.95.980126011058.455A-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 384ebf98fa8f9cdcc9764c656ebd10d3

On Mon, 26 Jan 1998, Jason C Penney wrote:

>Well there's something else to add to my portable version 6 machine type 
>proposal/discussion with myself:  a way to tell if the interpreter will 
>handle these menus or not.

If I'm not mistakin, isn't there a header bit that determins menu
availability?

>So, new question:  Would anyone ever implement these in an interpreter?  
>Is there any point?  Might be a nice place to put sound toggles or 
>something... but is the novelty worth the effort?

It should be possable to implemint these on any interpreter that runs in a
GUI enviorment (even GEOS on the C64 I would guess).  The source code for
Frotz already has a routine open for this, but it is blank on the Amiga
port.

Patrick
[ "i", "1" and "T" keys are messed up, please ignore any errors. ]
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Tue Jan 27 02:41:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 26 Jan 1998 09:02:08 -0500 (EST)
From: Mark J Musante <olorin@world.std.com>
To: Andrew Plotkin <erkyrath@netcom.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Menus
In-Reply-To: <Pine.SUN.3.95.980125223314.12645A-100000@netcom5>
Message-Id: <Pine.SGI.3.95.980126090054.4312E-100000@world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c0b29c19ac129a8cd585bbddffd24441

On Sun, 25 Jan 1998, Andrew Plotkin wrote:
> 
> If I'm reading this thing right (Z-Spec 10.4), yes, make_menu displays the
> menu in the menu bar. (The GUI's menu bar -- well, the Mac's menu bar,
> since Infocom only implemented this stuff on the Mac. I guess in Windows
> it would be the window menu bar.)

Really?  Mac only?  I could have sworn it was implemented on the Amiga
too.


  -=- Mark -=-

From ???@??? Fri Jan 30 18:26:14 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 26 Jan 1998 15:47:46 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Blorb spec
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.SUN.3.95.980125093337.15314B-100000@netcom8>
Message-Id: <Marcel-1.26-0126154746-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ea6e474d432977d3c2e10c0639439727


  I wonder if I can encourage some kind person to try to write a
portable bit of C code which would handle Blorb files?  Even if
only to do the menial things, such as reading in the data, working
out where things are, verifying that the Blorb file matches the
story file, and so on.  In other words, to do everything Blorb-
related except the actual plotting of PNG images and the actual
playing of AIFFs and other sounds.

  The availability of some generic C code for Quetzal saved-game
handling seemed to be a great help in getting Quetzal going, so
perhaps this would be as helpful to Blorb.  Umm... I suppose that
criminal mastermind, the Plotkin himself, might be a possible
candidate?

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Fri Jan 30 18:26:24 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 26 Jan 1998 12:17:07 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom3
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Blorb spec
In-Reply-To: <Marcel-1.26-0126154746-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.980126121432.22043A-100000@netcom3>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 413de5eec76b6aac1ad6d41b14dada03

On Mon, 26 Jan 1998, Graham Nelson wrote:

>   I wonder if I can encourage some kind person to try to write a
> portable bit of C code which would handle Blorb files?  Even if
> only to do the menial things, such as reading in the data, working
> out where things are, verifying that the Blorb file matches the
> story file, and so on.  In other words, to do everything Blorb-
> related except the actual plotting of PNG images and the actual
> playing of AIFFs and other sounds.
> 
>   The availability of some generic C code for Quetzal saved-game
> handling seemed to be a great help in getting Quetzal going, so
> perhaps this would be as helpful to Blorb.  Umm... I suppose that
> criminal mastermind, the Plotkin himself, might be a possible
> candidate?

Yeah, just like my portable C code for Pickle really made Pickle take off.
Thpbpbpt.

I also resent being called a criminal mastermind for Blorb when it's
Glk that I really want to take over the world.

Nonetheless, yes, I will write some handy library code. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Jan 30 18:26:25 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: "--- Z-machine" <z-machine@gmd.de>
Subject: Re: [z-machine] Blorb spec
Date: Mon, 26 Jan 1998 21:09:38 +0100
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19980126202610.AAD8937@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 786f7a3f03608a757ee5073b02abc9e8


> It's the same as it was back in October when I wrote the sound bits, with
> one exception: I gave up and added a 'Loop' chunk to hold the "repeat
> forever" flag in Lurking Horror sound files. This chunk is *only*
> meaningful in V3 games that use sound. In V5, it's ignored, since the
> @sound_effect opcode controls the repeat factor.

Hm, I heartily regret the day when I decided not to use the WAV format for
Infocom sound effects because the loop information didn't fit in.  Recent
releases of Frotz have the loop information for Lurking Horror wired into
the code which solves the problem.  I'd be happy if we removed this 'Loop'
chunk from the Blorb Spec.

-- Stefan


From ???@??? Fri Jan 30 18:26:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199801262046.PAA16314@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Mon, 26 Jan 1998 15:53:10 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Blorb spec
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <Marcel-1.26-0126154746-0b0M+4%@gnelson.demon.co.uk>
In-Reply-To: <Pine.SUN.3.95.980126121432.22043A-100000@netcom3>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8e7339f9d8ce8b33dc9050e4c10d5712

Andrew Plotkin send message across the ether on 26 Jan 98 (12:17) 
stating:

> Yeah, just like my portable C code for Pickle really made Pickle take off.
> Thpbpbpt.

I pushed for Pickle support... but it didn't work.  I didn't push very 
hard though.
 
> Nonetheless, yes, I will write some handy library code. 

You are a wonderful person.

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Fri Jan 30 18:26:29 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 26 Jan 1998 13:25:19 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom3
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Blorb spec
In-Reply-To: <19980126202610.AAD8937@jokisch>
Message-Id: <Pine.SUN.3.95.980126131825.17009A-100000@netcom3>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 268ff37c16ef9ea89330aaa82eb7f596

On Mon, 26 Jan 1998, Stefan Jokisch wrote:

> > It's the same as it was back in October when I wrote the sound bits, with
> > one exception: I gave up and added a 'Loop' chunk to hold the "repeat
> > forever" flag in Lurking Horror sound files. This chunk is *only*
> > meaningful in V3 games that use sound. In V5, it's ignored, since the
> > @sound_effect opcode controls the repeat factor.
> 
> Hm, I heartily regret the day when I decided not to use the WAV format for
> Infocom sound effects because the loop information didn't fit in.  Recent
> releases of Frotz have the loop information for Lurking Horror wired into
> the code which solves the problem.  I'd be happy if we removed this 'Loop'
> chunk from the Blorb Spec.

The v3 format may have been declared dead, but I was convinced that it's
ugly to *mandate* hardwiring all sound-capable interpreters for Lurking
Horror. This way at least there's a choice.

If you want, you can always keep your hardwiring and ignore the looping
chunk. The result is that the only V3-with-sound game your interpreter
will work for is Lurking Horror. That's the same practical result that
would be produced by your suggestion.

And I doubt anyone will complain, in any case. :)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Jan 30 18:27:31 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: Mark <mark_k@iname.com>
To: Z-Machine list <z-machine@gmd.de>
Date: Tue, 27 Jan 1998 20:26:29 GMT
Message-Id: <yam7331.1483.3825400@mail.iname.com>
In-Reply-To: <Pine.SGI.3.95.980126090054.4312E-100000@world.std.com>
X-Mailer: YAM 1.3.5 [020] - Amiga Mailer by Marcel Beck
Subject: Re: [z-machine] V6 Menus
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 27d9e55a07a9a6abde64f50f75e2dda1

On 26-Jan-98, Mark J Musante wrote:
>On Sun, 25 Jan 1998, Andrew Plotkin wrote:
>> 
>> If I'm reading this thing right (Z-Spec 10.4), yes, make_menu displays the
>> menu in the menu bar. (The GUI's menu bar -- well, the Mac's menu bar,
>> since Infocom only implemented this stuff on the Mac. I guess in Windows
>> it would be the window menu bar.)

>Really?  Mac only?  I could have sworn it was implemented on the Amiga
>too.

No, Infocom's Amiga V6 interpreters just contain a dummy routine for the menu
functions (as I recall; it has been a while since I looked at the disassembly).


-- Mark

From ???@??? Fri Jan 30 18:27:38 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 27 Jan 1998 18:13:24 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom12
To: Graham Nelson <graham@gnelson.demon.co.uk>,
        Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] blurb bug (or, possibly, spec bug)
In-Reply-To: <Marcel-1.26-0124225840-0b0M+4%@gnelson.demon.co.uk>
Message-Id: <Pine.SUN.3.95.980127174309.28640A-100000@netcom12>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b2f79ff681cd431488b42e9316f35940

On Sat, 24 Jan 1998, Graham Nelson wrote:

> I've updated perlBlorb to cover the changes in the Blorb
> specification since yesterday (anything to sound dramatic: all
> that happened was that Andrew uploaded v 1.0 to ftp.gmd.de) and
> made it available from my Web page, at the URL

Got a problem here. There's an unobvious point in the IFF spec, which I
followed when writing the Blorb document.

A Blorb file's format is:

 4 bytes    'FORM'    Chunk type (indicates IFF chunked format)
 4 bytes    n         Data length
 4 bytes    'IFRS'    Type of this 'FORM'  
 n-4 bytes  ...       Data (list of chunks)

Each resource (PNG image, AIFF sound, MOD song, etc) occupies one chunk. 
A chunk consists of a four-byte type field, a four-byte length field, and
then some data. 

But an AIFF file (unlike the other types) is an IFF chunked format; it
*already* begins with a four-byte type field and a four-byte length.
Therefore, you're not supposed to stick on another eight bytes of
(redundant) header info.

That is, if I'm including a 1000-byte PNG file in Blorb, the chunk looks
like this:

 4 bytes    'PNG '    Chunk type
 4 bytes    1000      Chunk length
 1000 bytes ...       PNG data

But if I'm including a 1000-byte AIFF file, the chunk is simply:

 1000 bytes ...       AIFF data

and this is ok because the format of the AIFF will be:

 4 bytes    'FORM'    Chunk type (indicates IFF chunked format)
 4 bytes    992       Data length
 4 bytes    'AIFF'    Type of this 'FORM'
 988 bytes  ...       Data (list of chunks)

The point of this (and a major point of IFF) is that an IFF file *is* a
chunk. Compare the AIFF and Blorb definitions I just gave with the
definition of an arbitrary chunk.

If every data type in Blorb was an IFF chunked format, you could compile
the Blorb file just by concatenating the data files. That was what the
creators of IFF were envisioning.

Now obviously that all-IFF world has not occurred. Nonetheless, I'd rather
go by the IFF spec. 

That would mean that the current version of blurb, and Graham's sample
Blorb files, are incorrect. 

Basically, any data file that begins with 'FORM' and a data length should
be concatenated directly instead of having a type/length header stuck on.
It's not in principle an AIFF-specific exception. (Although of course
that's the way it works out in practice.)

Argument?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Jan 30 18:28:20 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 28 Jan 1998 13:48:42 -0500 (EST)
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] blurb bug (or, possibly, spec bug)
In-Reply-To: <Pine.SUN.3.95.980127174309.28640A-100000@netcom12>
Message-Id: <Pine.SGI.3.95.980128134745.11488C-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9ba7a684882c5a74fe27d34e548da506

> The point of this (and a major point of IFF) is that an IFF file *is* a
> chunk. Compare the AIFF and Blorb definitions I just gave with the
> definition of an arbitrary chunk.
>
> If every data type in Blorb was an IFF chunked format, you could compile
> the Blorb file just by concatenating the data files. That was what the
> creators of IFF were envisioning.

> Argument?

  I'm not particularly active around here, but no.


___Dan_Knapp____The_Mauve_Baron______________________Beep Blip Bonk_______
<dankna@bergen.org><dankna@brain.mics.net> http://users.bergen.org/~dankna
Visit rec.games.video.classic and find out about Pac-Man's contemporaries!
Memo to self:  Turn computer off before removing ROM.

From ???@??? Fri Jan 30 18:29:02 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199801290522.AAA02755@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Thu, 29 Jan 1998 00:29:16 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] [Blorb] Files for Arthur, Journey, Shogun, and Zork0 up
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 578e8643acc5c2610ec6253c1e56eebe

Hi,

I put Blorb files for all the Version 6 Infocom games:
<http://www.chelmsford.com/home/jpenney/V6Lib/blorb/>

I think they are correct, but I don't want to upload them to GMD until 
somebody else thinks they are correct as well.  Once perlBlorb is 
updated to include AIFF files correctly, who is going to do the Lurking 
Horror and Sherlock?

Enjoy,
Jay


----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Fri Jan 30 18:30:06 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 29 Jan 1998 14:30:14 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] perlBlorb 1.02
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.26-0129143014-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: fc717148f63ef48b1bf3da7c4b607c89


For anyone interested in the ongoing development of "Blorb", my
web page

  http://www.gnelson.demon.co.uk/blorb/

has just been updated and now contains perlBlorb 1.02, fixing the
AIFF chunk problem reported by Andrew, and also working on Windows/
DOS machines with text file translation problems.

Blorb Now!

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Fri Jan 30 18:30:26 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 29 Jan 1998 10:56:31 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom18
To: Jason C Penney <jpenney@chelmsford.com>,
        Graham Nelson <graham@gnelson.demon.co.uk>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] [Blorb] Files for Arthur, Journey, Shogun, and Zork0 up
In-Reply-To: <199801290522.AAA02755@ns.chelmsford.com>
Message-Id: <Pine.SUN.3.95.980129105300.12154B-100000@netcom18>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 331e77094423b836a87e5044985db3d3

On Thu, 29 Jan 1998, Jason C Penney wrote:

> Hi,
> 
> I put Blorb files for all the Version 6 Infocom games:
> <http://www.chelmsford.com/home/jpenney/V6Lib/blorb/>
> 
> I think they are correct, but I don't want to upload them to GMD until 
> somebody else thinks they are correct as well.

Guess what. :-)

perlBlorb writes the Z-code header chunk as 'IFHd'. It should be 'IFhd'.
Lower-case h.

Because that's the way it's done in Quetzal, that's why.

The fix to perlBlorb.pl is obvious. Rebuild, re-upload, recycle, hopefully
we've got it right now...

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Jan 30 18:30:35 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 29 Jan 1998 13:12:02 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom18
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] blorblib 1.0
Message-Id: <Pine.SUN.3.95.980129130633.3763A-100000@netcom18>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: eec51a08e82e5446b2ef985d6ca7a2f9

See my page at

http://www.edoc.com/zarf/blorb/

The package (blorblib-10.tar.Z) contains source code for blorblib, a
library which loads resources and other data from a Blorb file. Blorblib
is intended for Z-machine interpreters.

It also contains source for blorbscan, a program which analyzes a Blorb
file in detail. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Jan 30 18:30:54 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 30 Jan 1998 01:04:36 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] perlBlorb 1.03
To: Z-Machine Mailing List <z-machine@gmd.de>
Cc: Andrew Plotkin <erkyrath@netcom.com>
Message-Id: <Marcel-1.26-0130010436-b49M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f3f8b9a48b8b88719c34cb0f9a7093fa


For a second time my Blorb page,

  http://www.gnelson.demon.co.uk/blorb/

has been updated to fix a bug pointed out by Andrew (IFhd being
spelt IFHd) and to slightly improve perlBlorb, now at version 1.03.

I swear I'm not doing all this correction and re-correction to
draw attention to Blorb, but, as we're here... viva Blorb.

   G.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Sun Feb 01 17:05:38 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 31 Jan 1998 12:55:36 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom15
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] blorblib 1.0.1
In-Reply-To: <Pine.SUN.3.95.980129130633.3763A-100000@netcom18>
Message-Id: <Pine.SUN.3.95.980131125415.4877B-100000@netcom15>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ee71011a22be343e93dce66993736e4b

Now updated so that it works on small-endian systems. Sorry for the goof. 

On Thu, 29 Jan 1998, Andrew Plotkin wrote:
> See my page at
> 
> http://www.edoc.com/zarf/blorb/
> 
> The package (blorblib-10.tar.Z) contains source code for blorblib, a
> library which loads resources and other data from a Blorb file. Blorblib
> is intended for Z-machine interpreters.
> 
> It also contains source for blorbscan, a program which analyzes a Blorb
> file in detail. 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Mon Feb 02 12:29:24 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802012041.PAA11749@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Sun, 1 Feb 1998 15:47:39 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] Sound File request.
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 771eea824779b48f379c1f401a76c6a5

Hi,

Since no one has come forward to try and make Lurking Horror and 
Sherlock Blorb files I've decided to try.  I didn't get far as I've been 
unable to convert all the sounds to AIFF (I found a DosSox with Infocom 
support in them, but it made bad files for some of the sounds).

If someone could either point me in the right direction, or convert the 
sounds for me and send me a zip file of them I'd really appreciate it.

Thanks,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Mon Feb 02 12:29:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sun, 1 Feb 1998 14:00:28 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Sound File request.
In-Reply-To: <199802012041.PAA11749@ns.chelmsford.com>
Message-Id: <Pine.BSI.3.95.980201135905.26722A-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d35388d74ee79f16480d124f2b3fc5a6

On Sun, 1 Feb 1998, Jason C Penney wrote:

>Since no one has come forward to try and make Lurking Horror and 
>Sherlock Blorb files I've decided to try.  I didn't get far as I've been 
>unable to convert all the sounds to AIFF (I found a DosSox with Infocom 
>support in them, but it made bad files for some of the sounds).
>
>If someone could either point me in the right direction, or convert the 
>sounds for me and send me a zip file of them I'd really appreciate it.

I would if I could, but the Amiga version of SOX doesn't include Infocom
support and I had no luck recompiling the program :-(

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Wed Feb 04 11:22:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802021739.MAA24215@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Mon, 2 Feb 1998 12:45:29 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 56568da76706fb9f83512e8ad2432dd9

Hi,

Based on feedback and "bug reports" I have been getting on V6Lib it is
apparent that there needs to be some sort of machine independent V6
Z-Machine.  Since many interpreters will (hopefully) be adding Blorb
support in the near future, I'm going to haul this out again now, in 
hopes of getting it done at the same time.

I've listed four questions.  I feel that there should either be a new
machine type identifier that answers all these questions "Yes!" or a
header extension that the interpreter could set flags in.

Where I refer to the Amiga, I'm speaking from experience with Dos
Frotz in Amiga mode.  I've had reports from users of Amiga Frotz that
imply that the same features exist there.

I've used the Amiga interpreter as a starting point for my examples,
since it looks nicer in general.  There are some other problems (such as
drawing an image can change the screens current pallette) that I assume
will go away with Blorb support.

Is the Amiga palette provided?
==========
Currently the Amiga offers an extra 2 shades of grey.  It's nice!

Can each window have its own colour pair?
==========
Currently on the Amiga all windows share one set of values.  There are
some exceptions.  You can give a window a pair of colours that is
opposite to all other windows' colour pairs.  And it is possible to print
over an image, in either of the two colours shared my most windows, using
a colour retrieved from the image.

Can the interpreter print in multiple text colours
==========
Currently on the Amiga this is not possible.  If you change colours in
any window, all text on the screen changes with it.  This means if I want
to print one word green, all text on the screen will flash in green and
then return to whatever colour was previously displayed.

Can use the interpreter display multiple font styles
==========
Currently there is no way to tell what will happen if I do the
following: 
 style fixed;
 style bold;

I now have either the fixed width style in bold, or I have the roman
style in bold.

Please post any ideas or arguments you have.  Even if you just think I'm
a raving lunatic for bringing this up all the time.  I've gotten four or
five emails from V6Lib users over the weekend wondering why these things
don't seem to work.

Thanks,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Wed Feb 04 11:23:45 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 3 Feb 1998 01:20:41 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Z-Machine Stuff
In-Reply-To: <199802021739.MAA24215@ns.chelmsford.com>
Message-Id: <Pine.BSI.3.95.980203010806.10103B-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b0820264204d48f016d122f4475f39bf

On Mon, 2 Feb 1998, Jason C Penney wrote:

>Where I refer to the Amiga, I'm speaking from experience with Dos
>Frotz in Amiga mode.  I've had reports from users of Amiga Frotz that
>imply that the same features exist there.

Well, I haven't used it (I'll have to download it and try it in an
emulator sometime) but I'm not sure about the text colour prob you
describe below.

>Is the Amiga palette provided?
>==========
>Currently the Amiga offers an extra 2 shades of grey.  It's nice!

The Amiga pallette set should be the standard, it allows the most colours
without loosing any.  But, it makes the difference between an 8 colour
screen and a 16 colour screen (n the Amiga at least) so maybe it should be
a header bit?  I don't know.

>Can each window have its own colour pair?
>==========

This should be the standard, even the Amiga can do this.  I really don't
understand why Infocom chose to limit their Amiga interpreters, I don't
belive this was ever a limitation of the Amiga hardware.

>Can the interpreter print in multiple text colours
>==========
>Currently on the Amiga this is not possible.  If you change colours in
>any window, all text on the screen changes with it.  This means if I want
>to print one word green, all text on the screen will flash in green and
>then return to whatever colour was previously displayed.

I belive this was a bug in Infocoms interpreters.  I know on every version
except 6 it works correctly (in AmigaFrotz).  I'll try and check V6 when I
get some free time (free time, what's that?)

>Can use the interpreter display multiple font styles
>==========
>Currently there is no way to tell what will happen if I do the
>following: 
> style fixed;
> style bold;

I think this should be a header bit, on some machines (which ones?) it may
be imposable to do this.  I think it's better to be safe and keep this
optional.

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Wed Feb 04 11:23:49 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <01BD309B.739AA260.davidk@monis.co.uk>
From: David Kinder <davidk@monis.co.uk>
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: RE: [z-machine] V6 Z-Machine Stuff
Date: Tue, 3 Feb 1998 12:01:24 -0000
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7c3651727d10021d3259a4f6edfc5d05

On Tuesday, February 03, 1998 9:21 AM, Patrick [SMTP:patrick@syix.com] wrote:

I suspect it would be better to create a new interpreter machine number, for which
we can define an acceptable set of basic properties (256 colours, etc.). The
Amiga mode in Frotz is a start, but there are limitations on the Amiga mode caused
by the fact that Infocom wrote their interpreter to work on a machine which can
only display 16 colours onscreen at once.

> >Can each window have its own colour pair?

> This should be the standard, even the Amiga can do this.  I really don't
> understand why Infocom chose to limit their Amiga interpreters, I don't
> belive this was ever a limitation of the Amiga hardware.

The problem is that on the Amiga 500, you've only got a 16 colour screen. 14 of
those are used for the picture palette, leaving only two for text. So in Amiga
mode, you can't have different windows with different text colours.


David Kinder            mailto:davidk@monis.co.uk
Monis Software          http://www.monis.co.uk/
126-134 Baker Street    Tel: +44 171 935 3336
LONDON                  Fax: +44 171 935 6663
W1M 1FH

From ???@??? Wed Feb 04 11:23:53 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802031301.IAA07742@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Tue, 3 Feb 1998 08:08:20 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <01BD309B.739AA260.davidk@monis.co.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d685939f5afd9bc6b00cc3c1e0b66d63

David Kinder sent a message across the ether on  3 Feb 98 (12:01) 
stating:

> I suspect it would be better to create a new interpreter machine number, for which
> we can define an acceptable set of basic properties (256 colours, etc.). The
> Amiga mode in Frotz is a start, but there are limitations on the Amiga mode caused
> by the fact that Infocom wrote their interpreter to work on a machine which can
> only display 16 colours onscreen at once.

This was my original idea back in September, but (almost) nobody agreed 
with me.  Because some machines will never be able to do all this (Amiga 
500), they could still report the Amiga interpreter number.

Jay


----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Wed Feb 04 11:23:54 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 3 Feb 1998 05:31:16 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: RE: [z-machine] V6 Z-Machine Stuff
In-Reply-To: <01BD309B.739AA260.davidk@monis.co.uk>
Message-Id: <Pine.BSI.3.95.980203052626.14883A-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: fc8830a714ed511f0f9daacf8470820c

On Tue, 3 Feb 1998, David Kinder wrote:

>I suspect it would be better to create a new interpreter machine number, for which
>we can define an acceptable set of basic properties (256 colours, etc.). The

256 colours would be nice.  Question though, should these be mapped to to
a specific pallette?

>Amiga mode in Frotz is a start, but there are limitations on the Amiga mode caused
>by the fact that Infocom wrote their interpreter to work on a machine which can
>only display 16 colours onscreen at once.

Why didn't they use HAM mode?  (beside the fact that it's a royal pain).
Also, I thought the 500 (ECS) allowed 32 colours?  I've only used ECS/OCS
Amigas on rare occasions so this is kinda new for me.

>The problem is that on the Amiga 500, you've only got a 16 colour screen. 14 of
>those are used for the picture palette, leaving only two for text. So in Amiga
>mode, you can't have different windows with different text colours.

Ok, but why make the destinction between the picture palette and text
colours?  Why not just remap the text colours to the nearest picture
pallette colour?

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Wed Feb 04 11:23:56 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <01BD30AD.B7504B10.davidk@monis.co.uk>
From: David Kinder <davidk@monis.co.uk>
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: RE: [z-machine] V6 Z-Machine Stuff
Date: Tue, 3 Feb 1998 14:12:08 -0000
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a8691d2640d6cfcad0073bdcb006ef03

On Tuesday, February 03, 1998 1:31 PM, Patrick [SMTP:patrick@syix.com] wrote:

> 256 colours would be nice.  Question though, should these be mapped to to
> a specific pallette?

Probably not. Trying to map any picture to an arbitrary palette (e.g. the standard
Windows colours) quickly reveals how few 256 colours actually is. Pictures should
be either 256 colours in an arbitrary palette, or true colour. In either case it
would be up to the interpreter to reduce the colour information to a level it could
display.

> Why didn't they use HAM mode?  (beside the fact that it's a royal pain).
> Also, I thought the 500 (ECS) allowed 32 colours?  I've only used ECS/OCS
> Amigas on rare occasions so this is kinda new for me.

OCS/ECS is 16 colours only for a horizontal resolution of 640 pixels. HAM mode is
too vile to contemplate and doesn't display text at all well (lots of nasty
fringing effects).

> Ok, but why make the destinction between the picture palette and text
> colours?  Why not just remap the text colours to the nearest picture
> pallette colour?

Probably because there's no guarantee that the palette represents a suitable
range of colours. For example, the Infocom V6 games often use the pictures to
draw screen borders, which are often drawn with most of the palette being shades
of the same colour.


David Kinder            mailto:davidk@monis.co.uk
Monis Software          http://www.monis.co.uk/
126-134 Baker Street    Tel: +44 171 935 3336
LONDON                  Fax: +44 171 935 6663
W1M 1FH

From ???@??? Wed Feb 04 11:23:57 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 3 Feb 1998 07:01:46 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: RE: [z-machine] V6 Z-Machine Stuff
In-Reply-To: <01BD30AD.B7504B10.davidk@monis.co.uk>
Message-Id: <Pine.BSI.3.95.980203065749.17085A-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 90772b3eb4d3dcf10f734ffceeaa93b2

On Tue, 3 Feb 1998, David Kinder wrote:

>Probably not. Trying to map any picture to an arbitrary palette (e.g. the standard
>Windows colours) quickly reveals how few 256 colours actually is. Pictures should
>be either 256 colours in an arbitrary palette, or true colour. In either case it
>would be up to the interpreter to reduce the colour information to a level it could
>display.

Ok, that makes sense.  But what about text colours, should they be
reserved from the initial 256 or maped to equivelent colours from the pic?

>OCS/ECS is 16 colours only for a horizontal resolution of 640 pixels. HAM mode is
>too vile to contemplate and doesn't display text at all well (lots of nasty
>fringing effects).

So 32 colours was low-res only?  No wonder I rarly see a hi-res Workbench
on pre-AGA machines.

BTW, HAM is also used on a game system, I forget which, may be
SuperNintendo or MegaDrive (Genesis).  I don't think it was used very
often though. 

Thanks for the info,

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Wed Feb 04 11:24:21 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802031846.NAA13522@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Tue, 3 Feb 1998 13:52:56 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <01BD30AD.B7504B10.davidk@monis.co.uk>
In-Reply-To: <Pine.BSI.3.95.980203065749.17085A-100000@ns1.syix.com>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 11706ee0ac2afdae536a42d3e3040614

On Tue, 3 Feb 1998, David Kinder wrote:

> >Probably not. Trying to map any picture to an arbitrary palette (e.g. the standard
> >Windows colours) quickly reveals how few 256 colours actually is. Pictures should
> >be either 256 colours in an arbitrary palette, or true colour. In either case it
> >would be up to the interpreter to reduce the colour information to a level it could
> >display.

Patrick sent a message across the ether on  3 Feb 98 (7:01) stating: 

> Ok, that makes sense.  But what about text colours, should they be
> reserved from the initial 256 or maped to equivelent colours from the pic?
 
All this colour stuff really has more to do with Blorb.  The only text 
currently allowed are the 8 provided (or 10 with the Amiga pallette), or 
won grabbed off the screen (from a pic).  This is fine IMO, but it would 
be nice if all the machines used the Amiga pallette for @set_colour.  I 
had suggested adding some extra colours as numbers 13-15, since 
currently these are wasted.

Blorb files can have palette information or colour depth stored in them 
as it stands.  Since all future V6 interpreters should support Blorb 
(I would think), I think that this is covered... isn't it?

Another problem that popped up with the Amiga model is that it uses the 
global background colour (stored in the header) to erase windows.  So if 
I have my main windows set to fg=white, bg=black and then have my status 
window set to fg=black and bg=white (which is legal) and then try to 
erase the status window, it get's filled with black and not white...

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Wed Feb 04 11:24:28 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 3 Feb 1998 14:48:20 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom15
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: RE: [z-machine] V6 Z-Machine Stuff
In-Reply-To: <01BD309B.739AA260.davidk@monis.co.uk>
Message-Id: <Pine.SUN.3.95.980203143804.28282C-100000@netcom15>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 70feedb545c9ee382afc381f04e06846

On Tue, 3 Feb 1998, David Kinder wrote:

> On Tuesday, February 03, 1998 9:21 AM, Patrick [SMTP:patrick@syix.com] wrote:
> 
> I suspect it would be better to create a new interpreter machine number, for which
> we can define an acceptable set of basic properties (256 colours, etc.).

I really don't like this approach, because it's all-or-nothing. The
interpreter has to guarantee the entire set of properties or it can't use
that machine number -- which means the game doesn't know that *any* of the
properties are available. Separate header bits can be checked separately.

If you define a minimal set of properties, you're also absolutely throwing
out any machine that doesn't meet them. Like (as you mention below) the
Amiga 500. Or even a Mac/PC with a monochrome monitor.

Jason Penney:

> > Ok, that makes sense.  But what about text colours, should they be
> > reserved from the initial 256 or maped to equivelent colours from the
> > pic?
 
> All this colour stuff really has more to do with Blorb.  The only text 
> currently allowed are the 8 provided (or 10 with the Amiga pallette), or 
> won grabbed off the screen (from a pic).  This is fine IMO, but it would 
> be nice if all the machines used the Amiga pallette for @set_colour.  

I'm (obviously :-) with Jason here. Blorb lets you define a preferred
palette, with the explicit warning that you may not get it. The
interpreter may reserve 16 colors (or whatever) for text colors, or draw
the closest equivalents from your preferred palette if it wants (most
likely, if the *player* wants.) 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Wed Feb 04 11:55:40 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@super.zippo.com (David Turnbull)
To: z-machine@gmd.de
Subject: [z-machine] Frotz for PalmPilot
Date: Tue, 03 Feb 1998 23:07:31 GMT
Message-Id: <34d7a1f1.24564793@snake.ae.usr.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 2db6a93b8339719767e0eb9217df5838

I am considering porting Frotz to the PalmPilot.  When I'm done, it
will be distributed free (not shareware).  I have a number of
questions that I need answered before I begin.  But first, a couple
things you may already know:

PalmPilot from 3com (same as Pilot from U.S.Robotics).  Monochrome 160
x 160 LCD pen sensitive with additional non-lcd space for data entry.
Reasonably powerful 68xxx compatible Motorola processor.  Modern units
contain 1MB of memory, old units easily upgraded by end-user.  A third
party is also selling memory upgrades as large as 3MB plus 1MB
additional EEPROM that could be used to store the interpreter and
z-data!

ZIP has already been ported to the Pilot.  It costs $12 and is broken
in many ways.  No support for fixed width fonts (does not display
anything when this font selected).  It breaks the standard Pilot
programming model, thereby causing problems with application switching
and auto-power-off.  Does not support beyond V5 games, and doesn't
support many V3 and V5 games properly.

Sound support will be limited to basic beeps because this is all the
Pilot will do.  Can I safely assume that all Infocom releases can be
solved without the audio clues or should I take these off the list of
supported titles?

Graphics will not be supported!  Can any Infocom V6 games revert to
text mode?

Now, here comes the interesting part...  How to handle the display.  I
have several ideas for this.  Because I an not familiar with all the
Infocom games and how they operate under different interpreters, I
have questions.

A 160x160 display will provide 20x16 fixed width characters.  There is
actually no fixed width font in the pilot, but I can use a
proportional font and place the characters in a grid.

It would seem that a 20 column screen is unusable for anything that
wants a fixed width font.  I will provide an option to make a virtual
screen (you'll have to scroll left and right).  To make this more
tolerable, I will always wrap proportional text around at 160 pels and
any rows that have no undisplayed data don't get scrolled left-right.

I don't really expect anyone will try to do things like play BZ in
split screen mode, but they could.  The real reason for going to these
extremes is to allow for hints and some games that used menus.

I haven't played BZ much, so I don't know where the runes come in, are
they just on the top or do they display in-line with the text?
Another way of asking is, If the user drops back to plain text mode in
BZ will they still see runes?

Am I crazy for trying to implement a fixed width font?  If I set the
proper bits in the header to tell the game I can't do fixed width, are
there any games that still won't work properly?  In the standards,
8.1.3 "A game must not use fonts other than 1 unless allowed to by the
interpreter."  Did the Infocom games follow this rule?

If I do implement fixed width fonts, I'd be inclined to use an 8x8
grid and implement the font 3 characters as described in the z-machine
standards document.  This will look fine, but if I put the
proportional font on an 8 high layout it will look too crowded.  For a
good looking display, the proper height for a proportional font is at
least 10 pels.  Is there any problems with doing this?  Will any games
make an attempt to move the cursor to a specific row of proportional
text?

Am I wasting my time?  (I already know I'm nuts.)

-david

From ???@??? Wed Feb 04 11:55:43 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802032332.SAA18423@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: erkyrath@netcom.com
Date: Tue, 3 Feb 1998 18:39:20 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <01BD309B.739AA260.davidk@monis.co.uk>
In-Reply-To: <Pine.SUN.3.95.980203143804.28282C-100000@netcom15>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a62a50d386e91854ca0a26bd0a3b0d1c

Andrew Plotkin sent a message across the ether on  3 Feb 98 (14:48) 
stating:

> On Tue, 3 Feb 1998, David Kinder wrote:
> 
> > On Tuesday, February 03, 1998 9:21 AM, Patrick [SMTP:patrick@syix.com] wrote:
> > 
> > I suspect it would be better to create a new interpreter machine number, for which
> > we can define an acceptable set of basic properties (256 colours, etc.).
> 
> I really don't like this approach, because it's all-or-nothing. The
> interpreter has to guarantee the entire set of properties or it can't use
> that machine number -- which means the game doesn't know that *any* of the
> properties are available. Separate header bits can be checked separately.
> 
> If you define a minimal set of properties, you're also absolutely throwing
> out any machine that doesn't meet them. Like (as you mention below) the
> Amiga 500. Or even a Mac/PC with a monochrome monitor.

I'm with Andrew on this.  I only suggested it as a possible 
alternative, but I don't really like it.  I was just trying to keep 
this version of the proposal freer from my opinions.  I think it might 
be best to have both a new machine number (255 -- Portable, or 
something), and a header extension with flags for the following 
behaviors:

*	Is the Amiga palette provided?

*	Can each window have its own colour pair?
	(if not, then it is not safe to assume that @erase_window will not 
	use the global bg colour stored in the header, but it may)

*	Can the interpreter print in multiple text colours?

*	Can use the interpreter display multiple font styles together?
	(this should be set true *only* if the interpreter is capable of all 
	possible combinations)

This allows a careful game author to tell if certain features are 
present, and adjust accordingly.  Of course Inform would have to 
compile v6 games with this extra header space... I think...

[palette stuff is in Blorb]
> I'm (obviously :-) with Jason here. 

Ha ha!  Good, I was afraid this part of the discussion might drown the 
rest of it.  :)

While we're at it (if anything ever gets agreed on) what about throwing 
a colour depth field in there that would hold either 8, 16, or 32?  
Yes? No? Maybe?

Later,
Jay
(who is playing with right justification for V6Lib...)

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Wed Feb 04 12:23:51 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <001c01bd3100$d5e29800$cb054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: <z-machine@gmd.de>
Subject: Re: [z-machine] Frotz for PalmPilot
Date: Wed, 4 Feb 1998 01:06:22 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a8f7a0178e1bd5169a9d2f4907aed3df

>From: David Turnbull <dpt@super.zippo.com>
>Can I safely assume that all Infocom releases can be
>solved without the audio clues

No audio needed. In fact, the audio files were "lost" for a long time, then
made available on GMD. And I suppose the Pilot *could* do more than beeps -
there are some demos out there, but it might be very hard to implement this.

>Graphics will not be supported!  Can any Infocom V6 games revert to
>text mode?

I'm afraid not; Zork Zero won't be finishable without graphics (Towers of
Bozbar, the rebus, ...) You can force Arthur into text mode (not a good
idea), but Journey is impossible because of the menu structure.

>I can use a proportional font and place the characters in a grid.

Which wouldn't look soooo great... it might be better to provide a
fixed-width font, especially as it'd have to be compatible to the "standard"
character set Inform uses (e. g. character @@64 = @, @@136 = ~, @'e = i,
...).

>I haven't played BZ much, so I don't know where the runes come in, are
>they just on the top or do they display in-line with the text?
>Another way of asking is, If the user drops back to plain text mode in
>BZ will they still see runes?

The runes are part of the game, appearing mid-text, several times, except in
pure text mode (where it says "some runes" instead of displaying them).

>I don't really expect anyone will try to do things like play BZ in
>split screen mode, but they could.  The real reason for going to these
>extremes is to allow for hints and some games that used menus.

I think Beyond Zork is one of the baddies when it comes to
interpreter-writing, with its excessive abuse of the status line
(automapping &c.) Just ask Rich of WinFrotz fame ;-) The scrolling mode is,
however, an excellent idea.

>Am I wasting my time?  (I already know I'm nuts.)

Most definitely not.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+



From ???@??? Wed Feb 04 14:25:43 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue,  3 Feb 1998 18:05:53 -0800
From: Bob Bottomley <Robert.A.Bottomley.Jr@cdc.com>
Subject: Re: [z-machine] Frotz for PalmPilot 
To: z-machine@gmd.de
X-Mailer: Z-Mail Pro 6.1 (Win32 - 021297), NetManage Inc.
X-Face: 'uY:)/LPl_h1J0SEh~@}FL%OZ_8;jrL]]D,^.x&Fp]SDUO4TRA`wZS2lNoCDLnzmGwCS4!7
 s6%20Rk2GUad\)[0"xx$s"G.[1S37IpU3~_8C,C</,H./v!7f$v6ze=>`r]AvugR0Z}n[QVH>JfxlF
 lAC#?bs-k9?~V(gfFTq4<7x9/cloRB=TEcH(9?!}|q)V5#p<E@]3;!f479[N~MA,KTuS>|<8".%#BN
 =DG6g5ajx(nzB[tGW8Vezu_a*)=0!|V4jD}h`|U)1>34{'>qQ@G^sG2'\b7.tOD^f!)z=[x<{IE'xF
 K<A>P%G'f~5"kyb1E(;*y9d/>t|[a
X-Priority: 3 (Normal)
References: <34d7a1f1.24564793@snake.ae.usr.com> 
Message-Id: <Chameleon.886558262.rab@BlackLodge>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6bd79e029cdfbe6e50f368e9b97a0a80

  From: David Turnbull <dpt@super.zippo.com>

> I am considering porting Frotz to the PalmPilot.

Check out this URL:

http://www.scrawlsoft.com/products/yazi/info.html

Take a look at what is done on the Newton platform. Some of its features are:

The deal with the handwriting was handled in a few ways:

    o A popup box of common word/phrases that the user can modify
    o A bunch of one-tap buttons for often used words, including a compass
      rose for directions and a set of tappable icons
    o Every word that appears in the 'output' window can be directly tapped
      and added to the 'input' window. This means that every word you see is
      available to use with a single tap.

What this means is rather than struggling to write in "open window and enter 
house," you can tap a total of 6 times for the same result.

--------------------------------------------------------------------------
"It is by caffeine alone I set my mind in motion.
It is by the juice of cola that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion."
                               --The Programmer's Creed

From ???@??? Wed Feb 04 14:35:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 3 Feb 1998 18:28:26 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom17
To: Z-Machine List <z-machine@gmd.de>
Subject: RE: [z-machine] V6 Z-Machine Stuff
In-Reply-To: <199802032332.SAA18423@ns.chelmsford.com>
Message-Id: <Pine.SUN.3.95.980203182733.19844E-100000@netcom17>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cce0b2cdc3b8f87edf244341671c32ff

On Tue, 3 Feb 1998, Jason C Penney wrote:

> Andrew Plotkin sent a message across the ether on  3 Feb 98 (14:48) 
> stating:
> [palette stuff is in Blorb]
> > I'm (obviously :-) with Jason here. 
> 
> Ha ha!  Good, I was afraid this part of the discussion might drown the 
> rest of it.  :)
> 
> While we're at it (if anything ever gets agreed on) what about throwing 
> a colour depth field in there that would hold either 8, 16, or 32?  
> Yes? No? Maybe?

Yes. Already there. See 
http://www.edoc.com/zarf/blorb/

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Feb 04 14:45:38 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 3 Feb 1998 18:22:49 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom17
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Frotz for PalmPilot
In-Reply-To: <34d7a1f1.24564793@snake.ae.usr.com>
Message-Id: <Pine.SUN.3.95.980203181326.19844C-100000@netcom17>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 866eddb310476b786b5370961ec097f9

On Tue, 3 Feb 1998, David Turnbull wrote:

> Am I crazy for trying to implement a fixed width font?  If I set the
> proper bits in the header to tell the game I can't do fixed width, are
> there any games that still won't work properly?  In the standards,
> 8.1.3 "A game must not use fonts other than 1 unless allowed to by the
> interpreter."  Did the Infocom games follow this rule?

I'm cheerfully certain that most Inform games which use the fixed-width
font don't bother to check any darn header bits. 

I think a virtual (scrolling) status window could work very well. 

In the story window, it will certainly be imperfect -- but if you do it on
a line-by-line basis, it could handle a large percentage of the games out
there. (That is, if an entire line in the story window is fixed-width,
declare it to be wider than the screen and scroll it back and forth.
Proportional text, and lines with both fonts, wrap normally.)

>  Will any games
> make an attempt to move the cursor to a specific row of proportional
> text?

You can't move the cursor at all in the story window. (I'm talking V5/8
here.)

Gunther:

> I think Beyond Zork is one of the baddies when it comes to
> interpreter-writing, with its excessive abuse of the status line
> (automapping &c.) Just ask Rich of WinFrotz fame ;-) 

Actually, BZ doesn't abuse the status line at all, in terms of cursor
movement and display. It's the font situation that causes massive
headaches. 

Ok, there's also the @read-in-the-status-line problem. I wish I could
consider that an abuse, but nothing in elegance or the Spec forbids it. :)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Wed Feb 04 15:15:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802040253.VAA21211@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Tue, 3 Feb 1998 21:59:22 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <199802032332.SAA18423@ns.chelmsford.com>
In-Reply-To: <Pine.SUN.3.95.980203182733.19844E-100000@netcom17>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a3baa8f58a8d162e4aa7ecbd002b3358

Andrew Plotkin sent a message across the ether on  3 Feb 98 (18:28) 
stating:

> On Tue, 3 Feb 1998, Jason C Penney wrote:
> 
> > Andrew Plotkin sent a message across the ether on  3 Feb 98 (14:48) 
> > stating:
> > [palette stuff is in Blorb]
> > > I'm (obviously :-) with Jason here. 
> > 
> > Ha ha!  Good, I was afraid this part of the discussion might drown the 
> > rest of it.  :)
> > 
> > While we're at it (if anything ever gets agreed on) what about throwing 
> > a colour depth field in there that would hold either 8, 16, or 32?  
> > Yes? No? Maybe?
> 
> Yes. Already there. See 
> http://www.edoc.com/zarf/blorb/

Sorry, this wasn't clear.  I meant should we maybe put this in the 
header extension (if that's what we go with).  I know it's in Blorb...  
:P

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Fri Feb 06 08:13:23 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 3 Feb 1998 22:30:01 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Frotz for PalmPilot
In-Reply-To: <Pine.SUN.3.95.980203181326.19844C-100000@netcom17>
Message-Id: <Pine.BSI.3.95.980203222710.25964C-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9ee63bf3134d139ab0a26331886ff3fb

On Tue, 3 Feb 1998, Andrew Plotkin wrote:

>I'm cheerfully certain that most Inform games which use the fixed-width
>font don't bother to check any darn header bits. 

Should programmers be checking the header bit?  It seems to me that an
interpreter could just as easly ignore the z-codes attempts to use a fixed
font and substitute a prop font in its place.  Sure it would be ugly but
it would still work.

Are there any interpreters that can't handle fixed fonts?  I would assume
they would be easer then proprotional ones.

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Fri Feb 06 08:13:29 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <001001bd313e$94cf7840$d5054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Z-Machine Stuff
Date: Wed, 4 Feb 1998 08:28:25 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 18ec7973c3790b92530a26e9e2c7b663

>If you define a minimal set of properties, you're also absolutely throwing
>out any machine that doesn't meet them. Like (as you mention below) the
>Amiga 500. Or even a Mac/PC with a monochrome monitor.

Ok, but here's a general question: doesn't the problem of running a V6 game
on, say, an Amiga and a true-colour PC have the additional trouble for the
author to not use colours in-game as the Amiga interpreter (I'm talking
about Frotz Amiga mode here) doesn't support changing colours mid-line, and
to use them otherwise?

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+


From ???@??? Fri Feb 06 08:13:42 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <01BD314E.0D5A3E30.davidk@monis.co.uk>
From: David Kinder <davidk@monis.co.uk>
To: Z-Machine List <z-machine@gmd.de>
Subject: RE: [z-machine] V6 Z-Machine Stuff
Date: Wed, 4 Feb 1998 09:19:52 -0000
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 428474603dfcfe8b09a1801816261126

On Wednesday, February 04, 1998 7:53 AM, Patrick [SMTP:patrick@syix.com] wrote:
> On Wed, 4 Feb 1998, Gunther Schmidl wrote:

> But wait a sec, I just tried running Dos Frotz in a PC emulator in Amiga
> mode and it seemed to handle colour correctly.  This was a v5 game though,
> is this brokin in v6 games only?

Yes, essentially. For V5, you've got 8 colours, plus a "defaults" for the
back and fore-ground colour. The palette doesn't change so it's easy to
implement colour changes.


David Kinder            mailto:davidk@monis.co.uk
Monis Software          http://www.monis.co.uk/
126-134 Baker Street    Tel: +44 171 935 3336
LONDON                  Fax: +44 171 935 6663
W1M 1FH

From ???@??? Fri Feb 06 08:13:47 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 04 Feb 1998 01:11:55 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: RE: [z-machine] V6 Z-Machine Stuff
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.SUN.3.95.980203143804.28282C-100000@netcom15>
Message-Id: <Marcel-1.26-0204011155-b49M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 69cda2799d6040591388682040d7ac5d

On Tue 03 Feb, Andrew Plotkin wrote:
> On Tue, 3 Feb 1998, David Kinder wrote:
> 
> > On Tuesday, February 03, 1998 9:21 AM, Patrick [SMTP:patrick@syix.com] wrote:
> > 
> > I suspect it would be better to create a new interpreter machine number, for which
> > we can define an acceptable set of basic properties (256 colours, etc.).
> 
> I really don't like this approach, because it's all-or-nothing. The
> interpreter has to guarantee the entire set of properties or it can't use
> that machine number -- which means the game doesn't know that *any* of the
> properties are available. Separate header bits can be checked separately.

I agree, and have a slight further concern: existing Version 6
games depend on the interpreter number in a rather delicate
fashion.  Some story files only work correctly with the right
interpreter number, and the standards document had to be rather
carefully written as a result (cf. 11.1.3 and several points in
section 8).

I would want to be very careful to ensure that Version 6
interpreters don't always run in this new interpreter-number,
because the V6 Infocom games would probably be fine in almost
every respect -- i.e., it would take a lot of testing before people
realised that they didn't work.  It would be good to hear from
Stefan and Matthew (R.) on this point, as they're the experts.

My further concern, really, is that this is an issue whose time has
not yet come.  I think we already have a sheaf of mostly
unimplemented proposals (any chance of Blorb sound support on your
interpreter, Andrew?) -- it is better to wait until there's need,
and then we'll have a clearer picture.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Fri Feb 06 08:13:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802041258.HAA25493@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Wed, 4 Feb 1998 08:04:50 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <001001bd313e$94cf7840$d5054e8c@async.edvz.uni-linz.ac.at>
In-Reply-To: <Pine.BSI.3.95.980203234936.29076A-100000@ns1.syix.com>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e33888c686529aff860f32f60c5d29bb

Patrick sent a message across the ether on  3 Feb 98 (23:52) stating:

> On Wed, 4 Feb 1998, Gunther Schmidl wrote:
> 
> >Ok, but here's a general question: doesn't the problem of running a V6 game
> >on, say, an Amiga and a true-colour PC have the additional trouble for the
> >author to not use colours in-game as the Amiga interpreter (I'm talking
> >about Frotz Amiga mode here) doesn't support changing colours mid-line, and
> >to use them otherwise?
> 
> I think we should remember that Amiga mode in DOS Frotz is very different
> then AmigaFrotz.  For instance, changing colour in mid-line works fine on
> a real Amiga.  

Hmm,  all reports I've had say other wise.  I'm just talking about in V6 
here.

> But wait a sec, I just tried running Dos Frotz in a PC emulator in Amiga
> mode and it seemed to handle colour correctly.  This was a v5 game though,
> is this brokin in v6 games only?

Well, it's not broken at all, since that's the way the ZSpec states it 
should behave.  :)

Later,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Fri Feb 06 08:13:57 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802041350.IAA26001@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Wed, 4 Feb 1998 08:56:39 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <Pine.SUN.3.95.980203143804.28282C-100000@netcom15>
In-Reply-To: <Marcel-1.26-0204011155-b49M+4%@gnelson.demon.co.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3b5ec7467ca88ea4a8ebff13c209c16f

Graham Nelson sent a message across the ether on  4 Feb 98 (1:11) 
stating:

> My further concern, really, is that this is an issue whose time has
> not yet come.  I think we already have a sheaf of mostly
> unimplemented proposals (any chance of Blorb sound support on your
> interpreter, Andrew?) -- it is better to wait until there's need,
> and then we'll have a clearer picture.

Currently none of the available screen models will have what is 
necessary for good (graphical) Blorb support.  Amiga mode has 14 colours 
allocated for images, and MCGA has <256.  This isn't what we want, is 
it?  So since we have to change interpreters so they don't behave like 
either of the above, wouldn't it be better to have specified, or 
specifiable, new behavior?  

With the four points in my proposal, I'm just trying to point out the 
things people have come up against already.  Writing test games using 
Infocom's own graphics show these limitations.

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Fri Feb 06 08:14:07 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <00a301bd319d$11297cc0$d2054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine Mailing List" <z-machine@gmd.de>,
        "Graham Nelson" <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] V6 Z-Machine Stuff
Date: Wed, 4 Feb 1998 19:34:05 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: aebe6f92c16122ac09fbf442c1c175aa

>My further concern, really, is that this is an issue whose time has
>not yet come.  I think we already have a sheaf of mostly
>unimplemented proposals (any chance of Blorb sound support on your
>interpreter, Andrew?) -- it is better to wait until there's need,
>and then we'll have a clearer picture.
>
>--
>Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

I definitely do not think that there's no need yet. Actually, the game I'm
working on already has been transferred to V6, and I run into dungloads of
problems especially with the colour support that the Amiga interpreter has
now - i. e. not supporting different colours at the same time (and let's
face it, MCGA doesn't only look crap, it also gets the colours wrong). I
have been, since the BLORB proposal came out, desperately waiting for an
Interpreter (and a compiler) to support it.
Jason puts a *lot* of effort into his V6Lib, and I know there are some
others who run into exactly the same problems --- so it may be better to
address this issue now, and not wait until "there's need" - because there
is.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+


From ???@??? Fri Feb 06 08:14:08 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 4 Feb 1998 11:20:01 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom12
Reply-To: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Z-Machine Stuff
In-Reply-To: <00a301bd319d$11297cc0$d2054e8c@async.edvz.uni-linz.ac.at>
Message-Id: <Pine.SUN.3.95.980204110038.24981B-100000@netcom12>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5212fd5f6d41eb95317913664d594def

On Wed, 4 Feb 1998, Gunther Schmidl wrote:

> but here's a general question: doesn't the problem of running a V6 game
> on, say, an Amiga and a true-colour PC have the additional trouble for
> the author to not use colours in-game as the Amiga interpreter 
> [whichever Amiga interpreter that is, see other posts]
> doesn't support changing colours
> mid-line, and to use them otherwise? 

Yes. This issue (unable to change colors in mid-line) is a problem of
fully supporting the spec on one particular platform. Either the author
has to check for it (checking for the Amiga machine number or else using a
new header bit) or the author will have to say "Tough, my game won't look
right on that platform." 

Jason Penney:

> Currently none of the available screen models will have what is 
> necessary for good (graphical) Blorb support.  Amiga mode has 14 colours 
> allocated for images, and MCGA has <256.  This isn't what we want, is 
> it?  So since we have to change interpreters so they don't behave like 
> either of the above, wouldn't it be better to have specified, or 
> specifiable, new behavior?  

No, because you'd be specifying (mandating) hardware capability. At least
on some platforms. On others, you'd be specifying a screen resolution or
color depth. What advantage is served? You guarantee that the game will
look good (for a fixed value of "good", not necessarily appropriate to
every game), but the player already has the capability to set his display
that way anyhow. 

It also makes life harder for the interpreter author. Right now we have a
deficit of willing interpreter authors. If an MCGA interpreter can be
quickly hacked for Blorb conformance, I think that should be encouraged,
even if it looks lousy. A better-looking, and still Blorb-conformant,
interpreter can be written later. 

Graham:

> >My further concern, really, is that this is an issue whose time has
> >not yet come.  I think we already have a sheaf of mostly
> >unimplemented proposals (any chance of Blorb sound support on your
> >[V5/8] interpreter, Andrew?)

Last time I tried to implement sound support, I implemented from the spec
-- got something I thought was right -- and then discovered that Sherlock
crashed my code. Violently.

Yes, it'll happen, but not right away. I don't think it would settle any
V6 image issues, anyway.

> >it is better to wait until there's need,
> >and then we'll have a clearer picture.
> 
> I definitely do not think that there's no need yet. Actually, the game I'm
> working on already has been transferred to V6, and I run into dungloads of
> problems especially with the colour support that the Amiga interpreter has
> now - i. e. not supporting different colours at the same time (and let's
> face it, MCGA doesn't only look crap, it also gets the colours wrong). I
> have been, since the BLORB proposal came out, desperately waiting for an
> Interpreter (and a compiler) to support it.

Well, we've got the compiler. 

I think it's time to go for it. (Easy for me to say, since I've done all
the work I can to help. :-)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."




From ???@??? Fri Feb 06 08:14:16 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802042252.RAA05322@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Wed, 4 Feb 1998 17:58:58 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 880a22fb146e8105b3b8177ca36f13ee

Andrew Plotkin sent a message across the ether on  4 Feb 98 (11:20) 
stating:

> Yes. This issue (unable to change colors in mid-line) is a problem of
> fully supporting the spec on one particular platform. Either the author
> has to check for it (checking for the Amiga machine number or else using a
> new header bit) or the author will have to say "Tough, my game won't look
> right on that platform." 

Right.  Some of my V6 test games did this sort of thing, and a 
V6Lib ZWinSytle can be written to handle machine differences rather 
elegantly.  My problem is I'm less than satisfied with any of the 
available machines, when they are both so close to being what I think we 
should have.

> Jason Penney:
	[begining bit snipped, since this part is the problem]
> > So since we have to change interpreters so they don't behave like 
> > either of the above, wouldn't it be better to have specified, or 
> > specifiable, new behavior?  
 
> No, because you'd be specifying (mandating) hardware capability. At least
> on some platforms. On others, you'd be specifying a screen resolution or
> color depth. What advantage is served? You guarantee that the game will
> look good (for a fixed value of "good", not necessarily appropriate to
> every game), but the player already has the capability to set his display
> that way anyhow. 

> It also makes life harder for the interpreter author. Right now we have
> a deficit of willing interpreter authors. If an MCGA interpreter can be
> quickly hacked for Blorb conformance, I think that should be
> encouraged, even if it looks lousy. A better-looking, and still
> Blorb-conformant, interpreter can be written later. 

Yikes!  Every time I'm not careful with my wording Andrew reads the 
interpretation I didn't think of.  As a result, I agree with you that I 
was wrong about that, up to a point.  I'm not sure where I was 
specifying screen resolutions or colour depths.  MCGA mode mandates 
screen resolution, I want to do away with it.  Both MCGA and Amiga mode 
mandate colour depth, and again I want to do away with it.

I have to stop doing all this fist thing in the morning and last thing 
at night.  I will now try to say what I *meant* to say above, but failed 
miserably...  please excuse the repetition.

Currently none of the available screen models will have what is
necessary for good (graphical) Blorb support.  Amiga mode has 14
colours allocated for images, and MCGA has <256.  This isn't what we
want, is it?  So interpreters would have to be changed so they don't
behave like either of the above to be able to display images as was 
discussed here before (i.e. possible 16 or 32 bit images).  I thought 
there was at least some agreement here that we wanted to do this.

Instead asking for this new screen model be implemented now, I'd like to 
implement a way to smooth the transition (via header bits and maybe 
the new machine number).  Frotz could take its Amiga mode, for instance, 
keep the behavior it has, claim the new machine number, and just set the 
extended bits correctly for now, and games could (and should, but this 
is the game authors problem still) be written so that when these 
features become present the game will take advantage of them.

Of course this will all come up again, since mention of multiple sounds 
playing at once has also come up.  This could get a header bit too.  Is 
there anything else (even if you don't agree that this is the way to 
go)?  

As you can see, what I meant to say (but didn't come close to saying)
wasn't quite so bad for interpreter authors.  I want to get it out of 
the way now, because if interpreter authors go out of their way to stick 
in Blorb, they may not take kindly to all sorts of extra changes popping 
up after the fact.  

Stefan Jokisch has known about me wanting to write V6 games since May 97.
One of the first things he said to me was that if I wanted to draw
pictures that take advantage of the higher Amiga mode resolution and MCGA
modes colours, Frotz would need to change.  He also told me that this
wasn't going to happen until there was a need.  

>From what I understand, he isn't going to get to Frotz just yet, so I'd 
like to have this all cleared up by the time he does (although I'd some 
input from him here.. *hint* *hint*).  I know Andrew isn't planning V6 
support as of now at all, and I haven't heard a thing from other 
interpreter writers (except for Rich of WinFrotz fame) about any of 
this... :(

Am I making sense yet?  Anyone read this far? 

Later,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Fri Feb 06 08:14:35 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@super.zippo.com (David Turnbull)
To: z-machine@gmd.de
Subject: Re: [z-machine] Frotz for PalmPilot
Date: Thu, 05 Feb 1998 00:13:37 GMT
Message-Id: <34d903a6.18451858@snake.ae.usr.com>
References: <34d7a1f1.24564793@snake.ae.usr.com>
In-Reply-To: <34d7a1f1.24564793@snake.ae.usr.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 875c7a31068f09d3721b763f18123db0

Ok great!  Thanks everyone.  Here's a followup with my remaining
thoughts.  I think I have enough information to begin programming now.
(Well, almost, I still have to figure out how I'm going to manage
memory.)

>>Can I safely assume that all Infocom releases can be
>>solved without the audio clues

Ok, great!  Looks like Lurking Horror and Sherlock will just be
silent.  Someone thought the Pilot can do more than beep, so I thought
I'd comment on exactly what sounds you can get from a pilot.

The OS call allows you to make a beep of any frequency and duration.
While it is beeping, the OS stays in it's own loop and keeps your
event loop from running :(.  You could access the sound chip directly,
but this only gains you control of the processor while the pilot is
beeping (but this is undocumented and may not even work well).
Therefore, you are limited to beeps and some very simple music.

>>I can use a proportional font and place the characters in a grid.

>Which wouldn't look soooo great... it might be better to provide a
>fixed-width font, especially as it'd have to be compatible to the "standard"
>character set Inform uses (e. g. character @@64 = @, @@136 = ~, @'e = i,
>...).

After further thought, I agree.  The PalmOS SDK docs are very skimpy
on font information.  There are functions that would lead me to
believe that a fixed font is in there somewhere.  I think I'll have to
write a program that will let me explore for fonts.

As a last resort, I'll build an entire 8x8 font set of Font 3 and Font
4.  I think I can do this in a few kilobytes.  Still, memory is first
on my list of concerns and every 1k counts.

>(automapping &c.) Just ask Rich of WinFrotz fame ;-) The scrolling mode is,
>however, an excellent idea.
>I think a virtual (scrolling) status window could work very well. 

About the scrolling mode and the rest of the plan....

Two (pilot) windows will be maintained.  One on the LCD and one
off-screen.  The off screen window will be user configurable to be
wider than the LCD.

Now for the fun.  Text in the upper window will print to the width of
the off-screen window (on the pilot).  Text in the lower window will
print to the width of the pilot screen.  You will use the pen to move
the upper window portal left and right.  This means you won't have to
scroll left and right to read the story text!!!

Pen events will be handled as follows:

A tap on the upper window will generate a mouse event.  Viola, Beyond
Zork map is interactive.  No sure this is too useful, but it's cute.
Any mouse aware menus will be tappable as well!

A tap on the lower window will put the word you tapped on into the
input buffer.

A drag in the upper window will scroll the upper window.

A drag in the lower window will translate into a compass direction
that is put in the input buffer.  Additional buttons will be provided
for up and down.

The very bottom of the screen will be a row of buttons for shortcuts
and such.  Some ideas: help button, common words list, "up.", "down.",
"take", "inventory.".

I now know I'll be able to support (or emulate) the minimum 60x14
screen described in Z-Machine standards!  Does this sound reasonable?
Should I expect it will work well with all V1-V5 games with the sole
exception of anything needing more lines?

It would seem V6 support is really not a good idea.  It's just a lot
of extra code that still won't run any programs other than the new
advent.z6.  I doubt we'll see any significant number of games written
for V6 that aren't graphics intensive and these won't be usable until
a color pilot is invented.

V6 support and debugging support will be explicitly removed.  I'll
make an attempt at undo support, but an evaluation of it's memory
requirements will be necessary before I make any decisions.

V8 games are V5 games times 2 in size right?  Of course, I'll support
these as well.

>I'm cheerfully certain that most Inform games which use the fixed-width
>font don't bother to check any darn header bits. 

Thought so!

-david

From ???@??? Fri Feb 06 08:14:54 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 4 Feb 1998 22:56:29 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Z-Machine Stuff
In-Reply-To: <199802041258.HAA25493@ns.chelmsford.com>
Message-Id: <Pine.BSI.3.95.980204225335.15864B-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c61d3605e3b40b71e33024110cf5cc34

On Wed, 4 Feb 1998, Jason C Penney wrote:

>Hmm,  all reports I've had say other wise.  I'm just talking about in V6 
>here.

Ok, I know when to admit when I'm wrong (although that is rare of course
:-)

I made a v6 demo and tested colours changes on the same line, didn't work
:-(  I still don't get why this is an Amiga limitation, the interpreter
could just open up a higher-colour screen and reserve some of the extra
colours for text colour, correct?

>Well, it's not broken at all, since that's the way the ZSpec states it 
>should behave.  :)

Ok, not brokin, just ugly :-)

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Fri Feb 06 08:15:15 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802051248.HAA13180@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Thu, 5 Feb 1998 07:55:14 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <199802050252.VAA09017@ns.chelmsford.com>
In-Reply-To: <Pine.SUN.3.95.980204214631.16636C-100000@netcom6>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ea64cac7d4d872659e6c981113c635cf

Andrew Plotkin sent a message across the ether on  4 Feb 98 (21:53) 
stating:

> So you don't need an interpreter number for this at all. Declare word 3 of
> the header extension to be your new field of flags. Say that it should
> always be zero in the game file; the terp should set bit 0 if it supports
> this field, and then bits 1 to 15 are the flags. 

Well, that makes sense to me.  And it keeps things compatible with 
current interpreters as they stand, since they won't touch it, if I'm 
understanding you correctly.  Now we have about 10 extra bits at this 
point...
 
> Actually, Graham got word 3 for his unicode proposal, I think. Pick some
> word after his.

4 maybe?

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Feb 07 14:23:00 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 6 Feb 1998 02:22:55 -0500
From: Bryan Scattergood <104312.2206@compuserve.com>
Subject: Re: [z-machine] Frotz for PalmPilot
To: "internet:dpt@super.zippo.com" <dpt@super.zippo.com>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Message-Id: <199802060225_MC2-321F-4AEA@compuserve.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 613a3606eba7c0083ab920c75c8b949a



David,

I'm a little late following up, but never mind.

<< (Well, almost, I still have to figure out how I'm going to manage
memory.) >>

I don't know how Frotz handles memory, but certainly I was disappointed 
by the memory consumption of the recent FrotzS5 port. (It seemed to 
load the entire story file into memory.) That simplifies the model, but 
it is also excessive on palmtops where the memory is small (typically 
less than 1M total) and storage is fast and solid-state.

I believe my Psion S3 interpreter probably holds the record for memory 
size; it can run games using a total memory consumption of less than 
64K over the size of the story file, even for large games like Trinity.
That includes the 26K or so for the running code image.

<< There are functions that would lead me to believe that a fixed font 
is in there somewhere.  >>

You may well find that the fixed font turns out to be the standard font 
printed with a fixed width; it certainly is on the Psion machines.
 
<< Two (pilot) windows will be maintained.  One on the LCD and one
off-screen.  The off screen window will be user configurable to be
wider than the LCD. >>

I have something like this planned to get round a similar problem on 
the Psion Siena. I raised this approach during a Glk discussion on raif 
a few weeks ago; there is some disagreement as to whether the header 
words dealing with window size tell you anything useful about the size 
of the lower window. I don't think they do, but that removes some 
options for aligning text in the lower window.

<< It would seem V6 support is really not a good idea.  It's just a lot
of extra code that still won't run any programs other than the new
advent.z6.  I doubt we'll see any significant number of games written
for V6 that aren't graphics intensive and these won't be usable until
a color pilot is invented. >>

At the risk of upsetting the folks currently pushing V6 as the next big 
thing, I'm tempted to agree.
 
<< V8 games are V5 games times 2 in size right?  Of course, I'll 
support these as well. >>

I thought the basic Pilot was a 128K machine? And Z8 allows 512K story 
files. Are you assuming storage cards or the larger (1M?) Pilot?

    Bryan

 

From ???@??? Sat Feb 07 14:23:25 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802061311.IAA00660@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Fri, 6 Feb 1998 08:17:52 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Frotz for PalmPilot
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <199802060225_MC2-321F-4AEA@compuserve.com>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cd709eae22f1739af6a86703983cbcb8

Bryan Scattergood sent a message across the ether on  6 Feb 98 (2:22) 
stating:

> << It would seem V6 support is really not a good idea.  It's just a lot
> of extra code that still won't run any programs other than the new
> advent.z6.  I doubt we'll see any significant number of games written
> for V6 that aren't graphics intensive and these won't be usable until
> a color pilot is invented. >>
> 
> At the risk of upsetting the folks currently pushing V6 as the next big 
> thing, I'm tempted to agree.

Well, I would hope that any V6 games that come out would still have a 
text only mode to them, if at all possible.  But that's probably just 
wishful thinking on my part.  I do intend to encourage this when I write 
my V6Lib User's Manual though.

As someone pushing V6 as something, I'm not upset.  I seems that it 
would require lots of time and effort, and at this point, no one would 
even use it.  While there were 256 downloads of advent.z6 last year, I 
only know of 4 people who loaded it up.

Jay
(who waited until after breakfast this time)

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Feb 07 14:23:29 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802061325.IAA00807@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Fri, 6 Feb 1998 08:31:33 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] [PNG] libpng 0.99a is out.
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e6dd33df6bfecbd3f58d73e8219c07c7

Hi,

For any of you interpreter authors considering Blorb support who are 
wondering about PNG, libpng 0.99a was released on January 31, and it 
should do more than everything needed (as far as I know).

It currently contains makefiles for the following platforms (ripped from 
the readme):

	makefile.aco  =>  ACORN makefile
	makefile.ama  =>  Amiga makefile
	makefile.atr  =>  Atari makefile
	makefile.bor  =>  Borland makefile
	makefile.dec  =>  DEC makefile
	makefile.dj2  =>  DJGPP 2 makefile
	makefile.elf  =>  Unix ELF makefile
	makefile.knr  =>  Makefile which calls ansi2knr to convert files
	makefile.mip  =>  MIPS makefile 
	makefile.msc  =>  Microsoft C makefile 
	makefile.sgi  =>  Silicon Graphics Irix makefile      
	makefile.std  =>  Standard Unix makefile 
	makefile.sun  =>  SUN makefile 
	makefile.tc3  =>  Turbo C 3.0 makefile
	makevms.com   =>  VMS make program

Well not everything, that covers quite a bit.  More info (and libpng) is 
available at <http://www.cdrom.com/pub/png/>

Hope this is useful,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Feb 07 14:23:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
X-Sender: mattack@mail.apple.com
Message-Id: <v01550101b1012219fac7@[17.202.20.138]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 6 Feb 1998 12:32:13 -0800
To: z-machine@gmd.de
From: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] Frotz for PalmPilot
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 78284311b0ab17c4767cdf24451ba044

>I don't know how Frotz handles memory, but certainly I was disappointed
>by the memory consumption of the recent FrotzS5 port. (It seemed to
>load the entire story file into memory.) That simplifies the model, but
>it is also excessive on palmtops where the memory is small (typically
>less than 1M total) and storage is fast and solid-state.

Frotz doesn't do any of the "virtual memory" stuff (I guess it doesn't
really belong in quotes, but we always _think_ of VM requiring hardware
support)
that the real Infocom interpreters do, nor that ZIP does.

Frotz took that stuff out for speed..   I've never actually _finished_ my
port of Frotz, but I did ZIP years ago, and it was really slow..  The VM
stuff is
one area that can be scrapped on a certain variety of machines that aren't
very fast, but have support for decent amounts of memory.  (Well, if a
palmtop has a meg of RAM, presumably it has support for more, but I'm not
suggesting to go buy memory.  That's what I *HATE* about computers the
most.. the "throw hardware at the problem" idea.  I think _most_ people
would be happy, and probably AS productive if not more, with AppleWorks on
a 1 MHz or 2.8 MHz Apple II..  That is, if they weren't brainwashed by the
"newer, faster, better" stuff, of which the last claim certainly isn't
always true... even faster on a raw MHz scale.. but I'm amazed how I am now
*waiting* for menus to pull down sometimes on a 7100, when I don't running
a System 7 variety on a low low end 68K Mac)




ANYHOW, sorry for the rambling.

If you want better memory support, I really suggest you look into ZIP,
since it has the VM stuff.

--
mattack@apple.com


From ???@??? Sat Feb 07 14:23:56 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@super.zippo.com (David Turnbull)
To: z-machine@gmd.de
Subject: Re: [z-machine] Frotz for PalmPilot
Date: Fri, 06 Feb 1998 21:50:21 GMT
Message-Id: <34db7292.11480324@snake.ae.usr.com>
References: <199802060225_MC2-321F-4AEA@compuserve.com>
In-Reply-To: <199802060225_MC2-321F-4AEA@compuserve.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: be96ba7b1c58f2736d63f7c1c4cbf0de

On Fri, 6 Feb 1998 02:22:55 -0500, you wrote:

>I don't know how Frotz handles memory, but certainly I was disappointed 
>by the memory consumption of the recent FrotzS5 port. (It seemed to 
>load the entire story file into memory.) That simplifies the model, but 
>it is also excessive on palmtops where the memory is small (typically 
>less than 1M total) and storage is fast and solid-state.

There are no memory routines in Frotz that I will be able to use.  I
have to rewite the entire library.  In fact, I have to rewrite just
about everything except for the math/logic functions and the screen
output functions.  I guess calling this a port may be misleading since
80% of the code is unusable.  However, I feel the Frotz code is too
understandable given my WINTEL background and it's screen.c code is
very very close to what I need.

>I believe my Psion S3 interpreter probably holds the record for memory 
>size; it can run games using a total memory consumption of less than 
>64K over the size of the story file, even for large games like Trinity.
>That includes the 26K or so for the running code image.

Exclusing UNDO memory, run-time memory consumption should easily be
less than 64K.

><< There are functions that would lead me to believe that a fixed font 
>is in there somewhere.  >>
>
>You may well find that the fixed font turns out to be the standard font 
>printed with a fixed width; it certainly is on the Psion machines.

I wasn't able to find a fixed font.  I'll be creating my own 8x8 font
to use, this will actually be easier than writing additional code to
use a prop font since I was going to support font 3 anyway.
 
><< It would seem V6 support is really not a good idea.  It's just a lot
>of extra code that still won't run any programs other than the new
>advent.z6.  I doubt we'll see any significant number of games written
>for V6 that aren't graphics intensive and these won't be usable until
>a color pilot is invented. >>
>
>At the risk of upsetting the folks currently pushing V6 as the next big 
>thing, I'm tempted to agree.

I've might make a small attempt at V6 games.  However, I'm not going
to support a virtual screen, so if the game can't run in a 160x130ish
monochrome screen with empty boxes in place of graphics,  it's too bad
for now.

My screen model changed slightly.  I'm no longer keeping a window
off-scrren.  Instead, I'll keep ASCII-like data which will be kinder
to memory and is needed anyway for "tapping words".  This model will
allow for easily adding a scrollback as well.

><< V8 games are V5 games times 2 in size right?  Of course, I'll 
>support these as well. >>
>
>I thought the basic Pilot was a 128K machine? And Z8 allows 512K story 
>files. Are you assuming storage cards or the larger (1M?) Pilot?

128K Pilots are not available to buy anymore and these are not really
suited for loading additional applications.  The current crop of
Pilots come with 512K or 1024K.  You can upgrade _ALL_ pilots to the
latest ROMs and 1M RAM for about $100(USD).  Sure, jamming 512K of
story into your pilot is really pushing it, but the additional
programming effort is insignificant.

Besides, when true SRAM comes down in price, you'll see PDAs with 4M
and more.

-david

From ???@??? Sat Feb 07 14:24:00 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
Message-Id: <199802062248.JAA07147@yallara.cs.rmit.edu.au>
Subject: Re: [z-machine] V6 Z-Machine Stuff
To: z-machine@gmd.de
Date: Sat, 7 Feb 1998 09:48:12 +1100 (EST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3ec348634b7290445ec4b15010609079

 
>
> >My further concern, really, is that this is an issue whose time has
> >not yet come.  I think we already have a sheaf of mostly
> >unimplemented proposals (any chance of Blorb sound support on your
> >interpreter, Andrew?) -- it is better to wait until there's need,
> >and then we'll have a clearer picture.
> >
> >--
> >Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom
>
> I definitely do not think that there's no need yet. Actually, the game I'm
> working on already has been transferred to V6, and I run into dungloads of
> problems especially with the colour support that the Amiga interpreter has
> now - i. e. not supporting different colours at the same time (and let's
> face it, MCGA doesn't only look crap, it also gets the colours wrong). I
> have been, since the BLORB proposal came out, desperately waiting for an
> Interpreter (and a compiler) to support it.
> Jason puts a *lot* of effort into his V6Lib, and I know there are some
> others who run into exactly the same problems --- so it may be better to
> address this issue now, and not wait until "there's need" - because there
> is.
>
> +------------------------+----------------------------------------------+
> + Gunther Schmidl        + "I couldn't help it. I can resist everything +
> + Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
> + A-4040 LINZ            +----------------------------------------------+
> + Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
> +------------------------+----------------------------------------------+
>
>
>
>
Even though I'm not actively developing a V6 game which requires this, I
really have to agree with Gunther here. If we're extending the z-machine
emulation to such an extent as Blorb is (although Blorb of course is extending
the emulators rather than the z-code itself), I really think it would be
worthwhile getting everything done now. As a computer programmer, I've had
to restart projects several times because of inadequate planning. It's
probably best to get it out of the way now.

My personal envisagement for the next generation of z-code gamefiles is that
if we're going to be extending the gamefile header to provide colour depth,
available features, etc. we might as well go the whole hog and have as a new
z-code version number. This way, it could mark the presence of the extra
header information.

[I'm no expert on the z-machine header format, but since there are entries in
the code table for the start of the various sections of the gamefile, surely
one of the sections could be moved up by 10 or 20 bytes to provide room for
an "extended" header.]

We could then also at the same time finally create a combined V6/V5 style
z-machine which has the best features of V6 such as user stacks, graphics
support, etc., but with the increased memory size that the V8 system now
enjoys.

Otherwise, we may end up with a situation of two conflicting z-machine types
[can you image: "let's see, V5 is type 1, V6 is type 2, V7 and V8 are an
extended V5, V9 is an extended V6, V10 extendeds V8, and V11 and V12 extend
V9." Admittantly, such expansions to fit gamefiles that size is probably
going a bit overboard, but the principle is still that we may end up with
a mixture of gamefile versions which support V5 or V6 without any particular
order to them, and I'd like to see that avoided if possible.

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

So maybe this may be a way to curcumnavigate the V6 problem with Infocom
games searching for a particular interpreter number: have a set gamefile
version which combines V5 and V6 with the extended memory of V8, and have
an extended header which the new breed of interpreters can fill out with
the data of what they support. [And if they don't support the extended 
header, just keep reporting their interpreter number as a standard one so
that the standard Infocom V6 games can still work].

Any other ideas on the matter?

--
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Sat Feb 07 19:16:51 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: h0142kdd@rz.hu-berlin.de ()
Message-Id: <199802070709.IAA17793@joker.rz.hu-berlin.de>
Subject: Re: [z-machine] V6 Z-Machine Stuff
To: z-machine@gmd.de
Date: Sat, 7 Feb 1998 08:09:23 +0100 (MET)
In-Reply-To: <199802062248.JAA07147@yallara.cs.rmit.edu.au> from "Paul Francis Gilbert" at Feb 7, 98 09:48:12 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: bec1d390761ebb380b794d5a95a8c21a

> [I'm no expert on the z-machine header format, but since there are entries in
> the code table for the start of the various sections of the gamefile, surely
> one of the sections could be moved up by 10 or 20 bytes to provide room for
> an "extended" header.]

A header extension table is already defined in the current standard. Since
it can be as long as we want it to, why not use it for colour depths etc.?

-- Dave

From ???@??? Fri Feb 13 16:33:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802071535.KAA17099@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Sat, 7 Feb 1998 10:41:58 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] V6 Z-Machine Stuff
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <199802070709.IAA17793@joker.rz.hu-berlin.de>
References: <199802062248.JAA07147@yallara.cs.rmit.edu.au> from "Paul Francis Gilbert" at Feb 7, 98 09:48:12 am
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a6945bb94fe816ba25ed75cd02726dcb

h0142kdd@rz.hu-berlin.de sent a message across the ether on  7 Feb 98 
(8:09) stating:

> > [I'm no expert on the z-machine header format, but since there are entries in
> > the code table for the start of the various sections of the gamefile, surely
> > one of the sections could be moved up by 10 or 20 bytes to provide room for
> > an "extended" header.]
> 
> A header extension table is already defined in the current standard. Since
> it can be as long as we want it to, why not use it for colour depths etc.?

I'm currently working on a brand spanking new version of my proposal 
that uses just a header extension.  If the extension isn't present 
(or if the interpreter doesn't honor it) the game relies on the behavior 
dictated by the machine number.

Jay


----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Fri Feb 13 16:36:01 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Z-Machine Stuff
Date: Sun, 8 Feb 1998 22:19:49 +0100
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19980208211051.AAD18293@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 03419a7eaa91825d8a3f0d11b861ab35


Gunther Schmidl wrote:

> I definitely do not think that there's no need yet. Actually, the game I'm
> working on already has been transferred to V6, and I run into dungloads of
> problems especially with the colour support that the Amiga interpreter has
> now - i. e. not supporting different colours at the same time (and let's
> face it, MCGA doesn't only look crap, it also gets the colours wrong). I
> have been, since the BLORB proposal came out, desperately waiting for an
> Interpreter (and a compiler) to support it.

If I get this right, you're asking to change the colour behaviour for
V6 interpreters which use interpreter number 4, i.e. Amiga.  Patrick
has called this behaviour "broken" and "ugly".  Are you both aware
that some Infocom V6 files require this behaviour to work properly?

On the same topic, I don't see the need to introduce another header
flag: Use of colours is limited if and only if the interpreter id is
Amiga.  Why should we want another header flag?  The flag wouldn't be
set by old interpreters anyway, so it would still be safer to check
the interpreter number.

Furthermore, Gunther, you're the first to report that "MCGA gets the
colours wrong".  It's not clear to me what you mean; could you elaborate?
And while you're at it, could you describe the "dungloads of problems"
just a tad more precisely?

-- Stefan

From ???@??? Fri Feb 13 16:42:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 11 Feb 1998 02:13:14 -0500
From: Bryan Scattergood <104312.2206@compuserve.com>
Subject: Re: [z-machine] Frotz for PalmPilot
To: "internet:dpt@super.zippo.com" <dpt@super.zippo.com>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Message-Id: <199802110214_MC2-32D2-75D5@compuserve.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: caf13e3a0f1e614e5cd52e02a9c60b66



David,

>>I believe my Psion S3 interpreter probably holds the record for memory 
>>size; it can run games using a total memory consumption of less than 
>>64K over the size of the story file, even for large games like Trinity.
>>That includes the 26K or so for the running code image.
> 
>Exclusing UNDO memory, run-time memory consumption should easily be
>less than 64K.

Oops. Yeah, I forgot to include undo memory (I normally leave that disabled.)
However, Trinity has a dynamic memory size close to the 64K limit. Add the
Z-stack, the ASCII screen storage, the interpreter code, the native stack and
storage for some the non-dynamic pages and you are well over 64K unless you
get inventive.

>My screen model changed slightly.  I'm no longer keeping a window
>off-scrren.  Instead, I'll keep ASCII-like data which will be kinder
>to memory and is needed anyway for "tapping words".  This model will
>allow for easily adding a scrollback as well.

You may find you need to store font data as well as the ASCII stuff.

>128K Pilots are not available to buy anymore and these are not really
>suited for loading additional applications.  The current crop of
>Pilots come with 512K or 1024K.  You can upgrade  ALL  pilots to the
>latest ROMs and 1M RAM for about $100(USD).  Sure, jamming 512K of
>story into your pilot is really pushing it, but the additional
>programming effort is insignificant.

I obviously haven't been paying enough attention to Pilot specs.

>Besides, when true SRAM comes down in price, you'll see PDAs with 4M
>and more.

I've had an 8M PDA sitting on my desk for about six months. If I ever start
using it for anything other than testing code it will probably need a 32M
storage card.

    Bryan

 

From ???@??? Fri Feb 13 16:44:22 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@super.zippo.com (David Turnbull)
To: z-machine@gmd.de
Subject: Re: [z-machine] Frotz for PalmPilot
Date: Wed, 11 Feb 1998 22:28:29 GMT
Message-Id: <34e211bd.194673996@snake.ae.usr.com>
References: <199802110214_MC2-32D2-75D5@compuserve.com>
In-Reply-To: <199802110214_MC2-32D2-75D5@compuserve.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 94511c0a98a2a33449600c8d141876de

On Wed, 11 Feb 1998 02:13:14 -0500, you wrote:

>>>I believe my Psion S3 interpreter probably holds the record for memory 
>>>size; it can run games using a total memory consumption of less than 
>>>64K over the size of the story file, even for large games like Trinity.
>>>That includes the 26K or so for the running code image.
>> 
>>Exclusing UNDO memory, run-time memory consumption should easily be
>>less than 64K.
>
>Oops. Yeah, I forgot to include undo memory (I normally leave that disabled.)
>However, Trinity has a dynamic memory size close to the 64K limit. Add the
>Z-stack, the ASCII screen storage, the interpreter code, the native stack and
>storage for some the non-dynamic pages and you are well over 64K unless you
>get inventive.

Memory needed for currently running game
----------------------------------------
dynamic memory        x
Z-stack               1K
misc persistent data  2K (includes screen data)

Memory consumed for storage
---------------------------
interpreter         50K (a wild guess based on existing zip port)
games files         x
save games          x

The native stack is not factored in because it is always 16k.  I'll
try to explain...  Upon system reset (new unit/paperclip
reset/processor exception/etc) the first 64K is cleaned out and 16K of
it is allocated for stack use.  Since the pilot is not multitasking,
this 16k is used by whatever is currently running.

The native heap is most of the rest of the first 64k block in the
pilot.  Since this 64k is never available directly to the user under
any circumstance, this memory is never reported to the user.  My Pilot
currently reads "Memory Used: 577K of 960K", but it truly has 1024K
installed.

Since the pilot is not multitasking, all static variables and a copy
of dynamic memory will be stored in a persistent database.  Static
variables would be lost when the program is stopped (say, to get a
phone number or write notes).

I couldn't find the source to the PsionS5 interpreter.  It's clearly
based on Frotz, which does not do dynamic memory.  Even so, adjusting
the included memory routines for a PDA seems very trivial.  I looked
at dymanic memory in ZIP but the memory routines in Frotz would be
easier for me to convert.

What are these "non-dynamic pages" you referenced?

>I've had an 8M PDA sitting on my desk for about six months. If I ever start
>using it for anything other than testing code it will probably need a 32M
>storage card.

I'm afraid a Pilot with 8M of PSRAM would need new batteries every
week.  SRAM would still last several months, but you would need a
second mortgage to pay for it.  What more can you expect from two AAA
cells?

FWIW, my test unit has 512K and the very first ROMs shipped.  However,
I have something called "XCopilot" that emulates a pilot on my Linux
machine, which is where I do development (with a hacked GNU C).

So, let's see...  Screen output is figured out.  Memory management is
figured out.  The rest of Frotz ports easily.  Cool!  There's a few
things left open regarding input and the toolbar, but nothing that
will require a complete rewrite if it doesn't work out.

-david

P.S. You mentioned a 128K pilot.  The least amount of memory it ever
came with was 256K.  But you got me talking about the 128K pilot
anyway.  Imagine a 128K pilot minus the 64K consumed for stack/heap
usage!!!

From ???@??? Fri Feb 13 16:44:36 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19980211164230.jholder@io.frii.com>
Date: Wed, 11 Feb 1998 16:42:30 -0700
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: [z-machine] Jzip 2.0.2 in beta, takers?
X-Mailer: Mutt 0.57
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d45c224ed8d3ed658fe623b56ab3ec0e


Well, as some of you may have noticed in a recent thread, Jzip 2.0.2
is in beta.  It supports Quetzal (or not, based on an #ifdef, so
you can play old save files), Zarf's Zstrict stuff, the tokenise_line
fix, the division rounding fix for negative divides, and
(drum roll) adds support for the extended save/load opcode.

I seem to be having trouble getting a successful DOS compile out of 
the quetzal source - either it is an idiosyncracy of the Borland Turbo
C compiler or my settings in my project file.  However, the UNIX port
seems fine.  If anyone has contradictory evidense, please present it to me!

It is available at http://www.frii.com/jzip202.zip, and running
$ver (Infocom) or verify (Inform) in a game will identify it as
a beta, as will `jzip -v`

Please email all problems to me.

Till then (*sigh*),
John
-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/

From ???@??? Fri Feb 13 16:44:55 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19980211191259.jholder@io.frii.com>
Date: Wed, 11 Feb 1998 19:12:59 -0700
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzip 2.0.2 in beta, takers?
References: <Mutt.19980211164230.jholder@io.frii.com>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <Mutt.19980211164230.jholder@io.frii.com>; from J. Holder on Feb 11, 1998 16:42:30 -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ef46915060eda0c51df25d12a86d3527

J. Holder writes:
> 
> 
> It is available at http://www.frii.com/jzip202.zip, and running

make that http://www.frii.com/~jholder/jzip202.zip

Sorry! (*sigh*, again)

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/

From ???@??? Fri Feb 13 21:49:48 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <zd3PJIACuA50Ewmp@elvw.demon.co.uk>
Date: Fri, 13 Feb 1998 08:59:46 +0000
To: z-machine@gmd.de
From: John Wood <John@elvw.demon.co.uk>
Subject: [z-machine] Announcement: Inform syntax for Windows 95/NT [long]
Mime-Version: 1.0
X-Mailer: Turnpike Version 3.03a <iAlJJHde64yJEPSoUQngOCV0T3>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 59510b728135875b6fd2503af69d12da

I have put some code on my homepage to handle Inform syntax highlighting
under Windows 95/NT.  The url is http://www.elvw.demon.co.uk/.  I can
see it now, but given the problems people have had accessing Graham's
pages just after he changes them non-Demon users should probably leave
it a day or two.

The whole package is 184K zipped - I append the (rather technical)
readme file, which will probably be of no use to anyone except
programmers.

Hope this is useful to someone - all comments welcome.

John
==========================================================
=============
INFORM SYNTAX STYLING FOR WINDOWS 95/NT
Version 0.1   February 9th 1998    John G. Wood <john@elvw.demon.co.uk>
==========================================================
=============

This is a collection of sample C++ code for syntax styling Graham
Nelson's Inform.  In his original post, Graham referred to this as
syntax colouring; I have generalised "colour" to "style" since I allow
the use of italic and bold text as well as colour when presenting this.
The code is organised into packages, so you can use as little or as much
as you like - the various packages are described below.  If you just
want to see how it works in practice, run the sample application
InformViewer.exe and open an Inform source file (one is provided).

I hereby release this into the public domain; if you find it useful, I
would appreciate it if you could let me know.  A mention in the credits
would be nice too, but it's entirely up to you.

This is the first public release and it is very much alpha - any reports
of problems (other than those mentioned below) will be gratefully
received.  My thanks (of course) to Graham Nelson for doing all the hard
parts - coming up with the language, compiler, and algorithm in the
first place!

John


INFORM AND IF
-------------
If you don't know Inform, this will be completely useless to you.
Inform is a language for writing Interactive Fiction (IF, or "text
adventures") - for more information try one of the following:

        Inform homepage:    http://www.gnelson.demon.co.uk/inform.html
        Author's newsgroup: rec.arts.int-fiction
        IF archives:        ftp://ftp.gmd.de/if-archive/


THE FILES
---------
There are a few auxiliary files in this distribution:

        ReadMe.txt :    You're reading it!
        Algorithm.txt : Graham Nelson's original algorithm, together
                        with notes on how I've changed it.
        Sample.inf :    A sample file to get you going.

The rest of the files are source files or else files necessary to build
the sample application (InformViewer.exe, also included).  These fit
together as follows, with packages lower in the diagram depending on
those higher up.  Best in a non-proportional font:

            +-----------------------+
            | 0. STYLE DEFINITIONS  |
            |-----------------------|
            | InformStyle.h         |
            +-----------+-----------+
                        |                 Windows/MFC               
               +--------+-------+             |
               |                |             |      
 +-------------+-------+  +-----+-------------+-----+
 | 1. SYNTAX STYLING   |  | 2. STYLE PRESENTATION   |
 |---------------------|  |-------------------------|
 | InformStyler.h,cpp  |  | InformStyleRecord.h,cpp |
 +-------------+-------+  +----+---------------+----+
               |               |               |     
               |               | +-------------+-------------+
               |               | | 2a. STYLE OPTIONS DIALOG  |
               |               | |---------------------------|
               |               | | InformStyleDlg.h,cpp  *   |
               |               | +-------------+-------------+
               |               |               |
          +----+---------------+----+          |
          | 3. STYLED EDIT CONTROL  |          |
          |-------------------------|          |
          | InformEditCtrl.h,cpp    |          |
          +-------------------+-----+          |
                              |                |
                         +----+----------------+----+
                         | 4. SAMPLE APPLICATION    |
                         |--------------------------|
                         | InformViewer.h,cpp,ds*   |
                         | InformViewerDoc.h,cpp    |
                         | InformViewerView.h,cpp   |
                         | MainFrm.h,cpp            |
                         | Resource.h               |
                         | StdAfx.h,cpp             |
                         | res/InformViewer.ico     |
                         | res/InformViewerDoc.ico  |
                         | res/Toolbar.bmp          |
                         +--------------------------+

* But see also InformViewer.rc and resource.h for dialog resources.


THE PACKAGES
------------

0. Style Definitions
--------------------
"InformStyle.h" simple contains an enumeration of the possible syntax
styles (Foreground, Quoted Text, etc) from GN's algorithm.

I have added two new styles, Number and CodeNumber, for my own benefit.
These are used for constant integers (decimal, hexadecimal or binary) in
declarations and in code respectively.

1. Syntax Styling
-----------------
The InformStyler class encapsulates the state machine from GN's
algorithm (modified as described in "Algorithm.txt").  Its only
significant public method is ColourString(), which builds up a map of
styles for a given text string.

ColourString() is not optimised for speed, but it takes less than a
second on my P166 to process a 4400+ line Inform file one line at a time -
there are far worse bottlenecks elsewhere!

Note that this code requires neither Windows nor MFC (although you would
have to dummy a few type definitions such as LPCTSTR to use it in
another environment).

2. Style Presentation
---------------------
The InformStyleRecord class contains the visual representation
information for one style - colour, bold and italic - plus a text name
for the benefit of the style options dialog.  The InformStyle enum entry
is referred to as the record's ID.

Also defined is a mapping class InformStyleRecordSet from IDs to
records.  There is a global object of this type accessible via
GetMasterStyles().

2a. Style Options Dialog
------------------------
The CInformStyleDlg class is simply a dialog box which allows the user
to customise the style presentation.  Pass it an InformStyleRecordSet on
construction and it will do the rest.  See "InformViewer.cpp" for an
example of using this.

Note that this requires the dialog resources from the sample application
- it should be easy enough to copy them across.

3. Styled Edit Control
----------------------
The CInformEditCtrl class is derived from a rich edit control.  It
currently has one interesting method, SetText().  This sets the text of
the control then colours it using an Inform syntax styler and the
master style set.  To ease styling when the text is edited, I store the
style's state for the start of each line.

This is the least satisfactory package.  The worst problem is speed -
the 4400+ line Inform file mentioned above takes over TWO MINUTES to
prepare on my P166.  I have found the culprit is the call that actually
changes the text style - SetSelectionCharFormat().  Commenting this out
reduces the time to under four seconds, but of course there's no visual
syntax styling!

The other problem is that I have only implemented it as a viewer.  If
the text is edited it will be wrongly styled unless the whole text is
processed again.

I hope to do something about both these problems in future releases but
thought it was worth releasing in it's current state anyway.

4. Sample Application
---------------------
InformViewer.exe is a simple SDI application that allows you to view
syntax-styled Inform files.  CInformViewerDoc just reads files into a
CString accessible to its views; CInformViewerView maintains a styled
edit control filling it's client area and updates the text when
necessary.  CInformViewerApp does three things of interest:
  a. It loads the master styles from the registry (if preferences have
     been written into the registry) in InitInstance();
  b. It saves the master styles to the registry in ExitInstance();
  c. It handles the "Tools|Syntax styles" command, updating all views
     in all documents if the styles have changed.
 
John G. Wood  |  john@elvw.demon.co.uk  |  Oxford, United Kingdom

From ???@??? Sat Feb 14 20:22:50 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 14 Feb 1998 03:06:23 -0500
From: Bryan Scattergood <104312.2206@compuserve.com>
Subject: Re: [z-machine] Frotz for PalmPilot
To: "internet:dpt@super.zippo.com" <dpt@extra.newsguy.com>
Cc: "internet:z-machine@gmd.de" <z-machine@gmd.de>
Message-Id: <199802140308_MC2-3341-B16E@compuserve.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7a023bce9d79dad1437295b91163ada7



David,

<< Since the pilot is not multitasking, all static variables and a copy
of dynamic memory will be stored in a persistent database.  Static
variables would be lost when the program is stopped (say, to get a
phone number or write notes). >>

Hmm. You've got me (more) confused. Does the active application have 
any data segment, or does it have to  store everything in the 
persistent database all the time? Or do you need to package the data 
segment into the database when the user switches tasks?

The Psion machines are actually fairly conventional; they have a 
pre-emptive multi-tasking OS, with each application running in its own 
address space.
 
<< Even so, adjusting the included memory routines for a PDA seems very 
trivial.  I looked at dymanic memory in ZIP but the memory routines in 
Frotz would be easier for me to convert. >>

It depends. If the Z-memory access routines allow creation of a pointer 
'into' the dynamic memory, then it needs to exist as a contiguous block 
unless you can find guarantees about how much pointer arithmetic the 
rest of the interpreter will perform.
 
<< What are these "non-dynamic pages" you referenced? >>

You also need to access the game above the dynamic memory; the code and 
string storage. If you go through the file-system to handle each and 
every read from this area, then performance sucks. You need to manage a 
local cache of pages from that area to get reasonable performance.

<< I'm afraid a Pilot with 8M of PSRAM would need new batteries every
week.  SRAM would still last several months, but you would need a
second mortgage to pay for it.  What more can you expect from two AAA
cells? >>

Well, the Siena manages around 40 hours of use, working out to over a 
month, on two AAA cells. But that maxes out at 1M. The 8M Series5 seems 
to be managing around 20-25 hours on two AA cells, but it is hard to 
tell since mine spends 95% of its time on a desk with the PSU 
connected. (And the drop in battery life is as much due to the larger 
screen, backlight and faster CPU as to the RAM.)

<< So, let's see...  Screen output is figured out.  Memory management 
is figured out.  The rest of Frotz ports easily.  Cool!  There's a few
things left open regarding input and the toolbar, but nothing that
will require a complete rewrite if it doesn't work out. >>

Good luck. You have plenty of scope to be inventive with the pen-input.

<< P.S. You mentioned a 128K pilot.  The least amount of memory it ever
came with was 256K.  But you got me talking about the 128K pilot
anyway.  Imagine a 128K pilot minus the 64K consumed for stack/heap
usage!!! >>

Confused again. I thought I read that somewhere but obviously I got it 
confused with the original version of the Psion S3 which came in 128K 
and 256K (and the system claimed around 70K.) I believe my interpreter 
runs on the smaller of those machines, but I never actually tried it.

    Bryan

 

From ???@??? Wed Feb 18 15:14:42 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@extra.newsguy.com (David Turnbull)
To: z-machine@gmd.de
Subject: Re: [z-machine] Frotz for PalmPilot
Date: Sun, 15 Feb 1998 03:25:20 GMT
Message-Id: <34e657b9.22572148@snake.ae.usr.com>
References: <199802140308_MC2-3341-B16E@compuserve.com>
In-Reply-To: <199802140308_MC2-3341-B16E@compuserve.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 4547e83c682e8f8bddcc9a3b008856be

On Sat, 14 Feb 1998 03:06:23 -0500, you wrote:

><< Since the pilot is not multitasking, all static variables and a copy
>of dynamic memory will be stored in a persistent database.  Static
>variables would be lost when the program is stopped (say, to get a
>phone number or write notes). >>
>
>Hmm. You've got me (more) confused. Does the active application have 
>any data segment, or does it have to  store everything in the 
>persistent database all the time? Or do you need to package the data 
>segment into the database when the user switches tasks?

OK, maybe we're getting off topic a bit but you did ask...

Pilot programs run in an event loop, so they are event driven like a
multitasking OS.  However, no other process is running while your
program is running.  The only thing running while your program is
active are some interrupt routines to handle pen and button input, but
you can override these anyway.

Every byte of memory in the pilot, except the first 64K, is persistent
database storage.  Your program is a database.  Your program is not
"copied" anywhere to run, it simply runs right in the database area.

Now, the first 64K of memory is allocated for an ordinary stack and
ordinary heap.  All variables, including globals (copied at run time),
are stored in the heap.  When the user requests to run another
program, you are given an event to ensure you have a chance to save
data and whatever.  When this other program is run, the stack and heap
are cleared out and given to the other program.

For a z-machine interpreter we want the user to be able to switch in
and out very seamlessly.  You can process the terminate-program event
by copying all static and global variables to a database.  But, a
better and faster way to do this would be to simply keep all your
global data in a database since you can access it directly via
pointers.

I haven't even gotten to the fun stuff.  The weird thing is that
everything you have grown used to, like <stdio.h> and <string.h>,
simply don't exist, but equivalent functions are available in the
pilot libraries which call ROM routines.

If you want to learn more, you can get a complete GNU based
development environment and a Pilot emulator for your PC.  The
programming manuals are available in PDF format from 3com.  If you
need more specific information, contact me directly and I'll help.

>The Psion machines are actually fairly conventional; they have a 
>pre-emptive multi-tasking OS, with each application running in its own 
>address space.
> 
><< Even so, adjusting the included memory routines for a PDA seems very 
>trivial.  I looked at dymanic memory in ZIP but the memory routines in 
>Frotz would be easier for me to convert. >>
>
>It depends. If the Z-memory access routines allow creation of a pointer 
>'into' the dynamic memory, then it needs to exist as a contiguous block 
>unless you can find guarantees about how much pointer arithmetic the 
>rest of the interpreter will perform.

Well, since you won't find any contiguous memory greater than 64K and
you won't find many games less than that, seems like some fancy tricks
are needed.  Frotz does all z-memory access with some #defined
functions.  I just replace these with some subroutines and viola!
 
><< What are these "non-dynamic pages" you referenced? >>
>
>You also need to access the game above the dynamic memory; the code and 
>string storage. If you go through the file-system to handle each and 
>every read from this area, then performance sucks. You need to manage a 
>local cache of pages from that area to get reasonable performance.

No file system.  Games are already in RAM.  Can't imagine needing to
cache that!

-david

From ???@??? Thu Feb 19 16:59:17 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
Message-Id: <199802182342.KAA20343@yallara.cs.rmit.edu.au>
Subject: [z-machine] Inform source code query
To: z-machine@gmd.de
Date: Thu, 19 Feb 1998 10:42:44 +1100 (EST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ec53d9fc66c21443b51eb2b646112aac

I'm finally near completion of my IF IDE environment for Win95/NT, and I'm
in the middle of creating a COM (component Object Model) shell replacement
for the Inform.c frontend file. And I've run into a problem.

In several of the files, in particular errors.c, there are several occurances
of "longjmp(g_fallback, 1);". Now, I may be missing something fundamental
here, but I can't find an occurance of an accompanying "setjmp" anywhere
within the source code, nor a declaration of the g_fallback variable used.

Where exactly does these statements jump to? Thanks for any help. I just 
need to know the destination of the statement so the COM object can clean
up before terminating.


-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Thu Feb 19 16:59:19 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802182344.SAA01098@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Wed, 18 Feb 1998 18:50:25 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] [Blorb] Blorb Files for Infocom V6 games
Reply-To: Jason C Penney <jpenney@chelmsford.com>
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e5da25005ebd4fafc0b1605c9bf0911c

Hi,

I have put what I believe to be final versions of the Blorb files for all 
the Infocom V6 games up at: 
<http://www.chelmsford.com/home/jpenney/V6Lib/blorb/>

If anyone finds any problems with them please let me know.  I still 
haven't been able to convert the sound files to AIFF, so I still haven't 
finished the files for Sherlock and The Lurking Horror.

Later,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Thu Feb 19 16:59:39 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980218181739.55259@nowhere.xmission.com>
Date: Wed, 18 Feb 1998 18:17:39 -0700
From: Matt Kimball <mkimball@xmission.com>
To: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>, z-machine@gmd.de
Subject: Re: [z-machine] Inform source code query
References: <199802182342.KAA20343@yallara.cs.rmit.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
In-Reply-To: <199802182342.KAA20343@yallara.cs.rmit.edu.au>; from Paul Francis Gilbert on Thu, Feb 19, 1998 at 10:42:44AM +1100
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 51e4b889e47f926bcd44a1794f63830a

On Thu, Feb 19, 1998 at 10:42:44AM +1100, Paul Francis Gilbert wrote:
> I'm finally near completion of my IF IDE environment for Win95/NT, and I'm
> in the middle of creating a COM (component Object Model) shell replacement
> for the Inform.c frontend file. And I've run into a problem.

Nice.  Will the source be available for porting to other systems?  Or
is nearly all the code tied to Win32?

> In several of the files, in particular errors.c, there are several
> occurances of "longjmp(g_fallback, 1);". Now, I may be missing
> something fundamental here, but I can't find an occurance of an
> accompanying "setjmp" anywhere within the source code, nor a
> declaration of the g_fallback variable used.

It looks like that is only relevant to the Mac port.  All the uses of
it are bracketed with '#ifdef MAC_FACE'.

Matt Kimball
mkimball@xmission.com

From ???@??? Thu Feb 19 17:00:56 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: Paul Francis Gilbert <pfg@yallara.cs.rmit.edu.au>
Message-Id: <199802190241.NAA09372@yallara.cs.rmit.edu.au>
Subject: Re: [z-machine] Inform source code query
To: z-machine@gmd.de
Date: Thu, 19 Feb 1998 13:41:23 +1100 (EST)
In-Reply-To: <19980218181739.55259@nowhere.xmission.com> from "Matt Kimball" at Feb 18, 98 06:17:39 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7f53778a0896888860cfab129342b665

> 
> On Thu, Feb 19, 1998 at 10:42:44AM +1100, Paul Francis Gilbert wrote:
> > I'm finally near completion of my IF IDE environment for Win95/NT, and I'm
> > in the middle of creating a COM (component Object Model) shell replacement
> > for the Inform.c frontend file. And I've run into a problem.
> 
> Nice.  Will the source be available for porting to other systems?  Or
> is nearly all the code tied to Win32?

The actual IDE system will be for Win32 only. It's been a major project for
many months, designing a visual IDE environment that would allow the easy
plugging in of new IF languages, but also the easy addition of experts to
do all the sort of things people have been talking about, like room
generators, quoted text spell checking, etc.

The actual compiler object is a separate entity, which uses the COM 
definitions. Since I hear the Mac now supports the COM model, it should
be able to compile for both PC's and Macs, but nothing else.

> 
> > In several of the files, in particular errors.c, there are several
> > occurances of "longjmp(g_fallback, 1);". Now, I may be missing
> > something fundamental here, but I can't find an occurance of an
> > accompanying "setjmp" anywhere within the source code, nor a
> > declaration of the g_fallback variable used.
> 
> It looks like that is only relevant to the Mac port.  All the uses of
> it are bracketed with '#ifdef MAC_FACE'.
> 

I was right. I was missing something obvious. I didn't look back and notice
the #ifdef block. Thanks, Matt for pointing out the obvious for me.

On a related note, though, is there any problem with using longjmp on
machines other than the Mac? I checked through my compiler index, and it
said that longjmp was an ANSI construct. It's just that I'll need a way for
all error exists to jump to a common 'exit point' routine, and the
setjmp/longjmp seems to be a good solution. Any thoughts appreciated.

> Matt Kimball
> mkimball@xmission.com
> 

I posted an anouncement a few days ago that screenshots of the PIDE system
are now available from my website, but our news server was going up and
down more times than a pair of kangaroos in the mating season (little
Red Dwarf humor there ;-)), so I'm not sure if got through. Since I got no
followups or replies, I'm assuming it didn't, so I'll post again.
http://yallara.cs.rmit.edu.au~/pfg/

-- 
Paul Gilbert           | pfg@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia	       | creatures from Alpha Centauri.

From ???@??? Sat Feb 21 11:37:18 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802200343.WAA20292@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Thu, 19 Feb 1998 22:49:48 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] Lurking Horror Sounds
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6942dcbbb8ae39095702feaadf1f00dd

Hi,

I've now managed to convert all the Infocom sound files to AIFF, except 
sound 17 from the Lurking Horror.  Can anyone verify for me that the 
LURKIN17.SND file on GMD is valid?  If so, can anyone convert this one 
file for me?  (please let me know before sending it to me, I don't need 
to drown in AIFF files...)

Thanks,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Feb 21 11:37:22 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <004d01bd3dcc$55be4ec0$cc054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: [z-machine] [BLORB] PNG and file sizes
Date: Fri, 20 Feb 1998 07:42:02 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 794b160f1c2f1bd92464554b0afe3041

I just noticed in horror while messing around with the graphics I plan to
include in my game that the 64k JPEG file turns into a monstrous 323k PNG
file! And it's not even 640x480!

To be brutally honest, this is unbearable. I plan to include at least 10
high-quality (i. e. high-colour) pictures, which would mean (if I don't do
sounds) at least 5 MB download for an IF game!

Comments? Suggestions?

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+


From ???@??? Sat Feb 21 11:37:43 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980220075915.27749.qmail@hotmail.com>
X-Originating-Ip: [144.126.195.141]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Content-Type: text/plain
Date: Fri, 20 Feb 1998 02:59:15 EST
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cef40cfa2f38451f59ea03bacbaf95a3



>From: "Gunther Schmidl" <sothoth@usa.net>
>To: "Z-Machine List" <z-machine@gmd.de>
>Subject: [z-machine] [BLORB] PNG and file sizes
>Date: Fri, 20 Feb 1998 07:42:02 +0100
>
>I just noticed in horror while messing around with the graphics I plan 
to
>include in my game that the 64k JPEG file turns into a monstrous 323k 
PNG
>file! And it's not even 640x480!
>
>To be brutally honest, this is unbearable. I plan to include at least 
10
>high-quality (i. e. high-colour) pictures, which would mean (if I don't 
do
>sounds) at least 5 MB download for an IF game!

I think that Gunther's got a good point here.  I'm sure that there';s 
room in the Blorb specs to allow BOTH png and jpeg, non?

If not, we should make it.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From ???@??? Sat Feb 21 11:37:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980220093129.51696@bartlet.df.lth.se>
Date: Fri, 20 Feb 1998 09:31:29 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
References: <19980220075915.27749.qmail@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89
In-Reply-To: <19980220075915.27749.qmail@hotmail.com>; from L. Ross Raszewski on Fri, Feb 20, 1998 at 02:59:15AM -0500
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 84be8cb66b8fb3adbbcde750c071fb8a

On Fri, Feb 20, 1998 at 02:59:15AM -0500, L. Ross Raszewski wrote:
> >I just noticed in horror while messing around with the graphics I plan 
> to
> >include in my game that the 64k JPEG file turns into a monstrous 323k 
> PNG
> >file! And it's not even 640x480!
> >
> >To be brutally honest, this is unbearable. I plan to include at least 
> 10
> >high-quality (i. e. high-colour) pictures, which would mean (if I don't 
> do
> >sounds) at least 5 MB download for an IF game!
> 
> I think that Gunther's got a good point here.  I'm sure that there';s 
> room in the Blorb specs to allow BOTH png and jpeg, non?
> 
> If not, we should make it.

I think we should.  The reason is that JPEG and PNG are good for
different things: JPEG uses lossy compression which makes it good for
photos, but bad for line drawings with lots of detail. PNG is
lossless.

That said, I have no idea why Gunther's JPEG image grew by a factor of
five, or if PNG images are _invariable_ somuch larger than JPEG
ones. WHich program did you use for the conversion?

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------

From ???@??? Sat Feb 21 11:38:09 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: sothoth@usa.net
Date: Fri, 20 Feb 1998 12:37:09 +0100
Message-Id: <199802201137.AA41306@alijku04.edvz.uni-linz.ac.at>
To: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
X-Mailer: programmed by Christoph Ertl christoph.ertl@jk.uni-linz.ac.at
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e6be92e5082c8d987a99900ddd9904d3

Magnus wrote:
>I think we should. The reason is that JPEG and PNG are good for
>different things: JPEG uses lossy compression which makes it good for
>photos, but bad for line drawings with lots of detail. PNG is
>lossless.

'xactly. And my pics can be lossy - they'd still look smashing
as they are 24-bit colour (I think :-)

>That said, I have no idea why Gunther's JPEG image grew by a factor of
>five, or if PNG images are _invariable_ somuch larger than JPEG
>ones. WHich program did you use for the conversion?

I used Adobe Photoshop 4.0
AFAIK, PNG doesn't compress. JPEG does so, very much so, even.
That may be why. I tried black/white JPEG, and it still
increased to 200kb or so.

From ???@??? Sat Feb 21 11:38:15 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980220133653.40492@bartlet.df.lth.se>
Date: Fri, 20 Feb 1998 13:36:53 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
References: <199802201137.AA41306@alijku04.edvz.uni-linz.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89
In-Reply-To: <199802201137.AA41306@alijku04.edvz.uni-linz.ac.at>; from sothoth@usa.net on Fri, Feb 20, 1998 at 12:37:09PM +0100
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ca945a8e5393a49b568c299bbd3b5548

On Fri, Feb 20, 1998 at 12:37:09PM +0100, sothoth@usa.net wrote:
> AFAIK, PNG doesn't compress. 

It does. I converted a bunch of 16 mm film images to PNG a couple of
weeks ago. Let's see (sounds of shuffling thorugh a stack of
CD-ROMs). Here's a typical image: 1418*918 pixels, 24-bit
colour. That makes for 3.7 MB of data. The PNG file is 1.9 M in
size. If I convert it to JPEG, the resulting file is only 0.2 M large.

> JPEG does so, very much so, even.

It obviously does. The reason for this is the lossiness of JPEG: you
simply throw out a lot of information in order to be able to compress
better.

In this particular case, the images were from a film of rather smooth
objects, which means that there will be very much redundancy in the
data, so lossy compression is justified. It is very difficult to see
any diffference between the PNG and JPG images with the naked
eye. However, there apparently are cases where JPEG is markedly
inferior. It's been claimed on this list that these cases include
things such as drawn maps, writing,and so on: images that are likely to
appear in adventure games.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------

From ???@??? Sat Feb 21 11:38:24 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 20 Feb 1998 09:01:22 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199802201401.JAA14172@pond.com>
To: z-machine@gmd.de
Subject: Re:  [z-machine] [BLORB] PNG and file sizes
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8164431e62e0f3a6283297ce40a64066

} I just noticed in horror while messing around with the graphics I plan to
} include in my game that the 64k JPEG file turns into a monstrous 323k PNG
} file! And it's not even 640x480!

} To be brutally honest, this is unbearable. I plan to include at least 10
} high-quality (i. e. high-colour) pictures, which would mean (if I don't do
} sounds) at least 5 MB download for an IF game!

} Comments? Suggestions?

1) Quantize your pictures down to 8 bits
(or)
2) Restart the whole JPEG argument
(or)
3) Make up a standard for putting JPEGs into BLORB.  Conspire with an
interpreter writer to implement it, and present it as a fait accompli
(disadvantage is that this will probably get you lynched)

From ???@??? Sat Feb 21 11:39:00 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980220174942.20311.qmail@hotmail.com>
X-Originating-Ip: [144.126.195.141]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Content-Type: text/plain
Date: Fri, 20 Feb 1998 12:49:41 EST
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5f54c3124a45c225aca19a1e61476cba



>
>PNG does compress, and very well I might add.  But, what JPEG does is 
not
>compression IMO, it simply leaves out much of the picture.  This is not 
to
>big a deal for true colour pictures unless you leave out too much (or 
have
>a good eye for detail, I can easly tell a JPEG from a PNG just by 
looking
>at them).  But, because PNG doesn't destroy the picture in the process 
the
>resulting file is larger.  Try saving a JPEG with no loss and see how 
big
>the file is :-)
>
>But, perhaps JPEG should be in the Blorb standard.

Actually, Jpeg dies compress, on top of being lossy.  at minimum 
compression (my converter of choice allows a maximum quality of 95%) a 
jpeg is still significantly smaller than a similar PNG.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From ???@??? Sat Feb 21 11:39:06 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980220174539.13031.qmail@hotmail.com>
X-Originating-Ip: [144.126.195.141]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Content-Type: text/plain
Date: Fri, 20 Feb 1998 12:45:38 EST
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 47a916c25e0c216b1106da8db66bbe0e



>Date: Fri, 20 Feb 1998 09:31:29 +0100
>From: Magnus Olsson <mol@df.lth.se>
>To: z-machine@gmd.de
>Subject: Re: [z-machine] [BLORB] PNG and file sizes
>I think we should.  The reason is that JPEG and PNG are good for
>different things: JPEG uses lossy compression which makes it good for
>photos, but bad for line drawings with lots of detail. PNG is
>lossless.
>
>That said, I have no idea why Gunther's JPEG image grew by a factor of
>five, or if PNG images are _invariable_ somuch larger than JPEG
>ones. WHich program did you use for the conversion?
>

It's invariable to be sure.  I've tried about 3 different programs that 
do PNG conversion, and PNG is definately a larger format.  Of course, 
any lossy format is going to get more compression (otherwise, people 
would have stopped using it in favor of something else.  I know of one 
or two formats that went this way)
5 to 1 isn't all that odd, consdidering that a 256 color GIF image in 
the neighborhood of 200-300 K converts to a true-color Jpeg in the 
neighborhood of 20-50 K

The moral of the story (arrrgh... sermonizing!) is that we need both a 
lossy format for Photo-quality images, and a non-lossy format for line 
art (Lemme tell ya, jpeg does not do too well with fine lines.)

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From ???@??? Sat Feb 21 11:39:39 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 20 Feb 1998 11:24:54 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom6
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] [BLORB] PNG and file sizes
In-Reply-To: <19980220075915.27749.qmail@hotmail.com>
Message-Id: <Pine.SUN.3.95.980220110526.14773C-100000@netcom6>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 06b5691c37704379aaf7699d0b4c593c

On Fri, 20 Feb 1998, L. Ross Raszewski wrote:

> >To be brutally honest, this is unbearable. I plan to include at least 
> 10
> >high-quality (i. e. high-colour) pictures, which would mean (if I don't 
> do
> >sounds) at least 5 MB download for an IF game!

You've got the images; that's how much data you want people to download.
The question is what forms of compression we allow and require.

> I think that Gunther's got a good point here.  I'm sure that there's 
> room in the Blorb specs to allow BOTH png and jpeg, non?

The Blorb spec structure, per se, could allow any number of image formats.

In the current system, a Blorb-compliant V6 interpreter *must* be able to
display PNG images, and game authors *must* use PNG format.

You are requesting that things be changed so that game authors *may* use
PNG or JPEG format, and interpreters *must* be able to display both PNG
and JPEG format. 

Also affected is the player, who will have to download files of different
sizes, as already noted.. So that's three groups of people who must be
considered. 

When writing Blorb, I intentionally made things as easy as possible for
interpreter authors, at the possible expense of authors and players. Why? 
Because we don't have any compliant interpreters and I *want some*. This
whole project is a waste of time unless someone gets a Blorb-Frotz (or
whatever) working, and I don't want to tell that person "Oh, and you have
to support two different image formats."

Also on the subject of compression: PNG does have a built-in (patent-free) 
compression mode. Is it possible that your graphics programs is saving
PNG files without compression? If so, the problem could be a lot less
severe than it looks. 

Also, have you tried doing ordinary file compression (zip or gzip) on the
image files? If there's a lot of unnecessary repetition in the PNG data,
then zip might compress it a lot more than zip would compress JPEG. In
that case, again, the problem would be smaller than it looks. (It's not
a big deal if Blorb files are always kept zipped on gmd.de.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Sat Feb 21 11:39:45 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <009401bd3e3e$60cd3e80$0d054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Date: Fri, 20 Feb 1998 21:20:41 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 15e425db6bf91806cc107c22dca7df72

Andrew Plotkin wrote:

>You are requesting that things be changed so that game authors *may* use
>PNG or JPEG format, and interpreters *must* be able to display both PNG
>and JPEG format.

Would it be THAT hard to do? Implementation-wise, I mean?

>Also affected is the player, who will have to download files of different
>sizes, as already noted.. So that's three groups of people who must be
>considered.

Why? There'd be only one blorb file, containing both JPGs and PNGs, as
needed.

>(It's not a big deal if Blorb files are always kept zipped on gmd.de.)

Until they are unzipped on the user's hard disk. If he has one.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+


From ???@??? Sat Feb 21 11:39:48 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <009501bd3e3e$61ea9560$0d054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: [z-machine] Amiga Mode (once again)
Date: Fri, 20 Feb 1998 21:28:24 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 4f64808327f0182f4a1d413d0eaea266

I'm afraid I have to walk this well-trodden path once again, and add some
comments.

Enter Beyond Zork in "Amiga Mode." Watch as it displays three colours at
once. I know it's no V6 game, but that doesn't matter.

Enter any V6 game in Amiga Mode. What do we have? Two colours for the whole
screen. Which means, if I want coloured input, I can't have it. If I want
mid-line colour changes, I can't have them. If I want... you get the idea.

Enter MCGA mode for the same game. OK. Not only does MCGA look unbelievably
shit (sorry, but that's the only word I could find - and it has nothing to
do with you interpreter writers. You're doing a great job), it also doesn't
react the same as Amiga mode, as it has more colours available at once.
Which means I have to change the statusline colour by hand if I want to do a
box (with V6Lib), and back again afterwards - a Very Bad Thing.
(I don't know if that box code is publicly available yet)

So, for crying out loud, WHY would ANYBODY still want to stick with those
old, limited formats (except for the old Infocoms, of course)?

Come on. PLEASE.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+


From ???@??? Sat Feb 21 11:39:57 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802202115.QAA00204@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Fri, 20 Feb 1998 16:21:46 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <19980220075915.27749.qmail@hotmail.com>
In-Reply-To: <Pine.SUN.3.95.980220110526.14773C-100000@netcom6>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ed2ee7c4af0dbb84f74e048955035814

Andrew Plotkin sent a message across the ether on 20 Feb 98 (11:24) 
stating:
 
> When writing Blorb, I intentionally made things as easy as possible for
> interpreter authors, at the possible expense of authors and players. Why? 
> Because we don't have any compliant interpreters and I *want some*. This
> whole project is a waste of time unless someone gets a Blorb-Frotz (or
> whatever) working, and I don't want to tell that person "Oh, and you have
> to support two different image formats."

This (IMHO) is the most important thing to consider right now.  Until 
there is at least one Blorb compliant interpreter it seems a bit much 
add to it in a way that will increase the work load for interpreter 
authors.  V6 is pretty scary, and Blorb support (as it stands) isn't 
that simple either (PNG support, MOD support, AIFF support...), even 
with BlorbLib and PNGLib.

As things stand people like Gunther and myself can't even currently test 
images in game, which is rather a bummer.  I'm afraid if we make Blorb 
any more complicated that it may be quite a long time before we can.  :(

Any interpreter authors feel like sharing there current position on 
Blorb? (pick one or something)

*	My interpreter will never support Blorb.
*	My interpreter will support Blorb when I get around to it.
*	My interpreter will support Blorb.  I'm working on it now.
*	I'm not sure.
*	[Other]

> Also, have you tried doing ordinary file compression (zip or gzip) on the
> image files? If there's a lot of unnecessary repetition in the PNG data,
> then zip might compress it a lot more than zip would compress JPEG. In
> that case, again, the problem would be smaller than it looks. (It's not
> a big deal if Blorb files are always kept zipped on gmd.de.)

This would in fact be a plus in some cases.  I know that the web server 
I use isn't inclined to send the Blorb files on my site as binary, it 
thinks it must be text.  It knows .zip files are binary.  

<rant>
Why can't web servers use something better than extensions to figure 
this out?  The unix file command can figure this out pretty well, can't 
it?  Do any modern non-Windows systems use extensions in this manner?  
Who thought this was a good idea?  With all the useless things you can 
do on the web, there is no easy way to give a mime type for a file! 
Why?!?!?!?   
</rant>

I'd also advice using max-compression if possible (zip -9 or pkzip -ex 
or gzip -9).

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Feb 21 11:40:01 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802202115.QAA00209@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Fri, 20 Feb 1998 16:21:47 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <009401bd3e3e$60cd3e80$0d054e8c@async.edvz.uni-linz.ac.at>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 88f166ed7c31bd41413a7af40887c7f5

Gunther Schmidl sent a message across the ether on 20 Feb 98 (21:20) 
stating:

> Andrew Plotkin wrote:
> 
> >You are requesting that things be changed so that game authors *may* use
> >PNG or JPEG format, and interpreters *must* be able to display both PNG
> >and JPEG format.
> 
> Would it be THAT hard to do? Implementation-wise, I mean?

I'm not that sure, but think about the compression of both formats. Now 
think about the amount of code for uncompression of either format.  I 
would think that JPEG could be a nightmare, but I may be wrong.
 
> >Also affected is the player, who will have to download files of different
> >sizes, as already noted.. So that's three groups of people who must be
> >considered.
> 
> Why? There'd be only one blorb file, containing both JPGs and PNGs, as
> needed.

I think he mean: If we add JPEG support they download smaller files that 
if we don't.  I don't think he's saying that there will be two different 
files, but that the decision will effect the size of the file the player 
will need to download. (and again I could be wrong)

> >(It's not a big deal if Blorb files are always kept zipped on gmd.de.)
> 
> Until they are unzipped on the user's hard disk. If he has one.

On what platforms that have/are going to have/potentially could have 
(modern) V6 support is this going to be a large issue?  I'm not trying 
to argue, I'm really curious.  (this time I'm not wrong, I am curious)

Maybe you could post on rgif and ask "If I released a Inform game with 
graphics, and the file was [whatever], would this affect your decision 
to play it?" or something.

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Feb 21 11:40:04 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802202143.QAA00572@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Fri, 20 Feb 1998 16:50:15 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Amiga Mode (should die!)
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <009501bd3e3e$61ea9560$0d054e8c@async.edvz.uni-linz.ac.at>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b2c202d6e270b66018d6065a9ca6dce9

Gunther Schmidl sent a message across the ether on 20 Feb 98 (21:28) 
stating:

> I'm afraid I have to walk this well-trodden path once again, and add some
> comments.

Here we go![1]
 
> Enter MCGA mode for the same game. OK. Not only does MCGA look unbelievably
> shit (sorry, but that's the only word I could find - and it has nothing to
> do with you interpreter writers. You're doing a great job), it also doesn't
> react the same as Amiga mode, as it has more colours available at once.
> Which means I have to change the statusline colour by hand if I want to do a
> box (with V6Lib), and back again afterwards - a Very Bad Thing.
> (I don't know if that box code is publicly available yet)

No the code isn't available publicly yet.  This is one of the reasons 
why.  I made "box" use the colour scheme stored in the Status Window, 
because it is the status window that draws the box.  I couldn't think of 
anything better to do that would be compatible with Inform's box 
syntax...

> So, for crying out loud, WHY would ANYBODY still want to stick with those
> old, limited formats (except for the old Infocoms, of course)?

The solution to this is to base future V6 Z-Machine games and 
interpreters on the MCGA screen model (which I believe is identical/very 
similar to Infocom's V6 Mac screen model) and claim the Dos machine 
version number.  I have tried to make V6Lib usable on both screen 
models, and it is, to an extent.  But it's a real pain to right one set 
of code that looks good on both models, without having every other V6Lib 
command surrounded by checks against the machine number.  I still think 
game authors should TRY to make the game look good in Amiga mode, but my 
game won't until Release 2 at least.

Example:
As was pointed out, more modern Amigas don't need the restrictions of the
V6 Amiga screen model.  If there is ever an interpreter to prove this, it
should claim the Dos Machine number.

The MCGA model doesn't have colour depth restrictions built in (which 
the Amiga mode does).  The 8bit limit is imposed by interpreters, the 
MCGA screen model doesn't rely on it (again, the Amiga model relies on 
having only 16 colours).  It doesn't have screen resolution or aspect 
ratio restrictions AFAIK.  It works in a much more reasonable way.

I know I stated in the past that I believed the Amiga model to be a good 
thing, but I was wrong.  Stefan Jokisch convinced me of this, and I 
thank him for showing me the light.  All that is lost by using MCGA over 
Amiga is 2 shades of gray, the gains are much larger.  Also, if screwing
with the Amiga screen model is more likely to break compatability with 
the Infocom V6 games.

The problems with the MCGA model are mostly (all?) artificial.  It has 
low resolution, but it doesn't need to.  It has a REAL ugly font, but it 
doesn't need to.  The fixed width font and the prop. font in fixed 
style are identical, and they HURT to look at, but it needn't be so.  It 
doesn't do bold, but it could.


Jay
(phew!)



[1] See Mario 64

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sat Feb 21 11:40:11 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 20 Feb 1998 14:01:08 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom6
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Amiga Mode (once again)
In-Reply-To: <009501bd3e3e$61ea9560$0d054e8c@async.edvz.uni-linz.ac.at>
Message-Id: <Pine.SUN.3.95.980220135825.25623B-100000@netcom6>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 97f237adf3d31c35689a01caa5b6dd47

On Fri, 20 Feb 1998, Gunther Schmidl wrote:

> So, for crying out loud, WHY would ANYBODY still want to stick with those
> old, limited formats (except for the old Infocoms, of course)?

What exactly are you suggesting?

I don't know if anyone wants to continue playing in these modes.

I don't think we should declare these modes to be *illegal*. 

I wouldn't mind if a lot of future games looked like crap in these modes.
I wouldn't even mind if they could look a little better but didn't try.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Sat Feb 21 11:40:20 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <012d01bd3e52$a16a98c0$0d054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine Mailing List" <z-machine@gmd.de>
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Date: Fri, 20 Feb 1998 23:44:18 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 2aeaeef68f63af9cdcd866405454d067

>>Gunther Schmidl sent a message across the ether on 20 Feb 98 (21:20)
>>stating:
>>Would it be THAT hard to do? Implementation-wise, I mean?
>
>I'm not that sure, but think about the compression of both formats. Now
>think about the amount of code for uncompression of either format.  I
>would think that JPEG could be a nightmare, but I may be wrong.

PNG is a standard Huffman compression; complete plug-in C libraries are
available (according to www.boutell.com/boutell/png/). I don't know about
JPEG, but as (for example) Netscape released their source code...
I must admit, though, that I have no idea how much effort that would be.

>I think he mean: If we add JPEG support they download smaller files that
>if we don't.  I don't think he's saying that there will be two different
>files, but that the decision will effect the size of the file the player
>will need to download. (and again I could be wrong)

You are right.

>> Until they are unzipped on the user's hard disk. If he has one.
>
>On what platforms that have/are going to have/potentially could have
>(modern) V6 support is this going to be a large issue?  I'm not trying
>to argue, I'm really curious.  (this time I'm not wrong, I am curious)

Ok, so I didn't think :-) Where would he download the zipped file to, then?


[and in another mail, he wrote]

>As things stand people like Gunther and myself can't even currently test
>images in game, which is rather a bummer.  I'm afraid if we make Blorb
>any more complicated that it may be quite a long time before we can.  :(

Of course I can test stuff on my machine with PNG only - it's fast and has a
large hard drive - but still, I think of those users that use dial-up (as I
do), or have to pay per downloaded megabyte (or hour)...
What I'm trying to say is that yes, go ahead and add PNG support, and
release your interpreters; but please consider adding JPEG as fast as
possible. When I finally finish my game, I'd really like support of both.
And it *will* take a long time.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+




From ???@??? Sat Feb 21 11:40:26 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <012e01bd3e52$a2c98c80$0d054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: Re: [z-machine] Amiga Mode (should die!)
Date: Fri, 20 Feb 1998 23:45:23 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a7747369bdc077f03674e4073e9dfce1

Jason C. Penney wrote:

>I have tried to make V6Lib usable on both screen
>models, and it is, to an extent.  But it's a real pain to right one set
>of code that looks good on both models, without having every other V6Lib
>command surrounded by checks against the machine number.  I still think
>game authors should TRY to make the game look good in Amiga mode, but my
>game won't until Release 2 at least.

I can only second that. It is fascinating what sorts of tricks you have to
do so that a game looks the same in Amiga and MCGA Mode (Mine doesn't - see
the statement about changing colours mid-line, which only works in MCGA),
and if you want a text-only version (V5, V8) too, it means even more code
(tons of #ifdefs). As long as the screen models are as... limited... as they
are now, I have to test the game in three screen modes to see if it works -
and changing *one* *line* can do different things in every screen model.
Believe me, I'm not exaggerating. Try having the input be another colour as
the game text in all three models (and it doesn't work in Amiga mode!) with
one code.
Impossible.

>All that is lost by using MCGA over
>Amiga is 2 shades of gray, the gains are much larger.

For text colours, that is.

>Also, if screwing
>with the Amiga screen model is more likely to break compatability with
>the Infocom V6 games.

I say, leave Amiga as it is (and I think we all have the same opinion on
this), and either improve on MCGA or add something completely new.

>The problems with the MCGA model are mostly (all?) artificial.  It has
>low resolution, but it doesn't need to.  It has a REAL ugly font, but it
>doesn't need to.  The fixed width font and the prop. font in fixed
>style are identical, and they HURT to look at, but it needn't be so.  It
>doesn't do bold, but it could.

Which says it all, I believe :-)

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+




From ???@??? Sat Feb 21 11:40:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <013c01bd3e53$23519a00$0d054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: Re: [z-machine] Amiga Mode (once again)
Date: Fri, 20 Feb 1998 23:58:56 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f078496302d13d27e4ebc70cc70c25b9

Andrew Plotkin wrote:
>
>> So, for crying out loud, WHY would ANYBODY still want to stick with those
>> old, limited formats (except for the old Infocoms, of course)?
>
>What exactly are you suggesting?
>
>I don't know if anyone wants to continue playing in these modes.

They'd need to for Atrhur, Shogun, Journey and Zork Zero.

>I don't think we should declare these modes to be *illegal*.

Of course not. See above.

>I wouldn't mind if a lot of future games looked like crap in these modes.

I would - that depends on the point of view. Why mess with 16 colours (or
even 2), when you can have 256, or even up to 16,000,000?

>I wouldn't even mind if they could look a little better but didn't try.

I admit I don't understand.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+



From ???@??? Sat Feb 21 12:43:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 20 Feb 1998 16:10:16 -0800 (PST)
From: Patrick <patrick@syix.com>
To: "L. Ross Raszewski" <rraszews@hotmail.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
In-Reply-To: <19980220174942.20311.qmail@hotmail.com>
Message-Id: <Pine.BSI.3.95.980220160819.27834A-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e92b2d41dbf7ddb9bfc60e57b425a372

On Fri, 20 Feb 1998, L. Ross Raszewski wrote:

>Actually, Jpeg dies compress, on top of being lossy.  at minimum 
>compression (my converter of choice allows a maximum quality of 95%) a 
>jpeg is still significantly smaller than a similar PNG.

Well, my video digitiser saves in both IFF (very little compression) and
JPEG (at any quality, 0 to 100%) and a JPEG saved at 100% is very close in
size to an IFF image.

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Sat Feb 21 13:03:33 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 20 Feb 1998 16:34:30 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] [BLORB] PNG and file sizes
In-Reply-To: <012d01bd3e52$a16a98c0$0d054e8c@async.edvz.uni-linz.ac.at>
Message-Id: <Pine.BSI.3.95.980220163244.27834B-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ece7f058287aedf0eaf4aee0b64b5389

On Fri, 20 Feb 1998, Gunther Schmidl wrote:

>PNG is a standard Huffman compression; complete plug-in C libraries are
>available (according to www.boutell.com/boutell/png/). I don't know about
>JPEG, but as (for example) Netscape released their source code...
>I must admit, though, that I have no idea how much effort that would be.

JPEG is also available as a complete C library.  Do a search of the
internet I'm sure they're available somewhere.

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Sat Feb 21 13:03:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 20 Feb 1998 16:37:11 -0800 (PST)
From: Patrick <patrick@syix.com>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Amiga Mode (should die!)
In-Reply-To: <012e01bd3e52$a2c98c80$0d054e8c@async.edvz.uni-linz.ac.at>
Message-Id: <Pine.BSI.3.95.980220163550.27834D-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cfce3783bfc6262928cca2477dcaa278

On Fri, 20 Feb 1998, Gunther Schmidl wrote:

>I say, leave Amiga as it is (and I think we all have the same opinion on
>this), and either improve on MCGA or add something completely new.

I'm sure this has been discussed before, but why don't we just make a new
machine number that supports all the Amiga colours with all the benifits
of DOS?

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Sun Feb 22 06:25:00 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980221154122.40420@bartlet.df.lth.se>
Date: Sat, 21 Feb 1998 15:41:22 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
References: <19980220075915.27749.qmail@hotmail.com> <Pine.SUN.3.95.980220110526.14773C-100000@netcom6>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89
In-Reply-To: <Pine.SUN.3.95.980220110526.14773C-100000@netcom6>; from Andrew Plotkin on Fri, Feb 20, 1998 at 11:24:54AM -0800
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c0c3441aba8efb21df84b46c1c3edaa0

On Fri, Feb 20, 1998 at 11:24:54AM -0800, Andrew Plotkin wrote:
> Also on the subject of compression: PNG does have a built-in (patent-free) 
> compression mode. Is it possible that your graphics programs is saving
> PNG files without compression? If so, the problem could be a lot less
> severe than it looks. 

I don't think you *can* turn off PNG compression in PaintShop Pro (which Gunther
was using to produce his PNG files). My experience with PNG is that the compression
is usually around 50% for photographic images. JPEG's lossy compression
is much, much better than that, but, of course, it's lossy.

> Also, have you tried doing ordinary file compression (zip or gzip) on the
> image files? If there's a lot of unnecessary repetition in the PNG data,
> then zip might compress it a lot more than zip would compress JPEG.

PNG images, being already compressed, don't compress further with
Zip. I just tried gzipping my 2.2 M image, and the gzipped file was
*larger* than the original (because gzip adds headers, compression
tables and such).

>From this I make the educated guess that even if your image conversion
program produces uncompressed PNG's, gzipping them wouldn't do much
better than halving the image size, i.e. a comparable result to PNG's
built-in compression.

Zarf is right in that this would still be better than what gzip could
do for JPEG images (which, like compressed PNG's, don't compress at
all), but it's absolute image size that counts, not compression
ratios, and the JPEG image would be five times smaller than the PNG
file to start with.

About the "politics" of Blorb: I agree that it's important to get
Blorb-compliant interpreters up and running ASAP, so people can start
writing games with graphics - there seems to be a great dealof pent-up
interest. If this means going for PNG-only initially, then I think JPEG
could wait.

However, I think that since people will probably want to make games where
the graphics are based on photos, and where the images will make huge
PNG files but will stand some "abuse" by lossy compression algorithms,
there will be a demand for JPEG support in Blorb.

If I understand things correctly, adding JPEG support to the Blorb
format is simple. The problem is how difficult it would be for the
interpreter writers to implement it. But there are standard image
conversion libraries available for free, and hopefully code from those
libraries could be used.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------

From ???@??? Sun Feb 22 06:25:21 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 21 Feb 1998 10:01:00 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom7
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Amiga Mode (once again)
In-Reply-To: <013c01bd3e53$23519a00$0d054e8c@async.edvz.uni-linz.ac.at>
Message-Id: <Pine.SUN.3.95.980221095819.27756E-100000@netcom7>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1c5cbf66800ac796be6df84fac87e616

On Fri, 20 Feb 1998, Gunther Schmidl wrote:

> Andrew Plotkin wrote:
> >I wouldn't mind if a lot of future games looked like crap in these modes.
> 
> I would - that depends on the point of view. Why mess with 16 colours (or
> even 2), when you can have 256, or even up to 16,000,000?
> 
> >I wouldn't even mind if they could look a little better but didn't try.
> 
> I admit I don't understand.

I just mean: if V6lib doesn't work right on Infocom's Amiga interpreter,
and JCP doesn't want to put in the work to make it do so, that's really
not a big deal.

Now, if we ignore that one display mode -- with its two-color limit,
etc -- can we write to the Z-Spec and not worry about machine numbers any
more? Or are there further problems?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Feb 06 08:13:32 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 3 Feb 1998 23:52:38 -0800 (PST)
From: Patrick <patrick@syix.com>
To: Gunther Schmidl <sothoth@usa.net>
Cc: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] V6 Z-Machine Stuff
In-Reply-To: <001001bd313e$94cf7840$d5054e8c@async.edvz.uni-linz.ac.at>
Message-Id: <Pine.BSI.3.95.980203234936.29076A-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 35c6e096cf438666cf415d1612934066

On Wed, 4 Feb 1998, Gunther Schmidl wrote:

>Ok, but here's a general question: doesn't the problem of running a V6 game
>on, say, an Amiga and a true-colour PC have the additional trouble for the
>author to not use colours in-game as the Amiga interpreter (I'm talking
>about Frotz Amiga mode here) doesn't support changing colours mid-line, and
>to use them otherwise?

I think we should remember that Amiga mode in DOS Frotz is very different
then AmigaFrotz.  For instance, changing colour in mid-line works fine on
a real Amiga.  

But wait a sec, I just tried running Dos Frotz in a PC emulator in Amiga
mode and it seemed to handle colour correctly.  This was a v5 game though,
is this brokin in v6 games only?

Patrick (I love that comic font in DOS Frotz, gotta find me a copy)
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Sat Feb 21 11:38:20 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 20 Feb 1998 04:50:18 -0800 (PST)
From: Patrick <patrick@syix.com>
To: sothoth@usa.net
Cc: z-machine@gmd.de
Subject: Re: [z-machine] [BLORB] PNG and file sizes
In-Reply-To: <199802201137.AA41306@alijku04.edvz.uni-linz.ac.at>
Message-Id: <Pine.BSI.3.95.980220044527.2567A-100000@ns1.syix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6e7ea2cc5dbdeb4412f2537cdb6da38f

On Fri, 20 Feb 1998 sothoth@usa.net wrote:

>I used Adobe Photoshop 4.0
>AFAIK, PNG doesn't compress. JPEG does so, very much so, even.

PNG does compress, and very well I might add.  But, what JPEG does is not
compression IMO, it simply leaves out much of the picture.  This is not to
big a deal for true colour pictures unless you leave out too much (or have
a good eye for detail, I can easly tell a JPEG from a PNG just by looking
at them).  But, because PNG doesn't destroy the picture in the process the
resulting file is larger.  Try saving a JPEG with no loss and see how big
the file is :-)

But, perhaps JPEG should be in the Blorb standard.

Patrick
---
A Title For This Page  --  http://www.syix.com/patrick/
Bow Wow Wow Fan Page   --  http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page  --  http://smallwonder.simplenet.com/
My Arcade Page         --  http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry

From ???@??? Sun Feb 22 06:24:58 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Sat, 21 Feb 1998 14:08:07 +0000
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: "Gunther Schmidl" <sothoth@usa.net>
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Cc: z-machine@gmd.de
Message-Id: <E0y6Fb6-0007Bx-00@oak1.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a6e7eaee05b966b06c2361552b0efb26

>PNG is a standard Huffman compression;

Correct me if I'm wrong, but I thought that PNG used a similar algorithm
to gzip (in the same way as GIF used a similar algorithm to compress),
and not Huffman. Huffman is used in the backend to compress the tables
however, if this is true.

I believe also this is why PNG produces smaller files than GIF (gzip
claims better compression than compress).

Either Huffman or gzip-style compression would produce the poor compression
behaviour noted for images with many colours. To compress well, they require
many long identical runs close together in the data.

Huffman is rarely used for compression nowadays (except as a backend to
another algorithm) as on typical data it compresses less well than the
alternatives.

Martin

From ???@??? Sun Feb 22 07:00:05 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802211832.NAA10168@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Andrew Plotkin <erkyrath@netcom.com>
Date: Sat, 21 Feb 1998 13:38:41 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Amiga Mode (once again)
Reply-To: Jason C Penney <jpenney@chelmsford.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
References: <013c01bd3e53$23519a00$0d054e8c@async.edvz.uni-linz.ac.at>
In-Reply-To: <Pine.SUN.3.95.980221095819.27756E-100000@netcom7>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b2d6d5c4f8b3ccada252a92ec6ff29c6

Andrew Plotkin wrote:
> > >I wouldn't even mind if they could look a little better but didn't try.


On Fri, 20 Feb 1998, Gunther Schmidl wrote:
> > I admit I don't understand.


Andrew Plotkin sent a message across the ether on 21 Feb 98 (10:01)
stating:

> I just mean: if V6lib doesn't work right on Infocom's Amiga interpreter,
> and JCP doesn't want to put in the work to make it do so, that's really
> not a big deal.

V6Lib will work just fine for the Amiga interpreter.  But if you make 
certain calls to it, and you are expecting Dos behavior, your GAME will 
look wrong on the Amiga interpreter.  That said, if you wrote a game 
with V6Lib expecting Amiga behavior, it would look the same in Dos, but 
the restrictions you just imposed on  yourself are nuts IMO.

What I don't feel like putting the effort into this for is the GAME I'm 
writing with V6Lib.  At some point I may go add in all sorts of special 
case code for Amiga mode, but it would hold up the development of 
everything else, so it's not a priority.

> Now, if we ignore that one display mode -- with its two-color limit,
> etc -- can we write to the Z-Spec and not worry about machine numbers any
> more? Or are there further problems?

More or less, everything becomes peachy.  When I asked Stefan Jokisch 
what else would be nice to have, we came up with the following four 
points  (if I'm wrong, and I'm misrepresenting you Stefan, please point 
it out and beat me over the head or something):

[NOTE:  These would require a new ZSpec revision so games could check 
against the ZSpec revision before expecting these features]

[NOTE2:  These features actually have little to do with V6 and should 
probably all exist in V4+, if taken into the spec]


*	Bit 6 of 'flags 1' is undefined in V4+
	Define it to be a 'Full font style combination support?' flag. 

*	add a bit to 'flags 2'.  If the game wants to use music it should set 
	this bit, the interpreter should clear it if it can't play music.


The following would also be nice, but require a bit more work...

*	extend @sound_effect:

		@sound_effect n 3 with n > 0
		...stops sound_effect #n only

		@sound_effect 0 3
		...stops all sound effects 

	This would allow multiple sound effects (if the interpreter supports 
	this there would need to be a way to signal the this as well)

*	Add a separate opcode for music (@sound_music?), which is the same, or 
	very similar to @sound_effect, but allows the music system of the 
	interpreter to work independently of the sound effect system.  
	(interpreters need only support this opcode if they set the 'can play 
	music flag', otherwise they should just treat it as a nop or something, 
	I think.)  

	And again if the interpreter can mix two music streams there need be 
	away to signal this.

Hows that?
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Sun Feb 22 11:33:18 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 21 Feb 1998 18:52:48 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] print_to_array and @:o (fwd)
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <v01540b00b0f908cc73e0@[130.60.44.174]>
Message-Id: <Marcel-1.26-0221185248-354M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 591135e4374342a8238df7fa55ac45bb


Dear all:

  I think, looking at Toni's problem and then at the Z-machine
standards document, that he may be running into an interpreter
bug.  Could interpreter-writers check?

  The key clause is 7.5.3, which asserts that when characters
are printed to memory (via output stream 3, that is), they should
be converted into ZSCII or else left as a question mark if that's
impossible.

  Toni's problem is that o-umlaut is being converted to a question
mark -- probably because the interpreter is not properly using the
table of ZSCII character values to convert back.

     Graham

---------- Forwarded message ----------
Date: Sat, 31 JAN 1998 20:35:17 +0100
From: Toni Arnold <tarnold@cl.unizh.ch>
To: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: print_to_array and @:o

Dear Graham

I have now found the routine (no, "message") that I absolutely needed to
continue my german translation: print_to_array()
The declination has been improved and adjectives have been added.
There is one little problem that is not very important for the translation
because suffixes never contain "Umlaute": print_to_array() does not handle
@:o - characters. If I want to print out the result char by char the
special character becomes a '?'.
For some special german morphological phenomena that have not been
implemented yet I think I will need it. Or I need access to strings stored
in an array char by char in another manner.

   Toni





From ???@??? Mon Feb 23 19:41:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <008a01bd3fa9$19a4de20$d3054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: Re: [z-machine] Amiga Mode (once again)
Date: Sun, 22 Feb 1998 16:25:33 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: fe960beaa63221caa081e3c776a6c2cb

>> Now, if we ignore that one display mode -- with its two-color limit,
>> etc -- can we write to the Z-Spec and not worry about machine numbers any
>> more? Or are there further problems?

[Proposal by Jason and Stefan snipped]

>Hows that?
>Jay

Ah, you see? There *are* interpreter writers that really WANT to support all
of the stuff we're asking here, and much more :-)

Thanks a lot, Stefan, for all your support on this. I know we couldn't make
it without you and all the other interpreter writers out there.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+


From ???@??? Mon Feb 23 19:41:32 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <008801bd3fa9$174a2540$d3054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: <z-machine@gmd.de>
Subject: Re: [z-machine] [BLORB] PNG and file sizes
Date: Sun, 22 Feb 1998 16:20:32 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5592320c005f8bb2efad6a5c1f00f60a

Magnus:


>I don't think you *can* turn off PNG compression in PaintShop Pro (which
Gunther
>was using to produce his PNG files). My experience with PNG is that the
compression


No, *I* was using Adobe Photoshop.

>About the "politics" of Blorb: I agree that it's important to get
>Blorb-compliant interpreters up and running ASAP, so people can start
>writing games with graphics - there seems to be a great dealof pent-up
>interest. If this means going for PNG-only initially, then I think JPEG
>could wait.


Definitely. But not too long.

>However, I think that since people will probably want to make games where
>the graphics are based on photos,

You're speaking my soul :-)

>and where the images will make huge
>PNG files but will stand some "abuse" by lossy compression algorithms,
>there will be a demand for JPEG support in Blorb.

Good to see someone understands :-)

>If I understand things correctly, adding JPEG support to the Blorb
>format is simple. The problem is how difficult it would be for the
>interpreter writers to implement it. But there are standard image
>conversion libraries available for free, and hopefully code from those
>libraries could be used.


There are, as somebody pointed out, libraries available for both PNG and JPG
that are not much more than "Plug & Play". However, we all know what "Plug &
Play" means in the Windows world... plug & pray. :-(
+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+



From ???@??? Mon Feb 23 19:41:41 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199802221603.LAA20228@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Sun, 22 Feb 1998 11:10:21 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Amiga Mode (once again)
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <008a01bd3fa9$19a4de20$d3054e8c@async.edvz.uni-linz.ac.at>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3e25c3170cb6c2b027f18fc30d9ed5b3

Gunther Schmidl sent a message across the ether on 22 Feb 98 (16:25) 
stating:

> Ah, you see? There *are* interpreter writers that really WANT to support all
> of the stuff we're asking here, and much more :-)
> 
> Thanks a lot, Stefan, for all your support on this. I know we couldn't make
> it without you and all the other interpreter writers out there.

I would like to point out (before things get out of hand, or someone 
gets mad at me) that just because I said Stefan supported the ideas, he 
never said any of this would be implemented soon.  (I actually have zero 
idea of the time frame, but I'm just covering my butt. :-O )

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Tue Feb 24 17:33:26 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: s.jokisch@avu.de (Stefan Jokisch)
To: <z-machine@gmd.de>
Subject: Re: [z-machine] print_to_array and @:o (fwd)
Date: Mon, 23 Feb 1998 20:10:08 +0100
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19980223190048.AAA20118@jokisch>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c5145006f9d4165dfb9fd86f16316298


>   I think, looking at Toni's problem and then at the Z-machine
> standards document, that he may be running into an interpreter
> bug.  Could interpreter-writers check?
> 
>   The key clause is 7.5.3, which asserts that when characters
> are printed to memory (via output stream 3, that is), they should
> be converted into ZSCII or else left as a question mark if that's
> impossible.
> 
>   Toni's problem is that o-umlaut is being converted to a question
> mark -- probably because the interpreter is not properly using the
> table of ZSCII character values to convert back.
> 
>      Graham

What interpreter did Toni use?  My Frotz source code looks
correct.

-- Stefan

From ???@??? Fri Mar 13 18:29:40 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@newsguy.com (David Turnbull)
To: z-machine@gmd.de
Subject: [z-machine] Font needed for Frotz port to PalmPilot
Date: Fri, 06 Mar 1998 20:29:54 GMT
Message-Id: <350256a3.4512260@smtp.newsguy.com>
References: <34d7a1f1.24564793@snake.ae.usr.com>
In-Reply-To: <34d7a1f1.24564793@snake.ae.usr.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9a0f50ea3d7c4666923907d3422728c0

I'm well into porting Frotz.  It may not sound like much, but I have
games loading, deleting, initializing memory, menus, and so on.  This
weekend I hope to get the CPU running and some crude output generated.

While lying awake one night, I came up with a brilliant way to make
the PalmOS memory manager compatible with the macro system used by
Frotz.  I'm very excited about this since it will improve performance
300% over my previous idea, uses less code/memory, and still not cause
any problems in a system with bad memory fragmentation.

One of my main goals is to provide the nicest display possible.  As
you may already know I'm using a sliding top window, but I could use
some help.

Loading additional fonts into the Pilot isn't easy.  There are no font
editors and the only utility to make fonts turns mac NFNT types into
pilot fonts.  I have no mac, and I refuse to compute on fruit.

I've considered simply using a bitmap and copying sections to the
screen, but this isn't supported and I'd have to make a seperate
resource for each character (slow, big, and ugly).  So it's easiest to
hack in some fonts, at least for now.

I've already spent many hours figuring out the method for storing
fonts and even have written a very able utility for translating them
into ASCII files I could edit.  I just have to write the part now that
turns the ASCII back into a font resource (easy).

I have found a pretty decent font that would allow me to display 32
colums of text!!!  It's not compatible with the graphics font, so I'd
have to switch back to 20 columns if graphics or extended characters
were ever selected during a game (easy).

Now the hard part...  I really don't feel like designing an 8x8 font
from scratch.  Does anyone have one that includes extended characters
and I could distribute for free?

-david

From ???@??? Fri Mar 13 18:43:38 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@newsguy.com (David Turnbull)
To: z-machine@gmd.de, s.jokisch@avu.de, 104312.2206@compuserve.com
Subject: [z-machine] CPU is running, now a question
Date: Mon, 09 Mar 1998 20:14:49 GMT
Message-Id: <35043dd0.5396001@smtp.newsguy.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: db10bc3e1a7ec9c6bb89616d8217fae0

OK, I didn't leave the house all weekend and made a lot of progress
with the Pilot conversion of Frotz.  Things are looking up and I'm
almost happy with the quality of it's current state.

I have the CPU running!!!  The following modules have been converted
and tested somewhat: process, variable, object, table, math, random.
In addition, main and fastmem have been completely rewritten.

Unfortunately, this is turning out to be more than just a simple port.
Not exactly a rewrite, but every routine needs to be adjusted slightly
to use the PalmOS memory management and a try/catch error handler.
All this really means is that I can't just plug in a new module when
Stefan updates it, I'll have to diff it and manually incoprporate the
changes.  (Remember, I don't have _ANY_ standard C libraries to work
with and memory management is something of a chore.)

When converting z_random I noticed that Frotz was doing something not
documented in the standards.  If the seed value was less than 1000 (or
greater than -1000, depending how you look at it) a test mode was
entered where you could generate every posibility sequentially.

Now, I've taken all the debug options out of Frotz and I want to take
this out as well.  Passing a 0 will seed with the real-time clock, but
otherwise I followed what the z-standards indicated (I think).

The question is, "Did I need to leave in this special seed mode?"

(Don't worry, the debug options I took out were for degugging z-code,
not my program.  Things like watching object movement and such.  But,
all the run-time error checking WAS left in working order.)

I have not got anything from the z-machine list since 23 Feb.  Proir
to that I got something almost every day for almost two months.  If 
anyone posted anything and I didn't respond, this is why.  If you are
going to reply to this, can you send it direct to me _and_ the list so
I can make sure my email provider didn't fudge things up with their
stupid SPAM filters.

Bryan might have remembered when I said:

>P.S. You mentioned a 128K pilot.  The least amount of memory it ever
>came with was 256K.  But you got me talking about the 128K pilot
>anyway.  Imagine a 128K pilot minus the 64K consumed for stack/heap
>usage!!!

Well, there indeed was a 128K pilot.  I was wrong and I admit it.
I've never seen one, but I found out it has a 32K dynamic heap.
Needless to say it isn't really suited for loading applications.
However, I heard the new pilot (V3) will have 2MB of RAM standard.

I heard on TV last night something like... "3Com is releasing a more
powerful Pilot while at the same time Apple is discontinuing their
like of Newton based products."  HaHaHa!  And some people wonder why I
refuse to compute on fruit.

-david

P.S. Stefan, thanks for some really easy to follow code!  The font you
used in CGA mode looks like what I need for the Pilot.  Would I be
able to use this?

From ???@??? Fri Mar 13 18:43:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199803092144.QAA00836@email.nist.gov>
From: "Michael Baum" <michael.baum@nist.gov>
To: "Z-Machine List" <z-machine@gmd.de>
Date: Mon, 09 Mar 1998 16:48:09 -0500
Reply-To: "Michael Baum" <michael.baum@nist.gov>
Priority: Normal
X-Mailer: PMMail 98 Professional (2.00.1500) For Windows NT (4.0.1381;3)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [z-machine] Common Save-File Exchange Format
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0e13a23c2f68bd694471aae4ac01372a

I tentatively fold this message, airfoil creases gently angl'd, and
defenestrate it in the direction of the list because I am but lately
come to it and I'm not sure if this is an FAQ.

Such is the pace of technology that I find myself often with older
Sav'd Games -- Games I've never quite finished -- and no idea what
wretched interpreter was in use when I last played. Naturally, almost
all of the current-or-nearly-so very excellent z-machine interpreters
seem to save games in incompatible formats.

Of course we now have the ummm <tugs at beard, oh yes ...> Quetzal
format or something like that which is supposed to be
interpreter-independent, as I understand it. This is nifty, but doesn't
solve the archive problem.

Now out where I live we once had a similar issue involving the swapping
of large, complex data files that defined the dimensions, materials,
tolerances, dependancies and such of complicated manufactured objects:
CAD files. Of course everyone and their _dawg_ had a CAD system, and
none with compatible file formats. The solution turned out to be to
establish a standard, generic CAD file format that captured all the
information you could possibly want. Instead of trying to write
translation routines from every CAD system to every other CAD system,
an Exponential Horror, every CAD system house just wrote one translator
into and out of the generic format. You could then use the generic as a
sort of _lingua franca_, if that's the phrase I want, stepping stone to
get from any format to any other.

Well, to get to the point, would it be a terrible lot of work to build
similar translators for the commonly used z-machine interpreters into
and out of Quetzal files -- it _is_ Quetzal_, isn't it? Are the save
files so very different from interpreter to interpreter? I haven't
looked at this and I had this sort of naive impression that the
original story file defined the extent of the changeable portion of the
Z-machine memory map, and that saving a story largely meant simply
saving that memory image? Probably not that easy.

Michael Who Is Almost Certain He Once Saw An Old C Manual Around Here
Somewhere Baum
dba michael.baum@nist.gov

From ???@??? Fri Mar 13 18:44:16 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@newsguy.com (David Turnbull)
To: "Z-Machine List" <z-machine@gmd.de>
Subject: Re: [z-machine] Common Save-File Exchange Format
Date: Mon, 09 Mar 1998 22:56:11 GMT
Message-Id: <35046edc.17953851@smtp.newsguy.com>
References: <199803092144.QAA00836@email.nist.gov>
In-Reply-To: <199803092144.QAA00836@email.nist.gov>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a6bcdb59861bde60f3a26677f2733d0f

On Mon, 09 Mar 1998 16:48:09 -0500, you wrote:

>Well, to get to the point, would it be a terrible lot of work to build
>similar translators for the commonly used z-machine interpreters into
>and out of Quetzal files -- it _is_ Quetzal_, isn't it? Are the save
>files so very different from interpreter to interpreter? I haven't
>looked at this and I had this sort of naive impression that the
>original story file defined the extent of the changeable portion of the
>Z-machine memory map, and that saving a story largely meant simply
>saving that memory image? Probably not that easy.

Actually, there are very few things involved in a saved game.  It
would be pretty easy to build a converter, but... you would need the
original game for some conversions.

>Michael Who Is Almost Certain He Once Saw An Old C Manual Around Here
>Somewhere Baum
>dba michael.baum@nist.gov

I think this project could be handled by all but the most novice of
programmers.  Go for it.

However, it is my opinion that there isn't much need for this type of
program.  If you can't remember what interpreter you used, it's very
likely you don't remember how you got to your current position.  If
you don't remember the game, certainly it would be fun to replay the
parts you forgot.  Even if you do remember the game, with a map it
should only take a minimal amount of time to get back to your current
position.

Ten-or-twelve years ago I might have thought differently.  But in
those days I couldn't type very fast and you had to wait for the
computer to think about your input and access the floppy drive.

I guess what I'm saying is that not everyone is going to think this
converter would be as useful as you do.  If you want one you are
probably going to have to write it yourself.

-david

P.S.  It is my intention to have the saves from my PalmPilot port be
Quetzal compatible.  You'll be able to HotSync them in and out.

From ???@??? Fri Mar 13 18:44:22 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 9 Mar 1998 18:53:01 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199803092353.SAA21945@pond.com>
To: z-machine@gmd.de
Subject: Re:  [z-machine] Common Save-File Exchange Format
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: af293b9382f5e6649857fda2394c0f12

} Well, to get to the point, would it be a terrible lot of work to build
} similar translators for the commonly used z-machine interpreters into
} and out of Quetzal files -- it _is_ Quetzal_, isn't it? Are the save
} files so very different from interpreter to interpreter? I haven't
} looked at this and I had this sort of naive impression that the
} original story file defined the extent of the changeable portion of the
} Z-machine memory map, and that saving a story largely meant simply
} saving that memory image? Probably not that easy.

A lot of work?  Yes, but mostly because it's a royal pain in the neck.
The memory images can be copied straight out in most cases, and the
z-machine stack can be translated.  BUT, to translate the stack you need some
information (number of parameters per call, IIRC) not readily available in many
interpreters, though it can be reconstructed with TXD or a similar
tool.

From ???@??? Fri Mar 13 18:46:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Tue, 10 Mar 1998 12:13:24 +0000
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: "Michael Baum" <michael.baum@nist.gov>
Subject: Re: [z-machine] Common Save-File Exchange Format
Cc: z-machine@gmd.de
Message-Id: <E0yCNuP-0005Vi-00@oak62.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 848c66a5ef9fcfc53978ff82be64f8c9

>Well, to get to the point, would it be a terrible lot of work to build
>similar translators for the commonly used z-machine interpreters into
>and out of Quetzal files -- it _is_ Quetzal_, isn't it? Are the save
>files so very different from interpreter to interpreter? I haven't
>looked at this and I had this sort of naive impression that the
>original story file defined the extent of the changeable portion of the
>Z-machine memory map, and that saving a story largely meant simply
>saving that memory image? Probably not that easy.

It is possible up to a point. Some of the main differences between save
formats are hinted at in the Quetzal spec.

If you look at the modifications I had to make to Zip and Frotz to enable
Quetzal saving, you'll get the general idea. It would be necessary to have
the converter as an interpreter in many cases, such that the stack format
could be modified, as well as the format of catch/throw cookies.

I think it's really more trouble than it's worth...

I can dig out the posts from this list dealing with this if you're interested.

Martin

From ???@??? Fri Mar 13 18:51:23 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@newsguy.com (David Turnbull)
To: z-machine@gmd.de
Subject: [z-machine] Someone, please help me.
Date: Wed, 11 Mar 1998 17:04:38 GMT
Message-Id: <3506c119.170102457@smtp.newsguy.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3bf578ca0a2814da37f43dd007874415

I have two questions so far...

1.  I took out the test mode from the z_random.  Seeding with 0 uses
the real-time clock for a seed.  Seeding with any other number does a
normal seed.  Before 0>seed>1000 would put the generator in a test
mode, but I wanted to remove all debugging features.  Is this OK?

2.  The double angle quotation marks are reversed in either the
standards or Frotz.  I'm not sure which is correct.  Which is it?

BTW, I have it generating text output now!  So far, no sacrifices have
been made except for testing/debugging and V6 features.

-david

From ???@??? Fri Mar 13 18:51:46 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 11 Mar 1998 10:20:17 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom12
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Someone, please help me.
In-Reply-To: <3506c119.170102457@smtp.newsguy.com>
Message-Id: <Pine.SUN.3.95.980311101140.23534E-100000@netcom12>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e79fda69cffbb5a46e2249cae1f99737

On Wed, 11 Mar 1998, David Turnbull wrote:

> 1.  I took out the test mode from the z_random.  Seeding with 0 uses
> the real-time clock for a seed.  Seeding with any other number does a
> normal seed.  Before 0>seed>1000 would put the generator in a test
> mode, but I wanted to remove all debugging features.  Is this OK?

The magic spec says: if the argument to @random is positive, return a
random number; if negative, seed the RNG; if zero, seed to the clock (or
other better-than-pseudo-random seed source.) (I assume the "test mode" 
was triggered by arguments -1 to -1000, not 1 to 1000?) 

> 2.  The double angle quotation marks are reversed in either the
> standards or Frotz.  I'm not sure which is correct.  Which is it?

The current standard is correct. 162 is >>, 163 is <<, and don't let
anyone tell you different. :)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Fri Mar 13 18:52:08 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: mdf@doc.ic.ac.uk (Martin Frost)
Date: Wed, 11 Mar 1998 20:06:00 +0000
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: z-machine@gmd.de
Subject: [z-machine] (Another) bug in Zip Quetzal patches...
Cc: mdf@doc.ic.ac.uk
Message-Id: <E0yCrlI-0000i8-00@oak69.doc.ic.ac.uk>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d1941209cfb8f48bf16ae8c8a3fd2778

Yet another bug has been discovered in the Zip Quetzal patches. This one
manifests itself as a crash or hang when doing the sequence save,restore,
save on a V3 Infocom game. This may be why the bug wasn't noticed till now.

Anyway, the bug is easy to fix. Simply apply the following diff to your
quetzal.c file, and all will be well.

I will check tonight whether this bug affects the Frotz patches. Out of
interest, is anyone using the Frotz patches yet?

Martin

PS. For those who are interested, there will shortly be a major overhaul
of the Quetzal web pages to tidy them up and remove some of the inaccuracies.
They will also be moving to a new location, probably in June-ish.

-----8<----- CUT HERE -----8<-----

*** bug-quetzal.c       Wed Mar 11 01:14:40 1998
--- quetzal.c   Wed Mar 11 01:16:46 1998
***************
*** 170,179 ****
          if (!write_byte (sfp, var))                   return FALSE;
          if (!write_byte (sfp, args))                  return FALSE;
          if (!write_word (sfp, nstk))                  return FALSE;
!         for (j=0, ++tmp_fp; j<nvars; ++j)
!             if (!write_word (sfp, stack[--tmp_fp]))   return FALSE;
!         for (j=0; j<nstk; ++j)
!             if (!write_word (sfp, stack[--tmp_fp]))   return FALSE;
          stkslen += 8 + 2 * (nvars + nstk);
        }
  
--- 169,176 ----
          if (!write_byte (sfp, var))                   return FALSE;
          if (!write_byte (sfp, args))                  return FALSE;
          if (!write_word (sfp, nstk))                  return FALSE;
!       for (j=0; j<nvars+nstk; ++j, --tmp_fp)
!           if (!write_word (sfp, stack[tmp_fp]))       return FALSE;
          stkslen += 8 + 2 * (nvars + nstk);
        }
  
***************
*** 336,342 ****
                          if (!read_word (sfp, stack+(--sp)))   return FALSE;
                      currlen -= tmpw*2;
                    }
!                 for (fp=sp-1, frame_count=0; currlen > 0; currlen-=8)
                      {
                      if (currlen < 8)                          return FALSE;
                      if (sp<4)
--- 333,339 ----
                          if (!read_word (sfp, stack+(--sp)))   return FALSE;
                      currlen -= tmpw*2;
                    }
!                 for (fp=STACK_SIZE-1, frame_count=0; currlen > 0; currlen-=8)
                      {
                      if (currlen < 8)                          return FALSE;
                      if (sp<4)

From ???@??? Sun Mar 15 11:54:50 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <000101bd4f76$fa9d7400$09054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: [z-machine] [Blorb] Interpreters?
Date: Sat, 14 Mar 1998 19:13:24 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0815126b92a02cc87abf7f9a54a605f3

Excusez moi for bringing this up again, but I need to know - is ANYBODY
working on a Blorb-compliant Interpreter, or can I just go and scrap all my
V6 stuff and pictures and rely on good(?) old Z8 :-( ?

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+


From ???@??? Tue Mar 17 15:15:28 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980315221356.62308@nowhere.xmission.com>
Date: Sun, 15 Mar 1998 22:13:56 -0700
From: Matt Kimball <mkimball@xmission.com>
To: z-machine@gmd.de
Subject: [z-machine] [Announce] zasm v0.1 released
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e8b4aaf5f6961df8861f05d8f00acf7e

I have just released version 0.1 of zasm, a Perl script implementing
an assembler for the Z-Machine.  It should be considered alpha quality
software.  Nevertheless, comments and code contributions are
solicited.  The following is from the zasm home page:

What is zasm?

zasm is an assembler for the Z-Machine. Since it is implemented in
Perl, it should be fairly portable to the various machines which have
Perl interpreters available.

zasm takes as input a single file with a sequence of Z-Machine
instructions, and it assembles these into a file named out.z5.
Currently zasm only supports version 5 of the Z-Machine.

zasm is distributed under the GNU General Public License. 


Why zasm?

Although Graham Nelson's Inform is an excellent tool for generating
Z-Machine story files, it is limited in some ways.  In particular, it
is a bit awkward to use when writing programs which allocate and
deallocate memory at run time.  In an effort to support this style of
programming, zasm reserves a large portion of address space for
dynamic allocation.


Is zasm for me?

If you are interested primarily in producing Infocom style story
files, Inform is the more appropriate tool.  On the other hand, if you
are interested in hacking on the Z-Machine or in writing tools which
compile new languages to the Z-Machine then zasm may meet your needs.


Where can I get more information?

http://www.mkimball.org/zasm.html

-- 
Matt Kimball
mkimball@xmission.com

From ???@??? Sun Mar 22 20:45:58 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 20 Mar 1998 19:23:03 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Re: print_to_array and @:a (fwd)
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <v01540b05b11b58821626@[130.60.44.162]>
Message-Id: <Marcel-1.26-0320192303-bc8M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: eee95d8fe3949c0e14e75f1e589f0983


I am inexcusably late in passing this message around -- it's for
interpreter-writers, anyway.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom
---------- Forwarded message ----------
Date: Thu, 26 FEB 1998 19:17:28 +0100
From: Toni Arnold <tarnold@cl.unizh.ch>
To: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: print_to_array and @:a

Dear Graham

I have tested all Z-Code Interpreters I could use; I would like to send it
to the Z-code-mailing list too, but where is it?

Toni


The results:

-------------------------------------------
ZIP test results for German Umlaute
by Toni Arnold
tarnold@cl.unizh.ch

Windows versions tested on Windows NT 4.0
Mac versions tested on Mac 68k & OS 7.1
All versions got from ftp.gmd.de

Feb. 26, 1998
-------------------------------------------


Inform 6.14 created umlaut.z5 and rummel.z5
alway on Win NT 4.0


Three things were tested:

(1) Umlaute from print "@:A";
(2) Umlaute from print (char) (array -> x);
    the array was created by obj.print_to_array(array);
(3) What happens if an Umlaut is typed on
    a game's command line?
    Normally ZIP behaves nearly like if <Return>
    was typed. That means the input is interpreted,
    but the output is printed on the same line.

    No interpreter could interpret an Umlaut. I
    would like to suggest to at least translate
    it to ae; so it would be recognized on
    all keyboards.



The testing order of the versions is randomly
selected and means nothing. I hope I have
not made too many errors.




-----------------
MS WINDOWS NT 4.0
-----------------



----------------------------------------
WZIP Version 2.1 -- May 18, 1996

Based on Mark Howell's ZIP interpreter
Windows port by Ron Murray
nmurrayr@cc.curtin.edu.au

(1) prints a square             :-(
(2) prints a ?                  :-(
(3) nearly like <Return>        :-(
----------------------------------------


----------------------------------------
WInfocom version Beta 1.0

Aug. 7, 1994 by Ido Razon

(1) can be customized:
    either translates to ae     ;-|
    or prints a square          :-(
(2) either translates to ae     ;-|
    or prints a >               :-(
(3) nearly like <Return>        :-(
-----------------------------------------


-----------------------------------------
ZIP 2.0

by Mark Howell, for DOS
howell_ma@movies.enet.dec.com

(I love that interpreter because
 of its simplicity)

(1) prints Umlaut correctly     :-)
(2) prints a ?                  :-(
(3) nearly like <Return>        :-(
-----------------------------------------


-----------------------------------------
Jzip 2.0.1g -- Nov.22, 1995

by John Holder
jholder@nmsu.edu

(1) prints Umlaut correctly     :-)
(2) prints a ?                  :-(
(3) lower case ignored, upper
    case nearly like <Ret>      ;-(
-----------------------------------------


-----------------------------------------
WinFrotz 2.32 R5.0

Win code by Ritch Lawrence, 1997
Frotz by Stefan Jokisch, 1995-1997

rich@kesmai.com

(1) prints Umlaut correctly     :-)
(2) prints Umlaut correctly     :-)
(3) prints and recognizes
    always a ?                  ;-(
-----------------------------------------




----------------------
Macintosh 68k & OS 7.1
----------------------



-----------------------------------------
ZIP Infinity Version 1.3 and 1.4b1
by Matthew T. Russotto

russotto@pond.com

(1) prints Umlaut correctly     :-)
(2) prints a ?                  :-(
(3) prints Umlaut correctly,
    but doesn't recognize       ;-|
-----------------------------------------


-----------------------------------------
MaxZip Version 1.7.4
by Andrew Plotkin
erkyrath@netcom.com

(1) prints Umlaut correctly     :-)
(2) prints a ?                  :-(
(3) ignores Umlaut              ;-(
-----------------------------------------


-----------------------------------------
MaxZeX Version 1.1
by Greg Ewing
greg@cosc.canterbury.ac.nz

(1) translates Umlaut to ae     ;-|
(2) translates Umlaut to ae     ;-|
(3) ignores Umlaut              ;-(
-----------------------------------------



---------------------------------
Appendix: The test routines used
---------------------------------


Test routine for output
-----------------------

Array ar -> 100;
Array te -> 60;

[ta_PrintArrayBuf a i;
  for (i=1: i <= a-->0 : i++)
   print (char) (a -> (i+1));
];

[Main a;
  a = "Was macht ~@:a~?";
  a.print_to_array(ar);
  ta_printArrayBuf(ar);
  print "^@:Ah...";
  te -> 0 = 60;
  read te 0;
];



Test verb for input
-------------------

[TryUmlSub;
  print "~@:ah~ erkannt!^";
];

verb "@:ah" "aeh" "?h"
      *         -> TryUml;




------------------------------------
  e-mail to:  tarnold@cl.unizh.ch
------------------------------------





From ???@??? Sun Mar 22 20:47:10 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <000601bd54f1$d1aa6aa0$3b8a4ac2@jokisch>
From: s.jokisch@avu.de (Stefan Jokisch)
To: "Z-machine" <z-machine@gmd.de>, <tarnold@cl.unizh.ch>
Subject: Re: [z-machine] Re: print_to_array and @:a (fwd)
Date: Sat, 21 Mar 1998 15:03:08 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: eee4f344e88062b40923f011a26db0df


>I have tested all Z-Code Interpreters I could use...


No, you haven't: DOS Frotz gets it right.  I'll ask Rich Lawrence to fix
his WinFrotz input routine.


-- Stefan


From ???@??? Wed Apr 08 18:06:11 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199803230333.WAA18718@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Sun, 22 Mar 1998 22:40:32 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] [BLORB] Sound files compiled
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 7475da78600e41a06d38e217c9fccf3a

Hi,

I've finally managed to complete the set of Infocom Blorb files at:
<http://www.chelmsford.com/home/jpenney/V6Lib/blorb>

Special thanks to Gene Jones for converting sound #17 from The 
Lurking Horror (which gave me no end of trouble).

I've just uploaded the files for Sherlock and The Lurking Horror.  
Now if only I could test them out (hint hint).  :)

Since they are compiled from files that are already on GMD, would it 
be ok to upload them?  The six of them take up a bit of space (and I 
don't have very much web space).

Later,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Wed Apr 08 18:07:17 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 23 Mar 1998 12:07:15 -0500 (EST)
From: Jesse Burneko <burnekoj@ultra27.cs.lafayette.edu>
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: [z-machine] Infocom Graphics Format...
Message-Id: <Pine.SOL.3.93.980323120343.27684A-100000@ultra27.cs.lafayette.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 88d495197d144e52fa35ebc55dc83570

Hello,

I know that there has been a lot of playing around with the new Blorb
format but I was just curious about the original Infocom method.

I know that the sound file format is well documented.  I've read the
specifications and understand it pretty well.

However, I have been unable to find ANY information on the file format
that Infocom used for graphics.  Does any documentation on this exist?  If
so where can I get it?

Thanks,

Jesse

"It's the honors house!  Who buries bodies by the honors house?"
                                               -Marina Kiriyeva-

"Yes, but after working for five weeks you had a cute electronic device that
played a cool little computer game where as after working for five weeks
we had a pile of paper that didn't mean anything."
					       -Kevin Johnson-

"It's this whole big eternity thing and I'm at the wrong end of it."
					       -Mike Ruete-

From ???@??? Wed Apr 08 18:08:20 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 24 Mar 1998 10:40:18 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] First Blorb-compliant interpreter!
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <35167A45.4367@is.ien.it>
Message-Id: <Marcel-1.26-0324104018-06cM+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.26]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5666cccc227b1f2a9fac649d2e223f26


As the email message below shows, somebody has persuaded Frotz
to accept Blorb sound files.  In the smallest possible way,
perhaps, Blorb is now a real live format!

We should try to avoid duplicating effort here, so I'll put
Aldo Cumani and Stefan in touch with each other.

    Graham

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom
---------- Forwarded message ----------
Date: Mon, 23 MAR 1998 16:05:41 +0100
From: cumani@is.ien.it
To: graham@gnelson.demon.co.uk
Subject: SPY1.BLB - bug report

Dear Graham,

Let me present myself: I'm a grey-haired researcher with some competence
in computer vison, and an IF addict of relatively recent date. I wish to
congratulate with you for your really nice works (I mean Inform and
your games).

And now, the specific reason of my writing. I think you'll be pleased to
hear that someone (myself) has downloaded and tested the first publicly
known example of Blorb file, i.e. the SPY1.BLB appearing in your Blorb
page, although I'm actually writing to signal a bug... :)

I've tested it both with DOS Frotz 2.32, after extracting and converting
the sound files to Infocom format, and with a Blorb-aware version of
Frotz
I've put together and named BLOTZ (guess why). The original Frotz runs
the
game, but endlessly repeats the last sound effect (which IMHO is NOT the
intended beahaviour), while BLOTZ crashes with an "illegal routine
address"
error.

The problem seems to be with the arguments of the sound_effect opcode,
that appears at offset B6C1 hex in the Z-code, B77A hex in the .blb
file:

 00B770   01 2D 01 01  8B FF FF 00  01 F5 95 01  02 FF 01 B2
                                       ^^^^^^^^^^^^^^^^^^
which, according to Mark Howell's TXD, means something like

       f5 95 01 02 ff 01       sound_effect    local0 #02 #ff 4

that is, "start effect number <local0> with volume 255, repeats 0,
end_of_sound interrupt to address 4" - but there is no routine at
address 4! (BTW, TXD also reports a "call to nonexistent address").
Frotz does not crash only because it interprets (IMHO incorrectly)
"0 repeats" as "infinite repeats", and the end_of_sound routine is not
called if the sound does not end by itself...

I've circumvented the problem by patching the code this way:

 00B770   01 2D 01 01  8B FF FF 00  01 F5 93 01  02 01 FF B2
                                          ^^        ^^ ^^
                                          changed bytes

that is

       f5 93 01 02 01 ff       sound_effect    local0 #02 #01ff

("start effect number <local0> with volume 255, repeats 1, no
interrupt").
With this patch, the game runs OK on DOS Frotz, WinFrotz and BLOTZ.

Let me know if my lucubrations are correct, and accept my apologies for
my bad English (it's not my "mother tongue"... is this correct? :)


                           Aldo Cumani


-- 
Ing. Aldo Cumani <cumani@is.ien.it>
Istituto Elettrotecnico Nazionale
Str. delle Cacce, 91
10135 Torino



From ???@??? Wed Apr 08 18:08:39 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 24 Mar 1998 12:44:21 -0500 (EST)
From: Jesse Burneko <burnekoj@ultra27.cs.lafayette.edu>
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: [z-machine] Re: Infocom Graphics Files
Message-Id: <Pine.SOL.3.93.980324124312.418A-100000@ultra27.cs.lafayette.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 4934f49be739e7d01ab603224c822d2b

Okay, now here's the question: If no documentation exists then how did
programs like pix2gif and frotz come into existence in the first place?
This seems like a serious case of the chicken comming before the egg.

Jesse

"It's the honors house!  Who buries bodies by the honors house?"
                                               -Marina Kiriyeva-

"Yes, but after working for five weeks you had a cute electronic device that
played a cool little computer game where as after working for five weeks
we had a pile of paper that didn't mean anything."
					       -Kevin Johnson-

"It's this whole big eternity thing and I'm at the wrong end of it."
					       -Mike Ruete-

From ???@??? Wed Apr 08 18:13:42 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199803271854.NAA07998@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Fri, 27 Mar 1998 14:01:25 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] V6 Mouse observations
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8ee718465ef8b183abcde71e83d43a60

Hi,

I have made some observations of mouse behavior in V6.  The first is 
that @read_mouse seems only to behave according to the Spec in the 
Dos Infocom interpreters (although without a 16 button mouse I'm not 
100% sure).

The other is this.  The Spec states:

0.3.2

Whenever a mouse click takes place (and provided the header extension
table exists and contains at least 2 words) the interpreter should
update the coordinates as follows: 

   Word 1:  x coordinate where click took place
   Word 2:  y coordinate where click took place

Now, Frotz does this just fine.  Unfortunately, all the Dos Infocom 
interpreters don't seem to do this.  They do the opposite.

   Word 1:  y coordinate where click took place
   Word 2:  x coordinate where click took place

What happens on other systems??  Anyone know?

I'm still fooling around, so there may be more to come.

Later,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor

From ???@??? Wed Apr 08 18:18:26 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 31 Mar 1998 07:56:11 -0500 (EST)
From: Phaedrus <dwildstr@mbhs.edu>
To: The Z-Machine Mailing List <z-machine@gmd.de>
Subject: [z-machine] BeOS interpreter standard number
Message-Id: <Pine.LNX.3.96.980331075400.22372B-100000@binx.mbhs.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: de2ce69c663d74b4be06fa12b78ddde7


Hi! I'm writing a BeOS GUI port of jzip, and am wondering which
interpreter number to include in header byte 1E. I'm thinking of
INTERP_UNIX (12) but would like some verification.

+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into         |
| theorems.              -Paul Erdos                          |
+-------------------------------------------------------------+
|                       David Wildstrom                       |
+-------------------------------------------------------------+

From ???@??? Wed Apr 08 18:18:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@newsguy.com (David Turnbull)
To: z-machine@gmd.de
Subject: [z-machine] International Support
Date: Tue, 31 Mar 1998 21:26:15 GMT
Message-Id: <3521577a.449225490@smtp.newsguy.com>
References: <19980315221356.62308@nowhere.xmission.com>
In-Reply-To: <19980315221356.62308@nowhere.xmission.com>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cb35996772bc8bea82c76f7365ffac3f

Frotz for PalmPilot is coming along very well.  I have the lower
window working perfectly with full international support (all
international characters specified in standards 1.0).

Now, the upper window.  Perhaps the upper window is going to need to
sacrifice full international support.  :(

How do you folks (who use these characters) feel about translating
them down to plain ASCII (<=0x7F)?  Just for the upper window.  Frotz
for DOS does it this way (for the lower window too, I think).

Are there any games that I could test?  Could somebody send me one
along with a small "script" (5-10 moves at least) so I can run through
a few pages of text.  I've been testing successfully with an old V3
games that responds [I don't know the word "xxx"] where xxx must have
been translated to "packed" format and back again correctly.

Is there a need for localized versions of this interpreter?

Does anyone know how to handle international characters in Font 3?
I'm leaning towards printing '?'.

Does anyone know why Frotz handles Beyond Zork specially in text.c?

-david

P.S.  I've added some cool features since I last posted.
P.P.S.  There will be an open beta, I'll post to this list.

From ???@??? Wed Apr 08 18:19:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 1 Apr 1998 09:16:12 -0800 (PST)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom2
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] International Support
In-Reply-To: <3521577a.449225490@smtp.newsguy.com>
Message-Id: <Pine.SUN.3.95.980401091449.13730B-100000@netcom2>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 94bea218c4adb5ee867206e3145fefb9

On Tue, 31 Mar 1998, David Turnbull wrote:

> How do you folks (who use these characters) feel about translating
> them down to plain ASCII (<=0x7F)?  Just for the upper window.  Frotz
> for DOS does it this way (for the lower window too, I think).

Remember that quote boxes appear in the upper window. I know I've seen a
game that uses accented characters in a quote box -- Christminster, maybe.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Apr 08 18:19:41 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@newsguy.com (David Turnbull)
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] International Support
Date: Wed, 01 Apr 1998 21:15:24 GMT
Message-Id: <3522a4e9.534597811@smtp.newsguy.com>
References: <Pine.SUN.3.95.980401091449.13730B-100000@netcom2>
In-Reply-To: <Pine.SUN.3.95.980401091449.13730B-100000@netcom2>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ff465cfdea904efd2b4a486f03dd8da4

On Wed, 1 Apr 1998 09:16:12 -0800 (PST), you wrote:

>On Tue, 31 Mar 1998, David Turnbull wrote:
>
>> How do you folks (who use these characters) feel about translating
>> them down to plain ASCII (<=0x7F)?  Just for the upper window.  Frotz
>> for DOS does it this way (for the lower window too, I think).
>
>Remember that quote boxes appear in the upper window. I know I've seen a
>game that uses accented characters in a quote box -- Christminster, maybe.

Yeah, but, the real issue is how hard it is to read your language with
all the accent characters removed.  I can assume it's tolerable, but
that is only an assumption and I'd like other opinions, especially
from those who can read the languages well.

Ahhh, those quote boxes.  Funny thing is, they won't work on my
implementaion of the Z-machine.  Since I'm using a "virtual" upper
window, so as to not limit the width of the screen, I couldn't come up
with a resonable way to make these work (and I did try).

Besides, this method of doing quotes really is abusing the Z-machine.
You should be able to do anything to my upper window that you can do
on Frotz for DOS, just don't expect the user to see anything below the
split.

-david

From ???@??? Wed Apr 08 18:23:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Sat, 04 Apr 1998 12:27:33 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] BeOS interpreter standard number
Message-Id: <d73c7b3148%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <Pine.LNX.3.96.980331075400.22372B-100000@binx.mbhs.edu>
Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.34c for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60g
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cdce5c1eae44ec119344ef4ab1e54668

In message <Pine.LNX.3.96.980331075400.22372B-100000@binx.mbhs.edu>
          Phaedrus <dwildstr@mbhs.edu> wrote:

> 
> Hi! I'm writing a BeOS GUI port of jzip, and am wondering which
> interpreter number to include in header byte 1E. I'm thinking of
> INTERP_UNIX (12) but would like some verification.
> 

I would strongly recommend DOS (6). Using a new code is just asking
for trouble from old Infocom games, particularly the V6 ones. Zip 2000 (for
RISC OS - another platform Infocom didn't have) defaults to this, but lets
the user override.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/

From ???@??? Wed Apr 08 18:06:01 1998
Return-Path: owner-z-machine@mail2.gmd.de
Newsgroups: rec.arts.int-fiction
Date: Mon, 23 Mar 1998 01:07:08 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Inform 6.15 released
Message-Id: <ant230108b49M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Organization: none
X-Newsreader: ANT RISCOS Marcel [ver 1.26]
Apparently-To: <z-machine@omega.gmd.de>
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 972fb9de6fa03efd9032c665f8db7996


Inform 6.15 now released
========================

The Inform compiler has been given its first maintenance re-release
since September.  Most of the bugs fixed are, as usual, fairly rare
and can be worked around, but there are now enough of them to justify
a fresh release.

There are also three minor enhancements, one of them quite useful:
----
Parametrised object creation.  That is, if you define a class in which
    objects can be created, and also give it a "create" property like so:

         Class Monster
         with ...
              create
              [ start_at new_species;
                  move self to start_at;
                  self.species = new_species;
              ], ...

    then you can now make creation calls like so:
    
         M = Monster.create(Tomb_of_Kings, Ogre);

    The same applies to "recreate":
    
         Monster.recreate(M, Wall_of_Thorns, Hobbit);

    An attempt to supply more than 3 parameters to either kind of creation
    will result in a run-time error message.
It is now legal to declare a Class with zero create-able objects:
    
         Class Moribund(0) ...

    This is useful (i) to permit a definition like
    
         Class Gadgets(NUM_GADGETS)
         
    in some library file, where NUM_GADGETS is supplied by the library
    file's user and might be zero; and/or (ii) to permit "recreate"
    to be used on objects of the given class, reinitialising them
    to the values set in the class definition.
The ASCII form feed character (12 decimal) is now legal as white space.
    More precisely, it is in all contexts treated as a line feed.
----
The Inform Technical Manual has as usual also been updated.

As a temporary measure, you can get hold of the ANSI C source code
for Inform 6.15 from the Inform 6 Home Page:

    http://www.gnelson.demon.co.uk/inform.html

Please note that there may be a delay of one to three days before
the new material becomes "visible" from your region of the Internet,
because of the regrettable way that my Internet service provider
organises its WWW space.  The material will in any case be filed
in its proper place at ftp.gmd.de shortly.

My thanks, as ever, to those who have emailed me bug reports.
I am always grateful for these, though it can sometimes take me
a couple of weeks to reply when I have a serious email backlog,
for which I apologise.  Please try to send me a short piece of
source code demonstrating what you think is wrong, if possible:
this saves on long explanations and makes it much easier for me
to find the problem.


    Graham Nelson
    22 March 1998


---------------------------------------------------------------------------
Bugs fixed since 6.14 (as reproduced from the Technical Manual):

Getting property lengths wrong for common property values referred to
    using the superclass operator :: (a bug which sometimes manifests
    itself in a crash when a common property routine belonging to a
    superclass is called).
Crashing when halting on a memory error because an extremely long string
    of text has caused MAX_STATIC_STRINGS to be exceeded.  (The compiler
    now ensures that MAX_STATIC_STRINGS is at least twice the size of
    MAX_QTEXT_SIZE, which should be more than plenty.)
Crashing when printing an extremely long "Expected ... but found ..."
    error (where the second ... stands for an awfully long string of
    text).
An inability to assemble the optional third operand to the "@set_colour"
    opcode (which is available to Version 6 games only).
Array sizes are now formally checked to lie in the range 1 to 32767
    entries, with an error message produced if they don't.
Misinterpretation of array definitions with calculated sizes:

         Array Muggins -> MAX_SERVERS * 50;

    In Inform 6.14, this would be wrongly parsed as an array with one
    entry, initialised to the value given: whereas 6.15 correctly parses
    it as an array with MAX_SERVERS*50 initially zero entries.
When constants are calculated with at compile time (as in the previous
    bug), Inform 6.15 now detects overflows of signed addition,
    subtraction and multiplication.  So if, for instance, MAX_SERVERS
    is 100000, then the following error is produced:

         Error:  Signed arithmetic on compile-time constants overflowed
         the range -32768 to +32767: "100000 * 50 = 500000"

Two bugs in the veneer (both found and fixed by Chris Hall): (i) a program
    using ".create()" but not "provides" will go into a recursive loop
    (this never happens if the Inform library is included);
    (ii) more importantly, some creations of objects within classes
    where deletions had previously occurred were resulting in two
    different created objects sharing the same properties.
Improper use of 'or' not always producing a good error message (sometimes
    producing instead the compiler error "*** emitter overflow ***").
    The more explanatory error message
    
         Error:  'or' not between values to the right of a condition

    should now be produced in all such cases.
Expressions featuring ) followed immediately by ( sometimes crashing
    the expression evaluator.  For instance:

         (ChooseRoutine())(1);
         BigRoom.(BigDoor.dir_to)();

    The grammar resolving whether a function call is intended, or
    only a bracketed expression, has been refined so that, e.g.,
    
         <SetTo dial (4*the_time)>;

    is not misinterpreted as containing one argument, the result of
    the function call "dial(4*the_time)".  (If you want this, you must
    put brackets around it.)
Named action constants (like ##Take) not being correctly numbered after
    the 256th in order of first usage.
The "Default" directive for setting constants not properly handling
    some values which are other than numerical -- e.g.,
    
         Default Story "Untitled Story";

    would not have worked correctly under Inform 6.14.
Backpatching "compiler errors" are now suppressed if errors have already
    been reported (because in some circumstances, error recovery is
    good enough to allow compilation to continue but not good enough
    to leave a self-consistent backpatch table in the affected area).
    Error recovery from missed close-quotation-marks in object
    definitions has been marginally improved in some cases.

Use of the Inform 5 statements 'print_paddr', 'print_addr' and
    'print_char' (all illegal in Inform 6) now results in an obsolete
    usage message which prints up the necessary Inform 6 equivalent.
The statistics output now includes the story file's serial codes, in the
    traditional <release number>.<serial code> format.

Note that v6.15 Technical Manual now contains an algorithm for
    syntax-colouring Inform source code, incorporating corrections made
    by John Wood.
---------------------------------------------------------------------------

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom

From ???@??? Wed Apr 22 10:07:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 9 Apr 1998 07:54:11 -0400 (EDT)
From: Phaedrus <dwildstr@mbhs.edu>
To: The Z-Machine Mailing List <z-machine@gmd.de>
Subject: [z-machine] Questions about "nothing" (what can I do with it?)
Message-Id: <Pine.LNX.3.96.980409074852.28503A-100000@binx.mbhs.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: cc091bc4c9fd8d992a4d708ebb548cfb


I know that the calls
	get_child 0
	get_parent 0
and 	get_sibling 0
are illegal, but what about:
	jin 0 obj
	jin obj 0
	test_attr 0 attr
	set_attr 0 attr
	clear_attr 0 attr
I'm tempted to believe that "jin 0 obj" is illegal, that "jin obj 0"
should jump if obj has no parent, "test_attr 0 attr" should never jump,
and "set/clear_attr 0 attr" should be illegal. Can I get any confirmation
on this?


+--First Church of Briantology--Order of the Holy Quaternion--+
| Brian Wilson's new album, "Imagination" is being released   |
| June 16th! Support your local genius and buy "Imagination"! |
+-------------------------------------------------------------+
|                       David Wildstrom                       |
+-------------------------------------------------------------+

From ???@??? Wed Apr 22 10:07:50 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <352D1E83.EB1D74D9@wurb.com>
Date: Thu, 09 Apr 1998 15:16:19 -0400
From: Carl Muckenhoupt <carl@wurb.com>
X-Mailer: Mozilla 4.04 [en] (Win95; I)
Mime-Version: 1.0
To: z-machine@gmd.de
Subject: Re: [z-machine] Questions about "nothing" (what can I do with it?)
References: <Pine.SUN.3.95.980409104542.10357D-100000@netcom16>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3a228892f671a0151ad5a37f05ceaf43

Andrew Plotkin wrote:
> Exception: Zork 1 seems to do "@jin 0 obj" if you type "go rope" (or
> anything else that responds "You should supply a direction!") I'm willing
> to consider this a bug on the Implementors' part. (In fact, I definitely
> recall that "go rope" had wild consequences in my very early Apple 2
> version of Zork 1; took you to random places.)

FWIW, I remember the same thing happening in the TRS-80 version if you types
"go house" from the starting position.

From ???@??? Wed Apr 22 10:07:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 9 Apr 1998 10:58:40 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom16
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Questions about "nothing" (what can I do with it?)
In-Reply-To: <Pine.LNX.3.96.980409074852.28503A-100000@binx.mbhs.edu>
Message-Id: <Pine.SUN.3.95.980409104542.10357D-100000@netcom16>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8f757b08dbc7e6ad6de531ee7e71aff3

On Thu, 9 Apr 1998, Phaedrus wrote:

> I know that the calls
> 	get_child 0
> 	get_parent 0
> and 	get_sibling 0
> are illegal, but what about:
> 	jin 0 obj
> 	jin obj 0
> 	test_attr 0 attr
> 	set_attr 0 attr
> 	clear_attr 0 attr
> I'm tempted to believe that "jin 0 obj" is illegal, that "jin obj 0"
> should jump if obj has no parent, "test_attr 0 attr" should never jump,
> and "set/clear_attr 0 attr" should be illegal. Can I get any confirmation
> on this?

I would much rather believe that they're all illegal, no clever damn
special cases. Keep it simple. 

I haven't gone looking, but I haven't seen any of these usages in Infocom
game files (when I use an interpreter set up to warn about them.)

Exception: Zork 1 seems to do "@jin 0 obj" if you type "go rope" (or
anything else that responds "You should supply a direction!") I'm willing
to consider this a bug on the Implementors' part. (In fact, I definitely
recall that "go rope" had wild consequences in my very early Apple 2
version of Zork 1; took you to random places.) 

Now this is separate from the question of what an interpreter should *do*
when it comes across an illegal opcode. Return 0 and/or never jump, is the
rule I used. But I think life will be much happier if we consider all
those cases illegal, and the game author's responsibility to fix if it all
possible.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Apr 22 10:08:06 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: John Elliott <jce@seasip.demon.co.uk>
Message-Id: <199804100010.AAA03350@seasip.demon.co.uk>
Subject: [z-machine] Buffering text
To: z-machine@gmd.de
Date: Fri, 10 Apr 1998 00:10:26 +0000 (GMT)
Content-Type: text
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 423916f04e9f41c0c1b605207e3f524c

  I'm porting my interpreter ZXZVM to another system, and I was wondering...

  This system prefers to print text as strings rather than single characters 
(so it can kern adjacent letters together). In order to take advantage of
this, I intend to print text a line at a time whether or not buffering 
is on. Any pending text would be printed before input requests, style
changes etc.
  Is this likely to break any games?

------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott           |BLOODNOK: "But why have you got such a long face?"
                       |SEAGOON: "Heavy dentures, Sir!"    - The Goon Show 
:-------------------------------------------------------------------------)

From ???@??? Wed Apr 22 10:08:10 1998
Return-Path: owner-z-machine@mail2.gmd.de
X-Sender: mattack@mail.apple.com
Message-Id: <v01550100b1530e52b650@[17.202.20.138]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 9 Apr 1998 16:48:15 -0700
To: z-machine@gmd.de
From: mattack@apple.com (Matt Ackeret)
Subject: Re: [z-machine] Buffering text
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c429f8a8ceb2940abcc8c3c77aafffc0

>  I'm porting my interpreter ZXZVM to another system, and I was wondering...
>
>  This system prefers to print text as strings rather than single characters
>(so it can kern adjacent letters together). In order to take advantage of
>this, I intend to print text a line at a time whether or not buffering
>is on. Any pending text would be printed before input requests, style
>changes etc.
>  Is this likely to break any games?

I did a similar thing in my own port of ZIP.

I just keep adding characters to a buffer, and only flush the buffer when
(1) a return is printed   (Though I guess this technically isn't necessary,
it is useful for the user to get some feedback quickly.)
(2) when input happens.

Actually I'm not sure if I even do #2 because I think a return is always
printed before input happens.. (and you're always in the bottom window,
which never does cursor moving at all, right???)

--
mattack@apple.com


From ???@??? Wed Apr 22 10:10:22 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 10 Apr 1998 09:35:23 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom2
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Buffering text
In-Reply-To: <v01550100b1530e52b650@[17.202.20.138]>
Message-Id: <Pine.SUN.3.95.980410092340.12640A-100000@netcom2>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 67e034b705b18931021c9453a239fc92

On Thu, 9 Apr 1998, Matt Ackeret wrote:

> >  I'm porting my interpreter ZXZVM to another system, and I was wondering...
> >
> >  This system prefers to print text as strings rather than single characters
> >(so it can kern adjacent letters together). In order to take advantage of
> >this, I intend to print text a line at a time whether or not buffering
> >is on. Any pending text would be printed before input requests, style
> >changes etc.
> >  Is this likely to break any games?
> 
> I did a similar thing in my own port of ZIP.
> 
> I just keep adding characters to a buffer, and only flush the buffer when
> (1) a return is printed   (Though I guess this technically isn't necessary,
> it is useful for the user to get some feedback quickly.)
> (2) when input happens.

I *only* do #2. It's never been a major problem. In fact, it's only been a
minor problem once, in Path to Fortune, which computes a whole night's
worth of turns while printing blank lines, one at a time. In MaxZip, this
winds up looking like a frozen pause followed by a total screen
update. Slightly ugly, but not awful. 

(If I updated the screen after every return was printed, there would be
significantly slower scrolling. Particularly on line-at-a-time output such
as tall nventory lists. I chose to avoid that. It's less of a problem on
faster machines, but of course the froze pause I mentioned above is also
less of a problem on faster machines.)
 
> Actually I'm not sure if I even do #2 because I think a return is always
> printed before input happens.. 

No, in almost all games, the prompt is printed before input happens, and
the prompt is just ">", no return at the end.

> (and you're always in the bottom window,
> which never does cursor moving at all, right???)

The upper window is often selected when doing character input (Inform
menus work this way, and the forms in Bureaucracy.)

It is also legal for the upper window to be selected when doing *line*
input. I believe this is only used in Beyond Zork, and then only when
defining in-game macros. MaxZip screws this up horribly. :-( 

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

From ???@??? Wed Apr 22 10:12:13 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: dpt@newsguy.com (David Turnbull)
To: z-machine@gmd.de
Subject: Re: [z-machine] Buffering text
Date: Sun, 12 Apr 1998 02:06:54 GMT
Message-Id: <35301e4e.163296@smtp.newsguy.com>
References: <v01550100b1530e52b650@[17.202.20.138]>
In-Reply-To: <v01550100b1530e52b650@[17.202.20.138]>
X-Mailer: Forte Agent 1.5/32.452
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 02463d09da49bb1a3003808d7c5ac081

On Thu, 9 Apr 1998 16:48:15 -0700, you wrote:

>>  I'm porting my interpreter ZXZVM to another system, and I was wondering...
>>
>>  This system prefers to print text as strings rather than single characters
>>(so it can kern adjacent letters together). In order to take advantage of
>>this, I intend to print text a line at a time whether or not buffering
>>is on. Any pending text would be printed before input requests, style
>>changes etc.

I guess you should ask yourself what benefit you get from printing a
line at a time instead of a word at a time.  In Ftotz, the OS
functions are sent an entire word at once, which should be very
compatible with your kerning.

I don't think very many games are going to turn off buffering.  The
ones that do are probably just going to print periods (wait......) or
be in a fixed-width font.

If it were me, and the CPU was fast I would do the following:  If in
proportional font, always do "word at a time printing" aka buffering.
If fixed font, obey the program's requests for buffering.

>>  Is this likely to break any games?

I doubt any would break, as long as you flushed the buffer on read or
read_char and so on.  If you have a slow machine, or delays are
programmed in the game, the user might be left "hanging" in some
cases, but this is only a minor annoyance and probably pretty rare.

-david

From ???@??? Wed Apr 22 10:21:11 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19980415100049.jholder@io.frii.com>
Date: Wed, 15 Apr 1998 10:00:49 -0600
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: [z-machine] Jzip 2.0.2 BETA - UNIX TESTERS Needed
X-Mailer: Mutt 0.57
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f157be187a2087e75e2f5dc1ec9432ce


I have released a BETA version of Jzip 2.0.2.

Testers wanted for UNIX ports only, at this point.

New features:
 	- Supports Quetzal.
 	- Supports Zarf's STRICTZ checking.
 	- Supports Extended save/load opcode.
 	- claims 0.2 compliance. (almost there, still tweaking things.)
 	- supports a few international chars.  Still being worked on.

Please try it out.  This is not a time-limited release, HOWEVER,
please do not distribute it outside of GMD until the code is rock solid.

Known Bug:
	- SoFar.z8 save files do not restore properly, although all other
          released .z8 games appear to work.

URLS:
ftp://ftp.gmd.de/incoming/if-archive/jzip202beta15APR1998.zip

Where Volker and David will put it is beyond me.  Perhaps in
ftp://ftp.gmd.de/if-archive/infocom/interpreters/zip

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/


From ???@??? Wed Apr 22 10:21:47 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: John Elliott <jce@seasip.demon.co.uk>
Message-Id: <199804152259.WAA02916@seasip.demon.co.uk>
Subject: [z-machine] Re: Buffering text
To: z-machine@gmd.de
Date: Wed, 15 Apr 1998 22:59:25 +0000 (GMT)
Content-Type: text
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 536a75d6f37c8b81200f0e4c538d2355

  Thanks to everyone who has made suggestions. ZXZVM v0.02 is now at gmd,
and in the unlikely event that you have a PCW16, you can see the text 
printing system in action. It isn't quite perfect yet; because of the 
buffering, changes to the 'fixed font' header flag don't always appear where
they're supposed to.

  Still, there are more important bugs to fix than that. Can anyone think
why the _Curses_ (r12) help menus would print all the menu options on the 
same line, while the menu cursor appears in the correct place?

------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott           |BLOODNOK: "But why have you got such a long face?"
                       |SEAGOON: "Heavy dentures, Sir!"    - The Goon Show 
:-------------------------------------------------------------------------)

From ???@??? Wed Apr 22 10:21:57 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <199804151854.LAA07904@newsguy.com>
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 15 Apr 1998 13:52:46 -0500
To: z-machine@gmd.de
From: David Turnbull <dpt@newsguy.com>
Subject: Re: [z-machine] Jzip 2.0.2 BETA - UNIX TESTERS Needed
In-Reply-To: <Mutt.19980415100049.jholder@io.frii.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 08db1180e9ec95ebbb12e88e1a14945c

At 10:00 AM 4/15/98 -0600, J. Holder wrote:
>
>I have released a BETA version of Jzip 2.0.2.
>
>Testers wanted for UNIX ports only, at this point.

Just did a quick "smoke test" and have the following to report:

- unix.mak worked perfectly on Solaris 2.6 w/GCC

- jzexe worked

- when testing with bear.z5, pressing CTRL-C causes game to bring up "[Hit
any key to exit.]" but pressing any key causes prompt to come up again,
then the next time you get a "Game file read error (PC = c170)".  Quitting
with "quit" does work properly.  CTRL-C, IMO, should not cause the game to
exit without confirmation anyway.

I don't have time to get into the source and tell you what's wrong because
I'm deep into my own port of Frotz for PlamPilot right now.  If you think
you have a fix for the CTRL-C problem and want to throw it my way, I'll
gladly test it.

-david

From ???@??? Wed Apr 22 10:22:20 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 16 Apr 1998 09:26:16 +0200
From: Torbj|rn Andersson <d91tan@Update.UU.SE>
Message-Id: <199804160726.JAA27991@Zeke.Update.UU.SE>
To: z-machine@gmd.de
Subject: Re: [z-machine] Jzip 2.0.2 BETA - UNIX TESTERS Needed
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0ecdc1cec5fc84342ca17230f9401fd5

> Known Bug:
>         - SoFar.z8 save files do not restore properly, although all other
>           released .z8 games appear to work.
 
This sounds like the bug Andrew Plotkin wrote about back in January.
At least, I was able to keep the new Jzip from crashing by changing
quetzal.c as he suggested.                                        
 
Here's the relevant part (just about all of it, actually) of that mail:
 
> In the sample quetzal.c file, line 308, we see
> 
>   if (h_version != 6) {
>     /* dummy stack frame for stack used before call */
> 
> This is supposed to represent the difference in stack usage between V6
> games and the other Z-machine types. Unfortunately, in Mark Howell's ZIP
> source, "h_version" is the *release number* (bytes 2-3) from the header,
> not the Z-machine version number (byte 0).
> 
> This line should be changed to
> 
>   if (h_type != 6) {
> 
> The error manifests itself if you try to save and restore a V5/8 game
> which happens to be release 6. You get a "wrong variable number on stack"
> error, followed by a fatal ZIP error. Presumably it would also screw up in
> any V6 game which was *not* release 6. 
> 
> Note that "h_version" occurs in two other places in quetzal.c, and there
> it is correct. (Quetzal saves the game release number in the IFhd chunk.) 

So Far is, of course, release 6.

     _
Torbjorn

From ???@??? Wed Apr 22 10:25:02 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19980416122733.jholder@io.frii.com>
Date: Thu, 16 Apr 1998 12:27:33 -0600
From: jholder@frii.com (J. Holder)
To: d91tan@update.uu.se (Torbj|rn Andersson)
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Jzip 2.0.2 BETA - UNIX TESTERS Needed
References: <199804160726.JAA27991@Zeke.Update.UU.SE>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <199804160726.JAA27991@Zeke.Update.UU.SE>; from Torbj|rn Andersson on Apr 16, 1998 09:26:16 +0200
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 595da82ca2decd7753f82830670a4b6d

Torbj|rn Andersson writes:
> > Known Bug:
> >         - SoFar.z8 save files do not restore properly, although all other
> >           released .z8 games appear to work.
>  
> This sounds like the bug Andrew Plotkin wrote about back in January.
> At least, I was able to keep the new Jzip from crashing by changing
> quetzal.c as he suggested.                                        

Sure enough.  Andrew got me the info yesterday...  Somehow I missed that one.
I did get the .z3 patches in tho. ;)

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/

From ???@??? Wed Apr 22 10:25:04 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19980416123525.jholder@io.frii.com>
Date: Thu, 16 Apr 1998 12:35:25 -0600
From: jholder@frii.com (J. Holder)
To: dpt@newsguy.com (David Turnbull)
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Jzip 2.0.2 BETA - UNIX TESTERS Needed
References: <Mutt.19980415100049.jholder@io.frii.com> <199804151854.LAA07904@newsguy.com>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <199804151854.LAA07904@newsguy.com>; from David Turnbull on Apr 15, 1998 13:52:46 -0500
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6d4172904f4aface8b951ff20034931b

David Turnbull writes:
> At 10:00 AM 4/15/98 -0600, J. Holder wrote:
> >
> >I have released a BETA version of Jzip 2.0.2.
> >
> >Testers wanted for UNIX ports only, at this point.
> 
> Just did a quick "smoke test" and have the following to report:
> 
> - unix.mak worked perfectly on Solaris 2.6 w/GCC
> 
> - jzexe worked
> 
> - when testing with bear.z5, pressing CTRL-C causes game to bring up "[Hit
> any key to exit.]" but pressing any key causes prompt to come up again,
> then the next time you get a "Game file read error (PC = c170)".  Quitting
> with "quit" does work properly.  CTRL-C, IMO, should not cause the game to
> exit without confirmation anyway.

While I have code in the interpreter to "eat" CTRL characters (with the 
exception of ctrl-D, which will end your session immediately (EOF after all 
(You see, I like to plug expect onto my interpreter...)), ctrl-m, & ctrl-h, 
but for some reason, ctrl-C will always get the interpreter out of cbreak 
mode, and this always causes serious problems.  does anyone have suggestions?

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/

From ???@??? Wed Apr 22 10:31:33 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <000101bd6bdf$38ebd2e0$d8054e8c@async.edvz.uni-linz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Z-Machine List" <z-machine@gmd.de>
Subject: [z-machine] [Inform] Possible addition to the next version?
Date: Mon, 20 Apr 1998 00:03:30 +0200
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8ba246f19932955ca2227a9d83bf3fbb

Of all the useful libraries that have appeared over time, I think L. Ross
Raszewski's ZNSI.H implements the feature that I missed most in Inform so
far (and even AGT has it!): in-string formatting codes.

So I've been thinking: would there be any problem with including this in the
next version of Inform? I know someone said "if we add everything to Inform
that somebody suggests, we'll get clunky libraries" (or something similar),
but this seems like a very very useful, time-saving addition indeed.

So why not use the ZNSI.H library? Because of string length limitation.
Directly included into the print, print_ret and "" statements (and even box,
which I've missed for a long time), this would be really great.

In comparison:

Now:
print "Use "; style bold; print "EXAMINE"; style roman; print " ("; style
bold; print "X"; style roman; print ") to look at things more closely.";

becomes:
"Use ]BEXAMINE]N (]BX]N) to look at things more closely.";
     ^^       ^^  ^^ ^^
     formatting codes

Yeah, I know you can use
print "Use", (emboss) 1,"EXAMINE" ...

but it's still way better with in-string formatting codes.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +----------------------------------------------+
+ Tel: 0732 25 28 57     + http://gschmidl.home.ml.org - new & improved +
+------------------------+----------------------------------------------+


From ???@??? Wed Apr 22 12:10:24 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <3.0.32.19980422112553.00800a50@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 22 Apr 1998 11:28:00 +1200
To: jholder@frii.com (J. Holder)
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Jzip 2.0.2 BETA - UNIX TESTERS Needed
Cc: z-machine@gmd.de
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f392cf5badae11b830a3fd06ac67aa65

At 12:35 16/04/98 -0600, J. Holder wrote:
>> At 10:00 AM 4/15/98 -0600, J. Holder wrote:
>> >I have released a BETA version of Jzip 2.0.2.
[...]
>While I have code in the interpreter to "eat" CTRL characters (with the 
>exception of ctrl-D, which will end your session immediately (EOF after all 
>(You see, I like to plug expect onto my interpreter...)), ctrl-m, & ctrl-h, 
>but for some reason, ctrl-C will always get the interpreter out of cbreak 
>mode, and this always causes serious problems.  does anyone have suggestions?

I thought CTRL-Z was EOF; surely that's the same on UNIX & PC?  But your
CTRL-C problem sounds like a signal thing; I haven't done any UNIX
programming myself, but I think all you need to do is tell the computer to
ignore the SIGINT signal.  On my compiler that can be done by calling
signal(SIGINT, SIG_IGN); I'm not sure on yours.  There's a similar signal
if you hit CTRL-Break; that one is called SIGBREAK.

Of course, instead of ignoring them you could instead redirect them to a
routine to set a QUIT flag or something, so that when your normal code
resumes it will jump out of the input routine and ask if you really want to
quit.  Just remember that when your signal-handler routine returns, the
input routine (or whatever) will resume where it left off.

Hope that helps.

-----                                
Gavin Lambert
uecasm@geocities.com
http://ue.home.ml.org/
Mirabilis ICQ UIN: 2274180  (what's ICQ?  Check out www.mirabilis.com)
Fight the spam!  Support an anti-unsolicited email amendment at
http://www.cauce.org/

----
Engage Brain Before Putting Mouth Into Gear.

People usually get what's coming to them...  unless it was mailed.

Insurance Claim: "To avoid hitting the bumper of the car in front, I struck
the pedestrian."
----

The above quotes have been randomly selected from a huge list.  I apologize
if you find some of them offensive.

From ???@??? Wed Apr 22 15:14:05 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <353D5966.F0B35557@ibm.net>
Date: Tue, 21 Apr 1998 22:43:50 -0400
From: John W Kennedy <jwkenne@ibm.net>
Reply-To: jwkenne@ibm.net
X-Mailer: Mozilla 4.05 [en] (Win95; U)
Mime-Version: 1.0
To: Gavin Lambert <uecasm@geocities.com>
Cc: "J. Holder" <jholder@frii.com>, z-machine@gmd.de
Subject: Re: [z-machine] Jzip 2.0.2 BETA - UNIX TESTERS Needed
References: <3.0.32.19980422112553.00800a50@pop.ihug.co.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 29de19ea0022781a914a9ec209cf54d6

Gavin Lambert wrote:
> I thought CTRL-Z was EOF; surely that's the same on UNIX & PC?

Alas, no.  Way back in the 70's, CP/M decided to use ^Z as EOF on disk
files, and DOS copied it (quite unnecessarily, I might add; the
technical reason for having any EOF on disk files at all was already
obsolete in DOS 1.0).  And it was wrong, wrong, wrong.  It should never
have been done.  It was an abuse of ASCII to do so.  CTRL-Z is the code
that is supposed to mean "While translating to ASCII from some other
code, I found something without a translation, or some other sort of
error that cannot be represented in ASCII."  CTRL-D is the code used for
EOF-from-the-keyboard in UNIX, and it is a much more sensible choice;
UNIX has no EOF-on-disk character at all.

From ???@??? Thu May 28 15:38:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19980527104252.jholder@io.frii.com>
Date: Wed, 27 May 1998 10:42:52 -0600
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: [z-machine] Jzip 2.0.2 Beta Release
X-Mailer: Mutt 0.57
Mime-Version: 1.0
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: adc89d3f64e1f887c548d3842c00cf8d



A new beta has been released!  Until it is in the usual spot, 
it can be found in:

/incoming/if-archive/jzip202beta-std10-unix-052798.tgz

This is a Std.1.0 compliant, Latin-1 enabled, Quetzal enabled version
of Jzip supporting extended save & load opcodes, and properly flushes
timed readkey buffers.  Hard_colors works.  There is a very raw port
if the i/o modules to curses/ncurses as well, that mostly works.

Currently, there are no known bugs present in the system.  Please
report any to me, and I will make this an official release within the
next 4-6 weeks, or when the curses io module is completed.

John
-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/


From ???@??? Thu May 28 15:38:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <19980527195856.24464.qmail@hotmail.com>
X-Originating-Ip: [209.3.129.166]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: [z-machine] [BETA] menu6.z6 <-- Domenu/Altmenu test in v6
Content-Type: text/plain
Date: Wed, 27 May 1998 15:58:56 EDT
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ee4df4c199ac6a4dda194f58feede1b4


Hi all.
I've hacked together a fully working version of the Domenu/Altmenu suite 
for V6Lib.  THe v6 test program, menu6, is a port of the v5 test 
program, menus.inf, which is available at gmd.  

Anyway, I'd be much obliged if I could get a few people to test it out 
on various v6 interpreters.  The file is available at 
<http://www.chelmsford.com/home/jpenney/V6Lib/menu.zip>

Please e-mail all comments to me (rraszews@acm.org) with a cc to Jason C 
Penney <jpenney@chelmsford.com>

thanks.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


From ???@??? Sun Jul 26 14:14:33 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 20 Jul 1998 10:34:13 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: [z-machine] I'm upgrading Zip 2000 - test fodder wanted.
Message-Id: <4e4e8b6848%kbracey@kbracey.acorn.co.uk>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: f1d64d82c0760bede7e690b4aeec9281


I'm in the process of bringing Zip 2000 up to Standard 1.0, and implementing
Quetzal and Blorb, and I'm looking for test fodder.

1) Has anyone got any nasty test programs for the Unicode part of Standard
   1.0? I've tested the simple stuff, but has anyone got, say, a simple test
   game that has Russian or Greek input? (I had endless hours of fun
   converting the whole Zip 2000 core to handling text as Unicode - but it
   all seems to still work, miraculously...)
   
   How good are other interpreters at handling the Unicode extension table
   at this point?

2) I've implemented Quetzal, but I need other Quetzal files to test
   against. What interpreters support Quetzal? Can anyone send me
   Quetzal saved positions from any of the LTOI 1/2 games I can try
   loading?

Cheers,

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sun Jul 26 14:14:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 20 Jul 1998 05:50:50 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom9
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] I'm upgrading Zip 2000 - test fodder wanted.
In-Reply-To: <4e4e8b6848%kbracey@kbracey.acorn.co.uk>
Message-Id: <Pine.SUN.3.95.980720054932.4637A-100000@netcom9>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5ac0084f1ed6d63ad47c4aa1b4a4cf0e


On Mon, 20 Jul 1998, Kevin Bracey wrote:

> I'm in the process of bringing Zip 2000 up to Standard 1.0, and implementing
> Quetzal and Blorb, and I'm looking for test fodder.
> 
>    How good are other interpreters at handling the Unicode extension table
>    at this point?

As far as I know, nobody has ever tried to implement this stuff until you. 
 
> 2) I've implemented Quetzal, but I need other Quetzal files to test
>    against. What interpreters support Quetzal? Can anyone send me
>    Quetzal saved positions from any of the LTOI 1/2 games I can try
>    loading?

JZip, XZip, MaxZip. I can send you save files tonight, if nobody else has.
(You have the test files from Jigsaw, right?)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sun Jul 26 14:14:39 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 20 Jul 1998 06:13:39 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom9
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] I'm upgrading Zip 2000 - test fodder wanted.
In-Reply-To: <Pine.SUN.3.95.980720054932.4637A-100000@netcom9>
Message-Id: <Pine.SUN.3.95.980720061253.6096A-100000@netcom9>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e5865159e43a6ac62aedfbf15d1f10b6


On Mon, 20 Jul 1998, Andrew Plotkin wrote:

> >    What interpreters support Quetzal? 
> 
> JZip, XZip, MaxZip.

Sorry -- should have added "...and I can never remember what Frotz
supports." :-)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sun Jul 26 14:14:44 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 20 Jul 1998 16:45:05 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] I'm upgrading Zip 2000 - test fodder wanted.
Message-Id: <9042ad6848%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <Pine.SUN.3.95.980720054932.4637A-100000@netcom9>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1d28667f4b34078a4126152a4bce3c08


In message <Pine.SUN.3.95.980720054932.4637A-100000@netcom9>
          Andrew Plotkin <erkyrath@netcom.com> wrote:

> 
> As far as I know, nobody has ever tried to implement this stuff until you. 

That'll be because I'm a nutter. I was the first person to do V6 too...

>  
> > 2) I've implemented Quetzal, but I need other Quetzal files to test
> >    against. What interpreters support Quetzal? Can anyone send me
> >    Quetzal saved positions from any of the LTOI 1/2 games I can try
> >    loading?
> 
> JZip, XZip, MaxZip. I can send you save files tonight, if nobody else has.
> (You have the test files from Jigsaw, right?)
> 

Er, nope. Where are they? Conversely, can I send you a save file? I have
a sample from Zork I (V5 version) at work with me here.

BTW, when this set of changes is finished, I will be releasing Zip 2000
as freeware rather than shareware, and making the source available. It
might be edifying for other interpreter writers.

As an idle aside, I feel I made a PR cock-up by calling it "Zip 2000". 
Stefan had the right idea when he called his "Frotz". People (including
the Inform manuals) tend to get think that Zip 2000 is a Zip derivative/port,
while Frotz is a whole new interpreter. Zip 2000 is no more a port of Zip
than Frotz is :(

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sun Jul 26 14:14:50 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35B3833D.95A80A3F@dsres.com>
Date: Mon, 20 Jul 1998 18:49:49 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Kevin Bracey <kbracey@acorn.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] I'm upgrading Zip 2000 - test fodder wanted.
References: <9042ad6848%kbracey@kbracey.acorn.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: da2ea3058b1c60ef818e1af2c8bbfa41


Kevin Bracey wrote:
> In message <Pine.SUN.3.95.980720054932.4637A-100000@netcom9>
>           Andrew Plotkin <erkyrath@netcom.com> wrote:

> > > 2) I've implemented Quetzal, but I need other Quetzal files to test
> > >    against. What interpreters support Quetzal? Can anyone send me
> > >    Quetzal saved positions from any of the LTOI 1/2 games I can try
> > >    loading?

> > JZip, XZip, MaxZip. I can send you save files tonight, if nobody else has.
> > (You have the test files from Jigsaw, right?)

> Er, nope. Where are they? Conversely, can I send you a save file? I have
> a sample from Zork I (V5 version) at work with me here.

The files *used* to be available on my web page, but they were withdrawn
after bugs were discovered in some of them. I've managed to lose most of
them (I tend to create them on the fly when people ask for them). I'll
knock some up tonight and mail them to you tomorrow (UK time).

There is also a useful utility I wrote called `ckifzs', which tests the
fundamental integrity of the file (rather than any subtleties of the
compression or something). C source for this follows (not copied to the
list).

As to real stress-test files, I don't have any, I'm afraid (maybe had I
made some the Quetzal patches would have been less buggy).

Martin


From ???@??? Sun Jul 26 14:14:54 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 20 Jul 1998 16:11:14 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199807202011.QAA13265@pond.com>
To: z-machine@gmd.de
Subject: Re:  [z-machine] I'm upgrading Zip 2000 - test fodder wanted.
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 1b95db7024e18b0a9846eb93a18d27f1


}    How good are other interpreters at handling the Unicode extension table
}    at this point?

ZIP Infinity and ZPlet do not attempt to.

} 2) I've implemented Quetzal, but I need other Quetzal files to test
}    against. What interpreters support Quetzal? Can anyone send me
}    Quetzal saved positions from any of the LTOI 1/2 games I can try
}    loading?

ZPlet and Zip Infinity 1.4b2 both handle Quetzal.


From ???@??? Sun Jul 26 14:15:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
Path: kbracey.acorn.co.uk!kbracey
Date: Wed, 22 Jul 1998 11:27:29 +0100
From: Kevin Bracey <kbracey@acorn.com>
Cc: z-machine@gmd.de, blasius@gmd.de
Subject: [z-machine] RISC OS Zip 2000 version 1.30 released
Message-Id: <bdda976948%kbracey@kbracey.acorn.co.uk>
Organization: Acorn Computers Ltd, Cambridge, United Kingdom
Lines: 56
X-Newsreader: Messenger v1.40a for RISC OS
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: bfb7e847d52628adf73aef3732ab3d25


This is a courtesy copy of a newsgroup posting.

Zip 2000 is a Standard interpreter (Revision 1.0) for Z-code programs.

In plain English, that means if you want to play Infocom interactive
fiction, or games written with the Inform compiler, on a RISC OS machine,
then this is the program for you.

Features include:

  * Full support for Version 1,2,3,4,5,6,7 & 8 games.
  * Full conformance to Graham Nelson's "Z-Machine Standards
    Document", Revision 1.0.
  * Graphics support.
  * Colour support.
  * Timed-input support.
  * Sound support.
  * Mouse support.
  * Menu support.
  * Full function key/cursor key/keypad support.
  * Full foreign language support, including runes and Unicode.
  * Easily adjustable screen size.
  * Full use of anti-aliased outline fonts.
  * Line editing & command recall.
  * Quetzal-format save files.
  * Multiple UNDO.
  * High speed - the fastest Z-code interpreter for RISC OS.
  * The best-looking Z-code interpreter on any platform.

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

New features in version 1.30 include:

  * All versions are now freeware, and include full V6 support, command
    recall, etc.

  * Full conformance to version 1.0 of the Z-machine Standards Document,
    including Unicode tables and nested stream 3.

  * Quetzal save file support.

Zip 2000 1.30 is available from:

  ftp://ftp.gmd.de/incoming/if-archive/Acorn_Zip2000_Std1.0.spk_Take2
      
from where it will shortly move to:

  ftp://ftp.gmd.de/if-archive/infocom/interpreters/zip/Acorn_Zip2000_Std1.0.spk
  
[/incoming/if-archive/Acorn_Zip2000_Std1.0.spk is a copy of the Z-Machine
 Standards Document, thanks to a slip of my mouse :)]


Share and enjoy!


Kevin Bracey
============


From ???@??? Sun Aug 02 14:27:15 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 10:15:15 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: [z-machine] Game title in Blorb files
Message-Id: <cac3336e48%kbracey@kbracey.acorn.co.uk>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e5261bad1e4b8baa8a23ab06e137c5a4


As I've been working on Blorb, I've noticed one potentially useful
omission; no standard way of storing the game's title seems to be defined.

I could really do with this to stick it in my window's title bar.
"The Blorb File" looks much better than "spy/z5".

Perhaps we could define a standard format for the ANNO chunk for Blorb
files? Or maybe just a separate chunk to keep it simple.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sun Aug 02 14:27:17 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 10:10:52 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: [z-machine] "The Blorb File" and @sound_effect
Message-Id: <465d336e48%kbracey@kbracey.acorn.co.uk>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 0a6780761c931828b70d335ec2c95272


I've gotten Zip 2000 to the point where it can run the all-in-one
version of Graham Nelson's "The Blorb File". (Much credit to
blorblib, which saved a lot of tedium).

Unfortunately, I'm now treated to a never-ending loop of "boing" sounds
when I drop the fir cone. This seems to be down to a three-way disagreement
between "The Blorb File", Zip 2000, and the Standard.

"The Blorb File" uses the @sound_effect opcode thus:

        @sound_effect  num  2  $FF  1

Zip 2000 interprets this as "Play sound <num>, maximum volume, repeating
infinitely, then call routine at address 4". It reckons that the third
parameter is volume (low byte) + times to play (high byte). It reckons
that if times to play = 0, it repeats forever. Fortunately, because
it's repeating forever, it never branches to address 4.

The Standard says that the high-byte of parameter 3 is times to _repeat_,
$FF meaning forever.

I reckon:

   1) The high-byte of parameter 3 is times to _play_, not repeat. I'm
      pretty certain that that's the way Sherlock works. So
      "@sound_effect num 2 $01FF" means play once at maximum volume, not
      twice.
      
   2) I must have gotten the idea that 0 = forever from somewhere.
      Anyone have an idea? It does seems pretty logical if that byte is
      times to play.
      
   3) Graham meant to type  "@sound_effect num 2 $01FF". The fourth
      parameter being 1 is silly.

Any comments?

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sun Aug 02 14:27:18 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35C1991E.3566E21F@dsres.com>
Date: Fri, 31 Jul 1998 11:14:54 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Game title in Blorb files
References: <cac3336e48%kbracey@kbracey.acorn.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5052d906eda378197fab53112878041c


Kevin Bracey wrote:

> Perhaps we could define a standard format for the ANNO chunk for Blorb
> files? Or maybe just a separate chunk to keep it simple.

I'd prefer a separate NAME (or somesuch) chunk.

Assuming magical things about standard chunks violates the IFF spec.

How about a chunk, type `NAME', with contents just like the ANNO chunk
(namely a block of bytes, each in the range 0x20 to 0x7E, interpreted as
ASCII text).

Or maybe it would be better to have it in Unicode?

Thinking about it, this would be a useful addition to Quetzal, too. I'm
thinking of users being able to say `where *did* this random save file
come from?' and being able to have the author's idea of the name of the
game (as opposed to the local filesystem's). This much could come from
an ANNO, though. OTOH, using a new chunk would allow interpreters to
compare the name of the game with that from the save file, giving a much
more accurate test of whether a save file really belongs with a game...
I'm digressing, however.

--m


From ???@??? Sun Aug 02 14:27:20 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 11:37:20 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Game title in Blorb files
Message-Id: <83473b6e48%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <35C1991E.3566E21F@dsres.com>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1

X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 900601d3024a3dc74a4c8b1f50fbf396


In message <35C1991E.3566E21F@dsres.com>
          Martin Frost <martin@dsres.com> wrote:

> How about a chunk, type `NAME', with contents just like the ANNO chunk
> (namely a block of bytes, each in the range 0x20 to 0x7E, interpreted as
> ASCII text).
> 
> Or maybe it would be better to have it in Unicode?

Absolutely. Interpreters need to have some sort of Unicode handling
already. Make the data big-endian UCS-2, which is no more or less than the
interpreter should already be able to handle.

> 
> Thinking about it, this would be a useful addition to Quetzal, too. I'm
> thinking of users being able to say `where *did* this random save file
> come from?' and being able to have the author's idea of the name of the
> game (as opposed to the local filesystem's). This much could come from
> an ANNO, though. OTOH, using a new chunk would allow interpreters to
> compare the name of the game with that from the save file, giving a much
> more accurate test of whether a save file really belongs with a game...
> I'm digressing, however.
> 

Good idea. Zip 2000 could then say 'This saved game file belongs to "Nord and
Bert Couldn't Make Head or Tail of It,"' rather than 'Saved game file does
not belong to this game'.

I don't think you actually want the interpreter to start comparing strings
though. Isn't comparing game headers and checksums far more accurate? You
don't want to give a Jigsaw Release 2 savefile to Jigsaw Release 3.
Although in that case you'd probably want to change the message above to
'This saved game file belongs to a different version of "Jigsaw,"' otherwise
you'd confuse the poor old user.

I'd define the content as:

   "A line of text describing the game, suitable for display in a window's
    title bar, or as a menu entry. By Inform and Infocom convention, usually
    the banner displayed in bold at start-up."

And then I'd give some examples:

      Jigsaw
      Zork I: The Great Underground Empire
      Zork I: Das Große Unterweltreich
      The Path to Fortune - Volume One of "The Windhall Chronicles"
      So Far
      Border Zone
      Nord and Bert Couldn't Make Head or Tail of It

Maximum length of 65 characters, say? What's a good chunk name? "BANN",
"GAME", "NAME", "TITL"?

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sun Aug 02 14:27:23 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35C1B3ED.15537210@dsres.com>
Date: Fri, 31 Jul 1998 13:09:17 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: [Fwd: [z-machine] Game title in Blorb files]
Content-Type: multipart/mixed; boundary="------------BA5FAEA844E31917F07069D3"
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: bdf2aeb9c963caa8bacb3dc7e2f341b9

Sorry, forgot to send this to the list as well:Message-ID: <35C1B397.AF8C9660@dsres.com>
Date: Fri, 31 Jul 1998 13:07:51 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Kevin Bracey <kbracey@acorn.com>
Subject: Re: [z-machine] Game title in Blorb files
References: <83473b6e48%kbracey@kbracey.acorn.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Kevin Bracey wrote:

> In message <35C1991E.3566E21F@dsres.com>
>           Martin Frost <martin@dsres.com> wrote:

> > [story name chunk in Quetzal as well as Blorb]

> Good idea. Zip 2000 could then say 'This saved game file belongs to "Nord and
> Bert Couldn't Make Head or Tail of It,"' rather than 'Saved game file does
> not belong to this game'.

> I don't think you actually want the interpreter to start comparing strings
> though. Isn't comparing game headers and checksums far more accurate? You
> don't want to give a Jigsaw Release 2 savefile to Jigsaw Release 3.
> Although in that case you'd probably want to change the message above to
> 'This saved game file belongs to a different version of "Jigsaw,"' otherwise
> you'd confuse the poor old user.

Yes, exactly. I'd say that if the name is present in story and save
file, then they should be compared. Not only does this avoid confusing
users (who probably either don't realise that their version of Jigsaw is
different from the version at their friend's place; or don't realise
that it matters for save files), but it also adds just that one extra
line of security against some terrible coincidence with two people
releasing different stories with the same header fields...

To clarify, I never intended to mean that *just* the names should be
compared. I meant that they should be used in addition to all the other
hints available.

> And then I'd give some examples: [of suitable contents]
> [see original post]

I like the selection.

> Maximum length of 65 characters, say?

Maybe make it a `recommended limit', with the obligatory blurb about
trimming somewhere appropriate and adding an ellipsis? After all, it is
only really for making things look better. If we really want an
arbitrary limit, 63 or 64 are much nicer numbers than 65, imho...

> What's a good chunk name? "BANN", "GAME", "NAME", "TITL"?

I'd say `NAME' or `Name'. Quoting IFF spec from memory, `it should be
easy to look at the chunk name and figure out the purpose of the
contents'. Ideally, `Title' would be better, but with 32-bit IDs, I'd go
for some variant of `name'.

How about *suggesting* that it goes near the beginning of the file
(without actually *requiring* this), so that someone doing an ASCII dump
of the file can work out what it is. No extra effort for interpreter
writers, and just that little extra usefulness...

--m


From ???@??? Sun Aug 02 14:27:28 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 07:26:28 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Game title in Blorb files
In-Reply-To: <83473b6e48%kbracey@kbracey.acorn.co.uk>
Message-Id: <Pine.SUN.4.02.9807310718110.3691-100000@netcom14>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 361e0500a73d34c240a3789f9c72417c


On Fri, 31 Jul 1998, Kevin Bracey wrote:

> In message <35C1991E.3566E21F@dsres.com>
>           Martin Frost <martin@dsres.com> wrote:
> 
> > How about a chunk, type `NAME'

I like this. (For both Blorb and Quetzal.) 

> > with contents just like the ANNO chunk
> > (namely a block of bytes, each in the range 0x20 to 0x7E, interpreted as
> > ASCII text).
> > 
> > Or maybe it would be better to have it in Unicode?
> 
> Absolutely. Interpreters need to have some sort of Unicode handling
> already.

Er, what? No they don't. Unicode is optional. Yes, I'm the lazy one here,
but I think it's very silly to require Unicode support solely for a "name"
feature (which is, itself, optional and purely for the player's
convenience.) 

The ANNO (20-7E) format is already in both Blorb and Quetzal. It's
deliberately a least-common-denominator format, so that absolutely
everybody will be able to handle it. I think that's the right idea here.

> I don't think you actually want the interpreter to start comparing strings
> though.

I agree. This is good for a warning, but the player should never be
prevented from loading a save file if the names don't match. (Even if both
are present.)

> > Maximum length of 65 characters, say?
>
> Maybe make it a `recommended limit', with the obligatory blurb about
> trimming somewhere appropriate and adding an ellipsis?

Yes. I don't think there's any reason for a mandatory limit.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Sun Aug 02 14:27:30 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19980731091043.jholder@io.frii.com>
Date: Fri, 31 Jul 1998 09:10:43 -0600
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Game title in Blorb files
References: <83473b6e48%kbracey@kbracey.acorn.co.uk> <Pine.SUN.4.02.9807310718110.3691-100000@netcom14>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <Pine.SUN.4.02.9807310718110.3691-100000@netcom14>; from Andrew Plotkin on Jul 31, 1998 07:26:28 -0700
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e0372a1c5eab29756f223f57f97a3c36


Andrew Plotkin writes:
> > > with contents just like the ANNO chunk
> > > (namely a block of bytes, each in the range 0x20 to 0x7E, interpreted as
> > > ASCII text).
> > > 
> > > Or maybe it would be better to have it in Unicode?
> > 
> > Absolutely. Interpreters need to have some sort of Unicode handling
> > already.
> 
> Er, what? No they don't. Unicode is optional. Yes, I'm the lazy one here,
> but I think it's very silly to require Unicode support solely for a "name"
> feature (which is, itself, optional and purely for the player's
> convenience.) 

Andrew's not the only lazy one here - in addition some of us still try to
support that ancient OS, MSDOS, and doing Unicode there is incredibly
messy.  It is marginally better under UNIX.

> > > Maximum length of 65 characters, say?
> >
> > Maybe make it a `recommended limit', with the obligatory blurb about
> > trimming somewhere appropriate and adding an ellipsis?
> 
> Yes. I don't think there's any reason for a mandatory limit.

Agreed.

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/


From ???@??? Sun Aug 02 14:27:31 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35C1E3AA.415C1F4C@dsres.com>
Date: Fri, 31 Jul 1998 16:32:58 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Game title in Blorb files
References: <Pine.SUN.4.02.9807310718110.3691-100000@netcom14>
Content-Type: text/plain; charset=iso-8859-1

X-Mime-Autoconverted: from 8bit to quoted-printable by mail.gmd.de id RAA28252
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: bd161348bf8fd2e4efdedfb578b9120d


Andrew Plotkin wrote:

> I think it's very silly to require Unicode support solely for a "name"
> feature (which is, itself, optional and purely for the player's
> convenience.)

OTOH, there's always the option of simply examining the characters and
replacing the ones you don't understand with `?' or somesuch. After all,
most interpreters probably have some sort of escaping mechanism for
Latin-1 characters if they can print transcripts...

How about the example that Kevin Stacey gave in his list of example
title chunks, `Zork I: Das Große Unterweltreich', where the title
contains a non-ASCII character?

> The ANNO (20-7E) format is already in both Blorb and Quetzal. It's
> deliberately a least-common-denominator format, so that absolutely
> everybody will be able to handle it. I think that's the right idea here.

The way I see it is that an interpreter which supports Blorb and story
names is probably quite a full-featured one, and doesn't really need
least-common-denominator handholding.

> the player should never be prevented from loading a save file if the names don't
> match. (Even if both are present.)

How about if the NAME chunk in a Quetzal file is only ever put there as
a direct copy of one in the Blorb file? This would probably be the
normal behaviour anyway.

--m


Type: TEXT/PLAIN; charset-ASCII
From ???@??? Sun Aug 02 14:31:23 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 16:39:49 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Game title in Blorb files
Message-Id: <1af9566e48%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <Pine.SUN.4.02.9807310718110.3691-100000@netcom14>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 68fa4a9ef1b5a072249933751cdd3e59


In message <Pine.SUN.4.02.9807310718110.3691-100000@netcom14>
          Andrew Plotkin <erkyrath@netcom.com> wrote:

> > 
> > Absolutely. Interpreters need to have some sort of Unicode handling
> > already.
> 
> Er, what? No they don't.

<Pantomime>
Oh yes they do!
</Pantomime>

> Unicode is optional.

Standard 1.0 requires you to at least understand the header Unicode table
to select ZSCII chars 155-252, and to be able to print_unicode the
alphabetic characters in U+0000 to U+00FF. Thus you must already have
a minimal mapping table from that part of Unicode to your native (probably
8-bit) chracter set. You can use this to decode the title. The code is
hardly mind-bending.

       zword_t *unicode_title;
       char *native_title;
       
       for (i = 0; i < name_len; i++)
       {
           if (unicode_title[i] < 0x100)
               native_title[i] = unicode_to_native_lookup[i];
           else
               native_title[i] = '?';
       }

Even simple interpreters like Frotz do at least that much.

> Yes, I'm the lazy one here,
> but I think it's very silly to require Unicode support solely for a "name"
> feature (which is, itself, optional and purely for the player's
> convenience.) 

What if you happen to have a German game with a German title? It would
be bizarre to have a VM that is capable of displaying German but not
giving the name of a game in German.

> 
> The ANNO (20-7E) format is already in both Blorb and Quetzal. It's
> deliberately a least-common-denominator format, so that absolutely
> everybody will be able to handle it. I think that's the right idea here.
> 

Yes, but Standard 1.0 has already gone beyond this
"least-common-denominator". It requires you to at least make an attempt
to display Unicode characters like "lower case u with diaeresis".

> > I don't think you actually want the interpreter to start comparing
> > strings though.
> 
> I agree. This is good for a warning, but the player should never be
> prevented from loading a save file if the names don't match. (Even if both
> are present.)

Absolutely.

> > [how long for the title?]
> Yes. I don't think there's any reason for a mandatory limit.

I concur. As long as you make clear that if it is too long it is likely
to be truncated with an ellipsis.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sun Aug 02 14:31:25 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 16:45:59 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Game title in Blorb files
Message-Id: <d089576e48%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <35C1E3AA.415C1F4C@dsres.com>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 33796f56c38f92a1a32dd02d4a64cc7a


In message <35C1E3AA.415C1F4C@dsres.com>
          Martin Frost <martin@dsres.com> wrote:

> > the player should never be prevented from loading a save file if the
> > names don't match. (Even if both are present.)
> 
> How about if the NAME chunk in a Quetzal file is only ever put there as
> a direct copy of one in the Blorb file? This would probably be the
> normal behaviour anyway.
> 

What if the user decides to change the name of the game (which would be
appearing in his list of games, perhaps) by modifying the Blorb file?
Unlikely, I suppose, but I don't think you want to prevent that sort
of thing.

I would personally only doing a comparison to tailor error responses
("this game belongs to X" as opposed to "this game belongs to a different
version of X"). I think that the release/serial number/checksum triple
is good enough to uniquely identify a game. It's unlikely enough that
two games with the same release number be produced on the same day (except
on one developer's machine), but then you've got a 1 in 65536 chance of
getting the checksums to match.

And you do somehow load a non-matching game by mistake, what's the worst that
can happen? The game gives a fatal error. A properly written Z-Machine VM
can't do any damage to the real machine (in theory :)

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sun Aug 02 14:31:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 09:06:18 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom14
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Game title in Blorb files
In-Reply-To: <35C1E3AA.415C1F4C@dsres.com>
Message-Id: <Pine.SUN.4.02.9807310858070.11472-100000@netcom14>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1

Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 94eb6ab148245214404f77638b7153ef


On Fri, 31 Jul 1998, Martin Frost wrote:

> How about the example that Kevin Stacey gave in his list of example
> title chunks, `Zork I: Das Große Unterweltreich', where the title
> contains a non-ASCII character?

Obviously you'd have to use an ASCII approximation. This is the down side.
 
> > The ANNO (20-7E) format is already in both Blorb and Quetzal. It's
> > deliberately a least-common-denominator format, so that absolutely
> > everybody will be able to handle it. I think that's the right idea here.
> 
> The way I see it is that an interpreter which supports Blorb and story
> names is probably quite a full-featured one, and doesn't really need
> least-common-denominator handholding.

Sound support is higher on my TODO list for MaxZip than Unicode. If/when I
get that far, MaxZip will support Blorb but not Unicode. It already
handles ANNO chunks in Quetzal files. Take that for whatever you like.

> > the player should never be prevented from loading a save file if the
> > names don't 
> > match. (Even if both are present.)
> 
> How about if the NAME chunk in a Quetzal file is only ever put there as
> a direct copy of one in the Blorb file? This would probably be the
> normal behaviour anyway.

I agree that would be normal behavior. I'm still not entirely happy with
using a human-readable string for a strict comparison. But I can't think
of a common case which will cause problems.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Sun Aug 02 14:31:29 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 17:30:50 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Game title in Blorb files
Message-Id: <b1a45b6e48%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <Pine.SUN.4.02.9807310858070.11472-100000@netcom14>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1

X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: eb7f0e0aa59d7fbe98133b5f71206de3


In message <Pine.SUN.4.02.9807310858070.11472-100000@netcom14>
          Andrew Plotkin <erkyrath@netcom.com> wrote:

> On Fri, 31 Jul 1998, Martin Frost wrote:
> 
> > How about the example that Kevin Stacey gave in his list of example
> > title chunks, `Zork I: Das Große Unterweltreich', where the title
> > contains a non-ASCII character?
> 
> Obviously you'd have to use an ASCII approximation. This is the down side.
>  

If a given interpreter can only display ASCII, let it approximate the
Unicode itself. By this logic we would say that Blorb should only allow
4-bit PNGs because some platforms can only do 16-colour displays :)
Approximating the Latin-1 range of Unicode to ASCII is far easier than
approximating 24-bit PNGs in a limited palette.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sun Aug 02 14:31:31 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35C1F2F0.79573967@dsres.com>
Date: Fri, 31 Jul 1998 17:38:08 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Game title in Blorb files
References: <d089576e48%kbracey@kbracey.acorn.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 82c162676b8ba93d9ff5baeb6e9747b9


Kevin Bracey wrote:

> > [comparing NAME chunks from savefile and story]

> What if the user decides to change the name of the game (which would be
> appearing in his list of games, perhaps) by modifying the Blorb file?
> Unlikely, I suppose, but I don't think you want to prevent that sort
> of thing.

Well, I suppose so. ;)

Once we've sorted this out, who's going to volunteer to write the script
to run Zip/Frotz on a whole load of games, parsing the banner thus
printed and wrapping the stories up in a Blorb file with the extracted
name?

--m


From ???@??? Sun Aug 02 14:31:34 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 31 Jul 1998 13:19:35 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199807311719.NAA27753@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Game title in Blorb files
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 09d28e6c88db8cbaa551869e3e6ac479



> The ANNO (20-7E) format is already in both Blorb and Quetzal. It's
> deliberately a least-common-denominator format, so that absolutely
> everybody will be able to handle it. I think that's the right idea here.

How about UTF-8?  Doesn't it look like regular ASCII when all the
characters in it are in the standard set?


From ???@??? Mon Aug 03 22:02:24 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 03 Aug 1998 10:09:59 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Game title in Blorb files
Message-Id: <79cabe6f48%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <199807311719.NAA27753@pond.com>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 112a23dd8e549c8a879c93df58d4d602


In message <199807311719.NAA27753@pond.com>
          "Matthew T. Russotto" <russotto@pond.com> wrote:

> 
> > The ANNO (20-7E) format is already in both Blorb and Quetzal. It's
> > deliberately a least-common-denominator format, so that absolutely
> > everybody will be able to handle it. I think that's the right idea here.
> 
> How about UTF-8?  Doesn't it look like regular ASCII when all the
> characters in it are in the standard set?

Yes, it does. But I'm not sure who's life you'd be making easier by using it.
Only tools that don't understand character encodings, which I don't think you
want to encourage.

Any naive tool on a Latin-1 system such as RISC OS or Windows is liable to
put in a German sharp-s as a $DF byte if the author's not awake, breaking the
UTF-8. The same tool would probably quite happily put that into the AUTH
chunk, although it's totally illegal.

If the data is UCS-2, then at least the author might be forced to pay
attention to character mapping issues, which is a general requirement of any
tool fiddling with Z-code.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Mon Aug 03 22:12:29 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35C58252.9C37A86A@dsres.com>
Date: Mon, 03 Aug 1998 10:26:42 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Game title in Blorb files
References: <199807311719.NAA27753@pond.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 44d3d4aa43cd6c74c9a75ba2e2b4f2c9


Matthew T. Russotto wrote:

> > The ANNO (20-7E) format is already in both Blorb and Quetzal. It's
> > deliberately a least-common-denominator format, so that absolutely
> > everybody will be able to handle it. I think that's the right idea here.

> How about UTF-8?  Doesn't it look like regular ASCII when all the
> characters in it are in the standard set?

When all characters are in the range 0x00 to 0x7F, yes.

I did consider suggesting this, although it still has difficulties.

UTF-8 is really intended to get around one of the problems with Unicode:
the increased size of the characters, and the inherent increased
storage/bandwidth requirements. Most Western text is mostly composed of
normal ASCII characters, perhaps with the odd 8-bit accent thrown in.
Instead of using two bytes for everything, UTF-8 allows just one byte
for the 7-bit characters, with two bytes for the 8-bit ones, and the
option of the full set if required.

It doesn't avoid the problem of what to do when there *are* extended
characters.

The reason Kevin Bracey suggested UCS-2 was that Unicode-compliant
interpreters must handle this format for characters anyway. It's also
the simplest format. Converting it to Latin-1 isn't difficult, either:
just ignore every other byte if they're zero, or insert a `?' or
suchlike if they're nonzero.

--m


From ???@??? Wed Aug 05 18:13:19 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 04 Aug 1998 14:04:52 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: [z-machine] GET_PROP_LEN 0
Message-Id: <ac21587048%kbracey@kbracey.acorn.co.uk>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ef54e4c5076fce6cb8f4a9993a01382f


Me again.

What should GET_PROP_LEN 0 return? My reading of the Standard says that
it's illegal, but I've just caught Shogun (322.89706) doing it.

This arose after I started making Zip 2000 a lot stricter about memory
accesses, which is of course just asking for trouble :)

If, as your first command, you say "STRAIGHTEN THE WHEEL", the following
piece of code gets executed:

 dc94:  GET_PROP_ADDR   L00,#20 -> L0b
 dc98:  GET_PROP_LEN    L0b -> -(SP)
 dc9b:  DIV             (SP)+,#02 -> L0c
 dc9f:  DEC_CHK         L08,#00 [TRUE] RTRUE
 dca3:  LOADW           L07,L08 >> L09
 dca7:  STORE           L06,L09
 dcaa:  JE              L09,"no.word" [TRUE] dc9f
 dcb1:  SCAN_TABLE      L06,L0b,L0c >> -(SP) [TRUE] dc9f
 dcb9:  JE              L06,"closed","shut" [FALSE] dcc6
 dcc1:  TEST_ATTR       L00,#11 [FALSE] dc9f
 dcc6:  JE              L06,"open" [FALSE] RET #FALSE
 dccc:  TEST_ATTR       L00,#11 [TRUE] dc9f
 dcd1:  RFALSE          

where L00 is the object number of the wheel (269, IIRC). The wheel
doesn't have property $20, so GET_PROP_ADDR returns 0. Zip 2000 1.30
then promptly aborts with "Attempt to access memory location &FFFFFFFF,
outside story file".

Logic, and this code, suggests that GET_PROP_LEN 0 should return 0.

Comments?

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Wed Aug 05 18:13:29 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 4 Aug 1998 09:01:02 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom16
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] GET_PROP_LEN 0
In-Reply-To: <ac21587048%kbracey@kbracey.acorn.co.uk>
Message-Id: <Pine.SUN.4.02.9808040841280.3751-100000@netcom16>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 3edc98777fb740b789a8b35bdc8a4d38


On Tue, 4 Aug 1998, Kevin Bracey wrote:

> What should GET_PROP_LEN 0 return? My reading of the Standard says that
> it's illegal, but I've just caught Shogun (322.89706) doing it.

Welcome to the wonderful world... As best I can figure, it's illegal, and
Shogun has a bug in it. 

The original ZIP source will behave unpredictably. It will try to read the
byte before the beginning of Z-machine memory, which is a malloced
chunk, so what you get depends on the malloc implementation.

My solution to this mess is to print a warning, *visible to the player*,
and then return zero. By default, such warnings are only printed once per
game session, so they don't interfere *too* much with the playing
experience. There are options to hide such warnings entirely, to show them
every time, and to treat them as fatal errors.

(However, I actually forgot to test for GET_PROP_LEN 0. Oops. I test for
GET_PROP_ADDR 0 and so on, but I missed that case. A note for the TODO
list.)
 
I think it would be a mistake to say that GET_PROP_LEN 0 is legal, and
always returns zero. That would effectively extend the spec and de-qualify
a lot of existing interpreters. I *don't* say that to coddle the
interpreter authors (I think they should *all* test these conditions, and
at the very least behave predictably!) But if it's legal, then more Inform
games will be written which *do* stuff like this. And then players with
older interpreters will encounter more crashes.

If we say it's illegal, and interpreters print warnings so that authors
*know* when they're doing something illegal, then future Inform games will
be more likely to adhere to the spec. (The spec we have now, I mean.)

BTW, I know I've posted this rant before (about GET_PROP_ADDR and so on)
and I'm sure you remember it. I apologize. I think this kind of thing is
important; it's the difference between a reliable software platform and an
unusable one.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Wed Aug 05 18:13:34 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 04 Aug 1998 17:39:36 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] GET_PROP_LEN 0
Message-Id: <62ca6b7048%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <Pine.SUN.4.02.9808040841280.3751-100000@netcom16>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 836e23a41166b9c7bd563f3b250453b3


In message <Pine.SUN.4.02.9808040841280.3751-100000@netcom16>
          Andrew Plotkin <erkyrath@netcom.com> wrote:

> On Tue, 4 Aug 1998, Kevin Bracey wrote:
> 
> > What should GET_PROP_LEN 0 return? My reading of the Standard says that
> > it's illegal, but I've just caught Shogun (322.89706) doing it.
> 
> Welcome to the wonderful world... As best I can figure, it's illegal, and
> Shogun has a bug in it. 

Ah, whether it is a bug from Infocom's point of view must surely depend
on what exactly Infocom's interpreters do... Welcome to the wonderful
world of inheriting someone else's VM without documentation :)

> My solution to this mess is to print a warning, *visible to the player*,
> and then return zero. By default, such warnings are only printed once per
> game session, so they don't interfere *too* much with the playing
> experience. There are options to hide such warnings entirely, to show them
> every time, and to treat them as fatal errors.

Zip 2000 is a lot harsher about diagnostics at present - anything illegal
is fatal. I should probably work on that, but I'm not terribly tolerant
of anyone doing naughty things...

> 
> (However, I actually forgot to test for GET_PROP_LEN 0. Oops. I test for
> GET_PROP_ADDR 0 and so on, but I missed that case. A note for the TODO
> list.)
>  
> I think it would be a mistake to say that GET_PROP_LEN 0 is legal, and
> always returns zero. That would effectively extend the spec and de-qualify
> a lot of existing interpreters. I *don't* say that to coddle the
> interpreter authors (I think they should *all* test these conditions, and
> at the very least behave predictably!) But if it's legal, then more Inform
> games will be written which *do* stuff like this. And then players with
> older interpreters will encounter more crashes.

I see what you're saying. But on the other hand, most interpreters at
present will not be visibly faulting it anyway, so I don't think we would be
making the situation much worse. And every Standard change de-qualifies
existing interpreters, doesn't it?

My personal view is that we should be guided by Infocom's interpreters. If
they definitely return 0, then that's what Standard 1.1 (or whatever) should
say, but with a proviso that older interpreters may not do this, so game
authors shouldn't rely on it.

If Infocom's interpreters are unpredictable, then yes, Shogun has a bug. I
would suggest then that a Standard interpreter should return 0 if playing
Shogun, otherwise output a diagnostic and return what you like.

Don't forget that the Standard is equally for interpreter authors as well as
game authors. It should document any dubious things that Infocom games do
otherwise people like me end up finding these things out the hard way.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Wed Aug 05 18:13:37 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 4 Aug 1998 17:12:07 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] GET_PROP_LEN 0
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <ac21587048%kbracey@kbracey.acorn.co.uk>
Message-Id: <Marcel-1.46-0804161207-0b0M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.46]
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: b787c363638313acf17e7322f5c69ba4


On Tue 04 Aug, Kevin Bracey wrote:
> Me again.
> 
> What should GET_PROP_LEN 0 return? My reading of the Standard says that
> it's illegal, but I've just caught Shogun (322.89706) doing it.

Thereby hangs a tale.  Early releases of Inform relied on
get_prop_len returning 0, because the .# operator, as in,

   x = spell_book.#spell_list;

was supposed to return 0 if the object didn't possess the given
property.  On some versions of Zip and ITF, this does indeed
work.  These days Inform would compile

    obj.#identifier

as:

    1  +0001f     get_prop_addr obj identifier -> TEMP1 
    1  +00023     jz           TEMP1 to L1 if TRUE
    1  +00027     get_prop_len TEMP1 -> TEMP1 
    1  +0002a    .L1

(well, actually it compiles .# to something much more
complicated in Inform 6, but this is the interesting part).
Since get_prop_addr definitely does return 0 if the property
doesn't exist, the above code is protected against this
contigency.  In short, no Inform-compiled game can ever produce
the "bad" case except by the direct result of the author's
folly in using assembly language.

Personally I would prefer the standard to require that

   get_prop_len 0
   
returns 0, since it's not a time-critical operation and why
not be safe rather than sorry.  At the time we made the decision
on this, I'm pretty sure we didn't know about Shogun's behaviour
requiring it.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Wed Aug 05 18:14:01 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Tue, 04 Aug 1998 19:02:18 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: [z-machine] SNam chunk proposal
Message-Id: <8e5c737048%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <35C58252.9C37A86A@dsres.com>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 2a4053ffe21a18f2ffb9fe475f1c80ad

In message <35C58252.9C37A86A@dsres.com>
          Martin Frost <martin@dsres.com> wrote:

> Matthew T. Russotto wrote:
>=20
> > How about UTF-8?  Doesn't it look like regular ASCII when all the
> > characters in it are in the standard set?
>
> The reason Kevin Bracey suggested UCS-2 was that Unicode-compliant
> interpreters must handle this format for characters anyway. It's also
> the simplest format. Converting it to Latin-1 isn't difficult, either:
> just ignore every other byte if they're zero, or insert a `?' or
> suchlike if they're nonzero.
>=20

Okay. Here's a definite proposal for a new chunk, for both Blorb and
Quetzal.

* Contents of the Story Name Chunk

    4 bytes         'SNam'          chunk ID
    4 bytes         n*2             chunk length
    n 16-bit words  ...             story name

This chunk contains UCS-2 text, in network byte order (most significant
byte first). Characters U+0000 to U+001F and U+007F to U+009F are
prohibited. The only indication of the length of this text is the
chunk length (there is no zero word termination as in C, for example).

The 'SNam' chunk, if present, contains the name of the story file
associated with or embedded in a Blorb file.

A Quetzal file may contain an 'SNam' chunk giving the name of the game it=

belongs to. This should be either copied from the SNam chunk of the story=
's
Blorb file, or deduced by some other means (such as a database of serial
numbers built in to the interpreter that saved the file). In a Quetzal fi=
le,
SNam must precede the IFhd chunk if present.

An interpreter might use this information when presenting a menu of games=
,
in the title of its window, or to display more helpful error messages suc=
h
as:

   'This save file belongs to "Jigsaw"'
   'This save file was created by a different version of "Christminster"'=

   =20
An interpreter must not rely on string comparisons of SNam chunks - it
is acceptable to load a Quetzal file for "Fred" into "Jim", as long as th=
e
IFhd chunk matches. A string comparison is permitted to distinguish betwe=
en
the two error cases above, as that is purely cosmetic.

There is no absolute limit on the length of the SNam chunk, but writers
should use their common sense, and readers should truncate with an
ellipsis or suchlike if necessary.

Note that as control codes are not permitted in the SNam chunk, there is =
no
way of putting a new-line in. If you want to put a new-line in the SNam
chunk, you're using it wrongly.

It is suggested that the contents of the SNam chunk should be the name
displayed as bold in a a game's start up banner. This is the setting of t=
he
constant "Story" in a game created using the Inform library.

Here are some examples of good SNam chunk contents:

    Jigsaw
    Zork I: The Great Underground Empire
    Zork I: Das Gro=DFe Unterweltreich
    The Path to Fortune - Volume One of "The Windhall Chronicles"
    So Far
    Border Zone
    Nord and Bert Couldn't Make Head or Tail of It

--=20
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk=
/

From ???@??? Tue Aug 11 16:45:53 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35C82C34.BEB4A35D@dsres.com>
Date: Wed, 05 Aug 1998 10:56:04 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] SNam chunk proposal
References: <8e5c737048%kbracey@kbracey.acorn.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d5b7907898252d2a01fde3e0b2755cf2


Kevin Bracey wrote:

> Okay. Here's a definite proposal for a new chunk, for both Blorb and
> Quetzal.

[...]

I like it, and if there are no objections I'll happily incorporate it
into the Quetzal document.

Incidentally, does anyone have any other changes they'd like in the next
version of the Quetzal document? Any new extension chunk types?

--m


From ???@??? Tue Aug 11 16:45:55 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 5 Aug 1998 06:24:51 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom6
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] SNam chunk proposal
In-Reply-To: <8e5c737048%kbracey@kbracey.acorn.co.uk>
Message-Id: <Pine.SUN.4.02.9808050619390.25840-100000@netcom6>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 6ce84960eb53ace432fd1d6c5a5750ed


On Tue, 4 Aug 1998, Kevin Bracey wrote:

> * Contents of the Story Name Chunk
> 
>     4 bytes         'SNam'          chunk ID
>     4 bytes         n*2             chunk length
>     n 16-bit words  ...             story name
> 
> This chunk contains UCS-2 text

I'm happy enough with this proposal. Go for it. If nobody else squeaks,
I'll add this to the Blorb document next week. (I'm going to be away from
Thursday to Sunday, or I'd do it sooner.)

Martin Frost:
> Incidentally, does anyone have any other changes they'd like in the next
> version of the Quetzal document? Any new extension chunk types?

Nothing has come to mind. Do you have a definitive set of test files on
your web site yet? :)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."




From ???@??? Tue Aug 11 16:45:57 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35C874B1.6A12563@dsres.com>
Date: Wed, 05 Aug 1998 16:05:21 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] SNam chunk proposal
References: <Pine.SUN.4.02.9808050619390.25840-100000@netcom6>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 037ac9a56b5ec92dad830934f47a1f71


Andrew Plotkin wrote:

> > Incidentally, does anyone have any other changes they'd like in the next
> > version of the Quetzal document? Any new extension chunk types?

> Nothing has come to mind. Do you have a definitive set of test files on
> your web site yet? :)

Er...

I'm working on it.

The web page is actually going to move soon, as GeoCities is getting
steadily worse wrt speed and filling every page with popup adverts. It
was always intended to be `temporary' at GeoCities. The new address will
be <http://www.users.redvan.net/~dougal/>, although it hasn't actually
moved yet.

I'll probably get the test files out just in time for everyone to have
already tested their Quetzal support. ;)

--m


From ???@??? Tue Aug 11 16:46:00 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 5 Aug 1998 13:19:40 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom4
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] GET_PROP_LEN 0
In-Reply-To: <62ca6b7048%kbracey@kbracey.acorn.co.uk>
Message-Id: <Pine.SUN.4.02.9808051310271.10306-100000@netcom4>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a251b4d40b31d8aeb56c410b4bb6d868


On Tue, 4 Aug 1998, Kevin Bracey wrote:

> Ah, whether it is a bug from Infocom's point of view must surely depend
> on what exactly Infocom's interpreters do... Welcome to the wonderful
> world of inheriting someone else's VM without documentation :)

No kidding.

The question is *our* point of view, though, and that includes all the
interpreters used by the IF community. With the usual weighting factors of
their rate of use, how likely they are to be upgraded... sigh.
 
> > My solution to this mess is to print a warning, *visible to the player*,
> > and then return zero. By default, such warnings are only printed once per
> > game session, so they don't interfere *too* much with the playing
> > experience. There are options to hide such warnings entirely, to show them
> > every time, and to treat them as fatal errors.
> 
> Zip 2000 is a lot harsher about diagnostics at present - anything illegal
> is fatal. I should probably work on that, but I'm not terribly tolerant
> of anyone doing naughty things...

I agree. Unfortunately nearly all Inform games contain these errors,
right? 

The only time I've seen this cause a crash (on an unprotected ZIP engine)
is Silenius Mysterium last year. But I have a gut feeling that it causes
noticeable numbers of flaky, here-and-gone-again errors during game
development. 
 
> I see what you're saying. But on the other hand, most interpreters at
> present will not be visibly faulting it anyway

...most of the time, but could crash. That bothers me a lot.

> so I don't think we would be
> making the situation much worse. And every Standard change de-qualifies
> existing interpreters, doesn't it?

Yes, if it has no provision for backward compatibility.

There have been very few such changes. Certainly I think there should be
as few as possible. 
 
> My personal view is that we should be guided by Infocom's interpreters. If
> they definitely return 0, then that's what Standard 1.1 (or whatever) should
> say, but with a proviso that older interpreters may not do this, so game
> authors shouldn't rely on it.

I agree with this. 

My impression is that Infocom's released interpreters do almost no
error-checking of this sort. That implies to me that their *in-house*
interpreters did lots and lots, simply because the game files contain so
few errors.

This also means that we should be guided by Infocom's game files as well
as their interpreters... of course, as we know, neither were perfect. 
 
> Don't forget that the Standard is equally for interpreter authors as well as
> game authors.

> It should document any dubious things that Infocom games do
> otherwise people like me end up finding these things out the hard way.

Document everything, but be careful what we legitimize.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Tue Aug 11 16:46:27 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 06 Aug 1998 09:51:20 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] SNam chunk proposal
Message-Id: <4a97487148%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <35C82C34.BEB4A35D@dsres.com>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 78c9927eb7944d6bcaa1782626edab9e


In message <35C82C34.BEB4A35D@dsres.com>
          Martin Frost <martin@dsres.com> wrote:

> 
> Incidentally, does anyone have any other changes they'd like in the next
> version of the Quetzal document? Any new extension chunk types?
> 

I'd like some IntD stuff for RISC OS, as follows (section numbers
as per version 1.4):

[operating system ID]
7.19.4          'RISC'          RISC OS

[interpreter ID]
7.20.2          '2000'          Zip 2000, by Kevin Bracey

[extension chunk]
7.21.2          'RISC'          '    '          0               7.23

[extension chunk description]
7.23	The following chunk has been registered for RISC OS, to enable a
	RISC OS interpreter to find a story file given a save file. The path
        name is be of variable size: the actual size can be calculated from
        the chunk size. It is not zero-terminated. The pathname will only be
        valid on the same machine, or possibly network, on which the file was
        saved. If present, this chunk must appear before IFhd.

7.22.1		4 bytes		'IntD'		chunk ID
7.22.2		4 bytes		n		chunk length (variable)
7.22.3		4 bytes		'RISC'		operating system ID: RISC OS
7.22.4		1 byte		00000010	flags (s set; c clear)
7.22.5		1 byte		0		contents ID
7.22.6		2 bytes		0		reserved
7.22.7		4 bytes		'    '		interpreter ID: any
7.22.8		n-12 bytes	...		canonical pathname of the 
                                                story file

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Tue Aug 11 16:46:31 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35C9884A.CE45B2D4@dsres.com>
Date: Thu, 06 Aug 1998 11:41:14 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] SNam chunk proposal
References: <4a97487148%kbracey@kbracey.acorn.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d5ab29f01b3807b3ff94d49ffb37e286


Kevin Bracey wrote:

> I'd like some IntD stuff for RISC OS, as follows [...]

OK. I'll add it to the spec.

I'd also like to propose the following:

A new operating system ID of `URL ', for any system capable of handling
URLs.

A new chunk:

	4 bytes		'IntD'		chunk ID
	4 bytes		n+12		chunk length
	4 bytes		'URL '		system ID: URL-capable
	1 byte		00000000	flags
	1 byte		0		contents ID
	2 bytes		0		reserved
	4 bytes		'    '		interpreter ID: any
	n bytes		...		an absolute URL of the story file,
					as defined by RFC1738.

The purpose of this chunk is to allow a system capable of handling URLs
to find the story file associated with a given saved game file. The URL
must be a full absolute URL (relative URLs are not permitted), must not
contain the optional fragment anchor, and the protocol must be one
capable of transferring story files. HTTP and FTP would be good choices.

[end of proposal]

This chunk would be useful for interpreters written in Java, for
example.

--m


From ???@??? Fri Aug 14 15:22:17 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35D2E165.67FA1413@dsres.com>
Date: Thu, 13 Aug 1998 13:51:49 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Quetzal update
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a3a54af6c84c81c6f3550940924fcf37


The Quetzal web page has now moved to its new location:

	http://www.users.redvan.net/~dougal/

The main thing of interest on there at the moment is version 1.5 of the
Quetzal document.

Changes from version 1.4 are as follows:

	`SNam' chunk added.
	`RISC', `URL ' system IDs added.
	`2000' interpreter ID added.
	`RISC'/`    '/0 extension chunk added.
	`URL '/`    '/0 extension chunk added.
	New web page and email address.
	Various cosmetic changes including removal of typos.

None of these affect correct existing implementations.

I'd also like to update the list of interpreters released with Quetzal
support. Currently I have the following:

	MaxZip v1.7.0 (Macintosh; problems with release 6 games)
	Zip Infinity v1.4b1 (Macintosh; problems with V3 games)
	Zip 2000 v1.30 (RISC OS)
	ZPlet (Java; problems with V3 games)

These version numbers are the earliest I know with some kind of support.
I'd also like to know the earliest with *reliable* support (without the
known problems mentioned above).

If there any additions or changes (such as different version numbers),
please let me know.

Thanks in advance,

--m


From ???@??? Fri Aug 14 15:22:20 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 13 Aug 1998 06:28:43 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom14
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Quetzal update
In-Reply-To: <35D2E165.67FA1413@dsres.com>
Message-Id: <Pine.SUN.4.02.9808130624300.27987-100000@netcom14>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: c45adf64249c7e87eddffd0920fcd0ae


On Thu, 13 Aug 1998, Martin Frost wrote:

> I'd also like to update the list of interpreters released with Quetzal
> support. Currently I have the following:
> 
> 	MaxZip v1.7.0 (Macintosh; problems with release 6 games)
> 	Zip Infinity v1.4b1 (Macintosh; problems with V3 games)
> 	Zip 2000 v1.30 (RISC OS)
> 	ZPlet (Java; problems with V3 games)
> 
> These version numbers are the earliest I know with some kind of support.
> I'd also like to know the earliest with *reliable* support (without the
> known problems mentioned above).

MaxZip 1.7.4 fixed the release-6 bug but still had the V3 bug.
MaxZip 1.7.5 fixed the V3 bug. Quetzal support should be reliable from
this point on.
It's now up to MaxZip 1.7.6. 

XZip 1.8 supports Quetzal reliably, as far as I know. (And is the first
version that does so.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Fri Aug 14 15:22:28 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <Mutt.19980813084213.jholder@io.frii.com>
Date: Thu, 13 Aug 1998 08:42:13 -0600
From: jholder@frii.com (J. Holder)
To: martin@dsres.com (Martin Frost), z-machine@gmd.de
Subject: Re: [z-machine] Quetzal update
References: <35D2E165.67FA1413@dsres.com>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <35D2E165.67FA1413@dsres.com>; from Martin Frost on Aug 13, 1998 13:51:49 +0100
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 50e6f534949166ed2be1ee00d8312cae


Martin Frost writes:
> I'd also like to update the list of interpreters released with Quetzal
> support. Currently I have the following:
> 
> 	MaxZip v1.7.0 (Macintosh; problems with release 6 games)
> 	Zip Infinity v1.4b1 (Macintosh; problems with V3 games)
> 	Zip 2000 v1.30 (RISC OS)
> 	ZPlet (Java; problems with V3 games)

Jzip 2.0.2 beta release 05271998 or later supports Quetzal. 

ObGrumble:
So I'm a bit slow.  I also work 10-12 hours a day most days... 
-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/


From ???@??? Fri Aug 21 18:58:20 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 17 Aug 1998 09:21:16 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom13
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] URL chunk proposal
In-Reply-To: <35C9884A.CE45B2D4@dsres.com>
Message-Id: <Pine.SUN.4.02.9808170914210.7604-100000@netcom13>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: e3861176f6098012d745772c49ff1228


I have no opinion on whether this should be IntD or top-level.

However, a nitpicky thought:

On Thu, 6 Aug 1998, Martin Frost wrote:

> The purpose of this chunk is to allow a system capable of handling URLs
> to find the story file associated with a given saved game file.

Do we allow for the case where the contents of a URL change? For
example, many game files will have their URL at gmd.de, like
'ftp://ftp.gmd.de/games/infocom/whatever.z5'. But there's no versioning
system at gmd, so new releases replace old releases at the same URL.

I don't think this is a big problem, as long as interpreters do the
usual header-chunk test after the URL is loaded. But it should be pointed
out. 

Actually this applies to platform-specific methods of finding the game
file, as well. Never assume the game file you found is really the version
you think it is. (Even Mac aliases can be fooled, if you drag a new Mac
file on top of an old one and replace it. :-)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Fri Aug 21 18:58:51 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35D860EF.DB19E0C8@dsres.com>
Date: Mon, 17 Aug 1998 17:57:19 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] URL chunk proposal
References: <Pine.SUN.4.02.9808170914210.7604-100000@netcom13>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a11538ddbcb93d580ef5185459ce0032


> Actually this applies to platform-specific methods of finding the game
> file, as well. Never assume the game file you found is really the version
> you think it is. (Even Mac aliases can be fooled, if you drag a new Mac
> file on top of an old one and replace it. :-)

Well, I'd sort of assumed that this was a matter of common sense for
interpreter writers. I'll add it anyway.

--m


From ???@??? Fri Aug 21 18:59:33 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 17 Aug 1998 16:11:15 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Quetzal update
Message-Id: <bf91157748%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <35D81FA3.5C516ACA@dsres.com>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a5484c41b23bede2b155bcfe014ce0d5


In message <35D81FA3.5C516ACA@dsres.com>
          Martin Frost <martin@dsres.com> wrote:

> Kevin Bracey wrote:
> > Why not just make it a 'URL ' primary chunk?
> 
> Logically, the system ID *should* be empty. However, an earlier version
> of the document specifically prohibits both IDs being empty, as this
> ought to be a new primary chunk. However, I'm opposed to adding new
> primary chunks for `extension' data only likely to be of value to a few
> systems. I suppose that URLs are sufficiently `universal' that a new
> chunk would be OK, but it somehow seems mismatched that some methods of
> accessing the story file go in an IntD chunk, and some in a primary
> chunk.

I don't think it's that strange, as long as you are happy with the
"universal"/"system-dependent" split. Some methods of finding the
story file will be universal, others will be system dependent. Yes, the
first two methods of finding the source file happened to be in 'IntD', but
that's because they were interpreter-dependent, not because "finding the
story file" is logically something that should be in 'IntD'.

> 
> OK, so that argument is circular. Anyone want me to change things?
> 
> Really, the IntD chunk should be called `Ext ' or something.
> 

All new top-level chunks are by definition "extension" data, because in an
IFF file all unknown chunks are ignored (unlike PNG where you have the
critical/auxiliary chunk distinction).

I'd say that 'URL ' has just as much right to be a top-level chunk as
'SNam' or 'ANNO'.

Sorry I didn't speak out on this when it was proposed - I was on holiday
all last week.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Fri Aug 21 18:59:35 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35D81FA3.5C516ACA@dsres.com>
Date: Mon, 17 Aug 1998 13:18:43 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Quetzal update
References: <17a7fe7648%kbracey@kbracey.acorn.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: a17070146a3307a89fe578fc54961c06


Kevin Bracey wrote:
> In message <35D2E165.67FA1413@dsres.com>
>           Martin Frost <martin@dsres.com> wrote:

> >       `URL '/`    '/0 extension chunk added.

> Call me picky, but shouldn't this logically be '    '/'    '/0? Even
> stronger, perhaps, could I suggest that this isn't interpreter or
> operating system-dependant, so shouldn't be part of 'IntD'?

> Why not just make it a 'URL ' primary chunk?

Logically, the system ID *should* be empty. However, an earlier version
of the document specifically prohibits both IDs being empty, as this
ought to be a new primary chunk. However, I'm opposed to adding new
primary chunks for `extension' data only likely to be of value to a few
systems. I suppose that URLs are sufficiently `universal' that a new
chunk would be OK, but it somehow seems mismatched that some methods of
accessing the story file go in an IntD chunk, and some in a primary
chunk.

OK, so that argument is circular. Anyone want me to change things?

Really, the IntD chunk should be called `Ext ' or something.

> Zip 2000 v1.30 is believed reliable - I'm not sure what the problems
> above are referring to (I did my Quetzal from scratch because I wasn't
> online to nick the Zip patches that weekend). I still haven't found a
> test suite...

There were a variety of problems with early Quetzal implementations (the
three earliest were Matthew Russotto's for ZPlet and Zip Infinity, and
mine for generic Zip). My patches had a few bugs in, and hence
interpreters using them (such as MaxZip) were not considered `reliable'
in early versions, until the bugs were fixed. There was also a problem
with the 1.3 document that made it very difficult to generate correct
savefiles for all version 3 story files.

If you've written your implementation from scratch or used recent
patches, this doesn't affect you.

Test suite is coming, really... Up till now, the best attempt at a test
suite was a set of example files saved by all known Quetzal-compliant
interpreters. However, this was withdrawn after the `known problems'
were discovered, and has not as yet been repaired and reinstated.

--m


From ???@??? Fri Aug 21 18:59:38 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <35D85663.F19F32B5@dsres.com>
Date: Mon, 17 Aug 1998 17:12:19 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Quetzal update
References: <bf91157748%kbracey@kbracey.acorn.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 32e4b881043c41b11a9e5c8048902cae


Kevin Bracey wrote:

> I'd say that 'URL ' has just as much right to be a top-level chunk as
> 'SNam' or 'ANNO'.

I'm happy to change this if it won't upset anyone else.

Anyone want to complain?

--m


From ???@??? Fri Aug 21 18:59:41 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 17 Aug 1998 12:00:57 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Quetzal update
Message-Id: <17a7fe7648%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <35D2E165.67FA1413@dsres.com>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 9ffa9faf62c19b84de2ee29037ca11ca


In message <35D2E165.67FA1413@dsres.com>
          Martin Frost <martin@dsres.com> wrote:

> 	`URL '/`    '/0 extension chunk added.

Call me picky, but shouldn't this logically be '    '/'    '/0? Even
stronger, perhaps, could I suggest that this isn't interpreter or
operating system-dependant, so shouldn't be part of 'IntD'?

Why not just make it a 'URL ' primary chunk?

> These version numbers are the earliest I know with some kind of support.
> I'd also like to know the earliest with *reliable* support (without the
> known problems mentioned above).

Zip 2000 v1.30 is believed reliable - I'm not sure what the problems
above are referring to (I did my Quetzal from scratch because I wasn't
online to nick the Zip patches that weekend). I still haven't found a
test suite...

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Tue Aug 25 17:05:29 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 21 Aug 1998 13:33:02 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: [z-machine] Zip 2000 and PNG
Message-Id: <866d167948%kbracey@kbracey.acorn.co.uk>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 5a91e4eadfdb00d4f272ad7d680911bf


Just to whet everyone's appetite, I've placed a screen shot from my
current working copy of Zip 2000 on my home page. It demonstrates the
alpha-compositing ability of PNG rather nicely.

The Blorb file there may be a useful test for some people as well.

    See it at http://www.acorn.co.uk/~kbracey/

The PNG-supporting release of Zip 2000 is imminent - it will probably
be uploaded to the IF-archive on Monday, all being well. I'll be releasing
source at the same time.

Unfortunately, we still need to do some work to get the Infocom V6 games
into Blorb - none of Jason Penney's V6 test files (except possibly Journey)
work as they stand, because of two issues:

  1) They don't contain the null placeholder images (Jason should fix
     this soon).
  2) There is no way to represent the paletteless images in the original
     .MG1 files in Blorb.
     
The second issue needs discussion. My proposal is that paletted PNGs with a
zero-length PLTE chunk should be permitted. Use of a zero-length PLTE chunk
is something that is proposed for PNGs embedded in MNG files to use the
global palette, so this seems fairly reasonable.

The only issue is where we get the PLTE to use instead from - we need a
scheme that works with the Infocom games. The Zip 2000 scheme up until now
for .MG1 graphics has always been "use the palette of the last image
plotted".

Experimentation so far has shown that "use the palette of the last image
decoded", where an image is decoded when picture_table is called or when an
image not in the last picture_table is drawn, seems to work just as well, and
is probably technically easier.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Tue Aug 25 17:05:34 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 21 Aug 1998 08:33:03 -0700 (PDT)
From: Andrew Plotkin <erkyrath@netcom.com>
X-Sender: erkyrath@netcom17
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Zip 2000 and PNG
In-Reply-To: <866d167948%kbracey@kbracey.acorn.co.uk>
Message-Id: <Pine.SUN.4.02.9808210831080.25709-100000@netcom17>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: ae975feb3a8d68e710b700aa58b3e2af


On Fri, 21 Aug 1998, Kevin Bracey wrote:

>   2) There is no way to represent the paletteless images in the original
>      .MG1 files in Blorb.
>      
> The second issue needs discussion. My proposal is that paletted PNGs with a
> zero-length PLTE chunk should be permitted. Use of a zero-length PLTE chunk
> is something that is proposed for PNGs embedded in MNG files to use the
> global palette, so this seems fairly reasonable.
> 
> The only issue is where we get the PLTE to use instead from - we need a
> scheme that works with the Infocom games. The Zip 2000 scheme up until now
> for .MG1 graphics has always been "use the palette of the last image
> plotted".
> 
> Experimentation so far has shown that "use the palette of the last image
> decoded", where an image is decoded when picture_table is called or when an
> image not in the last picture_table is drawn, seems to work just as well, and
> is probably technically easier.

Argh, argh, *crap*. I didn't know about this issue. 

Is it possible to go through Infocom's images and statically assign a
palette to each? Or are there really images whose colors shift depending
on when they're used?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Tue Aug 25 17:05:36 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Fri, 21 Aug 1998 16:54:58 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Zip 2000 and PNG
Message-Id: <23ea287948%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <Pine.SUN.4.02.9808210831080.25709-100000@netcom17>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: da1533f10908cf41e0486e5d2c035caa


In message <Pine.SUN.4.02.9808210831080.25709-100000@netcom17>
          Andrew Plotkin <erkyrath@netcom.com> wrote:

> 
> Argh, argh, *crap*.

Quite :)

> 
> Is it possible to go through Infocom's images and statically assign a
> palette to each? Or are there really images whose colors shift depending
> on when they're used?
> 

Some of them are purely design limitations of the 16-colour displays they
were to be run on. For example, Arthur's big banner image (the thing
surrounding the view picture), has no palette, so would change with
the image being displayed, often in a rather ugly fashion. A few images like
that could have a static palette assigned.

Unfortunately though, a lot of images are designed to be properly adaptive.
The best example is Zork Zero's compass rose, which appears in the correct
colour depending on the border in use.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Tue Aug 25 17:06:19 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 24 Aug 1998 09:59:56 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: [z-machine] Zip 2000 source uploaded
Message-Id: <ca6c8e7a48%kbracey@kbracey.acorn.co.uk>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: d34d3ee8dc70e678ba7ab74a75443e28


For those who are interested, the source to Zip 2000 version 1.32 has
been uploaded to the IF-archive. Get yours at:

   ftp://ftp.gmd.de/incoming/if-archive/Zip2000_Source_132.tar.gz
   
This version has full PNG support and low-quality Audio IFF support (it's
still using the same playback routines as it used to for the Infocom
sounds, so it's restricted to 8-bit mono).

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Tue Aug 25 17:06:28 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Mon, 24 Aug 1998 13:42:00 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199808241742.NAA25476@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Zip 2000 and PNG
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 847cf4f25a3e91b1ec3a316577114c0a


} Is it possible to go through Infocom's images and statically assign a
} palette to each? Or are there really images whose colors shift depending
} on when they're used?

Arthur has images whose colors shift.  Zork Zero, also, if I'm not
mistaken.



From ???@??? Thu Aug 27 19:04:05 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Wed, 26 Aug 1998 15:11:18 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: [z-machine] Mouse button numbering
Message-Id: <ba9ab27b48%kbracey@kbracey.acorn.co.uk>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 8247d13a2b06e1ee1a8c704a6c1ad594


I'm not happy with the Specification's current numbering of mouse buttons.

It states

   READ_MOUSE <array>
   
   The four words in the array are written with the mouse
   y coordinate, x coordinate, button bits (low bits on the right of the
   mouse, rising as one looks left), and a menu word.

RISC OS has a three-button mouse: SELECT, MENU, ADJUST (from left to
right), so I made Zip 2000 has passed these through to the game as
SELECT=bit 1, ADJUST=bit 0 (MENU is not passed to the game; it brings up
Zip 2000's menu).

Unfortunately, this is useless to anyone trying to use the mouse. I found
this out when I had the bright idea in my Parrot.blb test file
(see http://www.acorn.co.uk/~kbracey/Zip2000/parrot.html) of making
SELECT draw a toucan, and ADJUST draw a square.

In portable terms, that would mean the "primary" mouse button draws the
toucan, and the "secondary" mouse button draws the square (although you
shouldn't assume that the system has more than one mouse button, so you'd
have an alternate way of getting this functionality).

But which is the "primary" mouse bit? On Zip 2000 it's bit 1 - on a Mac it
might be bit 0. I think we need to define this better. Where did this
definition come from? Are these bits read by any Infocom games? What do other
interpreters do? The only use of READ_MOUSE I can find is the menu reading in
Journey, which doesn't look at the button bits.

It would work if bit 15 was the primary mouse button, then work down,
or if bit 0 was the primary mouse button, then work up.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Thu Aug 27 19:56:29 1998
Return-Path: owner-z-machine@mail2.gmd.de
Message-Id: <3.0.5.32.19980827192124.00816390@pop.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 27 Aug 1998 19:21:24 +1200
To: Kevin Bracey <kbracey@acorn.com>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Mouse button numbering
Cc: z-machine@gmd.de
In-Reply-To: <ba9ab27b48%kbracey@kbracey.acorn.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 03236bac649579e713e23d407adb7f29


At 15:11 26/08/98 +0100, Kevin Bracey wrote:
>
>I'm not happy with the Specification's current numbering of mouse
buttons.
[...]
>It would work if bit 15 was the primary mouse button, then work
down,
>or if bit 0 was the primary mouse button, then work up.

Perhaps a slight modification; on IBM computers you can have mice
either with a central button or without.  It seems to me that the
best definition would be to have bit 0 for the primary button, bit 1
for the central button, bit 2 for the secondary button, and other
bits if more buttons exist.  If a computer doesn't have a centre
button, then bit 1 will never be set.  Therefore the only button
guaranteed to work is the primary one and game authors should design
accordingly.  (In addition, there could also be some way for the game
to detect how many buttons are available and act accordingly -- on
most computers this can be a fixed value, on others like the IBM they
can just ask the mouse driver.)

Another possibility is to abandon the physical relationship, and just
designate bit 0 as primary, bit 1 as secondary, bit 2 and tertiary,
and so on, with the user able to designate as they wish.  On standard
three-button systems the left will be primary, right secondary, and
centre tertiary, but the order could be different on a left-handed
system.  Personally, I think this option is best.

Just my $0.01 (exchange rate... very bad)

-- 
Gavin Lambert
uecasm@geocities.com
http://ue.home.ml.org/
Mirabilis ICQ UIN: 2274180  (check out www.mirabilis.com)
Fight spam!  Support an email amendment at http://www.cauce.org/

----
If nothing ever sticks to Teflon, how do they make Teflon stick to
the pan?

Hofstadter's Law:
It always takes longer than you expect, even when you take
Hofstadter's Law into account.

If debugging is the process of removing bugs, then programming must
be the process of putting them in.
----

The above quotes have been randomly selected from a huge list.
I apologize if you find some of them offensive.


From ???@??? Thu Aug 27 21:16:39 1998
Return-Path: owner-z-machine@mail2.gmd.de
Date: Thu, 27 Aug 1998 09:43:37 +0100
From: Kevin Bracey <kbracey@acorn.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Mouse button numbering
Message-Id: <9170187c48%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <3.0.5.32.19980827192124.00816390@pop.ihug.co.nz>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: fa81c9cde61846444bb8f006119b7c80


In message <3.0.5.32.19980827192124.00816390@pop.ihug.co.nz>
          Gavin Lambert <uecasm@geocities.com> wrote:

> 
> Another possibility is to abandon the physical relationship, and just
> designate bit 0 as primary, bit 1 as secondary, bit 2 and tertiary,
> and so on, with the user able to designate as they wish.  On standard
> three-button systems the left will be primary, right secondary, and
> centre tertiary, but the order could be different on a left-handed
> system.  Personally, I think this option is best.
> 

That's my feeling exactly - but the question remains: why does the
spec say what it does? What games/interpreters were disassembled to
get these mappings?

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Sat Aug 29 14:14:52 1998
Return-Path: owner-z-machine@mail2.gmd.de
From: "David Turnbull" <dpt@newsguy.com>
To: <z-machine@gmd.de>
Subject: RE: [z-machine] Mouse button numbering
Date: Fri, 28 Aug 1998 14:35:14 -0500
Message-Id: <000001bdd2ba$fa9a2d00$b1a37095@rabbit.ae.usr.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <9170187c48%kbracey@kbracey.acorn.co.uk>
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-z-machine@mail2.gmd.de
Precedence: bulk
X-UIDL: 24fb916f54044e52d70dabef469e891b




> > Another possibility is to abandon the physical relationship, and just
> > designate bit 0 as primary, bit 1 as secondary, bit 2 and tertiary,
> > and so on, with the user able to designate as they wish.  On standard
> > three-button systems the left will be primary, right secondary, and
> > centre tertiary, but the order could be different on a left-handed
> > system.  Personally, I think this option is best.
> >
>
> That's my feeling exactly - but the question remains: why does the
> spec say what it does? What games/interpreters were disassembled to
> get these mappings?

My Win98 and my Linux machine both have a button on the side, which
functions like a button in the middle would.  This would make the physical
relationship setup even more dubious.  Macs and pen computing devices won't
easily be able to do more than one button.

When someone figures this out, let me know if a tap on a pen device should
send anything other than bit 0.

-david


From ???@??? Mon Jan 18 09:43:49 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Thu, 14 Jan 1999 01:01:30 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Proposal for a proposal for Version 9
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.46]
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 34642fe02f99443ec31660722a8ce829



The summer and autumn of 1999 mark the twentieth anniversary
of the creation of the Z-machine, when two would-be Infocom
programmers, Joel Berez and Marc Blank, were stranded in Pittsburgh
and passed the time by trying to find a way to squash "Zork" onto
a personal computer.

The following proposal might serve as one way to mark the occasion,
if it finds favour: I suggest that it is now time to create
Version 9.

The proposal I'm making here is at a very informal stage indeed.
Perhaps I might begin with a meta-proposal: a way to conduct
whatever discussions we have about "Version 9", if we choose to
construct one.  Please excuse my rudeness in electing myself
chairman of our committee, so to speak.

  (a) We try above all to agree, and in particular to persuade
      interpreter-writers that a proposed change is worth their
      while.  Conversely, we listen to them if they say that it's
      harder than it looks.
  (b) We make minimal changes, which require minimal work to
      implement, given what they must accomplish.
  (c) We address genuine needs rather than trying to build some
      Platonic ideal of the Z-machine.  In particular, there is
      no need to build Lord Dimwit Flathead the Excessive's
      Version Infinity.
  (d) We consider that other languages besides Inform may one day
      want to compile to the Z-machine.

The two "genuine needs" which I feel are pressing are:

  (1) The limit on story file size (512K to 640K), and above all
      on the size of writeable memory (64K).  Story file
      authors are actually having to go to some lengths to
      get around these limits, and especially the latter one,
      where people are actually writing Inform libraries to
      compress arrays as bitmaps, rotate things in and out of
      lower memory, etc.

  (2) Less pressing, and arguably my own fault, but for reasons
      to do with Inform's typelessness I would like it to be
      possible to distinguish between a number and an object
      at run-time.  (As it is in some other object-oriented
      virtual machines, notably those for Smalltalk and Java.)
      At present the Inform doctrine is that:
          routines, static strings, Z-machine objects and classes
             are "objects" and can be mutually distinguished,
          numbers, characters, arrays, actions, dictionary words,
             etc., etc., are not objects and cannot.
      This is anomalous and unsatisfactory, not just for the
      puritanical reason that it makes the language less "clean"
      than it should be -- though heaven knows, that's true --
      but because it's very hard to write code that can
      satisfactorily print something out in a useful way.

Both of these issues have arisen in work on the new "Infix"
feature for Inform 6.21 (he said mysteriously).

There are clearly other issues which _might_ be addressed,
such as (3) an increase in the number of attributes or (4) an
increase of the maximum number of local and global variables.
I am quite reluctant to go too far down the road of meddling
with everything, though.

Here is my minimal proposal to address (1) and (2), and which has
the fringe benefit of improving Z-machine arithmetic.


1. Version 9 should have a flat 32-bit memory model, thus raising
both limits in (1) above to roughly 1 gigabyte.  All addresses
would be byte addresses, and the formula to convert a packed
routine or string address P to a byte address A would just be
A := P.

2. Everything that is now a 2-byte word should become a 4-byte
word.  In particular, variables and the stack hold 4-byte values.
Minimum stack capacity (in bytes) is doubled to accommodate this.
The opcodes @storew and @loadw work in 4-byte increments, in
that

   @loadw X Y -> Z

would set Z to the 4-byte value at byte address X+4*Y, rather
than the 2-byte value at byte address X+2*Y as at present.
The long operand type holds a 4-byte value, not a 2-byte one.
Some of the Z-machine tables need similar alterations: e.g.
the table of default property values.

Lastly, the header and header extension table are "doubled"
in the sense that what is currently at byte X would in future
be in the byte at 2*X.  What is currently at the 2-byte word
at X, X+1 would in future be a 4-byte word at 2*X, 2*X+1,
2*X+2, 2*X+3.

3. The upper byte of a 4-byte value should be allowed to
contain information about its type, but the Z-machine shouldn't
get involved in whether it does or how it does.  The only
provisions are these:

   (a) the 5 arithmetic opcodes calculate with signed 31-bit
       numbers and always store values with top bit zero.
   (b) when an operand is "used", meaning that the Z-machine
       uses the value to do something rather than simply
       copies it across to a new location (e.g. the stack,
       a variable, an array entry), the following happens:
           if the top bit is set, then the top 8 bits
           are ignored and only the bottom 24 used as the
           value.

For instance, @loadw X Y -> ... "uses" both X and Y.
@storew X Y Z "uses" X and Y but doesn't use Z, which it simply
copies to the new location.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Mon Jan 18 09:43:59 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Wed, 13 Jan 1999 21:03:43 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199901140203.VAA27581@pond.com>
To: graham@gnelson.demon.co.uk, z-machine@gmd.de
Subject: Re:  [z-machine] Proposal for a proposal for Version 9
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 069567f8e10bbe08f19d6ab7db7af027


32-bit memory map, good.  Tagging values with the high bits, bad.
Also it restricts your memory map to 31 bits.  Better solution... I dunno..

Other limitations that should be addressed-- # of properties,
attributes, etc should be increased.  I'd probably add a header byte
setting the number of bytes used for attributes, letting it be
effectively unlimited.  # of properties can be increased to 256 or
65536  -- in the latter case I'd suggest a property list format which
allowed for a binary search of the property list.  I'd also throw out
all the bit-twiddling oddity of the current property list format, but that
may be just prejudice because it gave me fits in ZPlet.  

(I'd like to replace the opcode structure, but that's out of scope)


From ???@??? Mon Jan 18 09:44:01 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901140238.VAA24431@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Wed, 13 Jan 1999 21:38:45 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v3.01b)
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5d3f9f9001c17c90ad8bdb4c4d72f475


Graham Nelson sent a message across the ether on 14 Jan 99, (1:01) stating:

> The summer and autumn of 1999 mark the twentieth anniversary
> of the creation of the Z-machine, when two would-be Infocom
> programmers, Joel Berez and Marc Blank, were stranded in Pittsburgh
> and passed the time by trying to find a way to squash "Zork" onto
> a personal computer.
> 
> The following proposal might serve as one way to mark the occasion,
> if it finds favour: I suggest that it is now time to create
> Version 9.

I'd just like to suggest that if this goes ahead, it would also be nice 
to have a Version 10 (or 9a) that is basically V6 + V9 enhancements.  
While it would be nice to 'fix' V6 up a bit at the same time it seems 
that V6 as it stands is more than enough work on it's own, but if  
an interpreter supported V6 and V9 it would seem that combining the two 
would be semi-trivial (maybe I'm way off the mark, I don't know).

Of course you all knew that would be my suggestion anyway.

Later,
Jay





Infix now!
:-)

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor


From ???@??? Mon Jan 18 09:44:12 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <MqbLDte00UwD0tXmI0@andrew.cmu.edu>
Date: Wed, 13 Jan 1999 23:35:05 -0500 (EST)
From: Evin C Robertson <ecr+@andrew.cmu.edu>
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>
References: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: e5a9bbc5237d1c560a4e2f5142963369


Well, these are some ideas I've had while (admittedly slowly) working on
my own interpreter.  They should make very large games possible and
allow interpreters to run faster and be built more easily.  The added
space overhead is minimal, unlike going to 32 bit everything.  The
effort of changing existing interps to use 32 bits would probably be
easier than changing them to this, though (at least in my interp).  If
we go to 32 bits, probably people would need separately compiled
interpreters - one for 16 bit games and one for 32 bit games.

For better or worse, this document doesn't address differentiating
numbers and objects.  Feel free to ignore if none of this makes any
sense.

A lot of stuff could be moved out of the first 64K of memory.  Object
tables, global variables, the dictionary, property defaults, and
abbreviations.  This would leave properties, arrays, and various grammar
tables in low memory.

Where would we move all this stuff?  To high memory.

High memory is also currently limited.  We could number each routine and
string consecutively and use a table to decode addresses.

So high memory starts with a table of 32 bit addresses.  First come the
objects, then the routines, then the strings.  Perhaps a few numbers at
the beginning of this list to allow bounds checking on illegal values.

Routines and strings are held as would be expected at the specified
offsets.  Strings should begin at even offsets (not very difficult to
do, and allows fetching strings two bytes at a time on some computers). 
Routines have no alignment requirement.

At each object address, put the attributes, parent, sibling, and child
as normal.  Then give the short name of the object and a property
offset.  Followed by property numbers in ascending order (I suggest 16
bit).  A length byte will be at the property offset (in low memory),
followed by the first property, followed by another length byte, etc.

This scheme gets rid of the need for individual property tables, allows
fast searches, is fairly compatible with existing code, and minimizes
low memory use.  The objects' data would not be directly manipulatable,
but would be used using the normal object opcodes.

It would be illegal to attempt to call a string or object, to print a
routine or object, or to use a string or routine as an object.  Because
of this, the interpreter is free to do anything it wants with upper
memory structures, including decode strings, change byte ordering of
object tables, etc.

Global variables, property default tables, the abbreviation table, and
the main dictionary should all be held in upper memory; a packed by 8
offset will be given in the normal places in the header, so these must
occur somewhere in the lower 512kb of z-machine memory.  Like objects
and strings, these could all be decoded at load time.

Because the dictionary is not directly accessible, the extra data put in
each entry must be stored elsewhere.  Because of this, instead of
writing the address of the word in the dictionary, the interpreter will
write the number of the word ((word address - dictionary_offset) /
entry_length).  The extra data will be stored somewhere inform sees fit.

At save time, since the object tables in high memory may have changed,
to save, the interpreter will need to scan high memory for changes as
well as low memory.  Because the PC could be greater than 2^24, the
quetzal format would have to be changed to allow larger return addresses
in the stack frame.

The initial PC will be stored as a routine number, similar to v6.

This leaves property data (plus one size byte per property), arrays, and
various grammar junk in low memory, none of which can be removed easily.

People will have to work pretty hard to exceed 65535 objects, routines,
and strings (0 is reserved for object zero and empty calls).  Low memory
will still fill up.  Games at least 3 times as large as the current
largest could be written in this format.  Other than inform changes and
a few library changes, existing games should compile to this unmodified.

I'm sure I've overlooked several problems, and this seems fairly complex
already, so, anyway... whatever.


While I'm here, does anybody know what's up with the variable form of
2OP instructions?  Is this ever used in any case other than je?  If so,
what, and if not, what was infocom smoking at the time?  And despite the
claims of the zspec ("The Inform 6 assembler can generate every legal
opcode"), inform will not assemble "@je a ?blah" even though it's an
example.


From ???@??? Mon Jan 18 09:44:22 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Wed, 13 Jan 1999 23:24:06 -0800 (PST)
From: "Jakob 'sparky' Kaivo" <jake@nodomainname.net>
To: Jason C Penney <jpenney@chelmsford.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <199901140238.VAA24431@ns.chelmsford.com>
Message-Id: <Pine.LNX.4.04.9901132320520.19420-100000@elijah.nodomainname.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5855cc6d0d667291e070924ab4f8970f


Why bother having to do that? It makes much more sense (IMHO) to
incorporate the features of V6 that would go into V9a (or whatnot)
directly into V9 (perhaps with some flags that can be set to
enable/disable certain features). That doesn't necessarily mean that V9
interpreters would automatically be able to run V6 code, but could after a
recompile.

On Wed, 13 Jan 1999, Jason C Penney wrote:

> Graham Nelson sent a message across the ether on 14 Jan 99, (1:01) stating:
> 
> > The summer and autumn of 1999 mark the twentieth anniversary
> > of the creation of the Z-machine, when two would-be Infocom
> > programmers, Joel Berez and Marc Blank, were stranded in Pittsburgh
> > and passed the time by trying to find a way to squash "Zork" onto
> > a personal computer.
> > 
> > The following proposal might serve as one way to mark the occasion,
> > if it finds favour: I suggest that it is now time to create
> > Version 9.
> 
> I'd just like to suggest that if this goes ahead, it would also be nice 
> to have a Version 10 (or 9a) that is basically V6 + V9 enhancements.  
> While it would be nice to 'fix' V6 up a bit at the same time it seems 
> that V6 as it stands is more than enough work on it's own, but if  
> an interpreter supported V6 and V9 it would seem that combining the two 
> would be semi-trivial (maybe I'm way off the mark, I don't know).
> 
> Of course you all knew that would be my suggestion anyway.
> 
> Later,
> Jay
> 
> 
> 
> 
> 
> Infix now!
> :-)
> 
> ----
> Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
> <http://www.chelmsford.com/home/jpenney/>
> "The trouble with computers of course, is that they're very 
> sophisticated idiots."     -- The Doctor
> 

+-----------------------------+--------------------------------+
| Jakob 'sparky' Kaivo        |          jake@nodomainname.net |
| NoDomainName Networks       |    http://www.nodomainname.net |
| AtDot E-mail Services       |           http://www.atdot.org |
+-----------------------------+--------------------------------+


From ???@??? Mon Jan 18 09:44:56 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <Mutt.19990114143824.jholder@io.frii.com>
Date: Thu, 14 Jan 1999 14:38:24 -0700
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
References: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>; from Graham Nelson on Jan 14, 1999 01:01:30 +0100
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 653213091bc2e33e9e2688216e94e12a




I personally like Graham's suggestions.  I would add two more 
features I would like to have:

- A new opcode that can dynamically allocate memory.  (Yes, I know this
  is not trivial.  And I am not proposing how we should do so)

- Floating point math opcodes (if we are doing 32bit everything, we can use
  the ISO floating point spec)

Although neither of these are really necessary, and the former is more
useful than the latter.

John

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/


From ???@??? Mon Jan 18 09:44:58 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Thu, 14 Jan 1999 23:16:07 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Message-Id: <19990114231607.A9462@bartlet.df.lth.se>
References: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>; from Graham Nelson on Thu, Jan 14, 1999 at 01:01:30AM +0100
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 0382c5dce9b64751dc841d8f30b02068


On Thu, Jan 14, 1999 at 01:01:30AM +0100, Graham Nelson wrote:
> The following proposal might serve as one way to mark the occasion,
> if it finds favour: I suggest that it is now time to create
> Version 9.

Hear, hear!

Perhaps we shouldn't too conservative; I'd like to interpret "minimal
changes" as "minimal changes to the processor model and opcode
structure".  That is, let's not be afraid to add new features or
change old ones as long as that changes - both to compilers and to
interpreters - are local.

We should also consider whether new features should best go in the
Z-machine or in the library. John Holder has for example suggested the
addition of floating-point opcodes; I think that FP should be
implemented as library functions instead since they're rather
peripheral to the current uses of the Z machine and floating-point
performance doesn't seem the most critical point right now.


I have two ideas which I'd like your feedback on:

1) Automated translation of .z5 into .z9 (perhaps to enable
interpreter writers to concentrate on one version, or just as a neat
hack). Do you think there'd be any demand for this? And how hard would
it be?

2) If we move to 32-bit addressing, there shouldn't be so much need
to compress the game text. So what about getting rid of the compressed
Z strings and store all strings with one character per byte? This would
greatly simplify the writing of efficient string-manipulation routines;
perhaps we could finally get the 'print (A) item;' syntax we've been
missing for so long?

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Mon Jan 18 09:45:01 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Thu, 14 Jan 1999 19:50:21 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199901150050.TAA12269@pond.com>
To: mol@df.lth.se, z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 53b2a38b76e8c61669fbd6f83c75a8b6


>From owner-z-machine@omega.gmd.de  Thu Jan 14 17:22:55 1999
Date: Thu, 14 Jan 1999 23:16:07 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Message-Id: <19990114231607.A9462@bartlet.df.lth.se>
References: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk>; from Graham Nelson on Thu, Jan 14, 1999 at 01:01:30AM +0100
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
Status: R

On Thu, Jan 14, 1999 at 01:01:30AM +0100, Graham Nelson wrote:

} 2) If we move to 32-bit addressing, there shouldn't be so much need
} to compress the game text. So what about getting rid of the compressed
} Z strings and store all strings with one character per byte? This would
} greatly simplify the writing of efficient string-manipulation routines;
} perhaps we could finally get the 'print (A) item;' syntax we've been
} missing for so long?

This is a major change, but if we're going to do it I suggest UTF-8
(Java's variant) rather than ASCII or ISO-Latin-Anything.  And I'd
suggest removing the "print_ret" and "print" opcodes, moving all
constant strings to the end (allowing them to be compressed in storage
-- I think the main reason TADS games are so much larger than Inform
games is that TADS uses uncompressed text and then makes matters worse
by permuting it in a way that interferes with compression).

Maybe this should wait until V10.  I think the idea now is to lift the
restrictions authors are running into without other major changes.

Some questions:

Do we retain the 3-part scheme of dynamic memory, static memory, and
high memory?  Or do we reduce it to dynamic and static?  Or to just
"memory".  I'm partial to retaining at least dynamic and static --
just maybe we can make this large program continue to fit in small
machines.

How about operands?  There's currently "large constant", "small
constant" and "variable".  Presumably "large constant" now becomes a
32-bit number.  How about small constant?  16 bits or 8?  How about
variable?  Are there still 256 variables?

Unfortunately I accidentally deleted the original message, and don't
recall what load, store, etc, need to do. 


From ???@??? Mon Jan 18 09:45:29 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 07:37:01 -0500 (EST)
From: Mark J Musante <olorin@world.std.com>
Reply-To: Mark J Musante <olorin@world.std.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <19990114231607.A9462@bartlet.df.lth.se>
Message-Id: <Pine.SGI.3.95.990115073348.26793B-100000@world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 2f6fb7b003022d022efa37997639ed85


On Thu, 14 Jan 1999, Magnus Olsson wrote:
> 2) If we move to 32-bit addressing, there shouldn't be so much need
> to compress the game text. So what about getting rid of the compressed
> Z strings and store all strings with one character per byte? This would
> greatly simplify the writing of efficient string-manipulation routines;
> perhaps we could finally get the 'print (A) item;' syntax we've been
> missing for so long?

I'd like to see *some* form of encryption.  Also, one byte per char would
eliminate unicode.


  -=- Mark -=-



From ???@??? Mon Jan 18 09:45:36 1999
Return-Path: owner-z-machine@omega.gmd.de
From: katre <katre@mousetrap.c64.org>
Message-Id: <199901151344.IAA02190@mousetrap.c64.org>
Subject: Re: [z-machine] Proposal for a proposal for Version 9
To: jake@nodomainname.net (Jakob 'sparky' Kaivo)
Date: Fri, 15 Jan 1999 08:44:18 -0500 (EST)
Cc: z-machine@gmd.de
In-Reply-To: <Pine.LNX.4.04.9901141409370.2143-100000@elijah.nodomainname.net> from "Jakob 'sparky' Kaivo" at Jan 14, 99 02:12:23 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 3282029835578fd650d2818b213ffd16


> 
> Well, what I was thinking, really, was that there could be flags set in
> the header that could be read by the interpreter, so that there could be
> things like V9 with the graphics flag on, V9 with the graphics flag off,
> flags for sound, etc. This way there is just one new object code format,
> and the interpreter could just report error messages such as:
> 
> This is a V9 zcode file with the graphics flag on. Graphics aren't
> supported by this interpreter.
> 
> Or something similar.
> 

Yes, but with so few games (currently) using the V6 opcodes, wouldn't it be
best to leave them out of V9, especially if it is just an update to V5-8?  I
fully support an updated V6, but I don't think that mixing the two would be
trivial.

katre

> On Thu, 14 Jan 1999, katre wrote:
> 
> > [ Jason's proposal for V9a, or 10, snipped].
> > 
> > > 
> > > Why bother having to do that? It makes much more sense (IMHO) to
> > > incorporate the features of V6 that would go into V9a (or whatnot)
> > > directly into V9 (perhaps with some flags that can be set to
> > > enable/disable certain features). That doesn't necessarily mean that V9
> > > interpreters would automatically be able to run V6 code, but could after a
> > > recompile.
> > > 
> > 
> > Well, if we add the full graphical interface to the new V9, then _any_
> > interpreter that doesn't do graphics (i.e. DOS and curses frotz) can't ever be
> > compliant.  Also, since many (most?) games don't use those opcodes, it's silly
> > to force the interpreter to worry about them.  I do, however, like the idea of
> > updating the graphical version to also be full 32-bit (or whatever we decide).
> > 
> > katre
> > 
> 
> +-----------------------------+--------------------------------+
> | Jakob 'sparky' Kaivo        |          jake@nodomainname.net |
> | NoDomainName Networks       |    http://www.nodomainname.net |
> | AtDot E-mail Services       |           http://www.atdot.org |
> +-----------------------------+--------------------------------+
> 


From ???@??? Mon Jan 18 09:45:38 1999
Return-Path: owner-z-machine@omega.gmd.de
From: katre <katre@mousetrap.c64.org>
Message-Id: <199901151342.IAA02175@mousetrap.c64.org>
Subject: Re: [z-machine] Proposal for a proposal for Version 9
To: z-machine@gmd.de
Date: Fri, 15 Jan 1999 08:42:02 -0500 (EST)
In-Reply-To: <Mutt.19990114143824.jholder@io.frii.com> from "J. Holder" at Jan 14, 99 02:38:24 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5e73e4e9929531c8ce7cf4e11528d05e


> 
> - A new opcode that can dynamically allocate memory.  (Yes, I know this
>   is not trivial.  And I am not proposing how we should do so)
> 

The best way to do dynamic memory is not with an opcode.  This would require
the z-machine to be aware of what parts of the memory are being used, for
what, and would add a lot of z-machine overhead.  I'm definitely in support of
dynamic memory allocation, but I beleive it should be part of a library, and
most likely based on zarf's code from Lists, i.e. a large array, that library
functions can allocate and collect later.

katre


From ???@??? Mon Jan 18 09:45:40 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <Mutt.19990115082000.jholder@io.frii.com>
Date: Fri, 15 Jan 1999 08:20:00 -0700
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
References: <199901150050.TAA12269@pond.com>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <199901150050.TAA12269@pond.com>; from Matthew T. Russotto on Jan 14, 1999 19:50:21 -0500
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5a24a66028c498c860a4f0f4a4bdea8b


Matthew T. Russotto writes:
> On Thu, Jan 14, 1999 at 01:01:30AM +0100, Graham Nelson wrote:
> 
> } 2) If we move to 32-bit addressing, there shouldn't be so much need
> } to compress the game text. So what about getting rid of the compressed
> } Z strings and store all strings with one character per byte? This would
> } greatly simplify the writing of efficient string-manipulation routines;
> } perhaps we could finally get the 'print (A) item;' syntax we've been
> } missing for so long?
> 
> This is a major change, but if we're going to do it I suggest UTF-8
> (Java's variant) rather than ASCII or ISO-Latin-Anything.  
[snip]

UTF-8 Sounds good.  The Java interpreters writers would sure be happy...

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/


From ???@??? Mon Jan 18 09:45:43 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <gqbphD600UwD06PH40@andrew.cmu.edu>
Date: Fri, 15 Jan 1999 10:14:23 -0500 (EST)
From: Evin C Robertson <ecr+@andrew.cmu.edu>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Cc: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Pine.LNX.4.04.9901132320520.19420-100000@elijah.nodomainname.net>
References: <Pine.LNX.4.04.9901132320520.19420-100000@elijah.nodomainname.net>
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: b54033cdbe348669a005751d2dc8fa49


Excerpts from mail: 13-Jan-99 Re: [z-machine] Proposal fo.. by Jakob '.
Kaivo@nodomainn 
> Why bother having to do that? It makes much more sense (IMHO) to
> incorporate the features of V6 that would go into V9a (or whatnot)
> directly into V9 (perhaps with some flags that can be set to
> enable/disable certain features). That doesn't necessarily mean that V9
> interpreters would automatically be able to run V6 code, but could after a
> recompile.

v6 is very complex and allowing it in v9 disallows interpreters from
doing a lot - scrolling, changing fonts, resizing the window, etc.  Too
much trouble for too little gain.

Excerpts from mail: 14-Jan-99 Re: [z-machine] Proposal fo.. by Magnus
Olsson@df.lth.se 
>1) Automated translation of .z5 into .z9 (perhaps to enable
>interpreter writers to concentrate on one version, or just as a neat
>hack). Do you think there'd be any demand for this? And how hard would
>it be?

In the general case, this is nearly impossible.  In the case of most
inform compiled games, it is only incredibly difficult.  All data and
code would be located at new offsets, and in order to determine what
should go where, you have to perform an entire, accurate disassembly of
the game.  There are a bunch of other problems, such as games which rely
on overflow working as they expect, which means you have to mask all
arithmetic operations.  In addition, I don't think there are any
platforms z9 could run on to which z5 hasn't yet been ported.  You
really wouldn't want to do this anyway, as moving to 32 bit would
greatly increase the size of the games with no visible gain.

Excerpts from mail: 15-Jan-99 Re: [z-machine] Proposal fo.. by Mark J
Musante@world.std 
>I'd like to see *some* form of encryption.  Also, one byte per char would
>eliminate unicode.

Not any more than the current compressed string type; zscii only handles
8 bit text (section 3.8.1), though you can map unicode characters into
it (section 3.8.5).  I'd asume uncompressed strings would be subject to
the same rules.

z-machine text compression is excessively evil and not very good, but
interpreters already have it implemented.


From ???@??? Mon Jan 18 09:45:45 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <Mutt.19990115081307.jholder@io.frii.com>
Date: Fri, 15 Jan 1999 08:13:07 -0700
From: jholder@frii.com (J. Holder)
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
References: <Marcel-1.46-0114000130-d07M+4%@gnelson.demon.co.uk> <19990114231607.A9462@bartlet.df.lth.se>
X-Mailer: Mutt 0.57
Mime-Version: 1.0
In-Reply-To: <19990114231607.A9462@bartlet.df.lth.se>; from Magnus Olsson on Jan 14, 1999 23:16:07 +0100
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 8ea7bd3ca24d9f1bdc4033a602255494


Magnus Olsson writes:
> On Thu, Jan 14, 1999 at 01:01:30AM +0100, Graham Nelson wrote:
> We should also consider whether new features should best go in the
> Z-machine or in the library. John Holder has for example suggested the
> addition of floating-point opcodes; I think that FP should be
> implemented as library functions instead since they're rather
> peripheral to the current uses of the Z machine and floating-point
> performance doesn't seem the most critical point right now.

Okay, I'll continue working on my float library... (grin)

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/


From ???@??? Mon Jan 18 09:45:48 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 07:39:49 -0800 (PST)
From: "Jakob 'sparky' Kaivo" <jake@nodomainname.net>
To: Mark J Musante <olorin@world.std.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <Pine.SGI.3.95.990115073348.26793B-100000@world.std.com>
Message-Id: <Pine.LNX.4.04.9901150735040.15081-100000@elijah.nodomainname.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 1140f2148b30967cb4a0171823d7fd63


On Fri, 15 Jan 1999, Mark J Musante wrote:

> I'd like to see *some* form of encryption.  Also, one byte per char would
> eliminate unicode.
> 
> 
>   -=- Mark -=-

I would most definitely *NOT* like there to be any encryption in the Z
machine. This would place unnecessary constrictions on it (e.g. concerns
about exporting from U.S. or Waasenaar (sp?) agreement countries).

+-----------------------------+--------------------------------+
| Jakob 'sparky' Kaivo        |          jake@nodomainname.net |
| NoDomainName Networks       |    http://www.nodomainname.net |
| AtDot E-mail Services       |           http://www.atdot.org |
+-----------------------------+--------------------------------+


From ???@??? Mon Jan 18 09:45:50 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 11:32:26 -0500 (EST)
From: Mark J Musante <olorin@world.std.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <Pine.LNX.4.04.9901150735040.15081-100000@elijah.nodomainname.net>
Message-Id: <Pine.SGI.3.95.990115113045.1710A-100000@world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: ce7fbc54c3a359ce2ce3417034134da8


On Fri, 15 Jan 1999, Jakob 'sparky' Kaivo wrote:
> On Fri, 15 Jan 1999, Mark J Musante wrote:
> > I'd like to see *some* form of encryption.  Also, one byte per char would
> > eliminate unicode.
>
> I would most definitely *NOT* like there to be any encryption in the Z
> machine. This would place unnecessary constrictions on it (e.g. concerns
> about exporting from U.S. or Waasenaar (sp?) agreement countries).

You misunderstand.  I'm not talking about DES or something similar.  I'm
talking about munging the characters enough so that casual browsing won't
reveal the text.


  -=- Mark -=-


From ???@??? Mon Jan 18 09:46:06 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 10:10:09 -0800 (PST)
From: "Jakob 'sparky' Kaivo" <jake@nodomainname.net>
To: Mark J Musante <olorin@world.std.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <Pine.SGI.3.95.990115113045.1710A-100000@world.std.com>
Message-Id: <Pine.LNX.4.04.9901151009440.18040-100000@elijah.nodomainname.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 9068df6feac71b5ba79f543f2bac452b


Yes, I misunderstood. Obfuscation or munging is a better term, and a good
idea.

On Fri, 15 Jan 1999, Mark J Musante wrote:

> On Fri, 15 Jan 1999, Jakob 'sparky' Kaivo wrote:
> > On Fri, 15 Jan 1999, Mark J Musante wrote:
> > > I'd like to see *some* form of encryption.  Also, one byte per char would
> > > eliminate unicode.
> >
> > I would most definitely *NOT* like there to be any encryption in the Z
> > machine. This would place unnecessary constrictions on it (e.g. concerns
> > about exporting from U.S. or Waasenaar (sp?) agreement countries).
> 
> You misunderstand.  I'm not talking about DES or something similar.  I'm
> talking about munging the characters enough so that casual browsing won't
> reveal the text.
> 
> 
>   -=- Mark -=-
> 

+-----------------------------+--------------------------------+
| Jakob 'sparky' Kaivo        |          jake@nodomainname.net |
| NoDomainName Networks       |    http://www.nodomainname.net |
| AtDot E-mail Services       |           http://www.atdot.org |
+-----------------------------+--------------------------------+


From ???@??? Mon Jan 18 09:46:08 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 11:25:27 -0700
From: Matt Kimball <robozapp@xmission.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Message-Id: <19990115112527.A20799@xmission.xmission.com>
References: <Pine.SGI.3.95.990115073348.26793B-100000@world.std.com> <Pine.LNX.4.04.9901150735040.15081-100000@elijah.nodomainname.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <Pine.LNX.4.04.9901150735040.15081-100000@elijah.nodomainname.net>; from Jakob 'sparky' Kaivo on Fri, Jan 15, 1999 at 07:39:49AM -0800
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 1b280c2c0efbe461c6fb2975c859c0b3


On Fri, Jan 15, 1999 at 07:39:49AM -0800, Jakob 'sparky' Kaivo wrote:
> On Fri, 15 Jan 1999, Mark J Musante wrote:
> 
> > I'd like to see *some* form of encryption.  Also, one byte per char would
> > eliminate unicode.
> > 
> > 
> >   -=- Mark -=-
> 
> I would most definitely *NOT* like there to be any encryption in the Z
> machine. This would place unnecessary constrictions on it (e.g. concerns
> about exporting from U.S. or Waasenaar (sp?) agreement countries).

s/encryption/obfuscation/

-- 
Matt Kimball
mkimball@xmission.com


From ???@??? Mon Jan 18 09:46:10 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 10:25:40 -0800
Message-Id: <199901151825.KAA00738@app.dial.idiom.com>
From: Almohad Petrofsky <Almohad@petrofsky.berkeley.ca.us>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=NIL
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: df4619402dbda8fedd81710bd6e4ce4b


katre <katre@mousetrap.c64.org> sez:
> The best way to do dynamic memory is not with an opcode.  This would require
> the z-machine to be aware of what parts of the memory are being used, for
> what, and would add a lot of z-machine overhead.  I'm definitely in support of
> dynamic memory allocation, but I beleive it should be part of a library, and
> most likely based on zarf's code from Lists, i.e. a large array, that library
> functions can allocate and collect later.

I agree that the equivalent of malloc and free should be in the
library, but the equivalent of unix brk, which malloc occasionally
uses to ask the OS for more memory, would be a sensible opcode.  If
you're writing a text editor, you don't want to have a 1 Meg array
bloating the executable just so the user can occasionally edit a 1 Meg
file.

brk would simply take an address and set the new end of the memory map
to be at that address, thereby increasing or decreasing the space
available to the game.  The interpreter would implement this by
calling realloc, which in turn might call the real brk (or your OS's
equivalent).  You'll want this allocated memory to be writable of
course, so unfortunately you'd have two disjoint writable segments,
but that's not too bad.  (If we were designing from scratch, we'd
switch the order of read-only and writable memory, so that brk would
be adding on memory contiguous to the writable segment.)

Matthew T. Russotto writes:
> } 2) If we move to 32-bit addressing, there shouldn't be so much need
> } to compress the game text. So what about getting rid of the compressed
> } Z strings and store all strings with one character per byte? This would
> } greatly simplify the writing of efficient string-manipulation routines;
> } perhaps we could finally get the 'print (A) item;' syntax we've been
> } missing for so long?
> 
> This is a major change, but if we're going to do it I suggest UTF-8
> (Java's variant) rather than ASCII or ISO-Latin-Anything.  

But UTF-8 is a variable-length code, so it doesn't much simplify the
writing of efficient string-manipulation routines, which is why java
does not use UTF-8 for in-memory strings (it uses strings of 16-bit
chars).  To save file space, java stores strings in UTF-8 in the
object code, and expands them when the code is loaded.  Because the
format of our executable is a straight memory-map, we can't really do
that.

Magnus Olsson writes:
> On Thu, Jan 14, 1999 at 01:01:30AM +0100, Graham Nelson wrote:
> We should also consider whether new features should best go in the
> Z-machine or in the library. John Holder has for example suggested the
> addition of floating-point opcodes; I think that FP should be
> implemented as library functions instead since they're rather
> peripheral to the current uses of the Z machine and floating-point
> performance doesn't seem the most critical point right now.

Besides run-time efficiency (both time and space), the advantage to
making opcodes is that they would place a trivial burden on most
(all?) interpreter-writers, because they have floating-point available
to them (either in hardware or an already-written library), but
creating a z-code library for them is a big painful project (although
jholder doesn't seem to mind).  Important to ease and efficiency of
implementation would be to follow C's example and *not* specify IEEE
or any particular format, thereby allowing the interpreter-writer to
just use whatever he's got.

-al


From ???@??? Mon Jan 18 09:46:14 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 10:46:06 -0800
Message-Id: <199901151846.KAA00877@app.dial.idiom.com>
From: Alleluia Petrofsky <Alleluia@petrofsky.berkeley.ca.us>
To: z-machine@gmd.de
In-Reply-To: <199901151825.KAA00738@app.dial.idiom.com> (message from Almohad
	Petrofsky on Fri, 15 Jan 1999 10:25:40 -0800)
Subject: Re: [z-machine] Proposal for a proposal for Version 9
References:  <199901151825.KAA00738@app.dial.idiom.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=NIL
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: bc08f9b7c2b44bf18368aabacfebf22d


Regarding floating-point, I driveled:
> Important to ease and efficiency of
> implementation would be to follow C's example and *not* specify IEEE
> or any particular format, thereby allowing the interpreter-writer to
> just use whatever he's got.

D'oh!  You'd still need a format for constants in the executable,
wouldn't you?  There's also the problem of interaction with a
type-tagged architecture.  I guess it really is best just to let
jholder deal with it.

-al


From ???@??? Mon Jan 18 09:46:16 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <000201be40bc$1a5722a0$95054e8c@edvz.unilinz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Date: Fri, 15 Jan 1999 17:36:49 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0810.800
X-Mimeole: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 84ddcfc707c27e844c41404e9a44fdc8


katre wrote:
>Yes, but with so few games (currently) using the V6 opcodes, wouldn't it be
>best to leave them out of V9, especially if it is just an update to V5-8?
>I fully support an updated V6, but I don't think that mixing the two would
>be trivial.

NO! DAMMIT!
Isn't anybody thinking about us poor people who actually want to write V6
games? AAAARGH!!

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +---------------+------------------------------+
+ Tel: 0732 25 28 57     + ICQ: 22447430 + http://gschmidl.home.ml.org/ +
+------------------------+---------------+------------------------------+





From ???@??? Mon Jan 18 09:46:20 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <000f01be40c1$ea38a840$0101a8c0@mkimmel.isdn.crocker.net>
From: "Matt Kimmel" <matt@javanet.com>
To: <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Date: Fri, 15 Jan 1999 15:01:30 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5e4e61c975d3828f19a53cecdf5b4c51


>katre wrote:
>>Yes, but with so few games (currently) using the V6 opcodes, wouldn't it
be
>>best to leave them out of V9, especially if it is just an update to V5-8?
>>I fully support an updated V6, but I don't think that mixing the two would
>>be trivial.
>
>NO! DAMMIT!
>Isn't anybody thinking about us poor people who actually want to write V6
>games? AAAARGH!!


The flip side of this is that some of us are working on interpreters on
platforms where graphics and some of the other V6 features are either
non-trivial (e.g. Java), or impossible (e.g. PalmPilot, Windows CE).  It's
nice that we currently have the ability to support most versions in their
entirety, and to explicitly not support the versions that are beyond our
technical limitations, rather than having to implement "partial" support.
As someone working on a Java interpreter, I would vote in favor of creating
a separate version that combines Version 9 and Version 6 features.  Then
I'll be able to fully support V9 now and work on V10 (or whatever) support
later.

-Matt



From ???@??? Mon Jan 18 09:46:24 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 15:38:09 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199901152038.PAA13080@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 86ab3f655e352d933d3b0044085ce1c1


} UTF-8 Sounds good.  The Java interpreters writers would sure be happy...

True, but that's NOT why I picked it :-).  Basically

1) It looks like ASCII when only ASCII characters are used
2) It's not a big space-waster like 16-bit characters


From ???@??? Mon Jan 18 09:46:26 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 22:42:43 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Message-Id: <19990115224243.A24026@bartlet.df.lth.se>
References: <199901152038.PAA13080@pond.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <199901152038.PAA13080@pond.com>; from Matthew T. Russotto on Fri, Jan 15, 1999 at 03:38:09PM -0500
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 84cba044a839dfc20be9d4e08c4cf752


As I wrote before, I'd really like to see the special treatment of
strings disappear. Not only is it confusing (as witness the relatively
large number of posts on r.a.i-f from people having trouble with
strings in Inform), it's also a major obstacle to the implementation
of string handling primitives - a thing that is rather sorely missing
from Inform today.

I feel it would be a great advantage if strings could be accessed as
arrays (not necessarily byte arrays - we could, for example, decide to
go with Unicode). This doesn't mean that they would necessarily have
to *be* character arrays (i.e. Inform needn't be as primitive as C),
but it should be possible to read or write the n:th character of a
string without any fancy packing or unpacking.

Abandoning the packed Z-string model would, as I see it, have only two
small disadvantages:

1) The size of the game file would increase. This is primarily a
disadvantage for the people writing for really small machines, like
Psions, but the purpose of z9 is to break free of size limitations,
which leads me to believe most z9 games will be too large for such
small machines anyway. Besides, the small machines are getting bigger
with each year.

2) We'd lose the current text encryption, or perhaps we should call it
obfuscation as somebody suggested. (Technically, it is of course
encryption, but that term is associated with export controls and
whatnot).

I agree that obfuscation can be a desirable property, because if the
game file contains all the game text in clear, then it's far too easy
to read it by mistake. However, we can't hope for more than a
protection against casual or accidental snooping; obfuscation can
never prevent cheating, especially not since the specs for the
obfuscation is open. So we shouldn't put too much energy into
obfuscating the text. A simple obfuscation algorithm also has the
advantage that there's not even a theoretical risk of it being
considered as cryptographic software.

I'd like to suggest the following simple and (if I may say so myself)
elegant scheme:

Instead of having a special encoding for strings, let's add an
"obfuscation filter" between the Z-machine and physical memory. That
is, when the Z-machine writes the value X to memory, the value that is
actually stored is not X, but some invertible function f(X), and when
the Z-machine reads a memory location that really contains the value
Y, the value retrieved is really f^-1(Y).

I think it would be sufficient to, for example, XOR every byte with
the low byte of the address, or even with a fixed value.

This would be totally transparent to the Z-machine; it would read and
write in data to memory, and the interpreter would do the obfuscation.

Finally, a few words about Unicode. Unicode would have the obvious
disadvantage of doubling the size of all strings, and since most
Z-code programs today are mostly strings, this would lead to very
large increases in program size. The Z-machine would also have to have
opcodes to access both 1-byte, 2-byte and 4-byte words, as opposed to
both the existing versions as well as the proposed v9, which all deal
with only two sizes of data chunks (bytes and words). Also, I've heard
some talk of Unicode not being the panacea it was thought to be, but
I'm no expert.

However, I think a scheme like that used today (with several smaller
character sets) would go a long way.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Mon Jan 18 09:46:30 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 15 Jan 1999 22:51:02 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Message-Id: <19990115225102.B24026@bartlet.df.lth.se>
References: <Pine.LNX.4.04.9901132320520.19420-100000@elijah.nodomainname.net> <gqbphD600UwD06PH40@andrew.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <gqbphD600UwD06PH40@andrew.cmu.edu>; from Evin C Robertson on Fri, Jan 15, 1999 at 10:14:23AM -0500
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: d9ccb2f12f2721446e2a7f77bc66cc57


On Fri, Jan 15, 1999 at 10:14:23AM -0500, Evin C Robertson wrote:
> >1) Automated translation of .z5 into .z9 (perhaps to enable
> >interpreter writers to concentrate on one version, or just as a neat
> >hack). Do you think there'd be any demand for this? And how hard would
> >it be?
> 
> In the general case, this is nearly impossible.  In the case of most
> inform compiled games, it is only incredibly difficult.  

I think it would be difficult to do in an optimal way, but if one
accepts a sub-obtimal translation it's clearly doable. For example,
I could write a z5 interpreter in z9, and then just append the z5
code to it. That's not really translation, of course, but the point
is that the translation needn't be very literal. 

> In addition, I don't think there are any
> platforms z9 could run on to which z5 hasn't yet been ported.  You
> really wouldn't want to do this anyway, as moving to 32 bit would
> greatly increase the size of the games with no visible gain.

Apart from hack value, it could be useful in the case where z9 is
sufficiently different from earlier versions that writing an
interpreter for both z9 and z5 would be like writing two separate
interpreters; in that case, interpreter writers may want to ditch the
old versions, and users may want to ditch their old interpreters. Of
course, this scenario is exactly what Graham says we should avoid, and
of course I agree with that.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Mon Jan 18 09:46:33 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <0qbwPEW00UwD06PHk0@andrew.cmu.edu>
Date: Fri, 15 Jan 1999 17:53:04 -0500 (EST)
From: Evin C Robertson <ecr+@andrew.cmu.edu>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <19990115224243.A24026@bartlet.df.lth.se>
References: <199901152038.PAA13080@pond.com>
	<19990115224243.A24026@bartlet.df.lth.se>
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 4e584e3af050a26a2b63dd408709d82a


Excerpts from mail: 15-Jan-99 Re: [z-machine] Proposal fo.. by Magnus
Olsson@df.lth.se 
> As I wrote before, I'd really like to see the special treatment of
> strings disappear. Not only is it confusing (as witness the relatively
> large number of posts on r.a.i-f from people having trouble with
> strings in Inform), it's also a major obstacle to the implementation
> of string handling primitives - a thing that is rather sorely missing
> from Inform today.

Agreed, though this could be fixed with a more sophisticated inform
compiler/libraries.

> I feel it would be a great advantage if strings could be accessed as
> arrays (not necessarily byte arrays - we could, for example, decide to
> go with Unicode). This doesn't mean that they would necessarily have
> to *be* character arrays (i.e. Inform needn't be as primitive as C),

Heh.  In many ways, inform is more primitive than C.

> but it should be possible to read or write the n:th character of a
> string without any fancy packing or unpacking.

Would be nice, but inform could simulate it for you.

> Abandoning the packed Z-string model would, as I see it, have only two
> small disadvantages:
>  
> 1) The size of the game file would increase. This is primarily a
> disadvantage for the people writing for really small machines, like
> Psions, but the purpose of z9 is to break free of size limitations,
> which leads me to believe most z9 games will be too large for such
> small machines anyway. Besides, the small machines are getting bigger
> with each year.

Right; if we're going for 32 bits, concerns for keeping things as small
as they are now are basically nill.

[snip]
> Instead of having a special encoding for strings, let's add an
> "obfuscation filter" between the Z-machine and physical memory. That
> is, when the Z-machine writes the value X to memory, the value that is
> actually stored is not X, but some invertible function f(X), and when
> the Z-machine reads a memory location that really contains the value
> Y, the value retrieved is really f^-1(Y).
[snip]

Um, this is way too complex for its gain.  Better to deobfusicate at
load time than at run time.  Running the entire game through a
compression algorithm would prevent casual viewing and also considerably
reduce size.

> Finally, a few words about Unicode. Unicode would have the obvious
> disadvantage of doubling the size of all strings, and since most
> Z-code programs today are mostly strings, this would lead to very
> large increases in program size. The Z-machine would also have to have
> opcodes to access both 1-byte, 2-byte and 4-byte words, as opposed to
> both the existing versions as well as the proposed v9, which all deal
> with only two sizes of data chunks (bytes and words). Also, I've heard
> some talk of Unicode not being the panacea it was thought to be, but
> I'm no expert.
[snip]

Both unicode strings and UTF-8 sound like bad ideas to me.  What's wrong
with the current way of using unicode in zmachine encoded strings? 
Uncompressed, it uses one byte per character, allows much unicode use,
and should already be implemented by unicode-capable 'terps.  Zspec
section 3.8.5.*


From ???@??? Mon Jan 18 09:46:36 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901152333.PAA16914@scv1.apple.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <19990115224243.A24026@bartlet.df.lth.se>
Date: Fri, 15 Jan 1999 15:15:15 -0800
From: Matt Ackeret <mattack@apple.com>
Reply-To: mattack@apple.com
X-Mailer: by Apple MailViewer (2.98)
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 69fb1647a54f411cf41999f226425ab3


> Right; if we're going for 32 bits, concerns for keeping things as small
> as they are now are basically nill.

No, evil, AAAAAAAAUUUGGGGHHH..

This kind of thinking is what has made software huge, slow, and often to the  
user slower
than acceptably similar software running on machines orders of magnitude slower. 
(In other words, Lynx vs IE or Netscape, even with graphics turned off on the  
GUI browsers!)


> Um, this is way too complex for its gain.  Better to deobfusicate at
> load time than at run time.  Running the entire game through a
> compression algorithm would prevent casual viewing and also
> considerably
> reduce size.

But this slows down load time.

Unless actual execution time would be MUCH faster, I'd rather spread out the  
deobfuscation
to when strings are actually used (maybe keep a cache of deobfuscated  
strings), rather
than uncompress the whole file at load time.

Besides, XORing each byte in a string with 0xAA is pretty quick.


From ???@??? Mon Jan 18 09:46:38 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <001e01be40e9$4de407a0$541e39cb@paul.hdc.com.au>
From: "Paul Gilbert" <pfg@hdc.com.au>
To: <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Date: Sat, 16 Jan 1999 11:43:57 +1100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 87b061e40a681593fbe7f4f13ad41605


I'd just to enter the discussion by pointing out that doing a basic
decryption of a gamefile at load time would likely have a negligable effect
on the overall load time. Most of the time is taken up by physicall disk
access, and performing a XOR decryption of loaded text for even gamefile
sizes of a Megabyte would take less than a second.

It would also keep things simpler then the proposed idea of
dercypting/encrypting on every read/write, and do away with the need for
caching decrypted strings, etc.

-----Original Message-----
From: Matt Ackeret <mattack@apple.com>
To: z-machine@gmd.de <z-machine@gmd.de>
Date: Saturday, 16 January 1999 10:53
Subject: Re: [z-machine] Proposal for a proposal for Version 9


>> Right; if we're going for 32 bits, concerns for keeping things as small
>> as they are now are basically nill.
>
>No, evil, AAAAAAAAUUUGGGGHHH..
>
>This kind of thinking is what has made software huge, slow, and often to
the
>user slower
>than acceptably similar software running on machines orders of magnitude
slower.
>(In other words, Lynx vs IE or Netscape, even with graphics turned off on
the
>GUI browsers!)
>
>
>> Um, this is way too complex for its gain.  Better to deobfusicate at
>> load time than at run time.  Running the entire game through a
>> compression algorithm would prevent casual viewing and also
>> considerably
>> reduce size.
>
>But this slows down load time.
>
>Unless actual execution time would be MUCH faster, I'd rather spread out
the
>deobfuscation
>to when strings are actually used (maybe keep a cache of deobfuscated
>strings), rather
>than uncompress the whole file at load time.
>
>Besides, XORing each byte in a string with 0xAA is pretty quick.


From ???@??? Mon Jan 18 09:46:46 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901160153.UAA28878@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Fri, 15 Jan 1999 20:54:25 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <199901151344.IAA02190@mousetrap.c64.org>
References: <Pine.LNX.4.04.9901141409370.2143-100000@elijah.nodomainname.net> from "Jakob 'sparky' Kaivo" at Jan 14, 99 02:12:23 pm
X-Mailer: Pegasus Mail for Win32 (v3.01b)
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 0c860b25f08941f10b1f9125130c43b4


I seem to be missing some messages here, so excuse the odd quoting.  I 
have on attributions because I'm not exactly sure who said what. 

> > Well, what I was thinking, really, was that there could be flags set in
> > the header that could be read by the interpreter, so that there could be
> > things like V9 with the graphics flag on, V9 with the graphics flag off,
> > flags for sound, etc. This way there is just one new object code format,
> > and the interpreter could just report error messages such as:
 
> > This is a V9 zcode file with the graphics flag on. Graphics aren't
> > supported by this interpreter.

V6 isn't just graphics, it's a whole separate screen model.  A flag 
saying V5 screen model vs. V6 screen model might make sense, but I 
don't feel that's the way to go.  Anyhow, V6 (and V6Lib) allows for 
writing games that behave differently based on whether or not the 
interpreter supports graphics or not.  It's possible to write a game 
now that runs fine on text only V6 interpreters with out trying to draw 
things that it can't.

> > > Well, if we add the full graphical interface to the new V9, then _any_
> > > interpreter that doesn't do graphics (i.e. DOS and curses frotz) can't ever be
> > > compliant.  Also, since many (most?) games don't use those opcodes, it's silly
> > > to force the interpreter to worry about them.  I do, however, like the idea of
> > > updating the graphical version to also be full 32-bit (or whatever we decide).

Both Dos and Unix Frotz play V6 games just fine.  I'm not sure what 
this is talking about.  You can have a text only V6 interpreter, and 
have it be compliant.  I have a cruses based text only djgpp compiled 
frotz that I run V6Lib tests under all the time.


This really didn't have to much to do with the main discussion at hand 
I guess... sorry.
Jay


----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor


From ???@??? Mon Jan 18 13:30:49 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Sat, 16 Jan 1999 12:06:31 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Version 9: discussion and responses
To: Z-Machine Mailing List <z-machine@gmd.de>
Message-Id: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.46]
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 31c19ab39cc5cc8be0669bd6424dd7c9



Let me see if I can summarise discussion so far.

(i) A 32-bit structure seems to be generally acceptable.

Evin Robertson suggests the alternative of moving object and
property tables out of low memory and recoding packed addresses
so that high memory becomes essentially infinite.  The latter

is feasible but the former would make object property arrays
inaccessible, making all existing Inform code fail.  In any
event, array space would still be limited to 40K or so.

(ii) The proposal for the top bit to indicate a very primitive
form of data typing seems less acceptable, or at any rate has
been less discussed.

Matthew Russotto argues that it "restricts your memory map
to 31 bits", i.e., reduces maximum story file size to only
2.097 gigabytes.

The following further alterations to the ZM have been proposed:

1. More attributes (possibly "infinitely many", with a header
byte giving the number of bytes used for attribute storage).

2. More common properties, perhaps up to 65535 of them.

3. Dynamic memory allocation.  But Jakob Kaivo suggests doing this
in software.  (And I agree.  But see my counter-proposal 3a.)

4. Floating-point support.  But Magnus Olsson suggests doing this
in software.

5. Storing strings in unencrypted form with 1 byte per character,
or perhaps using a Unicode format.  Misunderstandings about the
meaning of the word "encryption" have confused the matter: the
present situation doesn't remotely qualify under export bans on
encryption, and is not intended for security but only compression.

6. Jason Penney suggests creating a Version 10 at the same time
as Version 9, consisting of V9 plus the V6 graphics and sound
support.

7. That perhaps all of memory should be writeable?

8. I'd like to add one proposal of my own, a small matter which I
should have mentioned earlier: at present, some interpreters allow
"nested" uses of @output_stream 3 to write text to arrays, and
others don't.  Various features of the Inform library already
need this to work.  I'd like to make it clearly mandatory in any
V9 that we produce.

My own responses to these proposals are as follows:

1. I have no strong preference.  Perhaps a compromise measure
would be to double the number of attributes to 96, stored in
a twelve-byte block, since we seem to be doubling things.
Nobody has ever emailed me to complain about shortage of
attributes, in any event.

2. Inform doesn't need this and wouldn't use it.  I prefer a
small table which is rapidly readable, but I'm open to
persuasion.

3. I am opposed to dynamic memory allocation, but if we must have
it -- and I can see that there are arguments in favour -- I
propose the following minimal system:

  3a.  A word in the header of the story file contains a number M.
  The extent of the story file is considered to be the extent of
  the actual file as stored on disc, plus M zero bytes stored at
  the top of memory.  In this way, an interpreter could know
  immediately whether there will ever be a memory problem in
  running the story file, and we can avoid the nightmare of memory
  running out on one machine but not another, which has plagued
  the TADS run-time system in the past.


Let me emphasize that I'm not persuaded of the need for dynamic
memory allocation at all, but if we're going to do it, then
something very carefully circumscribed seems wise.

4. Floating-point support should be handled in software (as it
was for all early processors and some processors still, e.g. the
ARM processor running in the machine I'm typing this on).  My
reasons for this are: (i) we are not writing real-time, texture
mapped games here, and don't need ultra-fast floating point
support; (ii) it would be bound to get us into nasty issues of
how to store "double floats"; (iii) it would be almost impossible
to make floating-point support platform independent.  And this
is important.  The only time I've wanted f.p. in one of my own
games was the flying-the-B52 puzzle from "Jigsaw", which needs
to keep taking inverse tangents.  Lord, but this was a nightmare
puzzle to debug: I kept having to take care to avoid divisions
by zero, in particular.  If the situation had been that the
calculations would only nearly come out equal on different
machines, this error would have been much harder to avoid.

5. I am unpersuaded.  The present arrangement seems fine to me.

6. I support this.

7. I oppose this, on the grounds that the present arrangement is
a good one for putting together and restoring saved-game files.
(If you want to write self-modifying code, you can already.
Just write it into an array and call it!)  I do want every byte
to be readable, though.

8. Surprisingly enough, I support this one.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Mon Jan 18 09:47:11 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Sat, 16 Jan 1999 15:39:54 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Version 9: discussion and responses
Message-Id: <19990116153954.A2393@bartlet.df.lth.se>
References: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk>; from Graham Nelson on Sat, Jan 16, 1999 at 12:06:31PM +0100
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 67b027e96a2de080cb255815bd19bbf3


On Sat, Jan 16, 1999 at 12:06:31PM +0100, Graham Nelson wrote:
> 3. I am opposed to dynamic memory allocation, but if we must have
> it -- and I can see that there are arguments in favour -- I
> propose the following minimal system:
> 
>   3a.  A word in the header of the story file contains a number M.
>   The extent of the story file is considered to be the extent of
>   the actual file as stored on disc, plus M zero bytes stored at
>   the top of memory.  In this way, an interpreter could know
>   immediately whether there will ever be a memory problem in
>   running the story file, and we can avoid the nightmare of memory
>   running out on one machine but not another, which has plagued
>   the TADS run-time system in the past.

It sounds like a good idea to let the interpreter know at the start
how much memory the Z-code program will ask for (or an upper limit),
considering that it should be possible to write Z-code interpreters
for computers with little physical memory and no VM. The limitations
it places on the Z-program shouldn't be very serious for IF
applications at the current state of the art. A possible extension
would be this: a really advanced Z-program (say, one involving 
advanced AI techniques for NPC conversation) could set the value
of M to infinity, which would enable interpreters to either refuse
to run the program at all (on small physical machines) or to warn
the user that "this program *may* run out of memory".

[ I've re-ordered the paragraphs in Graham's letter somewhat, to
bring this paragraph down here:]

> 5. Storing strings in unencrypted form with 1 byte per character,
> or perhaps using a Unicode format.  Misunderstandings about the
> meaning of the word "encryption" have confused the matter: the
> present situation doesn't remotely qualify under export bans on
> encryption, and is not intended for security but only compression.

Just a note: despite the fact that the current encoding of strings is
not intended for security, it nevertheless serves such a function,
which is important to some.

> 5. I am unpersuaded.  The present arrangement seems fine to me.

Given the premises - that the proposed v9 should introduce as minimal
changes as possible, and that we shouldn't try to achieve the Platonic
ideal Z-ocde version - I won't try to persuade you :-). I still think
the Z-machine's string handling is quite complicated to the
programmer.  (I might try to remedy this by writing a string-handling
Library extension some time in the future).  gnirf


I'd like to add a 9th point to the proposal: That a v9 interpreter's
behaviour when it encounters "Vile Zero Errors From Hell" be
unambigously specified, so we don't get the problem with code that
works on some interpreters but not on others. (I'm of course aware of
the fact that the new "strict" compiler option will greatly reduce the
incidence of such errors; this is more a matter of consistency than of
pressing need).


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Mon Jan 18 09:47:17 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <Iqc=sZi00UwD06N2A0@andrew.cmu.edu>
Date: Sat, 16 Jan 1999 11:28:21 -0500 (EST)
From: Evin C Robertson <ecr+@andrew.cmu.edu>
To: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] Version 9: discussion and responses
In-Reply-To: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk>
References: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk>
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 9cb03a73cd47ec990a81da0ffa96a67d


Excerpts from z-machine: 16-Jan-99 [z-machine] Version 9: disc.. by
Graham Nelson@gnelson.de 
> Evin Robertson suggests the alternative of moving object and
> property tables out of low memory and recoding packed addresses
> so that high memory becomes essentially infinite.  The latter
> is feasible but the former would make object property arrays
> inaccessible, making all existing Inform code fail.  In any
> event, array space would still be limited to 40K or so.

You misread.

Excerpts from z-machine: 13-Jan-99 Re: [z-machine] Proposal fo.. by Evin
C Robertson@andrew. 
>At each object address, put the attributes, parent, sibling, and child
>as normal.  Then give the short name of the object and a property
>offset.  Followed by property numbers in ascending order (I suggest 16
>bit).  A length byte will be at the property offset (in low memory),
>followed by the first property, followed by another length byte, etc.

All property data (except for the property numbers) are in low memory,
making property arrays work fine.

But yes, array space would still be limited.

Probably going to 32 bit would be a cleaner approach, but my method
would result in smaller games files, for whatever that's worth.  Also,
it will be more difficult to write interpreters which can handle both 16
bit z-machines and 32 bit in the same interpreter executable than to
make them capable of using alternate addressing for the stuff they
already do.  Maybe this isn't an inconvenience to users; I don't know.


From ???@??? Mon Jan 18 09:47:26 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Sat, 16 Jan 1999 21:30:26 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Version 9: discussion and responses
Message-Id: <19990116213026.B11521@bartlet.df.lth.se>
References: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk> <19990116153954.A2393@bartlet.df.lth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <19990116153954.A2393@bartlet.df.lth.se>; from Magnus Olsson on Sat, Jan 16, 1999 at 03:39:54PM +0100
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 3ad3027c1794c74a506aab8cdee627c8


On Sat, Jan 16, 1999 at 03:39:54PM +0100, Magnus Olsson wrote:
> On Sat, Jan 16, 1999 at 12:06:31PM +0100, Graham Nelson wrote:
> >   3a.  A word in the header of the story file contains a number M.
> >   The extent of the story file is considered to be the extent of
> >   the actual file as stored on disc, plus M zero bytes stored at
> >   the top of memory.  In this way, an interpreter could know
> >   immediately whether there will ever be a memory problem in
> >   running the story file

(...)

> A possible extension
> would be this: a really advanced Z-program (say, one involving 
> advanced AI techniques for NPC conversation) could set the value
> of M to infinity, which would enable interpreters to either refuse
> to run the program at all (on small physical machines) or to warn
> the user that "this program *may* run out of memory".

Oops. Silly me, typing faster than I was thinking (I've done an
awful lot of that lately, it seems. Bad Magnus).

Of course no such extension is necessary - with a 32-bit address
space, the Z-machine can "only" address 2 GB, so it makes no sense
to have M > 2^32.

Anyway, the scenario I had in mind was this:

Suppose a Z-program doesn't know exactly how much memory it will need,
so to be on the safe side it sets M to something large, say 10 MB. The
interpreter is of course now free to say that it can't run the
Z-program, or it can play safe and actually allocate 10 MB of memory
to run the Z-program.

But it can also allocate only the size of the Z-file, plus some safety
margin perhaps, and then postpone allocating more until the Z-program
actually accesses an address higher than the current memory size.

Doing this would of course be entirely up to the interpreter writer.
It would probably not be advisable to take chances ("This program says
it will need 100 MB, but I don't think it will use more than 64 kB") -
but even on a machine where you can allocate 100 MB of RAM in one
swoop, you may not want to do so for efficiency reasons.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Mon Jan 18 09:47:29 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Sat, 16 Jan 1999 17:20:54 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199901162220.RAA12013@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Version 9: discussion and responses
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: c03fd18243dfda82845df32db4202a22


In an attempt to clarify things (at least for myself, hopefully for others), 
I've outlined below the significant specification changes proposed for the
V9 Z-Machine

----

* In this document, "word" refers to a 4-byte quantity, and "halfword" to a 2-byte quantity.

Section 1, The Memory Map.

1.1 The memory map of the Z-machine is an array of bytes with "byte addresses"
running from 0 upwards. This is divided into three regions: "dynamic", "static",
and "heap". Dynamic memory begins from address $00000 and runs up to the
byte before the address stored in the word at $1c in the header. (Dynamic 
memory must contain at least 128 bytes.)  Static memory occupies the area
between dynamic memory and the last byte of the story file.  Heap
memory begins after the last byte of the story file and extends for the length
defined by the word at header address $2C.

* The address at $08 may be taken as a hint to the interpreter; anything below
  that address should be kept in RAM, anything in static memory above that
  address may be swapped out as necessary.  This is a hint only and not
  required behavior; an interpreter may swap out all memory or none, provided
  the results of the program running within it are not affected.

1.1.3 Heap memory may be read and written just like dynamic memory.

1.1.4 V9 story files are huge.

1.2 All addresses are byte addresses, and are one word long.

1.2.1 - 1.2.3 Obselete

---NON-TAGGED option---
Section 2 Numbers and Arithmetic

2.1 In the Z-machine, numbers are usually stored in 4 bytes ( Most Significant
Byte first) and hold any value in the range $00000000 to $ffffffff 
(0 to 4294967295 decimal). 

2.2 These values are sometimes regarded as 2's complement signed numbers.  In
effect -n is stored as $100000000-n and so the top bit is the sign bit.

2.3.2 
The result of an out-of-range calculation is reduced modulo $100000000. 

---TAGGED option---

2.1 In the Z-machine, numbers are usually stored in 4 bytes ( Most Significant
Byte first) and hold any value in the range $00000000 to $7fffffff 
(0 to 2147483647 decimal).

2.1.1 Numbers with the high byte set shall be reduced modulo $1000000 before use
in any operation.  Thus the range of such a tagged number is $000000 to $ffffff
(0 to 16777215 decimal)

2.2 These values are sometimes regarded as 2's complement signed numbers.  In
effect -n is stored as $80000000-n and so the second-most-significant bit is
the sign bit.  Tagged numbers are thus never negative.

2.2.2 The result of any signed operation has the most significant bit clear.

2.3.2 
The result of an out-of-range calculation is reduced modulo $80000000.
----------------
* Should we increase the range of RANDOM?

Section 4 How instructions are encoded

4.1

A single Z-machine instruction consists of the following sections (and in the
order shown): 

  Opcode               1 or 2 bytes
  (Types of operands)  1 or 2 bytes: 4 or 8 2-bit fields
  Operands             Between 0 and 8 of these: each 1 or 4 bytes
  (Store variable)     1 byte
  (Branch offset)      1 or 2 bytes
  (Text to print)      An encoded string (of unlimited length)

Bracketed sections are not present in all opcodes. (A few opcodes take both
"store" and "branch".) 

There are four 'types' of operand. These are often specified by a number stored
in 2 binary digits: 

  $$00    Large constant (0 to $fffffff)    4 bytes
  $$01    Small constant (0 to $ff)         1 byte
  $$10    Variable                          1 byte
  $$11    Omitted altogether                0 bytes
  
4.2.1

Large constants, like all 4-byte words of data in the Z-machine, are stored with
most significant byte first (e.g. $54622478 is stored as $54 followed by $62 
followed by $24 followed by $78). A  'large constant' may in fact be a small number. 

*TAGGED OPTION ONLY*
Any instruction which performs any operation on a large constant or variable 
except a simple copy shall, before using it, check the most significant 
bit of the constant.  If it is set, only the least significant
24 bits of the constant shall be used.  If it is clear, the least significant 31
bits shall be used.

* The example for Section 4 would need changing as well.

5. How routines are encoded

5.1 deleted; A routine may begin anywhere in memory.

5.5.1 In Version 9, there is a main routine (whose address is stored in a word
      at address $0C in the header) called when the game starts up.

*This is my change, I see no reason to keep the funny one-off thing -- MTR
 Should we make returning from this guy into a "quit", normalizing the
 main routine entirely?

----------
Section 6 The game state: storage and routine calls

6.1

The "state of play" is defined as the following: the contents of dynamic memory;
the contents of the heap; the contents of the stack; the value of the program 
counter (PC), and the "routine call state" (that is, the chain of routines which 
have called each other in sequence, and the values of their local variables).
Note that the routine call state, the stack and the PC must be stored
outside the Z-machine memory map, in the interpreter's private memory. 

* Should multi-undo be addressed?

6.1.3.3 On Restart, heap memory is cleared to zero.

6.2 
Global variables (variable numbers $10 to $ff) are stored in a table in the
Z-machine's dynamic memory, at an address given by the word at address $18 
of the header.  The table consists of 240 4-byte words and the initial values
of the global variables are the values initially contained in the table. (It
is legal for a program to alter the table's contents directly in play, though
not for it to change the table's address.) 

6.3

Writing to the stack pointer (variable number $00) pushes a value onto the
stack; reading from it pulls a value off. Stack entries are 4-byte words as
usual. 

6.3.3 (No change, but note the stack has gotten wider)

6.4.3 (Delete the word "packed")

Section 8: The Screen Model

8.1 Text may be printed in any font of the interpreter's choice, variable- or
fixed-pitch: except when the text style has been set to Fixed Pitch, then a
fixed-pitch font must be used. 

*right, I'm ditching that highly irritating header flag.

8.1.1 The height and width of the current font (in units (see below))
should be written to bytes $4E and $4C of the header, respectively. 
* Note I've chosen the V5 usage.

8.3.3

If the interpreter can produce colours, it should set bit 0 of 'Flags 1' in the
header, and write its default background and foreground colours into bytes
$58 and $5A of the header. 

8.4

The screen should ideally be at least 60 characters wide by 14 lines deep.
(Old Apple II interpreters had a 40 character width and some modern
laptop ones have a 9 line height, but implementors should seek to avoid
these extremes if possible.) The interpreter may change the exact
dimensions whenever it likes but must write the current height (in lines)
and width (in characters) into bytes $40 and $42 in the header. 

8.4.3

The screen's width and height in units should be written to the words at 
$44 and $48. 

Section 10 Input Streams and Devices.

10.5.2.1

The game may provide a "terminating characters table" by giving its byte
address in the word at $5C in the header. This table is a zero-terminated
list of input character codes which cause aread to finish the command
(in addition to new-line). Only function key codes are permitted: these
are defined as those between 129 and 154 inclusive, together with 252,
253 and 254. The special value 255 means "any function key code is
terminating". 


Section 11: Header Format:

11.1

Hex     Dyn     Int     Rst     Contents
0                               Version number 9
1                               Ascii 'Z' ($5A)
2               *       *       Bit 0: Colors available?
                *       *       2: Boldface available?
                *       *       3: Italic available?
                *       *       4: Fixed-space font availble?
                *       *       5: Sound Effects Available
                *       *       7: Timed Keyboard Input available
3                               OPTION: # of bytes for attributes
4                               Release Number (word)
8                               Base of swappable memory (address)
C                               Address of initial routine
10                              Location of dictionary (address)
14                              Location of object table (address)
18                              Location of global variables table (addresss)
1C                              Base of static memory (address)
20                              Flags 2 (word)
        *               *       Bit 0: Set when transcripting is on
                                1: Obselete, use set_font
                *       *       3: If set, game wants to use pictures
                *       *       4: If set, game wants to use UNDO
                *       *       5: If set, game wants to use a mouse
                                6: If set, game wants to use colors
                *       *       7: If set, game wants to use sound effects
                *       *       8: If set, game wants to use menus
                                (for bits 3,4,5,7, and 8, interpreter
                                clears if it cannot provide the requested effect)

24                              Serial number (ASCII for compilation date in
                                the form YYYYMMDD.)
2C                              Size of heap memory (word)
30                              Location of abbreviations table (address)
34                              Length of file in bytes
38                              Checksum (halfword)
3A                              - (halfword)
3C                              Interpreter number
3D                              -
3E                              Interpreter version
3F                              -
40              *       *       Screen height (lines); 255 means "infinite"
41                              -
42              *       *       Screen width (characters)
43                              -
44              *       *       Screen width in units (word)
48              *       *       Screen height in units (word)
4C              *       *       Font width in units (defined as width of a '0')
4D                              -
4E              *       *       Font height in units
4F                              -
50                              Obselete (word)
54                              Obselete (word)
58              *       *       Default background color
59                              -
5A              *       *       Default foreground color
5B                              -
5C                              Address of terminating characters table
60                              (V10?)
64              *       *       Standard revision number
68                              Alphabet table address, or 0 for default
6C                              Header extension table address

11.1.5

*** If an interpreter obeys Revision n.m of this document perfectly, as
far as anyone knows, then byte $64 should be written with n and byte
$65 with m. If it is an earlier (non-standard) interpreter, it should leave
these bytes as 0. 

11.1.6 Deleted

11.1.7.3 (unchanged, but note that words are 4 bytes now)

Section 12: The object table

12.1 

The object table is held in dynamic memory and its byte address is stored
in the word at $14 in the header. (Recall that objects have flags attached
called attributes, numbered from 0 upward, and variables attached called
properties, numbered from 1 upward. An object need not provide every
property.) 

12.2 (unchanged, note again that "words" are 4 bytes)

Option 1:
-----------
12.3.3 In Version 9, there are as many objects as fit in memory, each having
a 28-byte entry as follows

the 96 attribute flags  parent  sibling child           property table
-96 bits in 12 bytes--  ---3 words, i.e. 12 bytes---    --4 bytes--
-----------
Option 2
12.3.3 In Version 9, there are as many objects as fit in memory, each having
a 16+N-byte entry as follows

the 8N attribute flags  parent  sibling child           property table
-8N bits in N bytes--  ---3 words, i.e. 12 bytes---     --4 bytes--

12.3.3.1 The number of attribute bytes N is determined by byte $3 in the header
------------

12.4.2

In Versions 4 and later, a property block instead has the form 

   size and number       the actual property data
  --1 or 2 bytes---     --between 1 and 128 bytes--

The property number occupies the bottom 6 bits of the first size byte. 

* Might as well fix this bug while we can.

12.4.2.1

If the top bit of the size byte is set, then there is a second size byte. The
bottom seven bits of the second byte contain the property data length (counting
in bytes).

12.4.2.1.1

*** A value of 0 in the bottom seven bits of the second byte should be
interpreted as a length of 128. 

12.4.2.2

Otherwise, if bit 6 of the size byte is set then the length is 4, and if it is
clear then the length is 1. 

----Section 13 The dictionary and lexical analysis

13.1

The dictionary table is held in static memory and its byte address is stored
in the word at $10 in the header. 

13.2

The table begins with a short header: 

  n     list of keyboard input codes   entry-length  number-of-entries
 byte  ------n bytes-----------------      byte         4-byte word

The keyboard input codes are "word-separators": typically (and under
Inform mandatorily) these are the ZSCII codes for full stop, comma and
double-quote. Note that a space character (32) should never be a
word-separator. The "entry length" is the length of each word's entry in
the dictionary table. (It must be at least 6) 

* The only reason the number of entries is 4-bytes is because 2-byte halfwords
are difficult to deal with in Inform in this proposal.

15 Dictionary of Opcodes

15.2 (The example is now 16 bytes long)

15.3 A Standard interpreter is required to handle the following error
     conditions, and halt with an error if they occur.

15.3.1 An illegal opcode being hit.

15.3.2 A call to what can't be a routine.

15.3.3 A jump or call to an address beyond the size of memory.  
 
15.3.4 An attempt to print_obj or otherwise access an object which cannot
       exist because it is object 0 or its address is outside of memory.
       
15.3.5 An attempt to write to or get the property length of a nonexistent
       property. 
       
15.3.6 An attempt to access an attribute which does not exist. 

15.3.7 Division by 0. 

15.3.8 Stack overflow


add: signed 32 (31 in tag proposal) bit addition.  

div: 32-bit division.  31-bit division in tag proposal

get_prop: words are 4 bytes, and it is illegal for the opcode to be used
if the property has length other than 1 or 4.

put_prop: Same idea.

*Could allow 2 and 3 byte values.

loadb

2OP:16 10 loadb array byte-index -> (result) 

Stores array->byte-index (i.e., the byte at address
array+byte-index). 

loadw:

2OP:15 F loadw array word-index -> (result) 

Stores the word at address array+4*word-index

mod: remainder after signed 32-bit (31-bit in tag proposal) division

mul: signed 32 (31 in tag proposal) bit multiplication

print_paddr: Deleted

read:  The parse buffer is larger; byte 0 holds the maximum number
of textual words which can be parsed. byte 1 holds the number of
words written to the parse buffer.  The rest of the
parse buffer consists of 6-byte blocks.  The first four bytes of each
block are the address of the word in the dicationary, the fifth byte
gives the number of letters in the word, and the sixth byte gives the
position in the text-buffer of the first letter of the word.

storeb

VAR:226 2 storeb array byte-index value 

array->byte-index = value, i.e. stores the given value in the byte at
address array+byte-index (which must lie in dynamic or heap memory). (See
loadb.) 

storew

VAR:225 1 storew array word-index value 

array-->word-index = value, stores the given value in the word at
address array+4*word-index (which must lie in dynamic or heap memory).
(See loadw.) 

sub: 32 (31 in tag proposal) bit subtraction

loadh:

EXT:13 D loadw array word-index -> (result) 

Stores the halfword at address array+2*word-index

Would be a real bear in Inform, I think, but
probably belongs in the machine.  If Inform
could make use of it reasonably, might allow
some things to be smaller.

storeh

EXT:14 E storew array word-index value 

Stores the given value in the halfword at address 
array+2*word-index (which must lie in dynamic or heap memory).
(See loadh.) 


From ???@??? Fri Jan 22 14:36:33 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901180156.OAA03763@smtp1.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 18 Jan 1999 13:54:59 +1300
To: Graham Nelson <graham@gnelson.demon.co.uk>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Version 9: discussion and responses
Cc: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 99480ed8b2267193d82f71499e9b6d9a



I apologise in advance for the length of this message... I wanted to
get some thoughts of mine into the open, so they could be discussed,
if necessary, and I'm not really trying to state a position (other
than for obfuscation).

At 12:06 16/01/99 +0100, Graham Nelson wrote:
>
>5. Storing strings in unencrypted form with 1 byte per character,
>or perhaps using a Unicode format.  Misunderstandings about the
>meaning of the word "encryption" have confused the matter: the
>present situation doesn't remotely qualify under export bans on
>encryption, and is not intended for security but only compression.

If this kind of approach is taken, I would recommend using "extended
ASCII" (my term, and it's possible that this is actually UTF-8 or
some other format that I'm not familiar with).  In this format the
characters are in normal ASCII (1 byte per character) but if a
designated marker character is encountered (suggestions are 00 or FF)
the next two bytes are read as a Unicode character.  So normal
characters use 1 byte, and Unicode characters use three bytes.

However, I'm not entirely convinced whether this would be the best
approach, as characters 80-FF vary between machines, so cannot be
left arbitrary.  These would either have to be defined specifically
(with interpreters unable to display those characters printing '?' as
normal) or disallowed entirely, in which case the characters might as
well be stored in 7-bit segments.

But if we go down that road, it would be easier to keep the existing
Ztext, since all interpreters support it anyway; why reinvent the
wheel when it would only have limited benefit?

In any case, I definately support the need for some obfuscation of
the text stored in the story file (to be unpacked on loading) to
prevent casual cheating, but since the present system supports
this.....

-- 
Gavin Lambert
uecasm@geocities.com
<http://crash.ihug.co.nz/~brianc/>
Mirabilis ICQ UIN: 2274180  (check out <http://www.mirabilis.com>)
Fight spam!  Support an email amendment at <http://www.cauce.org/>

----
Shin: a device for finding furniture in the dark.

Why is it called "rush hour" if it's so damn slow?

Earth first!  We'll log the other planets later.
----

The above quotes have been randomly selected from a huge list.
I apologize if you find some of them offensive.


From ???@??? Fri Jan 22 14:36:49 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36A34C61.AA1B4E75@dsres.com>
Date: Mon, 18 Jan 1999 14:59:45 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Version 9: discussion and responses
References: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: ccea67c656f7cd117fac1827a8f28a3f


Graham Nelson wrote:

> Let me see if I can summarise discussion so far.

> (ii) The proposal for the top bit to indicate a very primitive
> form of data typing seems less acceptable, or at any rate has
> been less discussed.

I actually like it in principle. What I'm worried about is the
difficulty of implementing both it and normal 16-bit without testing the
version number on every arithmetic operation (if all arithmetic
operations are done in 32 bits, then we must clear the top bit on stores
(easy) and recalculate it on loads (more of a hassle). Luckily the spec
merely specifies reduction by a modulo on overflow, else things would be
a right pain.

I think it would be of particular use with one of the stated aims of the
new design, that people may want to write compilers for languages other
than Inform. I remember that after one of the regular postings of the
ZIL snippets on raif, several people said that they would much rather
write their IF in a LISP/Scheme/MDL type of language. Native support for
tagging makes such things very much easier.

> 5. Storing strings in unencrypted form with 1 byte per character,
> or perhaps using a Unicode format.  Misunderstandings about the
> meaning of the word "encryption" have confused the matter: the
> present situation doesn't remotely qualify under export bans on
> encryption, and is not intended for security but only compression.

As I see it, the major complaint about this is that it makes
disassembling strings difficult, and I disagree that this is the case.
It would not be difficult to write a routine to convert strings into
their character representation using stream 3 and print_paddr, so that a
string could be loaded into dynamic memory and manipulated. Yes, it is
more work, but IMHO not enough to warrant another big change.

FWIW, if I was designing an architecture for IF from scratch, I would
compress the static text using a Huffman-based scheme, such that a
string address is actually bit-oriented [0], and all game text uses a
common Huffman tree. This avoids the big problem with a fixed encoding,
which is that a game using a drastically different character set (or
subset of Unicode) suffers a huge penalty for all the escape characters:
consider a game written entirely in Greek, for example. Each character
would take 4 Z-characters to store, or two bytes in UTF-8; and this is
far from a pathological case. With Huffman, the commonly used characters
(say 60--70 with punctuation) get the shortest bit patterns, and the
game still has the option of using Latin-1 characters if it wishes [1].
I'm not suggesting that we use this for V9, though: I think that the
disadvantages of the current scheme are outweighed by the hassle of
changing [2].

> 6. Jason Penney suggests creating a Version 10 at the same time
> as Version 9, consisting of V9 plus the V6 graphics and sound
> support.

This (or some similar compromise arrangement) definitely gets my
support.

> 7. That perhaps all of memory should be writeable?

IMHO, this is definitely a Bad Thing (for save/load, among other
things). It's also not necessary. UNIX C compilers get by quite happily
storing much of the data (inline strings, mainly) in the text segment
(which is non-writeable), based on whether it has a `const' qualifier or
not (this is done for efficiency reasons on older UNIX versions, btw).

> 8. I'd like to add one proposal of my own, a small matter which I
> should have mentioned earlier: at present, some interpreters allow
> "nested" uses of @output_stream 3 to write text to arrays, and
> others don't.  Various features of the Inform library already
> need this to work.  I'd like to make it clearly mandatory in any
> V9 that we produce.

Definitely. Interpreter writers have no excuse for not doing this in a
new Version.

> 3. I am opposed to dynamic memory allocation, but if we must have
> it -- and I can see that there are arguments in favour -- I
> propose the following minimal system:

>   3a.  A word in the header of the story file contains a number M.
>   The extent of the story file is considered to be the extent of
>   the actual file as stored on disc, plus M zero bytes stored at
>   the top of memory.  In this way, an interpreter could know
>   immediately whether there will ever be a memory problem in
>   running the story file, and we can avoid the nightmare of memory
>   running out on one machine but not another, which has plagued
>   the TADS run-time system in the past.

If dynamic allocation is implemented, I would like to see a system like
the above, but possibly with a new opcode similar to the UNIX brk()
system call, which changes the size of the available address space. This
avoids (as was pointed out by someone else) the need for a program which
has potentially huge memory requirements to occupy all the space without
ever using it on a given run.

> 4. Floating-point support should be handled in software

Agreed. It's just not used often enough to warrant anything else.

Other points brought up by others:

- Encoding text by decompressing/decoding the entire file at startup.

This is really something I would not like to see necessary. While
increasingly many interpreters *do* load an entire story into memory
(and don't bother with paging), it is not necessary to do so, [3] and
with one of the points of the new proposals being that people will be
able to write very big games, it seems silly to effectively force
sequential access to the story file as it is stored. With only a little
more thought, this can be avoided.

- Quetzal will have to updated/modified (to include 32-bit PC).

Once the new format is finalised, I will of course work on updating
Quetzal. [4] If dynamic memory allocation is implemented in the way
mentioned above (specifically, causing there to be two separate dynamic
memory regions with the whole of the game code and static data in
between), this will also require [5] an update to the compression scheme
used (consider a game with 20--30 Mb of code and data, and having to use
2 bytes for every 256 in that big block: resulting in >150 Kb wasted).

A suggestion of my own is that while we are changing things, we remove
the restriction that there can't be gaps in a function argument list
(that the first omitted argument ends the list). This could be useful,
isn't hard to implement, and makes me look wonderfully prescient in
specifying the otherwise bizarre Quetzal argument format in stack
frames.

Other things to consider are whether Quetzal should be generally
overhauled for the new format, or whether it's good enough as it stands
(it's currently rather 16-bit).

--m

0/ With 32 bit addresses, this is not a problem, as it still allows 512
megabytes of static text.
1/ Also, if it does use them, then the overhead of doing so is
minimised.
2/ Unless things change so drastically in other respects that it becomes
infeasible to even try to make a combined V5/V9 interpreter.
3/ It is trivially easy to modify Frotz (which normally loads the whole
file into memory at startup), to instead use the UNIX mmap() system
call, so that the operating system does all the paging work (why
reinvent the wheel when you have hardware support?)
4/ WTF did I ever choose 24 bits for the PC anyway?
5/ For values of `require' meaning that it's a trivial amount of effort
for the resulting improvement in efficiency.


From ???@??? Fri Jan 22 14:36:55 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Mon, 18 Jan 1999 11:28:38 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199901181628.LAA18150@pond.com>
To: martin@dsres.com, z-machine@gmd.de
Subject: Re: [z-machine] Version 9: discussion and responses
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 7e8ee4ecd038cf8147083a45bd06d55b


}> 8. I'd like to add one proposal of my own, a small matter which I
}> should have mentioned earlier: at present, some interpreters allow
}> "nested" uses of @output_stream 3 to write text to arrays, and
}> others don't.  Various features of the Inform library already
}> need this to work.  I'd like to make it clearly mandatory in any
}> V9 that we produce.

}Definitely. Interpreter writers have no excuse for not doing this in a
}new Version.

Does the nesting information for stream 3 become part of the state of
play?

(For every monkey idea, there's a wrench :-) )

} A suggestion of my own is that while we are changing things, we remove
} the restriction that there can't be gaps in a function argument list
} (that the first omitted argument ends the list). This could be useful,
} isn't hard to implement, and makes me look wonderfully prescient in
} specifying the otherwise bizarre Quetzal argument format in stack
} frames.

I like that restriction. 
s


From ???@??? Fri Jan 22 14:36:57 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36A3685B.D33689A3@dsres.com>
Date: Mon, 18 Jan 1999 16:59:07 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Version 9: discussion and responses
References: <199901181628.LAA18150@pond.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 3d1637eb9b257d54a5f22db9adc9500a


Matthew T. Russotto wrote:

> Does the nesting information for stream 3 become part of the state of
> play?

I read the proposal on this to be the same as the current Z-machine
extension; namely that saving is illegal while stream 3 is active.
 
> } A suggestion of my own is that while we are changing things, we remove
> } the restriction that there can't be gaps in a function argument list
> } (that the first omitted argument ends the list). This could be useful,
> } isn't hard to implement, and makes me look wonderfully prescient in
> } specifying the otherwise bizarre Quetzal argument format in stack
> } frames.

> I like that restriction.

I regard it as illogical and unnecessary, and the sort of thing that
requires ugly workarounds in otherwise nice programs.

For example, in Java it is possible to declare two methods with the same
name but different arguments, and these are treated as distinct. This is
similar to the current Z-machine arrangement. There are several places
in the system where it would be valid to omit either of two arguments
(for example initialising the layout for a window as a grid with a
certain number of rows and columns, with either omitted taken as
infinite for that dimension). This has to be worked around in one of
several ugly ways:

  1) Ignoring this feature and having a total of three methods,
     with one for each of the arguments that can be omitted.
  2) Definining magical out-of-band values to indicate that some
     argument is not present (such as zero).
  3) Deciding that one argument is more likely to be omitted than
     another, and using one of the first two methods for the case
     where the other is.

IMHO, none of these is satisfactory, particularly when the restriction
could be lifted: if this change was made, you could simply call the same
function as:

	foo (); or foo (,);
	foo (x); or foo (x,);
	foo (,y);
	foo (x,y);

The only arguments I can see in favour of retaining this restriction
are: it allows a minor optimisation (interpreter doesn't need to check
all the argument types), and it's one more thing to change.

--m


From ???@??? Fri Jan 22 14:37:01 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Mon, 18 Jan 1999 18:15:30 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Version 9: discussion and responses
Message-Id: <19990118181530.A18521@bartlet.df.lth.se>
References: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk> <36A34C61.AA1B4E75@dsres.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <36A34C61.AA1B4E75@dsres.com>; from Martin Frost on Mon, Jan 18, 1999 at 02:59:45PM +0000
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: b915412643d98dbaea464e2799e550e2


On Mon, Jan 18, 1999 at 02:59:45PM +0000, Martin Frost wrote:
> Graham Nelson wrote:
> > 5. Storing strings in unencrypted form with 1 byte per character,
> > or perhaps using a Unicode format.  Misunderstandings about the
> > meaning of the word "encryption" have confused the matter: the
> > present situation doesn't remotely qualify under export bans on
> > encryption, and is not intended for security but only compression.
> 
> As I see it, the major complaint about this is that it makes
> disassembling strings difficult, and I disagree that this is the case.
> It would not be difficult to write a routine to convert strings into
> their character representation using stream 3 and print_paddr, so that a
> string could be loaded into dynamic memory and manipulated. Yes, it is
> more work, but IMHO not enough to warrant another big change.

The problem is not that it's difficult - as you say, there is stream 3
to do the assembly/disassembly for you. The problem is that the
packing/unpacking (I prefer those terms for various reasons) introduces
a lot of overhead.

Consider the following program fragment in a language that isn't
Inform but is very similar to it. At the beginning, s contains the
address of a Z string that's at least 10 characters long:

for (i = 5 : i < 10 : ++i) {
    s->i = 1 + s->i;
    print (string) s, "^";
}

It wouldn't be difficult to make the compiler emit code that made this
fragment do the intuitively obvious thing. However, to make sure the
code would work (assuming no changes to "print (string)", of course),
it would have to unpack s into a buffer before every access through
"->", and then re-pack it after every such access.

And it wouldn't suffice to have one global buffer in which to
do the unpacking; for this to work with asynchronous access to
several strings simultaneously, we would have to have one buffer for
each string!

One could envision ways of working around this. They would be quite
complex, though, and I'd think they would introduce rather major
changes to the Inform run-time system.

Of course, if compressed strings were used only for *static* text,
then the problem would disappear (only remember to unpack a static
string before copying it to a non-static string variable). But then
you have the problem of where to draw the line between static and
non-static text. I don't think it would be very easy to modify
Inform in such a way that only strings that nobody would ever
want to change were stored as compressed strings. Besides, such 
a change would break a lot of existing code.

(The change I proposed wouldn't break much code, on the other hand,
since very few programs outside of the Library make assumptions
on how packed strings are stored; they just rely on stream 3).


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Fri Jan 22 14:37:10 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36A37AAE.3441C11E@dsres.com>
Date: Mon, 18 Jan 1999 18:17:18 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Version 9: discussion and responses
References: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk> <36A34C61.AA1B4E75@dsres.com> <19990118181530.A18521@bartlet.df.lth.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 3ec34f6015835d7a17cf6552da209e6b


Magnus Olsson wrote:

> Consider the following program fragment in a language that isn't
> Inform but is very similar to it. At the beginning, s contains the
> address of a Z string that's at least 10 characters long:

> for (i = 5 : i < 10 : ++i) {
>     s->i = 1 + s->i;
>     print (string) s, "^";
> }

If you want to do this sort of thing, you don't need to keep packing and
unpacking the string. Simply unpack it once, do all the operations on an
array of characters, and replace the print with a loop doing print_char.
Yes, the printing is less efficient, but not by a huge amount.

I think that losing string compression/obfuscation is a big loss for
such a small win.

--m


From ???@??? Fri Jan 22 14:37:12 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Mon, 18 Jan 1999 19:45:57 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Version 9: discussion and responses
Message-Id: <19990118194557.A6301@bartlet.df.lth.se>
References: <Marcel-1.46-0116110631-d07M+4%@gnelson.demon.co.uk> <36A34C61.AA1B4E75@dsres.com> <19990118181530.A18521@bartlet.df.lth.se> <36A37AAE.3441C11E@dsres.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <36A37AAE.3441C11E@dsres.com>; from Martin Frost on Mon, Jan 18, 1999 at 06:17:18PM +0000
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5a83adebec339fd7e4c685ea9fe35518


On Mon, Jan 18, 1999 at 06:17:18PM +0000, Martin Frost wrote:
> Magnus Olsson wrote:
> 
> > Consider the following program fragment in a language that isn't
> > Inform but is very similar to it. At the beginning, s contains the
> > address of a Z string that's at least 10 characters long:
> 
> > for (i = 5 : i < 10 : ++i) {
> >     s->i = 1 + s->i;
> >     print (string) s, "^";
> > }
> 
> If you want to do this sort of thing, you don't need to keep packing and
> unpacking the string. Simply unpack it once, do all the operations on an
> array of characters, and replace the print with a loop doing print_char.
> Yes, the printing is less efficient, but not by a huge amount.

In *this* case it would work; however, I was using "print (string)"
only as an example. Replace it with an arbitrary function f(s) that
takes a (packed) string argument to get a more general case.

Of course, the programmer could take the trouble to write two versions
of the function f, one that takes a packed string and one that takes
an unpacked one, or he could just write the "unpacked" version and
take care always to unpack the argument before calling f.

But this would be putting a burden on the programmer that should be
carried by the compiler. 

What I'm saying is that to the game programmer, there should be
effectively *one* string datatype, not two ("effectively" meaning that
there could be two actual datatypes, as long as they had the same API
- that is, they'd be polymorphic types), and that that datatype should
be easy to use.

With the current Inform language, there are two very different string
data types, one of which is very difficult to use. You can easily
convert between them, but if you want to automate the conversion
(which scenario was what I was examining with my code fragment) you
end up with large overheads, and if you (as today) tell the programmer
to do the conversions himself, you put a lot of work on the programmer
that should be done transparently by the compiler or by the run-time
system.

So the programmer shouldn't have to replace print (string) with print
(character_array), or f(string s) with f(character array s); he should
be able to use the same function throughout.

> I think that losing string compression/obfuscation is a big loss for
> such a small win.

Obfuscation can be very easily put in, for example by my earlier
proposal to replace the current "fetch" of a Z-code interpreter:

destination = memory[address];

with

destination = memory[address] ^ (address & 0xff);

and the corresponding thing for stores. (Somebody dismissed this as
overly complicated; personally, I can hardly think of a simpler way to
obfuscate things :-) ).

Compression is a different matter, of course; but will the very modest
compression attained by Z-strings really be that important in v9 -
remember that we're going to 32-bit addresses in order to be able to
write games several megabytes in size...

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Fri Jan 22 14:37:20 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <19990118213332.28118.qmail@hotmail.com>
X-Originating-Ip: [144.126.187.238]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Version 9: discussion and responses
Date: Mon, 18 Jan 1999 16:33:31 EST
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: df202d2e5adb021c5a59a460f581febc


>Date: Mon, 18 Jan 1999 19:45:57 +0100
>From: Magnus Olsson <mol@df.lth.se>
>To: z-machine@gmd.de
>Subject: Re: [z-machine] Version 9: discussion and responses
>
>On Mon, Jan 18, 1999 at 06:17:18PM +0000, Martin Frost wrote:
>> Magnus Olsson wrote:

>Compression is a different matter, of course; but will the very modest
>compression attained by Z-strings really be that important in v9 -
>remember that we're going to 32-bit addresses in order to be able to
>write games several megabytes in size...

Before we throw such concerns out the window, I'd just like to note that 
we may be able to WRITE game files several megabytes in size, but
I sure as hell won't be able to DOWNLOAD game files several megabytes in 
size. Even with z9, I'd wager that few games would be "several megabytes 
in size" for some time at least (if nothign else, it takes a  really 
longtime to write a game that big). If there was some way to identify 
string arrays distinctly (I think the current version of inform 
metaclasses both strign arrays and packed strings to "string"), an 
automatic software converter could be written into the veneer (or into 
istring.h if you prefer) and we could be done with it. It would 
certainly be easier for interpreter writers (I think) if we kept the 
string encoding technique the same between versions.

* An aside...
If we're going to do a new version, could we maybe consider putting it 
in writing whether or not the interpreter is supposed to ask the user 
for a filename when the extended @save and @restore are used. There are 
times when I'd like one, and times when I'd like the other, so maybe 
this could be switchable?




______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


From ???@??? Fri Jan 22 14:37:22 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Mon, 18 Jan 1999 22:56:22 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Version 9: discussion and responses
Message-Id: <19990118225622.A31193@bartlet.df.lth.se>
References: <19990118213332.28118.qmail@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <19990118213332.28118.qmail@hotmail.com>; from L. Ross Raszewski on Mon, Jan 18, 1999 at 04:33:31PM -0500
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 2e0b3006e08a3caa3b71a872ad3626e4


On Mon, Jan 18, 1999 at 04:33:31PM -0500, L. Ross Raszewski wrote:
> >Compression is a different matter, of course; but will the very modest
> >compression attained by Z-strings really be that important in v9 -
> >remember that we're going to 32-bit addresses in order to be able to
> >write games several megabytes in size...
> 
> Before we throw such concerns out the window, I'd just like to note that 
> we may be able to WRITE game files several megabytes in size, but
> I sure as hell won't be able to DOWNLOAD game files several megabytes in 
> size. 

Well, if you're after reduced download times/costs/whatever, you
shouldn't have to rely on the built-in string compression, and with at
least the GMD archive you don't have to - all the files there are
gzipped, and you can download the gzipped version just by appending
.gz to the filename in FTP, and then unzip it on your own machine.

Gzipping a file whoch consists mainly of English text will compress
it by typically 70-80%. IIRC, the packed strings in Z files are not
compressed more than 30% or so. 

Any archive storing multi-megabyte z9 files will hopefully do so in
compressed form.

> Even with z9, I'd wager that few games would be "several megabytes 
> in size" for some time at least (if nothign else, it takes a  really 
> longtime to write a game that big). 

Well, z8 allows games up to 512k large, and we've seen several
complaints about that size limit lately. OK, maybe I was exaggerating
a little.


-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Fri Jan 22 14:37:26 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Mon, 18 Jan 1999 22:17:49 +0100 (BST)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: Re: [z-machine] Version 9: discussion and responses
To: Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <199901181628.LAA18150@pond.com>
Message-Id: <Marcel-1.46-0118211749-bc8M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Organization: none
X-Mailer: ANT RISCOS Marcel [ver 1.46]
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 63407a13575b1b8826718b225e7f430e


On Mon 18 Jan, Matthew T. Russotto wrote:
> }> 8. I'd like to add one proposal of my own, a small matter which I
> }> should have mentioned earlier: at present, some interpreters allow
> }> "nested" uses of @output_stream 3 to write text to arrays, and
> }> others don't.  Various features of the Inform library already
> }> need this to work.  I'd like to make it clearly mandatory in any
> }> V9 that we produce.
> 
> }Definitely. Interpreter writers have no excuse for not doing this in a
> }new Version.
> 
> Does the nesting information for stream 3 become part of the state of
> play?
> 
> (For every monkey idea, there's a wrench :-) )

I think the current doctrine is that "save" is permitted only
when stream 1 is selected.  It's a wrench, but you pick it up.

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom


From ???@??? Fri Jan 22 14:37:52 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36A470F9.59A67484@dsres.com>
Date: Tue, 19 Jan 1999 11:48:09 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Version 9: discussion and responses
References: <Marcel-1.46-0118211549-d07M+4%@gnelson.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 13181422fa5f2f79d849a1ce86a7b1e5


Graham Nelson wrote:
> On Mon 18 Jan, Martin Frost wrote:

> > If dynamic allocation is implemented, I would like to see a system
> > like the above, but possibly with a new opcode similar to the UNIX
> > brk() system call, which changes the size of the available address
> > space. This avoids (as was pointed out by someone else) the need
> > for a program which has potentially huge memory requirements to
> > occupy all the space without ever using it on a given run.

> But then we're back to the whole business of story files behaving
> unpredictably and differently on different machines.  The point
> of having an explicit M up front is to be sure that a responsible
> interpreter, at least (and I am also worried about irresponsible
> ones) is able to avoid getting half-way through play and then
> crashing.

I'm suggesting to have two explicit sizes mentioned upfront: a starting
size, which the interpreter should allocate before starting the game,
and a maximum size, which the interpreter should compare against the
likely amount of free memory on the machine and warn the user or refuse
to start as appropriate.

At the very least, the user can be warned before getting half way
through that things may well go wrong at a later stage.

I agree that there is a problem with irresponsible interpreters, though,
but I'm not sure that we should be influencing the design by how *badly*
it could be implemented.

--m


From ???@??? Fri Jan 22 14:37:56 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Tue, 19 Jan 1999 10:51:59 -0500
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: "Matthew T. Russotto" <russotto@pond.com>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
In-Reply-To: <199901152038.PAA13080@pond.com>
Message-Id: <Pine.SGI.4.05.9901191051130.11821-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 8700ea5d453878059e7c5bd85afee406


> } UTF-8 Sounds good.  The Java interpreters writers would sure be happy...
> 
> True, but that's NOT why I picked it :-).  Basically
> 
> 1) It looks like ASCII when only ASCII characters are used
> 2) It's not a big space-waster like 16-bit characters

  ISO-Latin-1 shares these two properties.  Which has the more desireable
bunch of characters in it?


___Dan_Knapp____The_Mauve_Baron______________________Beep Blip Bonk_______
<dankna@bergen.org><dankna@brain.mics.net> http://users.bergen.org/~dankna
My creature... my CREATION... it is DEAD!  Dead, I tell you, dead!


From ???@??? Fri Jan 22 14:38:01 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <000701be43c3$2618dd40$a9054e8c@edvz.unilinz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: <z-machine@gmd.de>
Subject: [z-machine] More V9/10 requests
Date: Tue, 19 Jan 1999 16:47:30 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0810.800
X-Mimeole: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 944738547f3d6c0f30736c50c2026ad2


While we're at it, I'd like to request a TADS-like file I/O. That is, the
game can write (via output_stream) to a file of a specified name WITHOUT the
interpreter asking for confirmation. This could be used (for example) to
read registration keys, save game-specific settings and export character
data from "Part I" for use in "Part II" of a game (which is STILL relevant
even if we have 4 Gigabytes of maximum game size, because all might not get
written at the same time).

And while I'm at that, it'd be nice (but not necessary in any way) if one
could read the current system date and time.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +---------------+------------------------------+
+ Tel: 0732 25 28 57     + ICQ: 22447430 + http://gschmidl.home.ml.org/ +
+------------------------+---------------+------------------------------+




From ???@??? Fri Jan 22 14:38:06 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Tue, 19 Jan 1999 16:15:13 +0000
From: Kevin Bracey <kbracey@e-14.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Message-Id: <ebfeedc648%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <Pine.SGI.4.05.9901191051130.11821-100000@vangogh.bergen.org>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: daabe86d20f5a6f40f095684ee668f8f


In message <Pine.SGI.4.05.9901191051130.11821-100000@vangogh.bergen.org>
          "A.K.A. TheWiz" <dankna@bergen.org> wrote:

> > } UTF-8 Sounds good.  The Java interpreters writers would sure be happy...
> > 
> > True, but that's NOT why I picked it :-).  Basically
> > 
> > 1) It looks like ASCII when only ASCII characters are used
> > 2) It's not a big space-waster like 16-bit characters
> 
>   ISO-Latin-1 shares these two properties.  Which has the more desireable
> bunch of characters in it?
> 

Latin-1 (ISO 8859-1) contains about 190 characters. UTF-8 (ISO/IEC 10646-1)
currently contains around 40000 characters and has room for 2000000000 more.

Don't forget that the Z-machine currently has full Unicode/UCS-2 support
any new version would have to maintain this feature, or it would be a step
backwards.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Fri Jan 22 14:38:10 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Tue, 19 Jan 1999 18:07:40 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] More V9/10 requests
Message-Id: <19990119180740.A8917@bartlet.df.lth.se>
References: <000701be43c3$2618dd40$a9054e8c@edvz.unilinz.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <000701be43c3$2618dd40$a9054e8c@edvz.unilinz.ac.at>; from Gunther Schmidl on Tue, Jan 19, 1999 at 04:47:30PM +0100
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: a5038e7c25a1abe99146064ea1f3f7f0


On Tue, Jan 19, 1999 at 04:47:30PM +0100, Gunther Schmidl wrote:
> While we're at it, I'd like to request a TADS-like file I/O. That is, the
> game can write (via output_stream) to a file of a specified name WITHOUT the
> interpreter asking for confirmation. This could be used (for example) to
> read registration keys, save game-specific settings and export character
> data from "Part I" for use in "Part II" of a game (which is STILL relevant
> even if we have 4 Gigabytes of maximum game size, because all might not get
> written at the same time).

I'd *really* like such a feature. And it would be a fairly minimal change
to the spec (as well as to interpreters), I think.

> And while I'm at that, it'd be nice (but not necessary in any way) if one
> could read the current system date and time.

The trouble with this would be that 
a) Quite likely, some of the machines on which the Z-machine has been
   implemented don't have a system clock. On the other hand, these
   machines may be too small for v9 anyway. Perhaps the hypothetical
   "date" opcode could return some special value in case the host
   machine doesn't have a system clock?

b) It would require some thought to settle on a portable date/time
   format.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Fri Jan 22 14:38:26 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Tue, 19 Jan 1999 10:15:18 -0800
Message-Id: <199901191815.KAA02370@app.dial.idiom.com>
From: Allocation Petrofsky <Allocation@petrofsky.berkeley.ca.us>
To: z-machine@gmd.de
In-Reply-To: <36A470F9.59A67484@dsres.com> (message from Martin Frost on Tue,
	19 Jan 1999 11:48:09 +0000)
Subject: [z-machine] v9 dynamic memory
References: <Marcel-1.46-0118211549-d07M+4%@gnelson.demon.co.uk> <36A470F9.59A67484@dsres.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=NIL
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 15e98cfb20f94f3e6202b50cb0922f2a


According to Martin Frost, Graham Nelson wrote:
> On Mon 18 Jan, Martin Frost wrote:

> > If dynamic allocation is implemented, I would like to see a system
> > like the above, but possibly with a new opcode similar to the UNIX
> > brk() system call, which changes the size of the available address
> > space. This avoids (as was pointed out by someone else) the need
> > for a program which has potentially huge memory requirements to
> > occupy all the space without ever using it on a given run.

> But then we're back to the whole business of story files behaving
> unpredictably and differently on different machines.  The point
> of having an explicit M up front is to be sure that a responsible
> interpreter, at least (and I am also worried about irresponsible
> ones) is able to avoid getting half-way through play and then
> crashing.

[I didn't get Graham's message, so please pardon me if he already
addressed my argument.]

With an opcode, we give the game the power to get any behavior
desired.  If it wants to play it safe, it will immediately allocate
all the memory it might need and never let it go.  If the allocation
fails, it can explain to the player the exact situation, perhaps a
simple "Sorry, your interpreter can't handle the truth" or a more
complicated "I couldn't allocate enough memory to enable the gropzing
nightmare section of the game, would you like to continue without
it?".  If the full allocation does succeed, the game might release
currently unneeded memory in response to the player commanding "memory
hogging off".

-al


From ???@??? Fri Jan 22 14:38:34 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Tue, 19 Jan 1999 14:00:10 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199901191900.OAA18243@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] More V9/10 requests
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: a738751084eb83a4cacc724108f9d7ae


} I'd *really* like such a feature. And it would be a fairly minimal change
} to the spec (as well as to interpreters), I think.

I think two opcodes, "open" and "close", to set up the file name/stream #
mapping and relinquish it, and a capability word bit in Flags 2, might
do it.  I'd also suggest this one be implemented in Standard 1.x for
V5/8 as well.

}b) It would require some thought to settle on a portable date/time
}   format.

How about YYMMDDHHMMSS :-)

BTW, did my massive post get out?  


From ???@??? Fri Jan 22 14:38:40 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Tue, 19 Jan 1999 20:37:36 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] More V9/10 requests
Message-Id: <19990119203736.A7696@bartlet.df.lth.se>
References: <199901191900.OAA18243@pond.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
In-Reply-To: <199901191900.OAA18243@pond.com>; from Matthew T. Russotto on Tue, Jan 19, 1999 at 02:00:10PM -0500
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 6396560d97eb43c0c238cf79feb3b7a3


On Tue, Jan 19, 1999 at 02:00:10PM -0500, Matthew T. Russotto wrote:
> }b) It would require some thought to settle on a portable date/time
> }   format.
> 
> How about YYMMDDHHMMSS :-)

That's fine and portable, as long as you don't want to do arithmetic
on dates.

> BTW, did my massive post get out?  

Which massive post?

I'm afraid I've missed a few messages today - I've seen one or two
replies to messages I haven't seen, and I haven't seen any massive
mail from Matthew either :-(.

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Fri Jan 22 14:38:46 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Tue, 19 Jan 1999 12:29:32 -0800 (PST)
From: "Jakob 'sparky' Kaivo" <jake@nodomainname.net>
To: Magnus Olsson <mol@df.lth.se>
Cc: z-machine@gmd.de
Subject: Re: [z-machine] More V9/10 requests
In-Reply-To: <19990119203736.A7696@bartlet.df.lth.se>
Message-Id: <Pine.LNX.4.04.9901191227350.26541-100000@elijah.nodomainname.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 4a2cf5e9011512db15f868413ce6bb69


On Tue, 19 Jan 1999, Magnus Olsson wrote:

> On Tue, Jan 19, 1999 at 02:00:10PM -0500, Matthew T. Russotto wrote:
> > }b) It would require some thought to settle on a portable date/time
> > }   format.
> > 
> > How about YYMMDDHHMMSS :-)
> 
> That's fine and portable, as long as you don't want to do arithmetic
> on dates.

With a little trickery you can do arithmetic on it. But it won't last 12
months. :( I prefer:

YYYYMMDDHHMMSS.ss

Mostly explanatory, expect maybe ss (1/100ths of a second). I personally
don't care about any Y10k issues, so YYYY should be good enough for the
next 8 thousand years. :)

+-----------------------------+--------------------------------+
| Jakob 'sparky' Kaivo        |          jake@nodomainname.net |
| NoDomainName Networks       |    http://www.nodomainname.net |
| AtDot E-mail Services       |           http://www.atdot.org |
+-----------------------------+--------------------------------+


From ???@??? Fri Jan 22 14:38:52 1999
Return-Path: owner-z-machine@omega.gmd.de
From: John Elliott <jce@seasip.demon.co.uk>
Message-Id: <199901192006.UAA02248@seasip.demon.co.uk>
Subject: Re: [z-machine] More V9/10 requests
To: z-machine@gmd.de
Date: Tue, 19 Jan 1999 20:06:44 +0000 (GMT)
In-Reply-To: <000701be43c3$2618dd40$a9054e8c@edvz.unilinz.ac.at> from "Gunther Schmidl" at Jan 19, 99 04:47:30 pm
Content-Type: text
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: f146529e365646f23197c1bfc61bce6a


  I tried posting this suggestion before, but checking my mail records I
see it got sent to Matthew Russotto rather than to the list.

  I'd like to suggest a "gestalt" opcode to check for future features,
and/or features specific to a single interpreter. IMO this is simpler than
reserving header bits.
  In the example below, I've imagined it as a jump-type opcode called
@check_extension. The only change immediately necessary would be to
implement the opcode as "jump never" on existing interpreters.

 [ HTML_Output;

    @check_extension 1213484364 ?Allow_html;   ! 1213484364 == 'HTML'
    @output_stream 1;
    rfalse;

    .Allow_html;
    @output_stream 5;
    rtrue;
 ];

(I also suggested the 'Z' in the second byte of the header, and disallowing
 using the header bit to change the font. Both of these appeared in
 Mr. Russotto's spec.)

------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott           |BLOODNOK: "But why have you got such a long face?"
                       |SEAGOON: "Heavy dentures, Sir!"    - The Goon Show 
:-------------------------------------------------------------------------)


From ???@??? Fri Jan 22 14:38:57 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <19990119201249.28529.qmail@hotmail.com>
X-Originating-Ip: [144.126.187.238]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] More V9/10 requests
Date: Tue, 19 Jan 1999 15:12:49 EST
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: a73eae8dac02ec500a409468d83813a0


While we're all excited about these new things goign on in Z, there's 
been something I've sort of wanted in inform for a while, that I thought 
I'd bring up, because I don't know if there are any drawbacks I've 
neglected to think of...

I'd like there to be some sort of keyword which could be used to create 
an object without creatign a property table. (ie Just create the object 
header.  the property table element of the header could be set to point 
to an empty one that inform has lying around)

THere's method to my madness, believe it or not; While I was working on 
imem, it occured to me that using similar principles, I could write a 
much more effective and user friendly dynamic object creator. With 
theproposal that v9 include dynamic memory, I'd really like to implement 
this, but I don't want to bloat story files with lots of duplicate empty 
property tables.

If it were possible to create these "en masse", such as 

Header(30) has x;

 to create 30 "blank" objects with the X attribute set (attributes are 
part of the object header) 
that would be even more helpful to my plans.

So, am I overlooking something? Is this a reasonable idea?
Thanks.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


From ???@??? Fri Jan 22 14:38:59 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <002201be43eb$f5d36500$9a054e8c@edvz.unilinz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: <z-machine@gmd.de>
Subject: Re: [z-machine] More V9/10 requests
Date: Tue, 19 Jan 1999 21:40:07 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0810.800
X-Mimeole: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 2fc407c0e0460d2d3e667401ad18765b


Matthew T. Russotto writes (about the date/time format):

>How about YYMMDDHHMMSS :-)
>

YYYYMMDDHHMMSS if anything.

(Eeeagh! Y2K!)

If we go for year-2000-compability in the serial number, we should go all
the way.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +---------------+------------------------------+
+ Tel: 0732 25 28 57     + ICQ: 22447430 + http://gschmidl.home.ml.org/ +
+------------------------+---------------+------------------------------+




From ???@??? Fri Jan 22 14:39:02 1999
Return-Path: owner-z-machine@omega.gmd.de
From: "Lucian P. Smith" <lpsmith@bioc.rice.edu>
Message-Id: <199901192045.OAA23979@heme.bioc.rice.edu>
Subject: Re: [z-machine] More V9/10 requests
To: z-machine@gmd.de
Date: Tue, 19 Jan 1999 14:45:01 -0600 (CST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 783ebabfbe546d0d408cc1e09a688d14


[Hey, hello everyone!  Just signed up to lurk, but got pulled in anyway.
Here goes,...]

Magnus wrote:
> 
> On Tue, Jan 19, 1999 at 04:47:30PM +0100, Gunther Schmidl wrote:
> > While we're at it, I'd like to request a TADS-like file I/O. That is, the
> > game can write (via output_stream) to a file of a specified name WITHOUT the
> > interpreter asking for confirmation. 

<snip>

> I'd *really* like such a feature. And it would be a fairly minimal change
> to the spec (as well as to interpreters), I think.

Just to confirm here:  would this be a retro-feature of the Z-machine in
general?  Or just of the new v9/v10?

Also, IIRC, Zork Zero did *not* prompt for filenames when it used 'em.
Haven't tried playing in on, say, WinFrotz to see how modern interpreters
handle it, or, indeed, how to trigger the behavior.

Personally, I'd like the option to prompt or not for filenames.  For output
like rating.txt from the Comp9x games, prompting is appropriate.  For games
with multiple sections/multiple authors/whatever, it might be nicer to just
write and read the files, behind the scenes.

Would it be possible to make it legal but optional for interpreter writers
to force one or the other, as a user setting for paranoid users?

And, while we're on the topic, would it be possible for an unscrupulous
Inform author to plant a virus on a host computer, if they happened upon the
correct architecture?  How are these things caught?

> b) It would require some thought to settle on a portable date/time
>    format.

Yeah!  We only have 11.5 months left to introduce a Y2K bug into Inform!
Let's hop to!

-Lucian


From ???@??? Fri Jan 22 14:39:08 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <004e01be43f6$55799600$9a054e8c@edvz.unilinz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: <z-machine@gmd.de>
Subject: [z-machine] V10
Date: Tue, 19 Jan 1999 22:54:42 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0810.800
X-Mimeole: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 10852a4dd03f34c9d440fc5ee8322549


Ok, I just had another idea.

The V6 screen model is, and you will hopefully agree, a pain in the ass.
This causes the problem that nobody is willing to actually WRITE an
interpreter that handles Blorb with V6.

So how about we ditch this screen model in favour for a better one in V10?

We could either keep the opcodes that are currently used, or keep those for
V6 backwards compatibility and create completely new ones for V10.

A quick poll shows demand for these features:

* a (theoretically) unlimited number of windows, as opposed to the 8 that V6
gives you.

* a fixed color model that actually works the same way on every interpreter,
unlike the difference between Amiga V6 and MCGA V6.

* an increased number of colours? 16 seems very few for today's standards.
I'd say at least 256, if not 65536.

* transparent bitmaps, and the ability to overlay

* a transparent colour

---

We might also want to think about an improved sound model that can play
several sounds at the same time *and* background music. Sorry if this is
already possible; I can't really read this out of the spec.

---

Now, I have no idea if Glk fits anywhere into this, but I hope Zarf will be
able to tell.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +---------------+------------------------------+
+ Tel: 0732 25 28 57     + ICQ: 22447430 + http://gschmidl.home.ml.org/ +
+------------------------+---------------+------------------------------+




From ???@??? Fri Jan 22 14:39:13 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <000c01be4405$c4460140$591e39cb@paul.hdc.com.au>
From: "Paul Gilbert" <pfg@hdc.com.au>
To: <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for a proposal for Version 9
Date: Wed, 20 Jan 1999 10:45:15 +1100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 501c502ad092a15599b62ae513a0d3d7



-----Original Message-----
From: Kevin Bracey <kbracey@e-14.com>
To: z-machine@gmd.de <z-machine@gmd.de>
Date: Wednesday, 20 January 1999 3:47
Subject: Re: [z-machine] Proposal for a proposal for Version 9


>In message <Pine.SGI.4.05.9901191051130.11821-100000@vangogh.bergen.org>
>          "A.K.A. TheWiz" <dankna@bergen.org> wrote:
>
>> > } UTF-8 Sounds good.  The Java interpreters writers would sure be
happy...
>> >
>> > True, but that's NOT why I picked it :-).  Basically
>> >
>> > 1) It looks like ASCII when only ASCII characters are used
>> > 2) It's not a big space-waster like 16-bit characters
>>
>>   ISO-Latin-1 shares these two properties.  Which has the more desireable
>> bunch of characters in it?
>>
>
>Latin-1 (ISO 8859-1) contains about 190 characters. UTF-8 (ISO/IEC 10646-1)
>currently contains around 40000 characters and has room for 2000000000
more.
>
>Don't forget that the Z-machine currently has full Unicode/UCS-2 support
>any new version would have to maintain this feature, or it would be a step
>backwards.
>


In relation to some earlier messages, one of the desirabilities for having
uncompressed text strings would be simplifying string manipulation. How much
would the process be complicated if we allow a variable-size character in
strings; it would certainly prevent being able to access character positions
by index, and be a step back towards the problems of string handling on
encoded z-text.

I'm sort of leaning towards thinking it might be nice to go to full Unicode
or full ASCII 1-byte characters [with a predefined Unicode subset for the
upper 80h characters] for strings. Perhaps with a flag in the header to
signify which text type is being used. This would provide immediate
compression for games which used straight standard english characters,
whilst leaving open the possibility of full Unicode for those who want it.

Full Unicode could pose size problems, especially if few non-ascii subset
Unicode characters are used in the gamefile. I can't see how we can really
find a common point of keeping size down without sacrificing string handling
ease.

>--
>Kevin Bracey, Senior Software Engineer
>Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
>Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
>Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/



From ???@??? Fri Jan 22 14:39:16 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901200112.UAA26063@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Tue, 19 Jan 1999 20:13:31 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] V10
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <004e01be43f6$55799600$9a054e8c@edvz.unilinz.ac.at>
X-Mailer: Pegasus Mail for Win32 (v3.01b)
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 45d1c038c13798a4def41b2eac49d5b3


Just a few comments on this...

Gunther Schmidl sent a message across the ether on 19 Jan 99, (22:54) 
stating:

> Ok, I just had another idea.
> 
> The V6 screen model is, and you will hopefully agree, a pain in the ass.
> This causes the problem that nobody is willing to actually WRITE an
> interpreter that handles Blorb with V6.
> 
> So how about we ditch this screen model in favour for a better one in V10?

As I said originally, "While it would be nice to 'fix' V6 up a bit at 
the same time it seems that V6 as it stands is more than enough work on 
it's own, but if  an interpreter supported V6 and V9 it would seem that 
combining the two would be semi-trivial (maybe I'm way off the mark, I 
don't know)".  And I still stand by that (but that is of course just my 
opinion).  Since there is one V6/Blorb interpreter, and there are 
rumblings of others in the making, I'm not sure this would be too good 
of an idea.  

> * a (theoretically) unlimited number of windows, as opposed to the 8 
that V6
> gives you.

I really have no opinion on this one.  I think you could 'fake' an 
infinite number of windows with the current model if you were careful.
 
> * a fixed color model that actually works the same way on every interpreter,
> unlike the difference between Amiga V6 and MCGA V6.

This problem could be solved by everyone agreeing to emulate one screen 
model.  (This was in a proposal I made a good long time ago which I've 
been looking for to repost).  MCGA mode probably the way to go for a 
number of reasons.  Amiga mode has limitations based on Amiga hardware 
that just don't make sense on other machines, and can be overcome by 
newer Amigas.

> * an increased number of colours? 16 seems very few for today's standards.
> I'd say at least 256, if not 65536.

Theoretically there was no color limit in MCGA mode, excepting that 
MCGA can only display x number of colors.  

> * transparent bitmaps, and the ability to overlay

This exists in V6 already.

> * a transparent colour

For images this exists, for text it does not (does it make any sense to 
exist as a font color?)
 
> We might also want to think about an improved sound model that can play
> several sounds at the same time *and* background music. Sorry if this is
> already possible; I can't really read this out of the spec.

This goes along with something I suggested before as well...  In fact, 
I'm off to dig that proposal up again.

Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor


From ???@??? Fri Jan 22 14:39:19 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901200130.UAA26311@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Tue, 19 Jan 1999 20:30:42 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: [z-machine] V10 proposals...
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v3.01b)
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: a68a84efa901e136b0c67a24468c2614


Hello again,

	First I'd like to address Gunther's point about the different 
machine modes.  The discussions about this before all pretty much 
boiled down the the following 

Long ago Andrew Plotkin asked:

> Now, if we ignore that one display mode [Amiga Mode] -- with its two-color limit,
> etc -- can we write to the Z-Spec and not worry about machine numbers
> any more? 

And I replied:

> More or less, everything becomes peachy.  

Now on with the show

Minor additions to V6 I'd like to see in V10 as a result of all the 
hashing about that went on before...


1)	Bit 6 of 'flags 1' is undefined in V4+

	Define it to be a 'Full font style combination support?' flag. 

	If this bit is set the interpreter should follow the "Ideal" model 	
	set	out by the ZSpec, "all text styles should be available for each 
	font (for instance, Courier bold should be obtainable) except that 	
	font 3 need only be available in Roman and Reverse Video".  If the 	
	interpreter is unable to fully comply with this the bit should be 	
	left unset, and game authors should take this to mean that they 	
	can't count on anything in this respect (which is how it is 		
	currently).   

2)	add a bit to 'flags 2'.  If the game wants to use music it should 	
	set this bit, the interpreter should clear it if it can't play 		
	music.  (If proposal 4 is adopted, this should tie in with it, if 	
	not it still stands on it's own to say that files identified as 	
	music in a blorb file can still be played by the interpreter)  (see 
	Blorb Spec, 11)

3)	extend @sound_effect:

	  @sound_effect n 3 with n > 0
	  ...stops sound_effect #n only

	  @sound_effect 0 3
	  ...stops all sound effects 

	This would allow multiple sound effects (if the interpreter 		
	supports this there would need to be a way to signal the this as 	
	well, maybe another header bit).

4)	Add a separate opcode for music (@sound_music?)

	It would be the same, or very similar to @sound_effect, but 		
	allows the music system of the 	interpreter to work independently 	
	of the sound effect system.  (interpreters need only support 		
	this opcode if they set the 'can play music flag', otherwise they 	
	should just treat it as a nop or something, I think.)    

That's about it,
Jay

----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor


From ???@??? Fri Jan 22 14:39:32 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <005701be444c$62d0b1c0$8f054e8c@edvz.unilinz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: "Jason C Penney" <jpenney@chelmsford.com>,
        "Z-Machine Mailing List" <z-machine@gmd.de>
Subject: Re: [z-machine] V10
Date: Wed, 20 Jan 1999 09:02:03 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0810.800
X-Mimeole: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5c1c43fbfacfe99ecf45cdb5feca3dab


>As I said originally, "While it would be nice to 'fix' V6 up a bit at
>the same time it seems that V6 as it stands is more than enough work on
>it's own, but if  an interpreter supported V6 and V9 it would seem that
>combining the two would be semi-trivial (maybe I'm way off the mark, I
>don't know)".  And I still stand by that (but that is of course just my
>opinion).  Since there is one V6/Blorb interpreter, and there are
>rumblings of others in the making, I'm not sure this would be too good
>of an idea.

Those who ARE writing those Blorb and/or Glk interpreters liked the idea. At
least the three I talked to.

The proposals I posted were from a discussion held on ifMUD on what we'd all
like to see in a graphical V10. If V6 supports some of these things already,
all the better; however, everyone agreed that the V6 screen model is much
more of a pain to implement than one based on Glk would be (of course, Glk
would propably have to be changed, too).

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +---------------+------------------------------+
+ Tel: 0732 25 28 57     + ICQ: 22447430 + http://gschmidl.home.ml.org/ +
+------------------------+---------------+------------------------------+



From ???@??? Fri Jan 22 14:39:41 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Wed, 20 Jan 1999 10:47:35 +0000
From: Kevin Bracey <kbracey@e-14.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] V10
Message-Id: <1ad653c748%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <004e01be43f6$55799600$9a054e8c@edvz.unilinz.ac.at>
X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom
X-Mailer: Messenger v1.40a for RISC OS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.60l
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: f173f4e0929829bc3442c5218a7de27b


In message <004e01be43f6$55799600$9a054e8c@edvz.unilinz.ac.at>
          "Gunther Schmidl" <sothoth@usa.net> wrote:

> Ok, I just had another idea.
> 
> The V6 screen model is, and you will hopefully agree, a pain in the ass.
> This causes the problem that nobody is willing to actually WRITE an
> interpreter that handles Blorb with V6.

Oy! Ref! Zip 2000 has been doing V6 for over 3 years now, and has had
Blorb sound effect and graphics support for 5 months. And the source is
available. It's not that hard.

-- 
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd                           Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road               Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Fri Jan 22 14:39:46 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36A5C051.5184E28B@dsres.com>
Date: Wed, 20 Jan 1999 11:38:57 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] More V9/10 requests
References: <Pine.LNX.4.04.9901191227350.26541-100000@elijah.nodomainname.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 4d4eb8440d1182108c41e01f7098b19d


Jakob 'sparky' Kaivo wrote:

[portable date format]

> YYYYMMDDHHMMSS.ss

How about (for more use in lower-level programs, etc) a table of normal
16-bit integers (or even 8-bit if year is defined from 1900).

Seems to make more sense (if people want to print it out then they can
do so without much trouble, and parsing it is unnecessary if arithmetic
is required).

Much like the ANSI C struct tm, in fact.

--m


From ???@??? Fri Jan 22 14:39:48 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Wed, 20 Jan 1999 09:04:10 -0500
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Jason C Penney <jpenney@chelmsford.com>
Cc: Z-Machine Mailing List <z-machine@gmd.de>
Subject: Re: [z-machine] V10
In-Reply-To: <199901200112.UAA26063@ns.chelmsford.com>
Message-Id: <Pine.SGI.4.05.9901200900550.2051-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: b5a876643e5d79b2aa7ae5d20abbbac3


> > * a transparent colour
> 
> For images this exists, for text it does not (does it make any sense to 
> exist as a font color?)

  Yes, actually, if it's superposed on another bitmap.  Some commercial
PostScript drawing program has a "paper" color which erases anything under it,
and I'd suggest stealing the idea; it could be used to create "see-through"
text which reveals things in the layer under it.  Note in replies that I'm
unfamiliar with v6.


___Dan_Knapp____The_Mauve_Baron______________________Beep Blip Bonk_______
<dankna@bergen.org><dankna@brain.mics.net> http://users.bergen.org/~dankna
This is a quiz.  This is only a quiz.  Had this been an actual test...


From ???@??? Fri Jan 22 14:40:29 1999
Return-Path: owner-z-machine@omega.gmd.de
From: jwkenne@ibm.net
Message-Id: <199901211900.OAA000.99@MYHOSTNAME.ibm.net>
Mime-Version: 1.0
Date: Thu, 21 Jan 99 12:54:17 -0400
To: z-machine@gmd.de
Reply-To: ibm.net@ibm.net
Subject: Re: [z-machine] Version 9: discussion and responses
X-Mailer: Ultimedia Mail/2 Lite, IBM T. J. Watson Research Center
Content-Id: <40_86_4_916941257>
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 59165ea8597319fbd3ace13b7ab2dc5e


>(i) A 32-bit structure seems to be generally acceptable.

Indeed, I think it a sine qua non.

>(ii) The proposal for the top bit to indicate a very primitive
>form of data typing seems less acceptable, or at any rate has
>been less discussed.

I have no real problem with this; the JAVA-based interpreter I've been
slowly putting together would, for example, have no technical problem.

On the other hand, the concept conflicts with the FP suggestion, not
only because IEEE wouldn't allow it (and is there any real point to
doing it non-IEEE?), but, more to the point, because one bit would no
longer make an adequate tag.  If floating-point were ever to be a
possibility, I think an entire nibble or byte would have to be reserved.
(Let's face it -- is a >16MB game realistic?)

>1. More attributes (possibly "infinitely many", with a header
>byte giving the number of bytes used for attribute storage).

>1. I have no strong preference.  Perhaps a compromise measure
>would be to double the number of attributes to 96, stored in
>a twelve-byte block, since we seem to be doubling things.
>Nobody has ever emailed me to complain about shortage of
>attributes, in any event.

Looking at the library, I've had the feeling that the attribute
table looked crowded."  I think 96 would be adequate, but
I also think a header-defined limit would be just about as easy
to implement.

>2. More common properties, perhaps up to 65535 of them.

>2. Inform doesn't need this and wouldn't use it.  I prefer a
>small table which is rapidly readable, but I'm open to
>persuasion.

I'm inclined to agree.  How many properties are truly common?

>3. Dynamic memory allocation.  But Jakob Kaivo suggests doing this
>in software.  (And I agree.  But see my counter-proposal 3a.)

>3. I am opposed to dynamic memory allocation, but if we must have
>it -- and I can see that there are arguments in favour -- I
>propose the following minimal system:

>  3a.  A word in the header of the story file contains a number M.
>  The extent of the story file is considered to be the extent of
>  the actual file as stored on disc, plus M zero bytes stored at
>  the top of memory.  In this way, an interpreter could know
>  immediately whether there will ever be a memory problem in
>  running the story file, and we can avoid the nightmare of memory
>  running out on one machine but not another, which has plagued
>  the TADS run-time system in the past.

>Let me emphasize that I'm not persuaded of the need for dynamic
>memory allocation at all, but if we're going to do it, then
>something very carefully circumscribed seems wise.

Again, I'm inclined to agree.  Is dynamic memory actually needed,
now that lifted memory restrictions would allow fairly unlimited
use of Inform's existing semi-dynamic facilities?

>4. Floating-point support.  But Magnus Olsson suggests doing this
>in software.

>4. Floating-point support should be handled in software (as it
>was for all early processors and some processors still, e.g. the
>ARM processor running in the machine I'm typing this on).  My
>reasons for this are: (i) we are not writing real-time, texture
>mapped games here, and don't need ultra-fast floating point
>support; (ii) it would be bound to get us into nasty issues of
>how to store "double floats"; (iii) it would be almost impossible
>to make floating-point support platform independent.  And this
>is important.  The only time I've wanted f.p. in one of my own
>games was the flying-the-B52 puzzle from "Jigsaw", which needs
>to keep taking inverse tangents.  Lord, but this was a nightmare
>puzzle to debug: I kept having to take care to avoid divisions
>by zero, in particular.  If the situation had been that the
>calculations would only nearly come out equal on different
>machines, this error would have been much harder to avoid.

Is there any 8/16/32 platform that, if it supports FP at all,
doesn't support IEEE?  (I know IBM mainframes have finally gotten
around to it.)

But I confess, I'd much rather see decimal fixed-point arithmetic
and a PICTURE feature (as in COBOL, PL/I, or Ada 95).  Surely
we need to deal with money more than with cosines?  (This is
not really a serious proposal for the Z-machine, though I'd like
to see at least a little such support in the library.)

>5. Storing strings in unencrypted form with 1 byte per character,
>or perhaps using a Unicode format.  Misunderstandings about the
>meaning of the word "encryption" have confused the matter: the
>present situation doesn't remotely qualify under export bans on
>encryption, and is not intended for security but only compression.

>5. I am unpersuaded.  The present arrangement seems fine to me.

For the most part, yes, once one has the stream-3 trick down pat.

Perhaps, however, a change could be made so that the alphabet tables
are in Unicode, thus massively simplifying games with large amounts
of text in non-Latin alphabets.  Practical implementation, of this,
however, would mean large changes to Inform.

>6. Jason Penney suggests creating a Version 10 at the same time
>as Version 9, consisting of V9 plus the V6 graphics and sound
>support.

>6. I support this.

So do I.  If a new graphics model is to be constructed, let it be
done separately, as Version 11, rather than send the message that
all current Inform work on V6 is doomed.

>7. That perhaps all of memory should be writeable?

>7. I oppose this, on the grounds that the present arrangement is
>a good one for putting together and restoring saved-game files.
>(If you want to write self-modifying code, you can already.
>Just write it into an array and call it!)  I do want every byte
>to be readable, though.

Again, I agree.

>8. I'd like to add one proposal of my own, a small matter which I
>should have mentioned earlier: at present, some interpreters allow
>"nested" uses of @output_stream 3 to write text to arrays, and
>others don't.  Various features of the Inform library already
>need this to work.  I'd like to make it clearly mandatory in any
>V9 that we produce.

>8. Surprisingly enough, I support this one.

I thought version 1.0 of the Standard mandated this for all Z-machine
versions already.

// John W Kennedy


From ???@??? Fri Jan 22 18:53:53 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901220605.TAA20944@smtp2.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 22 Jan 1999 18:03:37 +1300
To: Z-Machine List <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Version 9: discussion and responses
In-Reply-To: <36A470F9.59A67484@dsres.com>
References: <Marcel-1.46-0118211549-d07M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: b4dc62578174d5bfd206bb20e8e3556d


At 11:48 19/01/99 +0000, Martin Frost wrote:
>
>I'm suggesting to have two explicit sizes mentioned upfront: a
starting
>size, which the interpreter should allocate before starting the
game,
>and a maximum size, which the interpreter should compare against
the
>likely amount of free memory on the machine and warn the user or
refuse
>to start as appropriate.
>
>At the very least, the user can be warned before getting half way
>through that things may well go wrong at a later stage.

It always annoys me when I find a game that absolutely refuses to run
when I'm a little short on memory, especially when I know that it
won't necessarily be using all that memory immediately, but may use
it for some sequence that I won't get to until a later session, when
I will have enough memory.

The sort of thing I'd like to see (though I have no idea how
implementable it would be) is to have the interpreter warn the user
if it doesn't have sufficient memory to cover *all* the dynamic space
requested, but can still run.  If the game requests a dynamic
allocation and the interpreter is unable to fill it, it calls a
routine (either in the game or the library) that allows some graceful
exit from the situation.  Perhaps something along the lines of "There
is insufficient memory available to do that command." and a return to
the command prompt, or "Unable to continue with game due to lack of
memory, do you want to save here and continue when you have enough?",
or, if the game handled it, some detection that there wasn't enough
memory, so a different approach is used (perhaps a simple "It Is
Done." rather than a three-part fanfare while fireworks go off in the
background).

I prefer the latter approach, though it does place a slightly higher
burden on the game writer.  And yes, this does mean that results can
vary slightly between computers, but that is why I prefer the latter,
because it allows the game to continue.  Actually, for this approach
the notification can be made as a "return value" for the dynamic
allocation opcode, similar to C's malloc() returning 0 if it couldn't
allocate memory.  It is then up to the game to decide if it can live
without that memory or if it is critical to gameplay.


-- 
Gavin Lambert
uecasm@geocities.com
<http://crash.ihug.co.nz/~brianc/>
Mirabilis ICQ UIN: 2274180  (check out <http://www.mirabilis.com>)
Fight spam!  Support an email amendment at <http://www.cauce.org/>

----
Insurance Claim: "I ran into a lamppost that was obscured by human
beings."

"It's this whole big eternity thing and I'm at the wrong end of it."
--  Mike Ruete

Help: It said "Insert disk no.3", but only two will fit in the
drive!
----

The above quotes have been randomly selected from a huge list.
I apologize if you find some of them offensive.


From ???@??? Fri Jan 22 19:13:33 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901220652.TAA26166@smtp2.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Fri, 22 Jan 1999 18:41:39 +1300
To: Z-Machine List <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] V10
In-Reply-To: <004e01be43f6$55799600$9a054e8c@edvz.unilinz.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 30245392b2dccd6d3aa66aca9c06a083


At 22:54 19/01/99 +0100, Gunther Schmidl wrote:
>
>* an increased number of colours? 16 seems very few for today's
standards.
>I'd say at least 256, if not 65536.

Why not go whole hawg and support full 24-bit TrueColor?  Most
graphics-capable OSes support it (that I know of, at least), even if
the actual hardware does not (and in case you're wondering, mine
doesn't).

Those interpreters unable to display 24-bit colour can just do a
nearest-colour reduction, or they could dither images if they really
wanted to.

Later, "Jason C Penney" <jpenney@chelmsford.com> replied:
Theoretically there was no color limit in MCGA mode, excepting that 
MCGA can only display x number of colors.  

VGA and SVGA are the same, and the interpreter *could* be written so
as to keep an optimal-colour palette in use, and
nearest-colour-reducing to display images, and updating the palette
whenever a new image is loaded.  (I personally wouldn't know where to
start, but it can be done)

-- 
Gavin Lambert
uecasm@geocities.com
<http://crash.ihug.co.nz/~brianc/>
Mirabilis ICQ UIN: 2274180  (check out <http://www.mirabilis.com>)
Fight spam!  Support an email amendment at <http://www.cauce.org/>

----
When there are sufficient funds in the checking account, checks take
two weeks to clear.  When there are insufficient funds, checks clear
overnight. 

If it's stupid, but it works, then it's not stupid.

This will be a memorable month -- no matter how hard you try to
forget it.
----

The above quotes have been randomly selected from a huge list.
I apologize if you find some of them offensive.


859-1
From ???@??? Sat Jan 30 10:49:18 1999
Return-Path: owner-z-machine@omega.gmd.de
From: katre <katre@mousetrap.c64.org>
Message-Id: <199901221430.JAA14803@mousetrap.c64.org>
Subject: Re: [z-machine] V10
To: z-machine@gmd.de
Date: Fri, 22 Jan 1999 09:30:32 -0500 (EST)
Cc: katre@mousetrap.c64.org
In-Reply-To: <199901220652.TAA26166@smtp2.ihug.co.nz> from "Gavin Lambert" at Jan 22, 99 06:41:39 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5015094e6b7de89dc33bd40136191b17



[Long discussion of color snipped]

After thinking on color, V6/10, and blorb, I realized there would be two types
of games.  Games that don't use many colors, and games (like some I'm
planning) that will use millions.  So why not just have a flat basis set of,
say, 256 colors, for the former, and for the latter, use the palette
information given by a blorb file.  This way, the game writer can choose what
colors he wants, if he cares enough, but those who don't don't have 64k colors
wasting their resources?

katre


From ???@??? Sat Jan 30 10:52:42 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <001501be4b92$545c5c00$ac054e8c@edvz.unilinz.ac.at>
From: "Gunther Schmidl" <sothoth@usa.net>
To: <z-machine@gmd.de>
Subject: [z-machine] V9/10: Game state
Date: Fri, 29 Jan 1999 15:18:46 +0100
Mime-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0810.800
X-Mimeole: Produced By Microsoft MimeOLE V5.00.0810.800
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 974eb602ccde497d4c7772cf931aeaa3


With the recent batch of games that support color (including works of
progress), it has become clear that interpreters don't handle them correctly
in combination with SAVE, RESTORE and UNDO.

I notice with some distress that of the interpreters that I know of, only
one is able to correctly handle color in all instances (except with the
aforementioned SAVE, RESTORE and UNDO), and that is FROTZ 2.32 for DOS.

Therefore I propose adding the current fore- and background color to the
game state to amend this problem.

And while I'm at it, would a larger zmachine allow for multiple UNDOs as
TADS does? Or would that be a pain in the ass? I know FROTZ can do it, but
of course, this also breaks colors.

+------------------------+----------------------------------------------+
+ Gunther Schmidl        + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 +  except temptation"           -- Oscar Wilde +
+ A-4040 LINZ            +---------------+------------------------------+
+ Tel: 0732 25 28 57     + ICQ: 22447430 + http://gschmidl.home.ml.org/ +
+------------------------+---------------+------------------------------+



From ???@??? Sat Jan 30 10:52:44 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Fri, 29 Jan 1999 09:52:13 -0500 (EST)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <199901291452.JAA25712@pond.com>
To: sothoth@usa.net, z-machine@gmd.de
Subject: Re:  [z-machine] V9/10: Game state
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 054e5cfead831da710e040a2388d9e1a


} Therefore I propose adding the current fore- and background color to the
} game state to amend this problem.

None of the other text stuff is part of the game state, I don't think
current fore- and background color should be either. 

} And while I'm at it, would a larger zmachine allow for multiple UNDOs as
} TADS does? Or would that be a pain in the ass? I know FROTZ can do it, but
} of course, this also breaks colors.

Multiple UNDO is a separate issue.  With a small modification to the
Inform library and interpreters, it can be done now.


From ???@??? Sat Jan 30 10:52:45 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <oqgQxNS00UwA0_a1k0@andrew.cmu.edu>
Date: Fri, 29 Jan 1999 10:10:17 -0500 (EST)
From: Evin C Robertson <ecr+@andrew.cmu.edu>
To: z-machine@gmd.de
Subject: Re: [z-machine] V9/10: Game state
In-Reply-To: <001501be4b92$545c5c00$ac054e8c@edvz.unilinz.ac.at>
References: <001501be4b92$545c5c00$ac054e8c@edvz.unilinz.ac.at>
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: cef9d2dd954e34aecf21374d67177b6b


Excerpts from mail: 29-Jan-99 [z-machine] V9/10: Game state by "Gunther
Schmidl"@usa.ne 
> With the recent batch of games that support color (including works of
> progress), it has become clear that interpreters don't handle them
> correctly in combination with SAVE, RESTORE and UNDO.

A game is responsible for drawing its screen after restore/undo, not the
interpreter.  If the colors are wrong after a restore/undo, it is the
responsibility of the game to draw these colors, just as it is its
responisibility to draw everything else on the screen.

If your game doesn't redraw its colors, your game is at fault, not the
z-machine or interpreter.

> I notice with some distress that of the interpreters that I know of, only
> one is able to correctly handle color in all instances (except with the
> aforementioned SAVE, RESTORE and UNDO), and that is FROTZ 2.32 for DOS.
>  
> Therefore I propose adding the current fore- and background color to the
> game state to amend this problem.

The window split and the text in each window are not saved; color should
be no different.

> And while I'm at it, would a larger zmachine allow for multiple UNDOs as
> TADS does? Or would that be a pain in the ass? I know FROTZ can do it, but
> of course, this also breaks colors.

An interpreter can support multiple UNDOs; this has nothing to do with
larger z-machines (other than requiring more memory).  A library patch
to make inform allow multiple undos with the 'undo' command might be
useful.  Multiple undo has absolutely nothing to do with color.


From ???@??? Sat Jan 30 10:52:52 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B1CEAF.7617AD3B@ibm.net>
Date: Fri, 29 Jan 1999 10:07:27 -0500
From: John W Kennedy <rri0189@ibm.net>
Reply-To: rri0189@ibm.net
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
Mime-Version: 1.0
To: Z-machine mailing list <z-machine@gmd.de>
Subject: Re: [z-machine] V9/10: Game state
References: <001501be4b92$545c5c00$ac054e8c@edvz.unilinz.ac.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: fdfb2d547a702eff45bfdbf52ee1394e


Gunther Schmidl wrote:

> And while I'm at it, would a larger zmachine allow for multiple UNDOs as
> TADS does? Or would that be a pain in the ass? I know FROTZ can do it, but
> of course, this also breaks colors.

The size of the Z machine doesn't matter.  If the multiple UNDOs were to
be put under game control, it would require some small changes to the Z
machine to add the multi-level save-for-UNDO and restore-for-UNDO
instructions, but the saved data would still be outside the Z machine. 
In any case, since that solution would work only with new games written
to use it, the natural solution is to do what FROTZ did and make
multi-level UNDO invisible to the game.

The only proposal I can see in this area (and I merely throw it out for
discussion) would be to add such a multi-level-UNDO either to Version 9
and up or to Standard 1.1 and up, _AND_ to request that Z-machine
implementors disable their own multi-level UNDO when running at these
levels (actual implementation where multi-level UNDO exists would be
fairly trivial, involving only two new op-codes calling the existing
multi-level-undo and a simple test to suppress the existing user
interface).  This would allow game authors to implement a more secure
"no-UNDO-here" policy, and to make the game aware of the use of
multi-level UNDO, either for the purpose of taunting the player or (more
insidiously) to rerandomize things that ought not to be discovered by
trial and error.

-- 
-John W. Kennedy
-rri0189@ibm.net
Compact is becoming contract
Man only earns and pays.  -- Charles Williams


From ???@??? Sat Jan 30 10:52:54 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B1D004.C45770D1@dsres.com>
Date: Fri, 29 Jan 1999 15:13:08 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] V9/10: Game state
References: <001501be4b92$545c5c00$ac054e8c@edvz.unilinz.ac.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 4aec7ee533923026aa85303420f77fdd


Gunther Schmidl wrote:

> Therefore I propose adding the current fore- and background color to the
> game state to amend this problem.

Hmmmm. I'm not sure this is necessary. It's not hard to program this
defensively and call SET_COLOUR after RESTORE.


--m


From ???@??? Sat Jan 30 11:59:19 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199901292328.SAA09628@ns.chelmsford.com>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine Mailing List <z-machine@gmd.de>
Date: Fri, 29 Jan 1999 18:29:27 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: Re: [z-machine] V9/10: Game state
Reply-To: Jason C Penney <jpenney@chelmsford.com>
X-Confirm-Reading-To: Jason C Penney <jpenney@chelmsford.com>
X-Pmrqc: 1
Priority: normal
In-Reply-To: <oqgQxNS00UwA0_a1k0@andrew.cmu.edu>
References: <001501be4b92$545c5c00$ac054e8c@edvz.unilinz.ac.at>
X-Mailer: Pegasus Mail for Win32 (v3.01d)
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: a68d9391db5f66702774fbe0f87f360e


Evin C Robertson sent a message across the ether on 29 Jan 99, (10:10) stating:

> Excerpts from mail: 29-Jan-99 [z-machine] V9/10: Game state by "Gunther
> Schmidl"@usa.ne 
> > With the recent batch of games that support color (including works of
> > progress), it has become clear that interpreters don't handle them
> > correctly in combination with SAVE, RESTORE and UNDO.
> 
> A game is responsible for drawing its screen after restore/undo, not the
> interpreter.  If the colors are wrong after a restore/undo, it is the
> responsibility of the game to draw these colors, just as it is its
> responisibility to draw everything else on the screen.
> 
> If your game doesn't redraw its colors, your game is at fault, not the
> z-machine or interpreter.

There is code in V6Lib that is supposed to handle this, if ZStyles are 
used.  If this is not working then maybe it's a bug in V6Lib.  So this 
might not be Gunther's fault, it might be mine.

Jay


----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor


From ???@??? Wed Feb 03 07:28:21 1999
Return-Path: owner-z-machine@omega.gmd.de
From: katre <katre@mousetrap.c64.org>
Message-Id: <199902011259.HAA10763@mousetrap.c64.org>
Subject: [z-machine] Proposal for Version 10
To: z-machine@gmd.de
Date: Mon, 1 Feb 1999 07:59:38 -0500 (EST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 13fb2f7c192ec8c0a58ea7c9f7a52ccf


Hoping to stimulate a discussion on the merits and shortfalls of a new screen
model for a graphical Version 10, Gunther Schmidl and I have written a
proposal for such a model.  It has many new features, including palettes,
color cyling, changed window behaviour, and graphics primitives.  Both Gunther
and I are interested in writing graphics games using the z-machine, and these
are the sort of operations that we would like to see.  If anyone else can
think of something useful that we missed, please speak up.  So, sit back, read
this (I'm sorry if it's too long), and get ready to flame me. :)

John 'katre' Cater
katre@mousetrap.ml.org

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

If a section is not specified, then it is the same as in the current Z-Machine
specification found on Graham Nelson's web page
(http://www.gnelson.demon.co.uk/zspec).

Z-machine Version 10 specification
The only real differences between the proposed Version 10 and Version 9 are in
the screen model.
Sections which are the same between Version 10 and Version 6 have been
included for clarity, but are marked with an asterisk (*).

8.  The screen model

8.3  Under Version 10, each window has its own foreground and background color.
There are no exceptions.

8.3.1 The following codes are used to refer to colors, except under Version 10:

8.3.5 Under Version 10, colors are refered to from a palette.  There may be
more than one palette.

[Note: We also propose a revision to the Blorb specification to allow a)
multiple palettes, and b) that a picture can specify which palette it uses.]

8.3.5.1  The palettes are resources, outside the z-machine proper, similar to
pictures and sounds.

8.3.5.2  Palettes are referenced by number, starting with 0.  However, numbers
0 and 1 are reserved for global 32 and 16-bit palettes, respectively.

8.3.5.3 Each window may be associated with a different palette, using the
@set_palette (@set_palette window palette) opcode.  The palette for a already
drawn window may be changed, but only to a palette with an equal or larger
number of colors.

8.3.5.4 Colors in palettes may be directly manipulated by using the
@manip_color (@manip_color palette index red green blue) opcode.  This affects
all colors currently on screen which use this palette.

8.3.5.5 Also, palettes may be rotated using the @rotate_palette
(@rotate_palette palette number) opcode.  Large palettes (32 and 16 bit) may
not be rotated.  This does not have to be by direct color manipulation if the
hardware does not allow it.  It is also allowable to pass all picures through
a filter to change the colors before drawing them.

8.3.5.6 The global palette can be changed using the @manip_global index red
blue green opcode. This affects ALL colors CURRENTLY on screen and can be
used to acquire a 'fading' effect.

8.9 The screen model for Version 10 is as follows:

*8.9.1 The display is an array of pixels. Coordinates are usually given (in
units) in the form (y,x), with (1,1) in the top left. 

*8.9.2 If the interpreter thinks the status line should be redrawn (e.g.
because a menu window has been clicked over it), it may set bit 2 of 'Flags
2'. The game is expected to notice, take action and clear the bit. (However, a
more efficient interpreter would cache the status line and handle redraws
itself.) 

8.9.3 There are as many windows available as the interpreter can provide.  New
windows are created by the @new_window (@new_window y x width height ->
window_number) opcode, which returns either the window number, or -1 (on
error).  Window selection can be changed with the set_window opcode. Windows
are invisible and usually lie on top of each other. All text and graphics
plotting is always clipped to the current window, and anything showing through
is plotted onto the screen.  Subsequent movements of the window _do_ move what
was printed, and the text and graphics printed _do_ belong to the window that
printed them.  Each window has a position (in units), a size (in units), a
cursor position within it (in units, relative to its own origin), a number of
flags called "attributes" and a number of variables called "properties".
Windows can be destroyed using the @destroy_window (@destroy_window window)
opcode.

*8.9.3.1 There are four attributes, numbered as follows: 

    0: wrapping
    1: scrolling
    2: text copied to output stream 2 (the transcript, if selected)
    3: buffered printing

Each can be turned on or off, using the window_style opcode. 

*8.9.3.1.1 "Wrapping" is the continuation of printed text from one line to the
next. Text running up to the right margin will continue from the left margin
of the following line. If "wrapping" is off then characters will be printed
until no more can be fitted in without hitting the right margin, at which
point the cursor will move to the right margin and stay there, so that any
further text will be ignored. 

*8.9.3.1.2 "Buffered printing" means that text to be printed in the window is
temporarily stored in a buffer and only flushed onto the screen at intervals
convenient for the interpreter. 

*8.9.3.1.2.1 "Buffered printing" has two practical effects: firstly it causes a
delay before printed text actually appears. 

*8.9.3.1.2.2 Secondly it affects the way "wrapping" is done. If "buffered
printing" is on, then text is wrapped after the last word which could fit on a
line. If not, then text is wrapped after the last character that could fit. 

Example: suppose the text "Here is an abacus" is printed in a narrow window.
The appearance (after the buffer has been flushed, if there is buffered
printing) might be: 

                                     |...margins....|
    wrapping on    buffering on       Here is an
                                      abacus^
             off   buffering on       Here is an aba^
             
    wrapping on    buffering off      Here is an aba
                                      cus^
             off   buffering off      Here is an aba^

where the caret denotes the final position of the cursor. (Games often alter
"wrapping": it would normally be on for a window holding running text but off
for a status-line window, which is why window 0 has "wrapping" on by default
but all other windows have "wrapping" off by default. On the other hand all
windows have "buffered printing" on by default and games only alter this in
rare circumstances to avoid delays in the appearance of individual printed
characters.) 

8.9.3.2 There are 32 properties, numbered as follows:
	0 y coord	1 x coord	2 y size	3 x size
	4 y cursor	5 x cursor	6 left margin	7 right margin
	8 newline int.	9 int count	10 text style	11 fg color
	12 bg color	13 font number	14 font width	15 font height
	16 attributes	17 line count	18-31 user defined
Each property is a standard Z-machine number and is readable with
get-wind_prop and writeable with put_wind_prop.  However, a game should only
use put_wind_prop to set the newline interrupt routine, the interrupt
countdown, and the line count: everything else is either set by the
interpreter or by specialized opcodes.

*8.9.3.2.1 If a window has character wrapping, then text is clipped to stay
inside the left and right margins. After a new-line, the cursor moves to the
left margin on the next line. Margins can be set with set_margins but this
should only be done just after a newline or just after the window has been
selected. (These values are margin sizes in pixels, and are by default 0.) 

*8.9.3.2.2 If the interrupt countdown is set to a non-zero value (which by
default it is not), then the line count is decremented on each new-line, and
when it hits zero the routine whose packed address is stored in the "newline
interrupt routine" property is called before text printing resumes. (This
routine may, for example, meddle with margins to roll text around a
crinkly-shaped picture.) The interrupt routine should not attempt to print
anything. 

*8.9.3.2.2.1 Note that the set_margins opcode, which is often used by newline
interrupt routines (to adjust the shape of a margin as it flows past a
picture), automatically moves the cursor if the change in margins would leave
the cursor outside them. The effect will depend, unfortunately, on which
sequence of events above takes place. 

*8.9.3.2.2.2 A line count is never decremented below -999. 

*8.9.3.2.3 The text style is set just as in Version 4, using set_text_style
(which sets that for the current window). The property holds the operand of
that instruction (e.g. 4 for italic). 

*8.9.3.2.4 The interpreter should use the line count to see when it should
print "[MORE]". A line count of -999 means "never print [MORE]". (Version 6
games often set line counts to manipulate when "[MORE]" is printed.) 

*8.9.3.2.5 If an attempt is made by the game to read the cursor position at a
time when text is held unprinted in a buffer, then this text should be flushed
first, to ensure that the cursor position is accurate before being read. 

8.9.3.3 At the beginning of the game, only window 0 is created, which fills
the entire screen.  All windows by default have attribute 4 (buffering) on,
and everything else off.

*8.9.3.4 A window can be moved with move_window and resized with window_size.
If the window size is reduced so that its cursor lies outside it, the cursor
should be reset to the left margin on the top line. 

*8.9.3.5 Each window remembers its own cursor position (relative to its own
coordinates, so that the position (1,1) is at its top left). These can be
changed using set_cursor (and it is legal to move the cursor for an unselected
window). It is illegal to move the cursor outside the current window. 

*8.9.3.6 Each window can be scrolled vertically (up or down) any number of
pixels, using the scroll_window opcode. 

8.9.4 The windows to no extent mimic v4.

8.9.5  Screen clearing operations:

*8.9.5.1 Erasing a picture is like drawing it (see below), except that the
space where it would appear is painted over with background colour instead. 

*8.9.5.2 The current line can be erased using erase_line, either all the way to
the right margin or by any positive number of pixels in that direction. The
space is painted over with background colour (even if the current text style
is Reverse Video). 

8.9.5.3 Each window can be erased using erase_window, which clears it to the
background color.  The window is empty after this operation.

*8.9.5.3.1 Erasing window -1 erases the entire screen, destroys all windows but
0 (recreating 0 if destroyed) and clears to the background color of window 0.

*8.9.6 Pictures may accompany the game. They are not stored in the story file
(or the Z-machine) itself, and the interpreter is simply expected to know
where to find them. 

*8.9.6.1 Pictures are numbered from 1 upwards (not necessarily contiguously).
They can be "drawn" or "erased" (using draw_picture and erase_picture).
Before attempting to do so, a game may ask the interpreter about the picture
(using picture_data): this allows the interpreter to signal that the picture
in question is unavailable, or to specify its height and width. 

*8.9.6.2 The game may, if it wishes, use the picture_table opcode to give the
interpreter advance warning that a group of pictures will soon be needed (for
instance, a collection of icons making up a control panel). The interpreter
may want to load these pictures off disc and into a memory cache. 

8.9.6.3 Pictures can be scaled by using the @scale_picture (@scale_picture
picture new_x new_y) opcode.

8.9.7 Graphics primitives shall work in the following manner:

8.9.7.1 The graphics primitives opcodes will work in the currently selected
foreground color (even if reverse video is set), in the currently selected
window.

8.9.7.2 The graphics primitive opcodes are:
	@draw_point y x
	@draw_line y1 x1 y2 x2
	@draw_rectangle y1 x1 y2 x2 filled
	@draw_polygon table filled
	@draw_ellipse y1 x1 y2 x2 radius filled


From ???@??? Wed Feb 03 07:28:40 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B5D90C.BFE7E649@dsres.com>
Date: Mon, 01 Feb 1999 16:40:44 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for Version 10
References: <199902011259.HAA10763@mousetrap.c64.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 5ed4c59fce3767fd50d15b546f1152c9


katre wrote:

> Hoping to stimulate a discussion on the merits and shortfalls of a new
> screen model for a graphical Version 10, Gunther Schmidl and I have
> written a proposal for such a model.

I've noted a couple of points that stood out (I don't have time to read
this in great depth and comment on each part). I've also avoided any
fundamental questions about just how much graphics support is reasonable
for a Z-machine and at what point people should just use Java instead,
and restricted myself to specific questions raised by the proposal.

s/^/IMHO, /g

> 8.3.5.2  Palettes are referenced by number, starting with 0.
> However, numbers 0 and 1 are reserved for global 32 and 16-bit
> palettes, respectively.

Are these direct-colour palettes, or just some arbitrarily chosen
standard palettes?

> 8.3.5.3 Each window may be associated with a different palette, using
> the @set_palette (@set_palette window palette) opcode.  The palette for
> a already drawn window may be changed, but only to a palette with an
> equal or larger number of colors.

Are the old colours copied into the new palette in some way, or is the
screen display expected to update?

> 8.3.5.4 Colors in palettes may be directly manipulated by using the
> @manip_color (@manip_color palette index red green blue) opcode.  This
> affects all colors currently on screen which use this palette.

I think palettes are a mistake. Most higher-end graphics displays (over
256 colours) use a direct-mapping scheme (usually 5/5/5, 5/6/5 or
8/8/8), and by implementing everything in terms of palettes you add a
tremendous overhead: the display must be stored in memory in paletted
form and redrawn to the physical display on every palette modification.

> 8.3.5.5 Also, palettes may be rotated using the @rotate_palette
> (@rotate_palette palette number) opcode.  Large palettes (32 and 16
> bit) may not be rotated.  This does not have to be by direct color
> manipulation if the hardware does not allow it.  It is also allowable
> to pass all picures through a filter to change the colors before
> drawing them.

I don't see the point of this feature. Colour-cycling animation was a
useful and efficient technique in a few limited cases on older displays
with hardware palettes, but I don't believe it has sufficient universal
application to warrant its own opcode. Even if it is implemented, it
needs finer control than just a single number to be of real use (a
minimum of two numbers to specify a range to cycle).

> 8.3.5.6 The global palette can be changed using the @manip_global index
> red blue green opcode. This affects ALL colors CURRENTLY on screen and
> can be used to acquire a 'fading' effect.

As specified, this would be a nightmare to implement. For fading, I
would prefer an opcode with the ability to fade/dissolve between two
pictures in some `pretty' implementation-dependent way. Fading to black
or white would be a special case of this, and it would be much easier to
implement across the wide variety of graphics hardware out there.

I would suggest a simpler and more general colour model:

A game can hint at any time that a given collection of colours would be
a good choice for the palette from that point onwards. An interpreter
running on a paletted display may use these as the colours within its
approximation cube (and reload the hardware palette appropriately), or
may ignore the hint altogether. An interpreter running on a directly
mapped display simply ignores the information. (It may be wise to
specify that giving this hint also clears the screen, to prevent the
interpreter from having to remap every pixel in the display; any images
which should remain may be redrawn after the palette hint and will of
course use the new colour scheme). The precise values in the hardware
palette (if present) are entirely under the control of the interpreter:
the game can only make hints.

Individual images may have palettes (depending on the details of the
image storage format), but these are used purely to map each image pixel
to a 24-bit (48-bit?) colour before it is mapped back into a screen
colour. The actual information as to which palette entry is used for a
given pixel is then discarded.

An interpreter may implement the fade instruction mentioned above, or
may implement it simply by drawing the new image over the top if to do
otherwise would be difficult (whereupon its behaviour is identical to
draw_picture).

Interpreter behaviour when encountering a picture with an alpha channel
should also be specified: I'd like to see the channel used, but with the
interpreter given the option of setting a threshold at 50% and treating
any value below as transparent and any value above as opaque.

> *8.9.2 If the interpreter thinks the status line should be redrawn
> (e.g. because a menu window has been clicked over it), it may set
> bit 2 of 'Flags 2'.

Please, please can we get rid of these magic bits in any future
specifications. They are fine on startup, but cause real headaches for
{who,what}ever has to watch for them...

> 8.9.3 There are as many windows available as the interpreter can provide. 

Erk.

The number that a game can expect *must* be specified. If necessary, it
could be written into a header extension field on startup, but the game
needs to know.

> 8.9.4 The windows to no extent mimic v4.

Except that *all* the normal text operations work in them, of course...
It's more useful to specify what they *are*, rather than what they
*aren't*, especially when it's done in such a vague way. ;)

> *8.9.6 Pictures may accompany the game. They are not stored in the story file
> (or the Z-machine) itself, and the interpreter is simply expected to know
> where to find them.

We should use this opportunity to specify some canonical format for
these.

> 8.9.6.3 Pictures can be scaled by using the @scale_picture (@scale_picture picture new_x new_y) opcode.

I'm not sure that this is necessary. Certainly, it's nice, but will it
be used?

> 8.9.7.2 The graphics primitive opcodes are:

>         @draw_rectangle y1 x1 y2 x2 filled
>         @draw_ellipse y1 x1 y2 x2 radius filled

Unless you're planning to extend the opcode format, the number of
arguments is limited to four.

Most graphics libraries I've seen provide only the less general width
and height form of ellipses, as it is usually only this case that has
any hardware support (not that hardware support for ellipses is
particularly common anyway).

I'm still not sure that ellipse drawing is universally useful enough to
warrant its own opcode. Lines and rectangles could be useful for drawing
borders around text and graphics (or for any 3D-maze bits ;) ), but I
think that anyone who really really wants ellipses should put them in an
image (after all, solid areas of colour do compress very well with
PNG...)

--m


From ???@??? Wed Feb 03 07:29:12 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B6D70A.5CEE09F1@dsres.com>
Date: Tue, 02 Feb 1999 10:44:26 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for Version 10
Content-Type: multipart/mixed; boundary="------------AA534C48B2D079E7A98C687B"
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: cbda7ed1589bd5d8658b775c38d9ff2a

Forwarded at the request of the original author...

--mReturn-path: <katre@mousetrap.c64.org>
Delivery-date: Mon, 1 Feb 1999 23:40:35 +0000
From: katre <katre@mousetrap.c64.org>
Message-Id: <199902012352.SAA23827@mousetrap.c64.org>
Subject: Re: [z-machine] Proposal for Version 10
To: martin@dsres.com (Martin Frost)
Date: Mon, 1 Feb 1999 18:52:12 -0500 (EST)
In-Reply-To: <36B5D90C.BFE7E649@dsres.com> from "Martin Frost" at Feb 1, 99 04:40:44 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


> 
> > 8.3.5.2  Palettes are referenced by number, starting with 0.
> > However, numbers 0 and 1 are reserved for global 32 and 16-bit
> > palettes, respectively.
> 
> Are these direct-colour palettes, or just some arbitrarily chosen
> standard palettes?
> 
These are meant to be direct-color palettes, similar to (and, in fact, stolen
from) the standard 16 and 32-bit palettes from the blorb spec.

> > 8.3.5.3 Each window may be associated with a different palette, using
> > the @set_palette (@set_palette window palette) opcode.  The palette for
> > a already drawn window may be changed, but only to a palette with an
> > equal or larger number of colors.
> 
> Are the old colours copied into the new palette in some way, or is the
> screen display expected to update?
> 
This, and many of your other, questions probably arise because I wasn't clear
enough about the format of the palette.  The palette is a list of colors,
given as 3-byte red, green, and blue values.  A color is given as an index
into that list.  So when a new palette is used, the same index is examined in
the new list.

> > 8.3.5.4 Colors in palettes may be directly manipulated by using the
> > @manip_color (@manip_color palette index red green blue) opcode.  This
> > affects all colors currently on screen which use this palette.
> 
> I think palettes are a mistake. Most higher-end graphics displays (over
> 256 colours) use a direct-mapping scheme (usually 5/5/5, 5/6/5 or
> 8/8/8), and by implementing everything in terms of palettes you add a
> tremendous overhead: the display must be stored in memory in paletted
> form and redrawn to the physical display on every palette modification.
> 
This sounds like what I meant to say with palettes.  It would add in a slight
amount of overhead during the picture drawing, but speed has never been one of
the z-machine's strong points. :)

> > 8.3.5.5 Also, palettes may be rotated using the @rotate_palette
> > (@rotate_palette palette number) opcode.  Large palettes (32 and 16
> > bit) may not be rotated.  This does not have to be by direct color
> > manipulation if the hardware does not allow it.  It is also allowable
> > to pass all picures through a filter to change the colors before
> > drawing them.
> 
> I don't see the point of this feature. Colour-cycling animation was a
> useful and efficient technique in a few limited cases on older displays
> with hardware palettes, but I don't believe it has sufficient universal
> application to warrant its own opcode. Even if it is implemented, it
> needs finer control than just a single number to be of real use (a
> minimum of two numbers to specify a range to cycle).
> 
Actually, both future graphic game writers I asked about this (myself and
Gunther :) suggested this independently of each other.  This is basically the
same as the palette listed above.  The cycle amount is just added to 9or
subtracted from) the index to get the color used.  The vision I had was that
only small, special purpose palettes would be cycled, thus making a range
unnecessary.  For example, if I want a dancing flame, I have a flame picture
in a palette consisting of only reds, yellows, and oranges.  Do make it dance,
I cycle the palette.  Nothing very fancy needed.

> > 8.3.5.6 The global palette can be changed using the @manip_global index
> > red blue green opcode. This affects ALL colors CURRENTLY on screen and
> > can be used to acquire a 'fading' effect.
> 
> As specified, this would be a nightmare to implement. For fading, I
> would prefer an opcode with the ability to fade/dissolve between two
> pictures in some `pretty' implementation-dependent way. Fading to black
> or white would be a special case of this, and it would be much easier to
> implement across the wide variety of graphics hardware out there.
> 
This is probably a very good idea.  I wish we'd thought of it during the
writing process.

> I would suggest a simpler and more general colour model:
> 
[Good stuff about a simpler color model snipped]
The point of this color model is that, as a future game designer, I want a
fairly large amount of control over the display.  I want to be able to control
the colors, the pictures, etc.  I realize that this is going to be a pain for
interpreter writers (especially for those like myself, who are targeting
version 6 and version 10 specifically), but I need this type of control for
the games I want to write.  And that's all I'll say about my plans. :0

> 
> Interpreter behaviour when encountering a picture with an alpha channel
> should also be specified: I'd like to see the channel used, but with the
> interpreter given the option of setting a threshold at 50% and treating
> any value below as transparent and any value above as opaque.
> 
To be honest, I'm not sure what an alpha channel is, but this seems like a
good idea.  Using all of the picture data that's possible can never hurt.

> > *8.9.2 If the interpreter thinks the status line should be redrawn
> > (e.g. because a menu window has been clicked over it), it may set
> > bit 2 of 'Flags 2'.
> 
> Please, please can we get rid of these magic bits in any future
> specifications. They are fine on startup, but cause real headaches for
> {who,what}ever has to watch for them...
> 
I'd be happy to remove this.  I just left it in because I wasn't sure how to
replace it.

> > 8.9.3 There are as many windows available as the interpreter can provide. 
> 
> Erk.
> 
> The number that a game can expect *must* be specified. If necessary, it
> could be written into a header extension field on startup, but the game
> needs to know.
> 
The point to this one is that a game may continue to create windows until the
interpreter runs out of memory.  or just refuses.  It might not be a bad idea
to write an upper limit into a header block, though.

> > 8.9.4 The windows to no extent mimic v4.
> 
> Except that *all* the normal text operations work in them, of course...
> It's more useful to specify what they *are*, rather than what they
> *aren't*, especially when it's done in such a vague way. ;)
> 
I'm refering here to the use of split_window, etc.  The exceptions added to
version 6 to make it behave marginally like version 4 are silly.

> > 8.9.6.3 Pictures can be scaled by using the @scale_picture (@scale_picture picture new_x new_y) opcode.
> 
> I'm not sure that this is necessary. Certainly, it's nice, but will it
> be used?
> 
Possibly not, but I also don't like the idea of having to use two different
picrtures if I need the small dragon versus the large one.  most libraries
that display images will handle scaling as well.

> > 8.9.7.2 The graphics primitive opcodes are:
> 
> >         @draw_rectangle y1 x1 y2 x2 filled
> >         @draw_ellipse y1 x1 y2 x2 radius filled
> 
> Unless you're planning to extend the opcode format, the number of
> arguments is limited to four.
> 
> Most graphics libraries I've seen provide only the less general width
> and height form of ellipses, as it is usually only this case that has
> any hardware support (not that hardware support for ellipses is
> particularly common anyway).
> 
Oops.  Shows what I know.  Perhaps arrays then, giving the vertices?

> 
> --m
> 

John 'katre' Cater




From ???@??? Wed Feb 03 09:01:19 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B71608.C35AA53C@dsres.com>
Date: Tue, 02 Feb 1999 15:13:12 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for Version 10
References: <199902012352.SAA23827@mousetrap.c64.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 54929c0601470d18cf5c8edc4e6fdbeb


katre wrote:

> > I think palettes are a mistake. Most higher-end graphics displays
> > (over 256 colours) use a direct-mapping scheme (usually 5/5/5, 5/6/5
> > or 8/8/8), and by implementing everything in terms of palettes you

> > add a tremendous overhead: the display must be stored in memory in
> > paletted form and redrawn to the physical display on every palette
> > modification.

> This sounds like what I meant to say with palettes.  It would add in
> a slight amount of overhead during the picture drawing, but speed has
> never been one of the z-machine's strong points. :)

My point is not one of speed, but of memory consumption. Consider an
interpreter running on a typical 1024x768 16-bit display (currently
considered entry-level in the PC world). Your scheme would require the
best part of a megabyte of additional RAM, which every interpreter would
have to set aside on startup for every V10 game, even those that never
actually require the palette to be remapped.

All for a behaviour which was more a restriction of earlier graphics
hardware than a genuinely useful feature...

> > [colour cycling]

> Actually, both future graphic game writers I asked about this (myself
> and Gunther :) suggested this independently of each other.  This is
> basically the same as the palette listed above.  The cycle amount is
> just added to 9or subtracted from) the index to get the color used.
> The vision I had was that only small, special purpose palettes would
> be cycled, thus making a range unnecessary.  For example, if I want a
> dancing flame, I have a flame picture in a palette consisting of only
> reds, yellows, and oranges.  Do make it dance, I cycle the palette. 
> Nothing very fancy needed.

The trouble is that colour cycling isn't a very general animation
technique, and on modern displays ends up less efficient in terms of
speed and memory (as mentioned above), than more general schemes. It can
make dancing flames but little else (ticking clocks with a little
cleverness).

You also do need more control over the cycling than you indicate above.
Fine, the flame on your candle is only drawn in reds and oranges, but it
is presumably not square, and so will have a background colour, which
mustn't be cycled. Also, if you are planning on cycling just a part of
the display rather than the whole thing each image will have to remember
its own palette, and this will have to persist until the image is
finally entirely overwritten.

I could be persuaded to support the use of animation information encoded
in the picture files (presumably we'd still use Blorb and hence PNG) to
provide a sort of `semi-static' display. The general idea would be that
an interpreter that doesn't want to animate things just displays the
first frame. If you want a picture of a room, say, and there's a candle
with a dancing flame, then you can achieve this effect (either by
animating the main picture or by adding individual `flame' pictures over
the top).

> The point of this color model is that, as a future game designer,
> I want a fairly large amount of control over the display.  I want
> to be able to control the colors, the pictures, etc.  I realize

> that this is going to be a pain for interpreter writers (especially
> for those like myself, who are targeting version 6 and version 10
> specifically), but I need this type of control for the games I want
> to write.  And that's all I'll say about my plans. :0

You can't control the display. It's as simple as that. If you are
expecting a very specific behaviour from a given display than you've
abandoned portability. A palette-based colour model as you want is just
not practical across the wide variety of graphics hardware currently in
use. It's easy, fast and efficient in 8-bit mode under DOS, and on the
16-bit micros, but increasingly difficult elsewhere. It's not possible
(or is at least very difficult) under Windoze, for example (unless
you're going to force people to run your game full-screen under
DirectBletch or suchlike).

> To be honest, I'm not sure what an alpha channel is, but this seems
> like a good idea.  Using all of the picture data that's possible can
> never hurt.

An alpha channel is an additional dimension to the picture data (in PNG,
for example, pixels become 32-bit numbers ARGB rather than 24-bit RGB).
The most common use is to represent transparency.

Check out <http://www.acorn.co.uk/~kbracey/Zip2000/parrot.html> for an
example of what can be done with this extra information.
> > > 8.9.3 There are as many windows available as the interpreter
> > > can provide.

> > The number that a game can expect *must* be specified. If necessary,
> > it could be written into a header extension field on startup, but the
> > game needs to know.

> The point to this one is that a game may continue to create windows
> until the interpreter runs out of memory.  or just refuses.  It might
> not be a bad idea to write an upper limit into a header block, though.

If you go down that road, you've got the same game behaving
unpredictably differently on different machines and at different times.
You've also got the game not knowing whether or not an attempt to open a
window is going to succeed. These are basically the same questions that
were brought up in the discussion over dynamic memory allocation in
V9/V10.

> I also don't like the idea of having to use two different picrtures
> if I need the small dragon versus the large one. most libraries
> that display images will handle scaling as well.

My point was that image scaling is usually a Bad Thing. A small picture
enlarged becomes blocky, and a large picture reduced loses detail. You
can't check these things in advance, either, as you don't know that two
given interpreters will reduce your picture in the same way.

If you want differently sized images, store two in the PNG file. It may
be less efficient, but it's less work for interpreter writers. After
all, this proposal should be easy to implement as well as exactly right
for your particular game.

Blorb includes features to describe image scaling, anyway. ;)

--m


From ???@??? Wed Feb 03 07:29:27 1999
Return-Path: owner-z-machine@omega.gmd.de
From: katre <katre@mousetrap.c64.org>
Message-Id: <199902021740.MAA07768@mousetrap.c64.org>
Subject: Re: [z-machine] Proposal for Version 10
To: z-machine@gmd.de
Date: Tue, 2 Feb 1999 12:40:17 -0500 (EST)
In-Reply-To: <36B71608.C35AA53C@dsres.com> from "Martin Frost" at Feb 2, 99 03:13:12 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 8844e81eb633909ee9b2ae954fc44d5d


After discussing with my collaborators (well, actually there's only one), we
have decided to withdraw our proposal in favor of anything that meets a list
of minimum features.  This list would include:
1) many windows.  Definitely more than 8.
2) windows own their contents, which will be redrawn with them.  this is the
approach taken by most modern gui libraries, and seems to work very well.
3) still-frame animation, as suggested by Martin Frost in his recent mail.  It
would be acceptable if an interpreter that did not want to display the
animation would just display the first image.
4) graphics primitives, at least as far as points, lines, and simple polygons.
5) some color control, wether that is by giving the interpreter a palette, or
by the color hint method, again suggested by Martin Frost.  My only change
would be to have it on a window by window basis, not for the entire display,
although if this is too challenging for the hardware I could live without.

The proposal submitted by Gunther and myself was intended mainly to start
discussion into the direction an improved screen model should go.  So thank
you, Martin, for being willing to discuss this with me.  And shame on the rest
of you for not discussing.

John 'katre' Cater


From ???@??? Wed Feb 03 07:29:29 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B74758.347000BB@dsres.com>
Date: Tue, 02 Feb 1999 18:43:36 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for Version 10
References: <199902021740.MAA07768@mousetrap.c64.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 87745a7a66f7c965b9be80fd8dcc9402


katre wrote:

> 1) many windows.  Definitely more than 8.

16 or 32 do?

> 2) windows own their contents, which will be redrawn with them.
> this is the approach taken by most modern gui libraries, and seems
> to work very well.

Without meaning to complain again, ;) this is actually a fair amount of
latent overhead. Lots of large windows will require lots of memory to
store...

Not all systems provide this support, too, unless you're prepared to
have borders added to your windows (which are often undesirable). It can
be done on Amiga and X, but afaik is impossible on Macintosh and
Windows. If there is no OS support, then it's quite a lot of work for an
interpreter for (imho) negligible benefit.

If you want the ability to create new top-level windows with borders and
titles, then that's something quite different and has different
questions attached.

> 3) still-frame animation, as suggested by Martin Frost in his recent
> mail.  It would be acceptable if an interpreter that did not want to
> display the animation would just display the first image.

Yup. I support this. ;)

> 4) graphics primitives, at least as far as points, lines, and simple
> polygons.

Fine. Exactly how this is done needs specifying, but I have no
objections to points, lines and polygons.

> 5) some color control, wether that is by giving the interpreter a
> palette, or by the color hint method, again suggested by Martin Frost.
> My only change would be to have it on a window by window basis, not
> for the entire display, although if this is too challenging for the
> hardware I could live without.

It wouldn't work to have a separate hint palette for different windows,
as the point of the hint palette is to specify the colours that those
used in the display should be approximated by. No production graphics
hardware that I know of supports a per-window palette, so this is only
of use if it's global.

> shame on the rest of you for not discussing.

Steady on! Not everyone reads their mail every day. ;)

--m


From ???@??? Wed Feb 03 10:45:34 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <19990202210328.5732.qmail@hotmail.com>
X-Originating-Ip: [144.126.187.238]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for Version 10
Date: Tue, 02 Feb 1999 16:03:28 EST
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: c98acdc867a6b06bf78f48c9768a53ff


>From: katre <katre@mousetrap.c64.org>
>Subject: Re: [z-machine] Proposal for Version 10
>To: z-machine@gmd.de
>Date: Tue, 2 Feb 1999 12:40:17 -0500 (EST)
>
>After discussing with my collaborators (well, actually there's only 
one), we
>have decided to withdraw our proposal in favor of anything that meets a 
list
>of minimum features.  This list would include:
>1) many windows.  Definitely more than 8.
>2) windows own their contents, which will be redrawn with them.  this 
is the
>approach taken by most modern gui libraries, and seems to work very 
well.

I;m not sure how much I like this. One of my favorite facets of the 
z-machine screen model (which is hated by implementors, but I'm firmly 
against playing IF in a windowing environment anyway.) is that you can 
effectively "stamp" the contents of one window onto another by drawing a 
window overtop another, printing to it, then deleting the window. (cf 
the "box" feature in inform)

>3) still-frame animation, as suggested by Martin Frost in his recent 
mail.  It
>would be acceptable if an interpreter that did not want to display the
>animation would just display the first image.

WHy not just add some animated format (fli/flc perhaps?) into blorb as a 
format for pictures, and not even let the z-machine worry about it?

>4) graphics primitives, at least as far as points, lines, and simple 
polygons.

I'd support points, but anything else seems a bit excessive (if you can 
draw points, you can draw anythign else you like in software)



______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


From ???@??? Fri Feb 05 13:45:13 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199902022245.LAA06212@smtp2.ihug.co.nz>
X-Sender: brianc@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 03 Feb 1999 09:14:07 +1300
To: Z-Machine List <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Proposal for Version 10
In-Reply-To: <36B71608.C35AA53C@dsres.com>
References: <199902012352.SAA23827@mousetrap.c64.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: ebfb5a324f9729e875fd7417f39c8a2d


At 15:13 02/02/99 +0000, Martin Frost wrote:
>
>My point is not one of speed, but of memory consumption. Consider
an
>interpreter running on a typical 1024x768 16-bit display (currently
>considered entry-level in the PC world). Your scheme would require
the
>best part of a megabyte of additional RAM, which every interpreter
would
>have to set aside on startup for every V10 game, even those that
never
>actually require the palette to be remapped.

I make it 1.5 megabytes exactly; 1024x768 pixels, each pixel holding
16 bits of colour data (two bytes).  That's definately going
overboard. :)  Especially when you then raise the possibility of
additional palettes, using additional vast chunks of memory.

>I could be persuaded to support the use of animation information
encoded
>in the picture files (presumably we'd still use Blorb and hence PNG)
to
>provide a sort of `semi-static' display. The general idea would be
that
>an interpreter that doesn't want to animate things just displays
the
>first frame. If you want a picture of a room, say, and there's a
candle
>with a dancing flame, then you can achieve this effect (either by
>animating the main picture or by adding individual `flame' pictures
over
>the top).

This seems to me to be the most sensible approach to 
animation, and is much more versatile than palette rotation.

>> The point to this one is that a game may continue to create
windows
>> until the interpreter runs out of memory.  or just refuses.  It
might
>> not be a bad idea to write an upper limit into a header block,
though.
>
>If you go down that road, you've got the same game behaving
>unpredictably differently on different machines and at different
times.
>You've also got the game not knowing whether or not an attempt to
open a
>window is going to succeed. These are basically the same questions
that
>were brought up in the discussion over dynamic memory allocation in
>V9/V10.

I'd be in favour of either setting a definate limit, as in the
current V6 spec, or having the interpreter set a header byte (perhaps
one in the extensions table, unless we're extending the entire
header, as I think I've heard mentioned) indicating the number of
windows that can be created.  Perhaps the best idea is to combine the
two, by requiring that the interpreter allow a set number of windows
(say 8 or 16), but can provide more if requested, and on startup it
sets the indicator byte to show how many are available, so that games
can assume a certain amount will always exist, but leave room for
other games to create more windows if they really need to.

-- 
Gavin Lambert
uecasm@geocities.com
<http://crash.ihug.co.nz/~brianc/>
ICQ: 2274180  (<www.mirabilis.com>) 
----
"For those who like this sort of thing, this is the sort of thing
they like."  -- Abraham Lincoln


From ???@??? Fri Feb 05 13:46:45 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B83095.F308024A@dsres.com>
Date: Wed, 03 Feb 1999 11:18:45 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for Version 10
References: <19990202210328.5732.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: b459ff2714485dd3eb9a43962b18bb2d


Matt Ackeret wrote:

> >Not all systems provide this support, too, unless you're prepared to
> >have borders added to your windows (which are often undesirable). It can
> >be done on Amiga and X, but afaik is impossible on Macintosh and
> >Windows.

> Wait, if you mean a picture background, you can do it on a Mac.

> SetWindowPic() to set the window background to a picture...  But I've
> never actually used this.  I think this automatically draws the window
> contents as the picture.  I don't know if the app still gets regular
> update events.

No, I was referring to an entity which behaves like a normal GUI window
(in that it can be moved and resized, and its contents move with it),
but which is free from the normal decorations (title bar, border,
controls, ...).

This can be done on Amiga by setting the BORDERLESS flag, and on X
because all windows are like that unless you specifically ask for them
to be managed.

> All of these things seem very very far out, in my opinion.  Seems like
> these will be completely unplayable in a regular text interface.

This is true. It is also true for any game which relies on graphics in
V6.

--

L. Ross Raszewski wrote:

> WHy not just add some animated format (fli/flc perhaps?) into blorb as a
> format for pictures, and not even let the z-machine worry about it?

This is basically what I suggested, but using the existing multi-frame
capabilities of PNG rather than YA graphics format...

--m


From ???@??? Fri Feb 05 13:46:54 1999
Return-Path: owner-z-machine@omega.gmd.de
Date: Wed, 3 Feb 1999 08:14:54 -0500
From: "A.K.A. TheWiz" <dankna@bergen.org>
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for Version 10
In-Reply-To: <19990202121925.015509@relay.apple.com>
Message-Id: <Pine.SGI.4.05.9902030813380.3429-100000@vangogh.bergen.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 168e0c6176d206831eba71d9a1bf0bd6


> >Without meaning to complain again, ;) this is actually a fair amount of
> >latent overhead. Lots of large windows will require lots of memory to
> >store...
> >
> >Not all systems provide this support, too, unless you're prepared to
> >have borders added to your windows (which are often undesirable). It can
> >be done on Amiga and X, but afaik is impossible on Macintosh and
> >Windows. If there is no OS support, then it's quite a lot of work for an
> 
> Wait, if you mean a picture background, you can do it on a Mac.
> 
> SetWindowPic() to set the window background to a picture...  But I've
> never actually used this.  I think this automatically draws the window
> contents as the picture.  I don't know if the app still gets regular
> update events.

  It doesn't; SetWindowPic() is for windows with fixed content.  I think
the intent was different anyway.


___Dan_Knapp____The_Mauve_Baron______________________Beep Blip Bonk_______
<dankna@bergen.org><dankna@brain.mics.net> http://users.bergen.org/~dankna
Great minds think differently.


From ???@??? Fri Feb 05 13:47:12 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <19990203151658.22452.qmail@hotmail.com>
X-Originating-Ip: [144.126.178.48]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Proposal for Version 10
Date: Wed, 03 Feb 1999 10:16:57 EST
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 3dafe3559c55b740318582cfe13aa7c8


>Date: Wed, 03 Feb 1999 11:18:45 +0000
>From: Martin Frost <martin@dsres.com>
>To: Z-Machine List <z-machine@gmd.de>
>Subject: Re: [z-machine] Proposal for Version 10
>
>Matt Ackeret wrote:
>
>> All of these things seem very very far out, in my opinion.  Seems 
like
>> these will be completely unplayable in a regular text interface.
>
>This is true. It is also true for any game which relies on graphics in
>V6.
>

Though graphics does not rule out non-windowing environments. I wouldn't 
like to see any extension to Z that does.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


From ???@??? Fri Feb 05 13:47:23 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B87400.445EE04E@dsres.com>
Date: Wed, 03 Feb 1999 16:06:24 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for Version 10
References: <19990203151658.22452.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 84cb01c2b0bac129fac231419f4cac55


L. Ross Raszewski wrote:

> Though graphics does not rule out non-windowing environments.
> I wouldn't like to see any extension to Z that does.

I agree. This is a further reason to keep the current behaviour of
windows.

The main point I can see for windows `owning' their content is that
quote boxes displayed over the main game text do not mess up the
scrollback.

I'd like to see any eventual V10 display model able to cope equally well
with any bitmapped graphical display, from a Mac Plus upward.

--m


From ???@??? Fri Feb 05 13:47:43 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <199902031900.LAA08576@f32.hotmail.com>
X-Originating-Ip: [144.126.187.238]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: [z-machine] [z] Spec addition
Date: Wed, 03 Feb 1999 14:00:58 EST
Mime-Version: 1.0
Content-Type: text/plain
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: d2699e0b098263125ada704238b6d418


Just wondering if we couild make a minor change to the spec, namely 
makign it legal to @set_cursor to 0 0, thus rendering the cursor blinkey 
"invisible". There's a lot of code around that tries this little trick.

Thanks.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


From ???@??? Fri Feb 05 13:48:11 1999
Return-Path: owner-z-machine@omega.gmd.de
X-Mailer: CTM PowerMail demo 2.3 <http://www.ctmdev.com>
X-Sender: mattack@mail.apple.com
Date: Tue, 2 Feb 1999 12:19:25 -0800
To: Z-Machine List <z-machine@gmd.de>
From: Matt Ackeret <mattack@apple.com>
Subject: Re: [z-machine] Proposal for Version 10
Message-Id: <19990202121925.015509@relay.apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: ed801f560e5ea836b149a3b3b3940e01


>katre wrote:
>> 2) windows own their contents, which will be redrawn with them.
>> this is the approach taken by most modern gui libraries, and seems
>> to work very well.
>
>Without meaning to complain again, ;) this is actually a fair amount of
>latent overhead. Lots of large windows will require lots of memory to
>store...
>
>Not all systems provide this support, too, unless you're prepared to
>have borders added to your windows (which are often undesirable). It can
>be done on Amiga and X, but afaik is impossible on Macintosh and
>Windows. If there is no OS support, then it's quite a lot of work for an

Wait, if you mean a picture background, you can do it on a Mac.

SetWindowPic() to set the window background to a picture...  But I've
never actually used this.  I think this automatically draws the window
contents as the picture.  I don't know if the app still gets regular
update events.


All of these things seem very very far out, in my opinion.  Seems like
these will be completely unplayable in a regular text interface.


From ???@??? Fri Feb 05 13:49:26 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36B97F78.BC085D21@dsres.com>
Date: Thu, 04 Feb 1999 11:07:36 +0000
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Proposal for Version 10
References: <Pine.NXT.4.05.9902031037440.664-100000@ackema>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: aa37147286ff3c779152296af2c23892


Matt Ackeret wrote:

> > an entity which behaves like a normal GUI window (in that it can be
> > moved and resized, and its contents move with it), but which is free
> > from the normal decorations (title bar, border, controls, ...).

> Well, you could fake this on a Mac with a dboxproc window.  Then manually
> (i.e. call the toolbox routine) to drag the window when they click
> wherever appropriate.

I'm still not sure it's a good idea, though. It gets us into all sorts
of awkwardness with input focus, and since the feature isn't necessarily
available even on windowing systems it's a lot more work for interpreter
implementors.

My instinct is to keep with the current scheme whereby a window exists
purely to bound text and graphics drawn (does a window provide
clipping?)

--m


From ???@??? Sat Feb 27 15:30:25 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <Eqmber200Uw917PMU0@andrew.cmu.edu>
Date: Wed, 17 Feb 1999 03:15:51 -0500 (EST)
From: Evin C Robertson <ecr+@andrew.cmu.edu>
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] z-spec questions
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 3d2b933cd10bc02942181f2aac7c3b8b


Is it legal to loadb myarray -1 -> val; ?  I couldn't confidently
determine from the spec whether the index into a loadb was signed or
unsigned.  I assumed it unsigned for obvious reasons, but _zenspeak_
does this often and while writing a bug report I was unable to point at
the spec to say "there, I'm right."


What's the big deal with the VAR form of 2OP opcodes?  I've been
wondering this for a long time.  Is je really the only one ever used? 
And why doesn't inform or zasm assemble the example of je given in the
spec?


Finally, to whom should I send typo / obvious mistake reports on the
z-machine standards document?  To Graham?  To this list?



From ???@??? Sat Feb 27 15:30:37 1999
Return-Path: owner-z-machine@omega.gmd.de
Message-Id: <36CAA5EF.7E32@is.ien.it>
Date: Wed, 17 Feb 1999 12:20:15 +0100
From: Aldo Cumani <cumani@dns.ien.it>
Organization: IENGF
X-Mailer: Mozilla 3.01 (Win95; I)
Mime-Version: 1.0
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] z-spec questions
References: <Eqmber200Uw917PMU0@andrew.cmu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 7f31a7c18c17b49eab56d5d32adefa63


Evin C Robertson wrote:
> 
> Is it legal to loadb myarray -1 -> val; ?  I couldn't confidently
> determine from the spec whether the index into a loadb was signed or
> unsigned.  I assumed it unsigned for obvious reasons, but _zenspeak_
> does this often and while writing a bug report I was unable to point at
> the spec to say "there, I'm right."
> 
> [rest of message snipped]

I don't know for sure wether it's legal or not, but its usage by
_zenspeak_ is not a feature, it's a bug :(

I've fixed up that bug and uploaded the corrected story file to GMD.
Please note that the file to download is NOT zenspeak.z5 but
zenspeak.z5_GOOD (I had some transmission problems...)


-- 
Ing. Aldo Cumani <cumani@is.ien.it>
Istituto Elettrotecnico Nazionale
Str. delle Cacce, 91
10135 Torino


From ???@??? Sat Feb 27 15:31:12 1999
Return-Path: owner-z-machine@omega.gmd.de
From: "Patrick Kellum" <pkellum@lycosmail.com>
Organization: Arf!
Date: 18 Feb 99 21:16:28 +0800
Subject: Re: [z-machine] z-spec questions
Message-Id: <OUT-36CC8329.MD-1.1.pkellum@lycosmail.com>
In-Reply-To: <Eqmber200Uw917PMU0@andrew.cmu.edu>
To: z-machine@gmd.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: MicroDot-II/AmigaOS NC 1.1
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk
X-UIDL: 0db33a32ccc47f263750e0da6afe17f6


On Wed, 17 Feb 1999 03:15:51 -0500 (EST), Evin C Robertson had this to say about "[z-machine] z-spec questions".

> What's the big deal with the VAR form of 2OP opcodes?  I've been
> wondering this for a long time.  Is je really the only one ever used? 
> And why doesn't inform or zasm assemble the example of je given in the
> spec?

I wish I knew :-(  This is quite anoying and Inform wastes a lot of
space using multiple je where a single one would do :-(

> Finally, to whom should I send typo / obvious mistake reports on the
> z-machine standards document?  To Graham?  To this list?

I would suggest both, but that's just my opinion

Patrick

-- 
The Small Wonder Page
   http://smallwonder.simplenet.com/
My Miva Functions
   http://smallwonder.simplenet.com/miva/functions/index.mv
"Animal crackers in my poop." - Shirley Temple


From ???@??? Sun Nov 28 13:37:17 1999
Return-Path: <owner-z-machine@omega.gmd.de>
X-Track2: 2
Date: Thu, 25 Nov 1999 10:50:40 +0000 (GMT)
From: Graham Nelson <graham@gnelson.demon.co.uk>
Subject: [z-machine] Re: Translation Issue
To: Polawat Ouilapan <pol@loxinfo.co.th>,
  Z-Machine Mailing List <z-machine@gmd.de>
In-Reply-To: <383D0A6A.33836BBD@loxinfo.co.th>
Message-Id: <Marcel-1.46-1125105040-b49M+4%@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-z-machine@omega.gmd.de
Precedence: bulk


On Thu 25 Nov, Polawat Ouilapan wrote:
> Dear Graham,
>     Is it possible to write a story in a non-english-character language?
> I'm interested in writing it in Thai. If I want to go as far as having
> all Inform's command in Thai, what would I need to do?

The short answer is "yes", but you would need an interpreter which
supports the Z-machine standard on Unicode characters, and you
would also need the relevant fonts.  I'm not sure if any of the
existing interpreters would be good enough, but (as I'm posting
this answer to the Z-machine mailing list) perhaps someone will
let me know.

Once you can get the interpreter to display Thai characters, the
rest should be no harder than translating to a European language.
See the notes at

  http://www.gnelson.demon.co.uk/inform/releases/trans.txt

for more details, or see Chapter V in the forthcoming printed
Inform manual.

(Incidentally: Hans Dictus (dictus@obtilburg.nl) reports that
he has resumed work on Dutch Inform.)

-- 
Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom



From ???@??? Sat Feb 26 19:50:35 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Message-Id: <200002180052.TAA06440@chmls06.mediaone.net>
From: "Jay Penney" <JCZorkmid@textfire.com>
To: z-machine@gmd.de
Date: Thu, 17 Feb 2000 19:52:08 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: [z-machine] back to the mouse
Reply-to: JCZorkmid <JCZorkmid@textfire.com>
Sender: owner-z-machine@gmd.de
Precedence: bulk


Hi all,

Recently I decided to go back to looking at adding mouse support to 
V6lib.  Well, I remember why I put it off.  I did some testing with 
the Infocom dos v6 terps I have, and the different versions of Frotz 
I can run.

Below is a chart recording what I found.  I Clicked in the top left 
corner, and then the bottom right corner of the screen in each terp, 
and recorded each result. The values listed in current come from 
@read_mouse, while the values in last click came from the header. 


+---------------+---------+---------+---------+----------+
| Results       : Infocom | Frotz   | Frotz   | WinFrotz | 
|               : Dos     | -d6     | -d3     |          | 
+===============+=========+=========+=========+==========+
| Top Left      :         |         |         |          |
|    current    : 0,0     | 1,1     | 1,1     | 1,2      | 
|    last click : 1,1     | 0,0     | 1,1     | 2,1      | 
+---------------+---------+---------+---------+----------+
| Bottom Right  :         |         |         |          | 
|    current    : 200,640 | 640,400 | 319,199 | 634,395  | 
|    last click : 201,641 | 0,0     | 199,319 | 395,634  | 
+---------------+---------+---------+---------+----------+
| Current is    :         |         |         |          |
| real time     : yes     | no      | no      | no       | 
+---------------+---------+---------+---------+----------+
| Buttons are   :         |         |         |	         |
| real time     : yes     | no      | no      | no       | 
+---------------+---------+---------+---------+----------+
| last click    :         |         |         |          |
| updates on    : B2      | B1      | B1      | B1       | 
+---------------+---------+---------+---------+----------+
| Button map    :         |         |         |	         |
|       B1      : right   | left    | left    | left     | 
|       B2      : left    | none    | none    | none     | 
+---------------+---------+---------+---------+----------+  

Mouse support in Frotz seems to be very unlike mouse support in the 
Infocom interpreter.  The Infocom terp actually seems quite advanced 
in comparison to Frotz.

The spec is pretty vague in the mouse department, but as you can see 
something is quite wrong.  I've managed to confuse myself to the 
point that I can tell which coord is supposed to be x and which one 
is supposed to be y.  I think much of the problem stems from lack of 
a solid definition of @read_mouse.

The way Frotz reports buttons seems useless to me.  Once you click a 
button, B1 will always report Y until you quit (and Frotz doesn't 
support a B2).

The zcode and Inform source for my testing can be found at:
<http://www.chelmsford.com/~jpenney/V6Lib/zmouse.zip>

If anyone could add to the chart with different terps I'd appreciate 
it (apologies to those who gave me feedback on older versions of 
zmouse... I've been unable to reconcile emails with zmouse 
revisions). 

Later,
Jay Penney


----
<JCZorkmid@textfire.com>  Jason C. Penney
<http://www.chelmsford.com/home/jpenney/>
Check out V6Lib @ <http://www.chelmsford.com/home/jpenney/V6Lib>


From ???@??? Sat Feb 26 19:56:23 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Date: Wed, 23 Feb 2000 17:35:03 -0700
From: "J. Holder" <jholder@frii.com>
To: z-machine@gmd.de
Subject: [z-machine] testers wanted / Jzip 2.1
Message-ID: <20000223173503.A17797@io.frii.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk




I'm ready to upload Jzip 2.1 to the archive, but thought I would ask 
any of you who are interested to bang on it for a couple of days first.

- The interpreter claims spec. 1.0 compilance, although it doesn't yet support
  the Unicode extensions at all.  With that exception, I believe it to be
  compliant for z1-z5 and z8.  Please feel free to burst my bubble!  I'd like
  to fix it if it is broken.
- Jzip now uses Quetzal for save files
- Makefiles are included for Borland C for DOS, for UNIX, and for Atari ST
  with gcc.  Jzip should build on any UNIX by following the instructions
  in the Makefile.  If it doesn't, I want to fix that, too.

You can find it at:
http://www.frii.com/~jholder/jzip/

My response time should be good for a week or two, then I am expecting
another bundle of joy to drop into my life, and who knows exactly
what chaos will reign then...

Thanks,
John
-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
<jholder> do you like FreeBSD?
<hal> I need to get the ISDN line running so that I will tell it to pass over
  me and replace my SuSE box with FreeBSD.



From ???@??? Sat Feb 26 19:56:28 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
To: z-machine@gmd.de
Date: Wed, 23 Feb 2000 21:51:55 -0800
From: "Evin Robertson" <nitfol@my-deja.com>
Message-ID: <FIDMDOAEKOBPPBAA@my-deja.com>
Mime-Version: 1.0
Subject: Re: [z-machine] testers wanted / Jzip 2.1
Organization: My Deja Email  (http://www.my-deja.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


On Wed, 23 Feb 2000 17:35:03   J. Holder wrote:
>I'm ready to upload Jzip 2.1 to the archive, but thought I would ask
>any of you who are interested to bang on it for a couple of days first.
>
>- The interpreter claims spec. 1.0 compilance, although it doesn't yet support
>  the Unicode extensions at all.  With that exception, I believe it to be
>  compliant for z1-z5 and z8.  Please feel free to burst my bubble!  I'd like
>  to fix it if it is broken.

Adding @print_unicode is easy.  Just make it do the exact same thing
as @print_char.  This will at least make the game not do _bad things_
if it sees that spec 1.0 is available and wants to use unicode.

Under frotz and nitfol, @art_shift -9 -5 renders -1; jzip gives 2047.

Following the definition given in the spec:

1111111111110111  =  -9
1111111111111011  =  -9 >> 1
1111111111111101  =  -9 >> 2
1111111111111110  =  -9 >> 3
1111111111111111  =  -9 >> 4
1111111111111111  =  -9 >> 5  =  -1


You're not properly handling 64 byte long properties.  See section
12.4.2.1.1

These are both problems which plague most zip derivatives.

You don't check for -32768 / -1, which will crash on some machines
with overflow.  -32768 would be the 'proper' answer, but I think we
should declare this type of overflow illegal since some (all?) of
Infocom's own interpreters crash on this.  Likewise for the equivalent
multiplication.

You assume 'short' is exactly 16 bits when it's only guaranteed to be
at least that.  Better to do things correctly or use 'int16' typedefs.

This is only 10 minutes of investigation (not including write-up
time), so probably other stuff too.


>- Jzip now uses Quetzal for save files
>- Makefiles are included for Borland C for DOS, for UNIX, and for Atari ST
>  with gcc.  Jzip should build on any UNIX by following the instructions
>  in the Makefile.  If it doesn't, I want to fix that, too.

The following is on a Debian Potato box.  Results might vary from *nix
to *nix.

You include <string.h> which, assuming an ANSI C library will define
strchr correctly, yet you re#define strchr in ztypes.h leading to a
warning message on my box.

Instead of doing the HARD_COLORS thing, you should give the option of
using ncurses which supports color correctly on a variety of machines.

Color doesn't quite work right.  If an @erase_window happens, you
should make that be the default color for text which scrolls in from
the bottom.

If I press Ctrl-C it does [Hit any key to exit.] and pauses until I
Ctrl-C it again.


--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.


From ???@??? Mon Feb 28 20:48:18 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Message-ID: <001901bf8136$f053bce0$7a3163c3@default>
Reply-To: "David Kinder" <D.Kinder@btinternet.com>
From: "David Kinder" <D.Kinder@btinternet.com>
To: <z-machine@gmd.de>
References: <71D0D96AC395D211B56A00105A408BFD62B3DD@euclid.monis.co.uk>
Subject: Re: [z-machine] back to the mouse
Date: Sun, 27 Feb 2000 15:25:50 -0000
Organization:  
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


> If anyone could add to the chart with different terps I'd appreciate 
> it (apologies to those who gave me feedback on older versions of 
> zmouse... I've been unable to reconcile emails with zmouse 
> revisions). 

Using Infocom's Amiga interpreter supplied with Zork Zero, I get the
following results (on a 640x200 display):

Top left:
  current: 1,1
  last click: 5,1

Bottom right:
  current: 1,1
  last click: 204,640

Only the left mouse button has any effect, but both B1 and B2 remain
resolutely set to "N".

I'm not sure what Jay means by "Current is real time" and "Buttons are
real time".

Anyway, from all this it looks like different Infocom interpreters have
somewhat different levels of mouse support. Since Zork Zero does work
properly with this interpreter, I guess it's quite likely that all Infocom
data files assume only one mouse button and only read the mouse position
from "last click".

David





From ???@??? Mon Feb 28 20:48:20 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Message-Id: <200002271558.KAA12338@chmls06.mediaone.net>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: <z-machine@gmd.de>
Date: Sun, 27 Feb 2000 10:58:19 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [z-machine] back to the mouse
Reply-to: Jason C Penney <jpenney@chelmsford.com>
In-reply-to: <001901bf8136$f053bce0$7a3163c3@default>
Sender: owner-z-machine@gmd.de
Precedence: bulk


David Kinder sent a message across the ether on 27 Feb 00, (15:25) stating:

> I'm not sure what Jay means by "Current is real time" and "Buttons are
> real time".

By "[blah] is real time" I meant that as I moved the mouse the 
numbers/button status updated in real time (or close to it).  This is 
what I think read_mouse should do.  
 
> Anyway, from all this it looks like different Infocom interpreters have
> somewhat different levels of mouse support. Since Zork Zero does work
> properly with this interpreter, I guess it's quite likely that all Infocom
> data files assume only one mouse button and only read the mouse position
> from "last click".

This leads me to believe that the Amiga interpreter doesn't implement 
@read_mouse (it must just ignore it) and just uses the header data 
and the keypress to provide mouse support.  In this case the data 
files assumes that the header data will be present, and that a mouse 
click registers as a key press.

The Dos Frotz behavior in Amiga mode (-d6) seems to match the actual 
amiga terp fairly well.  The infocom Dos terp does implement 
@read_mouse, and in a very useful manner IMO, but it seems to be the 
only terp so far that does.

Jay 


----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor


From ???@??? Fri Mar 03 22:25:32 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Message-ID: <71D0D96AC395D211B56A00105A408BFD62B44F@euclid.monis.co.uk>
From: David Kinder <david.kinder@monis.co.uk>
To: z-machine@gmd.de
Subject: RE: [z-machine] back to the mouse
Date: Wed, 1 Mar 2000 17:10:30 -0000 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF83A1.0C16BD00"
Sender: owner-z-machine@gmd.de
Precedence: bulk

<x-html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: [z-machine] back to the mouse</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>&gt; By &quot;[blah] is real time&quot; I meant that as I moved the mouse the </FONT>
<BR><FONT SIZE=2>&gt; numbers/button status updated in real time (or close to it).&nbsp; This is </FONT>
<BR><FONT SIZE=2>&gt; what I think read_mouse should do.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Ah, I understand. The Amiga Zork Zero interpreter doesn't do that.</FONT>
</P>

<P><FONT SIZE=2>&gt; This leads me to believe that the Amiga interpreter doesn't implement </FONT>
<BR><FONT SIZE=2>&gt; @read_mouse (it must just ignore it) and just uses the header data </FONT>
<BR><FONT SIZE=2>&gt; and the keypress to provide mouse support.&nbsp; In this case the data </FONT>
<BR><FONT SIZE=2>&gt; files assumes that the header data will be present, and that a mouse </FONT>
<BR><FONT SIZE=2>&gt; click registers as a key press.</FONT>
</P>

<P><FONT SIZE=2>I agree. When I get a chance I'll dig out my old Amiga and check what</FONT>
<BR><FONT SIZE=2>the Arthur and Shogun interpreters do.</FONT>
</P>

<P><FONT SIZE=2>&gt; The Dos Frotz behavior in Amiga mode (-d6) seems to match the actual </FONT>
<BR><FONT SIZE=2>&gt; amiga terp fairly well.&nbsp; The infocom Dos terp does implement </FONT>
<BR><FONT SIZE=2>&gt; @read_mouse, and in a very useful manner IMO, but it seems to be the </FONT>
<BR><FONT SIZE=2>&gt; only terp so far that does.</FONT>
</P>

<P><FONT SIZE=2>Perhaps we need a small clarification in the spec. Does anyone on this</FONT>
<BR><FONT SIZE=2>list know what Zip2000 (the only other v6 interp. I can think of) does?</FONT>
<BR><FONT SIZE=2>Does nitfol support v6 yet?</FONT>
</P>

<P><FONT SIZE=2>David Kinder&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="mailto://davidk@monis.co.uk">mailto://davidk@monis.co.uk</A></FONT>
<BR><FONT SIZE=2>Monis Software&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.monis.co.uk/" TARGET="_blank">http://www.monis.co.uk/</A></FONT>
<BR><FONT SIZE=2>Audrey House&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel: +44 171 421 4600</FONT>
<BR><FONT SIZE=2>16-20 Ely Place&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax: +44 171 421 4601</FONT>
<BR><FONT SIZE=2>London EC1N 6SN</FONT>
</P>

</BODY>
</HTML></x-html>
From ???@??? Fri Mar 03 22:25:37 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Date: Wed, 01 Mar 2000 17:55:39 +0000
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: RE: [z-machine] back to the mouse
Message-ID: <db6a909849%kbracey@kbracey.acorn.co.uk>
In-Reply-To: <71D0D96AC395D211B56A00105A408BFD62B44F@euclid.monis.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <71D0D96AC395D211B56A00105A408BFD62B44F@euclid.monis.co.uk>
          David Kinder <david.kinder@monis.co.uk> wrote:

> 
> Perhaps we need a small clarification in the spec. Does anyone on this
> list know what Zip2000 (the only other v6 interp. I can think of) does?

I missed the start of this thread, but if you're asking what I think you're
asking, Zip 2000 supplies both @read_mouse coordinates and header coordinates
in real-time.

Looking at it, the following are possible faults:

   The header shouldn't be real-time, it should be updated on a click
   (10.3.1). We're not certain about @read_mouse, but real-time seems
   useful (although the menu component of it isn't real-time).
   
   If there is no extension header, @read_mouse won't work.
   
   If the pointer leaves the Zip 2000 window or the current Z-machine window,
   the mouse state, including the buttons, stops being updated until the
   pointer reenters the window. Is this the optimum behaviour?
   
If you have the source, you can see the relevant code in the c.riscosio
and c.riscoswimp files.

-- 
Kevin Bracey, Senior Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/


From ???@??? Fri Mar 03 22:26:13 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Message-Id: <200003021230.HAA28092@chmls06.mediaone.net>
From: "Jason C Penney" <jpenney@chelmsford.com>
To: z-machine@gmd.de
Date: Thu, 2 Mar 2000 07:30:33 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: [z-machine] back to the mouse
Reply-to: Jason C Penney <jpenney@chelmsford.com>
In-reply-to: <db6a909849%kbracey@kbracey.acorn.co.uk>
References: <71D0D96AC395D211B56A00105A408BFD62B44F@euclid.monis.co.uk>
Sender: owner-z-machine@gmd.de
Precedence: bulk


Kevin Bracey sent a message across the ether on 1 Mar 00, (17:55) stating:

> I missed the start of this thread, but if you're asking what I think you're
> asking, Zip 2000 supplies both @read_mouse coordinates and header coordinates
> in real-time.
> 
> Looking at it, the following are possible faults:
> 
>    The header shouldn't be real-time, it should be updated on a click
>    (10.3.1). We're not certain about @read_mouse, but real-time seems
>    useful (although the menu component of it isn't real-time).

My reasons for believing that @read_mouse should give the current 
state of the mouse vs. last click are A) that's what the Infocom Dos 
terp does, and B) otherwise it's redundant with the header info 
(which should be last click).

>    If the pointer leaves the Zip 2000 window or the current Z-machine window,
>    the mouse state, including the buttons, stops being updated until the
>    pointer reenters the window. Is this the optimum behaviour?

That seems as sensible a solution as any in this case IMO.

Jay


----
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"The trouble with computers of course, is that they're very 
sophisticated idiots."     -- The Doctor


From ???@??? Fri Mar 03 22:26:18 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Message-ID: <38BDFE12.B8AE2BDA@ot.com.au>
Date: Thu, 02 Mar 2000 16:37:22 +1100
From: Kyle Dean <kyled@ot.com.au>
Organization: Open Telecommunications
MIME-Version: 1.0
CC: z-machine@gmd.de
Subject: Re: [z-machine] back to the mouse
References: <HLLOEFJOEIDBCCAA@my-deja.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


Rather than watch the mouse hover around, and update the header all the
time, couldn't the interpreter only act when @read_mouse is called, or
the header is examined. (like memory mapped io)?

This is written without knowing anything about the implementation of
interpreters, but.


From ???@??? Fri Mar 03 22:26:22 2000
Return-Path: <z-machine-owner@mail.gmd.de>
MBOX-Line: From z-machine-owner@mail.gmd.de Thu Mar 02 09:31:22 2000
X-Track2: 2
X-Track: 1-1: 40
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
To: z-machine@gmd.de
Date: Wed, 01 Mar 2000 20:30:13 -0800
From: "Evin Robertson" <nitfol@my-deja.com>
Message-ID: <HLLOEFJOEIDBCCAA@my-deja.com>
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
Subject: RE: [z-machine] back to the mouse
X-Sender-Ip: 208.7.217.129
Organization: My Deja Email  (http://www.my-deja.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


On Wed, 1 Mar 2000 17:10:30    David Kinder wrote:
> Perhaps we need a small clarification in the spec. Does anyone on this
> list know what Zip2000 (the only other v6 interp. I can think of) does?
> Does nitfol support v6 yet?

Nitfol currently has marginal v6 support, and no v6 mouse support.


I think 'real-time' mouse support is probably useful, but it could
also be difficult to implement in some situations (think windowing
environments, remote display, weird widget sets, etc).  A fallback of:

 - Have @read_mouse report the last clicked location.

 - If the button has been clicked since the last timer callback or
   input, claim the button is currently pressed

Would be nice to allow / let games expect when things can't go
optimally.  This way the interpreter would only have to keep track of
clicks on it instead of watching the mouse hover around.


--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.

From ???@??? Fri Mar 03 22:26:26 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Date: Thu, 2 Mar 2000 09:25:27 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: [z-machine] Fwd: Relevant job opening (yes, relevant to the z-machine)
Message-ID: <20000302092527.A23636@bartlet.df.lth.se>
Reply-To: jacob@interwoven.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


Dear z-machinists,

I'm taking the liberty of forwarding this message to the list. Please
don't reply to me but to Jacob <jacob@interwoven.com>.

----- Forwarded message from Jacob Butcher <jacob@interwoven.com> -----

A friend just sent me this job opening.  I thought it probably relevant to
the text adventure community.  Perhaps you could pass it on to an appropriate
set of people, or even respond yourself?  (I have a sneaking suspicion that
the problem is easily solvable by porting a public domain Z-code interpreter,
but I am completely out of touch with the details here.)

				Jacob Butcher

> From: Clune, Ed [mailto:eclune@activision.com]
> Sent: Tuesday, February 29, 2000 2:56 PM
> Subject: searching for programmers of Nokia WAP unit for zork text games
> 
> I am looking for contract programmers that are interested in working with
> Nokia to create code on their new WAP cell-phone unit to run Zork and other
> text adventure games.  Please let me know if this is something you would be
> interested in working on or if can you provide recommendations on other
> qualified contractors who might be interested.  I'm looking for people with
> embedded system programming experience and some familiarity with text game
> programming (primarily logic and parsing).  Nokia would provide support for
> their unit.  Activision would provide data files for the various games.  We
> have no source code for the game parsing engine, just an executable, so one
> must be converted from public domain software or created from scratch.
> 
> Please let me know if you have suggestions of people to contact (or if you
> are interested yourself).
> 
> Thank you,
> 
> Ed Clune
> Manager
> Central Technology
> Activision
> LA, CA 90405
> 310-255-2532

----- End forwarded message -----

-- 
Magnus Olsson (mol@df.lth.se, zebulon@pobox.com)
------    http://www.pobox.com/~zebulon   ------


From ???@??? Sun Mar 26 22:10:58 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Date: Tue, 21 Mar 2000 08:16:41 -0700
From: "J. Holder" <jholder@frii.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] testers wanted / Jzip 2.1
Message-ID: <20000321081641.A76032@io.frii.com>
References: <20000223173503.A17797@io.frii.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20000223173503.A17797@io.frii.com>
Sender: owner-z-machine@gmd.de
Precedence: bulk



After a minor two week delay in which I became a father for the second
time (William Walker was born March 1st, yes, with all 10 fingers and toes),
I have continued bringing Jzip into Spec 1.0 compliance.  

I have fixed a number of things that Evin's test program found that 
made Jzip not spec 1.0 compiant.   

Almost done:
- support for @print_unicode and @check_unicode (probably ~2 weeks out)

Current fixes:
- rewrote much of property.c to support 64 properties per spec 1.0
- fixed the arithmetic shift operator
- fixed redirected output streams
- replaced all occurances of "short" with typedef (to help porters w/o 16 bit
  shorts.  You would think compiler writers would _like_ short shorts! HMPH!)
- fixed a lot of the color output code in unixio.c

Other than the support for the unicode stuff, this time I am DARNED CERTAIN
that Jzip 2.1 is spec 1.0 compliant.  Please prove me wrong!

Jzip 2.1 also supports Quetzal and StrictZ.

Remember: Jzip builds on ANY Unix (if it doesn't, I consider it broken,
mail me), Atari ST, and DOS w/ the Borland compiler.

You can find it at:
http://www.frii.com/~jholder/jzip/

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/



From ???@??? Wed Mar 29 11:53:48 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Date: Mon, 27 Mar 2000 08:25:53 -0700
From: "J. Holder" <jholder@frii.com>
To: z-machine@gmd.de
Subject: [z-machine] Opinions wanted: Unicode & Jzip 2.1
Message-ID: <20000327082553.A39592@io.frii.com>
References: <20000223173503.A17797@io.frii.com> <20000321081641.A76032@io.frii.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20000321081641.A76032@io.frii.com>
Sender: owner-z-machine@gmd.de
Precedence: bulk



I have been adding Unicode support to Jzip this week.  I am not
done yet (still a ways to go, since I want to test it a bit before release),
but I have a question of strategic importance that I wanted
your opinion(s) on.

To go to and from Unicode, Jzip has a bunch of files that contain the
translation tables from the Native codepage to Unicode.  

For context, I need suggestions that could work with Unices, Dos, OS/2, &
Atari ST.  Or it could be different for each platform, if this proves 
unwieldy.  But I would rather find a cross platform solution.

Questions:

1) Where should these files live? 
2) How should Jzip know how to find where they live? (env vars, etc.)

Codepages I currently have translation tables for are:
Basic:     ascii  
Unix:      iso8859-1 iso8859-2 iso8859-3 iso8859-4 iso8859-5 iso8859-6
           iso8859-7 iso8859-8 iso8859-9 iso8859-10
           dec-mcs   hproman8  next
OS/2, DOS: ibm1004 ibm437 ibm850 ibm851 ibm852
Windows:   cp1250 cp1251 cp1252 cp1253 cp1254 cp1255 cp1256 cp1257
Other:     mac

3) Are there any other codepages that would interest anyone here?
I have a _huge_ list of them (read:~9 MB) from dkuung.dk and I wrote a 
program that translates this into the Jzip condensed map format.  I am 
considering supplying EBCDIC just for kicks and grins...

-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/



From ???@??? Wed Mar 29 11:53:51 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Message-ID: <38DF9B3D.8317F1EB@dsres.com>
Date: Mon, 27 Mar 2000 18:32:45 +0100
From: Martin Frost <martin@dsres.com>
Organization: Dynamical Systems Research -- http://www.dynamical.com/
MIME-Version: 1.0
To: z-machine@gmd.de
Subject: Re: [z-machine] Opinions wanted: Unicode & Jzip 2.1
References: <20000223173503.A17797@io.frii.com> <20000321081641.A76032@io.frii.com> <20000327082553.A39592@io.frii.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


"J. Holder" wrote:

> For context, I need suggestions that could work with Unices, Dos, OS/2, &
> Atari ST.  Or it could be different for each platform, if this proves
> unwieldy.  But I would rather find a cross platform solution.

> 1) Where should these files live?
> 2) How should Jzip know how to find where they live? (env vars, etc.)

The normal situation with good Unix software seems to be that there are
compile-time BINDIR and LIBDIR options for binaries and auxilliary
files. These default to /usr/local/bin and /usr/local/lib or suchlike,
but can be changed easily (in Makefile, header file or similar).
Some software allows these to be overridden with environment vars,
but IMHO this is an unwieldy solution, as it means users must set
up their .profile or whatever before they can run the software.
As long as it's easy to change and rebuild, I don't have a problem
with this solution. It's easy and simple, and once the software is
built you can forget it. If you want to have prebuilt versions for
common Unices, set sensible defaults and document them. If people
want something else they can always rebuild.

I guess that non-Unix users are less used to compiling their own
software, though, so you may want environment variables there. In
that case, I'd still have defaults, making them relative to the
location of the binary, for example.

An alternative solution would be to have the directory specified
via a command-line argument, and have a shell script or batch
file for each OS which supplies this argument and can be easily
modified to suit local conventions. This has the advantage of
moving all the dependencies out of the binary, so it's a more
cross-platform solution, and removes the necessity to rebuild.

--m


From ???@??? Wed Mar 29 11:53:55 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Date: Mon, 27 Mar 2000 11:29:59 -0500
From: Christopher Currie <christopher@Currie.com>
Reply-To: Christopher Currie <christopher@Currie.com>
Message-ID: <19479.000327@currie.com>
To: "J. Holder" <jholder@frii.com>
CC: z-machine@gmd.de
Subject: Re: [z-machine] Opinions wanted: Unicode & Jzip 2.1
In-reply-To: <20000327082553.A39592@io.frii.com>
References: <20000327082553.A39592@io.frii.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


-----BEGIN PGP SIGNED MESSAGE-----

On Monday, March 27, 2000, it's been rumored that J. Holder said,
JH> For context, I need suggestions that could work with Unices, Dos,
OS/2, &
JH> Atari ST.  Or it could be different for each platform, if this
proves
JH> unwieldy.  But I would rather find a cross platform solution.

JH> Questions:

JH> 1) Where should these files live?
JH> 2) How should Jzip know how to find where they live? (env vars,
etc.)

You're asking for trouble on this one. Although I can't speak for the
Atari, these platforms have many different customs for where a
program's data files should live. So, in the interest of pleasing
everyone, it might be best to allow for multiple "standard"
locations,
and have Jzip search them in a predefined order such as

1) An environment var such as $JZIPDATA, if the platform supports it,

2) A unix-like standard location such as /usr/local/jzip/lib or
/usr/local/lib/jzip, especially if you ever plan to use autoconf

3) the a directory in executable's directory, e.g. if jzip is in
$JZIPBIN, the data could be found in $JZIPBIN/data or
$JZIPBIN/unicode

4) the executable's directory, (e.g. $JZIPBIN)

5) the current working directory

JH> 3) Are there any other codepages that would interest anyone here?
JH> I have a _huge_ list of them (read:~9 MB) from dkuung.dk and I
wrote a
JH> program that translates this into the Jzip condensed map format. 
I am
JH> considering supplying EBCDIC just for kicks and grins...

I'd grin to see that, just to know someone went through the pain of
testing it...

- --
Christopher
christopher@currie.com

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5i

iQCVAwUBON+MhsOO6BYHdZgpAQGrHAP+OfR+5qg0FSR9sKMCkmAzYY9iZV/TSkYx
GYbnzN9xuoc4MWF8kT16F7Wo7DjfxZMKfVO+iT+vIcTXE3GE18i7WzxOnDhyivvS
LkucJPz2PrAC9KvB/DWbxvAQf6GHtOgaCIQzQlYcGmXttiKtiBK/X7uWQKAzqgLv
5XqUM6DZQLk=
=ZlHP
-----END PGP SIGNATURE-----




From ???@??? Wed Mar 29 11:53:58 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
To: z-machine@gmd.de
Date: Mon, 27 Mar 2000 10:54:33 -0800
From: "Evin Robertson" <nitfol@my-deja.com>
Message-ID: <OINGPPMFBDPOJCAA@my-deja.com>
Mime-Version: 1.0
Subject: Re: [z-machine] Opinions wanted: Unicode & Jzip 2.1
Organization: My Deja Email  (http://www.my-deja.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


On Mon, 27 Mar 2000 08:25:53   J. Holder wrote:
> 3) Are there any other codepages that would interest anyone here?
> I have a _huge_ list of them (read:~9 MB) from dkuung.dk and I wrote a
> program that translates this into the Jzip condensed map format.  I am
> considering supplying EBCDIC just for kicks and grins...

While not a codepage, you might want to consider UTF-8 output (which
xterm with XFree86 4.0 can use).


--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.


From ???@??? Fri Mar 31 15:18:44 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Date: Wed, 29 Mar 2000 14:49:22 -0700
From: "J. Holder" <jholder@frii.com>
To: z-machine@gmd.de
Subject: [z-machine] Codepage conversion Standard Proposal
Message-ID: <20000329144922.A25847@io.frii.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-z-machine@gmd.de
Precedence: bulk



Guys,

For Jzip 2.1, I decided storing lots of little files with codepage
translation information from Native CPs to Unicode was messy. So,
in the spirit of Quetzal, I decided to store them in an IFF file.

The proposed Vaxum standard is below, as well as at:
http://www.frii.com/~jholder/vaxum/

I have the standard, sample map files, a program that can check 
valid maps, and a program that can build maps from a commonly
available format, all available in a zip file at:
http://www.frii.com/~jholder/vaxum/vaxum.zip  (48k)

Note that the program that make the Vaxum file is not the
friendliest thing in the world...

Any feedback would be appreciated, including the "why the hell
would anyone want that" type.  If no one uses it but me, well,
sobeit. (grin).

John
-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/



                    A Common Codepage Resource Standard
                             also called Vaxum:
                   Vaxum Adds Xcellent Unicode Manoeuvres

                 version 1.0 (March 27, 2000), by John Holder	

0. Motivation

This document provides a common way of storing codepage translation 
information that will be required of all interpreter writers who choose
to conform to Standard 1.0 of the Z-machine.  Note that this format is
of more general usefulness - it could be used with nearly any program.
Once this information has been created once, the tedium and redundancy
of doing it in more than one incompatible way is, well, redundant.
To my knowledge, this is the first (and hopefully last) IFF-based 
codepage conversion proposal.

The advantage of this format is that it is fairly easy to manage the
information for all the codepages - they are all in one file.  
Additionally, it will be incredibly simple to write tools to manipulate
this file format to allow the addition and subtraction of additional
codepages.

It may be useful for interpreter writers to share one of these files 
across multiple interpreters on the same platform.

1. Conventions

1.1 
A byte is an 8-bit unsigned quantity. 

1.2 
A word is a 16-bit unsigned quantity. Rather than writing Unicode words
in the form 0x1234, they will be written <U1234> to make it clear than the
value is a Unicode word.

1.5
All multi-byte numbers are stored in big-endian form: most significant byte 
first, then in strictly descending order of significance. 

1.6 
The reader is assumed to already be familiar with Unicode and other methods 
of character map encoding. 

1.7 
When form type names, which are four characters long, are set in running text, 
they're set in bold-face with spaces replaced by underscores. Thus ____ means 
"four spaces" and (c)_ means three letters of the copyright notation followed 
by a space. 
 

2. Overall structure

2.1 
For the purposes of flexibility, the overall format will be a new IFF type. 
The new FORM type is IFCP. 

2.2 
Three chunks are defined within this document to appear in the IFCP FORM: 
      'CPnm'  3.2
      'CPdt'  4.5

2.3 
Several chunks may also appear by convention in any IFF FORM: 
      'AUTH'  5.2, 5.3
      '(c) '  5.2, 5.4
      'ANNO'  5.2, 5.5


3. Chunk 'CPnm'

3.1
This chunk contains a codepage name in ASCII.  Multiple 'CPnm' chunks may 
follow each other, provided the last one is followed by a 'CPdt' chunk.
The following 'CPdt' chunk always containd the character map encoding for
the previous 'CPnm' chunks.

3.2
Each chunk has the format:
3.2.1 
      4 bytes       'CPnm' chunk ID
3.2.2 
      4 bytes       n      chunk length
3.2.3 
      n bytes       ...    ASCII bytes containing a Native codepage name

3.3
'CPnm' chunks outside of 'CCRS' chunks should be ignored.

4. Chunk 'CPdt'

4.1
Each word in the 'CPdt' block is a Unicode character.  The order of the 
Unicode characters in the map corresponds exactly to the order of the values
in the Native codepage.  If a native codepage doesn't have a character 
defined at a map point, the Unicode value will be <Uffff> (not a character).

4.2
Examples:

ISO-8859-3 character 0xc6 - word 0xc6 after the length word is <U0108>.
(0xc6 is the Latin capital letter C with a circumflex, 'C')

ISO-8859-3 character 0xae - word 0xae after the length word is <Uffff>.
(0xae is undefined in ISO-LATIN-3)

ISO-8859-3 character 0x00 - word 0x00 (the first word) after the length
                            word is <U0000>. (0x00 is NUL in ISO-LATIN-3)

4.3
If a Native codepage is 8-bit, it is possible for the mapping to contain
less than 256 characters.  Any character beyond the last defined in the
map can be assumed to be <Uffff>.

4.4
If a 'CPnm' chunk is present in a IFCP file, there must also be at least one
following 'CPdt' chunk.  The reciprocal is also true.

4.5
Each chunk has the format:
4.5.1 
      4 bytes      'CPdt'  chunk ID
4.5.2 
      4 bytes       n      chunk length
4.5.3 
      n words       ...    Words containing the Unicode character value for 
                           each codepoint in a Native mapping.
4.6
'CPdt' chunks outside of 'CCRS' chunks should be ignored.

4.7
Present 'CPdt' chunks may be inadequeate for storing shifted codepage 
information (e. g. SJIS).

5. Other IFF tags

5.1 
One of the advantages of the IFF standard is that extra chunks can be added 
to the format to extend it in various ways. For example, there are three 
standard chunk types defined, namely AUTH, (c)_, and ANNO. 

5.2 
AUTH, (c)_, and ANNO chunks all contain simple ASCII text (all characters 
in the range 0x20 to 0x7E). 
5.2.1 
The only indication of the length of this text is the chunk length (there 
is no zero byte termination as in C, for example). 
5.2.2 
The IFF standard suggests a maximum of 256 characters in this text as it 
may be displayed to the user upon reading, although it could get longer 
if required. 

5.3 
The AUTH chunk, if present, contains the name of the author or creator of
the file. For IFCP, this contains the creator of this IPCP file. There 
should only be one such chunk per file. 

5.4 
The (c)_ chunk contains the copyright message (date and holder, without 
the actual copyright symbol). This is used by the creator of the IFCP 
file. There should only be one such chunk per file.  When displaying 
(c)_ chunks, the © symbol should be used if possible.

5.5 
The ANNO chunk contains any textual annotation that the user or writing 
program sees fit to include. For the XX format, this block is normally not 
present. 

5.6 
The ANNO, (c)_ and AUTH chunks are all user-level information. Interpreters
must not rely on the presence or absence of these chunks, and should not 
have any behavior that is dependant upon them. 

5.7 
These chunks can be ignored when dealing with the IFCP format.  

5.8 
There are currently no extended chunks defined for the IFCP standard.  

6. Introduction to the IFF format

6.1     
This is based on the official IFF standards document, which is rather long 
and contains much that is irrelevant to the task in hand. I also do not have 
an electronic copy, so I am including only that which is relevant. Feel free 
to mail me (i.e. John Holder) if there are errors, inconsistencies, or 
omissions. For the inquisitive, a document containing much of the original 
standard, including the philosophy behind the structure, can be found at 
http://www.cica.indiana.edu/graphics/image_specs/ilbm.format.txt

6.2     
IFF stands for "Interchange File Format", and was developed by a committee 
consisting of people from Commodore-Amiga, Electronic Arts and Apple. It 
draws strongly on the Macintosh's concept of resources.

6.3     
The most fundamental concept in an IFF file is that of a chunk.
6.3.1   
A chunk starts with an ID and a length.
6.3.2   
The ID is the concatenation of four ASCII characters in the range 0x20 to 0x7E.
6.3.3   
If spaces are present, they must be the last characters (there must be no 
printing characters after a space).
6.3.4   
IDs are compared using a simple 32-bit equality test - note that this implies 
case sensitivity.
6.3.5   
The length is a 32-bit unsigned integer, stored in big-endian format (most 
significant byte, then second most, and so on).

6.4     
After the ID and length, there follow (length) bytes of data.
6.4.1   
If length is odd, these are followed by a single zero byte. This byte is *not*
included in the chunk length, but it is very important, as otherwise many 
68000-based readers will crash.

6.5     
A simple IFF file (such as the ones we will be considering) consists of a 
*single* chunk of type FORM.
6.5.1   
The contents of a FORM chunk start with another 4-character ID.
6.5.2   
This ID is also the concatenation of four characters, but these characters may 
only be uppercase letters and trailing spaces. This is to allow the FORM sub-ID
to be used as a filename extension.

6.6     
After the sub-ID comes a concatenation of chunks. The interpretation of these 
chunks depends on the FORM sub-ID (in this proposal, the sub-ID is IFCP), except 
that a few chunk types always have the same meaning (notably the AUTH, (c)_ and 
ANNO chunks described in section 7).

For reference, the other reserved types are:
    FOR[M1-9], CAT[ 1-9],
    LIS[T1-9], TEXT, and ____ (that is, four spaces).

6.7     
Each of these chunks may contain as much data as required, in whatever format 
is required.

6.8     
Multiple chunks with the same ID may appear; the interpretation of such chunks 
depends on the chunk. For example, multiple 'ANNO' chunks are acceptable, and 
simply refer to multiple annotations. If more than one chunk of a certain type 
is found, when the reader was only expecting one, the later chunks should 
simply be ignored (hopefully with a warning to the user).

6.9     
Indeed, skipping is the expected procedure for dealing with any unknown or 
unexpected chunk.

6.10    
Certain chunks may be compulsory if the FORM is meaningless without them. In 
this case the chunks 'CPnm' and 'CPdt' are both compulsory.


7.0 Notes

7.1
Sample source code and map files are available at
http://www.frii.com/~jholder/vaxum/vaxum.zip

7.2
The current version of the standard is at
http://www.frii.com/~jholder/vaxum/

7.3
Unix users note that public domain BDF fonts can be had for most of these 
mappings at 
http://czyborra.com/charsets/iso8859.html


8.0 Credits

I ripped off the general format and all the IFF content information for this 
document from Martin Frost's Quetzal Standard.  This standard (the rest of it)
was created by John Holder (jholder@frii.com). Comments and suggestions
are always welcome (and any errors in this document are entirely my own).




From ???@??? Fri Mar 31 15:18:45 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track2: 2
Date: Wed, 29 Mar 2000 16:51:21 -0700
From: "J. Holder" <jholder@frii.com>
To: z-machine@gmd.de
Cc: z-machine@gmd.de
Subject: Re: [z-machine] Codepage conversion Standard Proposal
Message-ID: <20000329165121.A30467@io.frii.com>
References: <20000329144922.A25847@io.frii.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20000329144922.A25847@io.frii.com>
Sender: owner-z-machine@gmd.de
Precedence: bulk




Vaxum Erreta:  Delete section 3.3 and 4.6.  Renumber 4.7 to 4.6

Sorry.
John
-- 
John Holder (jholder@frii.com)         http://www.frii.com/~jholder/
<jholder> do you like FreeBSD?
<hal> I need to get the ISDN line running so that I will tell it to pass over
  me and replace my SuSE box with FreeBSD.



From ???@??? Thu Sep 14 17:46:20 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <000d01c0176e$01dc9a90$6f10010a@avantgo.com>
From: "David Turnbull" <dpt@newsguy.com>
To: <z-machine@gmd.de>
Subject: [z-machine] Frobnitz for PalmOS
Date: Tue, 5 Sep 2000 12:17:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


I have finally (after two years) released my Z-machine interpreter for the
PalmOS.  It's still alpha and needs a bit more testing, but it's totally
playable.  It will play all games except V6, has the graphics font, color
support, timed input, undo, a Palm friendly interface, and much more.  It's
free too.

If you own a PalmOS device, please check it out.  Try out the more difficult
things and let me know of any problems.  It should run every game perfectly,
without any strange display artifacts or complaints.

http://member.newsguy.com/~hangard/frobnitz/

Also, I need to know what games use the verify and erase_line opcodes.
Thanks.

-david


From ???@??? Mon Sep 25 21:46:04 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <003201c025f3$128c9e60$6401a8c0@win2000>
From: "David Turnbull" <dpt@newsguy.com>
To: <z-machine@gmd.de>
References: <000d01c0176e$01dc9a90$6f10010a@avantgo.com>
Subject: [z-machine] Frobnitz for PalmOS
Date: Sat, 23 Sep 2000 23:45:43 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


Alpha 5 version of Frobnitz for the Palm is posted.  There is also now a
Perl script that will make PDB files.  If nothing serious is found in the
next week or so I'm going to tag it beta and announce it to the world.

http://member.newsguy.com/~hangard/frobnitz/

-david


From ???@??? Mon Oct 02 22:22:42 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Sent: 28 Sep 2000 01:12:27 GMT
Message-ID: <39D29AED.4C4297E8@Currie.com>
Date: Wed, 27 Sep 2000 21:12:13 -0400
From: Christopher Currie <Christopher@Currie.com>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: z-machine@gmd.de
Subject: [z-machine] Assembly question about je (2OP:1)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


I was rooting through the txd output for Zork, and I came across an
example where "je," normally a 2OP instruction, was compiled in VAR form
with 4 operands (in this case, a variable and three small constants).
Checking the Standards Doc, the description for "je" states that the
interpreter should "Jump if [the first operand] is equal to any of the
subsequent operands." I was surprised to see this apparent exception to
the two operand rule, and this brief line is all that the standard seems
to say about it. None of the other 2OP operands seem to accept more than
two operands, even if they conceiveably could (e.g. "add," "and," "or,"
or "mul").

Am I reading the spec wrong? How do the various interpreters handle "je"
with >2 operands? It's interesting to note that Inform will not assemble
the following:


[ Main a;
    a = 5;
    @je a 99 35 5 ?mylabel;
    "Didn't jump!";
.mylabel;
    "Jumped!";
];


For the curious, here is the 'txd -adn' output, from Zork I, Revision
88, Serial 840726:

c659:  c1 95 88 13 46 88 c8     je             g78 #13 #46 #88 c666


Christopher Currie



From ???@??? Mon Oct 02 22:22:42 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <000d01c02924$f8341c20$54a6e0d8@zork>
From: "Patrick Kellum" <pkellum@lycosmail.com>
To: <z-machine@gmd.de>
References: <39D29AED.4C4297E8@Currie.com>
Subject: Re: [z-machine] Assembly question about je (2OP:1)
Date: Thu, 28 Sep 2000 01:20:27 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-z-machine@gmd.de
Precedence: bulk



There are quite a few (all? it's been a while since I checked) 2OP opcodes
that have variable forms, but I belive JE was the only one ever used.
It's the only one Inform supportes as vje.  It's actually an extreamly
handy opcode, I was always suprised it never got much mention.

Patrick
---
"Every weekday morning the school bell cast its glamour over
 the surrounding hills, calling the young to classes.  They came
 running down the slopes and leaping over the streams, out from
 caves and the hollows of trees and suburban tract homes, impelled
 by powers greater then their own to gain an education."
    "The Iron Dragon's Daughter" by Michael Swanwick




----- Original Message -----
From: "Christopher Currie" <Christopher@Currie.com>
To: <z-machine@gmd.de>
Sent: Wednesday, September 27, 2000 6:12 PM
Subject: [z-machine] Assembly question about je (2OP:1)


> I was rooting through the txd output for Zork, and I came across an
> example where "je," normally a 2OP instruction, was compiled in VAR form
> with 4 operands (in this case, a variable and three small constants).
> Checking the Standards Doc, the description for "je" states that the
> interpreter should "Jump if [the first operand] is equal to any of the
> subsequent operands." I was surprised to see this apparent exception to
> the two operand rule, and this brief line is all that the standard seems
> to say about it. None of the other 2OP operands seem to accept more than
> two operands, even if they conceiveably could (e.g. "add," "and," "or,"
> or "mul").
>
> Am I reading the spec wrong? How do the various interpreters handle "je"
> with >2 operands? It's interesting to note that Inform will not assemble
> the following:
>
>
> [ Main a;
>     a = 5;
>     @je a 99 35 5 ?mylabel;
>     "Didn't jump!";
> .mylabel;
>     "Jumped!";
> ];
>
>
> For the curious, here is the 'txd -adn' output, from Zork I, Revision
> 88, Serial 840726:
>
> c659:  c1 95 88 13 46 88 c8     je             g78 #13 #46 #88 c666
>
>
> Christopher Currie
>


From ???@??? Mon Oct 02 22:22:42 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <39D2FD14.92400537@cisco.com>
Date: Thu, 28 Sep 2000 19:11:00 +1100
From: David Beazley <dbeazley@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Christopher Currie <Christopher@Currie.com>
CC: z-machine@gmd.de
Subject: Re: [z-machine] Assembly question about je (2OP:1)
References: <39D29AED.4C4297E8@Currie.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


Hi Christopher,

From memory (which is very rusty on this subject), in the
original Infocom version 1, 2 and 3 games (of which Zork
is one) allowed three opcodes to have their arguments
passed on an internal stack, instead of having them passed
explicitly. This allowed ONLY these three opcodes to be
passed a variable number of arguments.

In the old ITF interpreter we called these opcodes:
  compare, std_gosub, and input.
I believe the standard calls them: je, call, and sread.

Further, "je" is the ONLY opcode in the 2OP table in
the standard which ia allowed to behave in this way.

Later, Infocom version 4, 5 and 6 games expanded the
number of opcodes that could be passed a variable number
of arguments.

So, strictly speaking, you could validly argue that "je"
does not really belong in the 2OP table, but in the VAR
table. But that would make things messy ... :-)
It appears that it was the exception rather than the rule.

Unfortunately, I don't know how this translates into
Inform, but it should answer your question about the
other 2OP opcodes.


Hope this helps,

David.



Christopher Currie wrote:
> 
> I was rooting through the txd output for Zork, and I came across an
> example where "je," normally a 2OP instruction, was compiled in VAR form
> with 4 operands (in this case, a variable and three small constants).
> Checking the Standards Doc, the description for "je" states that the
> interpreter should "Jump if [the first operand] is equal to any of the
> subsequent operands." I was surprised to see this apparent exception to
> the two operand rule, and this brief line is all that the standard seems
> to say about it. None of the other 2OP operands seem to accept more than
> two operands, even if they conceiveably could (e.g. "add," "and," "or,"
> or "mul").
> 
> Am I reading the spec wrong? How do the various interpreters handle "je"
> with >2 operands? It's interesting to note that Inform will not assemble
> the following:
> 
> [ Main a;
>     a = 5;
>     @je a 99 35 5 ?mylabel;
>     "Didn't jump!";
> .mylabel;
>     "Jumped!";
> ];
> 
> For the curious, here is the 'txd -adn' output, from Zork I, Revision
> 88, Serial 840726:
> 
> c659:  c1 95 88 13 46 88 c8     je             g78 #13 #46 #88 c666
> 
> Christopher Currie

-- 
David Beazley                        email:dbeazley@cisco.com
Software Engineer                    email:dbeazley@acm.org
Cisco Systems                        Phone: +61 2 8448-7667
Level 4, Tower B, The Zenith Centre  FAX:   +61 2 8448-7688
821-843 Pacific Highway
Chatswood, NSW, 2067
AUSTRALIA



From ???@??? Mon Oct 02 22:22:42 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 27 Sep 2000 21:53:10 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <200009280153.VAA01747@pond.com>
To: Christopher@Currie.com, z-machine@gmd.de
Subject: Re:  [z-machine] Assembly question about je (2OP:1)
Sender: owner-z-machine@gmd.de
Precedence: bulk


} Am I reading the spec wrong? How do the various interpreters handle "je"
} with >2 operands? It's interesting to note that Inform will not assemble
} the following:

No, you've got it right - je is weird.


[ Main a;
    a = 5;
    @je a 99 35 5 ?mylabel;
    "Didn't jump!";
.mylabel;
    "Jumped!";
];

Change the "je" to "vje" (an Inform-ism) and it should work.



From ???@??? Mon Oct 02 22:22:43 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Reply-To: <zmachine.gmd.de@popey.com>
From: "Alan Pope" <popey@popey.com>
To: <z-machine@gmd.de>
Subject: [z-machine] z on a client-server system
Date: Sat, 30 Sep 2000 13:36:02 +0100
Message-ID: <000001c02ada$feab9a30$0300a8c0@mshome.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-z-machine@gmd.de
Precedence: bulk


Hi all,

I am considering writing a z-machine interpreter for a client server
architecture system called SAP R/3. There are a few restrictions for
example, graphics and sound are non existent. The one which I am having a
little trouble with - and this is where you guys come in, is with keyboard
input. The way that R/3 works is a bit like http - the user sends a request
and gets a response. The problem is (as I understand it) the z-machine needs
to be able to do things (timing/interrupt) whilst the user is thinking. With
R/3 nothing is being executed whilst the user is thinking. It is only when
the request is sent to the server that processing can continue. Once the
results are ready they are sent back to the user and the program effectively
goes idle. The user has a GUI on their pc which can handle input fields for
text input and output fields to display responses, but I can't get
individual keypresses easily. I have to get a whole line from the user and
then play with it.

Now my question is, am I reading the specs for z correctly in thinking that
z needs to take each keypress and pass that to the story or is that not the
case? Can I just pass a string to the z which feeds that to the story?

Thanks
Al.
http://www.popey.com/


From ???@??? Mon Oct 02 22:22:43 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sat, 30 Sep 2000 14:48:38 -0700
Message-Id: <200009302148.OAA00459@app.dial.idiom.com>
From: Alhambra Petrofsky <Alhambra@petrofsky.berkeley.ca.us>
To: zmachine.gmd.de@popey.com
CC: z-machine@gmd.de
In-reply-to: <000001c02ada$feab9a30$0300a8c0@mshome.net> (popey@popey.com)
Subject: Re: [z-machine] z on a client-server system
References:  <000001c02ada$feab9a30$0300a8c0@mshome.net>
Sender: owner-z-machine@gmd.de
Precedence: bulk


> From: "Alan Pope" <popey@popey.com>
> Date: Sat, 30 Sep 2000 13:36:02 +0100

> I am considering writing a z-machine interpreter for a client server
> architecture system called SAP R/3...

> Now my question is, am I reading the specs for z correctly in thinking that
> z needs to take each keypress and pass that to the story or is that not the
> case? Can I just pass a string to the z which feeds that to the story?

The read_char opcode requires single-character input, the read opcode
reads a whole line.

The great majority of z-machine applications are interactive fiction,
in which the great majority of input is untimed line-at-a-time.  If
you don't support single-character nor timed input, your interpreter
will still be quite useful.  For ideas on how to provide ersatz
support for these features, see dumb-frotz.  Included below is the
relevant portion of the dumb-frotz README.

-al


======================
SINGLE-CHARACTER INPUT
======================

   We assume a normal line-buffered input environment, which means that
   single character input is not really possible.  When the game wants a
   single character, you must type the character and a return (i.e. enter
   a single-character line).  If you just hit return (i.e. enter a blank
   line) then the return is used as the character.  If you enter a
   multiple-character line, the extra characters are used one at a time
   for subsequent single-character inputs, with no screen update in
   between.  This is useful for traversing menus.  You can tell if the
   game expects a single character or a full line by observing the
   line-type character which is output in the first column of every line.
   You can enter the non-printing characters (arrow keys, etc.) using
   backslashed escape sequences.

===========
TIMED INPUT
===========

   Standard getchar can not be made to timeout.  However, we can and do
   keep track of real time (to one second granularity) using time().  The
   effect we produce is that the game is paused while reading input, but
   when you finish entering a line, the game is first advanced by the
   amount of real time that elapsed while you were typing the line, and
   then the line is fed to the game.

   For example, if a game repeatedly does a read with a one second
   timeout, like Border Zone, and the user takes five seconds to enter
   the line "north", then the timeout routine is called five times, which
   updates the game's clock, and then "north" is returned to the game
   (unless the timeout routine returned "abort" one of those times, in
   which case the "north" is discarded).  If you've been sitting thinking
   for a little while and want to check if anything has happened then
   enter '\w'.  This will trigger some number of timeouts to bring the
   game up to the current time.



From ???@??? Mon Oct 02 22:22:43 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Alan Pope" <popey@popey.com>
To: <z-machine@gmd.de>
Subject: RE: [z-machine] z on a client-server system
Date: Sun, 1 Oct 2000 08:23:33 +0100
Message-ID: <000001c02b78$81b61e80$0300a8c0@mshome.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-reply-to: <200009302148.OAA00459@app.dial.idiom.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-z-machine@gmd.de
Precedence: bulk


Ah, thanks for that. That was going to be my approach if it wasn't too
important to get single characters.

Thanks all.
Al.

> -----Original Message-----
> From: Alhambra Petrofsky [mailto:Alhambra@petrofsky.berkeley.ca.us]
> Sent: 30 September 2000 22:49
> To: zmachine.gmd.de@popey.com
> Cc: z-machine@gmd.de
> Subject: Re: [z-machine] z on a client-server system
>
>
> > From: "Alan Pope" <popey@popey.com>
> > Date: Sat, 30 Sep 2000 13:36:02 +0100
>
> > I am considering writing a z-machine interpreter for a client server
> > architecture system called SAP R/3...
>
> > Now my question is, am I reading the specs for z correctly in
> thinking that
> > z needs to take each keypress and pass that to the story or is
> that not the
> > case? Can I just pass a string to the z which feeds that to the story?
>
> The read_char opcode requires single-character input, the read opcode
> reads a whole line.
>
> The great majority of z-machine applications are interactive fiction,
> in which the great majority of input is untimed line-at-a-time.  If
> you don't support single-character nor timed input, your interpreter
> will still be quite useful.  For ideas on how to provide ersatz
> support for these features, see dumb-frotz.  Included below is the
> relevant portion of the dumb-frotz README.
>
> -al
<snip>


From ???@??? Fri Oct 20 19:50:22 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: cutter.rexx.com: erkyrath owned process doing -bs
Date: Thu, 19 Oct 2000 20:31:03 -0700 (PDT)
From: Andrew Plotkin <erkyrath@eblong.com>
X-Sender: erkyrath@cutter.rexx.com
To: Z-Machine List <z-machine@gmd.de>
Subject: [z-machine] Zip bug fixes, and spec compliance
Message-ID: <Pine.BSF.4.21.0010191959140.67310-100000@cutter.rexx.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@gmd.de
Precedence: bulk


I've just uploaded new versions of MaxZip and XZip to gmd.de.

These include some fixes to long-standing bugs in the Zip engine:
 * log_shift opcode messed up negative numbers
 * print_char 13 didn't perform a linebreak (the way new_line or printing
   "^" would)
 * support for 64-byte property lists (not a bug, but a feature added in
   Z-Spec 1.0)

Patches for the first two appended to this message. For the third, I
stole a couple of lines of code from JZip. (It would have been more
elegant to steal the entire property.c file, but I was lazy. Nonetheless,
thanks, John. :-)

But the other thing I did, which is the real reason I'm posting, is that I
added user preferences to set the "Z-Spec-Compliant" header flag.

If you've read RAIF you've already seen this discussion. If not -- well, I
never liked that header flag; I thought it conveyed no information. 

A flag that declares whether you support a particular feature conveys
information; a game that uses that feature can check for it. Notice:
mis-setting such a flag is a demonstratable bug *either way*. If an
interpreter doesn't support color, but says it does, a game will rely on
color features and cause problems. If the terp doesn't support color, but
says it does, a game will avoid using color and (again) annoy the
player. Either way, there is a motivation to fix the bug.

But a flag that says "This interpreter obeys the specification"? It
doesn't give information about any feature, because any terp can implement
a feature from the 1.0-spec without being a 1.0-compliant interpreter. It
doesn't guarantee anything to the game, because a terp can have a bug
whether or not it sets the flag.

Basically, the only effect the compliance flag can have is to encourage
games to test for it, in order to encourage interpreters to set the
flag. That has nothing to do with *actual* spec compliance; it's just a
tautology.

And, in fact, this has now occurred in the IFComp. One entry refuses to
run on terps that don't set the spec-compliant flag. (Another prints a
warning, but runs.) 

I feel I *have* to release terp upgrades, in service to the players, and
even to the author. (I think the author made a mistake, but it was an easy
mistake to make.) The upgrade has nothing to do with spec compliance. (I
am in fact also fixing bugs at the same time, but I've had those fixes
pending since May -- I just haven't put in the effort of a release since
last year.) (Note that the log_shift and 64-byte-property fixes have *no*
effect on any IFComp entry. The linebreak bug does, but it's purely an
aesthetic matter -- paragraphs run together, usually in help menus.) 

Anyway, I have decided to leave the spec-compliance flag purely in the
hands of the player. 

You may well accuse me of trying to underscore the alleged meaninglessness
of the flag -- I won't disagree. I figure, I *still* don't guarantee my
terps are spec-1.0 compliant. (I've never implemented the Unicode opcodes,
even as no-ops.) So the terp has to either lie, or refuse to run certain
games. I will not enforce either choice; so it's up to the player.

There. That's my little rant.

--Z

------------------- start ---------------------


*** text.c~	Sat Jul 11 18:25:07 1998
--- text.c	Thu Oct 12 00:24:04 2000
***************
*** 431,437 ****
      } 
      else if (c == 13) {
      
!     	write_char ('\r');
      	
      }
      else {
--- 431,438 ----
      } 
      else if (c == 13) {
      
!         /* write_char ('\r'); */
!         new_line ();
      	
      }
      else {
***************
*** 533,538 ****
--- 534,542 ----
      } else {
  
          /* No formatting or output redirection, so just output the character */
+ 
+         if (c == 13) 
+           c = '\n';
  
          script_char (c);
  
*** math.c	Wed Oct 18 23:26:22 2000
--- math.c~	Sat Jul 11 18:25:07 1998
***************
*** 168,180 ****
  #endif
  {
  
!     if ((short) b >= 0)
          store_operand (a << (short) b);
      else
!         if ((short) a >= 0)
              store_operand (a >> abs ((short) b));
          else
!             store_operand (~(((~a) & 0xFFFF) >> abs ((short) b)));
  
  }/* arith_shift */
  
--- 168,180 ----
  #endif
  {
  
!     if ((short) b > 0)
          store_operand (a << (short) b);
      else
!         if ((short) a > 0)
              store_operand (a >> abs ((short) b));
          else
!             store_operand (~((~a) >> abs ((short) b)));
  
  }/* arith_shift */
  

-------------------- end ----------------------


"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."



From ???@??? Sat Oct 21 16:13:57 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <39F07783.FA75F0F2@attglobal.net>
Date: Fri, 20 Oct 2000 12:49:07 -0400
From: "John W. Kennedy" <jwkenne@attglobal.net>
Reply-To: jwkenne@attglobal.net
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Zip bug fixes, and spec compliance
References: <Pine.BSF.4.21.0010191959140.67310-100000@cutter.rexx.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


Andrew Plotkin wrote:
> But a flag that says "This interpreter obeys the specification"? It
> doesn't give information about any feature, because any terp can implement
> a feature from the 1.0-spec without being a 1.0-compliant interpreter. It
> doesn't guarantee anything to the game, because a terp can have a bug
> whether or not it sets the flag.

I believe the intent is to cover 64-byte properties, the Unicode ops (at
least degenerately), and (and this seems to be the most important at
present) recursive use of stream 3.
 
-- 
John W. Kennedy
(Working from my laptop)



From ???@??? Sat Oct 21 16:13:57 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: cutter.rexx.com: erkyrath owned process doing -bs
Date: Fri, 20 Oct 2000 10:34:32 -0700 (PDT)
From: Andrew Plotkin <erkyrath@eblong.com>
X-Sender: erkyrath@cutter.rexx.com
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] Zip bug fixes, and spec compliance
Message-ID: <Pine.BSF.4.21.0010201034200.90852-100000@cutter.rexx.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@gmd.de
Precedence: bulk


On Fri, 20 Oct 2000, John W. Kennedy wrote:

> Andrew Plotkin wrote:
> > But a flag that says "This interpreter obeys the specification"? It
> > doesn't give information about any feature, because any terp can implement
> > a feature from the 1.0-spec without being a 1.0-compliant interpreter. It
> > doesn't guarantee anything to the game, because a terp can have a bug
> > whether or not it sets the flag.
> 
> I believe the intent is to cover 64-byte properties, the Unicode ops (at
> least degenerately), and (and this seems to be the most important at
> present) recursive use of stream 3.

The intent is not served. My interpreters have supported nested stream-3
for years now. I know there are interpreters that set the spec-compliance
flag but don't touch the Unicode stuff. I don't know what the state of
64-byte properties is, but I certainly wouldn't rely on the
spec-compliance flag being *either* necessary *or* sufficient to guarantee
support.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Tue Oct 24 10:21:56 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp1.ihug.co.nz: Host p234-tnt4.akl.ihug.co.nz [203.173.212.234] claimed to be uecs
Organization: Ultra Enterprises
Message-Id: <4.2.0.58.20001021162637.009ac6d0@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Sat, 21 Oct 2000 17:02:59 +1300
To: Z-Machine List <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] spec compliance
In-Reply-To: <Pine.BSF.4.21.0010191959140.67310-100000@cutter.rexx.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>At 20:31 19/10/00 -0700, Andrew Plotkin wrote:
 >
 >But the other thing I did, which is the real reason I'm posting,
 >is that I added user preferences to set the "Z-Spec-Compliant"
 >header flag.
 >
 >If you've read RAIF you've already seen this discussion. If not 
--
 >well, I never liked that header flag; I thought it conveyed no
 >information.
[...]

My understanding is that the intent was to convey to game-authors 
that if the flag is set, the terp is 100% compliant with the 
spec.  If the flag isn't set, the terp isn't completely compliant, 
even though it might be 99% there.

If set (correctly, of course) this helps the game-authors 
recognise that all the fancy stuff they're using in their games 
will work exactly as they want.  If not set, however, it doesn't 
tell them a thing; and as you said, there are some cases where it 
may erroneously be set anyway, helping to confuse matters.

Here's a suggestion that might help this, though I'm not sure how 
practical it is... perhaps it can be used as a starting point.
  1. Have a new header bit (probably in the extensions area) 
showing that the terp supports compliance-interrogation.
  2. If that bit is set, the terp will accept a new instruction, 
called @zspec_test or similar, that takes as input a section 
number from the Z-Spec, and produces a numeric code, such as:
       0: doesn't support this section
       1: partial support for this section (some features 
implemented, but cannot rely on full functionality)
       2: fully supports this section
     Perhaps -1, 0, and 1 might be better for this.
  3. If an individual paragraph in the spec is specified, for 
example "3.8.5.1", the terp reports compliance for that paragraph 
only. (shouldn't be too hard to put in a lookup table)
  4. If a paragraph group is specified, for example "3.8.5", the 
terp reports 0 if all subparagraphs return 0, 2 if all 
subparagraphs return 2, or 1 otherwise.
  5. An empty query "" (or possibly "0", whichever is easier) 
reports total compliance with the spec, as above.

The only real problem I foresee with this sort of arrangement is 
if, in later specifications, the section numbers change 
drastically.  Perhaps for this situation, the spec version number 
the game is expecting can be part of the query, so that the terp 
selects the lookup table for that spec version.  At the moment I 
believe there would be only two possible values, "0.6" and "1.0"; 
and the former wouldn't support this extension anyway.

Any thoughts?

--
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
<http://ue.cjb.net/>, <http://crash.ihug.co.nz/~brianc/>
ICQ: 2274180  (<www.icq.com>)
For a dynamic signature like this, <http://ue.cjb.net/dynasig/>
----
Write all complaints legibly in this space -> []


</x-flowed>
From ???@??? Tue Oct 24 10:21:56 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <000e01c03b19$6b906420$9910010a@dturnbullsmd>
From: "David Turnbull" <dpt@newsguy.com>
To: "Z-Machine List" <z-machine@gmd.de>
References: <4.2.0.58.20001021162637.009ac6d0@pop.ihug.co.nz>
Subject: Re: [z-machine] spec compliance
Date: Fri, 20 Oct 2000 21:43:12 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> Any thoughts?

Yes!  Will you please share those mushrooms with us?

-david


From ???@??? Tue Oct 24 11:11:15 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp1.ihug.co.nz: Host p250-apx1.akl.ihug.co.nz [203.173.192.250] claimed to be uecs
Organization: Ultra Enterprises
Message-Id: <4.2.0.58.20001024105714.00a035d0@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 24 Oct 2000 10:58:28 +1300
To: "Z-Machine List" <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] spec compliance
In-Reply-To: <000e01c03b19$6b906420$9910010a@dturnbullsmd>
References: <4.2.0.58.20001021162637.009ac6d0@pop.ihug.co.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>At 21:43 20/10/00 -0700, David Turnbull wrote:
 >
 >> Any thoughts?
 >
 >Yes!  Will you please share those mushrooms with us?

I agree, it's horribly complicated as it stands; it was mainly 
intended as a starting point.  But you've got to admit, it's 
comprehensive! :)

--
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
<http://ue.cjb.net/>, <http://crash.ihug.co.nz/~brianc/>
ICQ: 2274180  (<www.icq.com>)
For a dynamic signature like this, <http://ue.cjb.net/dynasig/>
----
When it's you against the world, bet on the world.


</x-flowed>
From ???@??? Wed Oct 25 10:41:22 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <002601c03d82$d6aeda00$6401a8c0@win2000>
From: "David Turnbull" <dpt@newsguy.com>
To: "Z-Machine List" <z-machine@gmd.de>
References: <4.2.0.58.20001021162637.009ac6d0@pop.ihug.co.nz> <4.2.0.58.20001024105714.00a035d0@pop.ihug.co.nz>
Subject: Re: [z-machine] spec compliance
Date: Mon, 23 Oct 2000 23:22:46 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> I agree, it's horribly complicated as it stands; it was mainly
> intended as a starting point.  But you've got to admit, it's
> comprehensive! :)

Oops, I took that message as a joke.  Seriously then, what problem is it
that you are trying to solve?  It seems silly that each interpreter should
have to say whether it can add numbers, move objects around, and know where
dynamic memory ends.  Most of the spec you MUST implement correctly for
games to run.  Other stuff, such as color and font support, is indicated by
feature bits.  The feature bits and header information are the secret to
making a complex game run on any interpreter.  Unfortunately, as has been
stated before, the spec version doesn't actually mean anything and is very
misleading.

Also, being comprehensive has it's price.  Frobnitz is 64K right now, and
runs on a device where memory is precious.  I certainly woldn't be keen to
the idea of adding 10K of strings to the file for this feature.

I once saw a list of things an engineer was to ask of himself when starting
a new project.  I didn't save it because it was things I did already, but
I'd like to recall a few of the most important here.

1.  Do you know why you are doing this work?  When exactly is the problem
you are trying solve?
2.  Can you back out your work if you make a mistake or get blocked?
3.  How will the work you are doing affect others?

What I'm getting at is that the answer to #1 is unclear.  And implementing
your idea would cause me great concern about #3.

-david


From ???@??? Wed Oct 25 10:41:22 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: cutter.rexx.com: erkyrath owned process doing -bs
Date: Tue, 24 Oct 2000 11:54:42 -0700 (PDT)
From: Andrew Plotkin <erkyrath@eblong.com>
X-Sender: erkyrath@cutter.rexx.com
To: Z-Machine List <z-machine@gmd.de>
Subject: Re: [z-machine] spec compliance
In-Reply-To: <4.2.0.58.20001021162637.009ac6d0@pop.ihug.co.nz>
Message-ID: <Pine.BSF.4.21.0010241148380.39930-100000@cutter.rexx.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@gmd.de
Precedence: bulk


On Sat, 21 Oct 2000, Gavin Lambert wrote:

> At 20:31 19/10/00 -0700, Andrew Plotkin wrote:
>  >
>  >But the other thing I did, which is the real reason I'm posting,
>  >is that I added user preferences to set the "Z-Spec-Compliant"
>  >header flag.
>  >
>  >If you've read RAIF you've already seen this discussion. If not 
> --
>  >well, I never liked that header flag; I thought it conveyed no
>  >information.
> [...]
> 
> My understanding is that the intent was to convey to game-authors 
> that if the flag is set, the terp is 100% compliant with the 
> spec.  If the flag isn't set, the terp isn't completely compliant, 
> even though it might be 99% there.

But in practice, it doesn't convey this accurately. Furthermore, it's not
a useful question to be asking.
 
> Here's a suggestion that might help this, though I'm not sure how 
> practical it is... perhaps it can be used as a starting point.
>   1. Have a new header bit (probably in the extensions area) 
> showing that the terp supports compliance-interrogation.
>   2. If that bit is set, the terp will accept a new instruction, 
> called @zspec_test or similar, that takes as input a section 
> number from the Z-Spec, and produces a numeric code, such as:
>        0: doesn't support this section
>        1: partial support for this section (some features 
> implemented, but cannot rely on full functionality)
>        2: fully supports this section
>      Perhaps -1, 0, and 1 might be better for this.

This sort of feature-by-feature approach makes sense (although I wouldn't
go into so much detail as a paragraph-by-paragraph approach!)

However, at this point I don't think there's much point to adding it to
the Z-Spec. The spec is unlikely to change; there has been no serious
discussion of changing it in (literally) years. Z-machine interpreters are
only changing to catch up on bugs, and to add user-level (non-spec-
related) features.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."


From ???@??? Wed Oct 25 22:45:46 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@chelmsford.com>
To: Z-Machine List <z-machine@gmd.de>
Date: Tue, 24 Oct 2000 23:37:44 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [z-machine] spec compliance
Reply-to: Jason C Penney <jpenney@chelmsford.com>
Message-ID: <39F61D48.4589.D1CE68@localhost>
References: <4.2.0.58.20001021162637.009ac6d0@pop.ihug.co.nz>
In-reply-to: <Pine.BSF.4.21.0010241148380.39930-100000@cutter.rexx.com>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Sender: owner-z-machine@gmd.de
Precedence: bulk


Andrew Plotkin sent a message across the ether on 24 Oct 2000, (11:54) stating:

> On Sat, 21 Oct 2000, Gavin Lambert wrote:
> 
> > Here's a suggestion that might help this, though I'm not sure how
> > practical it is... perhaps it can be used as a starting point.
> >   1. Have a new header bit (probably in the extensions area) 
> > showing that the terp supports compliance-interrogation.
> >   2. If that bit is set, the terp will accept a new instruction, 
> > called @zspec_test or similar, that takes as input a section 
> > number from the Z-Spec, and produces a numeric code, such as:
> >        0: doesn't support this section
> >        1: partial support for this section (some features 
> > implemented, but cannot rely on full functionality)
> >        2: fully supports this section
> >      Perhaps -1, 0, and 1 might be better for this.
> 
> This sort of feature-by-feature approach makes sense (although I
> wouldn't go into so much detail as a paragraph-by-paragraph approach!)

I don't know how worth while it is, but here's the proposal I worked 
on based on discussions back in 99 some time for a header extension 
(fairly V6 centric, but a lot of it is actually V4+).  I know it was 
discussed, but I can't seem to find the actual posting in my archive. 
Might be worth thinking about.  There are bits left over we could use 
for 'supports unicode' and 'supports 64-byte props', etc.

-- begin --
Header Extension Proposal 
Take 4
Draft 1
Jason C. Penney

After much thought and discussion this time around I've thrown out 
the new machine number and gone for the header extension, probably 
using Word 4.  I've also tried to handle some of the issues mentioned 
in Section 11 of the Blorb Spec (1.0).  When reading this, remember 
that I'm just trying to draft up a proposal. If an idea is crap, 
let's fix it.  Using some of the left over bits for 


Proposed format of header extension
-----------------------------------

Hex	Contents
===	========
 0	Extension honored?
 1	Supports music?
 2	Multiple sound support?
 3	Full font style combination support?
 4	Supports 3-OP @set_colour?
 5	Provides Amiga text pallette?
 6	Each window has own colour pair?
 7	Supports multiple text colours?
 8
 9
 A
 B
 C
 D
 E


Proposed information in header extension
----------------------------------------

* Extension honored? [all versions]

This bit should be set if the interpreter honors the extension by
filling out the rest of the header extension.  If it is not set then
game files should rely on the interpreter number to signify what
features are available.  


* Supports music? [V4+]

This bit should be set if the interpreter can play music.
(see Blorb Spec, 11)


* Multiple sound support? [V4+]

This bit should be set if the interpreter can play multiple sounds at
once.  If this is so, the interpreter should support the following
extended syntax for @sound_effect.

	@sound_effect number 3

This should stop the sound 'number' if it was currently playing.  If 
this bit is not set, then the interpreter follows what is currently 
in the ZSpec.  

* Full font style combination support? [V4+]

If this bit is set the interpreter should follow the "Ideal" model 
set out by the ZSpec, "all text styles should be available for each 
font (for instance, Courier bold should be obtainable) except that 
font 3 need only be available in Roman and Reverse Video".  If the 
interpreter is unable to fully comply with this the bit should be 
left unset, and game authors should take this to mean that they can't 
count on anything in this respect (which is how it is currently).  

* Supports 3-OP @set_colour? [V6]

This bit should be set if the interpreter supports the 3-OP version 
of @set_colour.  

* Provides Amiga text pallette? [V6]

This bit should be set if the interpreter provides the Amiga V6 text
pallette (i.e. colours 10-12).  

* Each window has own colour pair? [V6]

This bit should be set if the interpreter allows each window to have 
its own distinct colour pair.  If so @erase_window should use the 
windows background colour when erasing.  If not @erase_window will 
use the background colour stored in the header.  

* Supports multiple text colours? [V6]

this bit should be set if the interpreter allows multiple text 
colours to be displayed on screen.  If it is not set @set_colour 
should change all text visible on the screen (as the Amiga 
interpreter does now).  


[NOTE:  That leaves 7 bits.  Maybe 2 or 3 could be used to signify 
the colour depth the interpreter provides in some way.]  

What Dos Frotz would need to do to support this.
===============================================
(provided as an example, being that it is the interpreter I have the
most experience with)

For Frotz to support this with no changes to the current screen 
models
it provides it would have to check if the header extension is 
present,
and if so it should do the following:

In MCGA mode:
	Set bits 0,3,4,6 and 7

In Amiga mode:
	Set bits 0,3,4, and 5

[NOTE: I'm 99% certain it should set bit 3...]

-- end --



--
Jason C Penney (jpenney@chelmsford.com)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"Time and tide melts the snow man." --The Doctor



From ???@??? Fri Dec 08 23:13:14 2000
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <00fd01c05ff4$b9cdb8e0$0101a8c0@gmd.de>
From: "Volker Blasius" <volker.blasius@gmd.de>
To: <z-machine@gmd.de>
Subject: [z-machine] sorry for the spam you received
Date: Thu, 7 Dec 2000 03:23:36 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


Hi,

to keep this from happening again, I tried to reconfigure the list so
that only subscribers of the list may post to it.

If you receive this message, at least half my effort was successful.

Sorry for the inconvenience!
Volker


From ???@??? Wed May 23 21:59:45 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 21 May 2001 10:38:21 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: [z-machine] V3+ text shift codes
Message-ID: <2cb7117e4a%kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology plc, Cambridge, United Kingdom
X-Mailer: Messenger v1.40f for RISC OS
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.61b
Sender: owner-z-machine@gmd.de
Precedence: bulk


I've just found out that Infocom's V3+ interpreters handle the text shift
codes 4 and 5 in a more complex fashion than documented in the Z-machine
spec.

The spec says that 4 does a temporary shift to A1, and 5 does a temporary
shift to A2.

Trying a number of Infocom interpreters (V3-V6 from the IBM LTOI 2 CD),
I find:

Current alphabet      Code 4           Code 5
--------------------------------------------------
       A0             Shift to A1      Shift to A2
       A1             Lock to A1       Lock to A0
       A2             Lock to A0       Lock to A2

Now, none of Infocom's games (that I've gotten my hands on to analyse)
actually use this facility, which is presumably why it's not been spotted.

Has anyone else seen this behaviour?

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Wed May 23 21:59:47 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-Id: <200105211252.OAA25712@mail.gmd.de>
Date: Mon, 21 May 2001 14:50:20 +0200
From: "Fredrik Ramsberg" <fredrik@cambrianlabs.com>
To: z-machine@gmd.de
Subject: [z-machine] C64 V5 interpreters
X-Mailer: WorldClient Pro 2.2.3
Sender: owner-z-machine@gmd.de
Precedence: bulk


I'm working on modifying a V5 interpreter on the C64. I have
some questions at this point:

* What V5 ZIP for the C64 is the best (or are they identical?)

* Does any of you have any notes you want to share, that may be
  useful in understanding any of the V5 interpreter versions for
  the C64? Memory maps, start addresses of routines or other info
  would be appreciated.

* Has anyone but Infocom written a (possibly incomplete) ZIP in
  6502-family assembler? It seems that Pinforic has some time
  critical parts in 6502 assembler, but I'd like more than that.

Best regards,

/Fredrik


From ???@??? Wed May 23 21:59:48 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 21 May 2001 09:38:58 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <200105211338.JAA28153@pond.com>
To: kevin.bracey@pace.co.uk, z-machine@gmd.de
Subject: Re:  [z-machine] V3+ text shift codes
Sender: owner-z-machine@gmd.de
Precedence: bulk


} I've just found out that Infocom's V3+ interpreters handle the text shift
} codes 4 and 5 in a more complex fashion than documented in the Z-machine
} spec.

} The spec says that 4 does a temporary shift to A1, and 5 does a temporary
} shift to A2.

} Trying a number of Infocom interpreters (V3-V6 from the IBM LTOI 2 CD),
} I find:

} Current alphabet      Code 4           Code 5
} --------------------------------------------------
}        A0             Shift to A1      Shift to A2
}        A1             Lock to A1       Lock to A0
}        A2             Lock to A0       Lock to A2

Can you put a test file somewhere which demonstrates this behavior?  (I could
write one myself but I'm lazy)


From ???@??? Wed May 23 21:59:49 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 21 May 2001 14:52:51 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re:  [z-machine] V3+ text shift codes
Message-ID: <344297e4a%kbracey@kbracey.cam.pace.co.uk>
In-Reply-To: <200105211338.JAA28153@pond.com>
X-Organization: Pace Micro Technology plc, Cambridge, United Kingdom
X-Mailer: Messenger v1.40f for RISC OS
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="443171026--1246317208--1369148134"
X-Posting-Agent: RISC OS Newsbase 0.61b
Sender: owner-z-machine@gmd.de
Precedence: bulk

In message <200105211338.JAA28153@pond.com>
          "Matthew T. Russotto" <russotto@pond.com> wrote:

> Can you put a test file somewhere which demonstrates this behavior?  (I
> could write one myself but I'm lazy)

Attached are the source and executable for a test program.

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/
! This array is the sequence of Z-characters:
!
!       4 4 13  10 17 17  20 0 28  5 20 23  17 9 5
!
! which according to the Z-specification outputs "Hello w!rld",
! but on Infocom's interpreters outputs "HELLO World".

Array text --> $108D $2A31 $501C $1697 $C525;

[ Main x;
  print (address) text;
  @read_char 1 -> x;
  quit;
];

Attachment Converted: "C:\Inst\Mailed\TextTestz5,065"
From ???@??? Wed May 23 21:59:51 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 21 May 2001 17:03:18 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re:  [z-machine] V3+ text shift codes
Message-ID: <6af5347e4a%kbracey@kbracey.cam.pace.co.uk>
In-Reply-To: <344297e4a%kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology plc, Cambridge, United Kingdom
X-Mailer: Messenger v1.40f for RISC OS
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.61b
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <344297e4a%kbracey@kbracey.cam.pace.co.uk>
          Kevin Bracey <kevin.bracey@pace.co.uk> wrote:

> In message <200105211338.JAA28153@pond.com>
>           "Matthew T. Russotto" <russotto@pond.com> wrote:
> 
> > Can you put a test file somewhere which demonstrates this behavior?  (I
> > could write one myself but I'm lazy)
> 
> Attached are the source and executable for a test program.

Actually, I've just read Marnix Klooster's "The Z-machine, And How To
Emulate It", which mentions it obliquely but wrongly. 

It appears the ITF interpreter does actually agree with Infocom's
interpreters; it's ZIP that gets it wrong. The Z-specification must have been
written from looking at ZIP. Either that or it was a deliberate omission to
cater to the lowest common denominator of interpreters.

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Wed May 23 21:59:53 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <3B097401.99D797AA@gnelson.demon.co.uk>
Date: Mon, 21 May 2001 21:01:04 +0100
From: Graham Nelson <graham@gnelson.demon.co.uk>
Reply-To: graham@gnelson.demon.co.uk
X-Mailer: Mozilla 4.61 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: z-machine@gmd.de
Subject: Re:  [z-machine] V3+ text shift codes
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <344297e4a%kbracey@kbracey.cam.pace.co.uk>
          Kevin Bracey <kevin.bracey@pace.co.uk> wrote:
>It appears the ITF interpreter does actually agree with Infocom's
>interpreters; it's ZIP that gets it wrong. The Z-specification must
have been
>written from looking at ZIP. Either that or it was a deliberate
omission to
>cater to the lowest common denominator of interpreters.

I recall earnest discussion on this point, but forget exactly why we
came to the decision we did - but I don't think it was by accident.
I doubt very much if Infocom's interpreters all agree on this point
themselves, and in cases where no existing game use a feature, we
felt reasonably free to simplify. But there certainly ought to be a
footnote to the specification on the subject. Would someone like to
research the matter further, and write up a brief paragraph summarising
the position?

I'd vote against actually changing the specification, unless it can be
shown to be erroneously interpreting an Infocom story file.

  Graham


From ???@??? Wed May 23 22:00:03 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-Id: <200105220755.JAA28658@hurz4.rz.hu-berlin.de>
Subject: Re: [z-machine] V3+ text shift codes
In-Reply-To: <344297e4a%kbracey@kbracey.cam.pace.co.uk> from Kevin Bracey at
 "May 21, 2001 02:52:51 pm"
To: h0142kdd@rz.hu-berlin.de
Date: Tue, 22 May 2001 09:55:15 +0200 (MET DST)
CC: z-machine@gmd.de
From: h0142kdd@rz.hu-berlin.de (Paul David Doherty)
X-PGP-Fingerprint: 0A 4B D3 B9 30 67 65 BE  35 D3 1C 8D 06 74 05 A5
X-URL: http://www2.rz.hu-berlin.de/angl/people/pdd/
Organization: Nope.
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


> > Can you put a test file somewhere which demonstrates this behavior?  (I
> > could write one myself but I'm lazy)
> 
> Attached are the source and executable for a test program.

To add more datapoints:

The Amiga interpreters (version 5a, 5b) display "HELLO World", just
like the IBM interpreters (5c, 5j). However, the C64 interpreter
(5j) displays "hello w!rld", which is closer to what the spec says
(though note that hello is not capitalized).

Seems like not even Infocom's original interpreters agree on how
to interpret this.

-- Dave


From ???@??? Wed May 23 22:00:05 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 22 May 2001 12:49:38 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re:  [z-machine] V3+ text shift codes
Message-ID: <5392a17e4a%kbracey@kbracey.cam.pace.co.uk>
In-Reply-To: <3B097401.99D797AA@gnelson.demon.co.uk>
X-Organization: Pace Micro Technology plc, Cambridge, United Kingdom
X-Mailer: Messenger v1.40f for RISC OS
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.61b
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <3B097401.99D797AA@gnelson.demon.co.uk>
          Graham Nelson <graham@gnelson.demon.co.uk> wrote:

> I'd vote against actually changing the specification, unless it can be
> shown to be erroneously interpreting an Infocom story file.
> 

Well, that's the open challenge, if anyone wants to take it up. Do any
Infocom V3+ story files use shift lock?

I've scanned my (limited) collection using a tweaked version of TXD, which
only showed up shift lock use in V1 and V2 versions of Zork I, and some false
alarms in Journey (where TXD incorrectly thought some routine parameters were
strings).

Oh, and for what it's worth, my IBM Infocom interpreters that understand
shift lock don't use it when performing ENCODE_TEXT.

Personally, I'd be in favour of changing the specification, as that behaviour
appears to be consistent on all Infocom's later interpreters, and is
correctly handled by ITF. It would be a shame to decree that ITF's behaviour
is "wrong". You'd certainly need a paragraph making clear that shift lock
should not be used, due to it leading to incompatibilities with old Infocom
and pre Z-spec 1.x interpreters.

Can we find a version beyond which all Infocom interpreters handle it
properly? At a guess, I suspect all V4+ ones do.

(PS Graham - did you get the e-mail I sent you the other day?)

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Wed May 23 22:00:12 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <3B0B414B.9BAF0FB2@cisco.com>
Date: Wed, 23 May 2001 14:49:15 +1000
From: David Beazley <dbeazley@cisco.com>
Organization: Cisco Systems  <http://www.cisco.com/au>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: z-machine@gmd.de
CC: George Janczuk <g.janczuk@oopl.com.au>
Subject: Re: [z-machine] V3+ text shift codes
References: <5392a17e4a%kbracey@kbracey.cam.pace.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-z-machine@gmd.de
Precedence: bulk


If you define what the original Infocom interpreters did
as being the "correct" implemenatation, then I'd have to
say that the behaviour you described in your initial email
is the correct behaviour. That is:

Current alphabet      Code 4           Code 5
--------------------------------------------------
       A0             Shift to A1      Shift to A2
       A1             Lock to A1       Lock to A0
       A2             Lock to A0       Lock to A2

When doing the ITF interpreter, we looked at the
behaviour of several different Infocom interpreters
(from memory, the ones for the MAC, Amiga, PC and
Apple2). As far as I am aware, the MAC, Amiga and
PC interpreters all behaved as described above
which is why the ITF interpreter followed suit.
For those interested, the ITF code fragment we
are talking about is:

        if (( ch == 4 ) || ( ch == 5 ))
        {
                /*
                **      Switch printing modes
                */
 
                if ( single_mode == 0 )
                        single_mode = ch - 3 ;
                else
                {
                        if ( single_mode != ch - 3 )
                                single_mode = 0 ;
                        print_mode = single_mode ;
                }
                return ;
        }

where "single_mode" does a temporary shift for the
next char only, and "print_mode" is used to lock the
mode for all subsequent chars.

So my (biased) view is that this is correct behaviour.

On the question of whether the spec. should change, I
personally have no real opinion. As someone has pointed
out, if there is no gamefile which makes use of this
behaviour then it is sort of a moot point. What I do think
is that the spec. should at least document the behavioural
differences between the Infocom interpreters on this point.

My $0.02 FWIW.

Rgds,

David.


Kevin Bracey wrote:
> 
> In message <3B097401.99D797AA@gnelson.demon.co.uk>
>           Graham Nelson <graham@gnelson.demon.co.uk> wrote:
> 
> > I'd vote against actually changing the specification, unless it can be
> > shown to be erroneously interpreting an Infocom story file.
> >
> 
> Well, that's the open challenge, if anyone wants to take it up. Do any
> Infocom V3+ story files use shift lock?
> 
> I've scanned my (limited) collection using a tweaked version of TXD, which
> only showed up shift lock use in V1 and V2 versions of Zork I, and some false
> alarms in Journey (where TXD incorrectly thought some routine parameters were
> strings).
> 
> Oh, and for what it's worth, my IBM Infocom interpreters that understand
> shift lock don't use it when performing ENCODE_TEXT.
> 
> Personally, I'd be in favour of changing the specification, as that behaviour
> appears to be consistent on all Infocom's later interpreters, and is
> correctly handled by ITF. It would be a shame to decree that ITF's behaviour
> is "wrong". You'd certainly need a paragraph making clear that shift lock
> should not be used, due to it leading to incompatibilities with old Infocom
> and pre Z-spec 1.x interpreters.
> 
> Can we find a version beyond which all Infocom interpreters handle it
> properly? At a guess, I suspect all V4+ ones do.
> 
> (PS Graham - did you get the e-mail I sent you the other day?)
> 
> --
> Kevin Bracey, Principal Software Engineer
> Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
> 645 Newmarket Road                            Fax: +44 (0) 1223 518526
> Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/

-- 
David Beazley                        email:dbeazley@cisco.com
Software Engineer                    email:dbeazley@acm.org
Cisco Systems                        Phone: +61 2 8446-6667
Level 3, The Forum                   FAX:   +61 2 8446-8496
201 Pacific Highway
St. Leonards, NSW, 2065
AUSTRALIA


From ???@??? Thu May 24 00:43:50 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 23 May 2001 08:38:37 -0400 (EDT)
From: "Matthew T. Russotto" <russotto@pond.com>
Message-Id: <200105231238.IAA28739@pond.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] V3+ text shift codes
Sender: owner-z-machine@gmd.de
Precedence: bulk


All the Mac interpreters from Lost Treasures print
HELLO World on the test program.  I haven't checked the Apple II interpreters
yet.


From ???@??? Fri Jul 20 11:50:13 2001
Return-Path: <z-machine-owner@mail.gmd.de>
Message-ID: <20010715012508.98018.qmail@mta512.mail.yahoo.com>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.4]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
Subject: [z-machine] Sound
Date: Sun, 15 Jul 2001 02:16:36 +0100
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 15 Jul 2001 01:14:21.0250 (UTC) FILETIME=[7A47BA20:01C10CCB]
Sender: owner-z-machine@gmd.de
Precedence: bulk


 I'm willing to accept Graham's hack that sampled sound can overlay
 music, and music is interrupted only by other music... on the condition
 that we get back to this later.

 Andrew Plotkin  22 September 1997
------


Four years later may be a bit *too* late, but I want to get back to it.

The Blorb specification currently states:
There is also the question of overlapping sounds. The Z-Spec (9.4.2) says
that
starting a new sound effect automatically stops any current one. But it is
not
desirable that a sound effect such as footsteps should interrupt the playing
of
background music. Therefore, the interpreter should amend this rule, and
consider sampled sounds and music to be in separate "channels". Samples
interrupt samples, and music interrupts music, but one form of sound does
not
interrupt the other.

This is basically a quick and ugly hack of the way the Z-Spec says sounds
should work, in order to make sound effects overlay background music. What's
more, it is 'an actual variance in the behavior of the Z-machine'. As things
stand, any interpreter which fully implements the Blorb spec must not
implement the Z-Spec properly. It's only a small change, but it's been
bothering
me for months.

It's bothering me more now, because I'm writing a Z-Machine interpreter,
which
will hopefully implement the Blorb spec. However, getting the sounds to work
will take an enormous amount of effort on my part, due to the fact that I
don't
have the first clue how to do it. I am unhappy with the prospect of spending
so
much effort implementing something which I dislike so very much, but I would
like to make my terp support sounds in some way.

What I am proposing, therefore, is an amendment to the Z-Spec, to improve
sound support. I have a few ideas, which I'm not certain about, but which I
think would be nice.

I'd like some new flags somewhere, perhaps in Flags 2 or in the header
extension. There is already a bit which the terp can use to inform the game
if it supports sound, but that is just sound in general. With the Blorb
spec,
it is conceivable that a terp writer may be able to play AIFF files, but not
MOD files, for some reason. Therefore two flags, one to specify if music is
available, and one to specify if sound effects are available, would be
useful.

A new opcode to set the current sound channel would allow old Infocom
games to content to work, but allow newer game to neatly play sounds over
other sounds. I'm not certain about the number of channels that should
exist.

Another opcode, nothing to do with overlapping sounds, but one that I would
find very useful, would allow the game writer to check if a certain sound
was
available. If the terp could not find the sound, or decided it could not
understand the format, this would allow the game writer to discover this,
and make other arrangements.

That's it, as far as my ideas have gone. Comments and criticism would be
appreciated.

--
Fillmore


From ???@??? Fri Jul 20 12:18:38 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp2.ihug.co.nz: Host p164-tnt7.akl.ihug.co.nz [203.173.206.164] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20010720115753.00a1e090@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 20 Jul 2001 12:08:55 +1200
To: z-machine@gmd.de
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Sound
In-Reply-To: <20010715012508.98018.qmail@mta512.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 02:16 15/07/01 +0100, Fillmore wrote:
 >
 >I'd like some new flags somewhere, perhaps in Flags 2 or in the
 >header extension. There is already a bit which the terp can use
 >to inform the game if it supports sound, but that is just sound
 >in general. With the Blorb spec, it is conceivable that a terp
 >writer may be able to play AIFF files, but not MOD files, for
 >some reason. Therefore two flags, one to specify if music is
 >available, and one to specify if sound effects are available,
 >would be useful.
[...]
 >I'm not certain about the number of channels that should exist.

Since you're proposing a header extension anyway, why not take 
that one step further?  Instead of having simple bitflags 
indicating whether sound and/or music is available (in addition to 
the standard "supports sound" flag), have two bytes in the header 
extension.  One contains the number of channels of sound (effects, 
voice, etc) supported by the interpreter, the other contains the 
number of channels of music supported by the terp.

If you're feeling stingy, we could allocate only a single byte for 
both, storing the sound in the low nybble and the music in the 
high nybble or something, since it's unlikely you'd get more than 
15 channels for either.

That way, the story file can set the appropriate values to let the 
terp know how many channels of each it would *like* (allowing the 
terp to save memory if the story doesn't need as many channels as 
it can create).  The terp then sets those values to the lesser of 
what the story file wants and what the terp can actually provide, 
providing a nice and simple negotiation.  Zero channels, of 
course, means that either the terp can't provide music (for 
example) or that the story won't be using it.

Of course there should be a recommended number of channels for 
each group to act as a guide to terp and story writers.  Three 
channels for sound and one for music seems like a reasonable limit 
to me....

Does this sound workable?
-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
It is impossible to make anything foolproof because fools are so 
ingenious.


</x-flowed>
From ???@??? Wed Aug 01 09:46:54 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.4]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <5.1.0.14.0.20010720115753.00a1e090@pop.ihug.co.nz>
Subject: Re: [z-machine] Sound
Date: Sun, 29 Jul 2001 00:32:43 +0100
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID: <OE27CBcKfExvWvqzAoa00005307@hotmail.com>
X-OriginalArrivalTime: 28 Jul 2001 23:30:07.0625 (UTC) FILETIME=[3C9CC790:01C117BD]
Sender: owner-z-machine@gmd.de
Precedence: bulk


Gavin Lambert wrote:
> Since you're proposing a header extension anyway, why not take
> that one step further?  Instead of having simple bitflags
> indicating whether sound and/or music is available (in addition to
> the standard "supports sound" flag), have two bytes in the header
> extension.  One contains the number of channels of sound (effects,
> voice, etc) supported by the interpreter, the other contains the
> number of channels of music supported by the terp.
> 
> If you're feeling stingy, we could allocate only a single byte for
> both, storing the sound in the low nybble and the music in the
> high nybble or something, since it's unlikely you'd get more than
> 15 channels for either.
> 
> That way, the story file can set the appropriate values to let the
> terp know how many channels of each it would *like* (allowing the
> terp to save memory if the story doesn't need as many channels as
> it can create).  The terp then sets those values to the lesser of
> what the story file wants and what the terp can actually provide,
> providing a nice and simple negotiation.  Zero channels, of
> course, means that either the terp can't provide music (for
> example) or that the story won't be using it.
> 
> Of course there should be a recommended number of channels for
> each group to act as a guide to terp and story writers.  Three
> channels for sound and one for music seems like a reasonable limit
> to me....
> 
> Does this sound workable?

It's an interesting idea, and it looked good at first, but I thought 
about it for a while, and I think it's a better idea to have a precise 
number of channels, say, four. This way a game writer knows for certain 
what will be available. That is, the interpreter either supports no sound 
or four channels. This makes it easier for a game writer to know if the 
effect he wants will be possible.

If we're going to talk about upgrading the Z-Machine (and I'm not sure
we are, but I hope other people will join in on the discussion), there
are probably areas other than sound that should be addressed. File
handling is the only one that leaps to mind at the moment, but proper
file handling, where the interpreter can prompt the user for the name
of a file, or access files silently, depending on what the game wants,
would be amazingly useful.

Anyone else got ideas? Comments? Please?

--
Fillmore



From ???@??? Wed Aug 01 10:31:32 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp4.ihug.co.nz: Host p118-tnt7.akl.ihug.co.nz [203.173.206.118] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20010801100029.00aa8d50@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 Aug 2001 10:12:12 +1200
To: "z-machine mailing list" <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Sound
In-Reply-To: <OE27CBcKfExvWvqzAoa00005307@hotmail.com>
References: <5.1.0.14.0.20010720115753.00a1e090@pop.ihug.co.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 00:32 29/07/01 +0100, Fillmore wrote:
 >
 >It's an interesting idea, and it looked good at first, but I
 >thought about it for a while, and I think it's a better idea
 >to have a precise number of channels, say, four. This way a
 >game writer knows for certain what will be available. That
 >is, the interpreter either supports no sound or four channels.
 >This makes it easier for a game writer to know if the effect
 >he wants will be possible.

I agree in part; I think that there should be a MINIMUM limit, so 
for example the terp either doesn't support sound at all or 
provides AT LEAST x channels (x to be decided in the next 
Spec).  Say we standardise on three channels of sound and one of 
music, as I suggested; thus any terp supporting both sound and 
music will provide those four channels at a bare minimum.  So 
story writers can rest assured that if the terp supports sound 
they have those three channels to work with.

But I'm also thinking for future expansion - it may be that some 
time down the track three-channel sound may be insufficient, and 
story writers will need to use more channels.  By storing the 
number of supported channels as I suggested and allowing the terp 
to provide additional channels if requested to (and supported), 
story writers can make the most of it.  If the extra channels they 
want are available, they can use them.  If not, they can fall back 
to the three-channel system (or, for example, perhaps they want 8 
channels but only five are available - they can use those five or 
just fall back to using only three, as before).

I don't think we should fall into the trap of using boolean flags 
for this, since it complicates any future expansion.  Imagine, if 
you will, a story or terp writer puzzling that through: "Let's 
see, if this bit is set, then some kind of sound is supported.  If 
THAT other bit is set, then we've got three channels 
available.  And if that one other there is set, then we've got six 
channels.  And THAT one means twelve channels..."
-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
Cats took many thousands of years to domesticate humans.


</x-flowed>
From ???@??? Sat Aug 04 12:57:09 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <20010801032319.11807.qmail@web5502.mail.yahoo.com>
Date: Tue, 31 Jul 2001 20:23:19 -0700 (PDT)
From: Mog the Moogle <bokochocobo@yahoo.com>
Subject: [z-machine] Looking at sound in detail
To: z-machine@gmd.de
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


I was wondering if someone could give me a detailed
breakdown of how all aspects of sound work with the
z-machine.  Forgive me if this is on any Standards
documents, or if I sent this the wrong way, for I just
recently signed up.

-regards, mogg

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From ???@??? Wed Aug 15 15:51:30 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-Id: <200108120013.CAA28030@mail.gmd.de>
Date: Sun, 12 Aug 2001 02:09:37 +0200
From: "Fredrik Ramsberg" <fredrik@cambrianlabs.com>
To: z-machine@gmd.de
Subject: [z-machine] A little help with the z-machine standard please?
X-Mailer: WorldClient Pro 2.2.3
Sender: owner-z-machine@gmd.de
Precedence: bulk


If an opcode has form="variable" and operand count="2OP", can I
(as an interpreter writer) be sure that the bottom four bits of the
operand type byte will be "1111" (meaning that operand 3 and 4 are
omitted)? That would simplify instrucion decoding a bit.

/Fredrik


From ???@??? Thu Sep 06 09:59:43 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Sent: 24 Aug 2001 21:36:15 GMT
Message-ID: <000701c12ce5$122bae30$802d98ce@ccurrie>
From: "Christopher Currie" <christopher@Currie.com>
To: <z-machine@gmd.de>
Subject: [z-machine] string processing
Date: Fri, 24 Aug 2001 17:38:09 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2479.0006
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
Sender: owner-z-machine@gmd.de
Precedence: bulk


There was a thread a month or so ago about a proposed "correction" to the
zspec dealing with how zstrings are encoded. Does anyone have an archive of
that thread I can read through? What was the eventual result?

Thanks,
Christopher Currie


From ???@??? Thu Sep 06 10:23:31 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 28 Aug 2001 13:27:46 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] string processing
Message-ID: <edfb1cb14a%kbracey@kbracey.cam.pace.co.uk>
In-Reply-To: <000701c12ce5$122bae30$802d98ce@ccurrie>
X-Organization: Pace Micro Technology plc, Cambridge, United Kingdom
X-Mailer: Messenger v1.40f for RISC OS
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.61b
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <000701c12ce5$122bae30$802d98ce@ccurrie>
          "Christopher Currie" <christopher@Currie.com> wrote:

> There was a thread a month or so ago about a proposed "correction" to the
> zspec dealing with how zstrings are encoded. Does anyone have an archive of
> that thread I can read through? What was the eventual result?

Not sure whether this list is archived, but the general upshot was that
most of Infocom's interpreters do provide alphabet lock functionality by
repeated shift characters, but Infocom never made use of the facility, and
most current interpreters (except ITF-derived ones) don't do it, so the
Z-spec is going to remain unchanged to prevent confusion.

I advocated putting some sort of note in the spec to avoid repeated shift
characters (apart from dictionary padding) to make clear that this is a
grey area.

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Thu Sep 06 10:23:32 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Sent: 28 Aug 2001 16:51:55 GMT
Message-ID: <002201c12fe2$09948fd0$9771729e@ccurrie>
From: "Christopher Currie" <christopher@Currie.com>
To: <z-machine@gmd.de>
Subject: Fw: [z-machine] string processing
Date: Tue, 28 Aug 2001 12:53:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2479.0006
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
Sender: owner-z-machine@gmd.de
Precedence: bulk


From: "Kevin Bracey" <kevin.bracey@pace.co.uk>

> Not sure whether this list is archived, but the general upshot was that
> most of Infocom's interpreters do provide alphabet lock functionality by
> repeated shift characters, but Infocom never made use of the facility, and
> most current interpreters (except ITF-derived ones) don't do it, so the
> Z-spec is going to remain unchanged to prevent confusion.
>
> I advocated putting some sort of note in the spec to avoid repeated shift
> characters (apart from dictionary padding) to make clear that this is a
> grey area.

I was unable to find an archive for the list, and I'm interested in the
details, if anyone has them. Would an interpreter be considered
non-compliant to the spec if it implemented the alpha-lock facility? If I
understand you, implementing it would not break any current or historic
story files...

Christopher


From ???@??? Thu Sep 06 10:24:15 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 29 Aug 2001 13:17:16 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: Fw: [z-machine] string processing
Message-ID: <c1db9fb14a%kbracey@kbracey.cam.pace.co.uk>
In-Reply-To: <002201c12fe2$09948fd0$9771729e@ccurrie>
X-Organization: Pace Micro Technology plc, Cambridge, United Kingdom
X-Mailer: Messenger v1.40f for RISC OS
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Posting-Agent: RISC OS Newsbase 0.61b
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <002201c12fe2$09948fd0$9771729e@ccurrie>
          "Christopher Currie" <christopher@Currie.com> wrote:

> I was unable to find an archive for the list, and I'm interested in the
> details, if anyone has them.

The state machine looks like:

Current alphabet      Code 4           Code 5
--------------------------------------------------
       A0             Shift to A1      Shift to A2
       A1             Lock to A1       Lock to A0
       A2             Lock to A0       Lock to A2

Thus two code 4s in a row will lock you to upper case, and a code 5 will
put you back. The encode_text opcode must not use the locks.

> Would an interpreter be considered
> non-compliant to the spec if it implemented the alpha-lock facility?

Technically, yes. Not that it's stopped me implementing it in the latest
Zip 2000.

> If I
> understand you, implementing it would not break any current or historic
> story files...

No, it wouldn't. Inform has never used the facility, and no-one has found
an Infocom file that used it.

Here's the source for a test program:

-----cut-----
! This array is the sequence of Z-characters:
!
!       4 4 13  10 17 17  20 0 28  5 20 23  17 9 5
!
! which according to the Z-specification outputs "Hello w!rld",
! but on Infocom's interpreters outputs "HELLO World".

Array text --> $108D $2A31 $501C $1697 $C525;

[ Main x;
  print (address) text;
  @read_char 1 -> x;
  quit;
];
-----cut-----

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Fri Nov 02 15:17:26 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 01 Nov 2001 16:13:23 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Message-ID: <dff9aad24a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] Blorb extensions for Infocom V6 games
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


On RAIF I've been posting some proposals for Blorb extensions to handle the
graphics of the four Infocom V6 games, but I've had little to no feedback.
Even Zarf won't talk to me :(

The aim is to make it possible to convert the Infocom graphics to Blorb
without any loss of functionality. That way interpreters only need to handle
Blorb with some minor extensions, rather than having to cope with two totally
different resource formats.

Conversion of the TLH and Sherlock sounds to Blorb was straightforward, and
these have been uploaded to the IF Archive. The only remaining issue is the
correct frequency for one of the TLH sounds.

For the graphics, I've been working on the basis that the optimal versions
are the MG1 files in the IF Archive. If anyone knows any better, speak up
now.

The MG1 graphics are designed for a 320x200 resolution screen, and use a
maximum of 14 colours per image. An extra transparent colour is also
supported. The games will scale themselves to different resolutions
(in particular Zip 2000 normally runs in a 640x400 Z-pixel display).

There are three peculiar features to the MG1 graphics.

    1) Images with zero height and/or width (in Zork Zero and Arthur)
    2) Images with no palette (in Zork Zero and Arthur)
    3) Images with no data (in Zork Zero, Shogun, and Arthur)

The first two cannot represented in Blorb 1.1, as PNGs must have both width
and height >= 1, and PNGs must have a palette. Item 3 can be dealt with
(inefficiently) by having a totally transparent PNG.

My proposal is to add two extensions to Blorb. Support for these extensions
by interpreters would be optional, and their use would only be permitted in
conversions of the Infocom graphics. I think rectangles are a good idea, in
the sense that they provide a mechanism for the Blorb file to describe the
screen layout, but they're not worth the compatibility grief of allowing new
programs to use them.


* Rectangles

A third format of picture is a rectangle. A rectangle has only size, but no
contents. A rectangle exists for the purposes of @picture_data, and
@erase_picture, but its use in @draw_picture or @picture_table is an error
[ note - I need to check this for certain; possibly they should be ignored ].

A rectangle is described by a "Rect" chunk:

      4 bytes   "Rect"    chunk ID
      4 bytes   8         chunk size
      4 bytes   px        picture width
      4 bytes   py        picture width

Rectangles are used by Zork Zero, Shogun and Arthur.


* The Adaptive Palette Chunk

This chunk contains a list of pictures that change their colours according to
the pictures plotted before - these will be known as adaptive-palette
pictures.

        4 bytes       'APal'       chunk ID
        4 bytes       num*4        chunk length
        num*4 bytes   ...          adaptive palette entries
        
Each entry is 4 bytes, of the form:

        4 bytes       number       picture resource number

This chunk exists only to produce conversions of the Infocom graphics used in
Zork Zero and Arthur. It must not be used for new programs. If you require
multiple coloured forms of images, you must include them as separate images.
With PNG it may also be possible to use alpha compositing to achieve the
desired effect.

If this chunk is present:

   * All pictures in the Blorb file will be PNGs or Rects.
   * All PNGs will be indexed-colour (colour type 3).
   * All PNGs will use only colour indices 2-15.
   * All PNGs will have no more than 16 entries in their PLTE chunk.
   * PNGs may have a tRNS chunk marking colour 0 only as fully transparent,
     in which case colour index 0 may also be used. No other forms of the
     tRNS chunk are valid.

However, the following rules still apply from the PNG standard:

   * Any bit depth of PNG is valid (1,2,4 or 8 bits per pixel).
   * The PLTE chunk is required by the PNG standard, and it must have
     sufficient entries to cover every colour used in the PNG, even in
     adaptive-palette pictures.
   * The PLTE chunk may not have more entries than can be represented
     by the PNG's bit depth.
   * The PNGs may have gAMA, cHRM and sRGB or iCCP chunks describing the
     colour space. Interpreters should make every effort to support at least
     gAMA. For the Infocom graphics at least, cHRM, sRGB and iCCP are
     probably beyond the call of duty.
     
The interpreter should keep track of the "Current Palette". This will be a
14-entry table, covering colour indices 2-16. For ease of implementation,
this will probably be a 16-entry table, whose first two entries are not
significant.

Whenever a picture *not* listed in the APal chunk is plotted, its palette (as
derived from its PLTE, gAMA, cHRM and sRGB/iCCP chunks) should be copied into
the Current Palette. If its palette has fewer than 16 entries, then only
those entries of the Current Palette are changed. (Possible interpreter
implementation: transform the PNG's PLTE chunk according to the gAMA, cHRM,
sRGB chunks, then copy it into your Current Palette which is always in the
screen colour-space. With libpng, use png_get_PLTE, after calling
png_update_info).

Whenever a picture listed in the APal chunk is plotted, its palette should be
ignored, and it should be plotted with the Current Palette. (Possible
interpreter implementation: strip out the PLTE, gAMA, cHRM and sRGB/iCCP
chunks from the PNG, and insert the Current Palette as its PLTE. Or with
libpng, use png_set_PLTE before reading the data).

Behaviour is undefined if any adaptive-palette pictures are plotted before
a non-adaptive picture has been plotted.

Alternatively, for the full retro-gaming experience, use a 16-colour screen
mode. Copy non-adaptive pictures' palette (apart from the first two entries)
into the screen palette when plotted. Use colour indices 0 and 1 for the
window background and text respectively. This mimics the IBM MGA and Amiga
display, where drawing a picture can change the colours of graphics already
on the screen, but it is not the preferred rendering.

Shogun and Journey do not use any adaptive-palette images, but on some
platforms the effect of pictures already on the screen changing colour is
visible. To give an interpreter the ability to do this if desired, and to
signal that optimisations may be possible because of the limited nature of
the graphics, the Blorb files for Shogun and Journey contain an empty APal
chunk.


-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Fri Nov 02 15:17:27 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 01 Nov 2001 16:42:56 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Message-ID: <61aeadd24a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] SNam chunk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id RAA04471
Sender: owner-z-machine@gmd.de
Precedence: bulk


I'm sure we discussed and agreed this a while back, but I can find no records
(is there an archive of this list?). Zip 2000 has implemented it for some
time. I want to put some SNam chunks into my Blorb versions of the Infocom
graphics and sounds, so I'd like the documentation added to the appropriate
specs.


* Story name chunk

Blorb and Quetzal files may contain a 'SNam' chunk, giving the name of the
story file. In a Blorb file, it contains the name of the embedded or
associated executable. In a Quetzal file, it contains the name of the game
that saved it - either copied from its Blorb SNam chunk or generated by some
other means.

The name should be human readable, and contain no control characters
(including line feeds). It should be suitable for placing in the title bar of
a window. Examples are:

      Beyond Zork: The Coconut of Quendor
      Curses
      Moments out of time
      Zork I: Das Große Unterweltreich

The chunk format is:
      
      4 bytes     "SNam"    chunk ID
      4 bytes     2*num     chunk size
      2*num bytes ...       story name

The story name is stored as big-endian UTF-16 Unicode. All Standard 1.0
Z-code interpreters should be able to map Unicode to their native character
set. At a minimum, an ASCII conversion routine is:

      uint16_t *snam;
      char *ascii;
      
      for (i=0; i<num; i++)
          ascii[i] = snam[i] < 0x80 ? snam[i] : '?';

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Tue Nov 06 11:36:20 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 05 Nov 2001 10:49:34 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Blorb extensions for Infocom V6 games
Message-ID: <41ac9cd44a.kbracey@kbracey.cam.pace.co.uk>
References: <dff9aad24a.kbracey@kbracey.cam.pace.co.uk>
In-Reply-To: <dff9aad24a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <dff9aad24a.kbracey@kbracey.cam.pace.co.uk>
          Kevin Bracey <kevin.bracey@pace.co.uk> wrote:

> On RAIF I've been posting some proposals for Blorb extensions to handle the
> graphics of the four Infocom V6 games, but I've had little to no feedback.

Hmm, the silence here is deafening too. Has everyone lost interest and
wandered off? Am I the only person using it? Has even Zarf abandoned Blorb?
He hasn't responded to any of my questions or suggestions - maybe his e-mail
is still playing up.

I think I'll just release Zip 2000 as it is, and post the converted
graphics, together with the specification for the SNam, Rect and APal
extensions, to the IF Archive. I've had some helpful feedback on the Infocom
originals, but no-one seems interested in Blorb (apart from requests to add
MPEG video and audio).

Looking at other interpreters, Blorb support seems to be very patchy, so it
may be that to most people Blorb is still some kind of mythical beast.

But I've got an interpreter that can now play Blorb forms of the 6 original
multimedia Infocom games far better than Infocom's own interpreters ever
could, so I very definitely want to be able to strip out my MG1 support.

I've resurrected the Zip 2000 home page. See:

      http://www.bracey-griffith.freeserve.co.uk/Zip2000/

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Tue Nov 06 11:36:22 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 05 Nov 2001 12:05:18 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Blorb extensions for Infocom V6 games
Message-ID: <469ba3d44a.kbracey@kbracey.cam.pace.co.uk>
References: <200111051144.fA5BilN27647@chmls05.mediaone.net>
In-Reply-To: <200111051144.fA5BilN27647@chmls05.mediaone.net>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <200111051144.fA5BilN27647@chmls05.mediaone.net>
          Jason C Penney <jpenney@jczorkmid.net> wrote:

> > A rectangle is described by a "Rect" chunk:
> > 
> >       4 bytes   "Rect"    chunk ID
> >       4 bytes   8         chunk size
> >       4 bytes   px        picture width
> >       4 bytes   py        picture width
> > 
> > Rectangles are used by Zork Zero, Shogun and Arthur.
> 
> I realize that it's inefficient but since it's just for these three 
> games, wouldn't it be easier for other interpreter writers to actually 
> create the blank png files?  Then we're down to just one extension to 
> handle the graphics.

The main issue with the rectangles is actually that some are zero width or
height. That isn't legal in a PNG, and the reference PNG library (libpng)
will fault them. Now, we could create illegal PNGs - zero width or height
with no IDAT chunk, in much the same way as I originally suggested PNGs with
no PLTE. In the context of a larger enclosing format such things are
tolerated (eg PNGs with no PLTE in a MNG datastream). The interpreter could
detect such PNGs and just not pass them to the library - a Blorb interpreter
will almost certainly be inspecting the IHDR directly anyway to get the
picture size; mine certainly does.

Zarf didn't seem keen on PLTE-less PNGs, so I shied away from other PNG
perversions. But in Zip 2000 at least, doing that would be no more complex.
But I would want consistency between the two extensions - either we use bend
the PNGs for both or we add extra chunks for both. It makes no sense to only
allow one of them to bend the PNG format.

I'm pretty certain that the zero width/height is a requirement to get the
layout right. I might be wrong though - it may be that the games only looks
at the other dimension.

Once the Rect exists, you might as well use it for other no-data images in
the same file. One of the games doesn't have zero-height or width images
(I can't remember which one) - it may be that that one should have blank PNGs
instead. But whichever one it was still needed the APal chunk.

> The rest of the proposal looks really good to me.  It'll be great to 
> have the four infocom games finally converted to blorb.

They look excellent on Zip 2000. I've made the PNGs have a file gamma of
1/1.8 rather than the standard 1/2.2, which makes them look a lot better.
Both the Mac and Amiga have a different video system gamma response to the
PC and Archimedes, and it seems that the graphics were originally designed
with that in mind. It wasn't compensated for in the PC conversion.

And because the graphics are now going through my better PNG handling code,
they can get full Floyd-Steinberg dithering in low colour modes, which rocks.
Goes a bit weird in Zork Zero though, as when it samples the background
colour of the status bar, it ends up choosing one of the dither colours at
random, and using that as the text background. That's why the dithering is an
option...

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Tue Nov 06 11:36:23 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Mon, 5 Nov 2001 07:19:07 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Blorb extensions for Infocom V6 games
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3BE63D6B.20365.271AEB6@localhost>
In-reply-to: <469ba3d44a.kbracey@kbracey.cam.pace.co.uk>
References: <200111051144.fA5BilN27647@chmls05.mediaone.net>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Kevin Bracey sent a message across the ether on 5 Nov 2001 (12:05) 
stating:

> In message <200111051144.fA5BilN27647@chmls05.mediaone.net>
>           Jason C Penney <jpenney@jczorkmid.net> wrote:
> 
> > > A rectangle is described by a "Rect" chunk:
> > > 
> > >       4 bytes   "Rect"    chunk ID
> > >       4 bytes   8         chunk size
> > >       4 bytes   px        picture width
> > >       4 bytes   py        picture width
> > > 
> > > Rectangles are used by Zork Zero, Shogun and Arthur.
> > 
> > I realize that it's inefficient but since it's just for these three
> > games, wouldn't it be easier for other interpreter writers to
> > actually create the blank png files?  Then we're down to just one
> > extension to handle the graphics.
> 
> The main issue with the rectangles is actually that some are zero
> width or height. That isn't legal in a PNG, and the reference PNG
> library (libpng) will fault them. Now, we could create illegal PNGs -
> zero width or height with no IDAT chunk, in much the same way as I
> originally suggested PNGs with no PLTE. In the context of a larger
> enclosing format such things are tolerated (eg PNGs with no PLTE in a
> MNG datastream). The interpreter could detect such PNGs and just not
> pass them to the library - a Blorb interpreter will almost certainly
> be inspecting the IHDR directly anyway to get the picture size; mine
> certainly does.
> 
> Zarf didn't seem keen on PLTE-less PNGs, so I shied away from other
> PNG perversions. But in Zip 2000 at least, doing that would be no more
> complex. But I would want consistency between the two extensions -
> either we use bend the PNGs for both or we add extra chunks for both.
> It makes no sense to only allow one of them to bend the PNG format.

You're right.  I misunderstood.  Is it legal to have a zero height/width 
JPEG?  If not then your proposed extension seems like the best idea.


> > The rest of the proposal looks really good to me.  It'll be great to
> > have the four infocom games finally converted to blorb.
> 
> They look excellent on Zip 2000. I've made the PNGs have a file gamma
> of 1/1.8 rather than the standard 1/2.2, which makes them look a lot
> better. Both the Mac and Amiga have a different video system gamma
> response to the PC and Archimedes, and it seems that the graphics were
> originally designed with that in mind. It wasn't compensated for in
> the PC conversion.
> 
> And because the graphics are now going through my better PNG handling
> code, they can get full Floyd-Steinberg dithering in low colour modes,
> which rocks. Goes a bit weird in Zork Zero though, as when it samples
> the background colour of the status bar, it ends up choosing one of
> the dither colours at random, and using that as the text background.
> That's why the dithering is an option...

Sounds great.  I've done quite a bit of work on V6Lib with Zip 2000 
lately.  If only I could get Red Squirrel to work in the high color 
modes.

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Tue Nov 06 11:36:25 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 05 Nov 2001 13:04:39 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Blorb extensions for Infocom V6 games
Message-ID: <740aa9d44a.kbracey@kbracey.cam.pace.co.uk>
References: <200111051144.fA5BilN27647@chmls05.mediaone.net> <3BE63D6B.20365.271AEB6@localhost>
In-Reply-To: <3BE63D6B.20365.271AEB6@localhost>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <3BE63D6B.20365.271AEB6@localhost>
          "Jason C Penney" <jpenney@jczorkmid.net> wrote:

> 
> You're right.  I misunderstood.  Is it legal to have a zero height/width 
> JPEG?  If not then your proposed extension seems like the best idea.

Blimey. Took me half an hour to find the answer to that question. JPEGs
can range from 1x1 to 65535x65535. Zero width and height not permitted.

> Sounds great.  I've done quite a bit of work on V6Lib with Zip 2000 
> lately.  If only I could get Red Squirrel to work in the high color 
> modes.

I'm impressed. It's actually good enough for people to bother to find a
RISC OS emulator to run it on! The upcoming Zip 2000 has a full-screen
mode - if you used that, together with some cunning scripting, you could
probably make it look seamlessly like a native interpreter :) Have you
contacted Red Squirrel's author? He could probably help you get the deep
modes working.

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Tue Nov 06 11:36:21 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-Id: <200111051144.fA5BilN27647@chmls05.mediaone.net>
X-cs: R
From: Jason C Penney <jpenney@jczorkmid.net>
X-RS-ID: <Default>
X-RS-Flags: 1,1,1,1,0,0,0
X-RS-Header: In-reply-to: <dff9aad24a.kbracey@kbracey.cam.pace.co.uk>
X-RS-Sigset: 6
To: Kevin Bracey <kevin.bracey@pace.co.uk>
Subject: Re: [z-machine] Blorb extensions for Infocom V6 games
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Comments: Confirmation of reading was requested.
Comments: Confirmation of delivery was requested.
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
Date: Mon, 5 Nov 2001 06:42:57 -0500
Sender: owner-z-machine@gmd.de
Precedence: bulk


Kevin Bracey sent a message across the ether on 1 Nov 2001 (16:13) stating:

> On RAIF I've been posting some proposals for Blorb extensions to
> handle the graphics of the four Infocom V6 games, but I've had little
> to no feedback. Even Zarf won't talk to me :(

Sorry I've been unable to reply until now. 
 

> There are three peculiar features to the MG1 graphics.
> 
>     1) Images with zero height and/or width (in Zork Zero and Arthur)
>     2) Images with no palette (in Zork Zero and Arthur) 3) Images with
>     no data (in Zork Zero, Shogun, and Arthur)
> 
> The first two cannot represented in Blorb 1.1, as PNGs must have both
> width and height >= 1, and PNGs must have a palette. Item 3 can be
> dealt with (inefficiently) by having a totally transparent PNG.
> 
> My proposal is to add two extensions to Blorb. Support for these
> extensions by interpreters would be optional, and their use would only
> be permitted in conversions of the Infocom graphics. I think
> rectangles are a good idea, in the sense that they provide a mechanism
> for the Blorb file to describe the screen layout, but they're not
> worth the compatibility grief of allowing new programs to use them.
> 
> 
> * Rectangles
> 
> A third format of picture is a rectangle. A rectangle has only size,
> but no contents. A rectangle exists for the purposes of @picture_data,
> and @erase_picture, but its use in @draw_picture or @picture_table is
> an error [ note - I need to check this for certain; possibly they
> should be ignored ].
> 
> A rectangle is described by a "Rect" chunk:
> 
>       4 bytes   "Rect"    chunk ID
>       4 bytes   8         chunk size
>       4 bytes   px        picture width
>       4 bytes   py        picture width
> 
> Rectangles are used by Zork Zero, Shogun and Arthur.

I realize that it's inefficient but since it's just for these three 
games, wouldn't it be easier for other interpreter writers to 
actually create the blank png files?  Then we're down to just one 
extension to handle the graphics.

The rest of the proposal looks really good to me.  It'll be great to 
have the four infocom games finally converted to blorb.

Jay


From ???@??? Fri Nov 09 12:35:22 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 07 Nov 2001 13:17:23 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
Message-ID: <afe0b1d54a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
To: z-machine@gmd.de
Subject: [z-machine] Some detailed Blorb queries
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


These are some queries on the Blorb spec and some comments on blorblib. I've
been unable to contact Zarf, so I thought I'd post them here to see if anyone
had any comments, at least about the spec bits.

1) Using blorblib, there's no easy way to find the type of a chunk that you
   load - is it AIFF, MOD or SONG? I'm having to access
   blorbmap->chunks[res.chunknum].type, which isn't a very high-level
   interface. I suggest adding the type to bb_result_t.
   
2) bb_load_resource_snd() has a typo - bb_ID_Pict instead of bb_ID_Snd.

3) I've only recently noticed that JPEGs have snuck their way into the
   standard. Fair enough, I suppose. Would it be possible to clamp down on
   JPEGs to ensure that they are baseline images? This is only recommended
   in the JFIF standard, but it would make my life a LOT easier (ie I can
   use an OS call to plot the JPEG, rather than including libjpeg).
   I can see no need for non-baseline images in a Blorb file. Progressive
   JPEGs in particular need a lot more RAM to process, where as normal ones
   can be plotted on the fly.

4) I note that AIFF's looping method is slightly different to a MOD's -
   might it be worth noting in the spec that when played as a SONG sample,
   the AIFF instrument will not sustain in the same fashion?

5) It isn't explicitly stated how blank samples in a SONG should be marked.
   I assume it should be a null sample name field. I will also treat as
   blank any sample whose name doesn't begin with "SND".

6) Does @sound_effect X 1 (prepare sound) stop the playback of any existing
   sound? On current versions of Zip 2000, it would, as only one sound can
   be loaded at once. Now I've added SONG support though, I can cache
   multiple samples at once. I would suggest that it be specified as
   "implementation-dependent" whether preparing a sound stops other
   sounds, and game authors be advised to not issue @sound_effect X 1 while
   a sound of the same type is playing. This is probably more for the Z-spec
   than the Blorb spec. Zip 2000 can only load one MOD/SONG at once though.
   
7) Likewise, it should be noted in the Blorb spec that @sound_effect X 3 or 4
   can be used with X ~= 0 to stop only one of the music or sound. This is
   sort of implied between the Z-spec and the Blorb spec, but it should be
   made explicit.

8) When an AIFF is used as a SONG sample, what should be done at the start
   of the sample? In a MOD, the sample's first two sample points are ignored
   and treated as zero. I can see three options:
   
       a) ignore the first two points of the AIFF and treat as zero,
       b) insert two zero points before the AIFF data, or
       c) play the AIFF data as is.

   I'm happy with any of those, but c) wouldn't be possible if you're
   converting it to a MOD. It does need to be standardised though.
   
9) I've written a mod2song tool to split a MOD into a SONG and multiple
   AIFFs. Once item 8 has been cleared up, I'll make it available.

10) I'm also putting together another test game ("The Sound of Music")
    to exercise MOD/SONG/AIFF functionality, based around Aunt Jemima's
    antique wireless. Others may find this useful.

11) Do you have any suggestion on how to handle non-mono AIFFs when placed
    in a SONG? My code currently always takes channel 1. Perhaps
    multi-channel AIFFs should be explicitly prohibited from use in SONGs.

12) What should the relative volume of samples and music be? I would suggest
    that a sample played on one channel of a SONG should be of
    equal volume to that sample played as an effect. This needs to be
    standardised - currently Moments Out Of Time defaults to music at volume
    1 and sound at volume 5. This apparently is because whichever interpreter
    the author is using plays music much louder than samples. But the
    music ends up far too quiet on Zip 2000.
    
13)  Similarly, I would suggest advising that the volume scale for the
    sound_effect opcode for AIFF and SONG should match that of the volume
    within SONG/MOD files (so a SONG played with @sound_effect volume 4
    containing samples at volume 64 sounds the same as a SONG played with
    @sound_effect volume 8 that contains volume 32 samples).
    
    This volume scale may or may not match Infocom's interpreters, but it
    doesn't seem that critical how it works in their games. Balance of
    sound and music in Blorb is critical though.
    
-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Fri Nov 09 12:35:41 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.13.162]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Some detailed Blorb queries
Date: Thu, 08 Nov 2001 02:26:35 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F102nvOYFgzdTn102er000222b4@hotmail.com>
X-OriginalArrivalTime: 08 Nov 2001 07:26:35.0982 (UTC) FILETIME=[B2BC5EE0:01C16826]
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
>1) Using blorblib, there's no easy way to find the type of a chunk that you
>    load - is it AIFF, MOD or SONG? I'm having to access
>    blorbmap->chunks[res.chunknum].type, which isn't a very high-level
>    interface. I suggest adding the type to bb_result_t.
>

Seconded. WHen I was writing GlkDOS, I noticed that I had to go to quite a 
bit of trouble to detect the sound type (which I had to do in order to 
initialize the right part of the audio system)

>3) I've only recently noticed that JPEGs have snuck their way into the
>    standard. Fair enough, I suppose. Would it be possible to clamp down on
>    JPEGs to ensure that they are baseline images? This is only recommended
>    in the JFIF standard, but it would make my life a LOT easier (ie I can
>    use an OS call to plot the JPEG, rather than including libjpeg).
>    I can see no need for non-baseline images in a Blorb file. Progressive
>    JPEGs in particular need a lot more RAM to process, where as normal 
>ones
>    can be plotted on the fly.

It would be nice. A big problem with this is that lots of tools will create 
progressive jpegs without the user beign aware of it (the option for it 
beign secreted away somewhere.) I've already had to help at least one user, 
who found his pictures not displaying (GlkDOS doesn't handle progressive 
jpeg either, I don't think winGLK did either at the time, and he didn't know 
that he was creating them)

>12) What should the relative volume of samples and music be? I would 
>suggest
>     that a sample played on one channel of a SONG should be of
>     equal volume to that sample played as an effect. This needs to be
>     standardised - currently Moments Out Of Time defaults to music at 
>volume
>     1 and sound at volume 5. This apparently is because whichever 
>interpreter
>     the author is using plays music much louder than samples. But the
>     music ends up far too quiet on Zip 2000.

There's other platformy ugliness assocated with volume; most of the 
windows/dos interpreters bash the system-wide sound settings, with the net 
result that after I start up nitfol, I find that the volume on the line-in 
channel has been muted (which is a real bear, since I have several computers 
chained together into one pair of speakers via the line-in jacks.)


An awful lot of your concerns refer to the SONG format. Of course, since 
SONG support is fairly limited (to Zip2000, iirc), and no one's liable to 
use it anyway (except to prove me wrong), I think you're going to find the 
concensus yours to make. (It's a pretty whack-ass format anyway)


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


</x-flowed>
From ???@??? Fri Nov 09 12:39:42 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 08 Nov 2001 10:08:39 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Some detailed Blorb queries
Message-ID: <5f6f24d64a.kbracey@kbracey.cam.pace.co.uk>
References: <F102nvOYFgzdTn102er000222b4@hotmail.com>
In-Reply-To: <F102nvOYFgzdTn102er000222b4@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <F102nvOYFgzdTn102er000222b4@hotmail.com>
          "L. Ross Raszewski" <rraszews@hotmail.com> wrote:

> 
> >3)  clamp down on
> >    JPEGs to ensure that they are baseline images?
> 
> It would be nice. A big problem with this is that lots of tools will create
> progressive jpegs without the user beign aware of it (the option for it 
> beign secreted away somewhere.) I've already had to help at least one user,
> who found his pictures not displaying (GlkDOS doesn't handle progressive 
> jpeg either, I don't think winGLK did either at the time, and he didn't
> know  that he was creating them)

That would suggest that there's a good degree of consensus that we
interpreter authors aren't going to stand for such nonsense :) Anyone want to
produce some "Progressive JPEGs, out, out, out!" placards?

> 
> There's other platformy ugliness assocated with volume; most of the 
> windows/dos interpreters bash the system-wide sound settings, with the net 
> result that after I start up nitfol, I find that the volume on the line-in 
> channel has been muted (which is a real bear, since I have several
> computers  chained together into one pair of speakers via the line-in
> jacks.)

Yuck. Nothing to do with Blorb fortunately. My interpreter does have to
mess with the sound settings a fair degree, but it doesn't alter any global
volume settings, and it puts things back when it's finished.

> An awful lot of your concerns refer to the SONG format. Of course, since 
> SONG support is fairly limited (to Zip2000, iirc), and no one's liable to 
> use it anyway (except to prove me wrong), I think you're going to find the 
> concensus yours to make. (It's a pretty whack-ass format anyway)

No, it applies equally to MOD. I was just using SONG as an example, as it's
one way you could get the same sample played as both music and effect. But
the same point applies if the same sample was embedded in the MOD. I'm
proposing:

     * full amplitude sine wave sample stored in AIFF played as an effect
       with volume 8,
     * full amplitude sine wave sample stored in AIFF played as part of
       a song with instrument volume 64, with the song played at volume 8,
     * and full amplitude sine wave sample in a MOD with instrument volume
       64 and the mod played at volume 8
       
should all sound the same. I'm then proposing that Z-code volume and MOD
volume be equivalent - ie reducing Z-code volume from 8 to 4 has the same
effect as reducing MOD instrument volume from 64 to 32.

This does have the corollary that MODs will generally sound "louder" as
they're using four channels compared to the effects' one. But it's an obvious
simplification, and if it's standardised, authors will be able to fine-tune
their volumes in confidence. Some systems (eg Amigas) will probably have to
actually nick one of the four music channels temporarily to play an effect,
in which case that volume behaviour will be the natural result.

My sound test game does use SONG, you'll be happy to hear :) I've written
a MOD->SONG converter to to encourage people to use it too...

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Sat Nov 10 12:17:57 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp1.ihug.co.nz: Host p703-apx1.akl.ihug.co.nz [203.173.194.195] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20011109140950.06fd57a0@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 09 Nov 2001 14:18:03 +1300
To: z-machine@gmd.de
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Some detailed Blorb queries
In-Reply-To: <afe0b1d54a.kbracey@kbracey.cam.pace.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 13:17 7/11/01 +0000, Kevin Bracey wrote:
 >
 >12) What should the relative volume of samples and music be? I
 >    would suggest that a sample played on one channel of a SONG
 >    should be of equal volume to that sample played as an 
effect.
 >    This needs to be standardised - currently Moments Out Of 
Time
 >    defaults to music at volume 1 and sound at volume 5. This
 >    apparently is because whichever interpreter the author is
 >    using plays music much louder than samples. But the music 
ends
 >    up far too quiet on Zip 2000.

That's a sensible default, but there should *always* be some way 
for the user to override this, either interpreter-wide or by the 
individual story files (without resorting to the Windows Volume 
Control or equivalent).

People have different tastes in what volumes they prefer; for 
example, I usually prefer to have the music playing significantly 
quieter than sound effects, because that way the sound effects 
(which tend to be more important) grab my attention better that 
way.  But other people would like them equal, and some would even 
like it with the music drowning out the sound!

Perhaps it could be set up as a hierarchy:
   1. Raw sound files, whatever volume they were (it's up to the 
authors to make them the same volume)
   2. Interpreter volume defaults
   3. Story volume defaults (some authors may prefer to override 
the default interpreter settings)
   4. User settings

So whenever you open a new story file, it has no user settings and 
will use the defaults, either from the story file or the 
interpreter, but the user can override these to whatever they 
prefer.
-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
The difference between a neurotic and a psychotic is that, while a 
psychotic
thinks that 2+2=5, a neurotic knows the answer is 4, but it 
worries him.


</x-flowed>
From ???@??? Fri Dec 07 09:23:01 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: Z-machine@gmd.de
Date: Mon, 3 Dec 2001 20:06:55 -0500
MIME-Version: 1.0
Subject: [z-machine] Dynamic Header Entries
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C0BDB5F.2267.2CB667@localhost>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


There are three bits of Flags 2 that the Spec says "may legally be 
changed by the game during play."  One of these (bit 2), needs to be 
cleared by the Z-Code (according to the spec).

2: Int sets to request status line redraw: game clears when it complies 
with this.

Is there actually a way to do this with the current tools (Inform)?  It 
would also be useful to both set and clear this bit.

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Fri Dec 07 09:23:19 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 04 Dec 2001 12:47:07 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Dynamic Header Entries
Message-ID: <94ad96e34a.kbracey@kbracey.cam.pace.co.uk>
References: <3C0BDB5F.2267.2CB667@localhost>
In-Reply-To: <3C0BDB5F.2267.2CB667@localhost>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <3C0BDB5F.2267.2CB667@localhost>
          "Jason C Penney" <jpenney@jczorkmid.net> wrote:

> There are three bits of Flags 2 that the Spec says "may legally be 
> changed by the game during play."  One of these (bit 2), needs to be 
> cleared by the Z-Code (according to the spec).
> 
> 2: Int sets to request status line redraw: game clears when it complies 
> with this.
> 
> Is there actually a way to do this with the current tools (Inform)?  It 
> would also be useful to both set and clear this bit.

You just write to the header with the standard --> operator:

    0-->8 = (0-->8) &~ 4;

I can't help but feel a little dubious about the idea of the game setting the
bit itself. It would obviously make life easier for the programmer by storing
a "refresh screen please" request in a single known location. Does anyone
know whether Infocom did this?

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Fri Dec 07 09:23:20 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Tue, 4 Dec 2001 08:39:57 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Dynamic Header Entries
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C0C8BDD.18077.3ACC0B@localhost>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Kevin Bracey sent a message across the ether on 4 Dec 2001 (12:47)
stating:

> You just write to the header with the standard --> operator:
> 
>     0-->8 = (0-->8) &~ 4;

Thanks.  I was using 0->$10 instead of 0-->($10/2).

Jay


-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Fri Dec 07 09:23:22 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 04 Dec 2001 14:37:18 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Dynamic Header Entries
Message-ID: <c9c3a0e34a.kbracey@kbracey.cam.pace.co.uk>
References: <3C0C8BDD.18077.3ACC0B@localhost>
In-Reply-To: <3C0C8BDD.18077.3ACC0B@localhost>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <3C0C8BDD.18077.3ACC0B@localhost>
          "Jason C Penney" <jpenney@jczorkmid.net> wrote:

> Kevin Bracey sent a message across the ether on 4 Dec 2001 (12:47)
> stating:
> 
> > You just write to the header with the standard --> operator:
> > 
> >     0-->8 = (0-->8) &~ 4;
> 
> Thanks.  I was using 0->$10 instead of 0-->($10/2).

Well, 0->$10 should work too. Oh, no it shouldn't, we're big-endian. 0->$11
would work. I prefer 0-->8 though.

-- 
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/


From ???@??? Fri Dec 07 09:23:29 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Tue, 4 Dec 2001 23:51:53 -0500
MIME-Version: 1.0
Subject: [z-machine] Mouse (again)
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C0D6199.32717.25E97D5@localhost>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Hi again,

I've put together a table of mouse support on different Z-Machine 
interpreters at http://www.jczorkmid.net/~jpenney/v6lib.diary/

Everything makes sense to me except Infocom's Dos V6 interpreter.  When 
running ZMouse it fills in the header information backwards from every 
other interpreter.  I'd assume it was just a bug, except that I can run 
the same Zork 0 file under it and Frotz and have mouse support work 
correctly in both.  Does anyone have any idea of why this would happen?

Thanks,
Jay Penney
-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Tue Dec 11 21:37:38 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 10 Dec 2001 12:43:25 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Message-ID: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


Over the past few weeks, Jason Penney and I have jointly drafted a modest
proposal for a new revision of the Z-machine standard.

It is humbly submitted to the list, in the hope that interested parties will
pass comment and to see whether we can agree that such an extension is
worthwhile.

The draft is here presented as an "update" to Standard 1.0. If it is finally
approved, a new integrated Standard 1.1 document would obviously have to
be drafted as well. Inform would also need minor patches to access the
extra capabilities straightforwardly.

Kevin Bracey
Jason C. Penney
---------------





                      Z-Machine Standard 1.1 Proposal
                      -------------------------------

                   Authors: Kevin Bracey & Jason C. Penney

                                INTRODUCTION
                                ============

This revision of the Z-Machine Standards Document has been written with
the following aims:

   1) To clarify problem areas in Standard 1.0, and correct errors
   2) To allow more probing of interpreter capabilities
   3) To clarify the use of Blorb with Standard 1.0
   4) To add some extensions for use with Blorb
   5) To add some simple extensions to the Version 5 and Version 6
      screen models to increase flexibility

As ever, interpreters *FULLY* implementing this Standard (apart from any
optional parts whose absence are signalled through header bits) for a given
Version should indicate this by setting the Standard revision bytes in the
header to $01 $01. (An interpreter might meet the Standard for all Versions
other than V6, in which case it would not fill in the revision bytes when
playing a V6 game).

There have been instances in the past of interpreters that do not fully meet
Standard 1.0 claiming Standard 1.0 compliance in the header. This sort of
behaviour is dangerous, and likely to cause games that would otherwise work
to break.

Conversely, games that absolutely require Standard 1.1 features should not
refuse outright to run on a non-Standard 1.1 interpreter - it may be
implementing the new features you require, being deficient only in other
areas. Instead, a warning should be issued to the user before proceeding.
Of course, whereever possible games should have alternative behaviour
automatically invoked for older interpreters.


                          UPDATES/CLARIFICATIONS
                          ======================

Memory layout
-------------
Version 6 and 7 story files are both limited to 512K, not 320K. The 320K
limitation was an artificial one imposed by the Inform compiler - this has
now been addressed by a compiler patch.


Encoded text
------------
Many of Infocom's interpreters (and some subsequent interpreters, such as
ITF's) treat multiple consecutive Z-characters 4 and 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.


Header capabilities bits
------------------------
The bits in the header indicating availability of sound or graphics should
ideally be set reflecting current availability, rather than general support.
In other words, if no Blorb (or other) resources for this story file have
been found, or if the Blorb file contains no graphics or no sound, the
corresponding bits should be cleared.

Also, it is recommended that interpreters that would prompt for an auxiliary
Blorb file should do so immediately on start up if any of the "game wants to
use sound/music/graphics" bits are set; this allows the bits to be cleared if
no file is forthcoming, before the game starts execution. The game can then
take appropriate action.

Bit 4 of Flags 1 indicates the availability of the fixed-pitch style, not
Font 4.


The fixed-pitch header bit
--------------------------
Use of the fixed-pitch bit in the header is deprecated in Version 5 and
later - it is an irregularity in the Z-machine that complicates the
implementation of buffering and text style handling in the interpreter, and
may even slow down all memory stores.

Font 4 (or Fixed Pitch style) should be used instead. Infocom did not use the
fixed-pitch bit after Version 4, and it is not implemented in at least some
of their later interpreters.

However, the fixed-pitch bit is modified by the "font" statement in
Inform 6.21, so is used by many current Inform generated files. Therefore
interpreter authors must support it in Version 5. Support in Version 6 is not
required.


@set_text_style
---------------
It was previously unclear in the Standard whether instructions like 

   @set_text_style 5;   ! Reverse+Italic

were legal. None of Infocom's game files make use of such forms, and many
interpreters will not handle them correctly. Such instructions should be
avoided; instead you can use multiple @set_text_style opcodes specifying each
style in turn, with the most important last, thus:

   @set_text_style 4;   ! Italic
   @set_text_style 1;   ! Reverse - overrides if combination not available

However, Standard 1.1 does now require such combinations in a single
opcode to be supported, as they are in some of Infocom's later
interpreters - see below. But unless a game absolutely requires
Standard 1.1 anyway (eg for true colour support), it is probably best
to request only one style per opcode for Standard 1.0 compatibility.


@get_prop_len
-------------
@get_prop_len 0 should return 0. This is required by some Infocom games and
files generated by old versions of Inform.


@set_cursor
-----------
S8.7.2.3 states that it is illegal to move the cursor outside the current
size of the upper window. S8.8.3.5 gives the equivalent rule for Version 6.

Many modern games have been lax in obeying this rule; in particular some
of the standard Inform menu libraries have violated it. Infocom's Sherlock
also miscalculated the size of the upper window to use for box quotes.

It is recommended that if the cursor is moved below the split position in
V4/V5, interpreters should execute an implicit "split_window" to contain the
requested cursor position, if possible. Diagnostics should be produced, but
should be suppressable.

In V6, it is legal to position the cursor up against the right or bottom of a
window - eg at (1,1) in a zero-sized window or at (641,401) in 640x400
window. Indeed, this is the default state of windows 1 to 7, and the cursor
may be left at the right-hand side of a window when wrapping is off.


@split_window
-------------
In Version 6, the Standard states that the cursor remains in the same
absolute position. This is an extension to the Z-machine, as this rule is not
followed by Infocom's own interpreters, which keep the same window-relative
position. The Standard behaviour more closely mimics Version 5's
split_window.

The opcode dictionary incorrectly states that "the width and x-coordinates of
windows 0 and 1 are not altered." The correct behaviour is detailed in
S8.8.4.1.


@output_stream
--------------
Interpreter authors are reminded that "nested" uses of @output_stream 3
have been required since Standard 1.0; see S7.1.2.1.1.


@read_mouse
-----------
@read_mouse should be realtime.  When called it should read the current mouse
location, whether or not the mouse is inside the current mouse window. Most
modern interpreters get this wrong, but Infocom's interpreters behave this
way. Interpreters are allowed to show positions and button states outside the
Z-machine screen if the pointer is outside the interpreter's own user
interface (using negative values if needed). 

Programs should be prepared to cope with this. For example in a painting
program you might want to ignore all buttons down outside the screen. When
dragging something you might want to keep trying to follow the pointer, even
outside the screen, until the buttons are released. 

Interpreters may constrain the pointer to the screen as long as buttons are
held down - this might aid dragging operations - although this is not
required.

Previous revisions of the Standard stated that mouse buttons were numbered in
the following fashion: "low bits on the right of the mouse, rising as one
looks left".  This is a rather non-portable implementation and should be
abandoned in modern interpreters in favor of the 'primary' button being the
lowest bit, the 'secondary' (if present) being the next lowest bit, etc. The
ordering of buttons should be that which is most natural for the host system.


@picture_data
-------------
@picture_data 0 should branch if any pictures are available.


@sound_effect
-------------
To clarify:

    @sound_effect number 3/4

will stop (and optionally unload) sound 'number' if it is currently playing
(or loaded). Otherwise it is ignored.

    @sound_effect 0 3/4

will stop (and unload) all sounds - music and effects.

The "repeats" parameter in Version 5 indicates the total number of times to
play the sound, not the number of times to repeat it after the first play.
Setting repeats to zero in V5 is illegal - it is suggested that interpreters
treat this as a request to play the sound once, and maybe issue a warning.

Callback routines are only called when the sound has played the requested
number of times. If manually stopped or interrupted by another sound, the
routine is not called.

The Blorb specification effectively revised Standard 1.0, as follows:

"Sound" is split into two classes - "music" (eg Blorb SONG and MOD) and
"effects" (eg Infocom .SND or Blorb AIFF).

The "sound requested" header bit is left set if the interpreter supports
either effects or music. It is only cleared if the interpreter can provide
neither effects nor music.

Music and effects are treated as two separate channels. Playing a new effect
interrupts the current effect, but not the music, and vice versa. Whether
loading a new sound (with @sound_effect n 1) stops the current one is
implementation defined.

As of Standard 1.1, there is a header bit to indicate that the game wants to
use multiple sound channels and the interpreter can handle it, and a bit
to indicate the availability of music.


Colour numbers
--------------
The presence of the "under the cursor" colour option, and in Standard 1.1
the set_true_colour opcode (see below), raises the possibility of
non-standard colour numbers appearing in window property 11. In addition, an
interpreter may offer non-standard default colours, which need to appear in
the story file header. We now give more detailed implementation guidelines.

If a true colour, or an "under the cursor" colour, has been requested by the
game, then the foreground or background colour shown in window property 11 is
implementation defined, except that:

      1) If the colour selected was one of the standard set (2-15), then
         that colour should be indicated in property 11.
      2) If the colour selected was not one of the standard set, the colour
         shown in property 11 should be >= 16.

It is legal for interpreters to always show the same value in property 11 if
a true or sampled colour is in use. As a result, story files cannot rely on
setting a value that was read from the window property giving the same
colour, if @set_true_colour or @set_colour -1 has been used in that window.

The same rules apply if an interpreter offers non-standard default colours
(which need to be shown in the header) although in this case it would be
ill-advised to show the same colour numbers for foreground and background -
unless they can be distinguished, non-standard default colours should
probably not be offered.

If the interpreter offers a limited palette, then there is no problem, as it
can be arranged for there to be fewer than 240 distinct non-standard colours.
In an interpreter with a higher colour-depth, a good implementation would be
to use colours 16-255 to represent the last 240 distinct non-standard colours
used, re-using numbers after 240 colours have been used. This will minimize
potential problems caused by non-standard colours, particularly when set as
defaults. 

Regardless of the limitations on colour numbers, in Version 6 each window
must remember accurately the colour pair selected, so it is preserved across
window switches.


                                ADDITIONS
                                =========

Blorb
-----
Standard 1.1 interpreters are required to handle Blorb (v1.1) files, at least
up to support for running a Z-code executable from within a Blorb file. If
the interpreter supports sound or graphics, it must be able to obtain those
resources from a Blorb file (although the Standard does not preclude other
formats).


Header Extension
----------------
If the interpreter claims Standard 1.1 compliance than it supports the
following extra words in the header extension table. If the header
extension table is present, and the extra words are present, then a
Standard 1.1 interpreter will examine and update them.

If the interpreter is not Standard 1.1, then the extra words will be ignored.
Guidelines on behaviour in this case are supplied in the descriptions below.

The new flags are placed in a new word, rather than in Flags 2 to minimize
potential compatibility problems. To prevent future compatibility problems,
all reserved bits in the Flags 3 word MUST be cleared by the interpreter.

Word  V  Dyn Int Rst  Contents
---- --- --- --- ---  --------------------------------
 4    3               Flags 3:
      4       *   *   0: All text style combinations available?
      5       *   *   1: Multiple colours available?
      3       *   *   8: If set, game wants to use music
      3       *   *   9: If set, game wants multiple sound channels
      6       *   *   10: If set, game wants to use transparency
                      (For bits 8-10, Int clears again if it cannot provide
                       the requested effect).
 5    5       *   *   True default foreground colour
 6    5       *   *   True default background colour


0: All text style combinations available?

         An interpreter sets or clears this bit to indicate whether
         it can provide all the text styles it supports in all
         combinations.  If it can do Bold, Italic or Fixed, but not
         Bold and Fixed at the same time this bit should be 0.  If it
         doesn't support Italic at all (and has cleared Flags 1 bit 3
         to specify this), but it does support combinations of the
         remaining three styles it should set this bit to 1.

         All combinations are required for font 1. Font 3 only requires
         Roman and Reverse Video. Font 4 requires all combinations, except
         that Fixed is ignored (because it is inherently fixed-pitch).

         If the interpreter predates Standard 1.1, then text style
         combinations may or may not be available; however until
         Standard 1.1 interpreters were not required to handle
         combinations of styles in a single @set_text_style call.
         Combination effects should therefore be requested using
         sequential calls (with the most important effect requested
         last).

1: Multiple colours available?

         This bit should be 1 if the interpreter can display multiple
         text colours on screen at one time, and should be 0 if
         changing the text colour changes all text on screen.

         Preferred behaviour for Standard interpreters is to display
         multiple colours. But if the interpreter predates Standard 1.1,
         then generally its behaviour will depend on the machine type -
         see section 8.3. If this flags word is present, then a Standard
         interpreter should normally set the bit, and provide multiple
         colours if at all possible, regardless of machine type.

8: If set, game wants to use music

        A game file that wishes to use music will set this bit.  If an
        interpreter can provide music (as described in the Blorb
        specification) it should leave the bit set; if it is unable
        to do this, it should clear the bit.  If this bit is set then
        a minimum of two sound channels exist, one for effects and one
        for music.

        If this flags word is not present, or the interpreter predates
        Standard 1.1, then there is no way to tell whether music is
        available. If an interpreter doesn't support music, then
        @sound_effect opcodes requesting music will be ignored.

        If a game that supplies this flags word does not set this bit,
        then the interpreter may choose to act as though music were
        unsupported.

9: If set, game wants multiple sound channels
 
        If the game wishes to have multiple sound channels, it
        should set this bit. This changes the behaviour of @sound_effect.
        An interpreter should clear this bit if it can't play more than one
        sound of a given type a time.

        Interpreters predating standard 1.1 will not support multiple
        sound channels, and will act as though this bit is clear.

        The minimum requirement on an interpreter that sets this bit is
        that it can play at least two mono effects and one (4-channel)
        piece of music simultaneously. More channels may be available (see
        @sound_effect section below for details).

10: If set, game wants to use transparency

        In Version 6 colour 15 is defined as transparent.  If an
        interpreter cannot provide transparency then it should clear
        this bit.

        Transparency is a new feature in Standard 1.1. Older interpreters
        will not support this.

All other bits in the flags word must be cleared by the interpreter.


@save and @restore
------------------
EXT:0 0 5 save table bytes name prompt -> (result)
EXT:1 1 5 restore table bytes name prompt -> (result)

As of Standard 1.1 an additional optional parameter, prompt, is allowed on
Version 5 extended save/restore.  This allows a game author to tell the
interpreter whether it should ask for confirmation of the provided file name
(prompt=1), or just silently save/restore using the provided filename
(prompt=0).

If the parameter is not provided, whether to prompt or not is a matter for
the interpreter - this might be globally user-configurable. Infocom's
interpreters do prompt for filenames, many modern ones do not.


@buffer_screen
--------------
New opcode in Standard 1.1, for Version 6

EXT:29 1D 6 buffer_screen mode -> (result)

Interpreters may use a backing store to store the Z-machine screen state,
rather than plotting directly to the screen. This would normally be the case
in a windowed operating system environment. If a backing store is in use,
display changes executed by the Z-machine may not be immediately made visible
to the user. Standard 1.1 adds the new opcode @buffer_screen to Version 6 to
control screen updates. An interpreter is free to ignore the opcode if it
doesn't fit its display model (in which case it must act as if buffer_screen
is always set to 0).
  
When buffer_screen is set to 0 (the default), all display changes are
expected to become visible to the user either immediately, or within a short
period of time, at the interpreter's discretion. At a minimum, all updates
would become visible before waiting for input. Any intermediate display
states between input requests may not be seen; for example when printing a
large amount of new text into a scrolling window, all the intermediate scroll
positions may or may not be shown.
  
When buffer_screen is set to 1, the interpreter need not change the visible
display at all. Any display changes can be done purely in the backing store.
A program may set buffer_screen to 1 before carrying out a complex layered
graphical composition, to indicate that the intermediate states are not worth
showing. When buffer_mode is set back to 0, the display is not necessarily
updated immediately - if this is required, buffer_mode -1 should be issued as
well. It would be extremely ill-advised to prompt for input with
@buffer_screen set to 1.
  
With buffer_screen in either state, an update of the visible display can be
forced immediately by issuing @buffer_screen -1, without altering the current
buffering state. Note that @buffer_screen -1 does NOT flush the text buffer.
  
@buffer_screen returns the old buffer_screen state.


@set_text_style
---------------
As of Standard 1.1, it is legal to request style combinations in a
single @set_text_style opcode by adding the values (which are powers of two)
together. If the parameter is non-zero, then all the styles given are
activated. If the parameter is zero, then all styles are deactivated.

If the "All text style combinations available?" bit is set in the header
extension, then the interpreter is required to display a combination of all
styles requested that it provides (i.e. if the interpreter can't display
italic but a game file requests style 12 [Italic + Fixed] anyway, the
interpreter would activate the Fixed style).  If the "Full font style
combinations available" bit is not set, then the Interpreter should give
precedence first to the most recent call to @set_text_style, and within that
to the highest bit, making the priority Fixed, Italic, Bold, Reverse. 


@set_font
---------
EXT:4 4 6 set_font font window -> (result)

In Version 6, set_font has an optional window parameter, as for set_colour.
This was part of the original Infocom design, but omitted by earlier
Standards. It is reinstated here, as it is useful to be able to measure
a font that is about to be used in another window, so that window can be
sized before attempting to place the cursor in it.


@set_colour
-----------
In Version 6 only, colour 15 is defined as transparent.  This is only valid
as a background colour; an attempt to select it for the foreground should
produce a diagnostic. Interpreters not supporting transparency should ignore
any attempt to select colour 15.

If the current background colour is transparent, then printed text should be
superimposed on the current window contents, without filling the background
behind the text. @erase_window, @erase_line and @erase_picture become null
operations.

The intent is to make it possible to superimpose text on non-uniform images.
Up until now, only uniform images could be satisfactorily written on
by sampling the background colour - that in itself would be problematical if
the interpreter used dithering..

Scrolling with the background set to transparent is not permitted, so
transparent should only be requested in a non-scrolling window. It is not
valid to use Reverse Video style with the background set to transparent.

Instructions that prompt for user input, such as @read and @save should be
avoided when the background is set to transparent, as it will not generally
be possible for text entry to take place satisfactorily in the absence of
a defined background colour.

Printing text multiple times on top itself with the background set to
transparent should be avoided, as the interpreter may use anti-aliasing,
resulting in the text getting progressively darker.

Standard 1.1 interpreters should provide the following basic colour
set, regardless of machine type, in both Version 5 and Version 6:

 -1 = sample      (true -3) [V6 only]
  0 = current     (true -2)
  1 = default     (true -1)
  2 = black       (true $0000, $$0000000000000000)
  3 = red         (true $001F, $$0000000000011111)
  4 = green       (true $03E0, $$0000001111100000)
  5 = yellow      (true $03FF, $$0000001111111111)
  6 = blue        (true $7C00, $$0111110000000000)
  7 = magenta     (true $7C1F, $$0111110000011111)
  8 = cyan        (true $7FE0, $$0111111111100000)
  9 = white       (true $7FFF, $$0111111111111111)
 10 = light grey  (true $5AD6, $$0101101011010110)
 11 = medium grey (true $4631, $$0100011000110001)
 12 = dark grey   (true $2D6B, $$0010110101101011)
 13  reserved
 14  reserved
 15 = transparent (true -4) [V6 only]

This is the original Amiga Version 6 colour set. The greys are gamma adjusted
from the original values (8-bit &AA,&77,&44) used on the Amiga, on the
assumption that the Amiga's system gamma is 1/1.8.

The equivalences between the colour numbers and true colours are canonical -
this gives an exact equivalence mapping from @set_colour to @set_true_colour.

Interpreters may provide different colours (eg making colour 10 dark grey),
but if and only if they can detect they are running an original Infocom story
file.


@set_true_colour
----------------
New opcode in Standard 1.1, for Version 5 or later.

EXT:13 D 5 @set_true_colour foreground background
         6 @set_true_colour foreground background window

fg and bg are 15-bit colour values - bit 15 = 0
                                     bits 14-10 blue
                                     bits 9-5 green
                                     bits 4-0 red

Magic values in the opcode are: (-1) = default setting
                                (-2) = current setting
                                (-3) = colour under cursor (V6 only)
                                (-4) = transparent (V6 only)

The interpreter should set the closest approximations available to
the requested colours. In V6, the interpreter may store the approximations
in window properties 16 and 17, so the program can tell how close it got
(although it is acceptable for the interpreter to just store the requested
value).

In the minimal implementation, interpreters just need to match to the closest
of the standard colours and internally call @set_colour (although that would
have to ensure window properties 16 and 17 were updated). In a full
implementation this would be turned around and @set_colour would internally
call @set_true_colour.

The default true colours are stored in the header extension table.

The optional window parameter is only allowed in V6, and operates the same as
in @set_colour.

True colour specifications are in the sRGB colour space, $0000 being black
and $7FFF being white. Colours should be gamma adjusted if necessary. See the
PNG specification for a good introduction to colour spaces and gamma
correction.


@get_wind_prop
--------------
With the addition of true colours, two new Version 6 window properties are
defined.

The two new window properties are:

   16: true foreground colour
   17: true background colour

These are not writable with @put_wind_prop.

The true foreground and background colours show the actual colour being
used for the foreground and background, whether it was set using @set_colour
or @set_true_colour. Transparent is indicated as -4. If the colour was
sampled from a picture, the value shown may be a 15-bit rounding of a
more precise colour, leading to a slight inaccuracy if the colour is read
and then written back.



@sound_data
-----------
New opcode in Standard 1.1, for Version 5 or later.

EXT:14 E 5 sound_data sound-number array ?(label)

Asks the interpreter for data on the sound with the given number. If the
sound number is valid, and the sound is of a type supported by the
intepreter, a branch occurs and information is written to the
array: the type (1 for effect, 2 for music) in word 0, and playing
status in word 1. (This is an array, not a "table" with initial size
information.) 

Otherwise, if the sound number is zero, the interpreter writes the number of
available (and supported) sounds into word 0 of the array and the release
number of the sounds file (eg from the Blorb RelN chunk) into word 1. A
branch occurs if the number of sounds is non-zero.

Otherwise, nothing happens.

The playing status is -1 if the sound is not currently playing. If the sound
is currently playing, the playing status is the length of time that the
sound has been playing, in tenths of a second, clamped to a maximum of 3276.7
seconds. If the sound is playing on multiple channels, it is the longest
running channel's playing time that is indicated.


@sound_effect
-------------
Standard 1.1 adds new behaviour to @sound_effect (but see the clarifications
section above for notes on pre-1.1 behaviour).

As of Standard 1.1, there is a header bit to indicate that the game wants to
use multiple sound channels and the interpreter can handle it.

If the multiple sound channels bit is clear (or not present), then the
interpreter behaves as per Standard 1.0 + Blorb 1.1 - see above for
clarifications.

If the multiple sound channels bit is set, then the interpreter should not
stop any current sound when a new one is played or loaded - it should only
stop a sound when explicitly asked to, or when it has played the specified
number of repeats. That way, a game can play multiple sounds of the same type
at once. 

However, there are an undefined number of sound channels available. When an
interpreter runs out of channels of a particular type, and an additional call
to @sound_effect is made, the sound with the highest resource number of the
same type is stopped (without its callback routine being called) and the new
sound is played.

The highest resource number rule allows an author to indicate the
"importance" of each sound.

The same sound can be played on more than one channel. In the event of
channel exhaustion, it is the "oldest" play of the sound with the highest
resource number that gets stopped first.

The original Standard 1.0 + Blorb 1.1 behaviour is equivalent to the new
scheme with one channel each of effects and music.


New opcode summary:
-------------------
St Br Opcode Hex V Inform name and syntax
*     EXT:0  0   5 save table bytes name prompt -> (result)
*     EXT:1  1   5 restore table bytes name prompt -> (result)
*     EXT:4  4   6 set_font font window -> (result)
      EXT:13 D   5 set_true_colour foreground background
                 6 set_true_colour foreground background window
   *  EXT:14 E   5 sound_data sound-number array ?(label)
*     EXT:29 1E  6 buffer_screen mode -> (result)

set_true_colour is not a good candidate for taking a 2OP encoding like
set_colour, as it will have a low usage frequency, and it will rarely take
small constants.


From ???@??? Tue Dec 11 21:37:58 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 10 Dec 2001 14:57:24 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <e29eb9e64a.kbracey@kbracey.cam.pace.co.uk>
References: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk> <20011210153713.A8805@igloo.df.lth.se>
In-Reply-To: <20011210153713.A8805@igloo.df.lth.se>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <20011210153713.A8805@igloo.df.lth.se>
          Magnus Olsson <mol@df.lth.se> wrote:

> 
> Here and in some other places I'm missing a reference to V8, which
> I think is the same as V5 in this respect.

V7 and V8 are implicitly the same as V5 in all respects, apart from packed
address handling. That's stated in section 1 of the existing Standard, but
you're right - a reminder wouldn't go amiss.

> 
> This implies that the primary mouse button is the right button -
> shouldn't it be "the 'primary' button being the highest bit" etc?

There's a basic problem here, which is why we're proposing changing it.
See http://web.jczorkmid.net:8080/~jpenney/v6lib.diary/ for the results
of Jason's investigations.

Normally, the left button is the primary one on most systems. This means that
at the moment the primary button is placed in bit 1 in Infocom's DOS
interpreter, with the secondary in bit 0. But in Infocom's Mac interpreter
(or WinFrotz, which only supports one button) the primary (only) mouse button
is in bit 0.

In other words a game author cannot tell which bit to check for the "primary"
mouse button - its location depends on how many buttons the mouse has!
Now, if they'd designed it with the primary button in bit 15, then it would
have been okay.

So the proposal is to put the primary button at the bottom. This matches the
existing behaviour of Infocom's Mac interpreter and WinFrotz, but reverses
the buttons of Infocom's DOS interpreter and Zip 2000. Zip 2000 will
obviously be updated, and anyone who can get the mouse to work on Infocom's
DOS interpreter (which isn't easy these days) will have to live with reversed
buttons.

None of Infocom's own games used @read_mouse, apart from to check menu
selections.

> > The "repeats" parameter in Version 5 indicates the total number of times
> > to play the sound, not the number of times to repeat it after the first
> > play. Setting repeats to zero in V5 is illegal - it is suggested that
> > interpreters treat this as a request to play the sound once, and maybe
> > issue a warning.
> 
> I seem to recall from the discussion on r.a.i-f that there are games
> around that set repeats to zero, so perhaps interpreters shouldn't treat
> it as an error but as equivalent to repeats == 1?

That's what it suggests, but endorsing such usage would (IMO) be a rather
pointless change to the Standard. I'm not sure whether Infocom's interpreters
would handle repeats = 0, so let's nip it in the bud. How many games actually
do this? There's only MooT, I think. 

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Tue Dec 11 21:38:02 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 10 Dec 2001 15:52:22 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <38a7bee64a.kbracey@kbracey.cam.pace.co.uk>
References: <200112101531.JAA09955@heme.bioc.rice.edu>
In-Reply-To: <200112101531.JAA09955@heme.bioc.rice.edu>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <200112101531.JAA09955@heme.bioc.rice.edu>
          "Lucian P. Smith" <lpsmith@bioc.rice.edu> wrote:

> What if, as a logical extension, repeats=0 loaded up the sound but didn't
> play it?  While not useful in a real game, it might be useful for testing,
> and would be intuitive for game authors when coding.

I see what you're saying, but again, this can be done easily with
@sound_effect <n> 1. And existing interpreters (eg WinNitfol and Zip 2000) do
err on the side of caution already and play such sounds once. Now Glk has
always been clear that repeats=0 doesn't play anything. But the Z-machine is
a little bit fuzzier.

Does anyone know what Infocom's Mac and Amiga Sherlock interpreters do with
repeats=0?

> 
> This would kill MooT, of course, which might be sufficient cause to not do
> it this way in and of itself.  

I think so. It's better to cope with MooT, with a possible warning being
displayed, than to kill it outright.

> Is a new version being released that fixes this?

I'm sure this has been mentioned to Ross. We're expecting a bug-fixed version
shortly. I should probably mention the "font on/off" thing if we're proposing
deprecating it.

> 
> (also, if repeats is -N, it should play it backwards N times ;-)

The correct behaviour is of course to play it forwards N times, but starting
in the past and finishing at the point of execution of the opcode.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Tue Dec 11 21:38:04 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Mon, 10 Dec 2001 19:43:06 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com>
X-OriginalArrivalTime: 10 Dec 2001 19:37:32.0464 (UTC) FILETIME=[1C747300:01C181B2]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
To: <z-machine@gmd.de>
Sent: Monday, December 10, 2001 12:43 PM
Subject: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> Over the past few weeks, Jason Penney and I have jointly drafted a modest
> proposal for a new revision of the Z-machine standard.
>
> It is humbly submitted to the list, in the hope that interested parties
will
> pass comment and to see whether we can agree that such an extension is
> worthwhile.
>
> The draft is here presented as an "update" to Standard 1.0. If it is
finally
> approved, a new integrated Standard 1.1 document would obviously have to
> be drafted as well. Inform would also need minor patches to access the
> extra capabilities straightforwardly.
>
> Kevin Bracey
> Jason C. Penney
> ---------------

Yay! But why couldn't you have talked to me when I suggested the Z-Machine
be updated a few months back?

And now, a few comments on the additions portion of the proposal. I haven't
commented
on the rest because I pretty much agree with it all.

>                                 ADDITIONS
>                                 =========
>
> Blorb
> -----
> Standard 1.1 interpreters are required to handle Blorb (v1.1) files, at
least
> up to support for running a Z-code executable from within a Blorb file. If
> the interpreter supports sound or graphics, it must be able to obtain
those
> resources from a Blorb file (although the Standard does not preclude other
> formats).

This seems like it might be a good idea in the short term, but, well, blorb
is not part of the Z-Machine. The Z-Machine games will run just fine without
this, and blorb may well be replaced at any time. I think blorb should be
supported by terps, but I don't think terps should have to support it. Like
Quetzal.

> @sound_effect
> -------------
> Standard 1.1 adds new behaviour to @sound_effect (but see the
clarifications
> section above for notes on pre-1.1 behaviour).
>
> As of Standard 1.1, there is a header bit to indicate that the game wants
to
> use multiple sound channels and the interpreter can handle it.
>
> If the multiple sound channels bit is clear (or not present), then the
> interpreter behaves as per Standard 1.0 + Blorb 1.1 - see above for
> clarifications.
>
> If the multiple sound channels bit is set, then the interpreter should not
> stop any current sound when a new one is played or loaded - it should only
> stop a sound when explicitly asked to, or when it has played the specified
> number of repeats. That way, a game can play multiple sounds of the same
type
> at once.
>
> However, there are an undefined number of sound channels available. When
an
> interpreter runs out of channels of a particular type, and an additional
call
> to @sound_effect is made, the sound with the highest resource number of
the
> same type is stopped (without its callback routine being called) and the
new
> sound is played.
>
> The highest resource number rule allows an author to indicate the
> "importance" of each sound.
>
> The same sound can be played on more than one channel. In the event of
> channel exhaustion, it is the "oldest" play of the sound with the highest
> resource number that gets stopped first.
>
> The original Standard 1.0 + Blorb 1.1 behaviour is equivalent to the new
> scheme with one channel each of effects and music.

I don't like this. I've never liked blorb's idea of music and sound effects
in
seperate channels. I don't think blorb is terribly fond of blorb's idea of
music and sound effects in seperate channels.
It says, in that spec:

This is an actual variance in the behavior of the Z-machine, and worse, a
variance which depends on data format. (One sound will either stop another,
or not, depending on whether the sound is stored in AIFF or MOD format.) We
apologize for the ugliness.

And it *is* ugly. I think we have few enough Z-Machine games using sound
that we can just
cut this out now, and replace it with something that isn't so ugly. Plus, if
the terp says
it can't handle channels, I think this should mean that it can't handle
channels, not that
it has two.

I don't like the automatic creation and destruction of channels without the
game-writer
having any control over the matter. If I want three sounds playing, and the
terp only
supports two, this will create ugliness and unexpected happenings. I think a
set number
of channels, say eight, with an opcode to set the current channel, is a
better idea.

So. Eight channels, numbered 0 to 7. The default channel is 0.
set_channel channel-number sets the current channel to channel-number.
sound_effect
works exactly as before, except only for the sound on the current channel.
If the
current channel is 1, and there's an AIFF playing on channel 1, and I tell
sound_effect
to play a MOD, it interupts the AIFF, but leaves all sounds on other
channels going.
There should also be some way to determine the current sound channel.

With this scheme, the bit in the header to check if music is supported would
not really
be needed, because the terp does not need to know the difference between
music and sound,
and can always check if any particular sound is playable with sound_data. If
the bit
in the header to check if channels were available was unset, only one sound
could
be played at a time, and calling set_channel would either be illegal, or
just do
nothing. I recommend the latter.

> New opcode summary:
> -------------------
> St Br Opcode Hex V Inform name and syntax
> *     EXT:0  0   5 save table bytes name prompt -> (result)
> *     EXT:1  1   5 restore table bytes name prompt -> (result)
> *     EXT:4  4   6 set_font font window -> (result)
>       EXT:13 D   5 set_true_colour foreground background
>                  6 set_true_colour foreground background window
>    *  EXT:14 E   5 sound_data sound-number array ?(label)
> *     EXT:29 1E  6 buffer_screen mode -> (result)
>
> set_true_colour is not a good candidate for taking a 2OP encoding like
> set_colour, as it will have a low usage frequency, and it will rarely take
> small constants.

And with set_channel:

St Br Opcode Hex V Inform name and syntax
      EXT:30  1D 5 set_channel chanel-number

--
Fillmore


From ???@??? Tue Dec 11 21:38:06 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
To: Noslwop@hotmail.com (Fillmore)
Date: Mon, 10 Dec 2001 15:13:22 -0500 (EST)
Cc: z-machine@gmd.de
In-Reply-To: <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com> from "Fillmore" at Dec 10, 2001 07:43:06 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20011210201322.A615A3080A3@fauna.jczorkmid.net>
From: jpenney@jczorkmid.net (Jason Penney)
Sender: owner-z-machine@gmd.de
Precedence: bulk


Legend has it that Fillmore said:


> > @sound_effect
> > -------------
> > Standard 1.1 adds new behaviour to @sound_effect (but see the
> clarifications
> > section above for notes on pre-1.1 behaviour).
> >
> > As of Standard 1.1, there is a header bit to indicate that the game wants
> to
> > use multiple sound channels and the interpreter can handle it.
> >
> > If the multiple sound channels bit is clear (or not present), then the
> > interpreter behaves as per Standard 1.0 + Blorb 1.1 - see above for
> > clarifications.
> >
> > If the multiple sound channels bit is set, then the interpreter should not
> > stop any current sound when a new one is played or loaded - it should only
> > stop a sound when explicitly asked to, or when it has played the specified
> > number of repeats. That way, a game can play multiple sounds of the same
> type
> > at once.
> >
> > However, there are an undefined number of sound channels available. When
> an
> > interpreter runs out of channels of a particular type, and an additional
> call
> > to @sound_effect is made, the sound with the highest resource number of
> the
> > same type is stopped (without its callback routine being called) and the
> new
> > sound is played.
> >
> > The highest resource number rule allows an author to indicate the
> > "importance" of each sound.
> >
> > The same sound can be played on more than one channel. In the event of
> > channel exhaustion, it is the "oldest" play of the sound with the highest
> > resource number that gets stopped first.
> >
> > The original Standard 1.0 + Blorb 1.1 behaviour is equivalent to the new
> > scheme with one channel each of effects and music.
> 
> I don't like this. I've never liked blorb's idea of music and sound effects
> in
> seperate channels. I don't think blorb is terribly fond of blorb's idea of
> music and sound effects in seperate channels.
> It says, in that spec:
> 
> This is an actual variance in the behavior of the Z-machine, and worse, a
> variance which depends on data format. (One sound will either stop another,
> or not, depending on whether the sound is stored in AIFF or MOD format.) We
> apologize for the ugliness.
> 
> And it *is* ugly. I think we have few enough Z-Machine games using sound
> that we can just
> cut this out now, and replace it with something that isn't so ugly. Plus, if
> the terp says
> it can't handle channels, I think this should mean that it can't handle
> channels, not that
> it has two.

It doesn't mean really that it has two.  It means it has one, and IF it
supports music it has two.

> I don't like the automatic creation and destruction of channels without the
> game-writer
> having any control over the matter. If I want three sounds playing, and the
> terp only
> supports two, this will create ugliness and unexpected happenings. I think a
> set number
> of channels, say eight, with an opcode to set the current channel, is a
> better idea.

What if the platform can only support 3 channels? Now the interpreter
has to say it doesn't support channels since it can't support 8 of
them.  If the platform can support 1024 channels it can still only
supply 8.

> So. Eight channels, numbered 0 to 7. The default channel is 0.
> set_channel channel-number sets the current channel to channel-number.
> sound_effect
> works exactly as before, except only for the sound on the current channel.
> If the
> current channel is 1, and there's an AIFF playing on channel 1, and I tell
> sound_effect
> to play a MOD, it interupts the AIFF, but leaves all sounds on other
> channels going.
> There should also be some way to determine the current sound channel.

I can imagine an implimentation where a MOD/SONG could use up multiple
channels since MODs are multichannel.  It would seem for an
interpreter to use the 8 channel scheme that could play either muisic
or sound it would have to support 8 multi-channel channels.  

Jay


-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Tue Dec 11 21:38:08 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <20011210201322.A615A3080A3@fauna.jczorkmid.net>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Mon, 10 Dec 2001 20:51:27 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE29cGOVXSw2zoRt0De000092fb@hotmail.com>
X-OriginalArrivalTime: 10 Dec 2001 20:45:54.0981 (UTC) FILETIME=[A9BEDD50:01C181BB]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Jason Penney" <jpenney@jczorkmid.net>
To: "Fillmore" <Noslwop@hotmail.com>
Cc: <z-machine@gmd.de>
Sent: Monday, December 10, 2001 8:13 PM
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> Legend has it that Fillmore said:
>
>
> > > @sound_effect
> > > -------------
> > > Standard 1.1 adds new behaviour to @sound_effect (but see the
> > clarifications
> > > section above for notes on pre-1.1 behaviour).
> > >
> > > As of Standard 1.1, there is a header bit to indicate that the game
wants
> > to
> > > use multiple sound channels and the interpreter can handle it.
> > >
> > > If the multiple sound channels bit is clear (or not present), then the
> > > interpreter behaves as per Standard 1.0 + Blorb 1.1 - see above for
> > > clarifications.
> > >
> > > If the multiple sound channels bit is set, then the interpreter should
not
> > > stop any current sound when a new one is played or loaded - it should
only
> > > stop a sound when explicitly asked to, or when it has played the
specified
> > > number of repeats. That way, a game can play multiple sounds of the
same
> > type
> > > at once.
> > >
> > > However, there are an undefined number of sound channels available.
When
> > an
> > > interpreter runs out of channels of a particular type, and an
additional
> > call
> > > to @sound_effect is made, the sound with the highest resource number
of
> > the
> > > same type is stopped (without its callback routine being called) and
the
> > new
> > > sound is played.
> > >
> > > The highest resource number rule allows an author to indicate the
> > > "importance" of each sound.
> > >
> > > The same sound can be played on more than one channel. In the event of
> > > channel exhaustion, it is the "oldest" play of the sound with the
highest
> > > resource number that gets stopped first.
> > >
> > > The original Standard 1.0 + Blorb 1.1 behaviour is equivalent to the
new
> > > scheme with one channel each of effects and music.
> >
> > I don't like this. I've never liked blorb's idea of music and sound
effects
> > in
> > seperate channels. I don't think blorb is terribly fond of blorb's idea
of
> > music and sound effects in seperate channels.
> > It says, in that spec:
> >
> > This is an actual variance in the behavior of the Z-machine, and worse,
a
> > variance which depends on data format. (One sound will either stop
another,
> > or not, depending on whether the sound is stored in AIFF or MOD format.)
We
> > apologize for the ugliness.
> >
> > And it *is* ugly. I think we have few enough Z-Machine games using sound
> > that we can just
> > cut this out now, and replace it with something that isn't so ugly.
Plus, if
> > the terp says
> > it can't handle channels, I think this should mean that it can't handle
> > channels, not that
> > it has two.
>
> It doesn't mean really that it has two.  It means it has one, and IF it
> supports music it has two.

True, but I still think all sounds should just be sounds, not music or
effects.

> > I don't like the automatic creation and destruction of channels without
the
> > game-writer
> > having any control over the matter. If I want three sounds playing, and
the
> > terp only
> > supports two, this will create ugliness and unexpected happenings. I
think a
> > set number
> > of channels, say eight, with an opcode to set the current channel, is a
> > better idea.
>
> What if the platform can only support 3 channels? Now the interpreter
> has to say it doesn't support channels since it can't support 8 of
> them.  If the platform can support 1024 channels it can still only
> supply 8.

This is the way the Z-Machine does things, though. As it says in the
current spec, the Z-Machine has 'a willingness to constrain maximum
as well as minimum levels of performance'. This way, we have 0, 1 or
8 channels, depending on the capabilities of the terp.
When writing a game, I want to know for a fact precisely how many
channels I have, and to be able to do anything to any of them.

> > So. Eight channels, numbered 0 to 7. The default channel is 0.
> > set_channel channel-number sets the current channel to channel-number.
> > sound_effect
> > works exactly as before, except only for the sound on the current
channel.
> > If the
> > current channel is 1, and there's an AIFF playing on channel 1, and I
tell
> > sound_effect
> > to play a MOD, it interupts the AIFF, but leaves all sounds on other
> > channels going.
> > There should also be some way to determine the current sound channel.
>
> I can imagine an implimentation where a MOD/SONG could use up multiple
> channels since MODs are multichannel.  It would seem for an
> interpreter to use the 8 channel scheme that could play either muisic
> or sound it would have to support 8 multi-channel channels.

This is a good point. Yes, it would mean that. Or not supporting MOD,
which would be a shame. It may be possible to do similar to what I believe
Glk does, and be able to create and destroy channels at will, with the terp
branching or something if it can't be done, but this should be under the
game
writer's control, not handled automatically by the terp.

--
Fillmore


From ???@??? Tue Dec 11 21:38:08 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Mon, 10 Dec 2001 19:17:53 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C150A61.28621.3CD862@localhost>
In-reply-to: <OE29cGOVXSw2zoRt0De000092fb@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Fillmore sent a message across the ether on 10 Dec 2001 (20:51) stating:

> True, but I still think all sounds should just be sounds, not music or
> effects.  

If we do that then there is no good way for an interpreter that 
supports only AIFFs and doesn't support MOD to signal this to the 
game.  Then the interpreter has to just claim it does not support 
sound, or the author is in a worse situation, and has to guess.

> This is the way the Z-Machine does things, though. As it says in the
> current spec, the Z-Machine has 'a willingness to constrain maximum as
> well as minimum levels of performance'. This way, we have 0, 1 or 8
> channels, depending on the capabilities of the terp.

This would give us music interrupting effects, which is incompatible 
with
Spec 1.0 + Blorb 1.1.

> When writing a game, I want to know for a fact precisely how many
> channels I have, and to be able to do anything to any of them.

What if @sound_data returned 3 words?  The third of which tells you 
how many channels of that type of sound remain?

> > I can imagine an implimentation where a MOD/SONG could use up 
multiple
> > channels since MODs are multichannel.  It would seem for an
> > interpreter to use the 8 channel scheme that could play either 
muisic
> > or sound it would have to support 8 multi-channel channels.

> This is a good point. Yes, it would mean that. Or not supporting MOD,
> which would be a shame. It may be possible to do similar to what I
> believe Glk does, and be able to create and destroy channels at will,
> with the terp branching or something if it can't be done, but this
> should be under the game writer's control, not handled automatically 
by
> the terp.

A clever use of sound_data before and after a call to a new sound 
would let the author know if a specific sound was stopped because you 
ran
out of channels.

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Tue Dec 11 21:38:19 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 11 Dec 2001 01:00:46 -0500
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk>
Message-Id: <6B96A324-EDFC-11D5-99A7-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

On Monday, December 10, 2001, at 07:43 AM, Kevin Bracey wrote:
>

> @split_window
> -------------
> In Version 6, the Standard states that the cursor remains in the same
> absolute position. This is an extension to the Z-machine, as this rule 
> is not
> followed by Infocom's own interpreters, which keep the same 
> window-relative
> position. The Standard behaviour more closely mimics Version 5's
> split_window.

Does this apply to move_window as well?  "moments" appears to assume 
that moving a window maintains the cursor absolute position, above and 
beyond a split.  I'm fairly sure the original Infocom games expect the 
cursor to move with the window.


</x-flowed>
From ???@??? Tue Dec 11 21:37:59 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Lucian P. Smith" <lpsmith@bioc.rice.edu>
Message-Id: <200112101531.JAA09955@heme.bioc.rice.edu>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
To: z-machine@mail.gmd.de
Date: Mon, 10 Dec 2001 09:31:54 -0600 (CST)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS snapshot-20010714
Sender: owner-z-machine@gmd.de
Precedence: bulk


Kevin writes:
> 
> In message <20011210153713.A8805@igloo.df.lth.se>
>           Magnus Olsson <mol@df.lth.se> wrote:
> 
> > > The "repeats" parameter in Version 5 indicates the total number of times
> > > to play the sound, not the number of times to repeat it after the first
> > > play. Setting repeats to zero in V5 is illegal - it is suggested that
> > > interpreters treat this as a request to play the sound once, and maybe
> > > issue a warning.
> > 
> > I seem to recall from the discussion on r.a.i-f that there are games
> > around that set repeats to zero, so perhaps interpreters shouldn't treat
> > it as an error but as equivalent to repeats == 1?
> 
> That's what it suggests, but endorsing such usage would (IMO) be a rather
> pointless change to the Standard. I'm not sure whether Infocom's interpreters
> would handle repeats = 0, so let's nip it in the bud. How many games actually
> do this? There's only MooT, I think. 

What if, as a logical extension, repeats=0 loaded up the sound but didn't
play it?  While not useful in a real game, it might be useful for testing,
and would be intuitive for game authors when coding.

This would kill MooT, of course, which might be sufficient cause to not do
it this way in and of itself.  Is a new version being released that fixes
this?

-Lucian

(also, if repeats is -N, it should play it backwards N times ;-)


From ???@??? Tue Dec 11 23:15:33 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 11 Dec 2001 10:07:13 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <d1e322e74a.kbracey@kbracey.cam.pace.co.uk>
References: <6B96A324-EDFC-11D5-99A7-0050E4A0CE52@speakeasy.net>
In-Reply-To: <6B96A324-EDFC-11D5-99A7-0050E4A0CE52@speakeasy.net>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <6B96A324-EDFC-11D5-99A7-0050E4A0CE52@speakeasy.net>
          "Matthew T. Russotto" <mrussotto@speakeasy.net> wrote:

> 
> On Monday, December 10, 2001, at 07:43 AM, Kevin Bracey wrote:
> >
> 
> > @split_window
> > -------------
> > In Version 6, the Standard states that the cursor remains in the same
> > absolute position.
> 

> Does this apply to move_window as well?  "moments" appears to assume 
> that moving a window maintains the cursor absolute position, above and 
> beyond a split.  I'm fairly sure the original Infocom games expect the 
> cursor to move with the window.

No, it doesn't apply to move_window. Where does moments assume this? I
haven't spotted it.

Internally in Zip 2000, split_window was implemented with
move_window, so I had to add extra code to do the cursor move (only added in
the last few months or so).

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 13 19:27:19 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 11 Dec 2001 10:30:08 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <e8fc24e74a.kbracey@kbracey.cam.pace.co.uk>
References: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk> <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com>
In-Reply-To: <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> > [Blorb support]
>
> This seems like it might be a good idea in the short term, but, well, blorb
> is not part of the Z-Machine. The Z-Machine games will run just fine
> without this, and blorb may well be replaced at any time. I think blorb
> should be supported by terps, but I don't think terps should have to
> support it. Like Quetzal.

I can see that what you say makes sense from an abstract point of view - the
Z-machine doesn't dictate what format its resources are in.

But there were two reasons for us deciding to put this in.

The first was that a modern sound/graphic capable interpreter that doesn't
use Blorb is about as useful as a chocolate teapot, or a Glulx interpreter
that doesn't support Glk. Look at WinFrotz for example. Standard 1.0, V6, but
no Blorb support, so of no practical use for multimedia. The hope was to
reduce user confusion, by tying Blorb into the main Standard.

Second was that if people are going to have Blorb-packaged games, it would
help if even non-multimedia interpreters could run the Z-code out of a Blorb
file, eventually (maybe) eliminating the need for the Z-code to be supplied
separately as well.

My hope would be that Blorb is going to be here to stay as long as the
Z-machine, if not longer, given its use in Glk.

What do other people think?


> I don't like this. I've never liked blorb's idea of music and sound effects
> in seperate channels. I don't think blorb is terribly fond of blorb's idea
> of music and sound effects in seperate channels. It says, in that spec:
> 
> This is an actual variance in the behavior of the Z-machine, and worse, a
> variance which depends on data format. (One sound will either stop another,
> or not, depending on whether the sound is stored in AIFF or MOD format.) We
> apologize for the ugliness.

But it is a three-year old standard that is already supported by a number
of interpreters (albeit small). To revoke it would cause compatibility
problems, as game authors would need to code need one set of behaviour for
Standard 1.0 terps, and another for Standard 1.1 terps.


> So. Eight channels, numbered 0 to 7. The default channel is 0. set_channel
> channel-number sets the current channel to channel-number. sound_effect
> works exactly as before, except only for the sound on the current channel.
> If the current channel is 1, and there's an AIFF playing on channel 1, and
> I tell sound_effect to play a MOD, it interupts the AIFF, but leaves all
> sounds on other channels going.

I think this ends up being too complicated in practice. You're thinking of 8
channels, with each sound being equivalent. But they're not. On my system
MODs and SONGs take 4 physical channels. AIFFs take 1, but when I upgrade Zip
2000 to support stereo AIFFs, they would take 2. So playing a stereo AIFF
could knock out two mono ones!

In addition, my MOD player will happily play one tune, but not two. But I
could play up to 8 AIFFs. The only way I could provide equivalence in
Zip 2000 would be to reduce it to the lowest common denominator, and say
that only one channel was available. With the original proposal, I could
supply 1 music channel, 1 beep channel, and up to three effects channels
(depending on stereo).

So I don't think we can in practice provide the equivalence of sound types
that you require. You can find out when channels have run out, by using
sound_data to check whether an earlier sound is still playing.

Maybe other interpreter authors could give a view.


> With this scheme, the bit in the header to check if music is supported
> would not really be needed, because the terp does not need to know the
> difference between music and sound, and can always check if any particular
> sound is playable with sound_data.

That's true actually. But it's also true of pictures to some extent. I think
it's a useful convenience to have global bits that can be checked. What
do others think?

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 13 19:27:20 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 11 Dec 2001 10:35:50 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <a08225e74a.kbracey@kbracey.cam.pace.co.uk>
References: <3C150A61.28621.3CD862@localhost>
In-Reply-To: <3C150A61.28621.3CD862@localhost>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <3C150A61.28621.3CD862@localhost>
          "Jason C Penney" <jpenney@jczorkmid.net> wrote:

> Fillmore sent a message across the ether on 10 Dec 2001 (20:51) stating:
> 
> > True, but I still think all sounds should just be sounds, not music or
> > effects.  
> 
> If we do that then there is no good way for an interpreter that 
> supports only AIFFs and doesn't support MOD to signal this to the 
> game.  Then the interpreter has to just claim it does not support 
> sound, or the author is in a worse situation, and has to guess.

Of course, it would be a lot better if everyone supported MOD+SONG. But the
Blorb spec does say that it is permitted to not handle music. It's not
permitted to handle MOD but not SONG though.

> What if @sound_data returned 3 words?  The third of which tells you 
> how many channels of that type of sound remain?

Tricky, given the mono/stereo problem. Ah, yes. More simply, just have
an indicator which says whether the interpreter could play the specified
sound without interrupting any ongoing sounds. Simple yes/no. That would
allow the author to ensure that an (unimportant) new sound doesn't
interrupt an earlier one, which isn't currently covered. Great.
Or maybe it could give the resource number of the sound which would be
knocked out. Even better.

You might want to know the absolute number of channels up front if you
were about to attempt to play some chords, but that doesn't seem likely,
given that we don't provide a pitch parameter. And if you wanted to play
tunes, you'd use SONG.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 13 19:27:22 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 11 Dec 2001 13:55:16 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <20011211135516.A15169@igloo.df.lth.se>
References: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk> <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com> <e8fc24e74a.kbracey@kbracey.cam.pace.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <e8fc24e74a.kbracey@kbracey.cam.pace.co.uk>; from kevin.bracey@pace.co.uk on Tue, Dec 11, 2001 at 10:30:08AM +0000
Sender: owner-z-machine@gmd.de
Precedence: bulk


On Tue, Dec 11, 2001 at 10:30:08AM +0000, Kevin Bracey wrote:
> In message <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com>
>           "Fillmore" <Noslwop@hotmail.com> wrote:
> 
> > > [Blorb support]
> >
> > This seems like it might be a good idea in the short term, but, well, blorb
> > is not part of the Z-Machine. The Z-Machine games will run just fine
> > without this, and blorb may well be replaced at any time. I think blorb
> > should be supported by terps, but I don't think terps should have to
> > support it. Like Quetzal.
> 
> I can see that what you say makes sense from an abstract point of view - the
> Z-machine doesn't dictate what format its resources are in.
> 
> But there were two reasons for us deciding to put this in.
> 
> The first was that a modern sound/graphic capable interpreter that doesn't
> use Blorb is about as useful as a chocolate teapot, or a Glulx interpreter
> that doesn't support Glk. Look at WinFrotz for example. Standard 1.0, V6, but
> no Blorb support, so of no practical use for multimedia. The hope was to
> reduce user confusion, by tying Blorb into the main Standard.

I'm with Kevin on this one, for the following reason:

Blorb is an existing standard that is *being used* (by the Glulx
crowd) for writing games today. This means that there are tools for
creating Blorb files, a knowledge of how the standard works, people
used to working with it.

 So it would be very practical to have Z-machine terps support
the same standard. It would of course be very different if Blorb was
just a proposed standard - in that case, the Z-machine could just set
its own standard and hope that others would follow.

This also means that it is very unlikely that Blorb may be replaced at
any time - that would break a number of existing games. Amended or
modified, yes, but not just replaced like that.


-- 
Magnus Olsson (mol@df.lth.se, mol@pobox.com)
------    http://www.pobox.com/~mol   ------


From ???@??? Thu Dec 13 19:27:24 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <3C150A61.28621.3CD862@localhost>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Tue, 11 Dec 2001 13:02:33 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE31yfcGbSR7uGEazBN0001c210@hotmail.com>
X-OriginalArrivalTime: 11 Dec 2001 12:56:54.0745 (UTC) FILETIME=[4F455C90:01C18243]
Sender: owner-z-machine@gmd.de
Precedence: bulk



----- Original Message ----- 
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: <z-machine@gmd.de>
Sent: Tuesday, December 11, 2001 12:17 AM
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> Fillmore sent a message across the ether on 10 Dec 2001 (20:51) stating:
> 
> > True, but I still think all sounds should just be sounds, not music or
> > effects.
> 
> If we do that then there is no good way for an interpreter that
> supports only AIFFs and doesn't support MOD to signal this to the
> game.  Then the interpreter has to just claim it does not support
> sound, or the author is in a worse situation, and has to guess.

Yes there is. According to the description of sound_data, 'If the
sound number is valid, and the sound is of a type supported by the
intepreter, a branch occurs'. 
It may seem like a bad idea to require the game author to check 
each file, or just one of each type of file, but what if the 
blorb spec is updated with new file formats? A game could come
out that uses them before all the interpreter writers have upgraded
their games, so checking individual files is good practice anyway.
And if something like mp3 comes out, it's quite likely people will
use that for music, because MOD may be too much effort to get working
properly. But it might again be used for sampled speech, so where
would it go? The answer, of course, is in sampled effects, but the
point is, the difference between music and effects is not real. Either
can, and quite possibly will, be used for the other.

> > This is the way the Z-Machine does things, though. As it says in the
> > current spec, the Z-Machine has 'a willingness to constrain maximum as
> > well as minimum levels of performance'. This way, we have 0, 1 or 8
> > channels, depending on the capabilities of the terp.
> 
> This would give us music interrupting effects, which is incompatible
> with
> Spec 1.0 + Blorb 1.1.

It's incompatible with Blorb, sure, but that part of the Blorb spec was
only put there because the Z-Machine could not by itself handle multiple
channels. I'm proposing that if we are going to update the Z-Machine,
we make it use channels properly, and ignore that bit of the Blorb spec.
> 
> > When writing a game, I want to know for a fact precisely how many
> > channels I have, and to be able to do anything to any of them.
> 
> What if @sound_data returned 3 words?  The third of which tells you
> how many channels of that type of sound remain?
> 
> > > I can imagine an implimentation where a MOD/SONG could use up
> multiple
> > > channels since MODs are multichannel.  It would seem for an
> > > interpreter to use the 8 channel scheme that could play either
> muisic
> > > or sound it would have to support 8 multi-channel channels.
> 
> > This is a good point. Yes, it would mean that. Or not supporting MOD,
> > which would be a shame. It may be possible to do similar to what I
> > believe Glk does, and be able to create and destroy channels at will,
> > with the terp branching or something if it can't be done, but this
> > should be under the game writer's control, not handled automatically
> by
> > the terp.
> 
> A clever use of sound_data before and after a call to a new sound
> would let the author know if a specific sound was stopped because you
> ran
> out of channels.

Yes, it would. I think, though, that letting the game author set channels
himself is still a better way to go. What if the terp has as many channels
as it likes, with four recommended as a minimum. 
@set_channel channel ->(result) sets the channel to channel, and returns 
true if successful. If the channel number is too high, it returns false,
and the game author knows he's run out of space.
And @set_channel -1 -> (result) can return the number of the current sound
channel. 

This lets the game author have pretty complete control over how he plays
the sounds, and lets the terp decide how many channels it can handle. And
it cuts out the whole division between music and sound, which I don't think
is a good idea.

--
Fillmore


From ???@??? Thu Dec 13 19:27:25 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <3C150A61.28621.3CD862@localhost> <a08225e74a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Tue, 11 Dec 2001 13:11:32 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE21Y486qCsmriiEIJM0000518f@hotmail.com>
X-OriginalArrivalTime: 11 Dec 2001 13:05:47.0517 (UTC) FILETIME=[8CD3EAD0:01C18244]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
To: <z-machine@gmd.de>
Sent: Tuesday, December 11, 2001 10:35 AM
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> In message <3C150A61.28621.3CD862@localhost>
>           "Jason C Penney" <jpenney@jczorkmid.net> wrote:
>
> > Fillmore sent a message across the ether on 10 Dec 2001 (20:51) stating:
> >
> > > True, but I still think all sounds should just be sounds, not music or
> > > effects.
> >
> > If we do that then there is no good way for an interpreter that
> > supports only AIFFs and doesn't support MOD to signal this to the
> > game.  Then the interpreter has to just claim it does not support
> > sound, or the author is in a worse situation, and has to guess.
>
> Of course, it would be a lot better if everyone supported MOD+SONG. But
the
> Blorb spec does say that it is permitted to not handle music. It's not
> permitted to handle MOD but not SONG though.

After a quick look through the Blorb spec, I can't see anything which
says you are allowed to not support any file format. But, I think
terps that handle MOD but not SONG will happen. SONG looks like it
takes quite a bit of extra programming to get working.

> > What if @sound_data returned 3 words?  The third of which tells you
> > how many channels of that type of sound remain?
>
> Tricky, given the mono/stereo problem. Ah, yes. More simply, just have
> an indicator which says whether the interpreter could play the specified
> sound without interrupting any ongoing sounds. Simple yes/no. That would
> allow the author to ensure that an (unimportant) new sound doesn't
> interrupt an earlier one, which isn't currently covered. Great.
> Or maybe it could give the resource number of the sound which would be
> knocked out. Even better.
>
> You might want to know the absolute number of channels up front if you
> were about to attempt to play some chords, but that doesn't seem likely,
> given that we don't provide a pitch parameter. And if you wanted to play
> tunes, you'd use SONG.

One big problem I've just seen with the terp handling all the channels.
Your spec mentions:


From ???@??? Thu Dec 13 19:27:26 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-eGroups-Return: z-machine-owner@mail.gmd.de
X-Yahoo-MsgId: <mta600.mail.yahoo.com.1008076865.91661.0001>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Tue, 11 Dec 2001 08:18:27 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C15C153.1967.1E82DE4@localhost>
In-reply-to: <OE21Y486qCsmriiEIJM0000518f@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Fillmore sent a message across the ether on 11 Dec 2001 (13:02) stating:

> > This would give us music interrupting effects, which is incompatible
> > with
> > Spec 1.0 + Blorb 1.1.
> 
> It's incompatible with Blorb, sure, but that part of the Blorb spec 
was
> only put there because the Z-Machine could not by itself handle 
multiple
> channels. I'm proposing that if we are going to update the Z-Machine,
> we make it use channels properly, and ignore that bit of the Blorb 
spec.

The issue to me is that people are now assuming that things work the 
way the Blorb spec states.  We don't want to break existing z-code 
programs, do we?

>  I think, though, that letting the game author set channels himself is
> still a better way to go. What if the terp has as many channels as it
> likes, with four recommended as a minimum. @set_channel channel
> ->(result) sets the channel to channel, and returns true if
> successful. If the channel number is too high, it returns false, and
> the game author knows he's run out of space. And @set_channel -1 ->
> (result) can return the number of the current sound channel. 
> 
> This lets the game author have pretty complete control over how he 
plays
> the sounds, and lets the terp decide how many channels it can handle. 
And
> it cuts out the whole division between music and sound, which I don't 
think
> is a good idea.

This leaves out the possibility of somebody writing an interpreter 
that supports (for instance) 8 channels total, but when a MOD is 
playing it uses 4 of them. So you could play 2 MODs, or 8 mono 
effects, or 1 stereo effect + 2 mono effects + 1 MOD, etc.

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor



From ???@??? Thu Dec 13 19:27:27 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 11 Dec 2001 13:25:43 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <3b1035e74a.kbracey@kbracey.cam.pace.co.uk>
References: <a08225e74a.kbracey@kbracey.cam.pace.co.uk> <OE21Y486qCsmriiEIJM0000518f@hotmail.com>
In-Reply-To: <OE21Y486qCsmriiEIJM0000518f@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE21Y486qCsmriiEIJM0000518f@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> > Of course, it would be a lot better if everyone supported MOD+SONG. But
> the
> > Blorb spec does say that it is permitted to not handle music. It's not
> > permitted to handle MOD but not SONG though.
> 
> After a quick look through the Blorb spec, I can't see anything which
> says you are allowed to not support any file format.

The only suggestion of lack of support is for music - there's a whole section
discussing what happens if an interpreter supports effects but not music.

It's also possible an interpreter won't support JPEG, simply because it
wasn't in the original Blorb spec - that was the case for a long time with
Zip 2000.

> But, I think
> terps that handle MOD but not SONG will happen. SONG looks like it
> takes quite a bit of extra programming to get working.

Compared to getting MOD working from scratch, doing SONG as well is
absolutely trivial, and that's why Zarf originally included it. But if you're
using an external MOD player that does almost all the work, the extra work to
do SONG suddenly looks big. It's only a question of perspective.

Doing the minimal implementation - creating a new MOD file from the SONG +
AIFF data - isn't at all hard. Example code is in Zip 2000, although it
doesn't actually create a complete MOD file - it tweaks around with the SONG
data to make it a valid MOD with no samples, passes that to the MOD player,
and then registers the AIFFs, converted to 8-bit, with the MOD player. That
took me two days, but only because I decided to get clever and create a
sample cache.

On the other hand, Zarf seems to be shying away from SONG, which I think is a
shame, because it covers the basic case of playing a number of tunes with
common samples, which can't be done with just AIFF, due to lack of pitch
parameters.

And I believe Nitfol doesn't support SONG, so that's the first MOD-playing
terp to fall at the fence.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 13 19:27:28 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <3C15C0AC.7829.1E5A166@localhost>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Tue, 11 Dec 2001 13:32:48 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com>
X-OriginalArrivalTime: 11 Dec 2001 13:27:03.0028 (UTC) FILETIME=[85177340:01C18247]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message ----- 
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: "Fillmore" <Noslwop@hotmail.com>
Sent: Tuesday, December 11, 2001 1:15 PM
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> Fillmore sent a message across the ether on 11 Dec 2001 (13:02) stating:
> 
> > > This would give us music interrupting effects, which is incompatible
> > > with
> > > Spec 1.0 + Blorb 1.1.
> >
> > It's incompatible with Blorb, sure, but that part of the Blorb spec
> was
> > only put there because the Z-Machine could not by itself handle
> multiple
> > channels. I'm proposing that if we are going to update the Z-Machine,
> > we make it use channels properly, and ignore that bit of the Blorb
> spec.
> 
> The issue to me is that people are now assuming that things work the way
> the Blorb spec states.  We don't want to break existing z-code programs,
> do we?

Because there are just SO MANY z-code program that use blorb right now,
aren't there?

> >  I think, though, that letting the game author set channels himself is
> > still a better way to go. What if the terp has as many channels as it
> > likes, with four recommended as a minimum. @set_channel channel
> > ->(result) sets the channel to channel, and returns true if
> > successful. If the channel number is too high, it returns false, and
> > the game author knows he's run out of space. And @set_channel -1 ->
> > (result) can return the number of the current sound channel.
> >
> > This lets the game author have pretty complete control over how he
> plays
> > the sounds, and lets the terp decide how many channels it can handle.
> And
> > it cuts out the whole division between music and sound, which I don't
> think
> > is a good idea.
> 
> This leaves out the possibility of somebody writing an interpreter that
> supports (for instance) 8 channels total, but when a MOD is playing it
> uses 4 of them. So you could play 2 MODs, or 8 mono effects, or 1 stereo
> effect + 2 mono effects + 1 MOD, etc.

Not really. If you have 8 channels, you play 1 MOD on channel 0, then
another on channel 1, then you try and set the channel to channel 2,
it fails. The terp probably knows how many channels altogether it can
handle, so any number over that it fails anyway. Within that many 
channels, the game writer can be sensible and use up channels in
order, reusing ones that no longer have sound playing, or they can
ask for new channels all over the place. This would lead to not
being able to play on channel 2 when you're already playing on
channel 7 and 8, but it would work.

-- 
Fillmore


From ???@??? Thu Dec 13 19:27:31 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 11 Dec 2001 13:57:39 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <c9fc37e74a.kbracey@kbracey.cam.pace.co.uk>
References: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com>
In-Reply-To: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> Because there are just SO MANY z-code program that use blorb right now,
> aren't there?

It's not just that, there are working Blorb interpreters out there too. Do
we suddenly write those off? And I know a number of Blorb games are in
development.

> Not really. If you have 8 channels, you play 1 MOD on channel 0, then
> another on channel 1, then you try and set the channel to channel 2,
> it fails. The terp probably knows how many channels altogether it can
> handle, so any number over that it fails anyway. Within that many 
> channels, the game writer can be sensible and use up channels in
> order, reusing ones that no longer have sound playing, or they can
> ask for new channels all over the place. This would lead to not
> being able to play on channel 2 when you're already playing on
> channel 7 and 8, but it would work.

Okay, that makes sense, but doesn't it put us back to square one in terms of
functionality? If you have 8 channels, but you can't tell how many you can
use at once, then you're back to the original "arbitrary number of channels"
suggestion. The difference is that you get to have a say as to what plays
with what.

But I think that the original design, plus the "does it fit?" sound_data
suggestion, would allow a library to selectively knock out sounds itself,
which would make it possible for a library to present a channel assignment
API in software. Jason, do you agree? Pop it into V6Lib, there's a good chap.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 13 19:27:32 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com> <c9fc37e74a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Tue, 11 Dec 2001 14:27:27 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE407MzPOL7gyHdABNz00018efc@hotmail.com>
X-OriginalArrivalTime: 11 Dec 2001 14:21:42.0714 (UTC) FILETIME=[27EFD1A0:01C1824F]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
To: <z-machine@gmd.de>
Sent: Tuesday, December 11, 2001 1:57 PM
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> In message <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com>
>           "Fillmore" <Noslwop@hotmail.com> wrote:
>
> > Because there are just SO MANY z-code program that use blorb right now,
> > aren't there?
>
> It's not just that, there are working Blorb interpreters out there too. Do
> we suddenly write those off? And I know a number of Blorb games are in
> development.

Don't write them off, change them. There's not going to be much difference
in the difficulty between adding my scheme or yours. As for games in
development, well, I'm not sure. I admit it'd be a pain, but I think
it's worth it.

> > Not really. If you have 8 channels, you play 1 MOD on channel 0, then
> > another on channel 1, then you try and set the channel to channel 2,
> > it fails. The terp probably knows how many channels altogether it can
> > handle, so any number over that it fails anyway. Within that many
> > channels, the game writer can be sensible and use up channels in
> > order, reusing ones that no longer have sound playing, or they can
> > ask for new channels all over the place. This would lead to not
> > being able to play on channel 2 when you're already playing on
> > channel 7 and 8, but it would work.
>
> Okay, that makes sense, but doesn't it put us back to square one in terms
of
> functionality? If you have 8 channels, but you can't tell how many you can
> use at once, then you're back to the original "arbitrary number of
channels"
> suggestion. The difference is that you get to have a say as to what plays
> with what.

But you can't tell how many channels you have in your scheme, either. So,
yeah, the difference is, I have more control. This is what I want.

> But I think that the original design, plus the "does it fit?" sound_data
> suggestion, would allow a library to selectively knock out sounds itself,
> which would make it possible for a library to present a channel assignment
> API in software. Jason, do you agree? Pop it into V6Lib, there's a good
chap.

I'm not sure I follow that.

Okay, here's a question. Working with your sound support, suppose I have
a game which is just a maze. There are two other people in the maze, and
I want to have the sound of footsteps play if they're near enough. It's
the same sound for both people, but with different channels. So, if one
is one room away, and the other is three rooms away, the same sound is
playing twice, once at full volume, and once at half volume.

Then the one near me walk away a room. I need to stop the sound, and
start it again at a different volume. How do I make sure I stop the right
sound? I haven't got any control over the channels, so stopping a sound
number might stop either one, probably depending on which one was started
last.

This isn't a very good game, I'll admit, but it's just to illustrate a
point.
Sometimes, I need to have control over what happens in the channels myself.

--
Fillmore


From ???@??? Thu Dec 13 19:27:34 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 11 Dec 2001 15:19:08 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <40723fe74a.kbracey@kbracey.cam.pace.co.uk>
References: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com> <c9fc37e74a.kbracey@kbracey.cam.pace.co.uk> <OE407MzPOL7gyHdABNz00018efc@hotmail.com>
In-Reply-To: <OE407MzPOL7gyHdABNz00018efc@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE407MzPOL7gyHdABNz00018efc@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> Okay, here's a question. Working with your sound support, suppose I have
> a game which is just a maze. There are two other people in the maze, and
> I want to have the sound of footsteps play if they're near enough. It's
> the same sound for both people, but with different channels. So, if one
> is one room away, and the other is three rooms away, the same sound is
> playing twice, once at full volume, and once at half volume.
> 
> Then the one near me walk away a room. I need to stop the sound, and
> start it again at a different volume. How do I make sure I stop the right
> sound? I haven't got any control over the channels, so stopping a sound
> number might stop either one, probably depending on which one was started
> last.

A good solution would be for the two people to have different footsteps (as
indeed they would in real life), then they have separate resource numbers, so
can be easily controlled. As long as you don't play the same sound multiple
times, you have straightforward mapping between resource number and virtual
channel.

So the problem comes down to handling the _same_ sound playing multiple
times. One solution would be to have the same sound occur multiple times in
the Blorb file, by having the resource index point at the same chunk twice.
That's not allowed though, so you'd have to include the sound twice. Yuck.

The other solution would be to stop all instances of that sound, then restart
as many as you need. Not good for continuity in a long loop situtation, but
you have the same problem if you want to reduce the volume of a playing
sound.

There is a point there in that I don't think we specified in the draft
whether @sound_effect <n> 3 stops all instances of sound n from playing.
Maybe we should actually put a rule in that says you can't play the same
sound more than once? Probably a bit strong.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 13 19:27:35 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com> <c9fc37e74a.kbracey@kbracey.cam.pace.co.uk> <OE407MzPOL7gyHdABNz00018efc@hotmail.com> <40723fe74a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Tue, 11 Dec 2001 18:17:08 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE21plWdtaGzW3yZty1000054d3@hotmail.com>
X-OriginalArrivalTime: 11 Dec 2001 18:11:23.0626 (UTC) FILETIME=[3E001CA0:01C1826F]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
To: <z-machine@gmd.de>
Sent: Tuesday, December 11, 2001 3:19 PM
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> In message <OE407MzPOL7gyHdABNz00018efc@hotmail.com>
>           "Fillmore" <Noslwop@hotmail.com> wrote:
>
> > Okay, here's a question. Working with your sound support, suppose I have
> > a game which is just a maze. There are two other people in the maze, and
> > I want to have the sound of footsteps play if they're near enough. It's
> > the same sound for both people, but with different channels. So, if one
> > is one room away, and the other is three rooms away, the same sound is
> > playing twice, once at full volume, and once at half volume.
> >
> > Then the one near me walk away a room. I need to stop the sound, and
> > start it again at a different volume. How do I make sure I stop the
right
> > sound? I haven't got any control over the channels, so stopping a sound
> > number might stop either one, probably depending on which one was
started
> > last.
>
> A good solution would be for the two people to have different footsteps
(as
> indeed they would in real life), then they have separate resource numbers,
so
> can be easily controlled. As long as you don't play the same sound
multiple
> times, you have straightforward mapping between resource number and
virtual
> channel.

Yeah, but what if I go insane and have ten people? Ten different samples
just
for footsteps seems a bit much.

> So the problem comes down to handling the _same_ sound playing multiple
> times. One solution would be to have the same sound occur multiple times
in
> the Blorb file, by having the resource index point at the same chunk
twice.
> That's not allowed though, so you'd have to include the sound twice. Yuck.
>
> The other solution would be to stop all instances of that sound, then
restart
> as many as you need. Not good for continuity in a long loop situtation,
but
> you have the same problem if you want to reduce the volume of a playing
> sound.

Yeah, but with one sound, you wait until it has finished playing, and use
the
routine that's called to stop it looping, and restart it at a different
volume.
If all instances of the sound are stopped, some of them may well be in the
middle
of playing, and this is a problem you don't have if you want to reduce the
volume
of a playing sound.

> There is a point there in that I don't think we specified in the draft
> whether @sound_effect <n> 3 stops all instances of sound n from playing.
> Maybe we should actually put a rule in that says you can't play the same
> sound more than once? Probably a bit strong.

And my way of handling channels would fix this. It's pretty much the same as
yours, with the terp deciding how many channels exist, and whether or not a
new channel is available, it just lets the game writer decide what to do if
it isn't, and have better control over stopping currently playing sounds.

--
Fillmore


From ???@??? Thu Dec 13 19:27:37 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk> <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com> <e8fc24e74a.kbracey@kbracey.cam.pace.co.uk> <20011211135516.A15169@igloo.df.lth.se>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Tue, 11 Dec 2001 18:34:08 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE479QtpfTYSl1q4gto0000fd50@hotmail.com>
X-OriginalArrivalTime: 11 Dec 2001 18:28:27.0375 (UTC) FILETIME=[A033CFF0:01C18271]
Sender: owner-z-machine@gmd.de
Precedence: bulk



----- Original Message -----
From: "Magnus Olsson" <mol@df.lth.se>
To: <z-machine@gmd.de>
Sent: Tuesday, December 11, 2001 12:55 PM
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> On Tue, Dec 11, 2001 at 10:30:08AM +0000, Kevin Bracey wrote:
> > In message <OE33PkQTGpaoG1VRIjn0000bbec@hotmail.com>
> >           "Fillmore" <Noslwop@hotmail.com> wrote:
> >
> > > > [Blorb support]
> > >
> > > This seems like it might be a good idea in the short term, but, well,
blorb
> > > is not part of the Z-Machine. The Z-Machine games will run just fine
> > > without this, and blorb may well be replaced at any time. I think
blorb
> > > should be supported by terps, but I don't think terps should have to
> > > support it. Like Quetzal.
> >
> > I can see that what you say makes sense from an abstract point of view -
the
> > Z-machine doesn't dictate what format its resources are in.
> >
> > But there were two reasons for us deciding to put this in.
> >
> > The first was that a modern sound/graphic capable interpreter that
doesn't
> > use Blorb is about as useful as a chocolate teapot, or a Glulx
interpreter
> > that doesn't support Glk. Look at WinFrotz for example. Standard 1.0,
V6, but
> > no Blorb support, so of no practical use for multimedia. The hope was to
> > reduce user confusion, by tying Blorb into the main Standard.
>
> I'm with Kevin on this one, for the following reason:
>
> Blorb is an existing standard that is *being used* (by the Glulx
> crowd) for writing games today. This means that there are tools for
> creating Blorb files, a knowledge of how the standard works, people
> used to working with it.

Yeah, and I think interpreters should support Blorb. I just don't think
they should have to. I think they should support Quetzal, too, but they
shouldn't have to. If it's not useful, bring out interpreters that *are*
useful, and people will use them. Enforcing this rule is more likely,
in my opinion, to make terps not claim 1.1 compliance than to make
them work with blorb.

>  So it would be very practical to have Z-machine terps support
> the same standard. It would of course be very different if Blorb was
> just a proposed standard - in that case, the Z-machine could just set
> its own standard and hope that others would follow.

I agree, I just don't think putting this requirement in the spec is the
way to get terp writers to agree to this. There are still plenty of terps
that don't conform to standard 1.0. Probably more don't than do. They do
as much as the writers have bothered to implement. Saying 'If you want to
be 1.1 compliant you have to' is not going to convince these people. The
way to get Blorb implemented is the same as it was for the past four years.
Write games that use it, and bug terp writers to implement it. I believe
this will happen with or without this being part of the spec.

--
Fillmore


From ???@??? Thu Dec 13 19:27:38 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.13.224]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Tue, 11 Dec 2001 13:30:48 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F145y9tMTF4ia5wAz8A00006f05@hotmail.com>
X-OriginalArrivalTime: 11 Dec 2001 18:30:49.0363 (UTC) FILETIME=[F4D57630:01C18271]
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
>From: Kevin Bracey <kevin.bracey@pace.co.uk>
>To: z-machine@gmd.de
>Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
>Date: Tue, 11 Dec 2001 13:25:43 GMT
>

>Compared to getting MOD working from scratch, doing SONG as well is
>absolutely trivial, and that's why Zarf originally included it. But if 
>you're
>using an external MOD player that does almost all the work, the extra work 
>to
>do SONG suddenly looks big. It's only a question of perspective.
>
>There lies the rub; virtually no one has implemented MOD from scratch; for 
>most glk porters, if it came down to "implement mod from scratch or don't 
>support it", the answer is "don't support it," end of story.  Sure, if you 
>were writing your own mod player, you could easily support song. But no one 
>does that. (excepting you, of course)

>And I believe Nitfol doesn't support SONG, so that's the first MOD-playing
>terp to fall at the fence.
>

Actually, Nitfol doesn't care what format the sound is in. However, no 
existing glk implementation (except maybe mac glk, but I'm not sure) 
supports it on Nitfol's behalf.

Sidebar: as far as I know, there is no simple way for a glk-based Z-machine 
to comnply with the blorb specification's styatements about how the 
Z-machine should handle sound; it suggests that sound effects and music be 
played in separate channels, but glk gives no mechanism that I know of for 
determining whether a numbered blorb resource is sound or music...

>--
>Kevin Bracey
>http://www.bracey-griffith.freeserve.co.uk/Zip2000/


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


</x-flowed>
From ???@??? Thu Dec 13 19:27:43 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
To: kevin.bracey@pace.co.uk (Kevin Bracey)
Date: Tue, 11 Dec 2001 19:57:20 +0000 (GMT)
Cc: z-machine@gmd.de
In-Reply-To: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk> from "Kevin Bracey" at Dec 10, 2001 12:43:25 
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16Dt1k-0000LX-00@seasip.demon.co.uk>
From: John Elliott <jce@seasip.demon.co.uk>
Sender: owner-z-machine@gmd.de
Precedence: bulk


: @set_font
: ---------
: EXT:4 4 6 set_font font window -> (result)
: 
: In Version 6, set_font has an optional window parameter, as for set_colour.
: This was part of the original Infocom design, but omitted by earlier
: Standards. It is reinstated here, as it is useful to be able to measure
: a font that is about to be used in another window, so that window can be
: sized before attempting to place the cursor in it.

  Do any known Infocom games use font 2 (the 'picture' font)? If they don't, 
it might be worth stating that a 1.1 standard interpreter must return 0 if
asked for this font. 
  Rationale: If a game wants to check that font 3 (the character graphics 
font) exists, then it checks the value returned by @set_font 3. If this is
nonzero, it assumes the font exists. However, some interpreters return 
nonzero for any font, whether or not they can display it (eg: JZIP v2.0.1g). 
So in order to check that font 3 is available, you have to do a little dance 
like this:

    font3_available = 0;

    @set_font 2 -> f2;			! Ought to fail
    @set_font 3 -> f3;			! May or may not fail

    if (f2 == 0 && f3 ~= 0) font3_available = 1;

    if (f3 ~= 0) @set_font f3 -> f3;       ! Reverse any font changes that 
    if (f2 ~= 0) @set_font f2 -> f2;       ! succeeded.


  and obviously an interpreter that really did support font 2 would
cause this check to fail.

-- 
John Elliott


From ???@??? Thu Dec 13 19:29:11 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Tue, 11 Dec 2001 18:59:24 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C16578C.17937.1A3CD8@localhost>
References: <ab5aade64a.kbracey@kbracey.cam.pace.co.uk> from "Kevin Bracey" at Dec 10, 2001 12:43:25 
In-reply-to: <E16Dt1k-0000LX-00@seasip.demon.co.uk>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


John Elliott sent a message across the ether on 11 Dec 2001 (19:57) 
stating:

> : @set_font
> : ---------
> : EXT:4 4 6 set_font font window -> (result)
> : 
> : In Version 6, set_font has an optional window parameter, as for 
set_colour.
> : This was part of the original Infocom design, but omitted by earlier
> : Standards. It is reinstated here, as it is useful to be able to 
measure
> : a font that is about to be used in another window, so that window 
can be
> : sized before attempting to place the cursor in it.
> 
>   Do any known Infocom games use font 2 (the 'picture' font)? If they 
don't, 
> it might be worth stating that a 1.1 standard interpreter must return 
0 if
> asked for this font. 

I'm fairly certain this is taken care of.  The spec already says it 
needs to return 0 if asked for a font it can't provide.  If an 
interpreter does otherwise it's a bug in the terp, isn't it?

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Thu Dec 13 19:29:12 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Tue, 11 Dec 2001 19:08:08 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C165998.11510.223BF9@localhost>
In-reply-to: <c9fc37e74a.kbracey@kbracey.cam.pace.co.uk>
References: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Kevin Bracey sent a message across the ether on 11 Dec 2001 (13:57) 
stating:

> > Because there are just SO MANY z-code program that use blorb right 
now,
> > aren't there?
 
> It's not just that, there are working Blorb interpreters out there 
too. Do
> we suddenly write those off? And I know a number of Blorb games are in
> development.

Not too many people would be happy to find that something that worked on 
the less capable interpreter (playing one piece of music and one effect 
at the same time) no longer works on the new extra spiffy terp.  To get 
your game to work in the most places you'd need to get it to work in 
both situations.  With our proposal all current games just work in 1.1 
terps because they won't have the extension table, so the "I want 
multiple channels" bit won't be set, so the interpreter won't provide 
more than 1 effect (and optionally 1 music if it can), which is how 
things are today.


> But I think that the original design, plus the "does it fit?" 
sound_data
> suggestion, would allow a library to selectively knock out sounds 
itself,
> which would make it possible for a library to present a channel 
assignment
> API in software. Jason, do you agree? Pop it into V6Lib, there's a 
good chap.

It would cover everything except for multiple instances of the same 
sound.  Currently you can't do that anyway.  I'm not saying you 
shouldn't be able to...

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Thu Dec 13 19:29:22 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 12 Dec 2001 10:06:05 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <469fa6e74a.kbracey@kbracey.cam.pace.co.uk>
References: <F145y9tMTF4ia5wAz8A00006f05@hotmail.com>
In-Reply-To: <F145y9tMTF4ia5wAz8A00006f05@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <F145y9tMTF4ia5wAz8A00006f05@hotmail.com>
          "L. Ross Raszewski" <rraszews@hotmail.com> wrote:

> Sidebar: as far as I know, there is no simple way for a glk-based Z-machine
> to comnply with the blorb specification's styatements about how the 
> Z-machine should handle sound; it suggests that sound effects and music be 
> played in separate channels, but glk gives no mechanism that I know of for 
> determining whether a numbered blorb resource is sound or music...

Right, I wasn't aware of that. But it's all part of the basic truth that the
Glk library isn't flexible enough to implement the Z-machine on top of
properly.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 13 19:29:24 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 12 Dec 2001 11:00:26 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <1099abe74a.kbracey@kbracey.cam.pace.co.uk>
References: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com> <c9fc37e74a.kbracey@kbracey.cam.pace.co.uk> <OE407MzPOL7gyHdABNz00018efc@hotmail.com> 
 <40723fe74a.kbracey@kbracey.cam.pace.co.uk> <OE21plWdtaGzW3yZty1000054d3@hotmail.com>
In-Reply-To: <OE21plWdtaGzW3yZty1000054d3@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE21plWdtaGzW3yZty1000054d3@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
> 
> > In message <OE407MzPOL7gyHdABNz00018efc@hotmail.com>
> >           "Fillmore" <Noslwop@hotmail.com> wrote:
> >
> Yeah, but what if I go insane and have ten people? Ten different samples
> just for footsteps seems a bit much.

Absolutely.

> 
> > So the problem comes down to handling the _same_ sound playing multiple
> > times. One solution would be to have the same sound occur multiple times
> > in the Blorb file, by having the resource index point at the same chunk
> > twice. That's not allowed though, so you'd have to include the sound
> > twice. Yuck.
> >
> > The other solution would be to stop all instances of that sound, then
> > restart as many as you need. Not good for continuity in a long loop
> > situtation, but you have the same problem if you want to reduce the
> > volume of a playing sound.
> 
> Yeah, but with one sound, you wait until it has finished playing, and use
> the routine that's called to stop it looping, and restart it at a different
> volume.

Good point. You would be able to have different callback routines for each
instance of a playing sound in the proposed scheme. So you could do our your
control work in the callback routines - ie choosing whether to change volume
and/or play the sound again. Does that get close to giving you sufficient
control?

> 
> And my way of handling channels would fix this. It's pretty much the same
> as yours, with the terp deciding how many channels exist, and whether or
> not a new channel is available, it just lets the game writer decide what to
> do if it isn't, and have better control over stopping currently playing
> sounds.
> 

Can you come up with a way in which a channel-based system can be backwards
compatible with the current specs?

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 13 19:29:48 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: [z-machine] sound streams and spec 1.1
To: z-machine@gmd.de
Date: Wed, 12 Dec 2001 13:34:17 -0500 (EST)
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20011212183417.633D730805B@fauna.jczorkmid.net>
From: jpenney@jczorkmid.net (Jason Penney)
Sender: owner-z-machine@gmd.de
Precedence: bulk


Hey,

Here's my thought on a backwards compatible version of @sound_stream.

If the 'Game wants multiple streams' bit isn't set then all e
ffects default to stream 0 and all music (if supported) to stream 1.  This is
primaraly provided for backwards compatibility and is depreciated.

How's that?

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Thu Dec 13 19:29:57 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
To: jpenney@jczorkmid.net
Date: Wed, 12 Dec 2001 21:18:55 +0000 (GMT)
Cc: z-machine@gmd.de
In-Reply-To: <3C16578C.17937.1A3CD8@localhost> from "Jason C Penney" at Dec 11, 2001 06:59:24 
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16EGmF-0000IL-00@seasip.demon.co.uk>
From: John Elliott <jce@seasip.demon.co.uk>
Sender: owner-z-machine@gmd.de
Precedence: bulk


: 
: I'm fairly certain this is taken care of.  The spec already says it 
: needs to return 0 if asked for a font it can't provide.  If an 
: interpreter does otherwise it's a bug in the terp, isn't it?

  What I meant was that the interpreter must not provide this 
font (at the moment, the spec just says that it need not provide it).

-- 
John Elliott


From ???@??? Thu Dec 13 19:29:58 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Wed, 12 Dec 2001 18:38:28 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C17A424.28675.111C97@localhost>
References: <3C16578C.17937.1A3CD8@localhost> from "Jason C Penney" at Dec 11, 2001 06:59:24 
In-reply-to: <E16EGmF-0000IL-00@seasip.demon.co.uk>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


John Elliott sent a message across the ether on 12 Dec 2001 (21:18) 
stating:

> : I'm fairly certain this is taken care of.  The spec already says it 
> : needs to return 0 if asked for a font it can't provide.  If an 
> : interpreter does otherwise it's a bug in the terp, isn't it?
> 
>   What I meant was that the interpreter must not provide this 
> font (at the moment, the spec just says that it need not provide it).

I guess I just don't understand what that buys anyone. AFAIK no current 
interpreter provides a font 2.  This should be detectable using 
@set_font. 

If at some later date we decide on some portable font format so people 
can distribute a custom font in a blorb file or something (not saying 
this is likely or a good idea, but it is an option) I imagine that would 
become font 2, and then once interpreters supported this they would 
correctly report that they did provide font 2.

Am I missing the point?

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Thu Dec 13 21:51:50 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp4.ihug.co.nz: Host p50-tnt7.akl.ihug.co.nz [203.173.206.50] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20011213212506.0729a0f0@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 13 Dec 2001 21:48:28 +1300
To: "z-machine mailing list" <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: [z-machine] Re: Z-Machine Standard 1.1 Proposal - 1st attempt
In-Reply-To: <OE49oD5jxRCO06fKn1Q000155ed@hotmail.com>
References: <3C15C0AC.7829.1E5A166@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 13:32 11/12/01 +0000, Fillmore wrote:
 >
 >Not really. If you have 8 channels, you play 1 MOD on channel 0, 

 >then another on channel 1, then you try and set the channel to
 >channel 2, it fails. The terp probably knows how many channels
 >altogether it can handle, so any number over that it fails
 >anyway. Within that many channels, the game writer can be
 >sensible and use up channels in order, reusing ones that no
 >longer have sound playing, or they can ask for new channels
 >all over the place. This would lead to not being able to play
 >on channel 2 when you're already playing on channel 7 and 8,
 >but it would work.

So, you've got MODs playing on channels 1 and 2 (using eight 
physical channels), and no other channels are available.  Then the 
MOD on channel 1 finishes playing, and suddenly you have four free 
channels.  Either they'll push the second MOD (still playing) out 
to channel 5 (breaking sound<->channel consistency) or you'll get 
them numbered 1,3,4,5 (breaking channel<->physical channel 
consistency).  Either way, it'll cause confusion.  And it gets 
worse if the implementation requires that stereo sounds or MODs 
require adjacent channels - the story author can never be sure if 
a given call will succeed or fail beforehand.

Anyway, effects and music *are* fundamentally different, that's 
why they were separated in the first place.  Effects are pure 
sound samples (and incidentally, MP3s fall into this category, I 
think), whereas music contains a number of sound samples and 
instructions for playing those samples in a sequence and at 
different pitches.  Music is more complicated to compose and play, 
but you can have much longer sequences in much less disk space.

Sigh, I think I'm starting to ramble again.  I'll go back under my 
rock :P
-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
A zygote is a gamete's way of producing more gametes.  This may be 
the
purpose of the universe.  -- Lazarus Long


</x-flowed>
From ???@??? Fri Dec 14 19:12:05 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 13 Dec 2001 10:44:58 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <91042ee84a.kbracey@kbracey.cam.pace.co.uk>
References: <E16EGmF-0000IL-00@seasip.demon.co.uk>
In-Reply-To: <E16EGmF-0000IL-00@seasip.demon.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <E16EGmF-0000IL-00@seasip.demon.co.uk>
          John Elliott <jce@seasip.demon.co.uk> wrote:

> : 
> : I'm fairly certain this is taken care of.  The spec already says it 
> : needs to return 0 if asked for a font it can't provide.  If an 
> : interpreter does otherwise it's a bug in the terp, isn't it?
> 
>   What I meant was that the interpreter must not provide this 
> font (at the moment, the spec just says that it need not provide it).

Okay, we'll make that a clarification for the existing specw but I'm not
quite sure how it helps. You're trying to cope with interpreters that never
return 0 from set_font. Who would actually modify an interpreter to
successfully return 0 from set_font 2 but not from all the other fonts?

I've probably missed something :))

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Dec 14 19:12:08 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 13 Dec 2001 11:17:31 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] sound streams and spec 1.1
Message-ID: <acff30e84a.kbracey@kbracey.cam.pace.co.uk>
References: <20011212183417.633D730805B@fauna.jczorkmid.net>
In-Reply-To: <20011212183417.633D730805B@fauna.jczorkmid.net>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <20011212183417.633D730805B@fauna.jczorkmid.net>
          jpenney@jczorkmid.net (Jason Penney) wrote:

> Hey,
> 
> Here's my thought on a backwards compatible version of @sound_stream.
> 
> If the 'Game wants multiple streams' bit isn't set then all e ffects
> default to stream 0 and all music (if supported) to stream 1.  This is
> primaraly provided for backwards compatibility and is depreciated.
> 

That would cover it.

I'm still not sure how the API is going to work though. Let's say you request
a channel. Do you tell it up-front what you're going to play on it?
Presumably not. In which case you can't be sure that any given sound will fit
in the channel, thus making a bit of a mockery of claiming the channel in the
first place.

That would put the burden firmly on the game to cope with stopping old
sounds on other channels to make room for the new sound.

But that is the way that Glk works. Now Glk was created from scratch, and
didn't have a legacy behaviour of free-form sound playing with automatic
stopping of earlier sounds. Instead it tries to present the illusion that
"all sounds are equal" through the API. The sound call can return "0" to
say it couldn't play the sound, but it doesn't tell you why. I for one am not
fond of this. It seems reasonably natural in Glk, with its plethora of rocks
handles and creation calls, but just doesn't feel right for the Z-machine
somehow.

Physical channel assignment could be tricky, as Gavin says. You couldn't
actually assign a physical channel to a game channel until a sound is played,
so you knew how many physical channels (or which ones - my MOD player insists
on channels 1-4) you need.

I think all of this gives you a very small amount of extra flexibility at the
cost of a lot of game author complexity, plus possibly some loss in freedom
of implementation for the interpreter.

With the original design, plus the "does it fit" extension to sound_data that
was discussed, as long as you don't play the same sound on multiple channels,
a virtual channel interface could be created in V6Lib, if required, giving
all the same functionality - claim channel, release channel, play sound on
channel n. But in the simple case, the author just plays, as currently,
and the interpreter does whatever it needs to to make room for the new sound.

The same sound on multiple channels - Fillmore's footsteps - can be given
some control in the callback handlers, as each sound could have a separate
callback.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Dec 14 19:12:09 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 13 Dec 2001 11:20:28 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Message-ID: <8c4431e84a.kbracey@kbracey.cam.pace.co.uk>
References: <3C17A424.28675.111C97@localhost>
In-Reply-To: <3C17A424.28675.111C97@localhost>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <3C17A424.28675.111C97@localhost>
          "Jason C Penney" <jpenney@jczorkmid.net> wrote:

> If at some later date we decide on some portable font format so people 
> can distribute a custom font in a blorb file or something (not saying 
> this is likely or a good idea, but it is an option) I imagine that would 
> become font 2, and then once interpreters supported this they would 
> correctly report that they did provide font 2.

Bad idea - it would be font 5 or higher, I think.

I agree that it could be clarified that Font 2 should be marked as not
supported, but I don't see that it achieves anything.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Dec 14 19:12:15 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 13 Dec 2001 14:59:09 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Message-ID: <db4945e84a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] Standard 1.1 Proposal - 2nd attempt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


This is a second draft of the proposal. It covers all the discussion on the
list, and a few other items that have come to my attention.

The main area of dispute would appear to be the sound. I've tightened up the
original design to the extent that most of Fillmore's requested functionality
could be provided by a library. So far I've counted 4 voices in favour of
this style of sound (including the 2 authors) and 1 opposed. That's not
statistically significant - we need more feedback.

Jason's going to stick a copy of this draft on his server and post on raif
pointing people to the mailing list. Hopefully we can get some more people
involved in the discussion.





                      Z-Machine Standard 1.1 Proposal
                      -------------------------------

                   Authors: Kevin Bracey & Jason C. Penney

                                INTRODUCTION
                                ============

This revision of the Z-Machine Standards Document has been written with
the following aims:

   1) To clarify problem areas in Standard 1.0, and correct errors
   2) To allow more probing of interpreter capabilities
   3) To clarify the use of Blorb with Standard 1.0
   4) To add some extensions for use with Blorb
   5) To add some simple extensions to the Version 5 and Version 6
      screen models to increase flexibility

As ever, interpreters *FULLY* implementing this Standard (apart from any
optional parts whose absence are signalled through header bits) for a given
Version should indicate this by setting the Standard revision bytes in the
header to $01 $01. (An interpreter might meet the Standard for all Versions
other than V6, in which case it would not fill in the revision bytes when
playing a V6 game).

There have been instances in the past of interpreters that do not fully meet
Standard 1.0 claiming Standard 1.0 compliance in the header. This sort of
behaviour is dangerous, and likely to cause games that would otherwise work
to break.

Conversely, games that absolutely require Standard 1.1 features should not
refuse outright to run on a non-Standard 1.1 interpreter - it may be
implementing the new features you require, being deficient only in other
areas. Instead, a warning should be issued to the user before proceeding.
Of course, whereever possible games should have alternative behaviour
automatically invoked for older interpreters.

As with the rest of the Standard, all references to Version 5 in this
document apply equally to Versions 7 and 8.



                          UPDATES/CLARIFICATIONS
                          ======================

Memory layout
-------------
Version 6 and 7 story files are both limited to 512K, not 320K. The 320K
limitation was an artificial one imposed by the Inform compiler - this has
now been addressed by a compiler patch.


Encoded text
------------
Many of Infocom's interpreters (and some subsequent interpreters, such as
ITF's) treat multiple consecutive Z-characters 4 and 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.


Header capabilities bits
------------------------
The (Version 6) sound and graphics bits in Flags 1 indicate general
availability of sound and graphics - ie whether the associated opcodes are
available and functional.

The bits in Flags 2 and 3 should ideally be set reflecting current
availability, rather than general support. In other words, if no Blorb (or
other) resources for this story file have been found, or if the Blorb file
contains no graphics or no sound, the corresponding bits should be cleared.

Also, it is recommended that interpreters that would prompt for an auxiliary
Blorb file should do so immediately on start up if any of the "game wants to
use sound/music/graphics" bits are set; this allows the bits to be cleared if
no file is forthcoming, before the game starts execution. The game can then
take appropriate action.

Bit 4 of Flags 1 indicates the availability of the fixed-pitch style, not
Font 4.


The fixed-pitch header bit
--------------------------
Use of the fixed-pitch bit in the header is deprecated in Version 5 and
later - it is an irregularity in the Z-machine that complicates the
implementation of buffering and text style handling in the interpreter, and
may even slow down all memory stores.

Font 4 (or Fixed Pitch style) should be used instead. Infocom did not use the
fixed-pitch bit after Version 4, and it is not implemented in at least some
of their later interpreters.

However, the fixed-pitch bit is modified by the "font" statement in
Inform 6.21, so is used by many current Inform generated files. Therefore
interpreter authors must support it in Version 5. Support in Version 6 is not
required.


Indirect variable references
----------------------------
In the seven opcodes that take indirect variable references (inc, dec,
inc_chk, dec_chk, load, store, pull), an indirect reference to the stack
pointer does not push or pull the top item of the stack - it is read
or written in place.


Version 6 windows
-----------------
Interpreter authors are advised that all 8 windows in Version 6 must be
treated identically. The only ways in which they are distinguished are:

   * Different default positions + sizes
   * Different default attributes
   * @split_window manipulates windows 0 and 1 specifically
   * Window 1 is the default mouse window

Differences in interpreter behaviour should only arise from differences in
window attributes and properties.


@set_text_style
---------------
It was previously unclear in the Standard whether instructions like 

   @set_text_style 5;   ! Reverse+Italic

were legal. None of Infocom's game files make use of such forms, and many
interpreters will not handle them correctly. Such instructions should be
avoided; instead you can use multiple @set_text_style opcodes specifying each
style in turn, with the most important last, thus:

   @set_text_style 4;   ! Italic
   @set_text_style 1;   ! Reverse - overrides if combination not available

However, Standard 1.1 does now require such combinations in a single
opcode to be supported, as they are in some of Infocom's later
interpreters - see below. But unless a game absolutely requires
Standard 1.1 anyway (eg for true colour support), it is probably best
to request only one style per opcode for backwards compatibility.


@set_font
---------
Font 2 (the picture font) is undefined. No interpreter should implement it,
and set_font 2 should always return 0. Any new fonts will have numbers
higher than 4. Fonts 5-1023 are reserved for future Standards to specify.
Local use may be made of higher font numbers.


@get_prop_len
-------------
@get_prop_len 0 should return 0. This is required by some Infocom games and
files generated by old versions of Inform.


@set_cursor
-----------
S8.7.2.3 states that it is illegal to move the cursor outside the current
size of the upper window. S8.8.3.5 gives the equivalent rule for Version 6.

Many modern games have been lax in obeying this rule; in particular some
of the standard Inform menu libraries have violated it. Infocom's Sherlock
also miscalculated the size of the upper window to use for box quotes.

It is recommended that if the cursor is moved below the split position in
V4/V5, interpreters should execute an implicit "split_window" to contain the
requested cursor position, if possible. Diagnostics should be produced, but
should be suppressable.

In V6, it is legal to position the cursor up against the right or bottom of a
window - eg at (1,1) in a zero-sized window or at (641,401) in 640x400
window. Indeed, this is the default state of windows 1 to 7, and the cursor
may be left at the right-hand side of a window when wrapping is off.

Attempting to print text (including new-lines) when the cursor is less than
font_height units from the bottom of the window results in undefined
behaviour - this precludes any printing in windows less than font_height
units high.


@split_window
-------------
In Version 6, the Standard states that the cursor remains in the same
absolute position. This is an extension to the Z-machine, as this rule is not
followed by Infocom's own interpreters, which keep the same window-relative
position. The Standard behaviour more closely mimics Version 5's
split_window.

The opcode dictionary incorrectly states that "the width and x-coordinates of
windows 0 and 1 are not altered." The correct behaviour is detailed in
S8.8.4.1.


@output_stream
--------------
Interpreter authors are reminded that "nested" uses of @output_stream 3
have been required since Standard 1.0; see S7.1.2.1.1.


@read_mouse
-----------
@read_mouse should be realtime.  When called it should read the current mouse
location, whether or not the mouse is inside the current mouse window. Most
modern interpreters get this wrong, but Infocom's interpreters behave this
way. Interpreters are allowed to show positions and button states outside the
Z-machine screen if the pointer is outside the interpreter's own user
interface (using negative values if needed). 

Programs should be prepared to cope with this. For example in a painting
program you might want to ignore all buttons down outside the screen. When
dragging something you might want to keep trying to follow the pointer, even
outside the screen, until the buttons are released. 

Interpreters may constrain the pointer to the screen as long as buttons are
held down - this might aid dragging operations - although this is not
required.

Previous revisions of the Standard stated that mouse buttons were numbered in
the following fashion: "low bits on the right of the mouse, rising as one
looks left".  This is a rather non-portable implementation and should be
abandoned in modern interpreters in favor of the 'primary' button being the
lowest bit, the 'secondary' (if present) being the next lowest bit, etc. The
ordering of buttons should be that which is most natural for the host system.


@picture_data
-------------
@picture_data 0 should branch if any pictures are available.


@sound_effect
-------------
To clarify:

    @sound_effect number 3/4

will stop (and optionally unload) sound 'number' if it is currently playing
(or loaded). Otherwise it is ignored.

    @sound_effect 0 3/4

will stop (and unload) all sounds - music and effects.

The "repeats" parameter in Version 5 indicates the total number of times to
play the sound, not the number of times to repeat it after the first play.
Setting repeats to zero in V5 is illegal - it is suggested that interpreters
treat this as a request to play the sound once, and maybe issue a warning.

Callback routines are only called when the sound has played the requested
number of times. If manually stopped or interrupted by another sound, the
routine is not called.

The Blorb specification effectively revised Standard 1.0, as follows:

"Sound" is split into two classes - "music" (eg Blorb SONG and MOD) and
"effects" (eg Infocom .SND or Blorb AIFF).

The "sound requested" header bit is left set if the interpreter supports
either effects or music. It is only cleared if the interpreter can provide
neither effects nor music.

Music and effects are treated as two separate channels. Playing a new effect
interrupts the current effect, but not the music, and vice versa. Whether
loading a new sound (with @sound_effect n 1) stops the current one is
implementation defined.

As of Standard 1.1, there is a header bit to indicate that the game wants to
use multiple sound channels and the interpreter can handle it, and a bit
to indicate the availability of music.


Volume guidelines
-----------------
[ This would better live in the Blorb specification, but is partly
  Z-machine specific. ]

When using Blorb resources, the default interpreter behaviour (unless over-
ridden by the player) should be for samples played at maximum volume (64) in
one channel of a SONG or MOD played at volume 8 to be of equal volume to
samples played at maximum volume (8) as an effect. This will be the natural
behaviour if effects use one physical channel and MODs/SONGs use four
physical channels.

Ideally, a sound played at volume <n> in a SONG played at volume <m> should
sound the same as when played as an effect at volume <n*m/64>. This mandates
that the volume scale for effects be equivalent to the scale defined for
samples in the MOD specification.

If multi-channel effects are used, the overall volume should be independent
of the number of channels used in the sound. Thus a stereo AIFF containing
the same samples for left and right should sound as loud as a mono AIFF
containing the same data. This will need adjustment of volume if stereo AIFFs
use two physical channels and mono AIFFs use one. No adjustment would be
required if an interpreter reduced all AIFFs to mono.


Colour numbers
--------------
The presence of the "under the cursor" colour option, and in Standard 1.1
the set_true_colour opcode (see below), raises the possibility of
non-standard colour numbers appearing in window property 11. In addition, an
interpreter may offer non-standard default colours, which need to appear in
the story file header. We now give more detailed implementation guidelines.

If a true colour, or an "under the cursor" colour, has been requested by the
game, then the foreground or background colour shown in window property 11 is
implementation defined, except that:

      1) If the colour selected was one of the standard set (2-15), then
         that colour should be indicated in property 11.
      2) If the colour selected was not one of the standard set, the colour
         shown in property 11 should be >= 16.

It is legal for interpreters to always show the same value in property 11 if
a true or sampled colour is in use. As a result, story files cannot rely on
setting a value that was read from the window property giving the same
colour, if @set_true_colour or @set_colour -1 has been used in that window.

The same rules apply if an interpreter offers non-standard default colours
(which need to be shown in the header) although in this case it would be
ill-advised to show the same colour numbers for foreground and background -
unless they can be distinguished, non-standard default colours should
probably not be offered.

If the interpreter offers a limited palette, then there is no problem, as it
can be arranged for there to be fewer than 240 distinct non-standard colours.
In an interpreter with a higher colour-depth, a good implementation would be
to use colours 16-255 to represent the last 240 distinct non-standard colours
used, re-using numbers after 240 colours have been used. This will minimize
potential problems caused by non-standard colours, particularly when set as
defaults. 

Regardless of the limitations on colour numbers, in Version 6 each window
must remember accurately the colour pair selected, so it is preserved across
window switches.


                                ADDITIONS
                                =========

Blorb
-----
Standard 1.1 interpreters are required to handle Blorb (v1.1) files, at least
up to support for running a Z-code executable from within a Blorb file. If
the interpreter supports sound or graphics, it must be able to obtain those
resources from a Blorb file (although the Standard does not preclude other
formats).


Header Extension
----------------
If the interpreter claims Standard 1.1 compliance then it supports the
following extra words in the header extension table. If the header
extension table is present, and the extra words are present, then a
Standard 1.1 interpreter will examine and update them.

If the interpreter is not Standard 1.1, then the extra words will be ignored.
Guidelines on behaviour in this case are supplied in the descriptions below.

Note that the header extension table itself is a Version 5 feature, so the
extra information here is not available in earlier versions, despite the
fact that some fields could be applicable.

The new flags are placed in a new word, rather than in Flags 2 to minimize
potential compatibility problems. To prevent future compatibility problems,
all reserved bits in the Flags 3 word MUST be cleared by the interpreter.

Word  V  Dyn Int Rst  Contents
---- --- --- --- ---  --------------------------------
 4    5               Flags 3:
      5       *   *   0: All text style combinations available?
      5       *   *   1: Multiple colours available?
      5       *   *   8: If set, game wants to use music
      5       *   *   9: If set, game wants multiple sound channels
      6       *   *   10: If set, game wants to use transparency
                      (For bits 8-10, Int clears again if it cannot provide
                       the requested effect).
 5    5       *   *   True default foreground colour
 6    5       *   *   True default background colour


0: All text style combinations available?

         An interpreter sets or clears this bit to indicate whether
         it can provide all the text styles it supports in all
         combinations.  If it can do Bold, Italic or Fixed, but not
         Bold and Fixed at the same time this bit should be 0.  If it
         doesn't support Italic at all (and has cleared Flags 1 bit 3
         to specify this), but it does support combinations of the
         remaining three styles it should set this bit to 1.

         All combinations are required for font 1. Font 3 only requires
         Roman and Reverse Video. Font 4 requires all combinations, except
         that Fixed is ignored (because it is inherently fixed-pitch).

         If the interpreter predates Standard 1.1, then text style
         combinations may or may not be available; however until
         Standard 1.1 interpreters were not required to handle
         combinations of styles in a single @set_text_style call.
         Combination effects should therefore be requested using
         sequential calls (with the most important effect requested
         last).

1: Multiple colours available?

         This bit should be 1 if the interpreter can display multiple
         text colours on screen at one time, and should be 0 if
         changing the text colour changes all text on screen.

         Preferred behaviour for Standard interpreters is to display
         multiple colours. But if the interpreter predates Standard 1.1,
         then generally its behaviour will depend on the machine type -
         see section 8.3. If this flags word is present, then a Standard
         interpreter should normally set the bit, and provide multiple
         colours if at all possible, regardless of machine type.

8: If set, game wants to use music

        A game file that wishes to use music will set this bit.  If an
        interpreter can provide music (as described in the Blorb
        specification) it should leave the bit set; if it is unable
        to do this, it should clear the bit.  If this bit is set then
        a minimum of two sound channels exist, one for effects and one
        for music.

        If this flags word is not present, or the interpreter predates
        Standard 1.1, then there is no way to tell whether music is
        available. If an interpreter doesn't support music, then
        @sound_effect opcodes requesting music will be ignored.

        If a game that supplies this flags word does not set this bit,
        then the interpreter may choose to act as though music were
        unsupported.

9: If set, game wants multiple sound channels
 
        If the game wishes to have multiple sound channels, it
        should set this bit. This changes the behaviour of @sound_effect.
        An interpreter should clear this bit if it can't play more than one
        sound of a given type a time.

        Interpreters predating standard 1.1 will not support multiple
        sound channels, and will act as though this bit is clear.

        The minimum requirement on an interpreter that sets this bit is
        that it can play at least two mono effects and one (4-channel)
        piece of music simultaneously. More channels may be available (see
        @sound_effect section below for details).

10: If set, game wants to use transparency

        In Version 6 colour 15 is defined as transparent.  If an
        interpreter cannot provide transparency then it should clear
        this bit.

        Transparency is a new feature in Standard 1.1. Older interpreters
        will not support this.

All other bits in the flags word must be cleared by the interpreter.


@save and @restore
------------------
EXT:0 0 5 save table bytes name prompt -> (result)
EXT:1 1 5 restore table bytes name prompt -> (result)

As of Standard 1.1 an additional optional parameter, prompt, is allowed on
Version 5 extended save/restore.  This allows a game author to tell the
interpreter whether it should ask for confirmation of the provided file name
(prompt=1), or just silently save/restore using the provided filename
(prompt=0).

If the parameter is not provided, whether to prompt or not is a matter for
the interpreter - this might be globally user-configurable. Infocom's
interpreters do prompt for filenames, many modern ones do not.


@buffer_screen
--------------
New opcode in Standard 1.1, for Version 6

EXT:29 1D 6 buffer_screen mode -> (result)

Interpreters may use a backing store to store the Z-machine screen state,
rather than plotting directly to the screen. This would normally be the case
in a windowed operating system environment. If a backing store is in use,
display changes executed by the Z-machine may not be immediately made visible
to the user. Standard 1.1 adds the new opcode @buffer_screen to Version 6 to
control screen updates. An interpreter is free to ignore the opcode if it
doesn't fit its display model (in which case it must act as if buffer_screen
is always set to 0).
  
When buffer_screen is set to 0 (the default), all display changes are
expected to become visible to the user either immediately, or within a short
period of time, at the interpreter's discretion. At a minimum, all updates
would become visible before waiting for input. Any intermediate display
states between input requests may not be seen; for example when printing a
large amount of new text into a scrolling window, all the intermediate scroll
positions may or may not be shown.
  
When buffer_screen is set to 1, the interpreter need not change the visible
display at all. Any display changes can be done purely in the backing store.
A program may set buffer_screen to 1 before carrying out a complex layered
graphical composition, to indicate that the intermediate states are not worth
showing. When buffer_mode is set back to 0, the display is not necessarily
updated immediately - if this is required, buffer_mode -1 should be issued as
well. It would be extremely ill-advised to prompt for input with
@buffer_screen set to 1.
  
With buffer_screen in either state, an update of the visible display can be
forced immediately by issuing @buffer_screen -1, without altering the current
buffering state. Note that @buffer_screen -1 does NOT flush the text buffer.
  
@buffer_screen returns the old buffer_screen state.


@set_text_style
---------------
As of Standard 1.1, it is legal to request style combinations in a
single @set_text_style opcode by adding the values (which are powers of two)
together. If the parameter is non-zero, then all the styles given are
activated. If the parameter is zero, then all styles are deactivated.

If the "All text style combinations available?" bit is set in the header
extension, then the interpreter is required to display a combination of all
styles requested that it provides (i.e. if the interpreter can't display
italic but a game file requests style 12 [Italic + Fixed] anyway, the
interpreter would activate the Fixed style).  If the "Full font style
combinations available" bit is not set, then the Interpreter should give
precedence first to the most recent call to @set_text_style, and within that
to the highest bit, making the priority Fixed, Italic, Bold, Reverse. 


@set_font
---------
EXT:4 4 6 set_font font window -> (result)

In Version 6, set_font has an optional window parameter, as for set_colour.
This was part of the original Infocom design, but omitted by earlier
Standards. It is reinstated here, as it is useful to be able to measure
a font that is about to be used in another window, so that window can be
sized before attempting to place the cursor in it.


@set_colour
-----------
In Version 6 only, colour 15 is defined as transparent.  This is only valid
as a background colour; an attempt to select it for the foreground should
produce a diagnostic. Interpreters not supporting transparency should ignore
any attempt to select colour 15.

If the current background colour is transparent, then printed text should be
superimposed on the current window contents, without filling the background
behind the text. @erase_window, @erase_line and @erase_picture become null
operations.

The intent is to make it possible to superimpose text on non-uniform images.
Up until now, only uniform images could be satisfactorily written on
by sampling the background colour - that in itself would be problematical if
the interpreter used dithering.

Scrolling with the background set to transparent is not permitted, so
transparent should only be requested in a non-scrolling window. It is not
valid to use Reverse Video style with the background set to transparent.

Instructions that prompt for user input, such as @read and @save should be
avoided when the background is set to transparent, as it will not generally
be possible for text entry to take place satisfactorily in the absence of
a defined background colour.

Printing text multiple times on top itself with the background set to
transparent should be avoided, as the interpreter may use anti-aliasing,
resulting in the text getting progressively darker.

Standard 1.1 interpreters should provide the following basic colour
set, regardless of machine type, in both Version 5 and Version 6:

 -1 = sample      (true -3) [V6 only]
  0 = current     (true -2)
  1 = default     (true -1)
  2 = black       (true $0000, $$0000000000000000)
  3 = red         (true $001F, $$0000000000011111)
  4 = green       (true $03E0, $$0000001111100000)
  5 = yellow      (true $03FF, $$0000001111111111)
  6 = blue        (true $7C00, $$0111110000000000)
  7 = magenta     (true $7C1F, $$0111110000011111)
  8 = cyan        (true $7FE0, $$0111111111100000)
  9 = white       (true $7FFF, $$0111111111111111)
 10 = light grey  (true $5AD6, $$0101101011010110)
 11 = medium grey (true $4631, $$0100011000110001)
 12 = dark grey   (true $2D6B, $$0010110101101011)
 13  reserved
 14  reserved
 15 = transparent (true -4) [V6 only]

This is the original Amiga Version 6 colour set. The greys are gamma adjusted
from the original values (8-bit &AA,&77,&44) used on the Amiga, on the
assumption that the Amiga's system gamma is 1/1.8.

The equivalences between the colour numbers and true colours are canonical -
this gives an exact equivalence mapping from @set_colour to @set_true_colour.

Interpreters may provide different colours (eg making colour 10 dark grey),
but if and only if they can detect they are running an original Infocom story
file.


@set_true_colour
----------------
New opcode in Standard 1.1, for Version 5 or later, if Flags 1 bit 0 is set.

EXT:13 D 5 @set_true_colour foreground background
         6 @set_true_colour foreground background window

fg and bg are 15-bit colour values - bit 15 = 0
                                     bits 14-10 blue
                                     bits 9-5 green
                                     bits 4-0 red

Magic values in the opcode are: (-1) = default setting
                                (-2) = current setting
                                (-3) = colour under cursor (V6 only)
                                (-4) = transparent (V6 only)

The interpreter should set the closest approximations available to
the requested colours. In V6, the interpreter may store the approximations
in window properties 16 and 17, so the program can tell how close it got
(although it is acceptable for the interpreter to just store the requested
value).

In the minimal implementation, interpreters just need to match to the closest
of the standard colours and internally call @set_colour (although that would
have to ensure window properties 16 and 17 were updated). In a full
implementation this would be turned around and @set_colour would internally
call @set_true_colour.

The default true colours are stored in the header extension table.

The optional window parameter is only allowed in V6, and operates the same as
in @set_colour.

True colour specifications are in the sRGB colour space, $0000 being black
and $7FFF being white. Colours should be gamma adjusted if necessary. See the
PNG specification for a good introduction to colour spaces and gamma
correction.


@get_wind_prop
--------------
With the addition of true colours, two new Version 6 window properties are
defined.

The two new window properties are:

   16: true foreground colour
   17: true background colour

These are not writable with @put_wind_prop.

The true foreground and background colours show the actual colour being
used for the foreground and background, whether it was set using @set_colour
or @set_true_colour. Transparent is indicated as -4. If the colour was
sampled from a picture, the value shown may be a 15-bit rounding of a
more precise colour, leading to a slight inaccuracy if the colour is read
and then written back.



@sound_data
-----------
New opcode in Standard 1.1, for Version 5 or later, if Flags 1 bit 5 is set.

EXT:14 E 5 sound_data sound-number array ?(label)

Asks the interpreter for data on the sound with the given number. If the
sound number is valid, and the sound is of a type supported by the
intepreter, a branch occurs and information is written to the
array: the type (1 for effect, 2 for music) in word 0, playing
status in word 1, and channel availability in word 2. (This is an array, not
a "table" with initial size information.) 

Otherwise, if the sound number is zero, the interpreter writes the number of
available (and supported) sounds into word 0 of the array and the release
number of the sounds file (eg from the Blorb RelN chunk) into word 1. A
branch occurs if the number of sounds is non-zero.

Otherwise, nothing happens.

The playing status is -1 if the sound is not currently playing. If the sound
is currently playing, the playing status is the length of time that the
sound has been playing, in tenths of a second, clamped to a maximum of 3276.7
seconds. If the sound is playing on multiple channels, it is the longest
running channel's playing time that is indicated.

The channel availability word is set to 0 if playing the sound will not
result in any other sounds being stopped. Otherwise the availability word
contains the number of a sound that will be interrupted by playing this
sound.


@sound_effect
-------------
Standard 1.1 adds new behaviour to @sound_effect (but see the clarifications
section above for notes on pre-1.1 behaviour).

As of Standard 1.1, there is a header bit to indicate that the game wants to
use multiple sound channels and the interpreter can handle it.

If the multiple sound channels bit is clear (or not present), then the
interpreter behaves as per Standard 1.0 + Blorb 1.1 - see above for
clarifications.

If the multiple sound channels bit is set, then the interpreter should not
stop any current sound when a new one is played or loaded - it should only
stop a sound when explicitly asked to, or when it has played the specified
number of repeats. That way, a game can play multiple sounds of the same type
at once. 

However, there are an undefined number of sound channels available. When an
interpreter runs out of channels of a particular type, and an additional call
to @sound_effect is made, the sound with the highest resource number of the
same type is stopped (without its callback routine being called) and the new
sound is played. It may be that playing a sound interrupts more than one
sounds - for example a stereo effect could interrupt two mono effects.

Sounds of different types can never interrupt each other - the channels used
for music and effects are independent. As a corollary to this, it may be that
more effects channels are available if the game does not ask to use music.

The highest resource number rule allows an author to indicate the
"importance" of each sound.

The same sound can be played on more than one channel, with different
volumes, repeats and callback routines. In the event of channel exhaustion,
it is the "oldest" play of the sound with the highest resource number that
gets stopped first.

@sound_effect <n> 3 (or 4) stops all plays of sound <n>.

The original Standard 1.0 + Blorb 1.1 behaviour is equivalent to the new
scheme with one channel each of effects and music.


New opcode summary:
-------------------
St Br Opcode Hex V Inform name and syntax
*     EXT:0  0   5 save table bytes name prompt -> (result)
*     EXT:1  1   5 restore table bytes name prompt -> (result)
*     EXT:4  4   6 set_font font window -> (result)
      EXT:13 D   5 set_true_colour foreground background
                 6 set_true_colour foreground background window
   *  EXT:14 E   5 sound_data sound-number array ?(label)
*     EXT:29 1D  6 buffer_screen mode -> (result)

set_true_colour is not a good candidate for taking a 2OP encoding like
set_colour, as it will have a low usage frequency, and it will rarely take
small constants.



From ???@??? Fri Dec 14 19:12:19 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <3C15C0AC.7829.1E5A166@localhost> <5.1.0.14.0.20011213212506.0729a0f0@pop.ihug.co.nz>
Subject: Re: [z-machine] Re: Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Thu, 13 Dec 2001 16:13:16 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE68IpLcEcLsXJB7oDa00001604@hotmail.com>
X-OriginalArrivalTime: 13 Dec 2001 16:07:29.0184 (UTC) FILETIME=[438DCA00:01C183F0]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message ----- 
From: "Gavin Lambert" <uecasm@geocities.com>
To: "z-machine mailing list" <z-machine@gmd.de>
Sent: Thursday, December 13, 2001 8:48 AM
Subject: [z-machine] Re: Z-Machine Standard 1.1 Proposal - 1st attempt


> At 13:32 11/12/01 +0000, Fillmore wrote:
>  >
>  >Not really. If you have 8 channels, you play 1 MOD on channel 0,
>  >then another on channel 1, then you try and set the channel to
>  >channel 2, it fails. The terp probably knows how many channels
>  >altogether it can handle, so any number over that it fails
>  >anyway. Within that many channels, the game writer can be
>  >sensible and use up channels in order, reusing ones that no
>  >longer have sound playing, or they can ask for new channels
>  >all over the place. This would lead to not being able to play
>  >on channel 2 when you're already playing on channel 7 and 8,
>  >but it would work.
> 
> So, you've got MODs playing on channels 1 and 2 (using eight
> physical channels), and no other channels are available.  Then the
> MOD on channel 1 finishes playing, and suddenly you have four free
> channels.  Either they'll push the second MOD (still playing) out
> to channel 5 (breaking sound<->channel consistency) or you'll get
> them numbered 1,3,4,5 (breaking channel<->physical channel
> consistency).  Either way, it'll cause confusion.  And it gets
> worse if the implementation requires that stereo sounds or MODs
> require adjacent channels - the story author can never be sure if
> a given call will succeed or fail beforehand.

Take a look at a similar situation with automatic channel handling.
You've start a MOD playing on channel 1, and then an AIFF on channel 2. 
If you start another MOD, the first MOD stops. If you start another
AIFF, nothing stops. This is basically the same problem. If you only have
3 real channels left, you can't play a MOD on a new z-channel. The only 
way to get around this in either case is to say 1 z-channel is equal 
to the highest number of channel a resource can hold.

> Anyway, effects and music *are* fundamentally different, that's
> why they were separated in the first place.  Effects are pure
> sound samples (and incidentally, MP3s fall into this category, I
> think), whereas music contains a number of sound samples and
> instructions for playing those samples in a sequence and at
> different pitches.  Music is more complicated to compose and play,
> but you can have much longer sequences in much less disk space.

They were seperated because the Z-Machine had no capacity for sound
channels, at all, and it was though people would want some. The
Z-Machine *still* has no support for sound channels. Sound
channels are not mentioned anywhere in the Z-Machine spec, as it is
at the moment. Blorb hacked together a quick ugly patch to let the
minimum possible support exist. If effects and music are *really*
so fundamentally different, they should be handled by different 
opcodes. Not that I want that.

--
Fillmore



From ???@??? Fri Dec 14 19:12:22 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] sound streams and spec 1.1
Date: Thu, 13 Dec 2001 16:36:56 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE61xxLI9jtcEko8PU200001559@hotmail.com>
X-OriginalArrivalTime: 13 Dec 2001 16:31:11.0162 (UTC) FILETIME=[931E69A0:01C183F3]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
To: <z-machine@gmd.de>
Sent: Thursday, December 13, 2001 11:17 AM
Subject: Re: [z-machine] sound streams and spec 1.1


> In message <20011212183417.633D730805B@fauna.jczorkmid.net>
>           jpenney@jczorkmid.net (Jason Penney) wrote:
>
> > Hey,
> >
> > Here's my thought on a backwards compatible version of @sound_stream.
> >
> > If the 'Game wants multiple streams' bit isn't set then all e ffects
> > default to stream 0 and all music (if supported) to stream 1.  This is
> > primaraly provided for backwards compatibility and is depreciated.
> >
>
> That would cover it.
>
> I'm still not sure how the API is going to work though. Let's say you
request
> a channel. Do you tell it up-front what you're going to play on it?
> Presumably not. In which case you can't be sure that any given sound will
fit
> in the channel, thus making a bit of a mockery of claiming the channel in
the
> first place.
>
> That would put the burden firmly on the game to cope with stopping old
> sounds on other channels to make room for the new sound.
>
> But that is the way that Glk works. Now Glk was created from scratch, and
> didn't have a legacy behaviour of free-form sound playing with automatic
> stopping of earlier sounds. Instead it tries to present the illusion that
> "all sounds are equal" through the API. The sound call can return "0" to
> say it couldn't play the sound, but it doesn't tell you why. I for one am
not
> fond of this. It seems reasonably natural in Glk, with its plethora of
rocks
> handles and creation calls, but just doesn't feel right for the Z-machine
> somehow.

That's not how my idea works. My idea is 'each sound channel works the same
way
as the one sound channel did in z-spec 1.0'. There

> Physical channel assignment could be tricky, as Gavin says. You couldn't
> actually assign a physical channel to a game channel until a sound is
played,
> so you knew how many physical channels (or which ones - my MOD player
insists
> on channels 1-4) you need.
>
> I think all of this gives you a very small amount of extra flexibility at
the
> cost of a lot of game author complexity, plus possibly some loss in
freedom
> of implementation for the interpreter.

There is not a lot of game author complexity. There's one extra opcode.

Let's compare, shall we?
You have eight physical channels, with a MOD playing on one and an AIFF on
another.

Using your method, you check sound_data to find out how many channels you
have
left, and discover only three. You now know that if you play a new MOD, it
will stop the oldest one playing. If that's what you want, you start the new
sound. If that's not what you want, you either don't play the sound, or you
stop a sound you don't mind losing and then play the new one.

Using my method, you check sound_data to find out how many channels you have
left, and discover only three. You now know that if you play a new MOD, it
won't work. If you decide that it's not that important, you don't even
bother
asking for the channel. If you do want to play the sound, you have to cut
out
another sound. So, you switch to the channel the sound you want to cut out
is
on, and start the new one, automatically interupting the one playing on that
channel.

My way gives you exactly the same amount of information on how many channels
you have left, with a bit more control over how you use them, and the
ability
to play the same sound more than once in different channels.

> With the original design, plus the "does it fit" extension to sound_data
that
> was discussed, as long as you don't play the same sound on multiple
channels,
> a virtual channel interface could be created in V6Lib, if required, giving
> all the same functionality - claim channel, release channel, play sound on
> channel n. But in the simple case, the author just plays, as currently,
> and the interpreter does whatever it needs to to make room for the new
sound.

With the new design, plus the "does it fit" extension to sound_data that
was discussed, you *can* play the same sound on multiple channels, and
V6lib can automatically implement the situation of playing until you've run
out of channels and then freeing up the oldest, by checking to see how many
channels exist before a sound is played, and then checking to see how many
exist afterwards. If the number hasn't changed, the sound isn't playing, so
you cut the oldest channel and try again.

Thus the complexity for the user is dependant in both cases on what they
wish
to do, and how much nifty V6lib-like code is between them and the opcodes.

I still believe that my way is more powerful, and more faithful to the
design
of the Z-Machine.

> The same sound on multiple channels - Fillmore's footsteps - can be given
> some control in the callback handlers, as each sound could have a separate
> callback.

I'm sorry, I don't understand that. Callback handlers? Have I missed
something?

--
Fillmore


From ???@??? Fri Dec 14 19:12:25 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 13 Dec 2001 17:16:24 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] sound streams and spec 1.1
Message-ID: <bada51e84a.kbracey@kbracey.cam.pace.co.uk>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com>
In-Reply-To: <OE61xxLI9jtcEko8PU200001559@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE61xxLI9jtcEko8PU200001559@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> 
> That's not how my idea works. My idea is 'each sound channel works the same
> way as the one sound channel did in z-spec 1.0'. There

Except that of course there have been two channels for about 3 years now, and
that's what all the current Z-machine + Blorb interpreters do.

You can't start denying that people are using Blorb with the Z-machine or
that interpreters exist.

> There is not a lot of game author complexity. There's one extra opcode.
> 
> Let's compare, shall we? You have eight physical channels, with a MOD
> playing on one and an AIFF on another.
> 
> Using your method, you check sound_data to find out how many channels you
> have left, and discover only three.

It wouldn't tell you how many channels, it would tell you that there wasn't
room, and that it would stop sound <n> if you played the proposed sound.
See the new draft posted a short while ago.

> You now know that if you play a new MOD, it will stop the oldest one
> playing. If that's what you want, you start the new sound. If that's not
> what you want, you either don't play the sound, or you stop a sound you
> don't mind losing and then play the new one.

Yes.

> 
> Using my method, you check sound_data to find out how many channels you
> have left, and discover only three. You now know that if you play a new
> MOD, it won't work.

How would you know a MOD needed >3 channels? You mean physical channels
rather than logical channels, I presume.

> If you decide that it's not that important, you don't even bother asking
> for the channel. If you do want to play the sound, you have to cut out
> another sound. So, you switch to the channel the sound you want to cut out
> is on, and start the new one, automatically interupting the one playing on
> that channel.

Okay.

> With the new design, plus the "does it fit" extension to sound_data that
> was discussed, you *can* play the same sound on multiple channels, and
> V6lib can automatically implement the situation of playing until you've run
> out of channels and then freeing up the oldest, by checking to see how many
> channels exist before a sound is played, and then checking to see how many
> exist afterwards. If the number hasn't changed, the sound isn't playing, so
> you cut the oldest channel and try again.

Can you draw up a formal proposal? ie replacements for the new @sound_data
and @sound_effect sections in the draft. I'm having trouble pinning this
down. Writing this sort of stuff down formally really helps clarify it in
both one's own head and other peoples.

> Thus the complexity for the user is dependant in both cases on what they
> wish to do, and how much nifty V6lib-like code is between them and the
> opcodes.
> 
> I still believe that my way is more powerful, and more faithful to the
> design of the Z-Machine.

I'd agree it's closer to the "only one channel" scheme, in that each channel
behaves like the 1 in the original Z-machine. But that Z-machine only played
mono effects, and no music. To achieve anything like the same simplicity
would require channel allocation to be limited to the lowest common
denominator - on my system only providing one channel, as I can only play
one MOD at once.

All existing Blorb-capable interpreters have two "channels" assigned
automatically. I am really not fond of the idea of back-tracking on that.

Any 1.1 interpreter will have to provide the old 1.0+Blorb behaviour too. We
already have one non backwards compatible extension to the Z-machine, and
that's called Glulx+Glk. We don't need another one.

> I'm sorry, I don't understand that. Callback handlers? Have I missed
> something?

When you play a sound, you can ask for a routine to be called when it's
finished. Please tell me you knew that. I'm probably using the wrong
terminology.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Dec 14 19:12:27 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com> <bada51e84a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] sound streams and spec 1.1
Date: Thu, 13 Dec 2001 17:44:05 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE694YdlbEwPIHn0TqF00001657@hotmail.com>
X-OriginalArrivalTime: 13 Dec 2001 17:38:19.0508 (UTC) FILETIME=[F4333B40:01C183FC]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
To: <z-machine@gmd.de>
Sent: Thursday, December 13, 2001 5:16 PM
Subject: Re: [z-machine] sound streams and spec 1.1


> In message <OE61xxLI9jtcEko8PU200001559@hotmail.com>
>           "Fillmore" <Noslwop@hotmail.com> wrote:
>
> >
> > That's not how my idea works. My idea is 'each sound channel works the
same
> > way as the one sound channel did in z-spec 1.0'. There
>
> Except that of course there have been two channels for about 3 years now,
and
> that's what all the current Z-machine + Blorb interpreters do.
>
> You can't start denying that people are using Blorb with the Z-machine or
> that interpreters exist.

I can start denying that two channels was ever part of the z-spec, because
it wasn't, it was part of the Blorb spec. And I can also say it's not too
late to change it now. There are very few Blorb games for the Z-Machine,
and if there are some in production, *now* is the time to get rid of the
seperate music/channels thing, assuming you believe, as I do, that it
should never have happened. If we wait until the system is used, then it's
too late.
>
> > There is not a lot of game author complexity. There's one extra opcode.
> >
> > Let's compare, shall we? You have eight physical channels, with a MOD
> > playing on one and an AIFF on another.
> >
> > Using your method, you check sound_data to find out how many channels
you
> > have left, and discover only three.
>
> It wouldn't tell you how many channels, it would tell you that there
wasn't
> room, and that it would stop sound <n> if you played the proposed sound.
> See the new draft posted a short while ago.

Does it? Must have missed that. Anyway, that just makes it easier. In both
cases,
you can check to see if the new sound has enough room to play. Simple.

> > You now know that if you play a new MOD, it will stop the oldest one
> > playing. If that's what you want, you start the new sound. If that's not
> > what you want, you either don't play the sound, or you stop a sound you
> > don't mind losing and then play the new one.
>
> Yes.
>
> >
> > Using my method, you check sound_data to find out how many channels you
> > have left, and discover only three. You now know that if you play a new
> > MOD, it won't work.
>
> How would you know a MOD needed >3 channels? You mean physical channels
> rather than logical channels, I presume.
>
> > If you decide that it's not that important, you don't even bother asking
> > for the channel. If you do want to play the sound, you have to cut out
> > another sound. So, you switch to the channel the sound you want to cut
out
> > is on, and start the new one, automatically interupting the one playing
on
> > that channel.
>
> Okay.
>
> > With the new design, plus the "does it fit" extension to sound_data that
> > was discussed, you *can* play the same sound on multiple channels, and
> > V6lib can automatically implement the situation of playing until you've
run
> > out of channels and then freeing up the oldest, by checking to see how
many
> > channels exist before a sound is played, and then checking to see how
many
> > exist afterwards. If the number hasn't changed, the sound isn't playing,
so
> > you cut the oldest channel and try again.
>
> Can you draw up a formal proposal? ie replacements for the new @sound_data
> and @sound_effect sections in the draft. I'm having trouble pinning this
> down. Writing this sort of stuff down formally really helps clarify it in
> both one's own head and other peoples.

Great idea. I'll do that in a minute.

> > Thus the complexity for the user is dependant in both cases on what they
> > wish to do, and how much nifty V6lib-like code is between them and the
> > opcodes.
> >
> > I still believe that my way is more powerful, and more faithful to the
> > design of the Z-Machine.
>
> I'd agree it's closer to the "only one channel" scheme, in that each
channel
> behaves like the 1 in the original Z-machine. But that Z-machine only
played
> mono effects, and no music. To achieve anything like the same simplicity
> would require channel allocation to be limited to the lowest common
> denominator - on my system only providing one channel, as I can only play
> one MOD at once.
>
> All existing Blorb-capable interpreters have two "channels" assigned
> automatically. I am really not fond of the idea of back-tracking on that.

I don't believe that's true. Nitfol supports blorb, and there is apparently
no way for it to support this. I don't know what Zip Infinity does offhand.
That's three blorb terps, with one supporting seperate music/effects, one
not, and one I'm not sure about.

> Any 1.1 interpreter will have to provide the old 1.0+Blorb behaviour too.
We
> already have one non backwards compatible extension to the Z-machine, and
> that's called Glulx+Glk. We don't need another one.

My point is, 1.0+Blorb behaviour is *not* current Z-Machine behaviour. If
I wrote my own sound format, with music and effects, and followed the 1.0
z-spec properly, there would be only one channel. It *may* be worthwhile
to have backwards compatiblity with the blorb spec, but I'm not happy
about the fact.

> > I'm sorry, I don't understand that. Callback handlers? Have I missed
> > something?
>
> When you play a sound, you can ask for a routine to be called when it's
> finished. Please tell me you knew that. I'm probably using the wrong
> terminology.

I did know that, I just didn't understand what you meant. You may be using
the correct terminology, but it didn't mean anything to me.

I'll write up my proposal properly and post it soon.

--
Fillmore


From ???@??? Fri Dec 14 19:12:31 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 13 Dec 2001 18:23:13 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] sound streams and spec 1.1
Message-ID: <b5f857e84a.kbracey@kbracey.cam.pace.co.uk>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com> 
 <bada51e84a.kbracey@kbracey.cam.pace.co.uk> <OE694YdlbEwPIHn0TqF00001657@hotmail.com>
In-Reply-To: <OE694YdlbEwPIHn0TqF00001657@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE694YdlbEwPIHn0TqF00001657@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> I can start denying that two channels was ever part of the z-spec, because
> it wasn't, it was part of the Blorb spec.

But by that logic, you might as well say "why use Blorb at all, it wasn't
part of the Z-spec?". Blorb was specifically written to be the standard
format of resources for the Z-machine, and the reason it isn't in the Z-spec
is only that the Z-spec predates it.

I know of at least 3 different interpreters on 3 different platforms handling
Blorb sound as it is written.

> And I can also say it's not too late to change it now. There are very few
> Blorb games for the Z-Machine, and if there are some in production, *now*
> is the time to get rid of the seperate music/channels thing, assuming you
> believe, as I do, that it should never have happened.

I'd agree that if you want to lose it, it had better be done as soon
possible. But I really don't feel terribly strongly about the separate
music/channels. When I was coding it in Zip 2000, it felt a sensible
pragmatic decision, as music and effects had to be handled very differently,
so it was helpful to keep them apart.

> If we wait until the system is used, then it's too late.

That's the point. I think it already is too late. The games aren't there, but
the interpreters are. There are already Z-machine + Blorb interpreters, and
have been for some time.

I'll accept the argument that this isn't a backwards compatibility problem
for the Z-machine in the purest sense, but it is certainly a backwards
compatibility problem for a Z-machine that implements Blorb, or Z-machine
games that want to use Blorb. And that's what we're interested in.

Trying to maintain this distinction between the Z-machine and Blorb seems to
be favouring theoretical layering distinctions over any sort of practical
usefulness.

I can see we're not going to agree on this one. We'll put it to the vote when
you've finalised a proposal.

> >
> > All existing Blorb-capable interpreters have two "channels" assigned
> > automatically. I am really not fond of the idea of back-tracking on that.
> 
> I don't believe that's true. Nitfol supports blorb, and there is apparently
> no way for it to support this. I don't know what Zip Infinity does offhand.
> That's three blorb terps, with one supporting seperate music/effects, one
> not, and one I'm not sure about.

Hmm. If Nitfol doesn't do it, then it's broken :) Nitfol has a number of
problems that arise from trying to do a Z-machine on top of unmodified Glk.
Sound is the least of them :)

Are there any other Blorb sound using interpreters at the moment? How many
platforms does Nitfol run on?

> My point is, 1.0+Blorb behaviour is *not* current Z-Machine behaviour. If
> I wrote my own sound format, with music and effects, and followed the 1.0
> z-spec properly, there would be only one channel.

Which is why the Blorb spec effectively had to revise the Z-spec to be
useful. I accept the Blorb spec revisions a sensible update to 1.0, and
they're incorporated in the 1.1 draft.

Now, in an alternate resource format, yes you might not have an effects/music
distinction. So you all the stuff in the 1.1 draft about the splits into
effects and music would no longer apply - everything would just be effects.

But again, that's favouring theory over usefulness. Can anyone seriously
conceive that someone will come up with a new, incompatible resource format?

> It *may* be worthwhile to have backwards compatiblity with the blorb spec,
> but I'm not happy about the fact.

The question is really, who is it hurting? Is the Blorb scheme really so bad
that you're prepared to introduce the compatibility problems associated with
revoking it? That would have to go to a vote.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Dec 14 19:12:40 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com> <bada51e84a.kbracey@kbracey.cam.pace.co.uk> <OE694YdlbEwPIHn0TqF00001657@hotmail.com> <b5f857e84a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] sound streams and spec 1.1
Date: Thu, 13 Dec 2001 20:40:10 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE29Xh3wFDxchdpqpEq00001825@hotmail.com>
X-OriginalArrivalTime: 13 Dec 2001 20:34:24.0654 (UTC) FILETIME=[8D8492E0:01C18415]
Sender: owner-z-machine@gmd.de
Precedence: bulk


Okay, here is my proposal for the sound support in Z-Machine 1.1 spec.
Read. Enjoy. Discuss.

@sound_data
-----------
New opcode in Standard 1.1, for Version 5 or later.

EXT:14 E 5 sound_data sound-number array ?(label)

Asks the interpreter for data on the sound with the given number.
If the sound can be played (i.e. if the sound number is valid, and
the sound is of a type supported by the interpreter, and the interpreter
has enough channels left to play the sound), a branch occurs and the
interpreter writes the type (1 for effect, 2 for music) in word 0 of
the array (This is an array, not a "table" with initial size
information.)

Otherwise, if the sound number is zero, the interpreter writes the number of
available (and supported) sounds into word 0 of the array and the release
number of the sounds file (eg from the Blorb RelN chunk) into word 1. A
branch occurs if the number of sounds is non-zero.

Otherwise, nothing happens.

@set_channel
------------
New opcode in Standard 1.1, for Version 5 or later.

EXT:30 1F 5 set_channel channel-number -> (result)

Sets the current sound channel to channel-number. The default
channel is channel 0.

However, there are an undefined number of sound channels available. When
a call to set_channel is made, the interpreter checks to see if there are
any sound channels left. If the interpreter successfully sets the channel,
it return 1. If the requested channel is unavailable, it returns 0.

If channel_number is -1, the result is the current channel number.

Different sound formats may take up different numbers of channels.
Therefore, successfully setting a channel does not mean the interpreter
will be able to play any given sound on the channel. Because of this,
it is recommended that the sound_data opcode is used to determine whether
the sound will successfully play.

@sound_effect
-------------
Standard 1.1 adds new behaviour to @sound_effect.

As of Standard 1.1, there is a header bit to indicate that the game wants to
use multiple sound channels and the interpreter can handle it.

If the multiple sound channels bit is clear (or not present), then
all effects default to stream 0 and all music (if supported) to stream 1.
This is the same as Standard 1.0 + Blorb 1.1. It is primarily provided
for backwards compatibility and is depreciated.

If the multiple sound channels bit is set, then the interpreter should play
the given sound on the currently selected sound channel. If a sound is
already playing on that channel, it is stopped, and the new sound started.

If the multiple sound channels bit is set, all sounds are treated equally,
except that sound_data can be used to determine whether a sound is an
effect or music. Any type of sound, effects or music, interrupts all types
of sound, effects or music, on the current channel.


From ???@??? Fri Dec 14 19:12:59 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <004601c18fe8$2da5a6a0$2e2986d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com> <bada51e84a.kbracey@kbracey.cam.pace.co.uk> <OE694YdlbEwPIHn0TqF00001657@hotmail.com> <b5f857e84a.kbracey@kbracey.cam.pace.co.uk> <OE29Xh3wFDxchdpqpEq00001825@hotmail.com>
Subject: Re: [z-machine] sound streams and spec 1.1
Date: Fri, 28 Dec 2001 21:39:17 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> @sound_data
> -----------
> New opcode in Standard 1.1, for Version 5 or later.
>
> EXT:14 E 5 sound_data sound-number array ?(label)
>
> Asks the interpreter for data on the sound with the given number.
> If the sound can be played (i.e. if the sound number is valid, and
> the sound is of a type supported by the interpreter, and the interpreter
> has enough channels left to play the sound),

More specifically - "can it be played in the current channel?"; it's got to
know what it is it will be replacing. Don't use the phrase "interpreter has
enough channels" - the terminology's confusing.

This still doesn't seem quite right. I think you need to be able to
distinguish between the sound being available and just having too many other
sounds ongoing.

But then we have an issue - do we insist that channels with nothing playing
on them don't consume resources, so it is sufficient to stop sounds on other
channels to try to make room for new sounds, or do we require the game to
release the other channels?

> a branch occurs and the
> interpreter writes the type (1 for effect, 2 for music) in word 0 of
> the array (This is an array, not a "table" with initial size
> information.)

In the channel-based scheme, I'm not sure that it's actually worth revealing
which sounds are effects and music.

You've taken out the "playing status" indication. I thought it was nice to
be able to see how long a sound had been playing (cunning synchronisation
effects, perhaps?)

If you're only outputting one value, you can make it a store instruction.

>
> @set_channel
> ------------
> New opcode in Standard 1.1, for Version 5 or later.
>
> EXT:30 1F 5 set_channel channel-number -> (result)
>
> Sets the current sound channel to channel-number. The default
> channel is channel 0.
>
> However, there are an undefined number of sound channels available. When
> a call to set_channel is made, the interpreter checks to see if there are
> any sound channels left. If the interpreter successfully sets the channel,
> it return 1. If the requested channel is unavailable, it returns 0.

I would suggest returning the previous channel, else zero, like set_font.
That would mean numbering them from 1 though.

>
> @sound_effect
> -------------
> Standard 1.1 adds new behaviour to @sound_effect.
>
> As of Standard 1.1, there is a header bit to indicate that the game wants
to
> use multiple sound channels and the interpreter can handle it.
>
> If the multiple sound channels bit is clear (or not present), then
> all effects default to stream 0 and all music (if supported) to stream 1.
> This is the same as Standard 1.0 + Blorb 1.1. It is primarily provided
> for backwards compatibility and is depreciated.

You mean deprecated :) I'm not sure whether it should be deprecated - it's
surely the common case that a lot of authors will want, that means they
won't have to worry about channel assignment.

You have a stronger requirement in the existing case - that it's always
possible to play music + effects simultaneously.

> If the multiple sound channels bit is set, then the interpreter should
play
> the given sound on the currently selected sound channel. If a sound is
> already playing on that channel, it is stopped, and the new sound started.

Presumably the same applies to the stop sound reason code - it only stops
the sound if it is playing in the current channel?

What about load and discard? Only affecting the current channel? So each
channel has a single loaded sound (at least)? I would suggest it's undefined
whether loading a new sound into a channel stops the existing sound - you
may have a channel-independent caching system, such as the one Zip 2000 uses
to make SONGs work well.

>
> If the multiple sound channels bit is set, all sounds are treated equally,
> except that sound_data can be used to determine whether a sound is an
> effect or music. Any type of sound, effects or music, interrupts all types
> of sound, effects or music, on the current channel.

The Blorb spec states that if music is requested on an interpreter that
doesn't handle it, the sound_effect opcode is ignored. That presumably still
stands.

--
Kevin



From ???@??? Fri Dec 14 19:13:01 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
To: kevin.bracey@pace.co.uk (Kevin Bracey)
Date: Thu, 13 Dec 2001 22:49:27 +0000 (GMT)
Cc: z-machine@gmd.de
In-Reply-To: <91042ee84a.kbracey@kbracey.cam.pace.co.uk> from "Kevin Bracey" at Dec 13, 2001 10:44:58 
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16EefP-0000L6-00@seasip.demon.co.uk>
From: John Elliott <jce@seasip.demon.co.uk>
Sender: owner-z-machine@gmd.de
Precedence: bulk


: Okay, we'll make that a clarification for the existing specw but I'm not
: quite sure how it helps. You're trying to cope with interpreters that never
: return 0 from set_font. Who would actually modify an interpreter to
: successfully return 0 from set_font 2 but not from all the other fonts?
:
: I've probably missed something :))

  I want "@set_font 2 returns nonzero" to indicate that the interpreter is 
buggy. If a non-buggy interpreter returns non-zero from @set_font 2 
(because the font is actually implemented) then it puts rather a spoke
in my assumptions. I don't need anyone to change existing buggy
interpreters; just to make sure that future Standard interpreters never 
implement font 2. 

-- 
John Elliott


From ???@??? Fri Dec 14 19:13:03 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com> <bada51e84a.kbracey@kbracey.cam.pace.co.uk> <OE694YdlbEwPIHn0TqF00001657@hotmail.com> <b5f857e84a.kbracey@kbracey.cam.pace.co.uk> <OE29Xh3wFDxchdpqpEq00001825@hotmail.com> <004601c18fe8$2da5a6a0$2e2986d9@oemcomputer>
Subject: Re: [z-machine] sound streams and spec 1.1
Date: Fri, 14 Dec 2001 01:00:17 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE31ZYhtBct79xdTDrk00001a5e@hotmail.com>
X-OriginalArrivalTime: 14 Dec 2001 00:54:32.0578 (UTC) FILETIME=[E490C620:01C18439]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
Sent: Friday, December 28, 2001 9:39 PM
Subject: Re: [z-machine] sound streams and spec 1.1


> > @sound_data
> > -----------
> > New opcode in Standard 1.1, for Version 5 or later.
> >
> > EXT:14 E 5 sound_data sound-number array ?(label)
> >
> > Asks the interpreter for data on the sound with the given number.
> > If the sound can be played (i.e. if the sound number is valid, and
> > the sound is of a type supported by the interpreter, and the interpreter
> > has enough channels left to play the sound),
>
> More specifically - "can it be played in the current channel?"; it's got
to
> know what it is it will be replacing. Don't use the phrase "interpreter
has
> enough channels" - the terminology's confusing.

Yeah, I know. I was somehow thinkig a channel didn't need to be selected,
but
of course a channel is always selected, so, yeah, can it be played in the
current channel is a better way of putting it,

> This still doesn't seem quite right. I think you need to be able to
> distinguish between the sound being available and just having too many
other
> sounds ongoing.

Well, we could write 'sound available' to word one and 'can be played in the
current channel to word two of the array.

> But then we have an issue - do we insist that channels with nothing
playing
> on them don't consume resources, so it is sufficient to stop sounds on
other
> channels to try to make room for new sounds, or do we require the game to
> release the other channels?
>
> > a branch occurs and the
> > interpreter writes the type (1 for effect, 2 for music) in word 0 of
> > the array (This is an array, not a "table" with initial size
> > information.)
>
> In the channel-based scheme, I'm not sure that it's actually worth
revealing
> which sounds are effects and music.

I agree, for the most part, except I left in the bit about different
channels
for music and sound when there aren't multiple sounds, for backwards
compatibility,
so, I decided to leave that in here as well. Maybe it should go.

> You've taken out the "playing status" indication. I thought it was nice to
> be able to see how long a sound had been playing (cunning synchronisation
> effects, perhaps?)

I liked it, too, but using it based on the sound number means that if the
same sound is playing more tha once, the information may well become
useless,
in both your scheme and mine. I thought about it for a bit, a decided if you
really wanted to measure time in tenths of a second, you can do it in
software,
for as many sounds as you like.

> If you're only outputting one value, you can make it a store instruction.

I'm only outputting one value unless the sound number is zero, in which case
I still output the number of available files and the release number.
Speaking
of the release number, the spec should state that if there is no release
number,
you get 0, or something like that. For pictures, too.

> >
> > @set_channel
> > ------------
> > New opcode in Standard 1.1, for Version 5 or later.
> >
> > EXT:30 1F 5 set_channel channel-number -> (result)
> >
> > Sets the current sound channel to channel-number. The default
> > channel is channel 0.
> >
> > However, there are an undefined number of sound channels available. When
> > a call to set_channel is made, the interpreter checks to see if there
are
> > any sound channels left. If the interpreter successfully sets the
channel,
> > it return 1. If the requested channel is unavailable, it returns 0.
>
> I would suggest returning the previous channel, else zero, like set_font.
> That would mean numbering them from 1 though.

Sounds good.

> >
> > @sound_effect
> > -------------
> > Standard 1.1 adds new behaviour to @sound_effect.
> >
> > As of Standard 1.1, there is a header bit to indicate that the game
wants
> to
> > use multiple sound channels and the interpreter can handle it.
> >
> > If the multiple sound channels bit is clear (or not present), then
> > all effects default to stream 0 and all music (if supported) to stream
1.
> > This is the same as Standard 1.0 + Blorb 1.1. It is primarily provided
> > for backwards compatibility and is depreciated.
>
> You mean deprecated :)

I do indeed. I can't believe I wrote that.

> I'm not sure whether it should be deprecated - it's
> surely the common case that a lot of authors will want, that means they
> won't have to worry about channel assignment.

Well, switching code from music/effects automatically on different channels
to music/effects manually on different channels means sticking
@set_channel 1 -> x; in front of all effects, and @set_channel 2 -> x; in
front of all music. Not a difficult thing to do, really, and it would give
exactly the same result, in a better manner. But if you can't be bothered,
it's not illegal to do it the other way, and it should work in any 1.1 terp.

> You have a stronger requirement in the existing case - that it's always
> possible to play music + effects simultaneously.
>
> > If the multiple sound channels bit is set, then the interpreter should
> play
> > the given sound on the currently selected sound channel. If a sound is
> > already playing on that channel, it is stopped, and the new sound
started.
>
> Presumably the same applies to the stop sound reason code - it only stops
> the sound if it is playing in the current channel?

Yes, that's right.

> What about load and discard? Only affecting the current channel? So each
> channel has a single loaded sound (at least)? I would suggest it's
undefined
> whether loading a new sound into a channel stops the existing sound - you
> may have a channel-independent caching system, such as the one Zip 2000
uses
> to make SONGs work well.

Sounds good (remembering that it's one in the morning here and I had to read
that three times before I think I understood it).

> >
> > If the multiple sound channels bit is set, all sounds are treated
equally,
> > except that sound_data can be used to determine whether a sound is an
> > effect or music. Any type of sound, effects or music, interrupts all
types
> > of sound, effects or music, on the current channel.
>
> The Blorb spec states that if music is requested on an interpreter that
> doesn't handle it, the sound_effect opcode is ignored. That presumably
still
> stands.

Yes. Actually, with multiple channels, it's probably possible to support all
music and no effects. It doesn't matter either way.

--
Fillmore


From ???@??? Fri Dec 14 19:13:04 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-eGroups-Return: z-machine-owner@mail.gmd.de
X-Yahoo-MsgId: <mta561.mail.yahoo.com.1008291604.96098.0042>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <E16EefP-0000L6-00@seasip.demon.co.uk>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
Date: Fri, 14 Dec 2001 01:04:27 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE12mLAztxc1o8yfogk00001a9c@hotmail.com>
X-OriginalArrivalTime: 14 Dec 2001 00:58:40.0790 (UTC) FILETIME=[7882EB60:01C1843A]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "John Elliott" <jce@seasip.demon.co.uk>
To: "Kevin Bracey" <kevin.bracey@pace.co.uk>
Cc: <z-machine@gmd.de>
Sent: Thursday, December 13, 2001 10:49 PM
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt


> : Okay, we'll make that a clarification for the existing specw but I'm not
> : quite sure how it helps. You're trying to cope with interpreters that
never
> : return 0 from set_font. Who would actually modify an interpreter to
> : successfully return 0 from set_font 2 but not from all the other fonts?
> :
> : I've probably missed something :))
>
>   I want "@set_font 2 returns nonzero" to indicate that the interpreter is
> buggy. If a non-buggy interpreter returns non-zero from @set_font 2
> (because the font is actually implemented) then it puts rather a spoke
> in my assumptions. I don't need anyone to change existing buggy
> interpreters; just to make sure that future Standard interpreters never
> implement font 2.

If the interpreter is buggy, it doesn't matter what the spec says, really.
I think this is a bad thing to rely on. In my code, I just check to see
if the spec number is >= 1.0. If it says it is, and it says it supports
any given font, that should be enough. If it's buggy, it needs fixing,
not hacking around.

The problem is, font 2 probably does, or did, have a specification
somewhere. If it is ever discovered what this specification is, and
it's not something really ugly and useless, it will probably become
a part of the spec. So, saying 'need not' is better than 'may not',
really.

--
Fillmore



From ???@??? Fri Dec 14 19:13:05 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.13.224]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] sound streams and spec 1.1
Date: Thu, 13 Dec 2001 20:26:52 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F11493XAg0pepP1znXg000036fd@hotmail.com>
X-OriginalArrivalTime: 14 Dec 2001 01:26:52.0944 (UTC) FILETIME=[691D2100:01C1843E]
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>


>All existing Blorb-capable interpreters have two "channels" assigned
>automatically. I am really not fond of the idea of back-tracking on that.
>
Nitfol doesn't.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


</x-flowed>
From ???@??? Fri Dec 14 21:18:21 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp1.ihug.co.nz: Host p80-tnt7.akl.ihug.co.nz [203.173.206.80] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20011214205438.072c6a00@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 14 Dec 2001 21:08:00 +1300
To: "z-machine mailing list" <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Z-Machine Standard 1.1 Proposal - 1st attempt
In-Reply-To: <OE12mLAztxc1o8yfogk00001a9c@hotmail.com>
References: <E16EefP-0000L6-00@seasip.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 01:04 14/12/01 +0000, Fillmore wrote:
 >
 >The problem is, font 2 probably does, or did, have a 
specification
 >somewhere. If it is ever discovered what this specification is,
 >and it's not something really ugly and useless, it will probably 

 >become a part of the spec. So, saying 'need not' is better than
 >'may not', really.

I always thought that font 2 was originally for runic characters, 
as also seen in the Ultima games (yes, I know they're not 
Z-Machine games).

I agree, though, the standard should say that set_font returns 
zero for any font not supported by the interpreter, not that 
set_font 2 will always return zero.  It is possible that standard 
x.y sometime in the future will define a standard font 2.


And regarding the sound vs. music channels issue; I'm not really 
for or against either side.  I believe that having interchangeable 
channels would be an implementation nightmare, but if people can 
come up with a good way to make it work, go for it :)

The thing is that it sounds like either a restriction to the 
lowest common denominator (I have eight physical channels, you 
might want to play two four-channel MODs simultaeneously, so only 
two z-channels exist at all times) or channel existence 
fluctuations depending on what else is playing (I'm playing a MOD, 
so only five z-channels exist.  Wait, now I'm playing a stereo 
sound too, so now there's only four z-channels.  Now the sound has 
stopped but I've started another MOD, so there's only two 
z-channels.  Everything's stopped, now 8 z-channels exist)  That's 
what I meant by author complexity.  Unless they're very careful 
they can never be sure how many channels are available at any 
given time (without explicitly asking), leading to 
unpredictability of playing sounds.
-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
Ambivalent?  Well, yes and no.


</x-flowed>
From ???@??? Mon Dec 17 19:36:08 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <003401c1865f$03cbfd80$6c2886d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com> <bada51e84a.kbracey@kbracey.cam.pace.co.uk> <OE694YdlbEwPIHn0TqF00001657@hotmail.com> <b5f857e84a.kbracey@kbracey.cam.pace.co.uk> <OE29Xh3wFDxchdpqpEq00001825@hotmail.com> <004601c18fe8$2da5a6a0$2e2986d9@oemcomputer> <OE31ZYhtBct79xdTDrk00001a5e@hotmail.com>
Subject: Re: [z-machine] sound streams and spec 1.1
Date: Sun, 16 Dec 2001 18:11:50 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> > But then we have an issue - do we insist that channels with nothing
> playing
> > on them don't consume resources, so it is sufficient to stop sounds on
> other
> > channels to try to make room for new sounds, or do we require the game
to
> > release the other channels?

You haven't answered this question. I would say the former.

>
> > You've taken out the "playing status" indication. I thought it was nice
to
> > be able to see how long a sound had been playing (cunning
synchronisation
> > effects, perhaps?)
>
> I liked it, too, but using it based on the sound number means that if the
> same sound is playing more tha once, the information may well become
> useless,
> in both your scheme and mine. I thought about it for a bit, a decided if
you
> really wanted to measure time in tenths of a second, you can do it in
> software,
> for as many sounds as you like.

No, you can't reliably time stuff in the Z-machine. You can make read
opcodes wait for a time, but you can't tell how long stuff like printing
takes; it could take forever if a [MORE] prompt appears. There's no way of
calculating elapsed time since a point.

> > I'm not sure whether it should be deprecated - it's
> > surely the common case that a lot of authors will want, that means they
> > won't have to worry about channel assignment.
>
> Well, switching code from music/effects automatically on different
channels
> to music/effects manually on different channels means sticking
> @set_channel 1 -> x; in front of all effects, and @set_channel 2 -> x; in
> front of all music. Not a difficult thing to do, really, and it would give
> exactly the same result, in a better manner. But if you can't be bothered,
> it's not illegal to do it the other way, and it should work in any 1.1
terp.

I don't like it because it's a new opcode that would cause all existing
interpreters to crash if they encountered it, meaning a forced "if
(standard_interpreter > $0101)" check on every attempt to play sound.

>
> > What about load and discard? Only affecting the current channel? So each
> > channel has a single loaded sound (at least)? I would suggest it's
> undefined
> > whether loading a new sound into a channel stops the existing sound -
you
> > may have a channel-independent caching system, such as the one Zip 2000
> uses
> > to make SONGs work well.
>
> Sounds good (remembering that it's one in the morning here and I had to
read
> that three times before I think I understood it).

Which I think sums up my problem with the whole scheme. It _sounds_ simple
to just map sounds to channels, but in actual practice it'll end up being
complicated for both game authors and interpreter authors. You'll have
seemingly equivalent channels and sounds that aren't in practice, the
possibility of being unable to play a new sound without manually stopping an
earlier sound, and Z-machine channel numbers that perforce bear no relation
to any physical machine channels.

Kevin
-----



From ???@??? Mon Dec 17 19:36:08 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <003501c188bc$10b4d440$6c2886d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
Subject: [z-machine] Vote on sound proposals
Date: Wed, 19 Dec 2001 18:36:22 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


I think the only thing holding up finalisation of Standard 1.1 is the debate
over sound. Jason put a pointer to the list up on raif a number of days ago,
so hopefully everyone who's interested is here.

Let's have a vote. We may as well do it publically on the list, as I don't
think there are that many people here (although I'd be happy to be proved
wrong). The question is: which sound system should be used as the basis of
Standard 1.1?

      A) The sound/music scheme in draft 2, on Jason's site
      B) The @set_channel scheme proposed by Fillmore
      C) Status quo - leave it as Standard 1.0 + Blorb 1.1
      D) Re-open discussions

Whichever is chosen would still be open for further refinement before the
final Standard is decided, but the first two have a fundamental
philosophical disagreement that needs to be decided one way or the other.

Everyone interested should reply to the list filling in the following form,
giving each option a ranking from 1 (most preferred) to 4 (least preferred).
Items may be given equal rankings, or boxes may be left blank (equivalent to
ranking them equal last).

Voting closes at 18:30 UTC on 19 December 2001. Votes will be counted
according to the Concordet method (examples at
http://www.ukvoting.org.uk/resources/condorcet-guide.html), with no required
margin over the status quo.

There will be another vote later to approve the final Standard 1.1 draft in
its entirety.

Kevin
-----

---------Voting form---------
    Option A:   [   ]
    Option B:   [   ]
    Option C:   [   ]
    Option D:   [   ]
-----------------------------



From ???@??? Mon Dec 17 19:36:09 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <004b01c188bc$b79af6e0$6c2886d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <003501c188bc$10b4d440$6c2886d9@oemcomputer>
Subject: Re: [z-machine] Vote on sound proposals
Date: Wed, 19 Dec 2001 18:41:02 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> ---------Voting form---------
>     Option A:   [ 1 ]
>     Option B:   [ 2 ]
>     Option C:   [ 4 ]
>     Option D:   [ 3 ]
> -----------------------------



From ???@??? Mon Dec 17 19:36:10 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <003501c188bc$10b4d440$6c2886d9@oemcomputer>
Subject: Re: [z-machine] Vote on sound proposals
Date: Sun, 16 Dec 2001 19:18:06 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE41bl71Ri4wXCPa8lM00003138@hotmail.com>
X-OriginalArrivalTime: 16 Dec 2001 19:12:19.0896 (UTC) FILETIME=[955F6380:01C18665]
Sender: owner-z-machine@gmd.de
Precedence: bulk


> ---------Voting form---------
>     Option A:   [ 2 ]
>     Option B:   [ 1 ]
>     Option C:   [ 4 ]
>     Option D:   [ 3 ]
> -----------------------------


From ???@??? Mon Dec 17 19:36:13 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Sun, 16 Dec 2001 17:17:12 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Vote on sound proposals
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C1CD718.10786.A738CB3@localhost>
In-reply-to: <20011216191232.4F51430805B@fauna.jczorkmid.net>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Sorry, 

I'm having a bad day... I meant:

---------Voting form---------
     Option A:   [ 1 ]
     Option B:   [ 2 ]
     Option C:   [ 4 ]
     Option D:   [ 3 ]
 -----------------------------


Jason Penney sent a message across the ether on 16 Dec 2001 (14:12) 
stating:

> > ---------Voting form---------
> >     Option A:   [ 2 ]
> >     Option B:   [ 1 ]
> >     Option C:   [ 4 ]
> >     Option D:   [ 3 ]
> > -----------------------------

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Mon Dec 17 19:36:16 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 17 Dec 2001 02:37:35 +0200 (EET)
From: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
To: <z-machine@gmd.de>
Subject: Re: [z-machine] Vote on sound proposals
In-Reply-To: <003501c188bc$10b4d440$6c2886d9@oemcomputer>
Message-ID: <Pine.OSF.4.30.0112170229010.16903-100000@vesuri.Helsinki.FI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@gmd.de
Precedence: bulk



Hello everyone,

On Wed, 19 Dec 2001, Kevin Bracey wrote:

[snip vote proposal]
[snip choices except...]
>       B) The @set_channel scheme proposed by Fillmore

Ah.. there's the rub.  Those of us that joined after Jason
Penney's call for participation on raif, haven't seen this
proposal.  I joined on Dec. 14th, the day after the post to raif.

Regards,

Joonas




From ???@??? Mon Dec 17 19:36:17 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Sun, 16 Dec 2001 20:00:26 -0500
MIME-Version: 1.0
Subject: [REPOST] Re: [z-machine] sound streams and spec 1.1
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C1CFD5A.15462.1F124E@localhost>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


I think this is the proposal and all the important discussion that 
occurred before the vote.  Hope this helps everyone.  If I left 
something out please post it.

Jay

------- Forwarded message follows -------
From:           	"Fillmore" <Noslwop@hotmail.com>
To:             	"z-machine mailing list" <z-machine@gmd.de>
Subject:        	Re: [z-machine] sound streams and spec 1.1
Date sent:      	Thu, 13 Dec 2001 20:40:10 -0000

Okay, here is my proposal for the sound support in Z-Machine 1.1 spec.
Read. Enjoy. Discuss.

@sound_data
-----------
New opcode in Standard 1.1, for Version 5 or later.

EXT:14 E 5 sound_data sound-number array ?(label)

Asks the interpreter for data on the sound with the given number.
If the sound can be played (i.e. if the sound number is valid, and
the sound is of a type supported by the interpreter, and the interpreter
has enough channels left to play the sound), a branch occurs and the
interpreter writes the type (1 for effect, 2 for music) in word 0 of
the array (This is an array, not a "table" with initial size
information.)

Otherwise, if the sound number is zero, the interpreter writes the 
number of
available (and supported) sounds into word 0 of the array and the 
release
number of the sounds file (eg from the Blorb RelN chunk) into word 1. A
branch occurs if the number of sounds is non-zero.

Otherwise, nothing happens.

@set_channel
------------
New opcode in Standard 1.1, for Version 5 or later.

EXT:30 1F 5 set_channel channel-number -> (result)

Sets the current sound channel to channel-number. The default
channel is channel 0.

However, there are an undefined number of sound channels available. When
a call to set_channel is made, the interpreter checks to see if there 
are
any sound channels left. If the interpreter successfully sets the 
channel,
it return 1. If the requested channel is unavailable, it returns 0.

If channel_number is -1, the result is the current channel number.

Different sound formats may take up different numbers of channels.
Therefore, successfully setting a channel does not mean the interpreter
will be able to play any given sound on the channel. Because of this,
it is recommended that the sound_data opcode is used to determine 
whether
the sound will successfully play.

@sound_effect
-------------
Standard 1.1 adds new behaviour to @sound_effect.

As of Standard 1.1, there is a header bit to indicate that the game 
wants to
use multiple sound channels and the interpreter can handle it.

If the multiple sound channels bit is clear (or not present), then
all effects default to stream 0 and all music (if supported) to stream 
1.
This is the same as Standard 1.0 + Blorb 1.1. It is primarily provided
for backwards compatibility and is depreciated.

If the multiple sound channels bit is set, then the interpreter should 
play
the given sound on the currently selected sound channel. If a sound is
already playing on that channel, it is stopped, and the new sound 
started.

If the multiple sound channels bit is set, all sounds are treated 
equally,
except that sound_data can be used to determine whether a sound is an
effect or music. Any type of sound, effects or music, interrupts all 
types
of sound, effects or music, on the current channel.

------- End of forwarded message -------


------- Forwarded message follows -------
From:           	"Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To:             	<z-machine@gmd.de>
Subject:        	Re: [z-machine] sound streams and spec 1.1
Date sent:      	Fri, 28 Dec 2001 21:39:17 -0000

> @sound_data
> -----------
> New opcode in Standard 1.1, for Version 5 or later.
>
> EXT:14 E 5 sound_data sound-number array ?(label)
>
> Asks the interpreter for data on the sound with the given number.
> If the sound can be played (i.e. if the sound number is valid, and
> the sound is of a type supported by the interpreter, and the 
interpreter
> has enough channels left to play the sound),

More specifically - "can it be played in the current channel?"; it's got 
to
know what it is it will be replacing. Don't use the phrase "interpreter 
has
enough channels" - the terminology's confusing.

This still doesn't seem quite right. I think you need to be able to
distinguish between the sound being available and just having too many 
other
sounds ongoing.

But then we have an issue - do we insist that channels with nothing 
playing
on them don't consume resources, so it is sufficient to stop sounds on 
other
channels to try to make room for new sounds, or do we require the game 
to
release the other channels?

> a branch occurs and the
> interpreter writes the type (1 for effect, 2 for music) in word 0 of
> the array (This is an array, not a "table" with initial size
> information.)

In the channel-based scheme, I'm not sure that it's actually worth 
revealing
which sounds are effects and music.

You've taken out the "playing status" indication. I thought it was nice 
to
be able to see how long a sound had been playing (cunning 
synchronisation
effects, perhaps?)

If you're only outputting one value, you can make it a store 
instruction.

>
> @set_channel
> ------------
> New opcode in Standard 1.1, for Version 5 or later.
>
> EXT:30 1F 5 set_channel channel-number -> (result)
>
> Sets the current sound channel to channel-number. The default
> channel is channel 0.
>
> However, there are an undefined number of sound channels available. 
When
> a call to set_channel is made, the interpreter checks to see if there 
are
> any sound channels left. If the interpreter successfully sets the 
channel,
> it return 1. If the requested channel is unavailable, it returns 0.

I would suggest returning the previous channel, else zero, like 
set_font.
That would mean numbering them from 1 though.

>
> @sound_effect
> -------------
> Standard 1.1 adds new behaviour to @sound_effect.
>
> As of Standard 1.1, there is a header bit to indicate that the game 
wants
to
> use multiple sound channels and the interpreter can handle it.
>
> If the multiple sound channels bit is clear (or not present), then
> all effects default to stream 0 and all music (if supported) to stream 
1.
> This is the same as Standard 1.0 + Blorb 1.1. It is primarily provided
> for backwards compatibility and is depreciated.

You mean deprecated :) I'm not sure whether it should be deprecated - 
it's
surely the common case that a lot of authors will want, that means they
won't have to worry about channel assignment.

You have a stronger requirement in the existing case - that it's always
possible to play music + effects simultaneously.

> If the multiple sound channels bit is set, then the interpreter should
play
> the given sound on the currently selected sound channel. If a sound is
> already playing on that channel, it is stopped, and the new sound 
started.

Presumably the same applies to the stop sound reason code - it only 
stops
the sound if it is playing in the current channel?

What about load and discard? Only affecting the current channel? So each
channel has a single loaded sound (at least)? I would suggest it's 
undefined
whether loading a new sound into a channel stops the existing sound - 
you
may have a channel-independent caching system, such as the one Zip 2000 
uses
to make SONGs work well.

>
> If the multiple sound channels bit is set, all sounds are treated 
equally,
> except that sound_data can be used to determine whether a sound is an
> effect or music. Any type of sound, effects or music, interrupts all 
types
> of sound, effects or music, on the current channel.

The Blorb spec states that if music is requested on an interpreter that
doesn't handle it, the sound_effect opcode is ignored. That presumably 
still
stands.

--
Kevin


------- End of forwarded message -------


------- Forwarded message follows -------
From:           	"Fillmore" <Noslwop@hotmail.com>
To:             	"z-machine mailing list" <z-machine@gmd.de>
Subject:        	Re: [z-machine] sound streams and spec 1.1
Date sent:      	Fri, 14 Dec 2001 01:00:17 -0000

----- Original Message -----
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
Sent: Friday, December 28, 2001 9:39 PM
Subject: Re: [z-machine] sound streams and spec 1.1


> > @sound_data
> > -----------
> > New opcode in Standard 1.1, for Version 5 or later.
> >
> > EXT:14 E 5 sound_data sound-number array ?(label)
> >
> > Asks the interpreter for data on the sound with the given number.
> > If the sound can be played (i.e. if the sound number is valid, and
> > the sound is of a type supported by the interpreter, and the 
interpreter
> > has enough channels left to play the sound),
>
> More specifically - "can it be played in the current channel?"; it's 
got
to
> know what it is it will be replacing. Don't use the phrase 
"interpreter
has
> enough channels" - the terminology's confusing.

Yeah, I know. I was somehow thinkig a channel didn't need to be 
selected,
but
of course a channel is always selected, so, yeah, can it be played in 
the
current channel is a better way of putting it,

> This still doesn't seem quite right. I think you need to be able to
> distinguish between the sound being available and just having too many
other
> sounds ongoing.

Well, we could write 'sound available' to word one and 'can be played in 
the
current channel to word two of the array.

> But then we have an issue - do we insist that channels with nothing
playing
> on them don't consume resources, so it is sufficient to stop sounds on
other
> channels to try to make room for new sounds, or do we require the game 
to
> release the other channels?
>
> > a branch occurs and the
> > interpreter writes the type (1 for effect, 2 for music) in word 0 of
> > the array (This is an array, not a "table" with initial size
> > information.)
>
> In the channel-based scheme, I'm not sure that it's actually worth
revealing
> which sounds are effects and music.

I agree, for the most part, except I left in the bit about different
channels
for music and sound when there aren't multiple sounds, for backwards
compatibility,
so, I decided to leave that in here as well. Maybe it should go.

> You've taken out the "playing status" indication. I thought it was 
nice to
> be able to see how long a sound had been playing (cunning 
synchronisation
> effects, perhaps?)

I liked it, too, but using it based on the sound number means that if 
the
same sound is playing more tha once, the information may well become
useless,
in both your scheme and mine. I thought about it for a bit, a decided if 
you
really wanted to measure time in tenths of a second, you can do it in
software,
for as many sounds as you like.

> If you're only outputting one value, you can make it a store 
instruction.

I'm only outputting one value unless the sound number is zero, in which 
case
I still output the number of available files and the release number.
Speaking
of the release number, the spec should state that if there is no release
number,
you get 0, or something like that. For pictures, too.

> >
> > @set_channel
> > ------------
> > New opcode in Standard 1.1, for Version 5 or later.
> >
> > EXT:30 1F 5 set_channel channel-number -> (result)
> >
> > Sets the current sound channel to channel-number. The default
> > channel is channel 0.
> >
> > However, there are an undefined number of sound channels available. 
When
> > a call to set_channel is made, the interpreter checks to see if 
there
are
> > any sound channels left. If the interpreter successfully sets the
channel,
> > it return 1. If the requested channel is unavailable, it returns 0.
>
> I would suggest returning the previous channel, else zero, like 
set_font.
> That would mean numbering them from 1 though.

Sounds good.

> >
> > @sound_effect
> > -------------
> > Standard 1.1 adds new behaviour to @sound_effect.
> >
> > As of Standard 1.1, there is a header bit to indicate that the game
wants
> to
> > use multiple sound channels and the interpreter can handle it.
> >
> > If the multiple sound channels bit is clear (or not present), then
> > all effects default to stream 0 and all music (if supported) to 
stream
1.
> > This is the same as Standard 1.0 + Blorb 1.1. It is primarily 
provided
> > for backwards compatibility and is depreciated.
>
> You mean deprecated :)

I do indeed. I can't believe I wrote that.

> I'm not sure whether it should be deprecated - it's
> surely the common case that a lot of authors will want, that means 
they
> won't have to worry about channel assignment.

Well, switching code from music/effects automatically on different 
channels
to music/effects manually on different channels means sticking
@set_channel 1 -> x; in front of all effects, and @set_channel 2 -> x; 
in
front of all music. Not a difficult thing to do, really, and it would 
give
exactly the same result, in a better manner. But if you can't be 
bothered,
it's not illegal to do it the other way, and it should work in any 1.1 
terp.

> You have a stronger requirement in the existing case - that it's 
always
> possible to play music + effects simultaneously.
>
> > If the multiple sound channels bit is set, then the interpreter 
should
> play
> > the given sound on the currently selected sound channel. If a sound 
is
> > already playing on that channel, it is stopped, and the new sound
started.
>
> Presumably the same applies to the stop sound reason code - it only 
stops
> the sound if it is playing in the current channel?

Yes, that's right.

> What about load and discard? Only affecting the current channel? So 
each
> channel has a single loaded sound (at least)? I would suggest it's
undefined
> whether loading a new sound into a channel stops the existing sound - 
you
> may have a channel-independent caching system, such as the one Zip 
2000
uses
> to make SONGs work well.

Sounds good (remembering that it's one in the morning here and I had to 
read
that three times before I think I understood it).

> >
> > If the multiple sound channels bit is set, all sounds are treated
equally,
> > except that sound_data can be used to determine whether a sound is 
an
> > effect or music. Any type of sound, effects or music, interrupts all
types
> > of sound, effects or music, on the current channel.
>
> The Blorb spec states that if music is requested on an interpreter 
that
> doesn't handle it, the sound_effect opcode is ignored. That presumably
still
> stands.

Yes. Actually, with multiple channels, it's probably possible to support 
all
music and no effects. It doesn't matter either way.

--
Fillmore

------- End of forwarded message -------

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Wed Dec 19 21:11:36 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 17 Dec 2001 09:34:51 -0500
Mime-Version: 1.0 (Apple Message framework v475)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Re: [z-machine] Vote on sound proposals
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
Message-Id: <3A8E74CA-F2FB-11D5-A881-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

---------Voting form---------
     Option A:   [ 2]
     Option B:   [ 4]
     Option C:   [ 1]
     Option D:   [ 3]
-----------------------------


</x-flowed>
From ???@??? Wed Dec 19 21:11:41 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com> <bada51e84a.kbracey@kbracey.cam.pace.co.uk> <OE694YdlbEwPIHn0TqF00001657@hotmail.com> <b5f857e84a.kbracey@kbracey.cam.pace.co.uk> <OE29Xh3wFDxchdpqpEq00001825@hotmail.com> <004601c18fe8$2da5a6a0$2e2986d9@oemcomputer> <OE31ZYhtBct79xdTDrk00001a5e@hotmail.com> <003401c1865f$03cbfd80$6c2886d9@oemcomputer>
Subject: Re: [z-machine] sound streams and spec 1.1
Date: Mon, 17 Dec 2001 16:28:26 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE62iZZyDw5fX4svGR500003a4b@hotmail.com>
X-OriginalArrivalTime: 17 Dec 2001 16:22:40.0007 (UTC) FILETIME=[0C195970:01C18717]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
Sent: Sunday, December 16, 2001 6:11 PM
Subject: Re: [z-machine] sound streams and spec 1.1


> > > But then we have an issue - do we insist that channels with nothing
> > playing
> > > on them don't consume resources, so it is sufficient to stop sounds on
> > other
> > > channels to try to make room for new sounds, or do we require the game
> to
> > > release the other channels?
>
> You haven't answered this question. I would say the former.

I would say the former, yes.

> >
> > > You've taken out the "playing status" indication. I thought it was
nice
> to
> > > be able to see how long a sound had been playing (cunning
> synchronisation
> > > effects, perhaps?)
> >
> > I liked it, too, but using it based on the sound number means that if
the
> > same sound is playing more tha once, the information may well become
> > useless,
> > in both your scheme and mine. I thought about it for a bit, a decided if
> you
> > really wanted to measure time in tenths of a second, you can do it in
> > software,
> > for as many sounds as you like.
>
> No, you can't reliably time stuff in the Z-machine. You can make read
> opcodes wait for a time, but you can't tell how long stuff like printing
> takes; it could take forever if a [MORE] prompt appears. There's no way of
> calculating elapsed time since a point.

You are, of course, entirely correct. Still, this was something I could
see problems with in both sound support specifications.

> > > I'm not sure whether it should be deprecated - it's
> > > surely the common case that a lot of authors will want, that means
they
> > > won't have to worry about channel assignment.
> >
> > Well, switching code from music/effects automatically on different
> channels
> > to music/effects manually on different channels means sticking
> > @set_channel 1 -> x; in front of all effects, and @set_channel 2 -> x;
in
> > front of all music. Not a difficult thing to do, really, and it would
give
> > exactly the same result, in a better manner. But if you can't be
bothered,
> > it's not illegal to do it the other way, and it should work in any 1.1
> terp.
>
> I don't like it because it's a new opcode that would cause all existing
> interpreters to crash if they encountered it, meaning a forced "if
> (standard_interpreter > $0101)" check on every attempt to play sound.

We already have to check if sound is on, and if there are multiple channels,
anyway. And we have to check if standard_interpreter > $0101 if we want to
find out if a sound exists in the first place. How is this different?

> >
> > > What about load and discard? Only affecting the current channel? So
each
> > > channel has a single loaded sound (at least)? I would suggest it's
> > undefined
> > > whether loading a new sound into a channel stops the existing sound -
> you
> > > may have a channel-independent caching system, such as the one Zip
2000
> > uses
> > > to make SONGs work well.
> >
> > Sounds good (remembering that it's one in the morning here and I had to
> read
> > that three times before I think I understood it).
>
> Which I think sums up my problem with the whole scheme. It _sounds_ simple
> to just map sounds to channels, but in actual practice it'll end up being
> complicated for both game authors and interpreter authors. You'll have
> seemingly equivalent channels and sounds that aren't in practice, the
> possibility of being unable to play a new sound without manually stopping
an
> earlier sound, and Z-machine channel numbers that perforce bear no
relation
> to any physical machine channels.

You don't have to manually stop an old sound at all. It's just that the
sound
that is automatically stopped is a different one to the one in your scheme.
Either
way, if you want to stop a different sound than the default one (the first
one
started, I think it was, on yours, or the one on the current channel on
mine),
you call two opcodes. It's just different opcodes.

Anyway, it hardly matters. My scheme as it is now is almost the same as
yours
anyway, and not very much like I actually thought it should go. Whatever
happens, I can live with the outcome.

--
Fillmore


From ???@??? Wed Dec 19 21:11:42 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 17 Dec 2001 16:42:15 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] sound streams and spec 1.1
Message-ID: <8a125eea4a.kbracey@kbracey.cam.pace.co.uk>
References: <20011212183417.633D730805B@fauna.jczorkmid.net> <acff30e84a.kbracey@kbracey.cam.pace.co.uk> <OE61xxLI9jtcEko8PU200001559@hotmail.com> 
 <bada51e84a.kbracey@kbracey.cam.pace.co.uk> <OE694YdlbEwPIHn0TqF00001657@hotmail.com> <b5f857e84a.kbracey@kbracey.cam.pace.co.uk> 
 <OE29Xh3wFDxchdpqpEq00001825@hotmail.com> <OE31ZYhtBct79xdTDrk00001a5e@hotmail.com> <OE62iZZyDw5fX4svGR500003a4b@hotmail.com>
In-Reply-To: <OE62iZZyDw5fX4svGR500003a4b@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE62iZZyDw5fX4svGR500003a4b@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> >
> > I don't like it because it's a new opcode that would cause all existing
> > interpreters to crash if they encountered it, meaning a forced "if
> > (standard_interpreter > $0101)" check on every attempt to play sound.
> 
> We already have to check if sound is on, and if there are multiple
> channels, anyway. And we have to check if standard_interpreter > $0101 if
> we want to find out if a sound exists in the first place. How is this
> different?

My point was that a new opcode is required on every sound play, not just
initialisation, if you're mixing music and effects and want to keep them
separate. You wouldn't normally ever need to issue the new @sound_data
opcode, as you should know what's in your Blorb file.

> You don't have to manually stop an old sound at all. It's just that the
> sound that is automatically stopped is a different one to the one in your
> scheme.

But you might have to stop extra sounds beyond the one already on in the
current channel - for example a channel might have had enough room in to play
the mono effect you played first, but a later stereo one (or piece of music)
doesn't fit, thus needing you to stop another channel too. The only
alternative is to pre-allocate enough space in each channel for every
possible sound, or to somehow indicate on channel creation what sounds it
will be used for.

> Either way, if you want to stop a different sound than the default one (the
> first one started, I think it was, on yours, or the one on the current
> channel on mine), you call two opcodes. It's just different opcodes.

Yes, but the other sounds can be stopped automatically in the original
scheme.

> 
> Anyway, it hardly matters. My scheme as it is now is almost the same as
> yours anyway, and not very much like I actually thought it should go.

Actually that's true of the version in draft 2 as well - Jason and I were
bashing it backwards and forwards over a week before it came out as it did in
draft 1, and it's now got some input from discussions here.

Sadly, when standardising, what start off looking like simple schemes rapidly
grow all sorts of annoying little wrinkles :)

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 20 23:43:11 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 19 Dec 2001 11:45:52 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Message-ID: <0f9c4aeb4a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] Character sets and stuff
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


I was recently having a discussion with Fredrik Ramsberg, who's producing
a Swedish translation of the Inform library, and filling him in on the
way character sets work in the Z-machine. During this discussion, a few more
things to go into the standard occurred to me. For one, I was reminded of the
fact that to produce, say, a Japanese game would be pretty infeasible.

There's one fundamental restriction that input is restricted to ZSCII, as it
comes in as a byte array of ZSCII characters from @read, or a ZSCII code from
@read_char. I'm not sure whether that it's worth lifting this restriction, as
any ideographic language can be (and usually is) input phonetically using a
restricted alphabet - the parser and grammar could be based on phonetic
forms. Does anyone know what the Japanese Zork did for input?

Any arbitrary Unicode character can be output, but the ONLY way of outputting
characters not in the ZSCII set is through the @print_unicode opcode. This
can work, but is highly inefficient (5 bytes per character), and you can only
do it in code - there would be no way of including Japanese text in strings.

What I'm considering adding to Standard 1.1 is a mechanism for encoding
arbitrary Unicode characters into strings, by using ZSCII codes above 255.
In addition, I'd like to add some clarifications to existing behaviour,
including notes on basic punctuation.

Here are my initial proposals. Let me know what you think.


                          UPDATES/CLARIFICATIONS
                          ======================
Character set
-------------
In the past, not just in the Z-machine world, there has been general
confusion over the rendering of ASCII/ZSCII/Latin-1/Unicode characters $27
and $60. For the Z-machine, the traditional interpretations of
right-single-quote/apostrophe and left-single-quote are preferred over the
modern neutral-single-quote and grave accent - see Table 2A of the Inform
Designer's Manual. $22 is a neutral double-quote.

An alternative rendering is to interpret both $27 and $60 as neutral quotes;
interpreting $60 as a grave accent is to be avoided.

No doubt aware of this confusion, Infocom never used character $60, and used
$27 almost exclusively as an apostrophe - hardly any single quotes appear in
Infocom games. Modern authors would do well to follow their lead.

The Infocom games that do use single quotes use $27 for both opening and
closing - but even on many of their interpreters this looked a little odd, so
suggesting that $27 be a right quote introduces no extra compatibility
problems.

* Notes on smartening output

Interpreters can easily convert $22 into opening and closing double quotes
automatically if they desire. Adjustment of $27 and $60 is ill-advised, due
to the difficulty in distinguishing single-quotes from apostrophes - witness
the following examples from various Infocom games:

    "I'm Wiggins, 'ead o' the Baker Street Irregulars."
    ... a majority of people agree our school system is 'out of control.'"
    ... agreed that 2051, '61, and '71 all looked disturbing. ...
    [Too bad there's no scratch 'n' sniff for this one, huh?]
    The word 'examne' isn't in your vocabulary.

Thus if authors want to have smart single quotes, it is up to them to
correctly use opening ($60) and closing ($27) forms.

One possible heuristic for an interpreter to elegantly handle both types of
quoting would be to initially treat $27 as a neutral quote, except when
occurring between two letters, when it is clearly an apostrophe. As soon as a
$60 is printed, it is clear that the game is intending to use smart quotes,
so $27 from then on should always be a right quote.

There is a similar problem with character $2D, which could be hyphen, minus
or a dash. When proportional fonts are used these forms should look very
different, so $2D is a candidate for interpreter smartening. By default it
should be assumed to be a hyphen, but conventional forms worth spotting are
" - " to represent an en-dash and " -- " to represent an em-dash, although
such smartening mustn't be applied when the game has requested fixed-pitch.
"-" immediately preceding a digit could be converted to a minus.


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 should be 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, this
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.


Unicode
-------
The Z-machine is not expected to handle complex Unicode formatting like
combining characters, bidirectional formatting and unusual line-wrapping
rules - it remains firmly based in the world of left-to-right text with space
breaks between words - every character is viewed as separate spacing glyph.

All output is in presentation order, from left to right. To handle languages
like Arabic or Hebrew, text would have to be output "visually", with manual
line breaks (possibly via an in-game formatting engine).

Far eastern languages are generally straightforward, except they usually use
no spaces, and line wraps can occur almost anywhere. The easiest to way to
handle this would be for the game to turn off buffering. A more sophisticated
game might include its own formatting engine. Also, fixed-space output is
liable to be problematical with most Far Eastern fonts, which use a mixture
of "full width" and "half width" forms - all half-width characters would have
to be forced to full width.

The only way to output arbitrary Unicode characters in Standard 1.0 is one
character at a time with the @print_unicode opcode. Standard 1.1 adds Unicode
string printing - see below.
   
The Z-machine does not provide access to non-BMP characters (ie characters
outside the range U+0000 to U+FFFF).

Unicode characters U+0000 to U+001F are treated the same as ZSCII characters
$00 to $1F - see table 2 in S 3.8. 


                                ADDITIONS
                                =========

Unicode in strings
------------------
In Standard 1.1, for Version 5 and later, a new mechanism for storing Unicode
text in standard Z-machine strings is defined - the @print_unicode opcode in
Standard 1.0 is not adequate to straightforwardly handle, say, a
Japanese-language game, which would require widescale use of non-ZSCII
characters.

When encountered in Z-machine text, ZSCII characters 768-1023 are "Unicode
escapes", which indicate that Unicode data follows.  The number of Unicode
codepoints to follow is given by the ZSCII code minus 767; 768 means 1, 1023
means 256.

After reading a Unicode escape, the Z-machine starts reading Unicode at the
next word. Once the designated number of Unicode characters have been read,
text decoding resumes where it left off in the word where the Unicode escape
was found. Once that word has been processed, the next word is read from
after the Unicode sequence, unless the end-bit was set. This ordering will
arise naturally from typical decoder implementations, so is easier to decode
than to explain.

The Unicode text is stored as a series of words, inverted to prevent casual
browsing.

This would be a typical usage:

  "Japanese" in Japanese: (U+65E5 U+672C U+8A9E)
  Z-characters: 5,6,24, 2,5,5, <Unicode>, <Unicode>, <Unicode>
  Encoded:  $10DC $88A5 $D15F $98D3 $75D1

The following examples demonstrate ordering:

  "Zork<TM>" (<TM> = U+2122)
  Z-characters: 4,31,20, 23,16,5, 6,24,0, <Unicode>
  Encoded: $13F4 $5E05 $9B00 $DEDD

  "Zor<TM>k"
  Z-characters: 4,31,20, 23,5,6, 24,0,16, <Unicode>
  Encoded: $13F4 $5CA6 $E010 $DEDD

  "Zo<TM>rk"
  Z-characters: 4,31,20, 5,6,24, 0,23,16, <Unicode>
  Encoded: $13F4 $14D8 $82F0 $DEDD

  "Z<TM>ork"
  Z-characters: 4,31,5, 6,24,0, <Unicode>, 20,23,16
  Encoded: $13E5 $1B00 $DEDD $D2F0

Occasional characters like that <TM> should normally be output using
print_unicode for backwards compatibility.

ZSCII characters 768-1023 can only be encoded as a 4 Z-character sequence,
leading to a basic overhead of 4 bytes on all pure Unicode strings.

Unicode escapes can only be used in strings, not @print_char, and are not
used when tokenising text.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 20 23:43:12 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 19 Dec 2001 11:53:21 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Message-ID: <3d4b4beb4a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] XOR opcode
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


Is it worth adding an XOR opcode? Trivial to implement in an interpreter,
but pretty trivial to work around the lack of. If we wanted to add it, the
sooner the better.

I've added an exclusive-or operator to my copy of Inform, along with
arithmetic and logical shifts, but it uses the (a&(~b))|((~a)&b) method
for the moment, and I wouldn't allow it to use the XOR opcode unless a
directive signalled that it was allowed to rely on 1.1 features (the same
directive would be needed to allow it to use Unicode strings).

Here's my proposal:


@xor
----
2OP:29 1D 1/* xor a b -> (result)

Bitwise EXCLUSIVE OR.

*** This opcode is new in Standard 1.1. On older interpreters it can be
simulated with the following code sequence:

   @not b -> sp;
   @and a sp -> sp;
   @not a -> sp;
   @and sp b -> sp;
   @or sp sp -> result;

Because it can be simulated relatively straightforwardly with other opcodes,
this opcode should be avoided unless a story file requires Standard 1.1
anyway.


-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Thu Dec 20 23:43:16 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 19 Dec 2001 08:59:35 -0500
Subject: Re: [z-machine] XOR opcode
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <3d4b4beb4a.kbracey@kbracey.cam.pace.co.uk>
Message-Id: <A278FD08-F488-11D5-A8BB-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

On Wednesday, December 19, 2001, at 06:53 AM, Kevin Bracey wrote:

> Is it worth adding an XOR opcode? Trivial to implement in an 
> interpreter,
> but pretty trivial to work around the lack of. If we wanted to add it, 
> the
> sooner the better.

Even the World's Laziest Interpreter Writer (me) doesn't see a problem 
with this one.


</x-flowed>
From ???@??? Thu Dec 20 23:43:56 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 20 Dec 2001 10:27:58 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Message-ID: <fb4fc7eb4a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] Sound vote result
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


Okay, that's a grand total of four votes :) I think even my Concordet
counting skills are up to this challenge.

Vote summary:

 A = KJB/JCP Draft 2 scheme
 B = Fillmore's @set_channel scheme
 C = Status quo (leave as Standard 1.0+Blorb 1.1)
 D = Re-open discussions

                     A  B  C  D
--------------------------------
Kevin Bracey         1  2  4  3
Fillmore             2  1  4  3
Jason Penney         1  2  4  3
Matthew Russotto     2  4  1  3


Option A is preferred to status quo by 2 votes net.
Option B is preferred to status quo by 2 votes net.
Option D is preferred to status quo by 2 votes net.

So we reject the status quo.

Option A is preferred to option B by 2 votes net.
Option A is preferred to option D by 4 votes net.
Option B is preferred to option D by 2 votes net.

Option A is preferred to each other option, so is the Concordet winner.

I'll get Jason to post up a third draft of the complete set of changes
today - we'll have a few days discussion on it, and if everyone seems happy,
we'll vote on it.

I've been unable to contact Graham, or at least elicit a reply, and he
doesn't appear to be subscribed to this list. If anyone knows how to contact
him, or knows why he may be unable to reply, it would be appreciated.

In his absence, I feel that a vote in favour of approving the Standard change
on this mailing list should be sufficient to grant a Standard change official
status.

It should really require some sort of margin rather than just a majority to
overturn a status quo, but given the turn-out on that vote, I'm not sure what
the margin should be. Perhaps we can require a margin of 20% of voters (ie
60% in favour vs 40% against).

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Dec 21 15:19:11 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Thu, 20 Dec 2001 07:31:25 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] XOR opcode
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C2193CD.5125.363E48E@localhost>
In-reply-to: <3d4b4beb4a.kbracey@kbracey.cam.pace.co.uk>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Kevin Bracey sent a message across the ether on 19 Dec 2001 (11:53) 
stating:

> Is it worth adding an XOR opcode? Trivial to implement in an 
interpreter,
> but pretty trivial to work around the lack of. If we wanted to add it, 
the
> sooner the better.

Sounds like a good idea to me.

Jay

-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Fri Dec 21 15:19:23 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 20 Dec 2001 17:13:25 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Message-ID: <026feceb4a.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] Standard 1.1 Proposal - 3rd attempt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


I tried to post a third draft earlier, but the list doesn't appear to have
sent it out. Maybe it was too long.

So, it can also be found at

     http://www.jczorkmid.net/~jpenney/ZSpec11-draft3.txt
     
Unless there are any contentious issues, I suggest we call a vote shortly.

There are probably still editorial issues like history and contribution
sections to go in, and creating a unified standard document, but we can vote
on approving the technical content of this document.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Dec 21 15:19:26 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 18:57:13 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE54ckeB2PcSoN5gfUw00005ff5@hotmail.com>
X-OriginalArrivalTime: 20 Dec 2001 18:51:12.0711 (UTC) FILETIME=[4BB94D70:01C18987]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
To: <z-machine@gmd.de>
Sent: Thursday, December 20, 2001 5:13 PM
Subject: [z-machine] Standard 1.1 Proposal - 3rd attempt


> I tried to post a third draft earlier, but the list doesn't appear to have
> sent it out. Maybe it was too long.
>
> So, it can also be found at
>
>      http://www.jczorkmid.net/~jpenney/ZSpec11-draft3.txt
>
> Unless there are any contentious issues, I suggest we call a vote shortly.

With all the talking about the sound support, I forgot about this:

> Standard 1.1 interpreters are required to handle Blorb (v1.1) files,
> at least up to support for running a Z-code executable from within a
> Blorb file. If the interpreter supports sound or graphics, it must
> be able to obtain those resources from a Blorb file (although the
> Standard does not preclude other formats).

This is just wrong. The Z-Machine does not, and should not, dictate
the format of its resources. If it had done so in the first place,
current terps would be required to support out of date formats.
There may well be circumstances under which supporting blorb is
not worth the effort, and it does not affect in any way how the
Z-Machine itself runs.

There is *no* way I'm going to support this one going into the spec.
It doesn't belong there.

--
Fillmore


From ???@??? Fri Dec 21 15:19:30 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.13.165]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 14:58:41 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F13SOm3WsTiaqi66Y2Q0000af18@hotmail.com>
X-OriginalArrivalTime: 20 Dec 2001 19:58:41.0850 (UTC) FILETIME=[B932E1A0:01C18990]
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

The thought occurs: doesn't requiring terps to support blorb make it 
impossible for any embedded terp to claim 1.1 compliance? If you've got a 
terp (like the infocom ones) that's hard-coded to a single game file, it 
can't handle this requirement.  Or, for that matter, if it's a game boy 
terp. The whole blorb requirement assumes that all terps are "covnentional" 
in that they're pieces of software which run files stored on the hard drive 
of a "real" computer. This is true for most terps, but UI don't think it's a 
tautology.


>From: "Fillmore" <Noslwop@hotmail.com>
>To: "z-machine mailing list" <z-machine@gmd.de>
>Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
>Date: Thu, 20 Dec 2001 18:57:13 -0000
>
>----- Original Message -----
>From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
>To: <z-machine@gmd.de>
>Sent: Thursday, December 20, 2001 5:13 PM
>Subject: [z-machine] Standard 1.1 Proposal - 3rd attempt
>
>
> > I tried to post a third draft earlier, but the list doesn't appear to 
>have
> > sent it out. Maybe it was too long.
> >
> > So, it can also be found at
> >
> >      http://www.jczorkmid.net/~jpenney/ZSpec11-draft3.txt
> >
> > Unless there are any contentious issues, I suggest we call a vote 
>shortly.
>
>With all the talking about the sound support, I forgot about this:
>
> > Standard 1.1 interpreters are required to handle Blorb (v1.1) files,
> > at least up to support for running a Z-code executable from within a
> > Blorb file. If the interpreter supports sound or graphics, it must
> > be able to obtain those resources from a Blorb file (although the
> > Standard does not preclude other formats).
>
>This is just wrong. The Z-Machine does not, and should not, dictate
>the format of its resources. If it had done so in the first place,
>current terps would be required to support out of date formats.
>There may well be circumstances under which supporting blorb is
>not worth the effort, and it does not affect in any way how the
>Z-Machine itself runs.
>
>There is *no* way I'm going to support this one going into the spec.
>It doesn't belong there.
>
>--
>Fillmore


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


</x-flowed>
From ???@??? Fri Dec 21 15:19:33 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <009a01c18995$bb856ae0$b72686d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE54ckeB2PcSoN5gfUw00005ff5@hotmail.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 20:34:25 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> > Standard 1.1 interpreters are required to handle Blorb (v1.1) files,
> > at least up to support for running a Z-code executable from within a
> > Blorb file. If the interpreter supports sound or graphics, it must
> > be able to obtain those resources from a Blorb file (although the
> > Standard does not preclude other formats).
>
> This is just wrong. The Z-Machine does not, and should not, dictate
> the format of its resources. If it had done so in the first place,
> current terps would be required to support out of date formats.
> There may well be circumstances under which supporting blorb is
> not worth the effort, and it does not affect in any way how the
> Z-Machine itself runs.
>
> There is *no* way I'm going to support this one going into the spec.
> It doesn't belong there.

Digging back through my e-mail records, when Graham was working towards
Standard 1.0, he was keen on standardising on a resource format. As far as
I'm aware the reason it didn't happen was not a philosophical one, but just
that the Infocom formats clearly weren't suitable, and a new one hadn't been
devised at the time Standard 1.0 was written.

And the text explicitly says that interpreters are allowed to support other
formats.

I don't understand the "circumstances under which supporting blorb is not
worth the effort". What are you thinking of? All we're talking about as a
minimum is picking the Z-code chunk out of a Blorb file; that's pretty
trivial, and vital to allow authors to move towards packaging their files.

You may as well argue that there's no need for a standard story file format
either - the way that the initial Z-machine state is packaged has no bearing
on the way the machine works. Yet the standard DOES specify how the Z-code
is packaged.

The JPEG committee took the abstract route and didn't specify a file format
for JPEG data, which led to something of a mess until C-cubed manage to
create the de facto JFIF standard. One of the main reasons no-one is using
the Z-machine for multimedia work is because WE are currently in just such a
mess - the range of interpreters has not got a standard resource format.
It's great if they all support @draw_picture, but totally useless in
practice unless authors can give them the pictures in the first place.

Glk doesn't have a problem specifying its resource format, so I don't see
why the Z-machine should.

In practice though, I suppose it's unlikely to be a problem. Anyone actively
maintaining a compiler will be well aware that Blorb support is expected, I
hope.
And it doesn't affect the competition I'm going to hold, which will require
Blorb support anyway.

Seeing as it bothers you, we can include an option in the vote to reduce the
Blorb requirement to a recommendation, like the status of Quetzal (although
I note the Quetzal spec IS an annexe of the Z-spec).

Kevin
-----



From ???@??? Fri Dec 21 15:19:46 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <009f01c18997$0165cb80$b72686d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <F13SOm3WsTiaqi66Y2Q0000af18@hotmail.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 20:43:36 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> The thought occurs: doesn't requiring terps to support blorb make it
> impossible for any embedded terp to claim 1.1 compliance? If you've got a
> terp (like the infocom ones) that's hard-coded to a single game file, it
> can't handle this requirement.  Or, for that matter, if it's a game boy
> terp. The whole blorb requirement assumes that all terps are
"covnentional"
> in that they're pieces of software which run files stored on the hard
drive
> of a "real" computer. This is true for most terps, but UI don't think it's
a
> tautology.

That's a good point. If you're hard-coded to a single file, then you clearly
aren't capable of loading anything, even a story file.

But on the other hand, if it's embedded, then whether the interpreter
complies with the Standard or not isn't an issue anyway, as the game will
have been written with that interpreter in mind, and it knows what it can
do.

Unless it was created with some sort of general-purpose "make a packaged
executable" program, in which case that program would be supplying the
interpreter. Thus the "make a packaged executable" program would have to
claim some sort of standard compliance itself, and it would be _its_
responsibility to accept Blorb.

Kevin
-----



From ???@??? Fri Dec 21 15:19:47 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 20 Dec 2001 12:48:33 -0800 (PST)
From: Dave <dgriffi@cs.csubak.edu>
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
In-Reply-To: <009a01c18995$bb856ae0$b72686d9@oemcomputer>
Message-ID: <Pine.OSF.4.05.10112201243560.6898-100000@pegasus.cs.csubak.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@gmd.de
Precedence: bulk


On Thu, 20 Dec 2001, Kevin Bracey wrote:

[snip]

> Seeing as it bothers you, we can include an option in the vote to reduce the
> Blorb requirement to a recommendation, like the status of Quetzal (although
> I note the Quetzal spec IS an annexe of the Z-spec).

In other words, should the spec say something like "If you want to use
sound and/or graphics, you MUST use Blorb."?

Sorry for getting on the list late in the game.


-- 
David Griffith
dgriffi@cs.csubak.edu


From ???@??? Fri Dec 21 15:19:48 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <00c701c1899e$7b0137c0$b72686d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <Pine.OSF.4.05.10112201243560.6898-100000@pegasus.cs.csubak.edu>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 21:37:07 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> On Thu, 20 Dec 2001, Kevin Bracey wrote:
>
> [snip]
>
> > Seeing as it bothers you, we can include an option in the vote to reduce
the
> > Blorb requirement to a recommendation, like the status of Quetzal
(although
> > I note the Quetzal spec IS an annexe of the Z-spec).
>
> In other words, should the spec say something like "If you want to use
> sound and/or graphics, you MUST use Blorb."?

That's what it does say, except that even if you're not using sound or
graphics, it says you must be able to accept a Z-code file packaged in
Blorb. There's no requirement to support sound or graphics.

Fillmore's not happy with mandating the use of any format, whereas I feel
that's too abstract to be helpful.

But I think I'd be happy just to reduce it to a recommendation. Something
like:


Blorb
-----
Blorb has been selected as the standard resource format of the Z-machine.
Although interpreters are not required to handle Blorb, they are urged to do
so, as it will be the format that authors use to create new resources. Blorb
versions of all the Infocom resources are now available. Even if an
interpreter does not support sound or graphics, it is still recommended to
support running a Z-code story file packaged in a Blorb file.


We'll include both options in the vote.

Kevin
-----



From ???@??? Fri Dec 21 15:19:49 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 20 Dec 2001 22:52:14 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Message-ID: <20011220225214.A23008@igloo.df.lth.se>
References: <Pine.OSF.4.05.10112201243560.6898-100000@pegasus.cs.csubak.edu> <00c701c1899e$7b0137c0$b72686d9@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00c701c1899e$7b0137c0$b72686d9@oemcomputer>; from kevin@bracey-griffith.freeserve.co.uk on Thu, Dec 20, 2001 at 09:37:07PM -0000
Sender: owner-z-machine@gmd.de
Precedence: bulk


Just some thoughts regarding whether acceptance of Blorb should be
required or just recommended:

While I don't share Fillmore's aversion to requireing Blorb
compliance, I don't quite see the need for it. We're also running the
risk of getting terps that claim "1.1 compliance except for Blorb"
(e.g. if they're running in an environment where Blorb files are
unpractical or where there is no real file system).

But, philosophically speaking, I think the main point of standard
compliance is that the game should be able to ask the terp "Do you
confirm to the standard?" and if the answer is yes, it should be able
to rely on certain features being present.

But is Blorb compliance such a feature? Does the game, when running,
care about whether its resources are packed in a Blorb file or not,
as long as it can access them in a standard way?

I do think that the standard should recommend Blorb compliance, but I
think that from the game's point of view, standard compliance is about
other thigns (such as a certain opcode having certain effects and no
others, and so on).

Of course, I may be totally off base here. 

-- 
Magnus Olsson (mol@df.lth.se, mol@pobox.com)
------    http://www.pobox.com/~mol   ------


From ???@??? Fri Dec 21 15:19:51 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <00de01c189a3$689a45e0$b72686d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <Pine.OSF.4.05.10112201243560.6898-100000@pegasus.cs.csubak.edu> <00c701c1899e$7b0137c0$b72686d9@oemcomputer> <20011220225214.A23008@igloo.df.lth.se>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 22:12:24 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> Just some thoughts regarding whether acceptance of Blorb should be
> required or just recommended:
>
> While I don't share Fillmore's aversion to requireing Blorb
> compliance, I don't quite see the need for it. We're also running the
> risk of getting terps that claim "1.1 compliance except for Blorb"
> (e.g. if they're running in an environment where Blorb files are
> unpractical or where there is no real file system).
>
> But, philosophically speaking, I think the main point of standard
> compliance is that the game should be able to ask the terp "Do you
> confirm to the standard?" and if the answer is yes, it should be able
> to rely on certain features being present.

That is the main point, yes, but in a way I don't think that it necessarily
should be the only point. I'm not fond of a world where users are confronted
with a mass of options they don't really need to know about. I think that
the Glulx/Glk/Blorb/Glulxe world suffers from this too. I think it clarifies
things if we tie the auxiliary standards into the main standard, so users
can eventually forget about Blorb altogether - it just becomes something
that Z-machines do.

My main concern was getting terps to pull Z-code out of Blorb files. This is
the conceptual equivalent of what cheapglk (?) does - thus Glulx authors
feel happy to package their Glulx executables up in Blorb in the knowledge
that all Glulx interpreters are capable of handling Blorb. I'd like the
Z-machine to be in the same situtation, so eventually there would be no need
to worry about providing separate Z-code files; authors would know that all
Standard 1.1 terps would be able to accept a packaged file

Although having checked more carefully, I note that the Glk spec doesn't
REQUIRE Glk systems to handle Blorb - it just happens that they all do. So
maybe it makes sense to follow the same recommendation tack.

Kevin
-----



From ???@??? Fri Dec 21 15:19:52 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE54ckeB2PcSoN5gfUw00005ff5@hotmail.com> <009a01c18995$bb856ae0$b72686d9@oemcomputer>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 22:52:54 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE48WJueC7O0OcYqfUY00006300@hotmail.com>
X-OriginalArrivalTime: 20 Dec 2001 22:46:55.0043 (UTC) FILETIME=[3935E930:01C189A8]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
Sent: Thursday, December 20, 2001 8:34 PM
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt


> > > Standard 1.1 interpreters are required to handle Blorb (v1.1) files,
> > > at least up to support for running a Z-code executable from within a
> > > Blorb file. If the interpreter supports sound or graphics, it must
> > > be able to obtain those resources from a Blorb file (although the
> > > Standard does not preclude other formats).
> >
> > This is just wrong. The Z-Machine does not, and should not, dictate
> > the format of its resources. If it had done so in the first place,
> > current terps would be required to support out of date formats.
> > There may well be circumstances under which supporting blorb is
> > not worth the effort, and it does not affect in any way how the
> > Z-Machine itself runs.
> >
> > There is *no* way I'm going to support this one going into the spec.
> > It doesn't belong there.
>
> Digging back through my e-mail records, when Graham was working towards
> Standard 1.0, he was keen on standardising on a resource format. As far as
> I'm aware the reason it didn't happen was not a philosophical one, but
just
> that the Infocom formats clearly weren't suitable, and a new one hadn't
been
> devised at the time Standard 1.0 was written.
>
> And the text explicitly says that interpreters are allowed to support
other
> formats.
>
> I don't understand the "circumstances under which supporting blorb is not
> worth the effort". What are you thinking of? All we're talking about as a
> minimum is picking the Z-code chunk out of a Blorb file; that's pretty
> trivial, and vital to allow authors to move towards packaging their files.

I create a z-terp, say, that people access via web pages, that only runs
games stored on the server. It can't support pictures or sound, and I have
complete control over which games are available. Is it worth the effort of
supporting blorb?

> You may as well argue that there's no need for a standard story file
format
> either - the way that the initial Z-machine state is packaged has no
bearing
> on the way the machine works. Yet the standard DOES specify how the Z-code
> is packaged.
>
> The JPEG committee took the abstract route and didn't specify a file
format
> for JPEG data, which led to something of a mess until C-cubed manage to
> create the de facto JFIF standard. One of the main reasons no-one is using
> the Z-machine for multimedia work is because WE are currently in just such
a
> mess - the range of interpreters has not got a standard resource format.
> It's great if they all support @draw_picture, but totally useless in
> practice unless authors can give them the pictures in the first place.
>
> Glk doesn't have a problem specifying its resource format, so I don't see
> why the Z-machine should.

I don't believe it does, actually. It can use whatever it likes. It's just
that Blorb is recommended and already used by most implementations.

> In practice though, I suppose it's unlikely to be a problem. Anyone
actively
> maintaining a compiler will be well aware that Blorb support is expected,
I
> hope.

I hope so, too.

> And it doesn't affect the competition I'm going to hold, which will
require
> Blorb support anyway.

Yay!

> Seeing as it bothers you, we can include an option in the vote to reduce
the
> Blorb requirement to a recommendation, like the status of Quetzal
(although
> I note the Quetzal spec IS an annexe of the Z-spec).

Yeah, I think that's the best way to go. And I also think that Blorb should
probably be listed under Related standards documents, too.

And, changing subjects almost completely, are we going to update the
Appendices?

--
Fillmore


From ???@??? Fri Dec 21 15:19:53 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <010001c189ab$c1632e00$b72686d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE54ckeB2PcSoN5gfUw00005ff5@hotmail.com> <009a01c18995$bb856ae0$b72686d9@oemcomputer> <OE48WJueC7O0OcYqfUY00006300@hotmail.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 23:12:09 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> > I don't understand the "circumstances under which supporting blorb is
not
> > worth the effort". What are you thinking of? All we're talking about as
a
> > minimum is picking the Z-code chunk out of a Blorb file; that's pretty
> > trivial, and vital to allow authors to move towards packaging their
files.
>
> I create a z-terp, say, that people access via web pages, that only runs
> games stored on the server. It can't support pictures or sound, and I have
> complete control over which games are available. Is it worth the effort of
> supporting blorb?

That's the same as Ross's point, which hadn't occurred to me. I would say
no, but then similarly it isn't worth supporting Standard 1.1, as you're
supplying the games, so standardisation isn't an issue anyway. It's an issue
if you decide to release this interpreter for general use - then you would
need to declare what it handled. And I'd want a released interpreter, of
whatever form, to accept Blorb files, just as it would accept Z-code files.

> And, changing subjects almost completely, are we going to update the
> Appendices?

Which ones? There are a few references in there which are out-of-date, I
suppose. That'll be the next job for someone once the addendum has been
agreed :( Ho hum.

Kevin
-----



From ???@??? Fri Dec 21 15:19:54 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE54ckeB2PcSoN5gfUw00005ff5@hotmail.com> <009a01c18995$bb856ae0$b72686d9@oemcomputer> <OE48WJueC7O0OcYqfUY00006300@hotmail.com> <010001c189ab$c1632e00$b72686d9@oemcomputer>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 20 Dec 2001 23:52:53 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE38Be932VXI2PGBPj300006263@hotmail.com>
X-OriginalArrivalTime: 20 Dec 2001 23:46:52.0944 (UTC) FILETIME=[99BA0900:01C189B0]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
Sent: Thursday, December 20, 2001 11:12 PM
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt


> > > I don't understand the "circumstances under which supporting blorb is
> not
> > > worth the effort". What are you thinking of? All we're talking about
as
> a
> > > minimum is picking the Z-code chunk out of a Blorb file; that's pretty
> > > trivial, and vital to allow authors to move towards packaging their
> files.
> >
> > I create a z-terp, say, that people access via web pages, that only runs
> > games stored on the server. It can't support pictures or sound, and I
have
> > complete control over which games are available. Is it worth the effort
of
> > supporting blorb?
>
> That's the same as Ross's point, which hadn't occurred to me. I would say
> no, but then similarly it isn't worth supporting Standard 1.1, as you're
> supplying the games, so standardisation isn't an issue anyway. It's an
issue
> if you decide to release this interpreter for general use - then you would
> need to declare what it handled. And I'd want a released interpreter, of
> whatever form, to accept Blorb files, just as it would accept Z-code
files.

Well, no, I'm not supplying the games, I'm merely picking them. And some
games
may work better if the terp claims 1.1 compliance.

> > And, changing subjects almost completely, are we going to update the
> > Appendices?
>
> Which ones? There are a few references in there which are out-of-date, I
> suppose. That'll be the next job for someone once the addendum has been
> agreed :( Ho hum.

Well, mainly appendix C, which contains various pieces of information which
are now out of date. There are probably one or two things in some of others
than need ammending. It's not overly important, but it's probably a good
idea.

--
Fillmore



From ???@??? Fri Dec 21 15:19:57 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 20 Dec 2001 20:21:31 -0500
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <F13SOm3WsTiaqi66Y2Q0000af18@hotmail.com>
Message-Id: <1081CB16-F5B1-11D5-831D-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

On Thursday, December 20, 2001, at 02:58 PM, L. Ross Raszewski wrote:

>
> The thought occurs: doesn't requiring terps to support blorb make it 
> impossible for any embedded terp to claim 1.1 compliance? If you've got 
> a terp (like the infocom ones) that's hard-coded to a single game file, 
> it can't handle this requirement.  Or, for that matter, if it's a game 
> boy terp. The whole blorb requirement assumes that all terps are 
> "covnentional" in that they're pieces of software which run files 
> stored on the hard drive of a "real" computer. This is true for most 
> terps, but UI don't think it's a tautology.

This is a good point.  Perhaps the standard can be split, like the C and 
Java standards are: The Blorb and Quetzal annexes can be declared 
required for interpreters on general purpose computers, but optional for 
embedded versions.  Certainly an embedded interpreter with some other 
resource format ought to be able to legally declare itself 1.1 compliant 
if it looks so to the game.

There's a couple other problems along that line, like the auxiliary file 
naming convention (which is in 1.0)

Other issues, piggybacking:

I think the $27/$60 thing is silly, and we should stick to the modern 
interpretation -- $27 is a neutral quote and $60 is a grave accent.  
"Smartening" quotes should be banned or at least discouraged... after 
all, is 1-10 minus nine or a range?

Is there a reason for restricting art_shift and log_shift to -15/+15?  
I've run into real-life situations where it was convenient to be able to 
shift a value all the way to zero.

Historical note:  According to my old notes, 'set_font' originally 
returned the previous font, at least in the Mac interpreters.  The 
Standard behavior is superior, and I don't believe any gamefile depended 
on this behavior.


</x-flowed>
From ???@??? Fri Dec 21 15:58:14 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Thu, 20 Dec 2001 21:52:31 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C225D9F.24422.5B4463@localhost>
In-reply-to: <OE48WJueC7O0OcYqfUY00006300@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Fillmore sent a message across the ether on 20 Dec 2001 (22:52) stating:

> I create a z-terp, say, that people access via web pages, that only 
runs
> games stored on the server. It can't support pictures or sound, and I 
have
> complete control over which games are available. Is it worth the 
effort of
> supporting blorb?

It might be.  What about a game written in V6 that uses sounds and 
graphics, but is smart enough to check all the header bits and work 
around them if they aren't available.  Now what if that game is only 
distributed in .blb format, and the author's license prohibits you from 
extracting the .z6 file and distributing it on it's own?

Just a thought.

Jay
-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Fri Dec 21 15:58:16 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp4.ihug.co.nz: Host p36-nas6.akl.ihug.co.nz [203.173.216.36] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20011221153956.072b2790@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 21 Dec 2001 15:53:45 +1300
To: z-machine@gmd.de
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
In-Reply-To: <1081CB16-F5B1-11D5-831D-0050E4A0CE52@speakeasy.net>
References: <F13SOm3WsTiaqi66Y2Q0000af18@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 20:21 20/12/01 -0500, Matthew T. Russotto wrote:

>This is a good point.  Perhaps the standard can be split, like 
>the C and Java standards are: The Blorb and Quetzal annexes can 
>be declared required for interpreters on general purpose 
>computers, but optional for embedded versions.  Certainly an 
>embedded interpreter with some other resource format ought to be 
>able to legally declare itself 1.1 compliant if it looks so to 
>the game.
>
>There's a couple other problems along that line, like the 
>auxiliary file naming convention (which is in 1.0)

I don't see this as a problem.  To my understanding, an "embedded" 
game is one with the terp and story bundled into one executable 
file, with no external files accessible.  That doesn't conflict 
with the concept of a Blorb file - all you need to do is bundle 
the Blorb file containing the z-code in with the terp instead of 
just the z-code.

Therefore, to have a fully standard-1.1-compliant terp system, the 
author of the embedded terp would have to provide support for one 
of the following two cases:
   (1) the authoring software can extract z-code from a blorb file 
and bundle it with its embedded terp, same as before
   (2) the authoring software just bundles the whole blorb file 
with the terp, and the terp itself is modified to be able to read 
the new format

Either way, it would be a piece of cake.  And bear in mind that 
the embedded platform doesn't have to support sound or music to 
support blorb.

On a related note, the web-terp example:  such a web-terp would be 
written in a direct-interactive technology such as Java or 
Flash.  Both of these support sound and graphics.  So it's not 
that you *can't* support them, it's that you don't want to.  But 
there's still no reason not to support blorb files, at least as 
far as extracting a z-code story file from them.

>I think the $27/$60 thing is silly, and we should stick to the 
>modern interpretation -- $27 is a neutral quote and $60 is a 
>grave accent.
>"Smartening" quotes should be banned or at least discouraged... 
>after all, is 1-10 minus nine or a range?

I agree.  In most fonts $27 is automatically a neutral quote, and 
you said yourself (whoever originally posted this, I've lost the 
thread) that the original Infocom games used that character as a 
neutral quote anyway.

>Is there a reason for restricting art_shift and log_shift to 
>-15/+15?
>I've run into real-life situations where it was convenient to be 
>able to shift a value all the way to zero.

I've encountered similar situations occasionally.  However, bear 
in mind that in most cases the terps would have to special-case 
that internally; in most of the C/C++ compilers (and probably 
other languages too) the expression "a >> 16" will generate the 
same result as "a >> 0" (for a 16-bit variable, anyway).

-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
10 PRINT "Waiter, There's a bug in my loop": GOTO 10


</x-flowed>
From ???@??? Fri Dec 21 16:48:14 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 20 Dec 2001 22:46:52 -0500
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <5.1.0.14.0.20011221153956.072b2790@pop.ihug.co.nz>
Message-Id: <5EE3B6FC-F5C5-11D5-831D-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

On Thursday, December 20, 2001, at 09:53 PM, Gavin Lambert wrote:

> At 20:21 20/12/01 -0500, Matthew T. Russotto wrote:
>
>> This is a good point.  Perhaps the standard can be split, like the C 
>> and Java standards are: The Blorb and Quetzal annexes can be declared 
>> required for interpreters on general purpose computers, but optional 
>> for embedded versions.  Certainly an embedded interpreter with some 
>> other resource format ought to be able to legally declare itself 1.1 
>> compliant if it looks so to the game.
>>
>> There's a couple other problems along that line, like the auxiliary 
>> file naming convention (which is in 1.0)
>
> I don't see this as a problem.  To my understanding, an "embedded" game 
> is one with the terp and story bundled into one executable file, with 
> no external files accessible.  That doesn't conflict with the concept 
> of a Blorb file - all you need to do is bundle the Blorb file 
> containing the z-code in with the terp instead of just the z-code.'


An "embedded" interpreter in the sense I mean is an interpreter for use 
on a special-purpose device, like a Palm pilot or a Game Boy or 
something else that might not have files as such, or might have a native 
way of storing pictures and sounds which is much better (read:more 
efficient) than Blorb on that particular platform.

>> Is there a reason for restricting art_shift and log_shift to -15/+15?
>> I've run into real-life situations where it was convenient to be able 
>> to shift a value all the way to zero.
>
> I've encountered similar situations occasionally.  However, bear in 
> mind that in most cases the terps would have to special-case that 
> internally; in most of the C/C++ compilers (and probably other 
> languages too) the expression "a >> 16" will generate the same result 
> as "a >> 0" (for a 16-bit variable, anyway).

In mine
0xFFFFFFFFU >> 32US = 0
0xFFFFUS >> 16US = 0

Linux does the same.  However, linux does screw up 32 bit shifts 
(0xFFFFFFFFUL >> 32 == 0xFFFF).  And the C standard defines only the 
open interval.  Oh well, I guess I have to bow to practicality here.


</x-flowed>
From ???@??? Fri Dec 21 17:28:14 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp4.ihug.co.nz: Host p36-nas6.akl.ihug.co.nz [203.173.216.36] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20011221165141.07267bb0@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 21 Dec 2001 17:23:10 +1300
To: z-machine@gmd.de
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
In-Reply-To: <5EE3B6FC-F5C5-11D5-831D-0050E4A0CE52@speakeasy.net>
References: <5.1.0.14.0.20011221153956.072b2790@pop.ihug.co.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 22:46 20/12/01 -0500, Matthew T. Russotto wrote:

>An "embedded" interpreter in the sense I mean is an interpreter 
>for use on a special-purpose device, like a Palm pilot or a Game 
>Boy or something else that might not have files as such, or might 
>have a native way of storing pictures and sounds which is much 
>better (read:more efficient) than Blorb on that particular 
>platform.

All right, but if they don't have "files as such", then presumably 
they have some external means of introducing programs (via a link 
transfer cable or cartridge writer, perhaps).  And if they don't 
support external files, then the z-code story "file" must actually 
be included within the interpreter itself.  So like I said before, 
there's no reason why a blorb file couldn't be embedded instead of 
the z-code.  Or as an interim measure, the program that binds the 
z-code to the interpreter could extract the code from a z-file.

And as I understand it, there's nothing stopping people from using 
different graphics and sounds formats inside a blorb file.  And 
the 1.1 standard as it stands doesn't require terps to support the 
standard blorb graphics or sound formats (though it is 
recommended), just the blorb file structure and the ability to 
extract a story file from the file.  All this means that it would 
still be perfectly 1.1-compliant to have a binding program that 
does this:
   (1) reads a blorb file with standard graphic/sound formats
   (2) converts the graphics & sounds into the formats preferred 
by the embedded platform
   (3) creates a new blorb file identical to the original, but 
using the converted graphics and sounds instead
   (4) binds the new blorb file to the terp for the embedded 
platform
   (5) transfer the terp (with attached blorb file) to the 
embedded platform so that it can be run

That's what I think, anyway :P

-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
Press any key - EXCEPT THAT ONE!!!


</x-flowed>
From ???@??? Fri Dec 21 17:58:25 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-eGroups-Return: z-machine-owner@mail.gmd.de
X-Yahoo-MsgId: <mta597.mail.yahoo.com.1008911001.72043.0004>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 21 Dec 2001 00:00:28 -0500
Mime-Version: 1.0 (Apple Message framework v475)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
Message-Id: <A6C00B40-F5CF-11D5-831D-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
On Thursday, December 20, 2001, at 11:23 PM, Gavin Lambert wrote:

 > At 22:46 20/12/01 -0500, Matthew T. Russotto wrote:
 >
 > All right, but if they don't have "files as such", then presumably they
 > have some external means of introducing programs (via a link transfer
 > cable or cartridge writer, perhaps).  And if they don't support
 > external files, then the z-code story "file" must actually be included
 > within the interpreter itself.

Not necessarily -- it could be sent over separately after being
transformed by some packaging program.  I think the Palm Pilot
interpreters work this way now.
 >
 > And as I understand it, there's nothing stopping people from using
 > different graphics and sounds formats inside a blorb file.  And the 1.1
 > standard as it stands doesn't require terps to support the standard
 > blorb graphics or sound formats (though it is recommended), just the
 > blorb file structure and the ability to extract a story file from the
 > file.

"If the interpreter supports sound or graphics, it must be able to
obtain those resources from a Blorb file"

 >   All this means that it would still be perfectly 1.1-compliant to have
 > a binding program that does this:
 >   (1) reads a blorb file with standard graphic/sound formats
 >   (2) converts the graphics & sounds into the formats preferred by the 
embedded platform
 >   (3) creates a new blorb file identical to the original, but using 
the converted graphics and sounds instead\n
 >   (4) binds the new blorb file to the terp for the embedded platform
 >   (5) transfer the terp (with attached blorb file) to the embedded
 > platform so that it can be run
 >
 > That's what I think, anyway :P

This would violate the Blorb standard, which is incorporated by
reference.  And not necessarily solve the problem -- an interpreter with
attached blorb file might be an inefficient way to use sound and
graphics resources.  For instance, the device might have a way of
storing sounds which requires much less resources to play than that.

What I want to be legal is for an interpreter on a special-purpose
platform (only -- I want to keep the Blorb requirement for
general-purpose PCs) to accept graphics and Z-code only in its own
format.  Any conversion to that format could be done by a loader program
(not part of the interpreter) on a general purpose machine.

Not that it really matters; I think if the standard passed as is and it
became an issue for an embedded terp-writer, he'd merrily ignore the
standard.  I'd like to avoid that.



</x-flowed>
From ???@??? Fri Dec 21 18:28:21 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp4.ihug.co.nz: Host p36-nas6.akl.ihug.co.nz [203.173.216.36] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20011221175947.00a9e2a0@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 21 Dec 2001 18:20:41 +1300
To: z-machine@gmd.de
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
In-Reply-To: <A6C00B40-F5CF-11D5-831D-0050E4A0CE52@speakeasy.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 00:00 21/12/01 -0500, Matthew T. Russotto wrote:

>Not necessarily -- it could be sent over separately after being
>transformed by some packaging program.  I think the Palm Pilot
>interpreters work this way now.

Either the packaging program comes with the terp (so it can 
combine the terp executable with the story file), in which case it 
can be modified to include the whole blorb file, or it's a 
separate program, which means that the embedded device must have 
some kind of filesystem and thus can support blorb files anyway.

>"If the interpreter supports sound or graphics, it must be able 
>to
>obtain those resources from a Blorb file"

Yes.  But that doesn't preclude those sound and graphics resources 
being in a format other than that considered "normal" by 
blorb.  AFAIK there is *nothing* in the Blorb standard that says 
that I can't put a graphic in my own .XYZ format into a Blorb file 
(it would just have to have a different chunk id).  Not being 
standard, most Blorb terps would ignore this chunk and say that 
the graphic doesn't exist.  But a terp that supports the .XYZ 
format (which presumably is the format preferred by the embedded 
platform, so will include the terp for that platform) will happily 
render the image.

>This would violate the Blorb standard, which is incorporated by
>reference.  And not necessarily solve the problem -- an 
>interpreter with
>attached blorb file might be an inefficient way to use sound and
>graphics resources.  For instance, the device might have a way of
>storing sounds which requires much less resources to play than 
>that.

So you store the sound in the alternate format.  It means the 
Blorb file will only be completely usable under terps that 
understand that format, but it's still a perfectly valid Blorb 
file.

>What I want to be legal is for an interpreter on a 
>special-purpose
>platform (only -- I want to keep the Blorb requirement for
>general-purpose PCs) to accept graphics and Z-code only in its 
>own
>format.  Any conversion to that format could be done by a loader 
>program
>(not part of the interpreter) on a general purpose machine.

What you seem to be missing is that the requirement is that all 
standard-1.1 terps must be able to:
   - read a Blorb file.  This is it's structure, not considering 
the actual data contained within.  It still counts if the Blorb 
file is bound to the terp itself (so it's reading it from it's own 
load image).
   - read z-code from a Blorb file.  This is being able to find 
the story chunk within the Blorb file and load and execute it 
exactly as it would had it been a standalone .z? file.
   - load any sound and graphics requested by the story from the 
Blorb file.  Note that this requirement *doesn't* mean that the 
terp has to understand PNG or MOD (though it's recommended).

So a Blorb file could contain a story, some graphics in .XYZ 
format and some sounds in .ZYX format.  A standard desktop terp 
would be able to execute the story but not load the graphics or 
sounds.  A terp (like the one on your embedded platform) would be 
able to execute the story, and use the graphics and sounds 
contained within.

Obviously the ideal is to have every Blorb file containing 
graphics and sounds in the "normal" formats, so that the majority 
of graphics&sound-supporting terps will be able to use them.  But 
there's nothing to preclude other formats from being used.

Presumably if someone creates a terp that uses alternative formats 
(instead of the normal ones) they will also create something 
(whether standalone or built into the terp) to convert graphics 
and sounds within Blorb files to the alternate formats and back 
again.

My whole point is that you can still be Standard 1.1 and Blorb 
compliant without being able to display PNGs or play MODs.  You 
*should* be able to do so (otherwise a conversion tool becomes a 
necessity rather than simply a good idea), but you do not *have* 
to.

-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
If you pick up a starving dog and make him prosperous, he will not 
bite you.
  This is the principal difference between a dog and a man. -- 
Mark Twain


</x-flowed>
From ???@??? Fri Dec 21 21:18:18 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <001301c189f9$df854640$8e0d86d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <1081CB16-F5B1-11D5-831D-0050E4A0CE52@speakeasy.net>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Fri, 21 Dec 2001 08:30:15 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


From: "Matthew T. Russotto" <mrussotto@speakeasy.net>

> This is a good point.  Perhaps the standard can be split, like the C and
> Java standards are: The Blorb and Quetzal annexes can be declared
> required for interpreters on general purpose computers, but optional for
> embedded versions.  Certainly an embedded interpreter with some other
> resource format ought to be able to legally declare itself 1.1 compliant
> if it looks so to the game.

It certainly needs to be reworded. Something has to "embed" the interpreter
in the first place, which means that something would presumably accept story
files - it would be that which had to satisfy the "accepting Blorb" rule.

>
> There's a couple other problems along that line, like the auxiliary file
> naming convention (which is in 1.0)
>
> Other issues, piggybacking:
>
> I think the $27/$60 thing is silly, and we should stick to the modern
> interpretation -- $27 is a neutral quote and $60 is a grave accent.

I want authors to be able to use smart single quotes - indeed some already
are. Zip 2000 has always had a fair amount of smartening, as should be clear
from its screen shots. The one area that's never been satisfactory is single
quotes. So I'm trying to lay down rules which mean that the interpreter
doesn't have to smarten them.

The basic minimum request is don't treat $60 as a grave accent - make it
neutral. You'll see that $60 has NEVER been shown as a grave accent in any
Inform/Z-machine documentation.

I'm massively in favour of the modern interpretation on modern systems, but
on legacy platforms like the Z-machine, whose whole emphasis is on text
handling in ASCII, it's very useful to be able to get left and right quotes.

> "Smartening" quotes should be banned or at least discouraged... after
> all, is 1-10 minus nine or a range?

That's a choice between an en-dash and a minus, which look almost identical.
The default "hyphen" rendering would definitely be wrong though.

> Is there a reason for restricting art_shift and log_shift to -15/+15?
> I've run into real-life situations where it was convenient to be able to
> shift a value all the way to zero.

The reason is that it's all the C standard guarantees will work if int is 16
bits. And pretty much all interpreters are in C, I doubt anyone has written
code to specifically handle shifts of more than 15 bits. In practice, it may
be that most C compilers will be fine, but I don't know. On my system the
shift value can be up to 255 - then it fails.

I would prefer -16/+16 at least, but people have enough problem getting
art_shift to work, so I don't think we could really rely on getting them to
work reliably.

>
> Historical note:  According to my old notes, 'set_font' originally
> returned the previous font, at least in the Mac interpreters.  The
> Standard behavior is superior, and I don't believe any gamefile depended
> on this behavior.

The Standard does still return the previous font, as long as the new one is
valid.

Kevin
-----



From ???@??? Fri Dec 21 21:48:16 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-eGroups-Return: z-machine-owner@mail.gmd.de
X-Yahoo-MsgId: <mta306.mail.yahoo.com.1008925436.06352.0032>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <004201c189fd$93bf3f00$8e0d86d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <A6C00B40-F5CF-11D5-831D-0050E4A0CE52@speakeasy.net>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Fri, 21 Dec 2001 08:57:51 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
> What I want to be legal is for an interpreter on a special-purpose
> platform (only -- I want to keep the Blorb requirement for
> general-purpose PCs) to accept graphics and Z-code only in its own
> format.  Any conversion to that format could be done by a loader program
> (not part of the interpreter) on a general purpose machine.

Does the Standard currently give you the freedom to not accept standard
Z-code files? I'm not sure that it does. Or maybe it does - it just says
what the standard format of Z-code files is, and doesn't explicitly say that
you have to load them. The unwritten assumption is that that's the format
games will be supplied in, so there had better be some way of handling them.

I would really class the loader program you describe as part of the
Z-machine implementation, so it would be the combination of interpreter and
loader to obey the Standard between them.

Anyway, I've redrafted the Blorb section again following these comments:

Blorb
-----
Blorb is now the standard resource format for the Z-machine.

Although the Standard does not require interpreters to handle Blorb, they
are
strongly urged to do so, as it is the format that authors use to create new
resources. Blorb versions of all the Infocom resources are now available, so
support for the original Infocom resource formats is no longer required.

Even if an interpreter does not support sound or graphics, it should still
support running a Z-code story file packaged in a Blorb file, as authors
will
wish to package games up with their resources.


Is this better?

Kevin
-----




From ???@??? Fri Dec 21 21:58:16 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 21 Dec 2001 10:11:46 +0100
From: Magnus Olsson <mol@df.lth.se>
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Message-ID: <20011221101146.A16112@igloo.df.lth.se>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE54ckeB2PcSoN5gfUw00005ff5@hotmail.com> <009a01c18995$bb856ae0$b72686d9@oemcomputer> <OE48WJueC7O0OcYqfUY00006300@hotmail.com> <010001c189ab$c1632e00$b72686d9@oemcomputer>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <010001c189ab$c1632e00$b72686d9@oemcomputer>; from kevin@bracey-griffith.freeserve.co.uk on Thu, Dec 20, 2001 at 11:12:09PM -0000
Sender: owner-z-machine@gmd.de
Precedence: bulk


On Thu, Dec 20, 2001 at 11:12:09PM -0000, Kevin Bracey wrote:
> > I create a z-terp, say, that people access via web pages, that only runs
> > games stored on the server. It can't support pictures or sound, and I have
> > complete control over which games are available. Is it worth the effort of
> > supporting blorb?
> 
> That's the same as Ross's point, which hadn't occurred to me. I would say
> no, but then similarly it isn't worth supporting Standard 1.1, as you're
> supplying the games, so standardisation isn't an issue anyway.

Au contraire, I think it is worth supporting Standard 1.1 in this case,
since (as I wrote earlier) the game may still want to query the interpreter
"are you 1.1 compliant", and if the answer is no, the game may disable
some features, because it doesn't know that the terp will handle those
features correctly.

-- 
Magnus Olsson (mol@df.lth.se, mol@pobox.com)
------    http://www.pobox.com/~mol   ------


From ???@??? Tue Dec 25 19:03:57 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.13.224]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Fri, 21 Dec 2001 10:12:37 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F134LAX3cf3ednHM3SO0000be6d@hotmail.com>
X-OriginalArrivalTime: 21 Dec 2001 15:12:37.0715 (UTC) FILETIME=[ECFD7A30:01C18A31]
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>



>And as I understand it, there's nothing stopping people from using
>different graphics and sounds formats inside a blorb file.  And
>the 1.1 standard as it stands doesn't require terps to support the
>standard blorb graphics or sound formats (though it is
>recommended), just the blorb file structure and the ability to
>extract a story file from the file.  All this means that it would
>still be perfectly 1.1-compliant to have a binding program that
>does this:

This is starting to get worrisome.  The Z-machine specification does not say 
anything about how the zcode gets to the interpreter. Now, we're talking 
about specifying that an embedded interpreter must come with an external 
tool for installing Z-code from a blorb file.

This is relatively dandy, but...

DOesn't this mean that *any* interpreter can meet the blorb requirement by 
including blorbscan in its distribution?


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


</x-flowed>
From ???@??? Tue Dec 25 19:03:59 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <000401c18a45$d2e6c480$1e1386d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <F134LAX3cf3ednHM3SO0000be6d@hotmail.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Fri, 21 Dec 2001 17:35:01 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> This is starting to get worrisome.  The Z-machine specification does not
say
> anything about how the zcode gets to the interpreter.

It does tell you how to distribute Z-code:

"Z-machine programs are stored on disc, or archived on the Internet, in what
are called story files. (Since they were introduced to hold interactive
stories.) A story file consists of a snapshot of main memory only. The
processor begins to run a story file by starting with an empty stack and a
PC value set according to some information in the story file's header."

If we weren't all agreed on that, the situation would be truly hopeless. But
it doesn't preclude the PalmOS (?) thing about converting to a different
format.

> Now, we're talking
> about specifying that an embedded interpreter must come with an external
> tool for installing Z-code from a blorb file.
>
> This is relatively dandy, but...
>
> DOesn't this mean that *any* interpreter can meet the blorb requirement by
> including blorbscan in its distribution?

Technically, yes. Pretty low-quality implementation though. It would at
least allow people to run Blorb-packaged files, which was the aim.

Kevin
-----



From ???@??? Tue Dec 25 19:04:18 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 21 Dec 2001 22:54:26 +0000
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v480)
From: Graham Nelson <graham@gnelson.demon.co.uk>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <026feceb4a.kbracey@kbracey.cam.pace.co.uk>
Message-Id: <AEDF2E7E-F665-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
X-Mailer: Apple Mail (2.480)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
On Thursday, December 20, 2001, at 05:13  pm, Kevin Bracey wrote:
> Unless there are any contentious issues, I suggest we call a vote 
> shortly.

I think I would prefer a little while to consider: e.g., we might call 
the vote
in early January. I point out that the wishlist grew as recently as this 
week,
and that standard revisions happen only every few years... (Yeah, I've
been lurking, though I confess I lost it a bit when it was all about 
footsteps.)

The key point is that a consensus needs to be reached which
involves interpreter writers; some standards put down markers for
the future (the Unicode extensions seemed more or less science
fiction when first proposed), but by and large we should obtain at
least grudging agreement that the new provisions will be written
eventually into the major interpreters. I appreciate this isn't easy.

I have several views on the proposed 1.1.

Overall, the proposal is well-reasoned. I'll probably vote for it.
On the other hand, I am anxious that we shouldn't create a giant
wishlist of everything missing from the ZM - I sort of feel that the XOR
opcode is an example of this: sure, it's trivial to implement, sure, it's
kind of surprising that there isn't one already, but at the end of the 
day
it serves little purpose except to make us feel better. The "microcode"
version of XOR isn't grotesquely large or slow, considering that we
don't want to XOR all that much. And who says a CPU needs an XOR?
The Pentium 4 doesn't have print_paddr, after all.

On the question of blessing Blorb, I am strongly in favour, puritanism
notwithstanding. None of the nuances in proposed-1.1 about sound and
graphics amount to a hill of beans unless there is a reliable delivery
mechanism for the multimedia content in question. I think Blorb has
served its apprenticeship in unofficial-standards-ville. (By writing a
chapter on Blorb into the book on Inform, I was hoping to give it a
nudge toward wider acceptance.)

I would also like a stronger statement in favour of supporting Quetzal,
though not to the extent of an absolute requirement, perhaps.

On the subject of revisions to bring the standard into line with
"what Infocom games/interpreters actually did", e.g. in the discussion
of v1 and v2 dictionary encodings, I am cautious to say the least.
Experience shows that Infocom's various binaries do not by any means
agree on any very simple rule, and a complex rule can be obfuscatory.
This was the motivation for having the commentary sections at the end
of each chapter, citing (among other things) quirky Infocom "deviations
from the standard". New evidence on things like v1 and v2 dictionary
encodings probably belong there, rather than in the standard.

> There are probably still editorial issues like history and contribution
> sections to go in, and creating a unified standard document, but we can 
> vote
> on approving the technical content of this document.

I will be happy to collate the document; I've been vaguely meaning to
produce a PDF spec in any case, but the web version would also remain.
I suspect that the barrier of having to explain something so that I can
understand it myself may be helpful in keeping the explanation clear.

On the other hand, let me make clear that I don't in any sense feel
that I "own" the format, and if the sense of the group is that it's time
somebody else served as town clerk, I'll be happy to step aside.
Standard 1.0 was a pretty democratic effort, in fact, and I believe I
can fairly honestly say that I took no unilateral decisions in drafting 
it.
Well, not many, anyway.

--
Graham Nelson


</x-flowed>
From ???@??? Tue Dec 25 19:04:20 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <000e01c18aff$53836c60$361486d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <AEDF2E7E-F665-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Sat, 22 Dec 2001 15:42:49 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


Graham, welcome back. I was rather concerned that you were totally unaware
of this.
It's really good to hear from you.

>
> I think I would prefer a little while to consider: e.g., we might call
> the vote
> in early January.

Yes, there's no hurry. I'm off for Christmas shortly anyway.

> The key point is that a consensus needs to be reached which
> involves interpreter writers; some standards put down markers for
> the future (the Unicode extensions seemed more or less science
> fiction when first proposed),

Judging by recent discussions with Fredrik Ramsberg it would appear that
even the accented character support in Std 0.2 is pretty much
science-fiction as far as most people are concerned :)

> but by and large we should obtain at
> least grudging agreement that the new provisions will be written
> eventually into the major interpreters. I appreciate this isn't easy.

I'm very aware of this. What I am personally proposing to do, as an
individual, is to attempt to kick-start the process by running a
competition, with significant cash prizes, to get decent interpreters
written/updated, once this Standard is agreed.

My feeling is that authors' lives have been made unnecessarily difficult by
lack of progress on the interpreter front, and I have found it frustrating
that Zip 2000 is ready and waiting, but no content is forthcoming, because
of the state of other platforms. Therefore I'm more than ready to stump up
cash for anyone who can create good Standard interpreters. I'm also
interested in spreading Glulx a bit more too, although that's not currently
my primary interest.

Whether this will work or not, I don't know. If it doesn't, it won't cost me
anything, at least.

> Overall, the proposal is well-reasoned. I'll probably vote for it.
> On the other hand, I am anxious that we shouldn't create a giant
> wishlist of everything missing from the ZM - I sort of feel that the XOR
> opcode is an example of this: sure, it's trivial to implement, sure, it's
> kind of surprising that there isn't one already, but at the end of the
> day
> it serves little purpose except to make us feel better.

I'm still in two minds about that particular addition, but I think my basic
thought was that it is a curious omission, and the addition is so trivial,
that we may as well do it at the same time as the other more significant
changes. I was surprised actually that the suggestion was accepted so
readily.

> The "microcode"
> version of XOR isn't grotesquely large or slow, considering that we
> don't want to XOR all that much. And who says a CPU needs an XOR?
> The Pentium 4 doesn't have print_paddr, after all.

In my local copy of Inform, I've added an ^ operator the hard way, and it's
not too much trouble, apart from the general code messiness you get from
spitting out multi-instruction code sequences in the code generator in the
absence of a peepholer. (Similar problems arise in creating >> and >>>
operators). You just end up having to use a couple of temporary globals in
some cases (bleurgh). If I was a bit more confident, I'd create the code as
an expression tree, but in the absence of CSE, I think it'd end up
evaluating the parameters twice.

In practice, I can't see anyone using it for some time anyway, unless
Standard 1.1 really does become very established. People are hardly going to
wrap their XOR instructions in "if (standard_interpreter >= $0101)"...

All the time I am very conscious that if we go too far, then we may as well
abandon the Z-machine and switch to Glulx. The strongest thing that the
Z-machine has in its favour is portability, and we mustn't endanger that
lightly.

> On the question of blessing Blorb, I am strongly in favour, puritanism
> notwithstanding. None of the nuances in proposed-1.1 about sound and
> graphics amount to a hill of beans unless there is a reliable delivery
> mechanism for the multimedia content in question. I think Blorb has
> served its apprenticeship in unofficial-standards-ville. (By writing a
> chapter on Blorb into the book on Inform, I was hoping to give it a
> nudge toward wider acceptance.)

That sums up my feeling too. But there are those who are strong proponents
of keeping the Z-machine spec abstract, and not sully itself with mandating
file formats. But then we end up with a sort of black hole - if the
Z-machine standard shouldn't talk about Blorb, and the Blorb standard can't
talk about the Z-machine (both those views have been advocated here) then
what can we do?

I've always believed that the coyness in the current Standard about resource
formats is not a philosophical one, but a practical one, given the lack of a
good standard choice at the time. I think that time has passed.

I've created two attempts at wording the Blorb requirement - the one in the
draft and the one I posted a couple of days ago. Do you have any better
thoughts?

> I would also like a stronger statement in favour of supporting Quetzal,
> though not to the extent of an absolute requirement, perhaps.

I'm disappointed about Quetzal's reception too. I've had e-mail queries from
Zip 2000 users asking if they can transfer games to their PDA. I said yes,
over-optimistically, only to find out that the PDA terps aren't using
Quetzal. Sigh.

The Standard currently "urges" interpreters to support Quetzal, but only in
the remarks section - the main spec cops out with "6.1.1.1 The format of a
saved game file is not specified." That isn't terribly satisfactory, but
unless we mandate Quetzal, whatever we do to it won't be a technical change,
so we could leave that up to the final editor, whoever it may be.

> This was the motivation for having the commentary sections at the end
> of each chapter, citing (among other things) quirky Infocom "deviations
> from the standard". New evidence on things like v1 and v2 dictionary
> encodings probably belong there, rather than in the standard.

Yes, I'd agree that's where that belongs in a unified spec. There are
probably other items like that (like the whole V3+ shift lock thing). The
original draft Jason proposed had attempts at actual replacement sections as
well, but that meant we had a document containing every change twice, which
got confusing. But in their absence, it's a little unstructured.

> I will be happy to collate the document; I've been vaguely meaning to
> produce a PDF spec in any case, but the web version would also remain.
> I suspect that the barrier of having to explain something so that I can
> understand it myself may be helpful in keeping the explanation clear.

Yes - it's great for something to pass through a second pair of hands. If
you would be prepared to do that, it'd be hugely appreciated. What is the
master format - is it still TeX? I quite miss the nice formatting of the
0.99 version.

> On the other hand, let me make clear that I don't in any sense feel
> that I "own" the format, and if the sense of the group is that it's time
> somebody else served as town clerk, I'll be happy to step aside.

I think stability is important, so I don't anticipate any more changes for a
few more years. If ever, maybe. Perhaps Glulx (or something else) will
obsolete the Z-machine in time. Who knows?

I think that as an informal, democratic forum, this is a good place for a
standard like this to be formed, edited, and finalised. The PNG standard is
maintained in a similar fashion on another mailing list I follow (although
now it's on its way to become an ISO standard too, which is another whole
kettle of fish). Editors come and go, but the group decides in the end.

> Standard 1.0 was a pretty democratic effort, in fact, and I believe I
> can fairly honestly say that I took no unilateral decisions in drafting
> it.
> Well, not many, anyway.

In co-editing this draft, I've been well aware that as editor one has far
too much power, especially if it ends up going to just a yes/no vote :) I
hope I haven't abused it though. I know I'm not asking anyone to do anything
I'm not prepared to do myself - indeed my copy of Zip 2000 has been tracking
changes to the draft just to check that what I've written makes sense and is
implementable in practice.

Kevin
-----



From ???@??? Tue Dec 25 19:04:45 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-eGroups-Return: z-machine-owner@mail.gmd.de
X-Yahoo-MsgId: <mta551.mail.yahoo.com.1009045311.79189.0011>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sat, 22 Dec 2001 18:16:47 +0000
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v480)
From: Graham Nelson <graham@gnelson.demon.co.uk>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <000e01c18aff$53836c60$361486d9@oemcomputer>
Message-Id: <0FC88C88-F708-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
X-Mailer: Apple Mail (2.480)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
On Saturday, December 22, 2001, at 03:42  pm, Kevin Bracey wrote:
> Graham, welcome back. I was rather concerned that you were totally 
> unaware
> of this.

Like the Horror, I lurk.

>> The "microcode"
>> version of XOR isn't grotesquely large or slow, considering that we
>> don't want to XOR all that much. And who says a CPU needs an XOR?
>> The Pentium 4 doesn't have print_paddr, after all.
>
> In my local copy of Inform, I've added an ^ operator the hard way, and 
> it's
> not too much trouble, apart from the general code messiness you get from
> spitting out multi-instruction code sequences in the code generator in 
> the
> absence of a peepholer. (Similar problems arise in creating >> and >>>
> operators). You just end up having to use a couple of temporary globals 
> in
> some cases (bleurgh).

As you say. Speaking from the point of view of somebody who did indeed
have to write a code generator for the ZM, however amateurishly, the
single most annoying thing missing was a 0OP "dup" instruction to
duplicate the top of the stack. It's amazing how cumbersome lots of
inline-coded operations are without it (for instance, checking that
a number is non-zero before dividing by it). If I were going to add one
instruction of the non-multimedia sort to the ZM, that would be it.
But I rather take the view that the ship has sailed and that no such
instructions (like XOR) should now be added. I think there's also a
sense in which our changes should be minimal and restricted to
what is needful, exactly in order to make it easier to persuade the
world to rewrite its interpreters.

(Of course if you call temporary globals "registers" it's slightly
less embarrassing to have to admit that you use them.)

> I've always believed that the coyness in the current Standard about 
> resource
> formats is not a philosophical one, but a practical one, given the lack 
> of a
> good standard choice at the time. I think that time has passed.

I think that's exactly right. I view the philosophical issue thus:
(a) the ZM spec should be austere and minimal in environmental
requirements in so far as reasonably possible; (b) in the case of purely
textual games with no state outside themselves, that is indeed possible
and desirable; (c) in the case of games needing pictures, sounds or
external files, one cannot maintain the pretence that the outside world
does not exist, and the Z spec's current silence is counterproductive.
(For instance on whether file reading and writing stops to prompt the
player, or, conversely, has some kind of right to any filenames it 
likes.)

I think it's pretty much common ground that an interpreter supporting
pictures and sound ought to be required to accept Blorb resources.
So far as I understand the debate, the real crunch question is whether
a purely textual interpreter with no such need, perhaps in an
environment where pictures are absurd, ought to accept Blorbs.
My feeling is that it should, under the strictly worded understanding
that it is not required to even look at any chunk except the Z-code
itself -- this would be enough to satisfy the standard. The reason
I agree with this proposal is that it seems entirely reasonable for
an author to compose a Blorb containing a purely textual game as
Z-code, plus a chunk giving the game's title, authorship, etc.

What I suggest is that with this, as with every other proposed change,
somebody very public-spirited (i.e. Kevin) might produce some
reference C source which as portably and transplantably as possible
implements the feature in question, heavily commenting what it's
trying to do: e.g., in the case of this Blorb rule, a routine which
literally does the minimum possible to look at a file, decide if it's
Z-code or a Blorb, and in either case leave the file I/O point at the
first byte of the Z-code header.  Something not requiring the
full majesty of scanblorb.

The curious thing about this argument is that if the Blorb specification
had as one of its rules that the initial byte had to be a 9, we could
simply declare that a Blorb file is version 9 of the Z-machine format.
I slightly suspect that the purists would then find the change
acceptable. The whole point of Blorb is not to attach lots of untidy,
flapping entrails to the Z-machine so that it messily extends into
the outside world; it's to do the exact reverse, to bring in and
enclose the necessary parts of the outside world within the
Z-machine, producing a much tidier frontier.

--
Graham Nelson



</x-flowed>
From ???@??? Tue Dec 25 19:04:47 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <000401c18b26$07e8cd00$d20f86d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <0FC88C88-F708-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Sat, 22 Dec 2001 20:19:57 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> As you say. Speaking from the point of view of somebody who did indeed
> have to write a code generator for the ZM, however amateurishly, the
> single most annoying thing missing was a 0OP "dup" instruction to
> duplicate the top of the stack. It's amazing how cumbersome lots of
> inline-coded operations are without it (for instance, checking that
> a number is non-zero before dividing by it). If I were going to add one
> instruction of the non-multimedia sort to the ZM, that would be it.

I was thinking of adding that myself, but the instruction is actually
already there:

      load sp -> sp

Admittedly, that's 3 bytes, but it exists. Now I will confess to some
versions of Zip 2000 actually getting that wrong, but no-one else ever has
AFAIK. (I added that indirected variable clarification to the draft to make
sure no-one else ever made the same mistake again).

The other two I was considering are instructions to swap the top two stack
elements, and a tailcall instruction.

> But I rather take the view that the ship has sailed and that no such
> instructions (like XOR) should now be added. I think there's also a
> sense in which our changes should be minimal and restricted to
> what is needful, exactly in order to make it easier to persuade the
> world to rewrite its interpreters.

I was quite prepared to withdraw the XOR suggestion rapidly, but even "the
world's laziest interpreter author" seemed enthusiastic :) I've found it
quite surprising which items have actually turned out to be contentious.

But if things can be gotten right in the compiler rather than the
interpreters, I'm all for it. I was having this argument a few months back
on RAIF when someone was complaining about V6 being limited to 320K by
Inform, and proposing creating a new V8/V6 hybrid. I've since managed to
create an Inform patch that lifts that memory restriction, thank goodness.

As far as most people are concerned, as long as Inform has the operators, it
doesn't matter how they're implemented. It's just that there's still the
continuing ties between Inform's operators and the Z-machine's, with the
result that Inform doesn't have XOR either. So let's make a deal. You add a
^ operator to Inform, and I'll take it out of the Z-machine :) I'll give you
my attempt at adding it to expressc to laugh at.

Oh, one of my other top Inform features would be
"opcodes-as-function-calls". I'd like to be able to write char_w =
_get_wind_prop(0,4) >> 8; or similar. Or _window_size(40*char_w, 20*char_h),
kind of thing, as was clearly possible in ZIL. But then I'm an unrepentant
assembler hacker.

> (Of course if you call temporary globals "registers" it's slightly
> less embarrassing to have to admit that you use them.)

Heh.

> I think it's pretty much common ground that an interpreter supporting
> pictures and sound ought to be required to accept Blorb resources.

Not totally. There's also some debate about whether an interpreter has to
handle Blorb graphics. It might be on a PDA-type device, and only accept
some other stripped down format, and come with a desktop-based converter
program. This is already the situation with PalmOS (I think) whose
interpreters don't accept "raw" Z-code files. My personal view is that the
converter is in effect part of the implementation, and as long as it obeys
the file-handling rules, that's fine.

> So far as I understand the debate, the real crunch question is whether
> a purely textual interpreter with no such need, perhaps in an
> environment where pictures are absurd, ought to accept Blorbs.
> My feeling is that it should, under the strictly worded understanding
> that it is not required to even look at any chunk except the Z-code
> itself -- this would be enough to satisfy the standard. The reason
> I agree with this proposal is that it seems entirely reasonable for
> an author to compose a Blorb containing a purely textual game as
> Z-code, plus a chunk giving the game's title, authorship, etc.

Okay, I'm glad there is _someone_ who's with me on this - I was considering
pulling the original wording altogether, given the general opposition. We
can leave it as an option in the vote.

Ross has pointed out that if we allow converters to be part of the
implementation, then just supplying a copy of Blorbscan to extract the
Z-code would be a sufficient implementation. Which I don't think I can deny.

> What I suggest is that with this, as with every other proposed change,
> somebody very public-spirited (i.e. Kevin)

Thankyou.

> might produce some
> reference C source which as portably and transplantably as possible
> implements the feature in question, heavily commenting what it's
> trying to do: e.g., in the case of this Blorb rule, a routine which
> literally does the minimum possible to look at a file, decide if it's
> Z-code or a Blorb, and in either case leave the file I/O point at the
> first byte of the Z-code header.  Something not requiring the
> full majesty of scanblorb.

Well, a Standard 1.1 Zip 2000 will be available within days of ratification.
For many of the features, it should be quite intelligible as to how they're
implemented, and the original Zip structure is still visible, so it
shouldn't be too alien to people. I'll publish some notes directing people
to salient parts of the code, with explanations of the principles.

Kevin
-----



From ???@??? Tue Dec 25 19:04:48 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sat, 22 Dec 2001 21:45:06 +0000
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v480)
From: Graham Nelson <graham@gnelson.demon.co.uk>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <000401c18b26$07e8cd00$d20f86d9@oemcomputer>
Message-Id: <2A0D8034-F725-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
X-Mailer: Apple Mail (2.480)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
On Saturday, December 22, 2001, at 08:19  pm, Kevin Bracey wrote:
>> As you say. Speaking from the point of view of somebody who did indeed
>> have to write a code generator for the ZM, however amateurishly, the
>> single most annoying thing missing was a 0OP "dup" instruction to
>> duplicate the top of the stack.
> I was thinking of adding that myself, but the instruction is actually
> already there:
>
>       load sp -> sp
>
> Admittedly, that's 3 bytes, but it exists.

Am I going slightly mad here? Surely this instruction is a nop --
it pops a value from the stack, then pushes it back on again.
Whereas I want to pop it once then push it back twice.

--
Graham Nelson


</x-flowed>
From ???@??? Tue Dec 25 19:04:51 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-eGroups-Return: z-machine-owner@mail.gmd.de
X-Yahoo-MsgId: <mta569.mail.yahoo.com.1009058197.44117.0038>
X-Track: 1: 40
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <002e01c18b33$1e865e80$dd4086d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <2A0D8034-F725-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Sat, 22 Dec 2001 21:53:39 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


From: "Graham Nelson" <graham@gnelson.demon.co.uk>
> On Saturday, December 22, 2001, at 08:19  pm, Kevin Bracey wrote:
> > I was thinking of adding that myself, but the instruction is actually
> > already there:
> >
> >       load sp -> sp
> >
> > Admittedly, that's 3 bytes, but it exists.
>
> Am I going slightly mad here? Surely this instruction is a nop --
> it pops a value from the stack, then pushes it back on again.
> Whereas I want to pop it once then push it back twice.

Aha, that's where you're wrong. Little-known fact: indirect references to
the stack don't push or pull it. It's not in the modern Standard, but all
known interpreters get it right, except Zip 2000 1.40 and 1.41 (ahem). It's
a note I've added to the draft.

Therefore load sp -> sp reads the top item of the stack without popping it,
and pushes the result on.

Kevin
-----




From ???@??? Tue Dec 25 19:04:52 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.13.162]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Sat, 22 Dec 2001 17:20:07 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F9dSe9g4pXX50yki4js0000d14c@hotmail.com>
X-OriginalArrivalTime: 22 Dec 2001 22:20:08.0232 (UTC) FILETIME=[D04D8280:01C18B36]
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
>
>I was quite prepared to withdraw the XOR suggestion rapidly, but even "the
>world's laziest interpreter author" seemed enthusiastic :) I've found it
>quite surprising which items have actually turned out to be contentious.


Well, the obvious trouble in the case of XOR is that it's only beneficial to 
have an opcode for it if you can use it freely; in the absence of XOR, A ^ B 
is:

(a|b)&~(a&b)

In the presence of it, as proposed, it's:

if (spec 1.1)
a^b
else
(a|b)&~(a&b)

Which comes down to there not being much point.

>But if things can be gotten right in the compiler rather than the
>interpreters, I'm all for it. I was having this argument a few months back
>on RAIF when someone was complaining about V6 being limited to 320K by
>Inform, and proposing creating a new V8/V6 hybrid. I've since managed to
>create an Inform patch that lifts that memory restriction, thank goodness.

You did?  Excellent. I can stick all the really silly stuff back in Moments.

>Oh, one of my other top Inform features would be
>"opcodes-as-function-calls". I'd like to be able to write char_w =
>_get_wind_prop(0,4) >> 8; or similar. Or _window_size(40*char_w, 
>20*char_h),
>kind of thing, as was clearly possible in ZIL. But then I'm an unrepentant
>assembler hacker.

Hm... Would it satisfy you if I just released a library fulll of wrappers?
(Come to think of it, that might be handy for helping people who've 
foolishly decided to make the glulx jump.)


>Not totally. There's also some debate about whether an interpreter has to
>handle Blorb graphics. It might be on a PDA-type device, and only accept
>some other stripped down format, and come with a desktop-based converter
>program. This is already the situation with PalmOS (I think) whose
>interpreters don't accept "raw" Z-code files. My personal view is that the
>converter is in effect part of the implementation, and as long as it obeys
>the file-handling rules, that's fine.
>

Right. There's a number of implementations that don't work in the "you give 
me a file, I play the game" fashion; "embedded" ones, which take their file 
from their own executable, and terps for bizarre platforms where the concept 
of "file" is different.  It doesn't make sense to require them to take Blorb 
files. In the second category, it doesn't make sense to talk about "where 
they get their files from" because it doesn't.  I can accept the idea that 
compliance is achieved by having the packaging program accept blorb (though 
this again still assumes that the game starts life as a file on a 
traditional computer.  But that's just a silly philosophical objection.), 
except that that seems to be in danger of leaving the spec toothless, since 
compliance would be achieved by bundling a blorb-extractor with any 
interpreter.
(which you go on to say in the next paragraph. Oh.)

Now, it falls outside of the spec's domain, I think, that even if you made 
your palm machine accept suitably-pre-encoded blorb files, and it didn't 
have to look at anything but the exec chunk thereof, you're in trouble if 
you try to stick a 20 meg blorb file on the thing.


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


</x-flowed>
From ???@??? Tue Dec 25 19:04:53 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sat, 22 Dec 2001 17:30:39 -0500
Subject: [z-machine] Off on a bit of a tangent -- stack use in the Z-machine
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <002e01c18b33$1e865e80$dd4086d9@oemcomputer>
Message-Id: <87097E1B-F72B-11D5-B9F4-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

On Saturday, December 22, 2001, at 04:53 PM, Kevin Bracey wrote:
>
> Aha, that's where you're wrong. Little-known fact: indirect references 
> to
> the stack don't push or pull it. It's not in the modern Standard, but 
> all
> known interpreters get it right, except Zip 2000 1.40 and 1.41 (ahem). 
> It's
> a note I've added to the draft.
>
> Therefore load sp -> sp reads the top item of the stack without popping 
> it,
> and pushes the result on.

I'm fairly sure I've seen some of this chicanery in at least one of the 
Infocom games (the Sorceror beta).  Confused the heck out of me until I 
figured out what it was doing.

Ahh, yes, here's one use:

  b096:  je              local1 #04 ~b0c9
  b09a:  loadb           local0 #01 -> sp
  b09e:  load            [sp] -> sp
  b0a1:  jz              sp b0af
  b0a4:  loadb           local0 #00 -> sp
  b0a8:  call            c83e sp -> sp
  b0ae:  ret_popped

This beta does a number of other clever things with the stack, often 
leaving the values on across branches rather than using a temporary 
local to store intermediate results.  I think the non-beta games are a 
bit less free with stack usage, but Sorcerer version 4 has the "load 
[sp] -> sp" instruction at ad8f.

BTW, Zplet also gets it wrong.


</x-flowed>
From ???@??? Tue Dec 25 19:04:54 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <004301c18b39$26860a80$dd4086d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <F9dSe9g4pXX50yki4js0000d14c@hotmail.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Sat, 22 Dec 2001 22:36:47 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> >But if things can be gotten right in the compiler rather than the
> >interpreters, I'm all for it. I was having this argument a few months
back
> >on RAIF when someone was complaining about V6 being limited to 320K by
> >Inform, and proposing creating a new V8/V6 hybrid. I've since managed to
> >create an Inform patch that lifts that memory restriction, thank
goodness.
>
> You did?  Excellent. I can stick all the really silly stuff back in
Moments.

Get it from Roger's patch page; I'd like feedback. Unfortunately it does
increase overhead, so as soon as you activate the "big memory model" switch
you'll lose 4% or so (probably less in something like Moments with huge
chunks of text).

> >Oh, one of my other top Inform features would be
> >"opcodes-as-function-calls". I'd like to be able to write char_w =
> >_get_wind_prop(0,4) >> 8; or similar. Or _window_size(40*char_w,
> >20*char_h),
> >kind of thing, as was clearly possible in ZIL. But then I'm an
unrepentant
> >assembler hacker.
>
> Hm... Would it satisfy you if I just released a library fulll of wrappers?
> (Come to think of it, that might be handy for helping people who've
> foolishly decided to make the glulx jump.)

Not quite - it's inefficient and a bugger to debug. (Er, what a phrase).
I've found it a pain when debugging at a low level if you've only got one
window_size opcode in the whole game, in a function that's called
everywhere. You have to start messing with stack backtraces.

I think it's fairly straightforward to do - I'll look at it later. We just
need a sensible syntax.

Kevin
-----



From ???@??? Tue Dec 25 19:04:55 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Sat, 22 Dec 2001 17:41:45 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C24C5D9.2951.54B1FF3@localhost>
In-reply-to: <F9dSe9g4pXX50yki4js0000d14c@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


L. Ross Raszewski sent a message across the ether on 22 Dec 2001 (17:20) 
stating:

> Now, it falls outside of the spec's domain, I think, that even if you 
made 
> your palm machine accept suitably-pre-encoded blorb files, and it 
didn't 
> have to look at anything but the exec chunk thereof, you're in trouble 
if 
> you try to stick a 20 meg blorb file on the thing.

I have a 64 MB Compact Flash card on my Visor (which runs PalmOS).  I 
imagine things like that will become more and more common for PDA style 
devices, so it's not that far fetched.

Jay
-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -
=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Tue Dec 25 19:04:56 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <004801c18b3b$ab3cbba0$dd4086d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <87097E1B-F72B-11D5-B9F4-0050E4A0CE52@speakeasy.net>
Subject: Re: [z-machine] Off on a bit of a tangent -- stack use in the Z-machine
Date: Sat, 22 Dec 2001 22:54:49 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


"Matthew T. Russotto" <mrussotto@speakeasy.net> wrote
>
> On Saturday, December 22, 2001, at 04:53 PM, Kevin Bracey wrote:
> > Therefore load sp -> sp reads the top item of the stack without popping
> > it,
> > and pushes the result on.
>
> I'm fairly sure I've seen some of this chicanery in at least one of the
> Infocom games (the Sorceror beta).  Confused the heck out of me until I
> figured out what it was doing.
>
> Ahh, yes, here's one use:
>
>   b096:  je              local1 #04 ~b0c9
>   b09a:  loadb           local0 #01 -> sp
>   b09e:  load            [sp] -> sp
>   b0a1:  jz              sp b0af
>   b0a4:  loadb           local0 #00 -> sp
>   b0a8:  call            c83e sp -> sp
>   b0ae:  ret_popped

That's not it - it's got the square brackets in. I think the loadb there
must be loading a global variable number from a property, which the load
then inspects. I think it's a standard part of Infocom's "GO" routine - it's
still there in Zork Zero :)

> BTW, Zplet also gets it wrong.

Poo. But it's infamously buggy on a number of counts, isn't it? Always the
danger of a new implementation.

Kevin
-----



From ???@??? Tue Dec 25 19:04:58 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sat, 22 Dec 2001 21:48:07 -0500
Subject: Re: [z-machine] Off on a bit of a tangent -- stack use in the Z-machine
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <004801c18b3b$ab3cbba0$dd4086d9@oemcomputer>
Message-Id: <7E7EE0AC-F74F-11D5-B9F4-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

On Saturday, December 22, 2001, at 05:54 PM, Kevin Bracey wrote:

>> BTW, Zplet also gets it wrong.
>
> Poo. But it's infamously buggy on a number of counts, isn't it?

Mostly slander based on some old/incomplete versions floating around the 
net.  Zplet is only Standard 0.2, but it's pretty decent Standard 0.2.


</x-flowed>
From ???@??? Tue Dec 25 19:05:09 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <000c01c18ba7$d07ae9c0$1e1186d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <7E7EE0AC-F74F-11D5-B9F4-0050E4A0CE52@speakeasy.net>
Subject: Re: [z-machine] Off on a bit of a tangent -- stack use in the Z-machine
Date: Sun, 23 Dec 2001 11:48:55 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


Matthew Russotto wrote:
> On Saturday, December 22, 2001, at 05:54 PM, Kevin Bracey wrote:
>
> >> BTW, Zplet also gets it wrong.
> >
> > Poo. But it's infamously buggy on a number of counts, isn't it?
>
> Mostly slander based on some old/incomplete versions floating around the
> net.  Zplet is only Standard 0.2, but it's pretty decent Standard 0.2.

I found out after I wrote that that you were the author (whoops), and it was
still being actively maintained. Sorry - my knowledge of other terps is a
little hazier than it should be. I'd just come from a site that was busy
explaining all the things that wouldn't work on his on-line game using zplet
:)

Looking at the source on sourceforge, it looks like you made exactly the
same mistake I did in Zip 2000 1.40 - I couldn't see the need for both
load_variable() and load_operand() in the original Zip source, so I
"optimised" it.

Mind you, I'm still struggling to find an example in an Infocom file. The
only places it matters are @load sp -> x,  @store sp x, and @pull sp. @pull
sp is interesting, because it effectively throws away the second stack item.
Can't think of a use for it though, and it's not available in V6.

I think it's one case where something that was well known by the first
Infocom-hackers was left out of the Standard, which has misled later
interpreter authors. All interpreters prior to the Standard (that I've
checked) got it right - ITF, Pinfocom, Zip, Infocom's own. Frotz also gets
it right, as it fairly closely followed Zip's structure.

Hopefully Zip 2000 and Zplet are the only offenders, and they can be fixed
in the next version. Actually, no, I've just checked Nitfol - it's wrong
too. Sigh. Is Evin Robertson here?

Kevin
-----



From ???@??? Tue Dec 25 19:05:12 2001
Return-Path: <z-machine-owner@mail.gmd.de>
Message-ID: <20011223135553.92992.qmail@mta467.mail.yahoo.com>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sun, 23 Dec 2001 13:54:12 +0000
Subject: Re: [z-machine] Off on a bit of a tangent -- stack use in the Z-machine
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v480)
From: Graham Nelson <graham@gnelson.demon.co.uk>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <000c01c18ba7$d07ae9c0$1e1186d9@oemcomputer>
X-Mailer: Apple Mail (2.480)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
On Sunday, December 23, 2001, at 11:48  am, Kevin Bracey wrote:
> Mind you, I'm still struggling to find an example in an Infocom 
> file. [...]
> I think it's one case where something that was well known by the first
> Infocom-hackers was left out of the Standard, which has misled later
> interpreter authors. All interpreters prior to the Standard (that I've
> checked) got it right - ITF, Pinfocom, Zip, Infocom's own. Frotz also 
> gets
> it right, as it fairly closely followed Zip's structure.

Can we put "right" in quotation marks here? Call me a sceptic,
but I haven't yet been persuaded that @load sp -> sp "should be"
anything other than a no-op. If there are no unambiguous witnesses
in the Infocom story files, surely that should tell us that this is not
an exception after all?

Just because Mark Howells coded it that way in the days of
trial and error, and this was perpetuated in early pre-Standard
interpreters, doesn't make it anything more than a popular
tradition...

--
Graham Nelson


</x-flowed>
From ???@??? Tue Dec 25 19:05:17 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <8B68ADF0-F7AC-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
Subject: Re: [z-machine] Off on a bit of a tangent -- stack use in the Z-machine
Date: Sun, 23 Dec 2001 14:43:37 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE49FgPGksocLlskVsC0000780a@hotmail.com>
X-OriginalArrivalTime: 23 Dec 2001 14:40:51.0910 (UTC) FILETIME=[D1DE3660:01C18BBF]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Graham Nelson" <graham@gnelson.demon.co.uk>
To: <z-machine@gmd.de>
Sent: Sunday, December 23, 2001 1:54 PM
Subject: Re: [z-machine] Off on a bit of a tangent -- stack use in the
Z-machine


> On Sunday, December 23, 2001, at 11:48  am, Kevin Bracey wrote:
> > Mind you, I'm still struggling to find an example in an Infocom
> > file. [...]
> > I think it's one case where something that was well known by the first
> > Infocom-hackers was left out of the Standard, which has misled later
> > interpreter authors. All interpreters prior to the Standard (that I've
> > checked) got it right - ITF, Pinfocom, Zip, Infocom's own. Frotz also
> > gets
> > it right, as it fairly closely followed Zip's structure.
>
> Can we put "right" in quotation marks here? Call me a sceptic,
> but I haven't yet been persuaded that @load sp -> sp "should be"
> anything other than a no-op. If there are no unambiguous witnesses
> in the Infocom story files, surely that should tell us that this is not
> an exception after all?
>
> Just because Mark Howells coded it that way in the days of
> trial and error, and this was perpetuated in early pre-Standard
> interpreters, doesn't make it anything more than a popular
> tradition...

Yes, but Infocom coded it that way, too. It's in the z3, z4, z5 and z6
interpreters for DOS. I would say that if there's no evidence one way
or the other in the Infocom story files, then the fact that all the
Infocom interpreters work the same way, and the majority of modern
interpreters also work that way, should be taken as evidence that
this is the way to proceed. Which means I need to do some quick
patching of my own interpreter.

Whichever way we go, it should certainly be mentioned in the spec.

--
Fillmore


From ???@??? Tue Dec 25 19:05:47 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <003e01c18be2$28b36600$a33986d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <8B68ADF0-F7AC-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
Subject: Re: [z-machine] Off on a bit of a tangent -- stack use in the Z-machine
Date: Sun, 23 Dec 2001 18:46:37 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


Graham wrote:
> Just because Mark Howells coded it that way in the days of
> trial and error, and this was perpetuated in early pre-Standard
> interpreters, doesn't make it anything more than a popular
> tradition...

I've checked the source of a few more terps (just looking at LOAD).

All pre-standard terps in the IF-archive follow the Infocom interpreters -
Zmachine, Pinfocom, ITF, Zip, Zipdebug, Zterp, YAZI, and they all have
special code to handle it (eg Zterp's fetch_variable_nopop() function) -
it's not the "default" behaviour that arises from a naive implementation.
Frotz also falls into this class.

Unfortunately, modern terps have followed the letter of the Standard:
Nitfol, Malyon, ZAX, Zplet, Zeal are the offenders I've found.

So it really looks as though the behaviour was changed by the publishing of
the Standard. Which would be a bit ironic, if you've been pining for a DUP
instruction all this time.

I'm still looking for an example of it being used in an Infocom story file.

Kevin
-----



From ???@??? Tue Dec 25 21:02:38 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp4.ihug.co.nz: Host p183-apx1.akl.ihug.co.nz [203.173.192.183] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20011225203419.076edd80@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 25 Dec 2001 20:59:20 +1300
To: <z-machine@gmd.de>
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
In-Reply-To: <000401c18b26$07e8cd00$d20f86d9@oemcomputer>
References: <0FC88C88-F708-11D5-A23F-00039340BD8A@gnelson.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
At 20:19 22/12/01 +0000, Kevin Bracey wrote:
 >
 >> So far as I understand the debate, the real crunch question is 

 >> whether a purely textual interpreter with no such need, 
perhaps
 >> in an environment where pictures are absurd, ought to accept
 >> Blorbs.  My feeling is that it should, under the strictly 
worded
 >> understanding that it is not required to even look at any 
chunk
 >> except the Z-code itself -- this would be enough to satisfy 
the
 >> standard. The reason I agree with this proposal is that it 
seems
 >> entirely reasonable for an author to compose a Blorb 
containing
 >> a purely textual game as Z-code, plus a chunk giving the 
game's
 >> title, authorship, etc.
 >
 >Okay, I'm glad there is _someone_ who's with me on this - I was
 >considering pulling the original wording altogether, given the
 >general opposition. We can leave it as an option in the vote.

For the record, I agree with you too.  (Mind you, I'm also not an 
interpreter author, just an interested party.)  Regardless of 
platform, all standard interpreters should support Blorb, at least 
to being able to extract the z-code chunk.  And before you 
embedded OS people start screaming at me, I've got some more to 
say about it later ;)

 >Ross has pointed out that if we allow converters to be part of 
the
 >implementation, then just supplying a copy of Blorbscan to 
extract
 >the Z-code would be a sufficient implementation. Which I don't 
think
 >I can deny.

As it stands, yes.  Nobody could deny that it was ugly, 
however.  I've got an idea about that, too.

Right, now back to the embedded OS debate.  I regard this as two 
separate categories:
   1. "Desktop" platforms; any standard PC-style computing 
environment, with a full filesystem.  DOS, Windows, Macintosh, 
Amiga, Unix, Commodore 64, whatever.
   2. "Embedded" platforms; any restricted computing environment, 
with no filesystem (or a weird filesystem), or restrictions on 
image formats.  PalmOS, (maybe) WindowsCE, PlayStation, etc.

For desktop platforms, the interpreter should be regarded as 
standalone.  The interpreter should, itself, with no external 
software (at least visible to the user - it's allowed to use 
external libraries), be capable of reading a Blorb file and 
extracting its z-code.  At a bare minimum.  Hopefully (if the terp 
itself supports sound or graphics) it can also get these from the 
Blorb file.

For embedded platforms, it's slightly more complex.  As I see it, 
there's only three ways for files to enter an embedded system:
   1. Transfer from a "host" desktop environment
      In this case, the embedded terp and the program that 
accomplishes the transfer can be considered a unit, and the terp 
can be considered compliant if the unit collectively is 
compliant.  This means that the transfer program can extract the 
z-code and attach it to a terp stub to produce an executable game 
that will run on the embedded platform.
   2. Transfer from another compatible embedded platform
      Whether from some sort of infrared or cable link, or through 
exchanging disks or CDs, the game is transferred from one device 
to another.  This is a no-brainer - the game should already be in 
the correct format and can be directly executed at the 
destination.
   3. Transfer via the Internet
      I may be wrong, but I think that any embedded platform 
capable of Internet access (to the point of downloading arbitrary 
files) should also be capable of desktop-like file handling.  So 
the terp should be able to internally load Blorb files.  Possibly 
a "Blorb-stripper" could also be included (not as a requirement to 
play, but as a way to reduce storage space) to remove or convert 
those parts of a Blorb file that the terp is incapable of 
handling.

So the upshot of my little tirade, I guess, is that while passing 
the Blorb file through a conversion program to get it executable 
is okay for embedded platforms (since you have to do something 
similar to get it onto them anyway), it should not be acceptable 
for "desktop" platforms.  Basically because they don't really have 
any good excuse to do it, so they shouldn't :P  (As several people 
have pointed out, the draft as it stands would allow this; I'm 
suggesting a rewording may be in order)

I think I'll duck now... :)
-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}, {http://crash.ihug.co.nz/~brianc/}
For a dynamic signature like this, {http://ue.cjb.net/dynasig/}
----
There's too much blood in my caffeine system.


</x-flowed>
From ???@??? Wed Dec 26 10:28:40 2001
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <0FC88C88-F708-11D5-A23F-00039340BD8A@gnelson.demon.co.uk> <5.1.0.14.0.20011225203419.076edd80@pop.ihug.co.nz>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Tue, 25 Dec 2001 21:10:29 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE34zfJLvf3B4eZ3lle00008546@hotmail.com>
X-OriginalArrivalTime: 25 Dec 2001 21:05:09.0076 (UTC) FILETIME=[D5D60940:01C18D87]
Sender: owner-z-machine@gmd.de
Precedence: bulk


Right, I'd like to point out that I do not believe putting Blorb into
the spec as a requirement is going to make people implement it.

Once the game is running, there is no way for it to tell whether or not
I do, in fact, support Blorb. The only way to tell if an interpreter
supports
Blorb is to hand it a Blorb file and see what it does with it.

If I couldn't be bothered to implement blorb because it's a good idea
and useful and the best thing since sliced bread, I certainly wouldn't
implement it just so that I could put 'Z-Spec 1.1' in my terp description.

Instead, I would most likely support everything that the game needs to care
about once it's actually running (in other words, everything except Blorb),
tell the game via that header that I do support 1.1 because now that the
game's running I might as well, and put 'Z-Spec 1.1 except Blorb' in
the description of my terp.

I do think that Blorb should be mentioned in the spec, and indeed authors
should be encouraged to support it. However, I believe that requiring it
will not actually make much difference in how many interpreters actually
support it. I not only don't like the idea, for reasons I have previously
expressed, I also don't think it's worth it.

I would also like to point out that if the Blorb specification
had as one of its rules that the initial byte had to be a 9, simply
declaring that a Blorb file is version 9 of the Z-machine format would
horrify me even more than just requiring support, and I would not in
fact suddenly change my mind and say 'Oh, well that's alright then.
Forget I spoke.'

--
Fillmore


From ???@??? Sun Jan 06 00:36:05 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 3 Jan 2002 16:22:12 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com>
X-OriginalArrivalTime: 03 Jan 2002 16:15:50.0929 (UTC) FILETIME=[E94AC010:01C19471]
Sender: owner-z-machine@gmd.de
Precedence: bulk


In my continuing attempt to implement a Z-Machine emulator, I've
noticed a few things in the current spec that seemed quite odd,
and promptly forgotten about them. I've also noticed some things in
the proposal that I wasn't sure about, but kind of forgot to mention
due to the whole 'I hate the way it wants sound to work' thing.
So, I had a read through both again today to see if I could remember
what I noticed, and came up with the following, which is probably not
everything I noticed the first time.

First, stuff I noticed in the current z-spec.

In Flags 2, the 'game wants to use colours' bit is the only one the
interpreter doesn't reset if it can't handle it. Why?

The specification appears to often, but not always, use the word 'pixels'
when referring to z6 units. Should this perhaps be changed, or have
I missed something?

Inform uses bit 1 of Flags 2 to decide whether to display score/turns or
hours:mins. I wouldn't have thought this should be allowed, but since it
quite obviously has been, shouldn't it be mentioned in the spec somewhere?
It's somewhat similar to the Tandy flag for version 3.

In section 3.8, the table showing the summary of the ZSCII rules says that
253 (double-click) is v6 only, but section 3.8.6 implies that of 252 (menu
click), 253 (mouse double-click) and 254 (mouse single click), 252 is the
only one not available in z5. The remarks section also says the Beyond
Zork (a z5 game) lists the double-click code in its terminating character
table. I assume this is a misprint?

Also, 3.8.6 recommends that an interpreter should only send code 254,
whether
a mouse is clicked once or twice. I assume there's a good reason for this.
What is it?



And now, stuff I noticed in the new z-spec proposal.

> The new flags are placed in a new word, rather than in Flags 2, to
minimize
> potential compatibility problems.

Like what? We've got practically a whole byte of flags left over from Flags
2,
what's wrong with using it?

> To prevent future compatibility problems,
> all reserved bits in the Flags 3 word MUST be cleared by the interpreter.

I'm not sure what this means. What is meant by 'reserved bits', and why must
they be cleared?

Why are the flags used in Flags 3 numbers 0, 1, 8, 9 and 10? Why the huge
gap?

And now, the flags in Flags 3:

> 0: All text style combinations available?

> An interpreter sets or clears this bit to indicate whether
> it can provide all the text styles it supports in all
> combinations.

I'm not sure this is, uh, worth the effort. I can see the point,
and I'm certainly not saying it *isn't* worth it, I'm just not sure.

> 1: Multiple colours available?

> This bit should be 1 if the interpreter can display multiple
> text colours on screen at one time, and should be 0 if
> changing the text colour changes all text on screen.

This is fine, I think it's a good idea, except that according to
the table, it's for version 5 and above. In the current spec,
version 5 games are required to show multiple colours if they
can show colours. Shouldn't this be just a z6 flag?

> When encountered in Z-machine text, ZSCII characters 768-1023 are "Unicode
> escapes", which indicate that Unicode data follows.  The number of Unicode
> codepoints to follow is given by the ZSCII code minus 767.

I've nothing against this at all, I'm just curious as to why you skip
characters
255-767. It does position the last Unicode escape at the last ZSCII code,
but
why, exactly, is this a better idea that just picking up where the already
existing
codes leave off?

And that's it. Everything I could think of to ask about. Hope it doesn't
cause
too many horrible problems or anything.

--
Fillmore


From ???@??? Sun Jan 06 00:36:15 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@gmd.de
Date: Thu, 3 Jan 2002 11:56:28 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C3446EC.21047.48304AD@localhost>
In-reply-to: <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@gmd.de
Precedence: bulk


Fillmore sent a message across the ether on 3 Jan 2002 (16:22) stating:

> > To prevent future compatibility problems,
> > all reserved bits in the Flags 3 word MUST be cleared by the 
interpreter.
> 
> I'm not sure what this means. What is meant by 'reserved bits', and 
why must
> they be cleared?

All the bits in flags 3 that haven't been defined should be cleared.  
This would be useful if more flags were defined later.  The interpreter 
would already claim that it doesn't support this new feature (because it 
clears the 'reserved bits').  No extra work for interpreter authors to 
just say 'I don't do that.'
 
> > 0: All text style combinations available?
> 
> > An interpreter sets or clears this bit to indicate whether
> > it can provide all the text styles it supports in all
> > combinations.
 
> I'm not sure this is, uh, worth the effort. I can see the point,
> and I'm certainly not saying it *isn't* worth it, I'm just not sure.

As the author of V6Lib, I've gotten a good number of requests for a way 
to do this.  I see it as extremely useful to a game author.  Knowing you 
can or can not rely on all combinations allows you to change the colour 
and set bold if you can't rely on italics and bold, but you need to make 
sure it's distinct from just bold.
 
> > 1: Multiple colours available?
> 
> > This bit should be 1 if the interpreter can display multiple
> > text colours on screen at one time, and should be 0 if
> > changing the text colour changes all text on screen.
> 
> This is fine, I think it's a good idea, except that according to
> the table, it's for version 5 and above. In the current spec,
> version 5 games are required to show multiple colours if they
> can show colours. Shouldn't this be just a z6 flag?

I think you're right.  I think only the V6 Amiga interpreters have this 
issue.

Jay

-- 

Jason C Penney (jpenney@jczorkmid.net) Xarton Dragon <UDIC>
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Sun Jan 06 00:36:20 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <00ba01c1947e$fe9d5b00$3a0786d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 3 Jan 2002 17:48:18 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> First, stuff I noticed in the current z-spec.
>
> In Flags 2, the 'game wants to use colours' bit is the only one the
> interpreter doesn't reset if it can't handle it. Why?

Don't know. It appears to be the way Infocom originally designed it. Colour
availability can be checked using bit 0 of Flags 1. Weird, but that's just
the way it is.

>
> The specification appears to often, but not always, use the word 'pixels'
> when referring to z6 units. Should this perhaps be changed, or have
> I missed something?

It should be units throughout. Probably just an oversight.

>
> Inform uses bit 1 of Flags 2 to decide whether to display score/turns or
> hours:mins. I wouldn't have thought this should be allowed, but since it
> quite obviously has been, shouldn't it be mentioned in the spec somewhere?
> It's somewhat similar to the Tandy flag for version 3.

It was a feature of the Z-machine - in Version 3 and earlier, the status
line is displayed by the interpreter, not the game - changing that bit
changes the way the interpreter draws the status line.

In Versions 4 and 5, the bit is unused, so Inform carries on using it to
indicate mode, but it now reads it in DrawStatusLine().

In Version 6, the bit is used for something else. Unfortunately, Inform
still carries on using it. This can be worked around by not using the
Statusline directive, and making sure your DrawStatusLine doesn't read it,
but it should be fixed.

> In section 3.8, the table showing the summary of the ZSCII rules says that
> 253 (double-click) is v6 only, but section 3.8.6 implies that of 252 (menu
> click), 253 (mouse double-click) and 254 (mouse single click), 252 is the
> only one not available in z5. The remarks section also says the Beyond
> Zork (a z5 game) lists the double-click code in its terminating character
> table. I assume this is a misprint?

Hmmm. Beyond Zork does include 253 in its terminating table, and recognises
it as a click. Only the V6 games distinguish between 254 and 253 - they need
a 253 to select an entry in the hints menus.

Section 3.8.6 does seem to imply that 253 is a V5 feature. The final
sentence should be changed to "In Version 5" rather than "In Versions 5 and
later", I think.

I suggest that 253 should not be marked as V6 only, but just be recommended
as being avoided in V5. This is because the only Infocom V5 mouse game
treated 253 and 254 equally, and we're not sure what various interpreters
supported. In V6, the Infocom game files REQUIRE 253 to work correctly, so
we can rely on interpreters to implement it.

Zip 2000 only generates the 253 code in Version 6, for what it's worth.

>
> Also, 3.8.6 recommends that an interpreter should only send code 254,
> whether
> a mouse is clicked once or twice. I assume there's a good reason for this.
> What is it?

Oops. See above - I think that should be for Version 5 only.

In V6, double-clicks should send a 254 (for the first click) followed by a
253 on
the second click. In V5, we're recommending that a double-click comes
through as two 254s.

> And now, stuff I noticed in the new z-spec proposal.
>
> > The new flags are placed in a new word, rather than in Flags 2, to
> minimize
> > potential compatibility problems.
>
> Like what? We've got practically a whole byte of flags left over from
Flags
> 2,
> what's wrong with using it?

We can't be absolutely sure what Infocom intended with those bits, and
current interpreters won't be clearing them, so they're no use for
"interpreter clears" type bits.

> > To prevent future compatibility problems,
> > all reserved bits in the Flags 3 word MUST be cleared by the
interpreter.
>
> I'm not sure what this means. What is meant by 'reserved bits', and why
must
> they be cleared?

See above - if they're not cleared now, they won't be any use in the future
for "interpreter clears" operation.

The "reserved bits" are all the other bits in Flags 3 that don't yet have a
meaning.

> Why are the flags used in Flags 3 numbers 0, 1, 8, 9 and 10? Why the huge
> gap?

It's a split between the "interpreter supports" and "game wants, interpreter
clears" bits.

> And now, the flags in Flags 3:
>
> > 0: All text style combinations available?
>
> I'm not sure this is, uh, worth the effort. I can see the point,
> and I'm certainly not saying it *isn't* worth it, I'm just not sure.

Apparently lots of authors want it, according to Mr Penney. It would allow
them to indicate stuff in a different way, if they absolutely have to
distinguish something, and would prefer to do it, say, in boldface
fixed-pitch, but are prepared to try something else if that's not available.

>
> > 1: Multiple colours available?
>
> This is fine, I think it's a good idea, except that according to
> the table, it's for version 5 and above. In the current spec,
> version 5 games are required to show multiple colours if they
> can show colours. Shouldn't this be just a z6 flag?

I was doubtful about this bit altogether, as I would view any interpreter
only supporting two on-screen colours as defective, but if it's going to be
there, then logically V5 interpreters could just as well have the same
problem as V6 ones.

> I've nothing against this at all, I'm just curious as to why you skip
> characters
> 255-767. It does position the last Unicode escape at the last ZSCII code,
> but
> why, exactly, is this a better idea that just picking up where the already
> existing
> codes leave off?

The vague idea was that you would leave a contiguous block of "real"
characters from 0-767, and higher codes being these "virtual" characters for
use in strings. It depends what we think might go in the extra characters.
Any future extensions could be done the same way - real characters at the
bottom, virtual characters at the top.

Hope this helps,

Kevin
-----



From ???@??? Sun Jan 06 00:36:25 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.13.161]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Thu, 03 Jan 2002 16:27:28 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F109p3eEHJtfob7bOsP00015cfc@hotmail.com>
X-OriginalArrivalTime: 03 Jan 2002 21:27:29.0073 (UTC) FILETIME=[72411A10:01C1949D]
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>
>From: "Fillmore" <Noslwop@hotmail.com>
>To: "z-machine mailing list" <z-machine@gmd.de>
>Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
>Date: Thu, 3 Jan 2002 16:22:12 -0000
>
>The specification appears to often, but not always, use the word 'pixels'
>when referring to z6 units. Should this perhaps be changed, or have
>I missed something?


IIRC, the spec sometimes calls these units "Z-Pixels", and so is probably  
trying to convey that.

>
>And now, the flags in Flags 3:
>
> > 0: All text style combinations available?
>
> > An interpreter sets or clears this bit to indicate whether
> > it can provide all the text styles it supports in all
> > combinations.
>
>I'm not sure this is, uh, worth the effort. I can see the point,
>and I'm certainly not saying it *isn't* worth it, I'm just not sure.

I'm not sure this is a very useful metric myself; I'd imagine that something 
like 99% of interpreters would answer "no", and that games would respond by 
not trying to mix styles, when, as it turns out, there's *one* pair of text 
attributes it can't mix.


>
> > 1: Multiple colours available?
>
> > This bit should be 1 if the interpreter can display multiple
> > text colours on screen at one time, and should be 0 if
> > changing the text colour changes all text on screen.
>
>This is fine, I think it's a good idea, except that according to
>the table, it's for version 5 and above. In the current spec,
>version 5 games are required to show multiple colours if they
>can show colours. Shouldn't this be just a z6 flag?
>

Wouldn't it be simpler to just give the finger to the amiga color behavior 
and dictate that spec 1.1 compliant terps should show Z6 text colors the 
same way they show text colors in v5?




_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


</x-flowed>
From ???@??? Sun Jan 06 00:36:32 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com> <00ba01c1947e$fe9d5b00$3a0786d9@oemcomputer>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Fri, 4 Jan 2002 01:28:39 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE24MwVN7miR9Odutox0000ce36@hotmail.com>
X-OriginalArrivalTime: 04 Jan 2002 01:22:16.0038 (UTC) FILETIME=[3EBD6060:01C194BE]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: "z-machine mailing list" <z-machine@gmd.de>
Sent: Thursday, January 03, 2002 5:48 PM
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt


> > First, stuff I noticed in the current z-spec.
> >
> > In Flags 2, the 'game wants to use colours' bit is the only one the
> > interpreter doesn't reset if it can't handle it. Why?
>
> Don't know. It appears to be the way Infocom originally designed it.
Colour
> availability can be checked using bit 0 of Flags 1. Weird, but that's just
> the way it is.

Would it affect any games if this was changed? It just seems like a really
odd choice.

> > Inform uses bit 1 of Flags 2 to decide whether to display score/turns or
> > hours:mins. I wouldn't have thought this should be allowed, but since it
> > quite obviously has been, shouldn't it be mentioned in the spec
somewhere?
> > It's somewhat similar to the Tandy flag for version 3.
>
> It was a feature of the Z-machine - in Version 3 and earlier, the status
> line is displayed by the interpreter, not the game - changing that bit
> changes the way the interpreter draws the status line.
>
> In Versions 4 and 5, the bit is unused, so Inform carries on using it to
> indicate mode, but it now reads it in DrawStatusLine().
>
> In Version 6, the bit is used for something else. Unfortunately, Inform
> still carries on using it. This can be worked around by not using the
> Statusline directive, and making sure your DrawStatusLine doesn't read it,
> but it should be fixed.

Yeah, I realised what was going on, I just think it should be mentioned.
I had assumed that all bits not in use should be set to zero, which resulted
in Inform games not displaying the time status line properly. I do think
that Inform probably shouldn't be setting this bit, but as it is, I believe
a mention should be made somewhere in the spec, probably in Appendix B.

> > And now, stuff I noticed in the new z-spec proposal.
> >
> > > The new flags are placed in a new word, rather than in Flags 2, to
> > minimize
> > > potential compatibility problems.
> >
> > Like what? We've got practically a whole byte of flags left over from
> Flags
> > 2,
> > what's wrong with using it?
>
> We can't be absolutely sure what Infocom intended with those bits, and
> current interpreters won't be clearing them, so they're no use for
> "interpreter clears" type bits.

It appears to me that Infocom's DOS terp did clear bits not in use, but
obviously Inform has made that impossible. Fair enough, then.

> > Why are the flags used in Flags 3 numbers 0, 1, 8, 9 and 10? Why the
huge
> > gap?
>
> It's a split between the "interpreter supports" and "game wants,
interpreter
> clears" bits.

Oh, so it is. Silly me.

> > And now, the flags in Flags 3:
> > > 1: Multiple colours available?
> >
> > This is fine, I think it's a good idea, except that according to
> > the table, it's for version 5 and above. In the current spec,
> > version 5 games are required to show multiple colours if they
> > can show colours. Shouldn't this be just a z6 flag?
>
> I was doubtful about this bit altogether, as I would view any interpreter
> only supporting two on-screen colours as defective, but if it's going to
be
> there, then logically V5 interpreters could just as well have the same
> problem as V6 ones.

Well, no. I believe the problem was due to something about the Amiga screen
model only being able to one colour for foreground and background text due
to the pictures in z6 or something. Anyway, the problem currently only
exists
in z6, so why enable z5 terps to legally have it as well? z5 games generally
don't even need colour.

> > I've nothing against this at all, I'm just curious as to why you skip
> > characters
> > 255-767. It does position the last Unicode escape at the last ZSCII
code,
> > but
> > why, exactly, is this a better idea that just picking up where the
already
> > existing
> > codes leave off?
>
> The vague idea was that you would leave a contiguous block of "real"
> characters from 0-767, and higher codes being these "virtual" characters
for
> use in strings. It depends what we think might go in the extra characters.
> Any future extensions could be done the same way - real characters at the
> bottom, virtual characters at the top.

Oh. Hrm. Fair enough.

--
Fillmore


From ???@??? Sun Jan 06 00:36:34 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: timpart@perdix.demon.co.uk (Timothy Partridge)
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt (fwd)
In-Reply-To: <20020104.003014.48@perdix.demon.co.uk>
Date: Fri, 04 Jan 2002 01:46:28 GMT
Message-ID: <20020104.014628.35@perdix.demon.co.uk>
Organization: Timothy Partridge
X-Mailer: TTFN version 0.43 (Acorn RISC OS)
X-Posting-Agent: RISC OS Newsbase 0.59c
Sender: owner-z-machine@gmd.de
Precedence: bulk


Kevin recently said:

> > I've nothing against this at all, I'm just curious as to why you skip
> > characters
> > 255-767. It does position the last Unicode escape at the last ZSCII code,
> > but
> > why, exactly, is this a better idea that just picking up where the already
> > existing
> > codes leave off?
>
> The vague idea was that you would leave a contiguous block of "real"
> characters from 0-767, and higher codes being these "virtual" characters for
> use in strings. It depends what we think might go in the extra characters.
> Any future extensions could be done the same way - real characters at the
> bottom, virtual characters at the top.

I was wondering why you wanted to encode the length of the Unicode string as
well, rather than having a single "shift into Unicode character" (and a
shift out of Unicode character when inside).

Also is it worth pointing out that some of the Unicode chararacters may be
in the ASCII range $0020 etc. Many writing systems use the space to separate
words and popping out of Unicode mode and back into it again to do a space
between words or some punctuation would be an enormous overhead.

I would live to suggest the following addition to 3.8.5.4.1 which currently
says "The interpreter is required to be able to print representations of
every defined Unicode character under <B>$0100</B> (i.e. of every defined
ISO 8859-1 Latin1 character).  If no suitable letter forms are available,
textual equivalents may be used (such as "ss" in place of German sharp "s")."

I think it would help to add $2018 through $201F. These are the left and
right quotation marks in various styles and could be defaulted to ' ' , ' " "
,, " by interpreters that don't possess the real thing. Then programs could
use these explicit characters as needed which would avoid ambiguity
associtated with $27 etc. I'd also like to suggest mandating support for
$2028 (line separator) and $2029 (paragraph separator). These can default to
a single or double new line for those that don't have them. This paves the
way for future, more extensive, support of Unicode. (The bi-directional
algorithm considers paragraphs at a time so supporting paragraph separator
helps!)

Part of proposed amendment causes me concern:
"The Z-machine is not expected to handle complex Unicode formatting like
combining characters, bidirectional formatting and unusual line-wrapping
rules - it remains firmly based in the world of left-to-right text with space
breaks between words - every character is viewed as separate spacing glyph.

"All output is in presentation order, from left to right. To handle languages
like Arabic or Hebrew, text would have to be output "visually", with manual
line breaks (possibly via an in-game formatting engine)."

If in the future we want to add complex Unicode support (probably by calling
an operating system module to assist in rendering) we would want the text to
be in logical order, not presentation order. Encouraging games to do output
in presentation order will them make them break in the future. 

Since we don't have any games like this yet (unless anyone knows
differently) I'd rather defer the question. Perhaps something on the lines
of

"The Z-machine is not expected to handle complex Unicode formatting like
combining characters, character reordering, bidirectional formatting and
unusual line-wrapping rules - it currently remains firmly based in the world
of left-to-right text with space breaks between words - every character is
viewed as separate spacing glyph.

"Games should always print text in logical order for processing by the
Z-machine. An advanced interpreter may wish to support more complex scripts
by calling an appropriate operating system rendering routine. Interpreters
that do not support complex scripts should be wary of falsely claiming to do
so when queried via check_unicode. Simply having the character available for
printing is not sufficient, the character's behaviour should be supported
too. (For example $590 to $7BF need to be rendered right to left.)"


How would people feel about adding a new opcode to read_unicode? This would
put "raw" Unicode values into an array of words. No translation to lower
case. (This is so that Turkish games can handle 'I' properly.) And for the
time being parse-buffer should always be zero. (That is another little
nightmare. Languages like Ethiopic have one character per syllable which
needs hundreds of characters. Translating into a ZSCII form suitable for
keeping in the dictionary is complex.) We could also change the behaviour
compared to read, so that if word 1 of the input array is non zero then the
existing characters in it would be re-displayed. Perhaps that would make
Messers Plotkin and Jokisch happy - they could use unicode_read instead of
read in their code.

   Tim 

-- 
Tim Partridge. Any opinions expressed are mine only and not those of my employer


From ???@??? Sun Jan 06 00:37:05 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-eGroups-Return: z-machine-owner@mail.gmd.de
X-Yahoo-MsgId: <mta607.mail.yahoo.com.1010135179.58718.0030>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <001501c194fe$6b7f6680$f10c86d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com> <00ba01c1947e$fe9d5b00$3a0786d9@oemcomputer> <OE24MwVN7miR9Odutox0000ce36@hotmail.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Fri, 4 Jan 2002 08:45:39 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> > Don't know. It appears to be the way Infocom originally designed it.
> Colour
> > availability can be checked using bit 0 of Flags 1. Weird, but that's
just
> > the way it is.
>
> Would it affect any games if this was changed? It just seems like a really
> odd choice.

I don't think it would be helpful to change it - current behaviour is
adequate, and we don't want to start confusing matters.

> >
> > In Version 6, the bit is used for something else. Unfortunately, Inform
> > still carries on using it. This can be worked around by not using the
> > Statusline directive, and making sure your DrawStatusLine doesn't read
it,
> > but it should be fixed.
>
> Yeah, I realised what was going on, I just think it should be mentioned.
> I had assumed that all bits not in use should be set to zero, which
resulted
> in Inform games not displaying the time status line properly.

I've always read the spec as telling us not to change any header bits unless
marked with "Int" in the header table. Oh, I see what you mean though - that
bit is marked "Int". Well, Zip 2000 doesn't touch bits that don't apply to
the current version, so bit 1 of Flags 1 remains untouched for all other
than V6.

I'll try to come up with some clarification.

> > We can't be absolutely sure what Infocom intended with those bits, and
> > current interpreters won't be clearing them, so they're no use for
> > "interpreter clears" type bits.
>
> It appears to me that Infocom's DOS terp did clear bits not in use, but
> obviously Inform has made that impossible. Fair enough, then.

Really? Which bits? Which terp?

> > > > 1: Multiple colours available?
> > >
> > I was doubtful about this bit altogether, as I would view any
interpreter
> > only supporting two on-screen colours as defective, but if it's going to
> be
> > there, then logically V5 interpreters could just as well have the same
> > problem as V6 ones.
>
> Well, no. I believe the problem was due to something about the Amiga
screen
> model only being able to one colour for foreground and background text due
> to the pictures in z6 or something. Anyway, the problem currently only
> exists
> in z6, so why enable z5 terps to legally have it as well? z5 games
generally
> don't even need colour.

I'd by happy to go with Ross and say that 1.1 terps have to do colour
properly or not at all.

I'm sure I remember Photopia having problems unless the whole screen changed
colour on some terps though.

Kevin
-----




From ???@??? Sun Jan 06 00:37:07 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <001601c19500$1a08af80$f10c86d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@gmd.de>
References: <20020104.014628.35@perdix.demon.co.uk>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt (fwd)
Date: Fri, 4 Jan 2002 09:13:38 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


> I was wondering why you wanted to encode the length of the Unicode string
as
> well, rather than having a single "shift into Unicode character" (and a
> shift out of Unicode character when inside).

It took me a while to come up with this scheme. It's hard to squeeze a
"shift to Unicode" into a small space. One way would be to call ZSCII 255
the shift, and place that in the alphabet, making it only 1 or 2
Z-characters for the shift. But then you have to have the "shift out", which
takes 16-bits (or 3 Z-characters). I didn't like this as it took up an
alphabet slot, potentially meant handling the shift in more than one place,
and is no more space efficient. By using characters outside the 0-255 range,
we're firmly in to the area of special characters that can only be encoded
with a 5,6,w,x sequence, so we only need to put the check in one place. And
there's then plenty of room to put the length in that sequence.

>
> Also is it worth pointing out that some of the Unicode chararacters may be
> in the ASCII range $0020 etc. Many writing systems use the space to
separate
> words and popping out of Unicode mode and back into it again to do a space
> between words or some punctuation would be an enormous overhead.

I kind of took that as obvious :)

> I would live to suggest the following addition to 3.8.5.4.1 which
currently
> says "The interpreter is required to be able to print representations of
> every defined Unicode character under <B>$0100</B> (i.e. of every defined
> ISO 8859-1 Latin1 character).  If no suitable letter forms are available,
> textual equivalents may be used (such as "ss" in place of German sharp
"s")."
>
> I think it would help to add $2018 through $201F. These are the left and
> right quotation marks in various styles and could be defaulted to ' ' , '
" "
> ,, " by interpreters that don't possess the real thing. Then programs
could
> use these explicit characters as needed which would avoid ambiguity
> associtated with $27 etc. I'd also like to suggest mandating support for
> $2028 (line separator) and $2029 (paragraph separator). These can default
to
> a single or double new line for those that don't have them. This paves the
> way for future, more extensive, support of Unicode. (The bi-directional
> algorithm considers paragraphs at a time so supporting paragraph separator
> helps!)

I did think of that, but that would break a LOT of backwards compatibility -
anything using those forms just wouldn't work on old terps, so people would
be reluctant to use it. That's why I tried to clarify the behaviour of $27
et al.

But on the other hand, they could make use of them if they detect they're
there - they could do run-time detection in Inform thus:

        Lowstring 0 "'";
        if (standard_interpreter >= $0100)
        {
            @check_unicode $2018 -> x;
            if (x & 1) Lowstring 0 "@{2018}";
        }

So it's probably a good idea to recommend that they're available.

> Part of proposed amendment causes me concern:
> "The Z-machine is not expected to handle complex Unicode formatting like
> combining characters, bidirectional formatting and unusual line-wrapping
> rules - it remains firmly based in the world of left-to-right text with
space
> breaks between words - every character is viewed as separate spacing
glyph.
>
> "All output is in presentation order, from left to right. To handle
languages
> like Arabic or Hebrew, text would have to be output "visually", with
manual
> line breaks (possibly via an in-game formatting engine)."
>
> If in the future we want to add complex Unicode support (probably by
calling
> an operating system module to assist in rendering) we would want the text
to
> be in logical order, not presentation order. Encouraging games to do
output
> in presentation order will them make them break in the future.

I was very doubtful that (at least in V6) it was feasible for the Z-machine
to handle anything other than LTR text, due to the way the architecture is
put together - all the intricacies of @read_cursor, line callbacks,
@set_margins. The only way to get such stuff to work at the minute would be
to output it visually.
In V5 or Glulx, you'd have more luck, but I don't want to specify stuff that
won't work in V6.

If we could figure out a bidi formatting extension, it would be invoked by a
new header flag, I'm sure, so stuff could be written either using logical or
presentation order - it wouldn't break backwards compatibility.

> How would people feel about adding a new opcode to read_unicode? This
would
> put "raw" Unicode values into an array of words. No translation to lower
> case. (This is so that Turkish games can handle 'I' properly.) And for the
> time being parse-buffer should always be zero. (That is another little
> nightmare. Languages like Ethiopic have one character per syllable which
> needs hundreds of characters. Translating into a ZSCII form suitable for
> keeping in the dictionary is complex.) We could also change the behaviour
> compared to read, so that if word 1 of the input array is non zero then
the
> existing characters in it would be re-displayed. Perhaps that would make
> Messers Plotkin and Jokisch happy - they could use unicode_read instead of
> read in their code.

I considered that, but I was a bit wary of overstretching. It's a fairly
large architectural extension, as input goes from being ZSCII to Unicode -
it ends up affecting all sort of little things like recording and playback.

Kevin
-----



From ???@??? Sun Jan 06 00:37:18 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com> <00ba01c1947e$fe9d5b00$3a0786d9@oemcomputer> <OE24MwVN7miR9Odutox0000ce36@hotmail.com> <001501c194fe$6b7f6680$f10c86d9@oemcomputer>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Fri, 4 Jan 2002 15:09:16 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE74IOPDrBSazgvkLru0000d406@hotmail.com>
X-OriginalArrivalTime: 04 Jan 2002 15:02:52.0548 (UTC) FILETIME=[E1FC9440:01C19530]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: "z-machine mailing list" <z-machine@gmd.de>
Sent: Friday, January 04, 2002 8:45 AM
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt


> > > Don't know. It appears to be the way Infocom originally designed it.
> > Colour
> > > availability can be checked using bit 0 of Flags 1. Weird, but that's
> just
> > > the way it is.
> >
> > Would it affect any games if this was changed? It just seems like a
really
> > odd choice.
>
> I don't think it would be helpful to change it - current behaviour is
> adequate, and we don't want to start confusing matters.

Fair enough.

> > >
> > > In Version 6, the bit is used for something else. Unfortunately,
Inform
> > > still carries on using it. This can be worked around by not using the
> > > Statusline directive, and making sure your DrawStatusLine doesn't read
> it,
> > > but it should be fixed.
> >
> > Yeah, I realised what was going on, I just think it should be mentioned.
> > I had assumed that all bits not in use should be set to zero, which
> resulted
> > in Inform games not displaying the time status line properly.
>
> I've always read the spec as telling us not to change any header bits
unless
> marked with "Int" in the header table. Oh, I see what you mean though -
that
> bit is marked "Int". Well, Zip 2000 doesn't touch bits that don't apply to
> the current version, so bit 1 of Flags 1 remains untouched for all other
> than V6.
>
> I'll try to come up with some clarification.
>
> > > We can't be absolutely sure what Infocom intended with those bits, and
> > > current interpreters won't be clearing them, so they're no use for
> > > "interpreter clears" type bits.
> >
> > It appears to me that Infocom's DOS terp did clear bits not in use, but
> > obviously Inform has made that impossible. Fair enough, then.
>
> Really? Which bits? Which terp?

I set all the bits in flag 1 in a test game, and ran it through Infocom's
DOS interpreter for Beyond Zork. It promptly crashed, complaining of
'Byte swapped game file'. So, I tried it again with all the bits preset
except the colour available bit, and it worked. It also unset all the bits
marked in the spec as meaning nothing in z5.

>
> > > > > 1: Multiple colours available?
> > > >
> > > I was doubtful about this bit altogether, as I would view any
> interpreter
> > > only supporting two on-screen colours as defective, but if it's going
to
> > be
> > > there, then logically V5 interpreters could just as well have the same
> > > problem as V6 ones.
> >
> > Well, no. I believe the problem was due to something about the Amiga
> screen
> > model only being able to one colour for foreground and background text
due
> > to the pictures in z6 or something. Anyway, the problem currently only
> > exists
> > in z6, so why enable z5 terps to legally have it as well? z5 games
> generally
> > don't even need colour.
>
> I'd by happy to go with Ross and say that 1.1 terps have to do colour
> properly or not at all.

Yeah, but I think this would break the Infocom z6 Amiga games, which
isn't a good idea.
>
> I'm sure I remember Photopia having problems unless the whole screen
changed
> colour on some terps though.

Hrm. I don't think so. The only problems I remember Photopia having were due
to
the background colour not reaching all the way to the end of the line on
WinFrotz.

--
Fillmore




From ???@??? Sun Jan 06 00:37:23 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 04 Jan 2002 16:01:51 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@gmd.de
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Message-ID: <7e6b9ff34a.kbracey@kbracey.cam.pace.co.uk>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com> <OE24MwVN7miR9Odutox0000ce36@hotmail.com> 
 <OE74IOPDrBSazgvkLru0000d406@hotmail.com>
In-Reply-To: <OE74IOPDrBSazgvkLru0000d406@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@gmd.de
Precedence: bulk


In message <OE74IOPDrBSazgvkLru0000d406@hotmail.com>
          "Fillmore" <Noslwop@hotmail.com> wrote:

> > > It appears to me that Infocom's DOS terp did clear bits not in use, but
> > > obviously Inform has made that impossible. Fair enough, then.
> >
> > Really? Which bits? Which terp?
> 
> I set all the bits in flag 1 in a test game, and ran it through Infocom's
> DOS interpreter for Beyond Zork. It promptly crashed, complaining of
> 'Byte swapped game file'. So, I tried it again with all the bits preset
> except the colour available bit, and it worked. It also unset all the bits
> marked in the spec as meaning nothing in z5.

Hmm, what about Flags 2? Anyway, it's never been specified what interpreters
should do with the other bits, so we're stuck with the backwards
compatibility problem - and from what you've just said, Infocom's terps
obviously don't like having extra bits set.

> >
> > I'd by happy to go with Ross and say that 1.1 terps have to do colour
> > properly or not at all.
> 
> Yeah, but I think this would break the Infocom z6 Amiga games, which
> isn't a good idea.

That would be the Amiga versions of the games, would it? Do they actually
rely on that behaviour? If so, they're different from the DOS versions.

Given the V6 mess, I'm happy if just the DOS game files work on a Standard
interpreter - the DOS versions are the newest for each game, and the Blorb
files I created go with them; I'm not aware of the DOS versions being
inferior in any respect. A terp that wants to run the Amiga files could
detect them specifically and behave differently.

> >
> > I'm sure I remember Photopia having problems unless the whole screen
> > changed colour on some terps though.
> 
> Hrm. I don't think so. The only problems I remember Photopia having were
> due to the background colour not reaching all the way to the end of the
> line on WinFrotz.

Maybe that was it.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Sun Jan 06 00:37:30 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com> <OE24MwVN7miR9Odutox0000ce36@hotmail.com> <OE74IOPDrBSazgvkLru0000d406@hotmail.com> <7e6b9ff34a.kbracey@kbracey.cam.pace.co.uk>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Fri, 4 Jan 2002 21:02:45 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE17XGV9QaX6txEl9in0000d593@hotmail.com>
X-OriginalArrivalTime: 04 Jan 2002 20:56:18.0440 (UTC) FILETIME=[41AEE880:01C19562]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin.bracey@pace.co.uk>
To: <z-machine@gmd.de>
Sent: Friday, January 04, 2002 4:01 PM
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt


> In message <OE74IOPDrBSazgvkLru0000d406@hotmail.com>
>           "Fillmore" <Noslwop@hotmail.com> wrote:
>
> > > > It appears to me that Infocom's DOS terp did clear bits not in use,
but
> > > > obviously Inform has made that impossible. Fair enough, then.
> > >
> > > Really? Which bits? Which terp?
> >
> > I set all the bits in flag 1 in a test game, and ran it through
Infocom's
> > DOS interpreter for Beyond Zork. It promptly crashed, complaining of
> > 'Byte swapped game file'. So, I tried it again with all the bits preset
> > except the colour available bit, and it worked. It also unset all the
bits
> > marked in the spec as meaning nothing in z5.
>
> Hmm, what about Flags 2? Anyway, it's never been specified what
interpreters
> should do with the other bits, so we're stuck with the backwards
> compatibility problem - and from what you've just said, Infocom's terps
> obviously don't like having extra bits set.

I would say that it should be illegal for games to set any bits in any flags
area that aren't marked in the spec to mean something, and any bits not
marked
in the spec to mean something should be set to 0 by the terp. This enables
future specifications to specify new meaning for the bits, and be certain
that
terps following old specifications will set it properly.

Of course, the fact that Inform sets one of the bits messes this up
slightly,
but we can make an exception for that one bit.

> > > I'd by happy to go with Ross and say that 1.1 terps have to do colour
> > > properly or not at all.
> >
> > Yeah, but I think this would break the Infocom z6 Amiga games, which
> > isn't a good idea.
>
> That would be the Amiga versions of the games, would it? Do they actually
> rely on that behaviour? If so, they're different from the DOS versions.

Yes, I believe they do. I mean, they must do, yes? The behaviour is
different
enough that if the games didn't work differently, playing them would look
horrible.

> Given the V6 mess, I'm happy if just the DOS game files work on a Standard
> interpreter - the DOS versions are the newest for each game, and the Blorb
> files I created go with them; I'm not aware of the DOS versions being
> inferior in any respect. A terp that wants to run the Amiga files could
> detect them specifically and behave differently.

I'm not happy with that, however. I don't mind, say, specifying that a terp
*must* make an exception for those Amiga files, but just letting it not be
backwards compatible with three or four Infocom games because it's too much
effort pretty much defeats the purpose of the spec, I think.

--
Fillmore


From ???@??? Sun Jan 06 00:37:47 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 4 Jan 2002 23:17:58 -0500
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@gmd.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <20020104.014628.35@perdix.demon.co.uk>
Message-Id: <332D31F0-0193-11D6-88BA-0050E4A0CE52@speakeasy.net>
X-Mailer: Apple Mail (2.475)
Sender: owner-z-machine@gmd.de
Precedence: bulk


<x-flowed>

On Thursday, January 3, 2002, at 08:46  PM, Timothy Partridge wrote:

> Part of proposed amendment causes me concern:
> "The Z-machine is not expected to handle complex Unicode formatting like
> combining characters, bidirectional formatting and unusual line-wrapping
> rules - it remains firmly based in the world of left-to-right text with 
> space
> breaks between words - every character is viewed as separate spacing 
> glyph.

> [snip]

> "Games should always print text in logical order for processing by the
> Z-machine. An advanced interpreter may wish to support more complex 
> scripts
> by calling an appropriate operating system rendering routine. 
> Interpreters
> that do not support complex scripts should be wary of falsely claiming 
> to do
> so when queried via check_unicode. Simply having the character 
> available for
> printing is not sufficient, the character's behaviour should be 
> supported
> too. (For example $590 to $7BF need to be rendered right to left.)"

I'd like to try to close this can of worms.  The Z-machine is 
left-to-right. The result of printing or checking characters which 
require special rendering should be formally undefined.  (IOW, you 
_can't_ do Hebrew or Arabic in accordance of the standard).

I might be convinced, with a bit of arm-twisting, to accept the wisdom 
of allowing those glyphs _provided_ they are bracketed with (no more 
than one level of) LRO and PDF, and all of those are allowed by 
check_unicode.  This is to potentially allow embedding of Hebrew or 
other right-to-left characters in a left-to-right game, e.g. if someone 
feels like printing a Hebrew word.  (the interpreter would not be 
required to DO anything with LRO and PDF -- it may simply print ALL 
glyphs as left to right and ignore LRO and PDF.  But using LRO and PDF 
gives a valid Unicode stream).  Bidirectional unicode formatting should 
be left for the 2.0 Standard.

For similar reasons I object to the paragraph and line separators.  The 
Z-machine just doesn't work that way.

Styled quotes I view as an unnecessary frill.

>
> How would people feel about adding a new opcode to read_unicode? This 
> would
> put "raw" Unicode values into an array of words. No translation to lower
> case. (This is so that Turkish games can handle 'I' properly.)

I really don't want to handle yet another input routine.  Certainly not 
general-purpose Unicode.  But there IS demonstrated demand for a 
case-preserving read, unfortunately.


</x-flowed>
From ???@??? Sun Jan 06 13:40:19 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <000601c195f9$2fec5fa0$a42b86d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com> <OE24MwVN7miR9Odutox0000ce36@hotmail.com> <OE74IOPDrBSazgvkLru0000d406@hotmail.com> <7e6b9ff34a.kbracey@kbracey.cam.pace.co.uk> <OE17XGV9QaX6txEl9in0000d593@hotmail.com>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Sat, 5 Jan 2002 14:56:38 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@gmd.de
Precedence: bulk


Fillmore wrote:

> I would say that it should be illegal for games to set any bits in any
flags
> area that aren't marked in the spec to mean something, and any bits not
> marked
> in the spec to mean something should be set to 0 by the terp. This enables
> future specifications to specify new meaning for the bits, and be certain
> that
> terps following old specifications will set it properly.

But it's a bit too late for Flags 1 and 2, as they've never specified how to
treat reserved flags. Flags 3 is strictly defined, so we will be able to use
that for extra stuff in future.

> > > > I'd by happy to go with Ross and say that 1.1 terps have to do
colour
> > > > properly or not at all.
> > >
> > > Yeah, but I think this would break the Infocom z6 Amiga games, which
> > > isn't a good idea.
> >
> > That would be the Amiga versions of the games, would it? Do they
actually
> > rely on that behaviour? If so, they're different from the DOS versions.
>
> Yes, I believe they do. I mean, they must do, yes? The behaviour is
> different
> enough that if the games didn't work differently, playing them would look
> horrible.

I'll have to check, but as far as I know the Infocom games don't NEED the
limited colour behaviour - they're just written in such a way that it
doesn't matter if you have the limited colour behaviour, as they don't
change colour in mid-text. The limitation was forced by the way some of the
terps worked (including the MCGA DOS one, I think), and the games were
prepared to cope with it.

What they would like - particularly Arthur - is the palette changing
behaviour for graphics, but that's a separate issue, and even some of
Infocom's own terps didn't do it (eg the EGA DOS one).

> I'm not happy with that, however. I don't mind, say, specifying that a
terp
> *must* make an exception for those Amiga files, but just letting it not be
> backwards compatible with three or four Infocom games because it's too
much
> effort pretty much defeats the purpose of the spec, I think.

But there are multiple versions of the files available, so just as it's not
necessary to support V1 or V2 because V3+ versions of those games exist, it
isn't really necessary to support the older Amiga versions of the V6 games.
Although, as I said above, I'm still not convinced you'd actually break
them.

Kevin
-----



From ???@??? Sun Jan 06 13:40:21 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "Fillmore" <Noslwop@hotmail.com>
To: "z-machine mailing list" <z-machine@gmd.de>
References: <026feceb4a.kbracey@kbracey.cam.pace.co.uk> <OE40W2ufyWOxbCJnEMz0000ca95@hotmail.com> <OE24MwVN7miR9Odutox0000ce36@hotmail.com> <OE74IOPDrBSazgvkLru0000d406@hotmail.com> <7e6b9ff34a.kbracey@kbracey.cam.pace.co.uk> <OE17XGV9QaX6txEl9in0000d593@hotmail.com> <000601c195f9$2fec5fa0$a42b86d9@oemcomputer>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Sat, 5 Jan 2002 18:04:55 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <OE57Yfxi0I8l3uXe16y0000ddcb@hotmail.com>
X-OriginalArrivalTime: 05 Jan 2002 17:58:28.0652 (UTC) FILETIME=[946836C0:01C19612]
Sender: owner-z-machine@gmd.de
Precedence: bulk


----- Original Message -----
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: "z-machine mailing list" <z-machine@gmd.de>
Sent: Saturday, January 05, 2002 2:56 PM
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt


> Fillmore wrote:
>
> > I would say that it should be illegal for games to set any bits in any
> flags
> > area that aren't marked in the spec to mean something, and any bits not
> > marked
> > in the spec to mean something should be set to 0 by the terp. This
enables
> > future specifications to specify new meaning for the bits, and be
certain
> > that
> > terps following old specifications will set it properly.
>
> But it's a bit too late for Flags 1 and 2, as they've never specified how
to
> treat reserved flags. Flags 3 is strictly defined, so we will be able to
use
> that for extra stuff in future.

Why is it too late? I don't see that it will break any existing games. We
may
be able to forget about setting the flags to 0, but I think we should
certainly
disallow games using the flags if it isn't specified in the spec that they
should use them.

> > > > > I'd by happy to go with Ross and say that 1.1 terps have to do
> colour
> > > > > properly or not at all.
> > > >
> > > > Yeah, but I think this would break the Infocom z6 Amiga games, which
> > > > isn't a good idea.
> > >
> > > That would be the Amiga versions of the games, would it? Do they
> actually
> > > rely on that behaviour? If so, they're different from the DOS
versions.
> >
> > Yes, I believe they do. I mean, they must do, yes? The behaviour is
> > different
> > enough that if the games didn't work differently, playing them would
look
> > horrible.
>
> I'll have to check, but as far as I know the Infocom games don't NEED the
> limited colour behaviour - they're just written in such a way that it
> doesn't matter if you have the limited colour behaviour, as they don't
> change colour in mid-text. The limitation was forced by the way some of
the
> terps worked (including the MCGA DOS one, I think), and the games were
> prepared to cope with it.

If that is the case then, fine, chuck the limited colour behaviour. If
changing
it doesn't break anything, it's not worth keeping the Amiga behaviour.

> What they would like - particularly Arthur - is the palette changing
> behaviour for graphics, but that's a separate issue, and even some of
> Infocom's own terps didn't do it (eg the EGA DOS one).
>
> > I'm not happy with that, however. I don't mind, say, specifying that a
> terp
> > *must* make an exception for those Amiga files, but just letting it not
be
> > backwards compatible with three or four Infocom games because it's too
> much
> > effort pretty much defeats the purpose of the spec, I think.
>
> But there are multiple versions of the files available, so just as it's
not
> necessary to support V1 or V2 because V3+ versions of those games exist,
it
> isn't really necessary to support the older Amiga versions of the V6
games.
> Although, as I said above, I'm still not convinced you'd actually break
> them.

Yes, but the v1 and v2 games aren't v3 games. The v6 Amiga games, however,
are v6 games, so I don't think the comparison is valid. Besides, it's
possible
to support *only* v1 and v2 games and still have a standard compliant terp.
If the Amiga games did break under terps that don't act like Amiga terps,
then
ignoring the Amiga games would leave some of the old Infocom games
completely
unplayable on all modern terps.

But, if it doesn't break them, I'm quite happy to forget about that
behaviour
completely.

--
Fillmore


From ???@??? Sat Feb 02 11:44:14 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-eGroups-Return: z-machine-owner@mail.gmd.de
X-Yahoo-MsgId: <mta598.mail.yahoo.com.1012230980.64132.0004>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@GMD.DE
Date: Mon, 28 Jan 2002 10:08:43 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C55232B.16862.27CB3BD@localhost>
In-reply-to: <OE17XGV9QaX6txEl9in0000d593@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Sorry... I've been away from things...

Fillmore sent a message across the ether on 4 Jan 2002 (21:02) stating:

Bits:
 
> I would say that it should be illegal for games to set any bits in any
> flags area that aren't marked in the spec to mean something, and any
> bits not marked in the spec to mean something should be set to 0 by
> the terp. This enables future specifications to specify new meaning
> for the bits, and be certain that terps following old specifications
> will set it properly.

I think stating that the interpreter should set these bits to 0 covers 
it.  If the spec+1 states 'bit X must be 0 in the game file' and then 
spec+2 states 'bit X should be set in the game file if the game wants 
bunky floobarg, the interpreter should clear it if it's not provided' 
then a compiler that compiles to spec+2 is now compiling game files that 
are no longer spec+1 compliant game files.


Amiga colour:

> > > > I'd by happy to go with Ross and say that 1.1 terps have to do
> > > > colour properly or not at all.
> > >
> > > Yeah, but I think this would break the Infocom z6 Amiga games,
> > > which isn't a good idea.
> >
> > That would be the Amiga versions of the games, would it? Do they
> > actually rely on that behaviour? If so, they're different from the
> > DOS versions.
> 
> Yes, I believe they do. I mean, they must do, yes? The behaviour is
> different enough that if the games didn't work differently, playing
> them would look horrible.

The Z-Code must be adaptive based on machine number, because you can use 
DOS Frotz to play Amiga/Mac/DOS z6 files in either Amiga or Dos mode.  I 
don't think DOS Frotz is doing all the work arounds on the fly (it does 
work around different image numbers between the Amiga and other files 
IIRC).

Jay

-- 

Jason C Penney (jpenney@jczorkmid.net) Xarton Dragon <UDIC>
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor



From ???@??? Tue Mar 19 00:22:29 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <00a301c1ce5b$0d767f60$3b3786d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@GMD.DE>
References: <3C94D5C1.1656.1D45EE1@localhost>
Subject: Re: [z-machine] Newline Interupt Routines
Date: Mon, 18 Mar 2002 08:58:16 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@GMD.DE
Precedence: bulk


> > As I recall from the original investigations, Infocom's various
> > interpreters were inconsistent. The standard wants terps to call the
> > routine before, except (as specified in 8.8.3.2.2.1) when it's
> > playing Zork Zero and claiming to be the DOS terp, when it should
> > call the routine after.
>
> I'm seeing this in the Dos Shogun interpreter as well though.

I think that it behaved differently on different platforms. Zork Zero itself
checks the platform header byte and takes different behaviour. Other games
aren't bothered by the distinction, and work with either.

> If it
> works on all modern terps the same way it isn't a big deal.  8.8.3.2.2.1
> is very precise:
>
> (1) move to the new line
> (2) put the cursor at the current left margin
> (3) call the interrupt routine (if it's time to do so)
>
> It would be nice if 8.8.3.2.2 was equally specific.  Am I right in
> thinking it would be:
> (1) call the interrupt routine (if it's time to do so)
> (2) move to the new line
> (3) put the cursor at the current left margin

I believe so. In both cases the "move to the new line" step potentially
involves scrolling the screen, of course.

There's the extra wrinkle that if the margins are changed and the cursor is
left outside them, the cursor gets put back to the left margin. This blurs
the distinction between the two cases sometimes if all you're doing is a
simple left-margin adjustment.

Kevin
-----



From ???@??? Tue Mar 19 00:22:30 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@GMD.DE
Date: Sun, 17 Mar 2002 17:43:29 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Newline Interupt Routines
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C94D5C1.1656.1D45EE1@localhost>
In-reply-to: <004001c1cdf2$e74ac020$3b3786d9@oemcomputer>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Kevin Bracey sent a message across the ether on 17 Mar 2002 (20:32) 
stating:

> > Frotz and Zip2000 execute the newline routine before moving the
> > cursor down to the next line (the newline).  Infocom's Dos terp
> > seems to do it AFTER. 8.8.3.2.2 doesn't clearly state if the cursor
> > is moved down before or after the interrupt routine is run.  It
> > probably should say one way or the other.
> 
> As I recall from the original investigations, Infocom's various
> interpreters were inconsistent. The standard wants terps to call the
> routine before, except (as specified in 8.8.3.2.2.1) when it's
> playing Zork Zero and claiming to be the DOS terp, when it should
> call the routine after.

I'm seeing this in the Dos Shogun interpreter as well though.  If it 
works on all modern terps the same way it isn't a big deal.  8.8.3.2.2.1 
is very precise:

(1) move to the new line 
(2) put the cursor at the current left margin 
(3) call the interrupt routine (if it's time to do so)

It would be nice if 8.8.3.2.2 was equally specific.  Am I right in 
thinking it would be:
(1) call the interrupt routine (if it's time to do so)
(2) move to the new line 
(3) put the cursor at the current left margin 

Jay

Jay

-- 

Jason C Penney (jpenney@jczorkmid.net) Xarton Dragon <UDIC>
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor



From ???@??? Tue Mar 19 00:22:31 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <004001c1cdf2$e74ac020$3b3786d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@GMD.DE>
Subject: Re: [z-machine] Newline Interupt Routines
Date: Sun, 17 Mar 2002 20:32:45 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@GMD.DE
Precedence: bulk


> Frotz and Zip2000 execute the newline routine before moving the cursor
> down to the next line (the newline).  Infocom's Dos terp seems to do it
> AFTER. 8.8.3.2.2 doesn't clearly state if the cursor is moved down
> before or after the interrupt routine is run.  It probably should say
> one way or the other.

As I recall from the original investigations, Infocom's various interpreters
were inconsistent. The standard wants terps to call the routine before,
except (as specified in 8.8.3.2.2.1) when it's playing Zork Zero and
claiming to be the DOS terp, when it should call the routine after.

Kevin
-----



From ???@??? Tue Mar 19 00:22:32 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@GMD.DE
Date: Sun, 17 Mar 2002 12:33:46 -0500
MIME-Version: 1.0
Subject: [z-machine] Newline Interupt Routines
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C948D2A.15601.B8D130@localhost>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Hi all,

I've been playing with aligning text to an irregularly shaped image in 
z6 (http://www.jczorkmid.net/~jpenney/v6lib.diary/) and I've come across 
something probably never came up before.

I save off the current bg colour, then set cursor at edge of possible 
image area and move it back one pixel and set the bg colour to the 
colour under the cursor.  I then compare the current bg colour to the 
original bg.  I keep doing this until I hit something other than the 
original bg colour.  This works in Zip2000, and in Infocom's own dos 
interpreters.  Giving me something like this

+---Image area----+
|   ###### blah blah blah blah
|  ##### blah blah blah blah blah
| #### blah blah blah blah blah
|  ########## blah blah blah blah
|     #### blah blah blah blah blah
| blah blah blah blah blah blah blah
|    #         # blah blah blah blah
+-----------------+

Frotz currently reports a different colour as soon as it's over an 
image... even if it's a trasparent region.  This results in:

+---Image area----+
|   ######        | blah blah blah blah
|  #####          | blah blah blah blah
| ####            | blah blah blah blah
|  ##########     | blah blah blah blah
|     ####        | blah blah blah blah
|                 | blah blah blah blah
|    #         #  | blah blah blah blah
+-----------------+

This isn't that bad actually since it does wrap around the image, but I 
was wondering if it was worth mentioning.  I guess with the true colour 
opcodes proposed for 1.1 where available it wouldn't be as big of a 
deal.

Also there is a slight disconnect between Infocom's Dos terp and both 
Frotz and Zip2000, making this not quite work in one or the other.

Frotz and Zip2000 execute the newline routine before moving the cursor 
down to the next line (the newline).  Infocom's Dos terp seems to do it 
AFTER. 8.8.3.2.2 doesn't clearly state if the cursor is moved down 
before or after the interrupt routine is run.  It probably should say 
one way or the other.

Jay

-- 

Jason C Penney (jpenney@jczorkmid.net) Xarton Dragon <UDIC>
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor



From ???@??? Sat Mar 23 21:09:45 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Track: -20:1
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <005801c1cff6$5049c1c0$0101a8c0@gmd.de>
From: "Volker Blasius" <volker.blasius@GMD.DE>
To: <z-machine@GMD.DE>
Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
Date: Wed, 20 Mar 2002 11:02:08 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-z-machine@GMD.DE
Precedence: bulk


----- Original Message -----
From: <owner-z-machine@GMD.DE>
To: <z-machine-approval@GMD.DE>
Sent: Dienstag, 19. März 2002 23:44
Subject: BOUNCE z-machine@gmd.de: Non-member submission from ["Robin
Lionheart" <lionheart@robinlionheart.com>]


> From: "Robin Lionheart" <lionheart@robinlionheart.com>
> To: <z-machine@GMD.DE>
> References: <3C55232B.16862.27CB3BD@localhost>
> Subject: Re: [z-machine] Standard 1.1 Proposal - 3rd attempt
> Date: Tue, 19 Mar 2002 17:43:54 -0500
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 6.00.2600.0000
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
>
> Jason Penney wrote:
> > I think stating that the interpreter should set these bits to 0
covers
> > it.  If the spec+1 states 'bit X must be 0 in the game file' and
then
> > spec+2 states 'bit X should be set in the game file if the game
wants
> > bunky floobarg, the interpreter should clear it if it's not
provided'
> > then a compiler that compiles to spec+2 is now compiling game files
that
> > are no longer spec+1 compliant game files.
>
> That's why we reserve two header bytes for the standard revision
number, so
> future non-spec+1 compliant games can test whether the terps can
handle
> them, no?
>
> I don't see where Spec 1.0 makes a myopic and useless prescription
like "bit
> X must be 0". Even if it did, I think it should be considered an error
to be
> corrected in Spec 1.1.
>
>
>


From ???@??? Sat Mar 23 21:09:46 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <005901c1cff6$6aeff620$0101a8c0@gmd.de>
From: "Volker Blasius" <volker.blasius@GMD.DE>
To: <z-machine@GMD.DE>
Subject: [z-machine] Z-spec compliance should not depend on Blorb compliance
Date: Wed, 20 Mar 2002 11:02:59 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-z-machine@GMD.DE
Precedence: bulk


----- Original Message -----
From: <owner-z-machine@GMD.DE>
To: <z-machine-approval@GMD.DE>
Sent: Mittwoch, 20. März 2002 0:48
Subject: BOUNCE z-machine@gmd.de: Non-member submission from ["Robin
Lionheart" <lionheart@robinlionheart.com>]


> From: "Robin Lionheart" <lionheart@robinlionheart.com>
> To: <z-machine@GMD.DE>
> Subject: Z-spec compliance should not depend on Blorb compliance
> Date: Tue, 19 Mar 2002 18:48:50 -0500
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 6.00.2600.0000
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
>
> To make Z-Spec compliance conditional on support for Blorb resource
files is
> as inappropriate as making it conditional on support for Quetzal save
game
> files would be.
>
> It should be acceptable to write a terp that can't save or restore
games, so
> long as the save/restore opcodes return the appropriate failure
values. It
> should also be acceptable to write a terp that doesn't do resource
files, as
> long as it resets the color and sound flags appropriately.
>
> The Z-spec should confine itself to Z-code. Blorb compliance should
remain a
> separate issue. It doesn't matter whether a Z-code resource is stored
by
> itself or in a Blorb file or a ZIP archive or a JAR file. Where the
Z-code
> is stored is outside the Z-spec's scope; it doesn't change how the
virtual
> Z-machine interprets the code.
>
> Recommend support for other standards like Blorb or Quetzal if you
like, but
> mandating support for them is inappropriate.
>
>
>


From ???@??? Sat Mar 23 21:10:27 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 21 Mar 2002 14:03:54 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Standard 1.1 - 4th draft
Message-ID: <f626b81a4b.kbracey@kbracey.cam.pace.co.uk>
References: <40DC0D0C-3CCC-11D6-97D8-0003938C3EE0@speakeasy.net>
In-Reply-To: <40DC0D0C-3CCC-11D6-97D8-0003938C3EE0@speakeasy.net>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <40DC0D0C-3CCC-11D6-97D8-0003938C3EE0@speakeasy.net>
          "Matthew T. Russotto" <mrussotto@speakeasy.net> wrote:

> 
> On Thursday, March 21, 2002, at 05:57  AM, Kevin Bracey wrote:
> 
> > I was thinking of adding the following text about suggested button
> > assignments. Can anyone else give me suggested mappings for their 
> > platform?
> > Or tell me what the "proper" names for Windows' buttons are?
> >
> >       Here are some suggested assignments:
> >
> >                                    Button assignments
> >                    Platform   Bit 0 (low)   Bit 1     Bit 2
> >                    ----------------------------------------
> >                    RISC OS    Select        Adjust    Menu
> >                    MacOS      Only button     -         -
> >                    Windows    Left          Right     Middle
> 
> In MacOS X, the secondary button is used to bring up contextual menus.  

Do you actually get one, as standard? Is support for more than one button new
to MacOS X, and if so, should I list Mac OS X separately?

And is it MacOS or Mac OS? (You don't want to hear about the endless RISC
OS/Risc OS/RiscOS/RISCOS arguments).

> The mapping I'd suggest is
> 
> Mac OS X       Primary     Secondary     Tertiary
> 
> (there is no way for a Mac OS X program to know the actual physical 
> positions of the buttons, and it wouldn't be desirable in any case.  Zip 
> Infinity simply maps the OS bits directly to Z-machine bits, allowing 
> the use of my trackball's fourth button as well, but that's getting a 
> bit ridiculous.)

No, it's perfectly sensible.


> > Some of a platform's buttons may be reserved for the interpreter's use 
> > and not visible to the story file, in which case the remaining buttons 
> > should be packed  down to the lowest bits.
> 
> I'd make this mandatory, to avoid situations where a game says, e.g. 
> "requires two button mouse" and then doesn't work because the 
> interpreter author mapped the two available buttons to bit 0 and 2.

Agreed.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Sat Mar 23 21:10:36 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <004901c1d0d8$f550a160$51091a81@gmd.de>
From: "Volker Blasius" <volker.blasius@GMD.DE>
To: <z-machine@GMD.DE>
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Date: Thu, 21 Mar 2002 14:04:38 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Majordomo seems to scan messages a bit too well. :)
Volker

----- Original Message -----
From: <owner-z-machine@GMD.DE>
To: <z-machine-approval@GMD.DE>
Sent: Thursday, March 21, 2002 11:43 AM
Subject: BOUNCE z-machine@gmd.de: Admin request of type /\bsubscribe\b/i at line
3


Date: Thu, 21 Mar 2002 10:42:58 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Message-ID: <94c1a51a4b.kbracey@kbracey.cam.pace.co.uk>
References: <005901c1cff6$6aeff620$0101a8c0@gmd.de>
In-Reply-To: <005901c1cff6$6aeff620$0101a8c0@gmd.de>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Cc: lionheart@robinlionheart.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Robin Lionheart wrote:

[Robin: can you please subscribe to the list, so Volker doesn't have to
moderate your postings?]

> To make Z-Spec compliance conditional on support for Blorb resource files
> is as inappropriate as making it conditional on support for Quetzal save
> game files would be.

As some people argued about draft 3. That's why draft 4 doesn't say that. It
intends to use the same strength of wording about Blorb that the Z-machine
standard uses about story files. Just to prevent confusion, here's the
section from draft 4:

      Blorb is the standard resource format for the Z-machine. Games should
      be distributed either as a single story file, a story file with
      separate Blorb file, or a single executable Blorb file. The latter is
      expected to become the norm for multimedia games.

      As such, Standard 1.1 interpreters are expected to handle Blorb (v1.1)
      files, at least up to support for running a Z-code executable from
      within a Blorb file. If the interpreter supports sound or graphics, it
      should be able to obtain those resources from a Blorb file (although
      the Standard does not preclude other formats).

      Embedded interpreters, or interpreters running on small platforms, may
      accept both Z-code and resources in some custom format, but these
      should come with some form of conversion utility.

To compare, the standard says the following about story files:

      Z-machine programs are stored on disc, or archived
      on the Internet, in what are called story files.
      (Since they were introduced to hold interactive stories.)
      A story file consists of a snapshot of main memory only.
      The processor begins to run a story file by starting with an
      empty stack and a PC value set according to some information
      in the story file's header.  Note that the story file has to be
      set up with many of the structures in memory, such as the
      dictionary and the object tree, already created and with
      sensible contents.

No-one is barring anyone from encrypting, compressing, packaging or otherwise
transforming either the story file or its resources for their own private
purposes.

But you need to have an agreement on a common distribution standard,
otherwise you can't distribute anything. We have a long-established standard
for story files (thank goodness, or we'd all be swapping Commodore 64 disc
images), and we have one for resources. And one for saved games, for that
matter.

> It should be acceptable to write a terp that can't save or restore games,
> so long as the save/restore opcodes return the appropriate failure values.
> It should also be acceptable to write a terp that doesn't do resource
> files, as long as it resets the color and sound flags appropriately.

The expectation (not requirement, thanks to extensive prior lobbying from the
anti-Blorb campaign) to support Blorb extends only as far as extracting the
story file from it - nothing whatsoever to do with sound or graphics.

If you _are_ supporting sound or graphics, the expectation is that you
either get them from Blorb, or use some other (maybe cut-down) format, and
supply a converter. Otherwise there's no way you will be able to run
anything.

Other parts of the spec pin down how Blorb resources behave in the Z-machine.
If you don't want to use Blorb, you should either ignore those parts of the
spec, or follow the general spirit. The multimedia extensions (like multiple
sound channels) are not necessarily dependent on Blorb.

> The Z-spec should confine itself to Z-code. Blorb compliance should remain
> a separate issue.

Unfortunately other people apply the same argument to the Blorb spec - it
should confine itself to Blorb, and it can't require any particular behaviour
from the Z-machine. Something's got to make them meet in the middle, or the
whole exercise is pointless.

Note that the Inform Designer's Manual's chapter on sound and graphics talks
exclusively about Blorb, and Graham Nelson is strongly in favour of Blorb
being adopted. I quote from an earlier message of his on this list:

      On the question of blessing Blorb, I am strongly in favour, puritanism
      notwithstanding. None of the nuances in proposed-1.1 about sound and
      graphics amount to a hill of beans unless there is a reliable delivery
      mechanism for the multimedia content in question. I think Blorb has
      served its apprenticeship in unofficial-standards-ville. (By writing a
      chapter on Blorb into the book on Inform, I was hoping to give it a
      nudge toward wider acceptance.)

      I would also like a stronger statement in favour of supporting Quetzal,
      though not to the extent of an absolute requirement, perhaps.

I forgot to put a mention of Quetzal in the draft, but I must say I'm fed
up of trying to help people get their Zip 2000 saved game files onto their
PDA, only to find out that their bleedin' PDA terp doesn't handle Quetzal :(

> It doesn't matter whether a Z-code resource is stored by itself or in a
> Blorb file or a ZIP archive or a JAR file.

Doesn't matter to whom? Surely it matters to the person who downloads it and
finds it doesn't work on their interpreter?

> Where the Z-code is stored is outside the Z-spec's scope; it doesn't change
> how the virtual Z-machine interprets the code.

Is it outside the scope? Don't Java standards specify what a JAR file is,
and how bytecode is packaged up into a .class file? Why shouldn't the
Z-machine spec specify how a Z-code program is distributed?

> Recommend support for other standards like Blorb or Quetzal if you like,
> but mandating support for them is inappropriate.

It's not mandating them. It's just making a very strong recommendation.

--
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Z/



From ???@??? Sat Mar 23 21:10:38 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 20 Mar 2002 23:04:41 -0500
Subject: Re: [z-machine] Standard 1.1 - 4th draft
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@GMD.DE
Content-Transfer-Encoding: 7bit
In-Reply-To: <00b801c1cf8a$86c0bfe0$5d4786d9@oemcomputer>
Message-Id: <C50CBF62-3C80-11D6-BB13-0003938C3EE0@speakeasy.net>
X-Mailer: Apple Mail (2.481)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

On Tuesday, March 19, 2002, at 04:10  PM, Kevin Bracey wrote:

> After getting diverted for a month or two by a number of non-Z related
> things, and stopping briefly to write a floating-point library, I've put
> together a fourth draft that addresses some of the points in the 
> previous
> draft.

Looks OK, save my previous objection to quote-smartening (summary: don't 
do it, and quotes have their modern meaning).  The language needs some 
cleaning up; there are some "shoulds" which indicate optional behavior, 
and some which indicate required behavior; one particularly ambiguous 
example is in the mouse button bit meaning section.


</x-flowed>
From ???@??? Sat Mar 23 21:10:41 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: Re: [z-machine] Standard 1.1 - 4th draft
To: z-machine@GMD.DE
Date: Thu, 21 Mar 2002 07:30:59 -0500 (EST)
In-Reply-To: <4d17a71a4b.kbracey@kbracey.cam.pace.co.uk> from "Kevin Bracey" at Mar 21, 2002 10:57:32 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20020321123059.0C77B30806D@fauna.jczorkmid.net>
From: jpenney@jczorkmid.net (Jason Penney)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Legend has it that Kevin Bracey said:
>       Here are some suggested assignments:
> 
>                                    Button assignments
>                    Platform   Bit 0 (low)   Bit 1     Bit 2
>                    ----------------------------------------
>                    RISC OS    Select        Adjust    Menu
>                    MacOS      Only button     -         -
>                    Windows    Left          Right     Middle

I think Unix/X would have the same mapping as Windows.

Jay


-- 
Jason C Penney (jpenney@jczorkmid.net)  Xarton Dragon -=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor


From ???@??? Sat Mar 23 21:10:45 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 21 Mar 2002 10:57:32 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Standard 1.1 - 4th draft
Message-ID: <4d17a71a4b.kbracey@kbracey.cam.pace.co.uk>
References: <C50CBF62-3C80-11D6-BB13-0003938C3EE0@speakeasy.net>
In-Reply-To: <C50CBF62-3C80-11D6-BB13-0003938C3EE0@speakeasy.net>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <C50CBF62-3C80-11D6-BB13-0003938C3EE0@speakeasy.net>
          "Matthew T. Russotto" <mrussotto@speakeasy.net> wrote:

> 
> On Tuesday, March 19, 2002, at 04:10  PM, Kevin Bracey wrote:
> 
> > After getting diverted for a month or two by a number of non-Z related
> > things, and stopping briefly to write a floating-point library, I've put
> > together a fourth draft that addresses some of the points in the 
> > previous
> > draft.
> 
> Looks OK, save my previous objection to quote-smartening (summary: don't 
> do it, and quotes have their modern meaning).

Sorry, I'm too strongly in favour of games looking nice :) All prior
Z-machine precedent (and documentation - see the DM4) is for $27 to be an
right-quote/apostrophe. And modern authors have already been using $60 as a
left-quote.

It's only a guideline though; it just gives the order of preferred renderings
as:

             1) right-quote/apostrophe and left-quote
             2) neutral-quote and neutral-quote
             3) neutral-quote and grave

Nothing's compulsory, and conversely, I'm not going to bar anyone from
smartening output; I'm not going to make Zip 2000 look uglier than Infocom's
interpreters. I just want to put some guidelines in.

> The language needs some 
> cleaning up; there are some "shoulds" which indicate optional behavior, 
> and some which indicate required behavior; one particularly ambiguous 
> example is in the mouse button bit meaning section.

Agreed, and done. I've gone through and replaced all the compulsory "shoulds"
with musts, shalls and wills.

I was thinking of adding the following text about suggested button
assignments. Can anyone else give me suggested mappings for their platform?
Or tell me what the "proper" names for Windows' buttons are?

      Here are some suggested assignments:

                                   Button assignments
                   Platform   Bit 0 (low)   Bit 1     Bit 2
                   ----------------------------------------
                   RISC OS    Select        Adjust    Menu
                   MacOS      Only button     -         -
                   Windows    Left          Right     Middle
      
      There is no way for a story file to ascertain how many buttons are
      available to the user, so it is recommended that vital functions are
      not accessible only via secondary mouse buttons. Some of a platform's
      buttons may be reserved for the interpreter's use and not visible to
      the story file, in which case the remaining buttons should be packed
      down to the lowest bits.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Sat Mar 23 21:10:46 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 21 Mar 2002 08:05:01 -0500
Subject: Re: [z-machine] Standard 1.1 - 4th draft
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@GMD.DE
Content-Transfer-Encoding: 7bit
In-Reply-To: <4d17a71a4b.kbracey@kbracey.cam.pace.co.uk>
Message-Id: <40DC0D0C-3CCC-11D6-97D8-0003938C3EE0@speakeasy.net>
X-Mailer: Apple Mail (2.481)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

On Thursday, March 21, 2002, at 05:57  AM, Kevin Bracey wrote:

> I was thinking of adding the following text about suggested button
> assignments. Can anyone else give me suggested mappings for their 
> platform?
> Or tell me what the "proper" names for Windows' buttons are?
>
>       Here are some suggested assignments:
>
>                                    Button assignments
>                    Platform   Bit 0 (low)   Bit 1     Bit 2
>                    ----------------------------------------
>                    RISC OS    Select        Adjust    Menu
>                    MacOS      Only button     -         -
>                    Windows    Left          Right     Middle

In MacOS X, the secondary button is used to bring up contextual menus.  
The mapping I'd suggest is

Mac OS X       Primary     Secondary     Tertiary

(there is no way for a Mac OS X program to know the actual physical 
positions of the buttons, and it wouldn't be desirable in any case.  Zip 
Infinity simply maps the OS bits directly to Z-machine bits, allowing 
the use of my trackball's fourth button as well, but that's getting a 
bit ridiculous.)

> Some of a platform's buttons may be reserved for the interpreter's use 
> and not visible to the story file, in which case the remaining buttons 
> should be packed  down to the lowest bits.

I'd make this mandatory, to avoid situations where a game says, e.g. 
"requires two button mouse" and then doesn't work because the 
interpreter author mapped the two available buttons to bit 0 and 2.


</x-flowed>
From ???@??? Sat Mar 23 21:11:45 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 22 Mar 2002 01:25:57 -0500
From: macintyr@netscape.net (Ian MacIntyre)
To: z-machine@GMD.DE
Subject: RE: [z-machine] Standard 1.1 - 4th draft
Message-ID: <6C7F3456.2BB469BF.009F0D43@netscape.net>
X-Mailer: Atlas Mailer 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-z-machine@GMD.DE
Precedence: bulk


An additional clarification should be added with respect to 
@output_stream 3. The specification says that v3 and above should support @ouput_stream 3, but the "table" operand that would be needed is listed as only being supported on v5 and up. I believe the opcode table and dictionary should be changed to reflect a v3 minimum for the current

v5 output_stream number table 

form.

-- 
Ian MacIntyre

-- 




__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


From ???@??? Fri Mar 29 11:35:48 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Message-ID: <014901c1d448$2155f5e0$4a3686d9@oemcomputer>
From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <z-machine@GMD.DE>
References: <F7YYbbIGYnP4IdpDX0b00004ae6@hotmail.com>
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Date: Mon, 25 Mar 2002 21:57:57 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-z-machine@GMD.DE
Precedence: bulk


> I'm against it, at least insofar as I'm against it being required by the
> spec (which would result not in broader blorb support, but in narrower
spec
> support), and I'm against its appearance in the main part of the spec in
> such a way as to make it appear to be required (And yes, the current
wording
> does suggest that it is required).

Tell me, why do people think Blorb is such a big deal, compared to any of
the other stuff in the spec? I reckon I could probably produce a Blorb patch
for Zip that was less than 30 lines long (assuming you use blorblib).

> Further, I think the spec suffers from an overall inconsistency in how it
> differentiates between "what has been done" and "what this specification
> requires".

I've cleared this up to a large extent in my latest draft - I'll get that up
soon. As Matthew pointed out - far too many "should"s.

Kevin
-----



From ???@??? Fri Mar 29 11:35:54 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.223.108]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Date: Mon, 25 Mar 2002 17:19:59 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F124YqAZswvgOSJSdZ5000081f9@hotmail.com>
X-OriginalArrivalTime: 25 Mar 2002 22:19:59.0803 (UTC) FILETIME=[33B218B0:01C1D44B]
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

>Tell me, why do people think Blorb is such a big deal, compared to any of
>the other stuff in the spec? I reckon I could probably produce a Blorb 
>patch
>for Zip that was less than 30 lines long (assuming you use blorblib).
>

I have several reasons, one of which I think I alluded to in my last mail to 
the list (provided it actually got there; is there any way someone can have 
the list change the reply-to address on messages it sends out?) -- I think 
people are too blorb-happy, and requiring that multimedia-free terps support 
blorb will encourage people to release multimedia games only in blorb 
format.

Secondly, and perhaps more importantly, a lot of people have been acting 
like requiring blorb would suddenly make people supoport blorb.  Blorb has 
been around for some time now, and only a *very* small number of terps 
support it. If we require it for spec 1.1 compliance, no matter how trivial 
you make the amount of work required sound, *it won't result in more blrob 
terps*.  In fact, it'll just result in *most terms not supporting 1.1.  Or 
worse, more terps that *lie about what their compliance*.

Thirdly and unimportantly, I think it's bad phiilisophical mojo to dictate 
these sorts of things in the Z-machine standards document. There shouild be 
a difference between "specification of the Z-machine"
and "what a z-machine interpreter should do".



_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


</x-flowed>
From ???@??? Fri Mar 29 11:36:02 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.223.108]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Date: Mon, 25 Mar 2002 21:23:00 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F55b3ly7nz0eJ0ExpFz000165c2@hotmail.com>
X-OriginalArrivalTime: 26 Mar 2002 02:23:00.0858 (UTC) FILETIME=[26AE85A0:01C1D46D]
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
>
>I doubt it will mostly be set to false.  Zip2000 could set it true...
>Infocom's own DOS V6 terp could set it true if it was still being
>maintained.  The possibility of someone incorrectly interpreting what it
>means doesn't seem like a good reason not to include it.
>
>Jay

Granted, a number of terps would set it to true, but it only takes *one* 
combination to be unavailable for the bit to be set false.  I'll grant that 
the risk of misinterpretatuion isn't a big deal, but what I'm trying to 
point out is that "all combinations are available" just isn't a useful thing 
to know, especially in the negative.  As the author of the game, I don't 
want to know if all combinations are available; I want to know if *this* 
combination is available.  If the bit is set, great.  If not, what have I 
learned? Nothing. I want to combine bold and italic, and the bit is unset 
because the terp can't combine bold and fixed-pitch (this seems like a 
realistic thing for a terp not to be able to do).  The only decision I can 
make, finding the bit unset, is to conclude that it's not safe to combine 
bold and italic, and therefore not do it (which is what I meant by 
misinterpreting the meaning of the bit).  I don't think this is proper 
behavior.  It would be infinately more useful to know *which* combinations 
are available than a blanket "not all of them" (ANd yes, I know that this 
argument could be applied to, say "complies with spec 1.1" as well. Frankly, 
I think Zarf had the right idea with the gestalt system in glulx. (not that 
adding a gestalt to the Z-machine would be a sane thing to try at this 
point))


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


</x-flowed>
From ???@??? Fri Mar 29 11:36:35 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sun, 24 Mar 2002 09:55:56 -0500
Subject: Re: [z-machine] Standard 1.1 - 4th draft
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@GMD.DE
Content-Transfer-Encoding: 7bit
In-Reply-To: <6C7F3456.2BB469BF.009F0D43@netscape.net>
Message-Id: <3EE5C812-3F37-11D6-BBD1-0003938C3EE0@speakeasy.net>
X-Mailer: Apple Mail (2.481)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

On Friday, March 22, 2002, at 01:25  AM, Ian MacIntyre wrote:

> An additional clarification should be added with respect to
> @output_stream 3. The specification says that v3 and above should 
> support @ouput_stream 3, but the "table" operand that would be needed 
> is listed as only being supported on v5 and up. I believe the opcode 
> table and dictionary should be changed to reflect a v3 minimum for the 
> current
>
> v5 output_stream number table

IIRC, output stream 3 is NOT supported in v3.


</x-flowed>
From ???@??? Fri Mar 29 11:36:36 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
To: rraszews@hotmail.com (L. Ross Raszewski)
Date: Mon, 25 Mar 2002 22:34:03 +0000 (GMT)
Cc: z-machine@GMD.DE
In-Reply-To: <F18ypQj0iozzIeSTJNJ0000dbbe@hotmail.com> from "L. Ross Raszewski" at Mar 25, 2002 05:06:02 
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16pd2R-0001oR-00@seasip.demon.co.uk>
From: John Elliott <jce@seasip.demon.co.uk>
Sender: owner-z-machine@GMD.DE
Precedence: bulk


: If I'm going to be 
: playing IF on a system withotu sound and graphic support, I *don't* want my 
: terp to be able to load the z-code resource from the blorb. I want to *not 
: have the blorb*. 

  I seem to recall something similar came up on raif at the end of last
November, and I suggested having two or more Blorb files - one containing
the game, the others containing the resources. The game file would contain a
table listing the other (optional) Blorb files. Thus:
<http://groups.google.com/groups?hl=en&th=f61aeb459a4409c4&seekm=1007157271.2762.0.nnrp-07.c2de7091%40news.demon.co.uk&rnum=1>

  Further down the thread I described an even more backwards-compatible 
(ie, ugly) idea which allows a "naked" Z5 to refer to one or more optional 
Blorb files.

-- 
John Elliott


From ???@??? Fri Mar 29 11:36:39 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@GMD.DE
Date: Mon, 25 Mar 2002 17:53:26 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C9F6416.9270.F7743DA@localhost>
In-reply-to: <F7YYbbIGYnP4IdpDX0b00004ae6@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@GMD.DE
Precedence: bulk


L. Ross Raszewski sent a message across the ether on 25 Mar 2002 (16:12) 
stating:

> Oh, and while I'm at it, I don't get why having "all style
> combinations available" is a useful flag to have; it'll almost
> certainly always be set false, and will probably be interpreted
> (incorrectly) by inform programmers to mean (~~ *no* font
> combinations are available)

Well... I'm working on the style code in V6Lib to not just pass style 
requests on to the opcode.  If it's handed a single a style it checks if 
the terp can do that, and if can it does.  If it can't it changes the 
colour (currently optional at compile time... possibly at run time 
later).  If you asked for a combo, and it's 1.1, and all combos are not 
supported it also uses the alternate option.

So I ask for bold+italics, the terp can do both, but doesn't support all 
style combos, you get bold + a different colour, which is still easy to 
distinguish from plain old bold (again, optional).

> it'll almost certainly always be set false, and will probably be
> interpreted (incorrectly) by inform programmers to mean (~~ *no* font
> combinations are available) 

I doubt it will mostly be set to false.  Zip2000 could set it true... 
Infocom's own DOS V6 terp could set it true if it was still being 
maintained.  The possibility of someone incorrectly interpreting what it 
means doesn't seem like a good reason not to include it.

Jay


-- 

Jason C Penney (jpenney@jczorkmid.net) Xarton Dragon <UDIC>
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor



From ???@??? Fri Mar 29 11:36:40 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 25 Mar 2002 23:18:57 +0000
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: Graham Nelson <graham@gnelson.demon.co.uk>
To: z-machine@GMD.DE
Content-Transfer-Encoding: 7bit
In-Reply-To: <F124YqAZswvgOSJSdZ5000081f9@hotmail.com>
Message-Id: <AEE48EB9-4046-11D6-A9E3-00039340BD8A@gnelson.demon.co.uk>
X-Mailer: Apple Mail (2.481)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
On Monday, March 25, 2002, at 10:19  pm, L. Ross Raszewski wrote:
>> Tell me, why do people think Blorb is such a big deal, compared to any 
>> of
>> the other stuff in the spec? I reckon I could probably produce a Blorb 
>> patch
>> for Zip that was less than 30 lines long (assuming you use blorblib).
...
> Thirdly and unimportantly, I think it's bad phiilisophical mojo to 
> dictate these sorts of things in the Z-machine standards document. 
> There shouild be a difference between "specification of the Z-machine"
> and "what a z-machine interpreter should do".

These things are a matter of degree. For instance, the Quetzal saved
game file format is arguably something which, in a better world, would
have been a part of the standard from the outset. It's really only
for historical reasons that it wasn't, and therefore isn't today.
In that case, too, one could argue that resource-starved interpreters
shouldn't be forced into bad decisions (as compared with using
some ultra-compact weird saved game format of their own), but it's
really rather marginal, and the point is not that an interpreter should
be required to dot every i and cross every t, and merely to pay
minimum respect to the format.

In the case of Blorb, I think it's the association with multimedia
stuff which seems to make people nervous. It really wouldn't make
the Z-Machine spiritually unclean to adopt this format... again, in
a carefully minimal way, as is proposed. Should another format
come along for packaging resources, there is no reason why an
interpreter could not support both, so it's not a case where the
standard is closing off options by making a choice for all time.

I see some virtue in the suggestion that the Standard shouldn't
appear to be telling designers how to distribute their games,
though; as a document, it isn't aimed at them.

--
Graham Nelson


</x-flowed>
From ???@??? Fri Mar 29 11:36:41 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.223.108]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Date: Mon, 25 Mar 2002 17:06:02 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F18ypQj0iozzIeSTJNJ0000dbbe@hotmail.com>
X-OriginalArrivalTime: 25 Mar 2002 22:06:02.0615 (UTC) FILETIME=[40B15870:01C1D449]
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
>
>The point of requiring blorb outside of terps that support sound and
>graphics is that a well written graphical game (at least in the
>traditional illustrated IF form) would detect that the terp doesn't
>support Sound and Graphics and work around them.

This is reasonably true.

>Given that the game
>may only be distributed as ReallyGreatGame.blb, a non multimedia terp
>should be able to load the ZCode from ReallyGreatGame.blb and set the
>header up so that the game knows to work around the non-mutimedianess of
>the terp.
>

I'd like to suggest for a moment that this is part of the problem; we go so 
far as to say in the blorb section of the 1.1 spec draft that "a blorb file 
containing both game code and resources" is to be the primary way of 
distributing games using multimedia. I'm not sure it's good for us to 
encourage this behavior -- So far, almost every guide to integrating blorb 
that I've seen simply assumes that, yes, you bundle your game code in with 
the resources. I don't see this as a necessary step (And, indeed, Moments 
out of Time was *not* bundled with its resources, and not because I knew 
darned right well that no one would be able to play it).  If I'm going to be 
playing IF on a system withotu sound and graphic support, I *don't* want my 
terp to be able to load the z-code resource from the blorb. I want to *not 
have the blorb*.  One primary reason,as far as I can tell, that we want 
blorb support included in the spec is so that if one is playing on a 
resource-limited system, they can still load Z-code out of the blorb, even 
if they can't manage graphics and sound.  But if one is using a 
resource-limited system, they aren't liable to want ot keep several 
megabytes of useless graphics/sound data around.  Even if I'm playing on a 
system that can manage the sound and graphics I desire, I don't like the 
fact that if a game has multimedia resources, current practice is that I 
have no choice but to keep the two together -- given my meager modem 
connection, I'd generally prefer to download th'one, then get the other 
later if my initial playing merits it.

Though it's not our place to discourage the practice of releasing games only 
as a monolithic blb file, maybe we should reconsider having the spec claim 
that this is the "expected" way of doing business.





_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


</x-flowed>
From ???@??? Fri Mar 29 11:36:42 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "David Fillmore" <noslwop@hotmail.com>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Date: Mon, 25 Mar 2002 00:25:52 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F33SEDdlBWY6zgQGYOK0001321e@hotmail.com>
X-OriginalArrivalTime: 25 Mar 2002 00:25:52.0928 (UTC) FILETIME=[9F4BC200:01C1D393]
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
>From: Kevin Bracey <kevin.bracey@pace.co.uk>
>To: z-machine@GMD.DE
>Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb 
>compliance
>Robin Lionheart wrote:
> > To make Z-Spec compliance conditional on support for Blorb resource 
>files
> > is as inappropriate as making it conditional on support for Quetzal save
> > game files would be.
>
>As some people argued about draft 3. That's why draft 4 doesn't say that. 
>It
>intends to use the same strength of wording about Blorb that the Z-machine
>standard uses about story files. Just to prevent confusion, here's the
>section from draft 4:
>
>       Blorb is the standard resource format for the Z-machine. Games 
>should
>       be distributed either as a single story file, a story file with
>       separate Blorb file, or a single executable Blorb file. The latter 
>is
>       expected to become the norm for multimedia games.
>
>       As such, Standard 1.1 interpreters are expected to handle Blorb 
>(v1.1)
>       files, at least up to support for running a Z-code executable from
>       within a Blorb file. If the interpreter supports sound or graphics, 
>it
>       should be able to obtain those resources from a Blorb file (although
>       the Standard does not preclude other formats).
>
>       Embedded interpreters, or interpreters running on small platforms, 
>may
>       accept both Z-code and resources in some custom format, but these
>       should come with some form of conversion utility.

It is not clear from the above section that Blorb support is not required.
Personally, I think Blorb support recommendations should be removed from the
specification itself, and placed into a 'Remarks' section in one of the
chapters, where important suggestions that are not actually required usually
go.


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


</x-flowed>
From ???@??? Fri Mar 29 11:36:44 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sun, 24 Mar 2002 21:05:10 -0800 (PST)
From: Dave <dgriffi@cs.csubak.edu>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
In-Reply-To: <3C9E546D.27998.B5214F5@localhost>
Message-ID: <Pine.OSF.4.05.10203242054130.14165-100000@pegasus.cs.csubak.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@GMD.DE
Precedence: bulk


On Sun, 24 Mar 2002, Jason C Penney wrote:

> David Fillmore sent a message across the ether on 25 Mar 2002 (0:25) 
> stating:
> 
> > It is not clear from the above section that Blorb support is not
> > required. Personally, I think Blorb support recommendations should be
> > removed from the specification itself, and placed into a 'Remarks'
> > section in one of the chapters, where important suggestions that are
> > not actually required usually go.
> 
> Here's the breakdown of people who have chimed in on this (if I'm 
> misrepresenting anyone please chime in).  There are other people who 
> have said things, but it's not clear, to me, where they stand.
[snip breakdown of yea and nay]
> Do other people have an opinion either way?

How would an interpreter running on, say, a PalmOS machine work if it had
to use Blorb?  How about on a WAP phone?  How about (my personal favorite)
a TI graphing calculator?  Processing Blorb files on such platforms might
be troublesome (anyone care to enlighten me?).  Blorb should be mandatory
only if the interpreter will be supporting sound and/or graphics.  If I'm
mistaken about the complexity of processing a Blorb file (ie, a TI-92+ can
handle it), then Blorb should be supported in all cases.


-- 
David Griffith
dgriffi@cs.csubak.edu


From ???@??? Fri Mar 29 11:36:45 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@GMD.DE
Date: Sun, 24 Mar 2002 22:34:21 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C9E546D.27998.B5214F5@localhost>
In-reply-to: <F33SEDdlBWY6zgQGYOK0001321e@hotmail.com>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@GMD.DE
Precedence: bulk


David Fillmore sent a message across the ether on 25 Mar 2002 (0:25) 
stating:

> It is not clear from the above section that Blorb support is not
> required. Personally, I think Blorb support recommendations should be
> removed from the specification itself, and placed into a 'Remarks'
> section in one of the chapters, where important suggestions that are
> not actually required usually go.

Here's the breakdown of people who have chimed in on this (if I'm 
misrepresenting anyone please chime in).  There are other people who 
have said things, but it's not clear, to me, where they stand.

For blorb in spec:
Kevin Bracey
Gavin Lambert
Graham Nelson
Jason Penney

Against:
David Fillmore
Robin Lionheart

Do other people have an opinion either way?

Jay

-- 

Jason C Penney (jpenney@jczorkmid.net) Xarton Dragon <UDIC>
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor



From ???@??? Fri Mar 29 11:36:48 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@GMD.DE
Date: Mon, 25 Mar 2002 00:45:02 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3C9E730E.17956.BC9BBC2@localhost>
References: <3C9E546D.27998.B5214F5@localhost>
In-reply-to: <Pine.OSF.4.05.10203242054130.14165-100000@pegasus.cs.csubak.edu>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Dave sent a message across the ether on 24 Mar 2002 (21:05) stating:

> How would an interpreter running on, say, a PalmOS machine work if it
> had to use Blorb?  How about on a WAP phone?  How about (my personal
> favorite) a TI graphing calculator?  Processing Blorb files on such
> platforms might be troublesome (anyone care to enlighten me?).  Blorb
> should be mandatory only if the interpreter will be supporting sound
> and/or graphics.  If I'm mistaken about the complexity of processing
> a Blorb file (ie, a TI-92+ can handle it), then Blorb should be
> supported in all cases.

That's cover by the following (from the Blorb section of draft 4):

> Embedded interpreters, or interpreters running on small platforms, may
> accept both Z-code and resources in some custom format, but these 
should
> come with some form of conversion utility. 

The point of requiring blorb outside of terps that support sound and 
graphics is that a well written graphical game (at least in the 
traditional illustrated IF form) would detect that the terp doesn't 
support Sound and Graphics and work around them.  Given that the game 
may only be distributed as ReallyGreatGame.blb, a non multimedia terp 
should be able to load the ZCode from ReallyGreatGame.blb and set the 
header up so that the game knows to work around the non-mutimedianess of 
the terp.

Jay

-- 

Jason C Penney (jpenney@jczorkmid.net) Xarton Dragon <UDIC>
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor



From ???@??? Fri Mar 29 11:36:49 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Mon, 25 Mar 2002 11:43:27 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Message-ID: <6fa3ba1c4b.kbracey@kbracey.cam.pace.co.uk>
References: <Pine.OSF.4.05.10203242054130.14165-100000@pegasus.cs.csubak.edu>
In-Reply-To: <Pine.OSF.4.05.10203242054130.14165-100000@pegasus.cs.csubak.edu>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <Pine.OSF.4.05.10203242054130.14165-100000@pegasus.cs.csubak.edu>
          Dave <dgriffi@cs.csubak.edu> wrote:

> 
> Processing Blorb files on such platforms might
> be troublesome (anyone care to enlighten me?).  Blorb should be mandatory
> only if the interpreter will be supporting sound and/or graphics.  If I'm
> mistaken about the complexity of processing a Blorb file (ie, a TI-92+ can
> handle it), then Blorb should be supported in all cases.

Processing Blorb (enough to do what is wanted by the spec, which is just to
be able to run the Z-code within it) is certainly harder than just loading a
Z-code file, but probably easier than handling Quetzal, and definitely easier
than executing Z-code in the first place, or doing demand-paging, like Zip
does.

It's just a question of loading the chunk index, parsing it to find the
executable chunk, and seeking to the right point.

In a Zip-based interpreter, for example, it's basically a matter of letting
the game file be either raw Z-code or Blorb (it doesn't matter which once
you're up and running), and once you've parsed the header, storing a static
"offset to Z-code within file" variable, which you just add in to all your
fseek calls. And knock out any rewind() calls, replacing them with fseek(gfp,
zcode_offset, SEEK_SET).

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Mar 29 11:36:51 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Sun, 24 Mar 2002 09:30:20 -0500
Subject: Re: [z-machine] Standard 1.1 - 4th draft
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@GMD.DE
Content-Transfer-Encoding: 7bit
In-Reply-To: <f626b81a4b.kbracey@kbracey.cam.pace.co.uk>
Message-Id: <AB22CA40-3F33-11D6-BBD1-0003938C3EE0@speakeasy.net>
X-Mailer: Apple Mail (2.481)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

On Thursday, March 21, 2002, at 09:03  AM, Kevin Bracey wrote:

> In message <40DC0D0C-3CCC-11D6-97D8-0003938C3EE0@speakeasy.net>
>           "Matthew T. Russotto" <mrussotto@speakeasy.net> wrote:

>> In MacOS X, the secondary button is used to bring up contextual menus.
>
> Do you actually get one, as standard? Is support for more than one 
> button new
> to MacOS X, and if so, should I list Mac OS X separately?

The Mac doesn't come with a 2-button mouse standard, but OS support 
through the normal event mechanisms for it IS standard, and that is new 
to OS X.

> And is it MacOS or Mac OS? (You don't want to hear about the endless 
> RISC
> OS/Risc OS/RiscOS/RISCOS arguments).

It's "Mac OS", according to the various documents I have within reach.  
The capitalization, at least, is not controversial :-)


</x-flowed>
From ???@??? Fri Mar 29 11:36:54 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 26 Mar 2002 10:58:12 GMT
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Message-ID: <b7543a1d4b.kbracey@kbracey.cam.pace.co.uk>
References: <3CA00681.30366.11F1B421@localhost>
In-Reply-To: <3CA00681.30366.11F1B421@localhost>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <3CA00681.30366.11F1B421@localhost>
          "Jason C Penney" <jpenney@jczorkmid.net> wrote:

> L. Ross Raszewski sent a message across the ether on 25 Mar 2002 (21:23) 
> stating:
> 
> > Granted, a number of terps would set it to true, but it only takes
> > *one* combination to be unavailable for the bit to be set false. 
> > I'll grant that the risk of misinterpretatuion isn't a big deal, but
> > what I'm trying to point out is that "all combinations are available"
> > just isn't a useful thing to know, especially in the negative. 
> 
> In the negative it isn't very useful.  That's not at all what I'm 
> interested in.  In the negative it means spec 1.0 behavior (you can try 
> it and it might work).  In the positive it tells us something we have no 
> way of knowing otherwise (it WILL work).

I've never been entirely convinced by this flag, but I suppose that argument
sort of makes sense. Assuming, of course, it's correctly implemented. And it
isn't necessarily simple to implement correctly - combinations available may
be a run-time issue (see below).

> I was under the impression that most terps that claim they can do bold, 
> italic, and reverse can do them in combination.  If a terp only does 
> bold and reverse, but can do them in combo it can still set the flag.  
> Am I wrong in thinking very few terps would ever set this to 0?

I honestly don't know. The prototype Std1.1 Zip 2000 you've got CAN now set
it to zero, eg if you were using font that had Bold and Italic variants, but
not Bold.Italic. Earlier versions always set it to 1.

> It's a given that 'which combos work' would be more useful.  The only 
> way I can see to reasonably do this would be to change it to work like 
> set_font.
> 
> set_text_style style -> result

In V6, you could inspect the window properties. For example, set bold, then
italic, and see if the property said "bold+italic". Probably not reliable
on current terps, but we could mandate that the window property accurately
showed current style in Std 1.1. No use for V5, of course.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Fri Mar 29 11:37:00 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: "Jason C Penney" <jpenney@jczorkmid.net>
To: z-machine@GMD.DE
Date: Tue, 26 Mar 2002 11:49:43 -0500
MIME-Version: 1.0
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Reply-To: Jason C Penney <jpenney@jczorkmid.net>
Message-ID: <3CA06057.15091.1350A1FB@localhost>
In-reply-to: <b7543a1d4b.kbracey@kbracey.cam.pace.co.uk>
References: <3CA00681.30366.11F1B421@localhost>
X-mailer: Pegasus Mail for Win32 (v4.0, beta 40)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Kevin Bracey sent a message across the ether on 26 Mar 2002 (10:58) 
stating:

> > It's a given that 'which combos work' would be more useful.  The
> > only way I can see to reasonably do this would be to change it to
> > work like set_font.
> > 
> > set_text_style style -> result
> 
> In V6, you could inspect the window properties. For example, set
> bold, then italic, and see if the property said "bold+italic".
> Probably not reliable on current terps, but we could mandate that the
> window property accurately showed current style in Std 1.1. No use
> for V5, of course.

That makes sense for V6.  I'd be happy with that if other people want to 
drop the bit.

Jay

-- 

Jason C Penney (jpenney@jczorkmid.net) Xarton Dragon <UDIC>
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor



From ???@??? Fri Mar 29 11:38:01 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "David Fillmore" <noslwop@hotmail.com>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Date: Thu, 28 Mar 2002 22:52:47 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F230JiQTyfPefLJGWSa0001c541@hotmail.com>
X-OriginalArrivalTime: 28 Mar 2002 22:52:47.0349 (UTC) FILETIME=[47AF0A50:01C1D6AB]
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
>From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
>
>Tell me, why do people think Blorb is such a big deal, compared to any of
>the other stuff in the spec?

I think Blorb a big deal because I think most of the things proposed are
sensible and good. On the other hand, I think required Blorb support and the
new sound support (which I still think could be a lot better somehow)
are not sensible and need to be fixed.

There are other things that I'm not sure about, but on the whole, it isn't
worth talking about the rest of the proposal because I like it the way it 
is.



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


</x-flowed>
From ???@??? Fri Mar 29 12:37:32 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp2.ihug.co.nz: Host p107-tnt7.akl.ihug.co.nz [203.173.206.107] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20020329120618.03697200@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 29 Mar 2002 12:07:39 +1200
To: z-machine@GMD.DE
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Standard 1.1 - 4th draft
In-Reply-To: <AB22CA40-3F33-11D6-BBD1-0003938C3EE0@speakeasy.net>
References: <f626b81a4b.kbracey@kbracey.cam.pace.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
At 09:30 24/03/02 -0500, Matthew T. Russotto wrote:

>>And is it MacOS or Mac OS? (You don't want to hear about the 
>>endless RISC
>>OS/Risc OS/RiscOS/RISCOS arguments).
>
>It's "Mac OS", according to the various documents I have within 
>reach.
>The capitalization, at least, is not controversial :-)

Ah, but then you have to ask whether it's "MacOS X", "Mac OSX", or 
"Mac OS X"; I've seen all three variations commonly.  At least 
I've never seen "MacOSX", though :)

-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}
----
Every dark cloud has a silver lining, but hundreds of people are 
struck by
lightning every year while looking for it.


</x-flowed>
From ???@??? Fri Mar 29 12:47:12 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: smtp2.ihug.co.nz: Host p107-tnt7.akl.ihug.co.nz [203.173.206.107] claimed to be uecs.
Organization: Ultra Enterprises
Message-Id: <5.1.0.14.0.20020329122828.03684980@pop.ihug.co.nz>
X-Sender: uecasm@pop.ihug.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 29 Mar 2002 12:36:33 +1200
To: z-machine@GMD.DE
From: Gavin Lambert <uecasm@geocities.com>
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb
  compliance
In-Reply-To: <Pine.OSF.4.05.10203242054130.14165-100000@pegasus.cs.csuba
 k.edu>
References: <3C9E546D.27998.B5214F5@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
At 21:05 24/03/02 -0800, Dave wrote:
 >How would an interpreter running on, say, a PalmOS machine work 
if
 >it had to use Blorb?  How about on a WAP phone?  How about (my
 >personal favorite) a TI graphing calculator?  Processing Blorb
 >files on such platforms might be troublesome (anyone care to
 >enlighten me?).  Blorb should be mandatory only if the 
interpreter
 >will be supporting sound and/or graphics.

As Kevin Bracey said, processing a Blorb file (in the limited 
sense required by the proposed spec) is trivial when compared to 
actually running the Z-code contained within.

And I think that what people keep forgetting is that when dealing 
with embedded platforms, the terp is not just the bit that 
executes the Z-code, it also includes the mechanism for getting 
the Z-code to the platform in the first place.

So you download a Blorb file containing tons of graphics, and 
sounds, and also the code for a really good game.  Your embedded 
terp came with a utility that runs on your host OS, which reads 
the Blorb file and spits out data in some weird esoteric format 
that your embedded terp can play, while keeping the amount of 
space used on the embedded platform to a minimum.  This could be 
as simple as just extracting the Z-code from the Blorb file, or as 
complex as converting all the graphics and sounds to a format that 
the embedded terp can actually use.  It's no different from how 
you get any other data to your embedded platform.
-- 
Gavin Lambert, Ultra Enterprises, uecasm@geocities.com
{http://ue.cjb.net/}
----
"Sometimes I wonder whether the world is being run by smart people 
who are
putting us on or by imbeciles who really mean it."  -- Mark Twain


</x-flowed>
From ???@??? Sun Apr 07 00:28:48 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 04 Apr 2002 14:28:55 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Message-ID: <0da7ea214b.kbracey@kbracey.cam.pace.co.uk>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
Subject: [z-machine] Draft 6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Draft 6 is now up at

    http://www.jczorkmid.net/~jpenney/ZSpec11-draft6.txt

It has the reworded Blorb and @set_text_style sections I posted earlier,
together with the new Quetzal section. The multiple colour and style bits
have been removed, and the others shuffled down. Extra detail about multiple
colours has been added to @set_colour.

In addition, the introduction spells out SHOULD versus MUST in tedious
detail.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/


From ???@??? Sun Apr 07 00:28:57 2002
Return-Path: <z-machine-owner@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 05 Apr 2002 11:20:09 +0100
From: Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Z-spec compliance should not depend on Blorb compliance
Message-ID: <f2345d224b.kevin@bracey-griffith.freeserve.co.uk>
References: <Pine.OSF.4.30.0204050002340.20191-100000@vesuri.Helsinki.FI> <a2771a224b.kevin@bracey-griffith.freeserve.co.uk> 
 <20020405094650.GA15359@igloo.df.lth.se>
In-Reply-To: <20020405094650.GA15359@igloo.df.lth.se>
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.70) POPstar/2.03
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <20020405094650.GA15359@igloo.df.lth.se>
          Magnus Olsson <mol@df.lth.se> wrote:

> On Thu, Apr 04, 2002 at 11:11:11PM +0100, Kevin Bracey wrote:
> > The earlier drafts did say "Blorb 1.1", but it got lost when the Blorb
> > requirement was watered down. Left as a series of "shoulds", I didn't think
> > there was a need to specify any particular version of Blorb. Looking at
> > it again, I'm still not sure it would make sense to specify a version.
> > 
> > If Blorb (or indeed Quetzal) had gone in as an absolute requirement, then we
> > would have had to specify a minimum (or specific?) version. In its current
> > guise, it's kind of left up to the common sense of interpreter authors.
> 
> You have a point, but I think I'll side with Joonas here, if nothing
> else then for completeness: since you're talking about Blorb, it makes
> sense to define what you mean by "Blorb". Since Blorb compliance is
> a "should" and not an absolute requirement, terp authors will still
> be free to follow any version of Blorb they like (including no version
> at all), but it would be nice if it was made absolutely clear what
> is meant by "Blorb compliance".

As long as we're prepared to update the Z-spec every time the Blorb spec is
(sensibly) updated. Otherwise, the spec will be left telling people that they
SHOULD implement Blorb 1.1 rather than the new Blorb 1.2.

But on the other hand, if Blorb 1.2 is backwards-compatible, then by
implementing it you are also implementing Blorb 1.1, so it becomes a moot
point. Only if Blorb 1.2 were to be backwards incompatible would you violate
the "SHOULD" implement Blorb 1.1 condition, which is what we want.

So, yes, I think that works fine. The sections get changed to:

Blorb
-----
Blorb is the standard resource format for the Z-machine. Games should be
distributed as

    a) a single story file;
    b) a story file with accompanying Blorb file;
 or c) a stand-alone executable Blorb file.
 
To minimise user confusion, Standard 1.1 interpreters should be able to run
Z-code executables contained in either a plain story file, or embedded in a
stand-alone Blorb 1.1 file. If the interpreter supports sound or graphics, it
should be able to obtain those resources from either a stand-alone or
separate Blorb 1.1 file (although the Standard does not preclude other
formats).

Embedded interpreters, or interpreters running on small platforms, may accept
either Z-code or resources in some custom format, but these should come with
some form of conversion utility. In the minimum case of a text-only
interpreter, this might take the form of a Blorb to story file converter.


Quetzal
-------
Quetzal is the standard saved game format for the Z-machine. Standard 1.1
interpreters are recommended to save games in Quetzal 1.4 format (by
default), and to be able to load both compressed and uncompressed Quetzal
1.4 files.


-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/


From ???@??? Fri Apr 19 23:10:59 2002
Return-path: <owner-z-machine@gmd.de>
Delivery-date: Fri, 19 Apr 2002 07:11:58 -0400
Date: Fri, 19 Apr 2002 13:12:18 +0200 (MET DST)
Message-Id: <200204191112.NAA18393@mail.gmd.de>
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
To: uzinf@mirality.co.nz
From: Majordomo@GMD.DE
Subject: Welcome to z-machine
Reply-To: Majordomo@GMD.DE


--

Welcome to the z-machine mailing list!

Please save this message for future reference.  Thank you.

If you ever want to remove yourself from this mailing list,
send the following command in email to
<z-machine-request@gmd.de>:

    unsubscribe

Or you can send mail to <Majordomo@gmd.de> with the following
command in the body of your email message:

    unsubscribe z-machine

or from another account, besides uzinf@mirality.co.nz:

    unsubscribe z-machine uzinf@mirality.co.nz

If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <owner-z-machine@gmd.de> .
This is the general rule for most mailing lists when you need
to contact a human.

 Here's the general information for the list you've subscribed to,
 in case you don't already have it:

[Last updated on: Mon Jan 15 14:54:53 1996]
The Z-machine is Infocom's imaginary computer, designed to run that
company's line of high-quality text adventures.  This list is a forum
to discuss all aspects of this machine, its interpreters, and its
compilers.



From ???@??? Tue Apr 23 21:20:41 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 04:00:16 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 23 Apr 2002 00:50:22 -0700 (PDT)
From: Dave <dgriffi@cs.csubak.edu>
To: z-machine@GMD.DE
Subject: [z-machine] Blorb and game files
Message-ID: <Pine.OSF.4.05.10204230034480.17591-100000@pegasus.cs.csubak.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@GMD.DE
Precedence: bulk



Two things have been bugging me about Blorb support:

1)
Suppose we have a game that uses sound and/or pics that aren't mandatory
for the game, so the author makes available a bare z-code file for those
who don't have a Blorb-capable interpreter.  IMHO, if a Blorb file is to
contain stuff for a Z-Machine game, then it should ALWAYS contain the
z-code file itself.  This would prevent abiguity of which Blorb to get for
a particular game; if you want to play "Dave's Dungeon", grab the Blorb if
you can read it, otherwise get the naked z-code file.

2) 
Should there be a file-nameing standard recommended for Blorb files?  For
example: advent-zm.blb is Advent for the Z-Machine and advent-glx.blb is
for Glulx.  This could be implemented as an update to the standard
Blorbifying scripts and utilities.  Like my first suggestion, this is
intended to reduce abiguity.


-- 
David Griffith
dgriffi@cs.csubak.edu




From ???@??? Tue Apr 23 21:20:42 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 04:20:43 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 23 Apr 2002 01:11:32 -0700 (PDT)
From: Dave <dgriffi@cs.csubak.edu>
To: z-machine@GMD.DE
Subject: [z-machine] Frotz's future
Message-ID: <Pine.OSF.4.05.10204230050481.17591-100000@pegasus.cs.csubak.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@GMD.DE
Precedence: bulk



I thought I'd share my plans for Unix Frotz as it has to do with the
upcoming standard update.


I plan to fully implement Blorb (include SND and MOD) for Unix Frotz.  On
a suggestion from David Kinder, I'm plan to do this such that the core
code is completely ignorant of this.  This should ease porting to strange
platforms that might not be able to handle Blorb very well.

The requirement that the interpreter must be able to play sound-effects
while a MOD is being played (or multiple effects at once) presents a
special problem for Unix machines.  Most native sound-drivers permit only
a single process to access the sound hardware at once.  Unix Frotz
currently generates sound by forking off a process to play the sound and a
signal is sent to cut the sound short.  This works fine if the interpreter
is asked to play just one sound at a time and it's understood that asking
for a new sound be played will stop the old one.  Right now, I don't know
how this can work with multiple sound-effects and/or MODs.  One solution
is to use the Enlightened Sound Daemon to play all sounds.  This would
obviate the need to port to other audio APIs since ESD has already been
ported.  The other is to use SDL.  This is a library akin to the DirectX
family of libraries for Windows[1] and will probably be what I'll use to
produce graphics when I get around to adding an optional GUI to Unix
Frotz.  I'm not entirely clear on this requirement, so please enlighten me
if I've assumed wrong.

I received Unix Frotz from Galen Hazelwood and Jim Dunleavy received the
Frotz core[2] from Stefan Jokisch[3].  It seems that I'm now being looked 
at as the official maintainer of the Frotz codebase because Jim seems to
have vanished.  Does anyone know where he's gone to?


[1] SDL runs on Windows quite nicely too.

[2] The DOS port.

[3] He's now coding for the MAME project.

-- 
David Griffith
dgriffi@cs.csubak.edu




From ???@??? Tue Apr 23 21:49:38 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 06:11:12 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 23 Apr 2002 11:04:32 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Blorb and game files
Message-ID: <f4d2a02b4b.kbracey@kbracey.cam.pace.co.uk>
References: <Pine.OSF.4.05.10204230034480.17591-100000@pegasus.cs.csubak.edu>
In-Reply-To: <Pine.OSF.4.05.10204230034480.17591-100000@pegasus.cs.csubak.edu>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <Pine.OSF.4.05.10204230034480.17591-100000@pegasus.cs.csubak.edu>
          Dave <dgriffi@cs.csubak.edu> wrote:

> 
> Two things have been bugging me about Blorb support:
> 
> 1)
> Suppose we have a game that uses sound and/or pics that aren't mandatory
> for the game, so the author makes available a bare z-code file for those
> who don't have a Blorb-capable interpreter.  IMHO, if a Blorb file is to
> contain stuff for a Z-Machine game, then it should ALWAYS contain the
> z-code file itself.  This would prevent abiguity of which Blorb to get for
> a particular game; if you want to play "Dave's Dungeon", grab the Blorb if
> you can read it, otherwise get the naked z-code file.

That would be a useful convention for public release. It also circumvents the
problem that some Blorb terps might only supported embedded Z-code, and some
might only support separate Z-code.

But during development, it can be a pain to put the ever-changing Z-code into
a fairly stable set of resources. Interpreters should support all
combinations.

As an aside, the user could download both files - running the Z-code file
would load the Blorb, but ignore the Z-code inside it.

> 
> 2) 
> Should there be a file-nameing standard recommended for Blorb files?  For
> example: advent-zm.blb is Advent for the Z-Machine and advent-glx.blb is
> for Glulx.  This could be implemented as an update to the standard
> Blorbifying scripts and utilities.  Like my first suggestion, this is
> intended to reduce abiguity.

This came up on raif a while back. I forget what the conclusion was - have
a quick Google. It's platform-dependent, of course, but it would seem logical
to me for unix-oid platforms to use ".z6.blb" (or whatever), akin to .tar.gz.

Other platforms, like Mac OS and RISC OS have a single "type" ID, which
cannot be nested like that. On RISC OS, my chosen convention would be for
vanilla Blorb or Z-code Blorb to have the "Blorb" type, and Glulx "Blorb" to
have the "Glulx" type - the Glulx interpreter would detect that it was
actually Blorb by inspecting the contents. Zip 2000 would also support a
Z-code Blorb file having "Z-code" type in the same way.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/



From ???@??? Tue Apr 23 22:50:47 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 07:08:40 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: [z-machine] Questions on the spec
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 23 Apr 2002 11:56:33 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E0065D36@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Blorb and game files
Thread-Index: AcHqrx8aBESI4wKcRBSlUFjKQ6xfgAABBlxg
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id MAA28770
Sender: owner-z-machine@GMD.DE
Precedence: bulk



Working on Frotz and looking at various deficiencies in my work-in-progress, I've a
couple of questions that the spec doesn't seem to cover:

The description of the check_unicode opcode says "Bit 0 of the result should be set if
and only if the interpreter can print the character". How does this relate to different
fonts? If I've got "Arial Unicode" as my text font and "Courier New" as my fixed font,
I can print most Unicode characters in the text font but not in the fixed. Does
check_unicode refer to the text font, or just that at least one font will work?

The spec doesn't talk about what an interpreter should do if the user resizes the
interpreter window. WinFrotz does some evil hacking with the window sizes which
usually works (at least for V5/V8 games) but has the potential to go wrong. Kevin,
what does Zip2000 do?

David Kinder            mailto://davidk@monis.com
Monis Software          http://www.monis.com/
Audrey House            Tel: +44 020 7421 4600
16-20 Ely Place         Fax: +44 020 7421 4601
London EC1N 6SN



From ???@??? Wed Apr 24 20:53:08 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 08:57:35 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 23 Apr 2002 08:51:47 -0400
Subject: Re: [z-machine] Questions on the spec
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@GMD.DE
Content-Transfer-Encoding: 7bit
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0065D36@CORP03.corp.monis.com>
Message-Id: <DF5999D6-56B8-11D6-BB77-0003938C3EE0@speakeasy.net>
X-Mailer: Apple Mail (2.481)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

On Tuesday, April 23, 2002, at 06:56  AM, David Kinder wrote:

> The description of the check_unicode opcode says "Bit 0 of the result 
> should be set if
> and only if the interpreter can print the character". How does this 
> relate to different
> fonts? If I've got "Arial Unicode" as my text font and "Courier New" as 
> my fixed font,
> I can print most Unicode characters in the text font but not in the 
> fixed. Does
> check_unicode refer to the text font, or just that at least one font 
> will work?

I'd suggest 'current font'.  Either that or add a parameter to 
check_unicode; it's probably not too late for that.

> The spec doesn't talk about what an interpreter should do if the user 
> resizes the
> interpreter window. WinFrotz does some evil hacking with the window 
> sizes which
> usually works (at least for V5/V8 games) but has the potential to go 
> wrong. Kevin,
> what does Zip2000 do?

If this isn't explicitly "undefined behavior", it should be.  There's no 
mechanism for notifying the interpreter of changes.  Though IMO games 
should check for window size changes after a 'restore', in practice many 
do not.




</x-flowed>
From ???@??? Wed Apr 24 20:53:19 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 12:12:37 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 23 Apr 2002 16:57:21 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Questions on the spec
Message-ID: <1820c12b4b.kbracey@kbracey.cam.pace.co.uk>
References: <456ABFFB6AEC044CA3671F03F16055E0065D36@CORP03.corp.monis.com>
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0065D36@CORP03.corp.monis.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <456ABFFB6AEC044CA3671F03F16055E0065D36@CORP03.corp.monis.com>
          "David Kinder" <david.kinder@monis.com> wrote:

> The description of the check_unicode opcode says "Bit 0 of the result
> should be set if and only if the interpreter can print the character". How
> does this relate to different fonts? If I've got "Arial Unicode" as my text
> font and "Courier New" as my fixed font, I can print most Unicode
> characters in the text font but not in the fixed. Does check_unicode refer
> to the text font, or just that at least one font will work?

I've taken it to mean in the current font.

> The spec doesn't talk about what an interpreter should do if the user
> resizes the interpreter window. WinFrotz does some evil hacking with the
> window sizes which usually works (at least for V5/V8 games) but has the
> potential to go wrong. Kevin, what does Zip2000 do?

You can update the fields in the header at the moment it happens, but you
can't do anything to force the game to take notice. They might look again, or
they might not, and whatever, they can't do anything until the current line
input ends. After a restart things will be okay. After a restore they should
probably look again whatever, as they may have been loaded on a different
interpreter, even.

In V6 there is a header bit which the interpreter can set to ask the game to
redraw, and Zip 2000 sets this after a size change - this is obeyed by the
Infocom games and V6Lib after each command entry. V6Lib will even use timed
input to enhance this, allowing it to check screen size every few seconds.

Resizing the screen is a potentially messy operation for the Z-machine, and
Zip 2000 acknowledges that by not having a resize icon - you have to change
the size via a dialogue box (which specifies in rows and columns).

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/



From ???@??? Wed Apr 24 20:53:35 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 18:31:26 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "David Fillmore" <noslwop@hotmail.com>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Blorb and game files
Date: Tue, 23 Apr 2002 22:25:45 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F226AAsjGey76fsXTLT00003efc@hotmail.com>
X-OriginalArrivalTime: 23 Apr 2002 22:25:46.0126 (UTC) FILETIME=[D0198AE0:01C1EB15]
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
From: Dave <dgriffi@cs.csubak.edu>

>Two things have been bugging me about Blorb support:
>
>1)
>Suppose we have a game that uses sound and/or pics that aren't mandatory
>for the game, so the author makes available a bare z-code file for those
>who don't have a Blorb-capable interpreter.  IMHO, if a Blorb file is to
>contain stuff for a Z-Machine game, then it should ALWAYS contain the
>z-code file itself.  This would prevent abiguity of which Blorb to get for
>a particular game; if you want to play "Dave's Dungeon", grab the Blorb if
>you can read it, otherwise get the naked z-code file.

This isn't some that can be enforced. Of course, if everyone agreed to it,
fair enough.
On the other hand, I don't agree. I'd prefer to release the game and the
resources in seperate files, possibly even having the pictures and sounds as
seperate resource files. This would enable someone who had a non-blorb 
capable
terp to download only the game, and someone who uses a terp which only 
supports
blorb sounds to not download all the pictures.

>2)
>Should there be a file-nameing standard recommended for Blorb files?  For
>example: advent-zm.blb is Advent for the Z-Machine and advent-glx.blb is
>for Glulx.  This could be implemented as an update to the standard
>Blorbifying scripts and utilities.  Like my first suggestion, this is
>intended to reduce abiguity.

I think this was discussed on r*if not too long ago. I'm really not sure
about my feelings on the subject, except to say that blorb can potentially
be used by many more systems than z-machine and glulx, and coming up
with a new standard filename for each system is not something I'd like to
do.

--
Fillmore




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com




</x-flowed>
From ???@??? Wed Apr 24 20:53:37 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 18:35:51 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [62.252.64.5]
From: "David Fillmore" <noslwop@hotmail.com>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Questions on the spec
Date: Tue, 23 Apr 2002 22:31:08 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F165LoeVGBjk3FSoUIo0000006f@hotmail.com>
X-OriginalArrivalTime: 23 Apr 2002 22:31:08.0381 (UTC) FILETIME=[902DC0D0:01C1EB16]
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
From: Kevin Bracey <kevin.bracey@pace.co.uk>
>In message <456ABFFB6AEC044CA3671F03F16055E0065D36@CORP03.corp.monis.com>
>           "David Kinder" <david.kinder@monis.com> wrote:
>
> > The spec doesn't talk about what an interpreter should do if the user
> > resizes the interpreter window. WinFrotz does some evil hacking with the
> > window sizes which usually works (at least for V5/V8 games) but has the
> > potential to go wrong. Kevin, what does Zip2000 do?
>
>You can update the fields in the header at the moment it happens, but you
>can't do anything to force the game to take notice. They might look again, 
>or
>they might not, and whatever, they can't do anything until the current line
>input ends. After a restart things will be okay. After a restore they 
>should
>probably look again whatever, as they may have been loaded on a different
>interpreter, even.
>
>In V6 there is a header bit which the interpreter can set to ask the game 
>to
>redraw, and Zip 2000 sets this after a size change - this is obeyed by the
>Infocom games and V6Lib after each command entry. V6Lib will even use timed
>input to enhance this, allowing it to check screen size every few seconds.

I've been wondering about this bit. The spec says the interpreter sets it
'to request status line redraw'. This should perhaps say 'screen redraw', 
and
a note should be made that a terp may in fact use this to notify the game
of a screen resize.

--
Fillmore

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com




</x-flowed>
From ???@??? Wed Apr 24 20:53:39 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Apr 2002 22:05:42 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-Originating-IP: [128.220.13.224]
From: "L. Ross Raszewski" <rraszews@hotmail.com>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Blorb and game files
Date: Tue, 23 Apr 2002 22:01:01 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F73A1yKweDNC1XwOOrh000001d7@hotmail.com>
X-OriginalArrivalTime: 24 Apr 2002 02:01:02.0156 (UTC) FILETIME=[E2A750C0:01C1EB33]
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

>1)
>Suppose we have a game that uses sound and/or pics that aren't mandatory
>for the game, so the author makes available a bare z-code file for those
>who don't have a Blorb-capable interpreter.  IMHO, if a Blorb file is to
>contain stuff for a Z-Machine game, then it should ALWAYS contain the
>z-code file itself.  This would prevent abiguity of which Blorb to get for
>a particular game; if you want to play "Dave's Dungeon", grab the Blorb if
>you can read it, otherwise get the naked z-code file.
>

My feelings are *totally* the opposite. I don't think a blorb file should 
*ever* contain the game code, unless the game cannot be played without the 
resources.
First, a game may be available with several resource files, or several 
versions of the resource file. The most obvious reason for this is to reduce 
file sizes to facilitate download times. Including the Z-code in every 
version of the blorb trashes that idea.
Second, a single blorb file may be used by multiple games. This is 
impossible if we insist that a blorb file contain it's (unique) associated 
game.
Third, There is a logical differentiation between executable code and 
resource code. (This isn't very good as a practical point, I know)
Third, if we insist that the z-code "must" be in the blorb file,
then *people will only release their games in blorb form*. They will *not*, 
as we'd all hope, release the game as a standalone and as a blorb.

>2)
>Should there be a file-nameing standard recommended for Blorb files?  For
>example: advent-zm.blb is Advent for the Z-Machine and advent-glx.blb is
>for Glulx.  This could be implemented as an update to the standard
>Blorbifying scripts and utilities.  Like my first suggestion, this is
>intended to reduce abiguity.

Since the relevant specifications all mandate least-common-denominator file 
names, that particular convention would cripple the name-space considerably. 
However, I'd have no objection, if only for the sake of convenience, of 
suggesting that only blorb files containing no exec chunks be given the 
'.blb' extention, with others taking, say '.bz?' and '.blx'

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx




</x-flowed>
From ???@??? Wed Apr 24 21:43:12 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Wed, 24 Apr 2002 05:41:04 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 24 Apr 2002 10:32:47 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] Questions on the spec
Message-ID: <d0c0212c4b.kbracey@kbracey.cam.pace.co.uk>
References: <F165LoeVGBjk3FSoUIo0000006f@hotmail.com>
In-Reply-To: <F165LoeVGBjk3FSoUIo0000006f@hotmail.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <F165LoeVGBjk3FSoUIo0000006f@hotmail.com>
          "David Fillmore" <noslwop@hotmail.com> wrote:

> From: Kevin Bracey <kevin.bracey@pace.co.uk>
> > In V6 there is a header bit which the interpreter can set to ask the game
> > to redraw, and Zip 2000 sets this after a size change - this is obeyed by
> > the Infocom games and V6Lib after each command entry. V6Lib will even use
> > timed input to enhance this, allowing it to check screen size every few
> > seconds.
> 
> I've been wondering about this bit. The spec says the interpreter sets it
> 'to request status line redraw'. This should perhaps say 'screen redraw', 
> and a note should be made that a terp may in fact use this to notify the
> game of a screen resize.

Yes, that should be corrected. The Infocom games do in fact take it to mean
screen redraw (with potential resize), and the spec should say that.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/



From ???@??? Thu Apr 25 18:54:19 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Wed, 24 Apr 2002 08:22:53 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [z-machine] Questions on the spec
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 24 Apr 2002 13:17:03 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E0065D38@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Questions on the spec
Thread-Index: AcHq4ZpydTj2PQHMQnCB6GcIjWl2lQAp2NDw
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id OAA00191
Sender: owner-z-machine@GMD.DE
Precedence: bulk



Another day, another question:

The proposed Z-Machine 1.1 spec explicitly defines the RGB values for the
standard Z-Machine colours. Is this really such a good idea?

The reason I ask is that I prefer a darker palette, especially for green.
Full green (0x00FF00) usually looks foul when used as a background colour
on most monitors, whereas something like 0x00D000 is much easier on the
eye. Ideally I'd prefer an interpreter where I could set the RGB values of
the default colours.

Fixing what the RGB values of the colours are does allow a game to all
set_colour(3) and know that the foreground is set to 0x001F. However, I'm
not certain that that is such a big gain: If the game wants *precisely*
that colour it should call set_true_colour(), otherwise it should call
set_colour() and live with what the interpreter and user have picked.

David Kinder            mailto://davidk@monis.com
Monis Software          http://www.monis.com/
Audrey House            Tel: +44 020 7421 4600
16-20 Ely Place         Fax: +44 020 7421 4601
London EC1N 6SN



From ???@??? Thu Apr 25 18:54:20 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Wed, 24 Apr 2002 08:42:21 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 24 Apr 2002 13:36:07 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: RE: [z-machine] Questions on the spec
Message-ID: <bf89322c4b.kbracey@kbracey.cam.pace.co.uk>
References: <456ABFFB6AEC044CA3671F03F16055E0065D38@CORP03.corp.monis.com>
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0065D38@CORP03.corp.monis.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <456ABFFB6AEC044CA3671F03F16055E0065D38@CORP03.corp.monis.com>
          "David Kinder" <david.kinder@monis.com> wrote:

> 
> Another day, another question:
> 
> The proposed Z-Machine 1.1 spec explicitly defines the RGB values for the
> standard Z-Machine colours. Is this really such a good idea?
> 
> The reason I ask is that I prefer a darker palette, especially for green.
> Full green (0x00FF00) usually looks foul when used as a background colour
> on most monitors, whereas something like 0x00D000 is much easier on the
> eye. Ideally I'd prefer an interpreter where I could set the RGB values of
> the default colours.
> 
> Fixing what the RGB values of the colours are does allow a game to all
> set_colour(3) and know that the foreground is set to 0x001F. However, I'm
> not certain that that is such a big gain: If the game wants *precisely*
> that colour it should call set_true_colour(), otherwise it should call
> set_colour() and live with what the interpreter and user have picked.

Hmmm. It's probably more useful to specify them if set_true_colour doesn't
exist, as it allows colour matching between graphics and text. But if you
have set_true_colour, then it is a bit redundant, as you could use
set_true_colour (if set_colour -3 wasn't appropriate).

But on the other hand, Infocom's terps were (as far as I'm aware) very firm
in their implementation of the colours as being pure primaries and
secondaries. I'm also in favour of firm specification of the expected result
- if it's that bright for you it should have been that bright for the author
too, if you both have conforming interpreters.

If you like your greens being darker, then presumably you'd want any bright
greens specified with set_true_colour darker too? Would you be annoyed if
someone did set_true_colour (full green) and you couldn't darken it? Or had
bright green graphics? It seems to me that you might be better served by
general brightness/contrast/gamma controls in the interpreter, that apply to
the whole Z-machine screen.

Whatever, I don't think there's a problem with allowing the user to modify
the definition of standard colours, as long as they default to the correct
thing. It shouldn't be the norm to mess with interpreter settings - the games
themselves should have colour choice menus, just as Infocom's did.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/



From ???@??? Thu Apr 25 18:54:23 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Wed, 24 Apr 2002 11:40:26 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: FW: [z-machine] Questions on the spec
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 24 Apr 2002 16:33:37 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E0035166@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Questions on the spec
Thread-Index: AcHrjWkFXLtU3rs3R1O6e2kYwd2GNAAF3qzAAAAfBxA=
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id RAA26718
Sender: owner-z-machine@GMD.DE
Precedence: bulk



Kevin Bracey wrote:

> But on the other hand, Infocom's terps were (as far as I'm aware) very
> firm in their implementation of the colours as being pure primaries and
> secondaries.

That's true, but slightly contrary to interpreters like DOS Frotz, which
indicate the bold style with a brighter version of the colour (as in
Varicella's light green on dark green), which I've always found to look
rather good. Sadly DOS Frotz wouldn't be able to keep this and be 1.1
compliant, as far as I understand it?

David



From ???@??? Sat Apr 27 13:26:04 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Fri, 26 Apr 2002 05:10:25 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: RE: [z-machine] Questions on the spec
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 26 Apr 2002 10:01:42 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E0065D3A@CORP03.corp.monis.com>
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Questions on the spec
Thread-Index: AcHrjWkFXLtU3rs3R1O6e2kYwd2GNABcchzw
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id LAA30109
Sender: owner-z-machine@GMD.DE
Precedence: bulk



More about colours, I'm afraid... 

The proposed 1.1 specification says, after listing the standard colour set as 5-bit
BGR values:

 "This is the original Amiga Version 6 colour set."

This is backed up by Kevin, who wrote

 "But on the other hand, Infocom's terps were (as far as I'm aware) very firm in their
  implementation of the colours as being pure primaries and secondaries."

I'd like to suggest that neither of these are quite right (at least for Amiga), i.e. the
colour set listed in the 1.1 spec isn't quite the Amiga colours, and that the Amiga
colours aren't pure primaries and secondaries.

To check this I dug out my old Amiga from the cupboard it now lives in, and fired up
original disks of Beyond Zork and Shogun and ran a little tool on the Amiga that shows
a particular screen's palette. Using 4-bit RGB, the Amiga colours for both BZ and Shogun
come out as

  Black    000
  Red      E00
  Green    0C0
  Yellow   EE0
  Blue     05A
  Magenta  F0F
  Cyan     0EE
  White    FFF

In particular, green and blue are not even close to being pure primary. As this colour
set is the Amiga Infocom original (and looks better too :-)) I'd like to suggest that
the cannonical colours should be, in the same 5-bit BGR as the spec uses:

  Black       (true $0000, $$0000000000000000)
  Red         (true $001C, $$0000000000011100)
  Green       (true $0300, $$0000001100000000)
  Yellow      (true $039C, $$0000001110011100)
  Blue        (true $5140, $$0101000101000000)
  Magenta     (true $7C1F, $$0111110000011111)
  Cyan        (true $7380, $$0111001110000000)
  White       (true $7FFF, $$0111111111111111)

One thing I haven't done is to adjust the colours for gamma correction, as was done for
the greys, as I'm not clear on the precise equation used. However I don't believe that
that will significantly change the colours.

Comments?
David



From ???@??? Sat Apr 27 13:26:04 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Fri, 26 Apr 2002 07:10:36 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 26 Apr 2002 12:06:12 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: RE: [z-machine] Questions on the spec
Message-ID: <72fa312d4b.kbracey@kbracey.cam.pace.co.uk>
References: <456ABFFB6AEC044CA3671F03F16055E0065D3A@CORP03.corp.monis.com>
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0065D3A@CORP03.corp.monis.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <456ABFFB6AEC044CA3671F03F16055E0065D3A@CORP03.corp.monis.com>
          "David Kinder" <david.kinder@monis.com> wrote:

> I'd like to suggest that neither of these are quite right (at least for
> Amiga), i.e. the colour set listed in the 1.1 spec isn't quite the Amiga
> colours, and that the Amiga colours aren't pure primaries and secondaries.
> 
> To check this I dug out my old Amiga from the cupboard it now lives in, and
> fired up original disks of Beyond Zork and Shogun and ran a little tool on
> the Amiga that shows a particular screen's palette. Using 4-bit RGB, the
> Amiga colours for both BZ and Shogun come out as
> 
>   Black    000
>   Red      E00
>   Green    0C0
>   Yellow   EE0
>   Blue     05A
>   Magenta  F0F
>   Cyan     0EE
>   White    FFF
> 
> In particular, green and blue are not even close to being pure primary. As
> this colour set is the Amiga Infocom original (and looks better too :-))
> I'd like to suggest that the cannonical colours should be, in the same
> 5-bit BGR as the spec uses:
> 
>   Black       (true $0000, $$0000000000000000)
>   Red         (true $001C, $$0000000000011100)
>   Green       (true $0300, $$0000001100000000)
>   Yellow      (true $039C, $$0000001110011100)
>   Blue        (true $5140, $$0101000101000000)
>   Magenta     (true $7C1F, $$0111110000011111)
>   Cyan        (true $7380, $$0111001110000000)
>   White       (true $7FFF, $$0111111111111111)
> 
> One thing I haven't done is to adjust the colours for gamma correction, as
> was done for the greys, as I'm not clear on the precise equation used.
> However I don't believe that that will significantly change the colours.

Okay, in that case, I'd step back from mandating precise definitions of the
basic colours - also bearing in mind the DOS Frotz behaviour, which it does
seem overly harsh to outlaw. Instead we'll just give a recommendation, and I
would be happy to recommend those Amiga values. There will then be no
canonical relationship between set_colour and set_true_colour, but it will be
possible to find out what the default colours are by reading window
properties.

The gamma equation used is:

   Z component = 31 * [(Amiga component / 15) ^ (1.8/2.2)]

1.8 is the assumed gamma of the, which I've chosen on the limited evidence
I've managed to find. (I believe that on an Amiga, as on the Mac, a given
numerical colour component looks lighter than on a PC). So your blue becomes
$59A0 (B=22,G=13,R=0), rather than $5540 (B=21,G=10,R=0). [ You said $5140,
but 4-bit 10 is closer to 5-bit 21 than 20 ].

If you have a real Amiga, preferably with a monitor, I'd like you to try to
confirm that this gamma estimate is reasonable, by comparing colours with a
PC. And what about the greys? Are they correct? I got them by screenshotting
an Amiga emulator.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/



From ???@??? Sat Apr 27 13:26:08 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Fri, 26 Apr 2002 11:59:33 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
Subject: RE: [z-machine] Questions on the spec
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 26 Apr 2002 16:54:48 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <456ABFFB6AEC044CA3671F03F16055E0035183@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Questions on the spec
Thread-Index: AcHtEujq9Lq2MkqjQRqGhieekL4GTgAJzuaQ
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id RAA02669
Sender: owner-z-machine@GMD.DE
Precedence: bulk



> 1.8 is the assumed gamma of the, which I've chosen on the limited evidence
> I've managed to find. (I believe that on an Amiga, as on the Mac, a given
> numerical colour component looks lighter than on a PC).

That seems likely. The colours in Amiga emulators do not usually look quite
right, which does suggest a different gamma. 

> If you have a real Amiga, preferably with a monitor, I'd like you to try to
> confirm that this gamma estimate is reasonable, by comparing colours with a
> PC.

I will have a look. Sadly my Amiga monitor died a while back. However the Amiga
monitor (which was either a Philips CM8833 or a Commodore 1084, which is really
the Philips with a different badge) were not really monitors in the modern sense;
they contained a 15kHz/50Hz TV tube, so comparison with my TV should be
acceptable.

> And what about the greys? Are they correct? I got them by screenshotting
> an Amiga emulator.

The greys looked right (on the Amiga they are 0xAAA, 0x777 and 0x444. I don't
think either of the Amiga emulators (UAE or Fellow) do gamma correction.

David



From ???@??? Sat Apr 27 13:26:10 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Fri, 26 Apr 2002 13:21:28 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Fri, 26 Apr 2002 18:16:32 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: RE: [z-machine] Questions on the spec
Message-ID: <1ae2532d4b.kbracey@kbracey.cam.pace.co.uk>
References: <456ABFFB6AEC044CA3671F03F16055E0035183@CORP03.corp.monis.com>
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0035183@CORP03.corp.monis.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <456ABFFB6AEC044CA3671F03F16055E0035183@CORP03.corp.monis.com>
          "David Kinder" <david.kinder@monis.com> wrote:

> 
> > 1.8 is the assumed gamma of the, which I've chosen on the limited
> > evidence I've managed to find. (I believe that on an Amiga, as on the
> > Mac, a given numerical colour component looks lighter than on a PC).
> 
> That seems likely. The colours in Amiga emulators do not usually look quite
> right, which does suggest a different gamma. 

Good.

> > And what about the greys? Are they correct? I got them by screenshotting
> > an Amiga emulator.
> 
> The greys looked right (on the Amiga they are 0xAAA, 0x777 and 0x444.

Right, that's the numbers I got.

> I don't
> think either of the Amiga emulators (UAE or Fellow) do gamma correction.

So I gathered; I did look at some source to check. Would you care to work
out the 15-bit numbers again with that gamma formula (rounding to nearest)?

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/



From ???@??? Sat Apr 27 14:05:01 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Fri, 26 Apr 2002 21:59:31 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Organization: Mirality Systems
Message-Id: <5.1.0.14.0.20020427134936.0690be50@mirality.co.nz>
X-Sender: uecasm@mirality.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 27 Apr 2002 13:54:26 +1200
To: <z-machine@GMD.DE>
From: Gavin Lambert <uzinf@mirality.co.nz>
Subject: RE: [z-machine] Questions on the spec
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0035183@CORP03.corp.monis.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
At 16:54 26/04/02 +0100, David Kinder wrote:
 >
 >> And what about the greys? Are they correct? I got them by
 >>screenshotting an Amiga emulator.
 >
 >The greys looked right (on the Amiga they are 0xAAA, 0x777 and
 >0x444. I don't think either of the Amiga emulators (UAE or
 >Fellow) do gamma correction.

Don't know if this is relevant or not, but I've come across the 
following formula:

   gray = ((222 * red) + (707 * green) + (71 * blue)) / 1000;

Assuming each of red, green, and blue have equal scales, this is 
supposed to produce a gray value using the same scale that is 
representative of the actual brightness of the colour.  It's 
basically a weighted average that takes into account that green 
appears much brighter than red, and blue appears darker than red, 
to the human eye at least.
-- 
Gavin Lambert, Mirality Systems
{http://ue.cjb.net/}
----
ERROR: REALITY.SYS Corrupted -- Universe unrecoverable




</x-flowed>
From ???@??? Wed May 01 20:18:39 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Mon, 29 Apr 2002 04:53:26 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
Subject: RE: [z-machine] Questions on the spec
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 29 Apr 2002 09:46:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <456ABFFB6AEC044CA3671F03F16055E0065D3B@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Questions on the spec
Thread-Index: AcHtRr3whyDtrjZ8SU24Or2SYZ6q6ACEqhdw
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id KAA03141
Sender: owner-z-machine@GMD.DE
Precedence: bulk



Over the weekend I fired up my old Amiga and did a quick gamma comparison. This wasn't
exactly the most rigorous experiment ever, as it largely involved me standing in the
middle of the room looking from the PC to the TV and back. However, with similar
brightness settings on the monitor and the TV, a given colour was definitely a lot
brighter on the Amiga than the PC. Even if the monitor brightness was increased
substantially, the gamma adjusted value on the PC was a better match than the raw
value.

Based on that, I'd suggest the following for the section in @set_colour on the
palette. All the colours were worked out with Kevin's formula, which, since it's
not obvious (at least to me) I'm suggesting be added in to the spec. I'm not sure
whether or not this palette should be an absolute requirement or a recommendation.
On the whole I'd favour the former, but what does everyone else think?


Standard 1.1 interpreters must provide the following basic colour set,
regardless of machine type, in both Version 5 and Version 6:

 -1 = sample      (true -3) [V6 only]
  0 = current     (true -2)
  1 = default     (true -1)
  2 = black       (true $0000, $$0000000000000000)
  3 = red         (true $001D, $$0000000000011101)
  4 = green       (true $0340, $$0000001101000000)
  5 = yellow      (true $03BD, $$0000001110111101)
  6 = blue        (true $59A0, $$0101100110100000)
  7 = magenta     (true $7C1F, $$0111110000011111)
  8 = cyan        (true $77A0, $$0111011110100000)
  9 = white       (true $7FFF, $$0111111111111111)
 10 = light grey  (true $5AD6, $$0101101011010110)
 11 = medium grey (true $4631, $$0100011000110001)
 12 = dark grey   (true $2D6B, $$0010110101101011)
 13  reserved
 14  reserved
 15 = transparent (true -4) [V6 only]

This is the original Amiga Version 6 colour set. The colours have been gamma
adjusted from the original 8-bit values used on the Amiga, on the assumption
that the Amiga's system gamma is 1/1.8, using the following formula:

  Z component = 31 * [(Amiga component / 15) ^ (1.8/2.2)]


David Kinder            mailto://davidk@monis.com
Monis Software          http://www.monis.com/
Audrey House            Tel: +44 020 7421 4600
16-20 Ely Place         Fax: +44 020 7421 4601
London EC1N 6SN



From ???@??? Wed May 01 20:18:42 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Mon, 29 Apr 2002 05:01:50 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
Subject: RE: [z-machine] Questions on the spec
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 29 Apr 2002 09:54:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <456ABFFB6AEC044CA3671F03F16055E0065D3C@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Questions on the spec
Thread-Index: AcHtEujq9Lq2MkqjQRqGhieekL4GTgCR8T4A
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id KAA16273
Sender: owner-z-machine@GMD.DE
Precedence: bulk



Another spec question, this time about the mouse. Under V6, when a mouse window is set, Frotz
converts the mouse co-ordinates to be relative to the mouse window. Zip2000, on the other
hand, always reports the mouse co-ordinates relative to the screen (at least this is my
understanding, looking at the source).

I'm guessing here that Zip2000 is right and Frotz is wrong. Since the spec doesn't explicity
state what the mouse co-ordinates are relative to, I'd suggest that the clarification section
of the 1.1 spec update ought to say something about this.

David Kinder            mailto://davidk@monis.com
Monis Software          http://www.monis.com/
Audrey House            Tel: +44 020 7421 4600
16-20 Ely Place         Fax: +44 020 7421 4601
London EC1N 6SN



From ???@??? Wed May 01 20:19:12 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 30 Apr 2002 10:33:58 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 30 Apr 2002 15:24:22 +0100
From: Kevin Bracey <kevin.bracey@pace.co.uk>
To: z-machine@GMD.DE
Subject: RE: [z-machine] Questions on the spec
Message-ID: <ee76532f4b.kbracey@kbracey.cam.pace.co.uk>
References: <456ABFFB6AEC044CA3671F03F16055E0065D3B@CORP03.corp.monis.com>
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0065D3B@CORP03.corp.monis.com>
X-Organization: Pace Micro Technology
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.71)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <456ABFFB6AEC044CA3671F03F16055E0065D3B@CORP03.corp.monis.com>
          "David Kinder" <david.kinder@monis.com> wrote:

> Over the weekend I fired up my old Amiga and did a quick gamma comparison.
> This wasn't exactly the most rigorous experiment ever, as it largely
> involved me standing in the middle of the room looking from the PC to the
> TV and back. However, with similar brightness settings on the monitor and
> the TV, a given colour was definitely a lot brighter on the Amiga than the
> PC. Even if the monitor brightness was increased substantially, the gamma
> adjusted value on the PC was a better match than the raw value.

Excellent news. (The "correct" test would be to calibrate the brightness and
contrast to make the black and white match, then to test the intermediate
colours).

> Based on that, I'd suggest the following for the section in @set_colour on
> the palette. All the colours were worked out with Kevin's formula, which,
> since it's not obvious (at least to me) I'm suggesting be added in to the
> spec. I'm not sure whether or not this palette should be an absolute
> requirement or a recommendation. On the whole I'd favour the former, but
> what does everyone else think?

I'd say that the specific set_colour <-> set_true_colour correspondence for
colours 2-12 should be a recommendation - terps like DOS Frotz should be free
to have a DOS palette, and users should be able to override the colours (at
their own risk).

> Standard 1.1 interpreters must provide the following basic colour set,
> regardless of machine type, in both Version 5 and Version 6:
> 
>  -1 = sample      (true -3) [V6 only]
>   0 = current     (true -2)
>   1 = default     (true -1)
>   2 = black       (true $0000, $$0000000000000000)
>   3 = red         (true $001D, $$0000000000011101)
>   4 = green       (true $0340, $$0000001101000000)
>   5 = yellow      (true $03BD, $$0000001110111101)
>   6 = blue        (true $59A0, $$0101100110100000)
>   7 = magenta     (true $7C1F, $$0111110000011111)
>   8 = cyan        (true $77A0, $$0111011110100000)
>   9 = white       (true $7FFF, $$0111111111111111)
>  10 = light grey  (true $5AD6, $$0101101011010110)
>  11 = medium grey (true $4631, $$0100011000110001)
>  12 = dark grey   (true $2D6B, $$0010110101101011)
>  13  reserved
>  14  reserved
>  15 = transparent (true -4) [V6 only]
> 
> This is the original Amiga Version 6 colour set. The colours have been
> gamma adjusted from the original 8-bit values used on the Amiga, on the
> assumption that the Amiga's system gamma is 1/1.8, using the following
> formula:
> 
>   Z component = 31 * [(Amiga component / 15) ^ (1.8/2.2)]

Sounds good.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/Zip2000/



From ???@??? Sun May 26 12:48:50 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 23 May 2002 06:05:10 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
Subject: [z-machine] Inform home page
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Thu, 23 May 2002 10:51:34 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E00352AA@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Questions on the spec
Thread-Index: AcHwU/ZmTupZ6ULnRFyFRWb3lWN07gR617TA
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id LAA18759
Sender: owner-z-machine@GMD.DE
Precedence: bulk



Does anyone know what's happened to the new Inform page? It seems to have
disappeared and the domain doesn't seem to have a valid DNS entry any more.

David



From ???@??? Sun May 26 14:34:10 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Sat, 25 May 2002 22:27:07 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Organization: Mirality Systems
Message-Id: <5.1.0.14.0.20020526141803.028626e0@mirality.co.nz>
X-Sender: uecasm@mirality.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 26 May 2002 14:20:01 +1200
To: "David Kinder" <david.kinder@monis.com>, <z-machine@GMD.DE>
From: Gavin Lambert <uzinf@mirality.co.nz>
Subject: Re: [z-machine] Inform home page
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E00352AA@CORP03.corp.monis.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
At 10:51 23/05/2002 +0100, David Kinder wrote:
 >
 >Does anyone know what's happened to the new Inform page? It 
seems
 >to have disappeared and the domain doesn't seem to have a valid
 >DNS entry any more.

The only Inform address I knew about was 
http://gnelson.demon.co.uk/ - I went there and was redirected to 
http://www.inform-fiction.org/.  That address worked properly, 
albeit a little slowly.
-- 
Gavin Lambert, Mirality Systems
{http://ue.cjb.net/}
----
/*
    WARNING:  THIS CODE IS A HACK.  WE CAN NOT AND WILL NOT BE
    RESPONSIBLE FOR ANY NAUSEA, DIZZINESS, VOMITING, OR SHORTNESS 
OF
    BREATH RESULTING FROM READING THIS CODE.  PREGNANT WOMEN AND
    INDIVIDUALS WITH BACK INJURIES, HEART CONDITIONS, OR ARE UNDER
    THE CARE OF A PHYSICIAN SHOULD NOT READ THIS CODE.

      -- The Management
*/




</x-flowed>
From ???@??? Sun Jun 30 23:37:24 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 27 Jun 2002 05:22:19 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [z-machine] Mouse support
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Thu, 27 Jun 2002 10:14:39 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E0065D70@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Questions on the spec
Thread-Index: AcHwU/ZmTupZ6ULnRFyFRWb3lWN07gtZjqwg
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id LAA27671
Sender: owner-z-machine@GMD.DE
Precedence: bulk



I've been doing some work on V6 mouse support in my interpreter interface.
One issue that I came across was that the Z-Machine specification doesn't
state whether mouse co-ordinates in the header and as returned by @read_mouse
should be reported relative to the position of the current mouse window (as
Frotz does) or as absolute screen values (as Zip2000 does).

Anyway, after modifying Jason's ZMouse to use a V6 window in the middle 
of the screen, it seems that Infocom's Amiga and DOS interpreters always
report absolute co-ordinates. I don't have access to a Mac or any of
Infocom's Mac interpreters, so I can't test that. Assuming that the Mac
versions follow the same logic, I'd like to suggest the following
addition to the Spec 1.1 document in the clarifications section (below 
"Mouse clicks":


Mouse co-ordinates
------------------
Mouse co-ordinates, whether returned by the @read_mouse opcode or written
into the header during input, are always relative to the top of the display
at (1,1), regardless of the position of the current mouse window.


David

PS: Since there hasn't been any discussion about it for ages, are we now
going to settle on the 1.1 spec?



From ???@??? Sun Jun 30 23:37:24 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 27 Jun 2002 07:16:07 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 27 Jun 2002 07:09:58 -0400
From: Mark J Musante <olorin@world.std.com>
X-X-Sender: olorin@shell01.TheWorld.com
To: z-machine@GMD.DE
Subject: Re: [z-machine] Mouse support
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0065D70@CORP03.corp.monis.com>
Message-ID: <Pine.SGI.4.40.0206270709300.3310260-100000@shell01.TheWorld.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@GMD.DE
Precedence: bulk




On Thu, 27 Jun 2002, David Kinder wrote:
> Mouse co-ordinates
> ------------------
> Mouse co-ordinates, whether returned by the @read_mouse opcode or written
> into the header during input, are always relative to the top of the display
> at (1,1), regardless of the position of the current mouse window.

Most systems I've seen use (0,0).


-markm




From ???@??? Sun Jun 30 23:37:24 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 27 Jun 2002 07:43:26 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [z-machine] Mouse support
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Thu, 27 Jun 2002 12:35:44 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E020A36F@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Mouse support
Thread-Index: AcIdy/Jn2ZMsX5yORtqbI3azSKxLzwAApGrA
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id NAA07474
Sender: owner-z-machine@GMD.DE
Precedence: bulk



> Most systems I've seen use (0,0).

Infocom's DOS interpreter seems to use (0,0) as the top left for @read_mouse
and (1,1) for the top left for the header values. It would seem to make
sense to use (1,1) as the rest of the V6 screen model always uses (1,1)
for the top left when moving windows, etc.

David



From ???@??? Sun Jun 30 23:37:24 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 27 Jun 2002 09:03:46 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 27 Jun 2002 08:58:13 -0400
Subject: Re: [z-machine] Mouse support
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@GMD.DE
Content-Transfer-Encoding: 7bit
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E0065D70@CORP03.corp.monis.com>
Message-Id: <8A774A16-89CD-11D6-9805-0003938C3EE0@speakeasy.net>
X-Mailer: Apple Mail (2.482)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

On Thursday, June 27, 2002, at 05:14  AM, David Kinder wrote:

I'm fairly sure I've done this test before, and the Mac interpreter has 
the mouse co-ordinates relative to the screen, not the mouse window.  
The mouse window is a constraint only, not an origin.

I don't have time to do the test now, but I'll check the 1,1 v. 0,0 
thing later, ifI remember.




</x-flowed>
From ???@??? Sun Jun 30 23:37:24 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 27 Jun 2002 09:40:59 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [z-machine] Mouse support
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Thu, 27 Jun 2002 14:28:35 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E020A378@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] Mouse support
Thread-Index: AcId2vsPCTKaZoIFS0GH/ZFTiapbLQAA2BwwAAAG9qA=
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id PAA12730
Sender: owner-z-machine@GMD.DE
Precedence: bulk



> I don't have time to do the test now, but I'll check the 1,1 v. 0,0 
> thing later, if I remember.

I think Jason has already done some tests that indicate the 
Mac used (1,1) too:

http://www.jczorkmid.net/~jpenney/v6lib.diary/

David



From ???@??? Thu Jul 25 20:17:57 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Jul 2002 14:50:17 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15677.41802.840324.995961@jackfruit.Stanford.EDU>
Date: Tue, 23 Jul 2002 11:41:14 -0700
To: z-machine@GMD.DE
Subject: [z-machine] hello; file length field in header
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Hi.  I'm new here; is there an archive of this mailing list anywhere,
perchance?  I'm writing a Z-machine interpreter, and I get the feeling
that I'm about to ask a lot of Frequently Asked Questions...

Anyways, my first question is:

How much wiggle-room is there in the file length specified in the
header?  I was just comparing that length (multiplied by the
appropriate constant) with some of the files on the Masterpieces CD.
Some of the files are considerably longer than specified
(e.g. zorkN.dat), but the stuff after the specified length is pretty
clearly padding.  But a lot of the files seem to be one byte longer,
with that extra byte being 0x1a in all the cases that I've examined.

I assume that byte isn't "really" part of the game file, and that I'm
justified in not including it in my memory.  But I wanted to
double-check, because the standard isn't completely clear on this; I
could read 11.1.6 to mean that header word 0x1a is calculated by
taking the actual file length (which might not be a multiple of 2 or 4
or 8) and then dividing it by an appropriate constant (and ignoring
the remainder), in which case I should include that extra byte in my
memory (and, indeed, up to an extra 3 or 7 bytes in some
circumstances).

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       NANCY!!  Why is everything RED?!



From ???@??? Thu Jul 25 20:17:57 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Jul 2002 16:49:55 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Subject: Re: [z-machine] hello; file length field in header
To: z-machine@GMD.DE
Date: Tue, 23 Jul 2002 21:43:06 +0100 (BST)
Cc: carlton@math.stanford.edu
In-Reply-To: <no.id> from "david carlton" at Jul 23, 2002 11:41:14 
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E17X6Us-0000eT-00@seasip.demon.co.uk>
From: John Elliott <jce@seasip.demon.co.uk>
Sender: owner-z-machine@GMD.DE
Precedence: bulk


: How much wiggle-room is there in the file length specified in the
: header?  I was just comparing that length (multiplied by the
: appropriate constant) with some of the files on the Masterpieces CD.
: Some of the files are considerably longer than specified
: (e.g. zorkN.dat), but the stuff after the specified length is pretty
: clearly padding.  But a lot of the files seem to be one byte longer,
: with that extra byte being 0x1a in all the cases that I've examined.

  The "Extra byte is 0x1A" is likely to be a throwback to CP/M days, when 
text files were terminated with 0x1A. Even now, some programs append 0x1A
to text files they're outputting; InstallShield does, for example.

: I assume that byte isn't "really" part of the game file, and that I'm
: justified in not including it in my memory.  But I wanted to
: double-check, because the standard isn't completely clear on this; I
: could read 11.1.6 to mean that header word 0x1a is calculated by
: taking the actual file length (which might not be a multiple of 2 or 4
: or 8) and then dividing it by an appropriate constant (and ignoring
: the remainder)

  In Infocom's own v3 interpreter for the Z80, word 0x1A is only used 
when verifying the game. It is multiplied by 2 and then that number of bytes
is summed (excluding the header). It therefore seems likely that word 0x1A 
is ((filesize + 1) / 2) rather than (filesize / 2). At a guess, then, 
in v5 this word would be (filesize + 3) / 4, and in v8, (filesize + 7) / 8.

  This means that when a Z-code file with an odd number of bytes is
checksummed, the interpreter may try to read off the end of the file. So
either the file has to be padded to the next appropriate multiple with zero
bytes, or the interpreter has to supply zero bytes for requests beyond the 
end of the file.
  In fact, a cursory survey of Z-code files suggests that both Infocom and 
Inform files are padded to a multiple of 512 bytes in any case. It might be 
instructive to create some pathological Z-code files, such as:

* A v3 file whose size on disc is one byte shorter than 2 * header length;
* A v5 file with a few megabytes of random data appended;
* A file for which word 0x1A has been reduced (so that the Z-code tries to
 access memory beyond the end of the file) 

  and see how interpreters cope with them. If interpreters don't have
trouble in the second case (overlong Z-code files) then that allows the 
possibility of appending additional data to a Z-code story file that newer
interpreters can parse and older interpreters ignore - such as a Blorb file,
for example.

-- 
John Elliott



From ???@??? Thu Jul 25 20:17:57 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 23 Jul 2002 18:14:27 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15677.54212.557569.684567@jackfruit.Stanford.EDU>
Date: Tue, 23 Jul 2002 15:08:04 -0700
To: z-machine@GMD.DE
Cc: John Elliott <jce@seasip.demon.co.uk>
Subject: Re: [z-machine] hello; file length field in header
In-Reply-To: <E17X6Us-0000eT-00@seasip.demon.co.uk>
References: <no.id>
	<E17X6Us-0000eT-00@seasip.demon.co.uk>
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


On Tue, 23 Jul 2002 21:43:06 +0100 (BST), John Elliott <jce@seasip.demon.co.uk> said:

> The "Extra byte is 0x1A" is likely to be a throwback to CP/M days, when 
> text files were terminated with 0x1A.

Ah, thanks for the info.

> It therefore seems likely that word 0x1A is ((filesize + 1) / 2)
> rather than (filesize / 2).

No, it's filesize / 2 (which is (filesize - 1) / 2).  Unless there's
padding, in which case it's (unpadded part / 2) in the ones I've
checked by hand (assuming I didn't make mistakes).  So I think it
should be safe for interpreters to allocate an array whose size is
given by looking in the header and then reading that number of
characters: they shouldn't have unexpeted EOF's.

> In fact, a cursory survey of Z-code files suggests that both Infocom
> and Inform files are padded to a multiple of 512 bytes in any case.

Not in all cases; I'll put a table at the end.

> If interpreters don't have trouble in the second case (overlong
> Z-code files) then that allows the possibility of appending
> additional data to a Z-code story file that newer interpreters can
> parse and older interpreters ignore - such as a Blorb file, for
> example.

That's an interesting idea!  Or debugging information could be put
there in the future.  (Though maybe the debugging information would be
better put in the Blorb file, whether appended at the end as you
suggest or in a separate file.)  You'd have to be a bit careful to
distinguish the extra file at the end from padding; but the padding
seems regular enough that picking a magic word to signal the start of
an extra file shouldn't be a problem.

Anyways, here's a table of the actual and predicted file sizes for the
games on the Masterpieces CD.  Many are padded, but many aren't.  I've
examined some of the ones with padding by hand; in all situations that
I looked at, it looks like the game code ends where predicted by the
header.  (In some circumstances, it is then followed by a single 0x1a
byte plus a lot of padding bytes, 0x00 or 0x5e; in some circumstances,
there isn't the 0x1a, just the padding bytes.)  I don't see the
pattern behind the padding: why is infidel.dat so long, for example?
(But I checked, and it really is 93556 bytes plus 29324 bytes of
padding; note that 122880 is divisible by 8192 but not by 16384.)  I
think (but I'm not sure) that the 0x00 padding bytes bring things up
to a nice multiple and then some 0x5e padding bytes are thrown on in
what seems to me a haphazard fashion...

amfv.dat: Actual: 262018 Predicted: 262016
ballyhoo.dat: Actual: 153600 Predicted: 128556
beyondzo.dat: Actual: 276480 Predicted: 261388
borderzo.dat: Actual: 178373 Predicted: 178372
bureaucr.dat: Actual: 243341 Predicted: 243340
cutthroa.dat: Actual: 112640 Predicted: 112558
deadline.dat: Actual: 122880 Predicted: 108454
enchante.dat: Actual: 122880 Predicted: 111126
hollywoo.dat: Actual: 109651 Predicted: 109650
infidel.dat: Actual: 122880 Predicted: 93556
leather.dat: Actual: 129023 Predicted: 129022
lurking.dat: Actual: 153600 Predicted: 128986
moonmist.dat: Actual: 153600 Predicted: 128866
nordandb.dat: Actual: 170285 Predicted: 170284
planetfa.dat: Actual: 122880 Predicted: 109398
plundere.dat: Actual: 128963 Predicted: 128962
seastalk.dat: Actual: 117763 Predicted: 117762
sherlock.dat: Actual: 188445 Predicted: 188444
sorcerer.dat: Actual: 122880 Predicted: 108682
spellbre.dat: Actual: 153600 Predicted: 128916
starcros.dat: Actual: 92160 Predicted: 83792
stationf.dat: Actual: 153600 Predicted: 128934
suspect.dat: Actual: 122880 Predicted: 118692
suspend.dat: Actual: 122880 Predicted: 105584
trinity.dat: Actual: 262065 Predicted: 262064
wishbrin.dat: Actual: 128905 Predicted: 128904
witness.dat: Actual: 122880 Predicted: 104664
zork1.dat: Actual: 92160 Predicted: 84876
zork2.dat: Actual: 92160 Predicted: 89912
zork3.dat: Actual: 92160 Predicted: 82714

And, if you want to poke around with other files, here's the code that
I used:

/* C code to predict Z-Machine file sizes by looking at the header */

#include <stdio.h>

main()
{
  int i, length;
  unsigned char version = getchar(), temp1, temp2;

  for (i = 1; i < 0x1a; ++i)
    getchar();

  temp1 = getchar();
  temp2 = getchar();
  length = (version <= 3 ? 2 : (version <= 5 ? 4 : 8))
    * ((temp1 * 256) + temp2);
  printf("%d\n", length);
}


#!/bin/bash

# A shell script to generate the aforementioned table, assuming a.out
# is the program whose source is given above.

INFOCOMDIR=~/if/infocom

for file in $(cd ${INFOCOMDIR}; ls *.dat); do
  echo -n "${file}: "
  echo -n "Actual: $(ls -l ${INFOCOMDIR}/${file} | sed 's/^.*users *//' | sed 's/ .*//') "
  echo "Predicted: $(a.out < ${INFOCOMDIR}/${file})"
done

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       Hmmm..  a CRIPPLED ACCOUNTANT with a FALAFEL sandwich is HIT by
       a TROLLEY-CAR..



From ???@??? Thu Jul 25 20:20:27 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Wed, 24 Jul 2002 14:33:58 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Wed, 24 Jul 2002 19:25:10 +0100
From: Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] hello; file length field in header
Message-ID: <a5902f5b4b.kevin@bracey-griffith.freeserve.co.uk>
References: <15677.41802.840324.995961@jackfruit.Stanford.EDU>
In-Reply-To: <15677.41802.840324.995961@jackfruit.Stanford.EDU>
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.70) POPstar/2.03
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <15677.41802.840324.995961@jackfruit.Stanford.EDU>
          david carlton <carlton@math.stanford.edu> wrote:

> Hi.  I'm new here; is there an archive of this mailing list anywhere,
> perchance?  I'm writing a Z-machine interpreter, and I get the feeling
> that I'm about to ask a lot of Frequently Asked Questions...

Don't think so, I'm afraid.

> Anyways, my first question is:
> 
> How much wiggle-room is there in the file length specified in the
> header?

None. Except that it may be zero, meaning you'll have to check file length
yourself - that's the case for V1 and V2, and it's also been proposed to be
ollowed for later versions so the size can go above 512K (in V6 and V7).

>I was just comparing that length (multiplied by the
> appropriate constant) with some of the files on the Masterpieces CD.
> Some of the files are considerably longer than specified
> (e.g. zorkN.dat), but the stuff after the specified length is pretty
> clearly padding.  But a lot of the files seem to be one byte longer,
> with that extra byte being 0x1a in all the cases that I've examined.

If the header specifies the length, anything after that is padding. You don't
need to load it, and it MUSTN'T be included in checksum calculations. The
file cannot be shorter than the header specifies - this should be a fatal
interpreter error.

> I assume that byte isn't "really" part of the game file, and that I'm
> justified in not including it in my memory.  But I wanted to
> double-check, because the standard isn't completely clear on this; I
> could read 11.1.6 to mean that header word 0x1a is calculated by
> taking the actual file length (which might not be a multiple of 2 or 4
> or 8) and then dividing it by an appropriate constant (and ignoring
> the remainder), in which case I should include that extra byte in my
> memory (and, indeed, up to an extra 3 or 7 bytes in some
> circumstances).

No - it's up to the person creating the game file to ensure that its size
is a multiple of 2, 4 or 8 as appropriate.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/



From ???@??? Thu Jul 25 22:06:39 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 25 Jul 2002 05:52:19 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Organization: Mirality Systems
Message-Id: <5.1.1.6.0.20020725213934.02613008@mirality.co.nz>
X-Sender: uecasm@mirality.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 25 Jul 2002 21:45:13 +1200
To: z-machine@GMD.DE
From: Gavin Lambert <uzinf@mirality.co.nz>
Subject: Re: [z-machine] hello; file length field in header
In-Reply-To: <a5902f5b4b.kevin@bracey-griffith.freeserve.co.uk>
References: <15677.41802.840324.995961@jackfruit.Stanford.EDU>
 <15677.41802.840324.995961@jackfruit.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
At 19:25 24/07/2002 +0100, Kevin Bracey wrote:
 >
 >> Hi.  I'm new here; is there an archive of this mailing list
 >> anywhere, perchance?  I'm writing a Z-machine interpreter,
 >> and I get the feeling that I'm about to ask a lot of
 >> Frequently Asked Questions...
 >
 >Don't think so, I'm afraid.

How interested do you think people would be in a public archive of 
this list, then?  If there's sufficient interest, I might put all 
the emails I have archived (and to my knowledge I have every 
message back until 2 June 1997) up on my website.

No promises though -- especially since my website has been "under 
construction" for a couple of months with not that much 
progress...  (it's not the site mentioned in my sig, if you're 
curious)
-- 
Gavin Lambert, Mirality Systems
{http://ue.cjb.net/}
----
It might look like I'm doing nothing, but at the cellular level 
I'm really quite busy.




</x-flowed>
From ???@??? Thu Jul 25 22:42:27 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 25 Jul 2002 06:39:24 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [z-machine] hello; file length field in header
Date: Thu, 25 Jul 2002 11:35:40 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E020A4B7@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] hello; file length field in header
Thread-Index: AcIzwMJ/RlvxVId9QG2UZgaZX/+7MAABhgUQ
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id MAA05477
Sender: owner-z-machine@GMD.DE
Precedence: bulk



> How interested do you think people would be in a public archive of 
> this list, then?  If there's sufficient interest, I might put all 
> the emails I have archived (and to my knowledge I have every 
> message back until 2 June 1997) up on my website.

Having an archive of this list would be a very good idea, I think, otherwise
all sorts of Z-Machine details just get lost.

Could you upload your archive of the list to ftp.ifarchive.org? Has anyone
got an archive of the list going back before 1997?

David



From ???@??? Thu Jul 25 23:02:27 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 25 Jul 2002 06:54:17 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Organization: Mirality Systems
Message-Id: <5.1.1.6.0.20020725224504.025fc710@mirality.co.nz>
X-Sender: uecasm@mirality.co.nz
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 25 Jul 2002 22:49:45 +1200
To: <z-machine@GMD.DE>
From: Gavin Lambert <uzinf@mirality.co.nz>
Subject: RE: [z-machine] hello; file length field in header
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E020A4B7@CORP03.corp.monis.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>
At 11:35 25/07/2002 +0100, David Kinder wrote:
 >
 >Having an archive of this list would be a very good idea, I 
think,
 >otherwise all sorts of Z-Machine details just get lost.
 >
 >Could you upload your archive of the list to ftp.ifarchive.org? 
Has
 >anyone got an archive of the list going back before 1997?

Unless you like dealing with about 4Mb of text solidly 
concatenated together (that's how my email client likes to store 
messages), I'd recommend waiting for the website :)

Admittedly that includes all the routing headers etc, so there's 
probably only 3Mb of actual content there...

It's also not necessarily complete, though it's as complete as I 
have.  There have been times when my email account has gone wonky, 
though, so I may have missed a few messages :(

-- 
Gavin Lambert, Mirality Systems
{http://ue.cjb.net/}
----
Life after death?  Is that like terminate and stay resident?




</x-flowed>
From ???@??? Thu Jul 25 23:32:22 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 25 Jul 2002 07:23:38 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [z-machine] hello; file length field in header
Date: Thu, 25 Jul 2002 12:19:48 +0100
Message-ID: <456ABFFB6AEC044CA3671F03F16055E020A4B8@CORP03.corp.monis.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [z-machine] hello; file length field in header
Thread-Index: AcIzyY10Y4FD0AfGTU6xkWWCTuCjggAA4mCQ
From: "David Kinder" <david.kinder@monis.com>
To: <z-machine@GMD.DE>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.gmd.de id NAA13784
Sender: owner-z-machine@GMD.DE
Precedence: bulk



> Unless you like dealing with about 4Mb of text solidly 
> concatenated together (that's how my email client likes to store 
> messages), I'd recommend waiting for the website :)

Well, there's no problem uploading that much data to the archive, and it
shouldn't take too long to write a little tool to break out the text into
a file per email.

David



From ???@??? Thu Aug 08 22:58:53 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 25 Jul 2002 08:59:42 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 25 Jul 2002 08:56:08 -0400
Subject: Re: [z-machine] hello; file length field in header
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
From: "Matthew T. Russotto" <mrussotto@speakeasy.net>
To: z-machine@GMD.DE
Content-Transfer-Encoding: 7bit
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E020A4B8@CORP03.corp.monis.com>
Message-Id: <E3327876-9FCD-11D6-92ED-0003938C3EE0@speakeasy.net>
X-Mailer: Apple Mail (2.482)
Sender: owner-z-machine@GMD.DE
Precedence: bulk


<x-flowed>

On Thursday, July 25, 2002, at 07:19  AM, David Kinder wrote:

>
>> Unless you like dealing with about 4Mb of text solidly
>> concatenated together (that's how my email client likes to store
>> messages), I'd recommend waiting for the website :)
>
> Well, there's no problem uploading that much data to the archive, and it
> shouldn't take too long to write a little tool to break out the text 
> into
> a file per email.

That's Unix 'mbox' format; there's probably plenty of tools already 
which can push, stamp, file, index, brief, debrief, and number it -- 
which makes it an almost ideal archive format.

I have archives myself, but only back to November 2001.




</x-flowed>
From ???@??? Thu Aug 08 22:58:53 2002
Return-path: <carlton@jackfruit.stanford.edu>
Delivery-date: Thu, 25 Jul 2002 12:21:00 -0400
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15680.9582.6405.120797@jackfruit.Stanford.EDU>
Date: Thu, 25 Jul 2002 09:21:02 -0700
To: Gavin Lambert <uzinf@mirality.co.nz>
Cc: <z-machine@GMD.DE>
Subject: RE: [z-machine] hello; file length field in header
In-Reply-To: <5.1.1.6.0.20020725224504.025fc710@mirality.co.nz>
References: <456ABFFB6AEC044CA3671F03F16055E020A4B7@CORP03.corp.monis.c
 om>
	<5.1.1.6.0.20020725224504.025fc710@mirality.co.nz>
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu


On Thu, 25 Jul 2002 22:49:45 +1200, Gavin Lambert
<uzinf@mirality.co.nz> said:

> Unless you like dealing with about 4Mb of text solidly concatenated
> together (that's how my email client likes to store messages), I'd
> recommend waiting for the website :)

I wouldn't worry about that: presumably your mailer saves this in a
standard format (Unix mbox format, or whatever), so we can use our
mailers to read it just as easily as you can use your mailer to read
it.

Which isn't to say that breaking it up and putting it on a web page
wouldn't be useful as well.

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       When you get your PH.D. will you get able to work at BURGER
       KING?



From ???@??? Thu Aug 08 22:58:53 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 25 Jul 2002 12:23:52 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15680.9473.371719.745967@jackfruit.Stanford.EDU>
Date: Thu, 25 Jul 2002 09:19:13 -0700
To: z-machine@GMD.DE
Cc: 
Subject: [z-machine] Re: hello; file length field in header
In-Reply-To: <15677.41802.840324.995961@jackfruit.Stanford.EDU>
References: <15677.41802.840324.995961@jackfruit.Stanford.EDU>
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


On Tue, 23 Jul 2002 11:41:14 -0700, david carlton
<carlton@math.Stanford.EDU> said:

> How much wiggle-room is there in the file length specified in the
> header?

I found a place where the standard addresses this; unfortunately, the
standard addresses it incorrectly.  Specifically, in the discussion of
the "verify" opcode, it says:

  The interpreter may stop calculating when the file length (as given
  in the header) is reached.  It is legal for the file to contain more
  bytes than this, but if so the extra bytes must all be 0, which
  would contribute nothing to the checksum anyway.  (Some story files
  are padded out to an exact number of virtual-memory pages using 0s.)

Inform may pad only using 0's, but Infocom games are certainly padded
in other ways.

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       PARDON me, am I speaking ENGLISH?



From ???@??? Thu Aug 08 22:58:53 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 25 Jul 2002 12:24:13 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15680.9582.6405.120797@jackfruit.Stanford.EDU>
Date: Thu, 25 Jul 2002 09:21:02 -0700
To: Gavin Lambert <uzinf@mirality.co.nz>
Cc: <z-machine@GMD.DE>
Subject: RE: [z-machine] hello; file length field in header
In-Reply-To: <5.1.1.6.0.20020725224504.025fc710@mirality.co.nz>
References: <456ABFFB6AEC044CA3671F03F16055E020A4B7@CORP03.corp.monis.c
 om>
	<5.1.1.6.0.20020725224504.025fc710@mirality.co.nz>
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


On Thu, 25 Jul 2002 22:49:45 +1200, Gavin Lambert
<uzinf@mirality.co.nz> said:

> Unless you like dealing with about 4Mb of text solidly concatenated
> together (that's how my email client likes to store messages), I'd
> recommend waiting for the website :)

I wouldn't worry about that: presumably your mailer saves this in a
standard format (Unix mbox format, or whatever), so we can use our
mailers to read it just as easily as you can use your mailer to read
it.

Which isn't to say that breaking it up and putting it on a web page
wouldn't be useful as well.

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       When you get your PH.D. will you get able to work at BURGER
       KING?



From ???@??? Thu Aug 08 22:58:53 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 25 Jul 2002 12:55:05 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 25 Jul 2002 19:51:00 +0300 (EET DST)
From: M Joonas Pihlaja <jpihlaja@cc.helsinki.fi>
To: <z-machine@GMD.DE>
Subject: RE: [z-machine] hello; file length field in header
In-Reply-To: <456ABFFB6AEC044CA3671F03F16055E020A4B8@CORP03.corp.monis.com>
Message-ID: <Pine.OSF.4.30.0207251942130.8345-100000@sirppi.helsinki.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-z-machine@GMD.DE
Precedence: bulk



On Thu, 25 Jul 2002, David Kinder wrote:

[> Gavin Lambert wrote: ]
> > Unless you like dealing with about 4Mb of text solidly
> > concatenated together (that's how my email client likes to store
> > messages), I'd recommend waiting for the website :)

Personally I'd prefer the raw archive for easy off-line grepping.

> Well, there's no problem uploading that much data to the
> archive, and it shouldn't take too long to write a little
> tool to break out the text into a file per email.

This is just the job for Unix's formail program.

Regards,

Joonas




From ???@??? Thu Aug 08 23:16:58 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Mon, 29 Jul 2002 16:29:28 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15685.42116.329028.318189@jackfruit.Stanford.EDU>
Date: Mon, 29 Jul 2002 13:24:36 -0700
To: z-machine@GMD.DE
Subject: [z-machine] more Z-Machine questions
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Here's my next batch of Z-Machine questions:

* Is there any particular reason that both jl and jg exist?  I would
  guess not, but perhaps there was no reason to get rid of one of them
  given that there's still room left in the 2OP table.

* In dec_chk and inc_chk, is the comparison signed or unsigned?  I'm
  guessing signed, since other comparisons are.

* In the 'jump' opcode, does the operand get added to the value of the
  PC at the start of the instruction, or to what the value of the PC
  would be after the end of the instruction?  I.e. if the operand is
  0, does jump become a loop or a no-op?  I'm guessing the latter, but
  that's just a guess.

Thanks.

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       ANN JILLIAN'S HAIR makes LONI ANDERSON'S HAIR look like RICARDO
       MONTALBAN'S HAIR!



From ???@??? Thu Aug 08 23:16:58 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 30 Jul 2002 03:55:41 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 30 Jul 2002 08:50:32 +0100
From: Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] more Z-Machine questions
Message-ID: <377a0c5e4b.kevin@bracey-griffith.freeserve.co.uk>
References: <15685.42116.329028.318189@jackfruit.Stanford.EDU>
In-Reply-To: <15685.42116.329028.318189@jackfruit.Stanford.EDU>
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.70) POPstar/2.03
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <15685.42116.329028.318189@jackfruit.Stanford.EDU>
          david carlton <carlton@math.stanford.edu> wrote:

> Here's my next batch of Z-Machine questions:
> 
> * Is there any particular reason that both jl and jg exist?  I would
>   guess not, but perhaps there was no reason to get rid of one of them
>   given that there's still room left in the 2OP table.

You'd have to ask Infocom :)  It does seem a little pointless, doesn't it?
 
> * In dec_chk and inc_chk, is the comparison signed or unsigned?  I'm
>   guessing signed, since other comparisons are.

Signed.

> * In the 'jump' opcode, does the operand get added to the value of the
>   PC at the start of the instruction, or to what the value of the PC
>   would be after the end of the instruction?  I.e. if the operand is
>   0, does jump become a loop or a no-op?  I'm guessing the latter, but
>   that's just a guess.

The new PC is "address after instruction + operand - 2". This is basically
the same as branches - see S4.7.2.

The interpreter advances the PC as it reads the instruction, so at the
point of "execution" the PC generally points after the last operand,, and at
the point of "branch" the PC points after the branch data.

Jump 0 would actually be rather useless, as you'd end up inside the
instruction. For branch, this has allowed a 0 offset to represent "rfalse",
but this is not specified for jump instructions.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/



From ???@??? Thu Aug 08 23:16:58 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 30 Jul 2002 12:25:28 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15686.48334.355913.558763@jackfruit.Stanford.EDU>
Date: Tue, 30 Jul 2002 09:20:30 -0700
To: Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk>
Cc: z-machine@GMD.DE
Subject: Re: [z-machine] more Z-Machine questions
In-Reply-To: <377a0c5e4b.kevin@bracey-griffith.freeserve.co.uk>
References: <15685.42116.329028.318189@jackfruit.Stanford.EDU>
	<377a0c5e4b.kevin@bracey-griffith.freeserve.co.uk>
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


On Tue, 30 Jul 2002 08:50:32 +0100, Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk> said:

> The new PC is "address after instruction + operand - 2". This is
> basically the same as branches - see S4.7.2.

Oh, gosh, good thing I asked: that's really not what the standard says
at all.  (The relevant text is "This is not a branch instruction and
the operand is a 2-byte signed offset to apply to the program
counter.")

> The interpreter advances the PC as it reads the instruction, so at
> the point of "execution" the PC generally points after the last
> operand, and at the point of "branch" the PC points after the branch
> data.

Yeah, that's what I figured.  I just didn't see anything in the
standard that made that explicit (though it might be somewhere I
missed), and I happen not to be implementing my interpreter that way.
I decided to not have the PC advanced at all until the instruction was
done executing: that way, if there's a bug in the code I'm
interpreting that triggers an error, it makes it easier to try to
recover semi-gracefully (print an error message and skip the offending
instruction).  Admittedly, such bugs are unlikely to occur while
decoding the instruction, but they could happen (e.g. an illegal local
variable reference or an argument of variable $00 while the stack is
empty).

Thanks for all the info.

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       INSIDE, I have the same personality disorder as LUCY RICARDO!!



From ???@??? Thu Aug 08 23:21:07 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Wed, 31 Jul 2002 19:52:41 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15688.30332.663444.366673@jackfruit.Stanford.EDU>
Date: Wed, 31 Jul 2002 16:45:00 -0700
To: z-machine@GMD.DE
Subject: [z-machine] z-machine questions, round 3
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


The next batch of questions:

* Do arguments always get decoded left-to-right?  In other words, if
  $00 occurs as more than one of the arguments of an opcode, is it
  specified which argument gets the top of the stack and which
  argument gets the next-to-top of the stack?

* Why does Quetzal, when saving the stack, save the arguments supplied
  to a given stack frame as a bunch of flags rather than as a number
  between 0 and 7?

Thanks,

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       I left my WALLET in the BATHROOM!!



From ???@??? Thu Aug 08 23:21:08 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Thu, 01 Aug 2002 03:03:39 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Thu, 01 Aug 2002 07:59:22 +0100
From: Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] z-machine questions, round 3
Message-ID: <46770f5f4b.kevin@bracey-griffith.freeserve.co.uk>
References: <15688.30332.663444.366673@jackfruit.Stanford.EDU>
In-Reply-To: <15688.30332.663444.366673@jackfruit.Stanford.EDU>
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.70) POPstar/2.03
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <15688.30332.663444.366673@jackfruit.Stanford.EDU>
          david carlton <carlton@math.stanford.edu> wrote:

> The next batch of questions:
> 
> * Do arguments always get decoded left-to-right?  In other words, if
>   $00 occurs as more than one of the arguments of an opcode, is it
>   specified which argument gets the top of the stack and which
>   argument gets the next-to-top of the stack?

Yes, it's handled left-to-right - first argument gets popped/pushed first.
This is frequently relyed on by existing code. As an aside, be aware of the
way that indirect references to the stack work - check the 1.1 draft for
details; it's not in the 1.0 standard.

> * Why does Quetzal, when saving the stack, save the arguments supplied
>   to a given stack frame as a bunch of flags rather than as a number
>   between 0 and 7?

Misunderstanding of the way VAR opcodes work, I suspect. Possibly considering
some future VM change that would allow certain operands to be omitted.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/



From ???@??? Thu Aug 08 23:27:12 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Fri, 02 Aug 2002 15:27:40 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15690.56143.887326.624419@jackfruit.Stanford.EDU>
Date: Fri, 2 Aug 2002 12:19:43 -0700
To: z-machine@GMD.DE
Subject: [z-machine] z-machine questions, round 4
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


Here's the next batch of questions:

* In scan_table, exactly what is the meaning of the "form" argument?
  The description says "bit 8 is set for words, clear for bytes; the
  rest contains the length of each field in the table.  Thus, $82 is
  the default."  Should that say bit 7 rather than bit 8?  And is the
  length always in bytes, even if bit 7/8 is set?  That's the only way
  I can get the example to make sense.

  Also, just to be anal: when the description of scan_table says
  "return the address/0" it means "store the address/0 in (result)",
  right?

* I wanted to double-check on the way that Quetzal requires
  catch/throw to be implemented.  If I'm not running V6 code and I do
  a catch within the first honest routine that was called (as opposed
  to the initial execution that starts at a certain address that isn't
  a routine), should the magic cookie be 2?  (Because there's the
  dummy frame plus the frame for the first routine.)

Thanks,
David Carlton
carlton@math.stanford.edu



From ???@??? Thu Aug 08 23:31:54 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Mon, 05 Aug 2002 15:20:49 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15694.52761.317537.671075@jackfruit.Stanford.EDU>
Date: Mon, 5 Aug 2002 12:12:25 -0700
To: Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk>
Cc: z-machine@GMD.DE
Subject: Re: [z-machine] z-machine questions, round 3
In-Reply-To: <46770f5f4b.kevin@bracey-griffith.freeserve.co.uk>
References: <15688.30332.663444.366673@jackfruit.Stanford.EDU>
	<46770f5f4b.kevin@bracey-griffith.freeserve.co.uk>
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


On Thu, 01 Aug 2002 07:59:22 +0100, Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk> said:
> In message <15688.30332.663444.366673@jackfruit.Stanford.EDU>
>           david carlton <carlton@math.stanford.edu> wrote:

>> The next batch of questions:
>> 
>> * Do arguments always get decoded left-to-right?  In other words, if
>> $00 occurs as more than one of the arguments of an opcode, is it
>> specified which argument gets the top of the stack and which
>> argument gets the next-to-top of the stack?

> Yes, it's handled left-to-right - first argument gets popped/pushed
> first.  This is frequently relyed on by existing code.

Maybe this is the answer to my earlier question about why both jl and
jg exist; after all, comparing the top two elements of the stack to
see which is larger seems like it might be a frequent operation, and
"jl $00 $00 ?(label)" and "jg $00 $00 ?(label)" are different.
(Whereas "jl $00 $01 ?(label)" and "jg $01 $00 ?(label)" aren't.)

David Carlton              |  <http://math.stanford.edu/~carlton/>
carlton@math.stanford.edu  |  Go books: <http://www.gobooks.info/>

       I just heard the SEVENTIES were over!!  And I was just getting
       in touch with my LEISURE SUIT!!



From ???@??? Thu Aug 08 23:31:54 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 06 Aug 2002 15:17:12 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
Date: Tue, 06 Aug 2002 20:11:36 +0100
From: Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk>
To: z-machine@GMD.DE
Subject: Re: [z-machine] z-machine questions, round 4
Message-ID: <01afe5614b.kevin@bracey-griffith.freeserve.co.uk>
References: <15690.56143.887326.624419@jackfruit.Stanford.EDU>
In-Reply-To: <15690.56143.887326.624419@jackfruit.Stanford.EDU>
User-Agent: Messenger-Pro/2.50a (MsgServe/1.50) (RISC-OS/3.70) POPstar/2.03
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-z-machine@GMD.DE
Precedence: bulk


In message <15690.56143.887326.624419@jackfruit.Stanford.EDU>
          david carlton <carlton@math.stanford.edu> wrote:

> Here's the next batch of questions:

Sorry to be unhelpful, but I really can't remember the answers to these two.
Might I suggest browsing the source code of either my own Zip 2000, or
Frotz 2002? They should give you the answer to many of your questions.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/



From ???@??? Thu Aug 08 23:31:54 2002
Return-path: <z-machine-owner@mail.gmd.de>
Delivery-date: Tue, 06 Aug 2002 16:55:23 -0400
X-Authentication-Warning: postix.gmd.de: majord set sender to owner-z-machine@gmd.de using -f
From: david carlton <carlton@math.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15696.13891.765530.961359@jackfruit.Stanford.EDU>
Date: Tue, 6 Aug 2002 13:49:07 -0700
To: Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk>
Cc: z-machine@GMD.DE
Subject: Re: [z-machine] z-machine questions, round 4
In-Reply-To: <01afe5614b.kevin@bracey-griffith.freeserve.co.uk>
References: <15690.56143.887326.624419@jackfruit.Stanford.EDU>
	<01afe5614b.kevin@bracey-griffith.freeserve.co.uk>
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Cc: carlton@math.stanford.edu
Sender: owner-z-machine@GMD.DE
Precedence: bulk


On Tue, 06 Aug 2002 20:11:36 +0100, Kevin Bracey <kevin@bracey-griffith.freeserve.co.uk> said:

> Might I suggest browsing the source code of either my own Zip 2000,
> or Frotz 2002? They should give you the answer to many of your
> questions.

Okay, that's what I'll do.  And maybe I'll keep notes for what I had
questions about, on the theory that, if another draft of Standard 1.1
gets produced, it might be nice to know what some of the
mistakes/unspecified aspects/confusing aspects of Standard 1.0 are
that aren't already fixed in 1.1.  (Or just to help the next person
who decides to write a Z-Machine interpreter.)

David Carlton
carlton@math.stanford.edu