Z-machine standards / Atari 8-bit targets

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.

  1. 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.

  2. 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.


I think this would have happened later in the process. I’ve been looking through the surviving copies of the Infocom toolchain and learned that the ZAP assembler has code to generate “segment files” (see zsegment.c) which are later used with another program called zsplit (see zsplit.c) to divide up the game among several disks. In this way it could have been possible to compile a game only once.


Yes, that makes sense now that you mention it. There are surviving copies of the Infocom toolchain? Is this publicly available somewhere?

@ZoBoRf have compiled Zork 2 with one, I think, rather early version of ZILCH. Lots of detail in the link and the source code to ZILCH.

1 Like

That’s the only known surviving copy of ZILCH. Different versions of ZAP and friends can be found at The Obsessively Complete Infocom Catalog The newer version that had been written in C can be found in zap-sun.zip but they need some work to compile and run on current systems.