PDP8 and Z-machine engine
ethan.dicks at gmail.com
Sat Sep 2 17:43:09 CDT 2006
On 9/3/06, Gordon JC Pearce <gordon at gjcp.net> wrote:
> > With the comment about the south pole, on the heating budget for
> > the clock, I found out for some reasion penguincentral.com
> > is down.
Yes. My hosting provider of 10 years, Colossus, vanished without
a trace about a week ago. I'm still working on options to bring
it back up.
> > I was looking for SBC-1620 software and was hopeing to find
> > more about the adventure port.
I only have a couple of photos of my SBC-6120, and as for
software that runs on the Z-machine, I had a couple of tutorials,
and my port of Zork, not Adventure.
>> Could a older Z-machine engine be ported to the loveable 8?
Can? I think so, with some possible pitfalls.
> Interesting. Looking (very quickly) at the Z-machine spec, it seems
> fairly simple.
In principle, I don't see how implementing a v3 Z-machine (128Kbyte
max game file) is beyond the capabilities of a PDP-8. I do think that
unless one were to require a KT8A and at least 64K words (out of
a max possible 128K words), a v5 Z-machine is out of the question
(ZDungeon is a z5 file, FWIW).
The smallest machine I am aware of with a v5 Z-machine is the
Commodore 64. There are several implementations of a v3
Z-machine on 8-bit machines with 32K-48K (Apple II+, TRS-80,
and recently, the Elf 2000 (1802 w/32K RAM and ElfOS).
The fundamental limitation is available RAM after storing the
Z-machine (4Kbytes to 8Kbytes in machine code) and the
"impure storage". On small machines, Infocom and others
implemented a demand-paged virtual memory scheme for the
bulk of the game - all the code fragments and text fragments
are swapped in as needed. The variables and objects are
dynamic, so they were loaded from disk once then held in
memory throughout play. When saving the game, all the
Z-machine has to do is write out the impure area to disk.
While helping Mike Riley (author of ElfOS) debug "ZRUN".
we discovered that with a v3 game and a 32Kbyte machine,
after you subtract a few K for resident OS overhead and a
few more K for the Z-machine, and many K for impure
storage, there was on the order of 2K free for swapping out
the fixed bits of the game. With 512 bytes per disk block,
that worked out to, I think, 3 game pages at a time. There
was _not_ enough free RAM to hold the larger impure
storage area of a v5 game, so we came up with a banked
memory expansion scheme (to 512Kb with one SRAM
chip) that would allow it, but it's obviously not a popular
enough design to catch on to a wide enough audience to
make the effort of writing a v5 Z-machine more than a
If one were to implement a true VM scheme where both
pure and impure pages could be read and/or written, then
32K is no longer the boundary it once was, but performance
would suffer terribly. Back in the day, on a C-64, it was many
seconds between typing a command and getting a response.
On machines with a faster disk implementation, the Apple II+,
say, it was still a few seconds between prompts. If one were
to add in the necessity to write and keep track of impure
pages as well, it would be a long wait. Infocom abandoned
machines as "small" as the C-64 for later games in favor of
the larger and newer machines of the day (Amiga, Mac, PC).
An easy choice, in part, because these larger machines could
hold an entire 256K max game file in memory, simplifying
the internals of the Z-machine and leading to greatly improved
As for a v3 Z-machine (that could run the Zork trilogy, Planetfall,
Starcross, and many other titles), the hardest thing I can envision
would be the constant battle of trying to implement a 16-bit
virtual machine on a 12-bit real machine. The pointers in the
game code to text and code fragments are 16-bits (that are
then extended to 17-bits inside the Z-machine to find the "real"
location in the file) and the 256 variables are 16-bit, so you'd
have to deal with a lot of 24-bit items to keep track of the
elements of the game. Not impossible, but does take a bit of
code to do it. The actual opcodes themselves are quite straight
foward, even if they typically operate on 16-bit quantities.
There are other examples (like dealing with object properties),
that make one decide between storage efficiency and code
efficiency (v3 objects are 32 settable attribute bits plus three
bytes for parent/sibling/child entries, plus variable amounts
of "properties", on the order of a few bytes each) - all very
> This gives me a good excuse to start on my PDP-8
> emulator again
I'd recommend going with an established (and debugged) emulator.
If there's something that simh won't do for you, that's another matter,
but it does run OS/8 very well.
> - at least that way if I need more core, I just need to
> change a #define instead of starting a big long thread about
> semiconductor memory ;-)
Well... up to 32Kwords that's fine, but above that, you have to
implement the KT8A memory management board that allows
up to 128Kwords. More than a simple #define.
More information about the cctech