Due to my recent work on restoring a way to release divided story files using Infocom’s late Atari 8-bit multidisk interpreter (ref. https://intfiction.org/t/puddle-buildtools-for-punyinform-releases/51322/31?u=8bit_era) I see at least two things that should be fixed in a future version of the standards document. And generally I’d like to share my observations to whom it may concern.
-
In the header format (page 70), Hex 1 is correctly acknowledging that it is used for flags. For 2: Story file split across two discs? the question mark may be deleted. The value has to be 4 for correctly setting it.
-
In the remarks section, a reference to Stefan Jokisch is made.
In the Infocom period, the larger Version 3 story files would not entirely fit on a single Atari 800 disc (though they would fit on a single Apple II, or a single PC disc). Atari versions were therefore made which were identical to the normal ones except for having Flags 1 bit 2 set, and were divided into the resident part on one disc and the rest on another. (This discovery was announced by Stefan Jokisch on 26 August 1997 and sees the end of one of the very few Z-machine mysteries left when Standard 1.0 was first published.)
The first part is correct (having flags 1 bit 2 set, even though the flag’s integer value is not mentioned), the second part: …were divided into the resident part on one disc and the rest on another needs improvement. I took this as given when I was trying to make the late Atari 8-bit interpreter work. So the first version of my tool read the highmem address from the header and then correctly split the story on said offset, so that the resident memory resides together with the interpreter on one disk and the high memory resides on disk 2. This notably does not work as Infocom’s Atari two disk interpreter expects the highmem to start at 8FFF + 1.
So instead you take the story file, patch the “end of resident memory marker”, or whatever you may call it, which is byte 4 and 5 in the story’s Z-machine header to 8FFF and then split the file exactly at this offset.
My guess is that Infocom’s compiler had an option to target Atari 8-bit and prepare the file as expected.
I actually got on the right track when diffing the Plundered Hearts Atari story file I extracted from the Atari 8-bit disk image with the regular one. The end of residend memory marker in the regular one is completely different. The story file though is the same. When I go to the address where the high mem begins in the regular story file, I see it is identical to the content of the Atari 8-bit file. So Infocom only pushed the address of the “end of resident memory marker” to 8FFF and then intentionally split the story at this offset. It kinda makes sense usage wise. The regular Atari 8-bit disk may hold 92k (the bigger 130k disks were introduced later). The offset 8FFF in bytes is roughly 36k. A version 3 story file may be 128k. Now subtract 128k with 36k and there you have your 92k. I think the idea behind this is also minimizing the times the user needs to swap a disk. Actually I seem to be able to play without swapping once the game is loaded, which makes sense on a constrained environment.
Note this is much copy/paste of what I already said on the PunyInform Discord server and I am no expert for the Z-machine, so please excuse if some of my wording may differ from common wording in the Z-machine standard, I just wanted to share this for those that may find my observations useful.
PS: Yes, all Infocom releases using the late / two disk interpreter set byte 4 & 5 to 8FFF and also set byte 1 bit 2 to integer value 4.
