Zoom is a Z-Machine, which means that it plays text adventure games written in ZCode. The original games were written by a company called 'Infocom' in the 80's: these are available on the Infocom Masterpieces CD, published by Activision. Unfortunately, Activision seems to have lost interest in this title - however, there are a few companies that have a stock of this CD (I bought mine from here). In around 1993, a compiler called 'Inform' was released that allowed ordinary mortals to create their own ZCode adventures. This sparked quite a revival, and there are many games available for download here. Inform itself has a homepage here
Those of you who already knew all that will probably be wondering why I've gone to all the trouble of writing a new ZCode interpreter from scratch. The answer is that I was experimenting with a optimisation technique called 'specialisation' (a specialised program is one with reduced, or no, static data to interpret). The Z-Machine looked like it would specialise well, so I chose that to experiment with. I finished the thing off because it almost worked first time (the very first executable build managed to display the Zork I start-up message), and because I wanted an interpreter that could do a decent job of displaying adventures under Linux.
The version presented here is known to work with version 3, 4, 5, 6, 7 and 8 story files. It is designed to run under X-windows on a vaguely POSIX-ish Unix, or under Mac OS X although porting the display library to other systems should be possible (there is a Windows port, but it hasn't been maintained in a while. The work to restore it to functionality should be minimal for all but v6 games)
Oh, you want to know the effect of specialisation on the interpreter? Well, it runs at around 50% faster than frotz (and it performs more bounds checking than frotz does), but the cost of this is an executable that is around 5x the size. If your compiler is particularily bad at optimising switch statements (gcc is pretty good at this), you may find that zoom runs slower (this is because most of the inner loop is automatically generated by a utility, and consists of a couple of switch statements that test for all possible varieties of bytecode, and their arguments). Zoom compiled without optimisation is still faster than Frotz compiled with optimisation.
No doubt you've been patiently scrolling though this page looking for the stuff, so here it is: