New subject: PDP-8 Z-machine

8 Feb 2012

On 2012-02-08 01.37, Ethan Dicks<ethan.dicks at gmail.com> wrote:
...

 On Tue, Feb 7, 2012 at 12:51 AM, Cameron Kaiser<spectre at floodgap.com>  wrote:
 > >>  ?I've been trying to figure out
if the PDP-8 could handle C, and
> >>  the answers I get range from "I don't know" to
"Definitely not".  I am not aware of a C compiler for the PDP-8, but I
think it would be
 exceedingly difficult to write one if were possible at all (I've done
 a lot of system and embedded code in C and debugged it in assembler,
 so I know a bit about the syntactical mapping that goes on with C
 abstractions to the instruction sets of MC68000s, VAXen, PDP-11s,
 etc). 
Everything is possible. The main question is how slow it would be.

...
  > >> 
Something I'd really like to see is a Z-machine running on the PDP-8.  I would
like that too.  I've even thought a lot about it.  IMHO,
 anyone who does it will be writing the Z-machine in PDP-8 assembler,
 just like what was done for the Z-80 and the 6502 for 1970s and 1980s
 micros.  I_think_  the Mac Z-machine was the first written in C, but I
 could easily be mistaken on that.  I know there were official
 Z-machines written in C for the Mac and the Amiga, and probably the
 later ones on the PC (not sure about the early v3 interpreters for
 DOS).

 I like Frotz.  Frotz is huge compared to the 6K-8K early 8-bit
 interpreters.  It gets more dicey trying to ask a 12-bit machine with
 4K pages to emulate a 16-bit virtual machine.  I would consider it a
 win if one could fit the Z-machine code in 2 fields with enough space
 left over for a 2-page system handler and a 1-page line printer
 (SCRIPT) handler, using any memory above 8K for object data and game
 file buffers.  Three fields seems plausible.  A few years back, I
 assisted with a modern from-scratch Z-machine effort for ElfOS on the
 1802 (that I was showing off at an early VCFmw).  On a 32K Spare Time
 Gizmos Elf2000, once the interpreter was loaded and the object tables
 were loaded, there was very little room to buffer the game - I think
 it was on the order of 1-3 512 byte disk blocks.  You can fit a v3
 game and interpreter in 32K, but to do it in less would probably
 require a read-write virtual memory scheme on the object data
 (fortunately, a full boat on a PDP-8 is 32K 12-bit words not 32K 8-bit
 bytes - that helps too). 
Frotz is nice in its way, but totally unusable if you want to look at 
doing something on a PDP-8.

I think two fields for all the code of the Z-machine itself is possible. 
Including drivers, yes. Depending on the size of the game, you'll have 
different amount of memory to play with after that.
I assume you by "object tables" mean the in-game read/write memory.

I can tell that ZEMU on the PDP-11 can handle any V1 to V8 games 
dynamically, and takes about 32Kbyte of memory to do that. The rest is 
used/usable by the game itself.

To write a V3-specific interpreter, as well as skipping some fancy 
screen handling that ZEMU do, it should need way less.

...
  Strangely enough, I was just thinking about a 12-bit
Z-machine this
 week.  Anyone out there have 12-bit coding experience and have time to
 answer a few questions about OS/8 and file interchange from the 8-bit
 outer world? 
Sure. Go ahead.

And then allison <ajp166 at verizon.net> wrote:

On 02/07/2012 05:39 PM, Ethan Dicks wrote:
...
   On Tue, Feb 7,
2012 at 12:51 AM, Cameron Kaiser<spectre at floodgap.com>  wrote:
 >   I don't think the PDP-8 could.  I
gotta say that I don't think so either.
  It's not impossible though you might have a hardware abstraction to
 deal with recursion and addressing.   But it will not be pretty. 
Right. You need to make some design decisions on how to implement some 
things in software that other machines do in hardware, but things like a 
stack is not really that hard to write.

...
   > Something I'd really like to see is a
Z-machine running on the PDP-8.  I would like that too.  I've even thought a lot
about it.  IMHO,
 anyone who does it will be writing the Z-machine in PDP-8 assembler,
 just like what was done for the Z-80 and the 6502 for 1970s and 1980s
 micros.  I _think_ the Mac Z-machine was the first written in C, but I
 could easily be mistaken on that.  I know there were official
 Z-machines written in C for the Mac and the Amiga, and probably the
 later ones on the PC (not sure about the early v3 interpreters for
 DOS).
  Its likely doable but it would take work.  Keep in mind that an -8 maxes
 memory at 32Kwords.  that means bigger will have to have a mechanism
 for swapping to storage.

 Keep in mind the Z80 did not ahve many of the addressing modes of C. 
Right. A Z-machine for the PDP-8 is definitely doable. It might not be 
that fast, but it would work.

...
     A few years
back, I
 assisted with a modern from-scratch Z-machine effort for ElfOS on the
 1802 (that I was showing off at an early VCFmw).  On a 32K Spare Time
 Gizmos Elf2000, once the interpreter was loaded and the object tables
 were loaded, there was very little room to buffer the game - I think
 it was on the order of 1-3 512 byte disk blocks.  You can fit a v3
 game and interpreter in 32K, but to do it in less would probably
 require a read-write virtual memory scheme on the object data
 (fortunately, a full boat on a PDP-8 is 32K 12-bit words not 32K 8-bit
 bytes - that helps too).  That and if you do text in six bit ascii you get two cars
to a word. 
Right. But that is not much help for the Z-machine, which packs text 
inside the games in its own format anyway. There is very little text 
required in the Z-machine itself.

...
   Strangely
enough, I was just thinking about a 12-bit Z-machine this
 week.  Anyone out there have 12-bit coding experience and have time to
 answer a few questions about OS/8 and file interchange from the 8-bit
 outer world?
  Some here, not a lot as I've not run OS/8 in a long time.  FYI
 a suitable dev system would be a DECmateII or III running OS278. 
If you have questions about OS/8 or PDP-8 issues, feel free to ask. I 
only read this list in digest mode, so please cc me directly as well.

...
  The biggest thing to watch for in PDP8 code is
recursion as you
 need a software stack and handler to preserve data/addresses. 
Not really needed. The Z-machine implementation itself is more or less 
an abstract CPU, and does not really need to do any recursion. However, 
the Z-machine games themself can do recursion. But as a stack for this 
purpose is a part of the requirement of the Z-machine itself, it will 
just work, if you implement the Z-machine.

...
  The DECmates had the 6120 and that implemented IOTs to
create
 a address and data stack( hardware can be built to do that in
 any omnibus 8).   The unique PDP-8 IO made doing things like that
 more common than would be guessed. 
Right. But on an Omnibus machine, the easy way would be to instead have 
a small subroutine that push/pop on the stack, instead of having to 
built new hardware.

	Johnny

PDP-8 Z-machine (was: PDP-8 Unix)