So I had some free time this weekend and decided to work on DrupalZM a bit.

A Little About the Machine

The Z-machine is an interesting virtual machine. Unlike the average system architecture, the Z-machine has no registers in the typical sense, and keeps a separate stack from main memory. It can store local variables on its stack that can be used for the current call, and global variables in memory that can be used across calls. It has opcodes for the typical operations like math, boolean logic, calling, jumping, comparing, etc, but it also has text adventure specific opcodes, like an opcode for looking up game objects and their properties (e.g. is the mailbox open, whats the name of this room, is the light on or off, etc), opcodes for looking up dictionary and lexical data for parsing, and high level opcodes like print to the screen, save, restart, etc.

Additionally, the total size of an opcode and operands can vary in length (since there are no registers, the opcodes allow you to assign results to many different locations from the stack to memory), and sometimes can be followed by high level data like a string of characters. It’s an interesting quasi-mix of typical low level processor functionality and high level operations. It’s actually pretty cool, and a bit of a challenge (I think) to program.

For those who wish to see technical specification in its full glory, you can check it out here.

Progress So Far

So that being said, I’ve set out on the long road. So far, I’ve accomplished the following:

1. Created a Drupal module that installs the custom content type “z-machine”, that allows z-machine nodes to be added (basically a description of the game and the file it points to). This will allow Drupal site admins to easily add new stories to their website.
2. Memory, Stack, and PC storage per user per z-machine, which means that a user’s progress will be saved at all times in any game he/she is playing. Saving and Restoring will still be available if desired of course, but there will be no need to save when done playing.
3. When a user goes to a z-machine page, code will execute that will either read the machine from the appropriate file, or use the user’s memory if its available (i.e. they’ve played before).
4. All opcode types except extended opcodes are processed and directed, in all forms. So this includes 0OP, 1OP, 2OPs, and VARs, in their Long, Short, and variable forms
5. Storage and branching is fully supported for all opcodes. Return values will be stored in their correct location (Stack, local variables, global variables), and instructions that require a branch will do so to the correct address, both in their positive and negative forms (if true/if false).
6. The stack is fully implemented, both in normal pushes and pops, as well as storing call information such as next PC, local variables, and return variable. Upon a return call, the z-machine will correctly clean the stack up and set the PC correctly
7. About 20 opcodes (which means 40-60 or so with their different forms) have been implemented so far
8. A full zcharacter <-> zscii <-> asciii conversion system has been implemented with abbreviation table lookup
9. Basic object and property handling has been implemented
10. For what’s been done so far, it fully supports versions 1-3 and some support 4-5, and little support for 6-8.

I’ve made quite a bit of progress, but there is still a tonnn to go. But it’s a lot of fun. The machine can execute about 150 instructions before dying from an unknown opcode. But, in those 150 instructions, I’m already seeing text on the webbrowser! Here’s a small excerpt:

Instruction:178 print: ZORK I: The Great Underground Empire
Copyright (c) 1981, 1982, 1983 Infocom, Inc.
Instruction:178 print: All rights reserved.
Instruction:187 print:

Instruction:16
loadbstack push
Instruction:73
andstack push
Instruction:160
Instruction:178 print: ZORK is a registered trademark of Infocom, Inc.

Pretty exciting! More to come…