8 Feb
2012
8 Feb
'12
9:18 a.m.
On 2012-02-08 01.37, Ethan Dicks<ethan.dicks at gmail.com> wrote:
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.
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.
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.
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.
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.
On Tue, Feb 7, 2012 at 12:51 AM, Cameron Kaiser<spectre at floodgap.com> wrote:
Everything is possible. The main question is how slow it would be.
> >> ?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). > >>
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). 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:
It's not impossible though you might have a hardware abstraction to
deal with recursion and addressing. But it will not be pretty. > I don't think the PDP-8 could.
I
gotta say that I don't think so either.
> 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).
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. 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. 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