Building Infocom Disk Images for CoCo

In the previous posts in this series, I have discussed pairing original Infocom Z interpreter software with new Z code story files in order to enable new interactive fiction games to run on the CoCo. In this post, I intend to tie-up some loose ends and to detail the actual process involved.

Image Issues

The outcome of this whole process will be to build a diskette image. The resulting image can be used as-is in MAME or another emulator, it can be loaded on a real CoCo with a CoCoSDC device or using DriveWire, or it can be used to write an actual physical diskette. Choosing and following the appropriate process for any of the above will be left as an exercise or the reader.

This post will focus on producing what is known as a "JVC" diskette image. In its simplest form, this format is merely a sequential arrangement of sector data arranged sequentially by track, yielding a 161280 byte file representing a single-sided disk with 35 tracks, 18 sectors per track, and 256 bytes per sector. This simple, sequential data layout makes reading and writing specific track data by offset into the disk image very simple.

Filesystem Concerns

The Disk Extended Color BASIC (DECB) code on the CoCo reserves track 17 of the disk for storing the disk's directory. Depending on how a disk is used (i.e. how programs are started), a valid directory may not be required. However, at least some versions of the Infocom Z interpreter rely on being loaded via LOADM and therefore require a valid directory to be present on track 17 of the disk image.

Many CoCo games (including some versions of the Infocom Z interpreter) depend on being started by the DOS command in DECB. The DOS command loads data from track 34 of the disk into a fixed location in memory, checks for a simple signature at the head of that data, and then jumps into the loaded program if the proper signature is found. Care must be taken to preserve the contents of track 34 if use of the DOS command is required to start the game.

Interpreter Differences

I loaded each of the Infocom games from the disk images at the Color Computer Archive. After starting each game, I issued the $VERSION command in order to collect version information from each interpreter. As shown in the table below, at least three interpreter versions were shown to be used by Infocom to package their games for the CoCo!

Result of $VERSION Command by Game

Game	Version
Ballyhoo	COCO VERSION D
Cutthroats	COCO 2 VERSION C
Deadline	COCO 2 VERSION C
Enchanter, The	COCO VERSION D
Hitchhiker's Guide to the Galaxy	COCO 2 VERSION C
Infidel	COCO 2 VERSION C
Lurking Horror, The	COCO 2 VERSION C
Planetfall	COCO 2 VERSION C
Sea Stalker	VERSION A
Sorcerer	VERSION A
Spellbreaker	COCO 2 VERSION C
StarCross	COCO 2 VERSION C
Stationfall	COCO 2 VERSION C
Suspect	VERSION A
Suspended	VERSION A
Wishbringer	COCO 2 VERSION C
Witness, The	COCO VERSION D
Zork I	COCO 2 VERSION C
Zork II	COCO 2 VERSION C
Zork III	COCO 2 VERSION C

Oddly enough, no interpreter found reported anything like "VERSION B". Was a version "B" ever released? What about a version "E" or other later version? Also, if we relate the alphabetical version order to the original release dates of the games above, the release order of the games does not seem to match the version order for the CoCo Z machine interpreters. Were the CoCo versions released in a different order than the original game release order? Or perhaps the diskettes imaged on the Color Computer Archive were purchased in random order over a period of time, while the diskettes sold were sent with whatever version of the CoCo Z machine interpreter was current at the time?

If you have an original Infocom game disk for the CoCo, please boot it up and issue the "$VERSION" command. If you get different results than shown in the table above, then _PLEASE_ let me know in the comments below or however else you may know to reach me!

Given the above, a decision must be made as to which interpreter version to use. The "VERSION A" interpreters are not started via the DOS command, but instead require either the standard "LOADM : EXEC" combo or a BASIC program to do the same. My personal preference for starting via the DOS command and my (baseless?) presumption that higher versions are later and hopefully better (i.e. more features and fewer bugs) causes me to select to use the "COCO VERSION D" interpreter taken from the Ballyhoo disk image.

Command Performance

Starting here, I will presume that you have a "version 3" Z machine story file available called "newgame.z3" and an image of the original Infocom Ballyhoo diskette called "ballyhoo.dsk". So, let's start by using the Toolshed decb command to create a clean disk image called "newgame.dsk":

rm -f newgame.dsk
decb dskini newgame.dsk

Next, copy the Z machine interpreter from Ballyhoo to the new disk image. This is done by copying the first 9216 bytes (i.e. two tracks, eighteen 256-byte sectors each) from one disk image to the other:

dd if=ballyhoo.dsk of=newgame.dsk conv=notrunc bs=1 count=9216

While pillaging the Ballyhoo image, also copy over the boot track code. This is done by copying the contents of track 34 (at byte offset 156672) from one disk image to the other. The size could be as much as an entire track (4608 bytes):

dd if=ballyhoo.dsk of=newgame.dsk conv=notrunc bs=1 \
     count=4608 skip=156672 seek=156672

The final missing piece is the new story file. But there is a problem. While there are now 142848 unused bytes on the new disk image, track 17 (i.e. the directory track) is roughly in the middle of the unused space. So, any story file above a certain size (i.e. exactly 64512 bytes) will need to be written to the disk image in two parts. Given that, two commands are needed to write a large story file:

dd if=newgame.z3 of=newgame.dsk conv=notrunc bs=1 \
     seek=9216 count=64512

dd if=newgame.z3 of=newgame.dsk conv=notrunc bs=1 \
     skip=64512 seek=82944

Mischief Managed

Well, that's about it. The directory track remains empty -- enterprising hacker's could copy the directory track from the original Ballyhoo disk, enabling users to see a LOADM'able BIN file for the game (in case they don't have the DOS command available). Or, the directory track could be modified to show other messages as desired by the hacker. Such directory modifications will also be left as an exercise for the reader.

Beyond that, there remains a moral issue -- technically, doing the project as described amounts to software piracy. While I doubt that any Infocom lawyers will come knocking on your door, those who feel strongly about the issue may have objections to "borrowing" the Infocom code in this way (or at all). You'll have to resolve that issue for yourself, of course. But if nothing else, this is a fun way to consume exising Interactive Fiction on the CoCo!

Writing a new Z machine interpreter from scratch is not an unreasonable task, even for an old machine like the CoCo. Maybe if some people start consuming Inform content as described above, that will encourage someone to write a more modern Z machine interpreter for the CoCo? Then we could all be happy and our consciences could be free. Who is up for the challenge? Let me know! I'll stay tuned...