Re: Port of Frotz to Commodore 64/128?

David Evans wrote:
> In article <1121697572.187722.158910@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> <dunric@xxxxxxxxx> wrote:
> >Is there a port of Frotz for the Commodore 64/128? I looked around in
> >vain and couldn't find a port for the machine.
> >
>
> I am unconvinced that you will find a port of Frotz. The smallest
> system that it seems to run on is the GBA, which I believe is rather
> more beefy than the 64/128.

Indeed. Infocom's interpreter for Zork I weighs in at 6K, and doesn't
get much larger for the later versions that are a little more
sophisticated (able to use all 64K RAM on a C-64, 1541 speedloader...)

> It has been many years since I looked at
> the Frotz code but as I recall it does make assumptions that may get in
> the way of running on small machines.

Even if one were to start with Frotz, it's difficult to get a large
program written in C to squeeze into an 8-bit machine with little
memory. Especially in the case of a C-64 (less so with the C-128),
the interpreter needs to be as small as possible to leave enough
free RAM to house the game. V3 games (Zork I, Planetfall,
Starcross...)
aren't so bad, but V4 and V5 games (Trinity, A Mind Forever Voyaging,
and most modern Inform games) start off so much larger, just due to
how big the object storage area can be, that even 32K free really isn't
enough.

> You might be better off porting a different Z-machine emulator; there
> must be some around for small boxes. One by Johnny Billquist is listed
> here:
>
> http://www.update.uu.se/~bqt/rsx.html

While that might be a good starting point, the PDP-11 is a 16-bit
CPU and not, I think, the best choice for launching a 6502 project.

> or you could dig up something for CP/M.

That might be a more reasonable option... at least the CPUs are
closer, architecturally.

This exact issue came up recently while trying to assist someone
on a new, from-scratch interpreter for an 8-bit machine with 32K
of RAM (total), and about 12K free after the OS and game
interpreter were loaded.

I think it took 2 weeks from the beginning of the project until
one could play Zork I from start to finish. Expanding this
interpreter to encompass V4 games has been much slower,
partially because in the case of Trinity, there's nowhere
near enough free RAM to cache the dynamic information, and this
interpreter is written in assembler, not C, so this is without
the overhead of a clib, etc. The solution for this particular
problem was to design a RAM expansion unit to act like EMS
memory did back in the PC days - 512K (or so) of RAM paged in
a fixed window, so that writing a demand-paging routine
(Infocom's trick for fitting an 80K+ game file in a 48K
Apple II or TRS-80, etc) is dead simple.

In short, it's possible to shoehorn games into small machines
(small, in this case is where the available RAM is less than
the size of the game file), but it does take some care and
deliberation. Frotz grew up on machines where memory size
isn't an issue... either you have hundreds of K of physical
RAM (or more), or the OS handles paging for you so you don't
have to invent your own scheme - you just slurp up the game
file, and as far as your program can tell, it's all there,
all the time.

That having been said, I'd love to see a new, from-scratch
implementation of a z-machine for the 6502. It's been on
my personal project list for a number of years, but I've
never managed to get much of a start on it. Coding for C-64
is easy on the one hand, because it's simple to set up
"direct" disk block access, which is fortunate, because it's
not trivial to do random seeks into a traditional sequential
file, something that's really useful when you can't slurp up
the entire game file into RAM. Frotz, of course, assumes
that one can seek() back and forth, as most modern OSes permit.

I'd be happy to be able to run an interpreter that works
with some of the hard-disk add-ons like the IDE-64, since
those won't work so cleanly with direct disk accesses as
the 1541.

.