[z-machine] Blorb extension proposal

[Cedric Knight]

I'd quite like to build a blorbifier into the next release of the
Inform compiler.  One advantage of this is that it would make it
easier to compile multimedia files in a single step, by using
directives such as
    Link SND_humming "sounds/hum.aiff";
    Link PICT_squid "~informer/gimp/squid.jpeg" >= 1/2; ! include
minimum scaling
and then use those constants later on.  I wonder if it's OK with L.
Ross Raszewski to use his filetype-autodetection code from iblorb.

The other advantage is that Graham was interested in adding
bibliographic data such as title and author consistently to Z-machine
and Glulx files.  The inform-maintenance list looked at the TADS key
pairs (http://www.tads.org/howto/gameinfo.htm) and liked it, although
there was also some thought given to XML
(http://www.logicalshift.co.uk/etc/IF_XML_metadata.pdf).

Blorb was originally discussed on the Z-machine list, and 'needs an
update anyway'.  At the moment there is an AUTH[OR] chunk, and a '(C)
' and 'ANNO' chunk.  We could wither add a subset of the TADS tags* to
the ANNO chunk, or give it a new name like BIBL.  AUTH and RelN would
have the same meaning as before, although they could be duplicated
within the bibliographic chunk.

*I'd suggest Name (=Title), Desc, Version (Serial number), Language,
LicenceType, CopyingRules; also maybe add SeriesTitle, SeriesNumber,
OriginalAuthor, original Date.

Now I see two problems:
(a) Most z-code interpreters currently can't cope with the ZCOD chunk
being inside a Blorb file, and making versions available without
annotation kind of defeats the purpose;
(b) It's useful to be able to distinguish Blorb files containing Zcode
from Blorb files containing Glulx or nothing by means of a single
3-character extension.  Or it is on Windows anyway.

What I'd like to suggest is that as well as being able to distribute a
Zcode file and a Blorb file, or a Blorb file including a Zcode chunk,
there should be an addition to the Blorb spec that allows a Blorb file
to be tacked on after the code.  This could look like:

Area read by terp:
  Z machine header
  Rest of Z-machine story file, padded up to 0.5K boundary.
X: Beginning of Blorbed resources
  12-byte IFF header (FORM, length, IFRS)
  Resource index 'RIdx' chunk**
  Other chunks
File footer
  4-byte XOR checksum of Blorb file
  4-byte length of Blorb file (so X=length of file -12 -this number)
  4-byte marker value ('BiLB'?)
End of file
**(note that file locations in the Ridx chunk would be relative to
point X, as in the current spec)

This would allow easy 'jukebox' editing of metadata, and existing
interpreters would be able to play the file as normal.

Comments welcome.

CK