On 5/9/05, Christian Corti <cc at corti-net.de> wrote:
On Sun, 8 May 2005, Ethan Dicks wrote:
One of the events in the timeline mentions a ZIP
(Zork Implementaton
Program - the game engine) for the DECmate...
Porting a Z-Code interpreter to a new machine is a nice exercise. In my
case I ported the Infocom interpreter from the InfoTaskforce (written in
C) to the IBM 5110
Nice. I don't have a 5110, or I'd want it.
I have a work in progress of porting a v3 interpreter to the PET, but
I just haven't gotten around to finishing it. It starts up and
displays text, but depending on the game, accepts input to one degree
or another. I'm fairly certain I'm stepping on some zero page
variable that I shouldn't be, and it's also being used by the kernel
for CHARIN/CHROUT stuff (I/O to disk and the screen). This same
program does work with the VIC-20 (as tested under VICE with 24K of
RAM), but the screen size there makes it hard to play a game.
Obviously, the nature of the 6502 makes writing an interpreter
feasible (since Infocom directly supported the C-64, Apple II, and the
Atari). Pretty much any 1MHz micro that has at least 32K of usable
storage (48K or 64K is better) and a disk system with random block
access (for the demand-paged virtual memory scheme used to keep only
as much of the game in memory as needed at the moment) that is large
enough to hold the game file (80-something K in the case of Zork I) is
all that's required. The limiting factor in playing the game is disk
speed, not CPU speed. With more memory, the game spends more time
playing out of RAM than paging off the disk, but even a 32K machine
should have enough to hold the varable store, the interpreter, and
enough of the paged store to contain the parser and the present room
code.
Mapping all of this onto the PDP-8, however, is somewhat
problematic... the Z-machine, the foundation of Infocom's success in
the days of competing micro architectures, is a byte-oriented virtual
machine with 16-bit (stored) pointers (depending on the interpreter
that can be expanded to 17 or 18 bits like BCPLs BPTRs). I have often
mused over the years how best to map that virtual machine onto the
PDP-8, with no real progress. With large 16-bit and 32-bit host
platforms (Amiga, Mac, UNIX, VMS, PC...), it is not necessary to
implement a virtual memory scheme. With the PDP-8 and its own
page-oriented memory system, it's certainly necessary, and doubly
difficult. At least in the case of a 6502, the virtual memory
routines simply hit a page boundary, pull in the next 256 bytes of the
game to some available hole, and map the upper 8 bits of the Zpointers
in software.