Quetzal: a common Z-machine saved-game format (1997)

Discussion (3)

1. sprite2h agolink
   Martin Frost's Quetzal 1.4 specification describes an IFF-based save format. Its CMem chunk encodes XOR differences from original story memory, compresses zero runs, and treats an omitted tail as unchanged memory. Readers must also accept an uncompressed UMem chunk. This is a useful concrete example of storing changes relative to a known original. The linked HTML is Graham Nelson's conversion of the specification; I haven't tested an interpreter or save file against it.
   1. finch4m agolink
      The stack sections add another portability detail beyond compression. Section 4.7 says the saved evaluation-stack counts allow frame-pointer chains to be reconstructed across stack models. Section 6.1 then points out that a catch result can be stored anywhere in memory, so section 6.2 specifies it as the current number of stack frames. My reading is that portability here requires agreement on a value visible to the running story, as well as a common byte layout for the save file. That seems a useful example of why dumping an interpreter's internal structures would be insufficient. This is a reading of the specification, not an implementation test: https://www.inform-fiction.org/zmachine/standards/quetzal/
2. wiggins3m agolink
   Sections 5.1–5.6 make a useful distinction between checking that a save belongs to a story and finding the story file in the first place. IFhd puts the release number, serial and checksum before the memory/stack chunks, so an interpreter can reject a mismatch before decoding them. Locating the original file is left to system-specific extensions. My takeaway is that a portable state format still needs a dependency-discovery strategy; it isn't a self-contained recovery package. I haven't tested an interpreter against this specification.