Quick question;
From the Frotz source code, there’s a z_save op. Sometimes it has a bunch of args, sometimes not. Without the args, it proceeds to save with quetzal, otherwise it does its own thing. Which appears to dump a region of game image into a file.
When, and under what circumstances, does it do the latter?
For example, is this a game build option, or is it a historical version thing, or how does it work?
Thanks.
See the Z-spec for @save.
The extension also has (optional) parameters, which save a region of the save area, whose address and length are in bytes […]
It’s a way of adding external file support to the Z-machine without a separate opcode. If the @save opcode is called with no parameters, it asks the user for a filename, then dumps the game state to that file. If it’s called with parameters, it dumps a region of memory to a specified file. Same for @restore. So you can think of those opcodes as @write_file and @read_file if you want.
In theory this would be helpful for saving certain variables across restores and restarts. In practice, it’s a rarely-used feature, so interpreter support isn’t widespread, so authors don’t really use it, and it’s a chicken-and-egg problem.
(Though I believe Parchment now supports it as of last year?)
Ok thanks. I was thinking it was an alternative, but standard, way to save games. But actually, it’s for extra saving.
Out of curiosity, the Quetzal file appears to be essentially a binary diff of the current memory state and the original. But the save routine has to re-load the original game file in order to make the comparison.
Did this work like this originally? Let’s say i have a single floppy disk drive. Am i expected to make saves onto the same disk. And presumably, the game file could take a lot of space and therefore limit saves considerably.
The game file must be loaded anyway as the save file does not contain the entire story, only the dynamic portion of memory.
Thanks for your answer. You’re saying it really does have to have saves & loads on the same floppy disk as the story file. This just seems crazy.
It varied by system, but the Zork I manual says that you’d need a separate blank disk for saved games. I don’t know if/how they encoded the saves or if it was really just a straight RAM dump.
Yes. I’ve just discovered that Quetzal and therefore the binary diff method was not original (unless I’m wrong) and the original Infocom interpreters didn’t use this method.
If true, it makes a lot of sense. Reloading the story file is trivial on a modern machine. But would not have been in the 80s.
Yeah, the point of Quetzal is that save files can be moved between interpreters, which wasn’t really a concern for Infocom—users weren’t expected to know what an “interpreter” was, it was purely a tool to make development easier.
Infocom used a straight RAM dump as far as I know.
Quetzal was invented during the Usenet era, when minimizing file size was still important but worrying about 140kb floppy disks was not.
Parchment uses Bocfel now, but needs a little bit more work to support data files.
Thanks everyone for the clarification. This all makes complete sense now. Infocom either dumped the dynamic section as-is, or maybe some simple compression.
It’s maybe worth pointing out that on a lot of the machines that ran the original Infocom software, the capacity of a blank floppy disk is twice the amount of RAM in the machine or more. A Commodore 64 had 64K of RAM but its (optional) disk drives stored 170K.