Infocom released a number of it’s interactive fiction titles for the Color Computer in the 1980s, just as it did for most computers of the era. The versions released for the CoCo targeted the standard 32 column text screen of course. With it’s limited text display (32×16) and no true lowercase, the standard CoCo1/2 screen is really less than ideal for interactive fiction like Zork.
With the addition of a 64 column alphanumeric mode to the CoCoVGA project, it occurred to me that this mode would be great for the Infocom adventures. So I set out to see what could be done. Source code not being available at the time, my plan was to disassemble an existing interpreter, and modify it.
In doing this, I learned quite a bit about how the Infocom games work. I’ll share here some of what I discovered.
The software for an Infocom adventure consists of two parts; the interpreter, and the ‘Z-machine’ or ‘story file’. The z-machine itself is essentially a snapshot of the memory contents of a virtual machine (computer). The interpreter executes z-machine instructions and implements them on the host machine, while also managing virtual memory, and providing I/O for the virtual machine.
In this way, Infocom was able to easily port their games to any platform, by simply writing a new interpreter. The z-machine itself being the same from system to system.
The virtual machine’s memory map consists of three major parts; Dynamic Memory, Static Memory, and High Memory. Dynamic memory contains things such as game objects/information and global variables, and may be read from and written to by the virtual machine. Static memory contains the dictionary and various language tables, and may only be read. High memory contains the virtual machine’s executable code, the ‘Z-Code”.
Dynamic and static memory are loaded into host ram on startup, and remain there. The beginning portion of high memory (the executable z-code), is loaded into host ram at startup, and additional blocks of high memory are swapped in as called for during execution.
The z-code is made up of instructions and operands for the virtual machine. The interpreter executes this code, implementing the needed functions on whatever the host system happens to be.
On the CoCo interpreter I worked on at least, the virtual memory system uses 256 byte pages. These are tracked through a table by the interpreter so they can be loaded into CoCo memory from disk and referred to as called for by the z-code being executed.
After learning enough about the interpreter and how it operates I was able to adjust things to make room for a larger video page, and alter the screen handling routines to make use of the CoCoVGA’s 64×32 W64 mode. I also discovered that the z-machine files themselves handle lowercase. The CoCo interpreters have additional code that converts everything to caps for the 32×16 alpha screen, since most CoCos do not do lowercase. I also circumvented that conversion in order to display in lowercase on the CoCoVGA since it has that capability.
Infocom adventures on the CoCoVGA 64 col mode!
Once I had completed the CoCoVGA versions, I realized it would be simple at that point to alter the code to make a 64 column version for the CoCo3. So I did that as well. I whipped up some boot track loaders to go along with the interpreter/z-machine packages and made .DSK images which can now be found on the Color Computer archive.
And on the CoCo3 in 64 columns!
Check them out if you’re a CoCo Infocom fan!
Please note that I left the original disk I/O routines intact, so if running on the CoCo SDC, you’ll need to switch to the stock Disk BASIC in bank 1 after mounting the .DSK image for it to run properly.