infocom on other systems

On Mon, Sep 01, 2008 at 10:34:58PM -0400, Rick Murphy wrote: True, unfortunately. I completely appreciate the sentiment - that's why I helped out a couple of years back on an 1802 Z-Machine. It was lots of fun and a great thrill when it worked for the first time. If anyone on the list was at VCFmw last year, I had an Elf-2000 and an Embedded Elf with me, running a couple of games. Neat. I don't know about _impossible_ but it certainly is extremely difficult. It's not a case of brute-force vs complexity... Adventure is a monolithic FORTRAN (now FORTRAN or C) program, and even with overlays, it's a) huge, and b) internally complex. The advantage of the Z-machine is that the _game_ complexity is all in the game file. The platform just has to handle a few dozen opcodes and be able to swap in needed portions of the game file on smaller hosts (larger hosts, i.e. - that can directly address 128Kbytes or more, can just pull everything in and advance the Z-machine program counter at will). That having been said, the Z-machine is inherently a 16-bit virtual processor. It's trivial to implement on an MC68000, cumbersome but not too ugly on 8-bit processors like the 6502 or Z-80, but about as far away from a 12-bit machine as one can get. I've thought a lot about a PDP-8 Z-machine implementation over the years. Sometime in the last year, I decided the first step would be to port some simplistic V3 game file dumpers to OS/8. If that proved to be too difficult to complete, then a full-on Z-machine would be nearly impossible. Fundamentally, I think one would have to scale up all the 16-bit Z-pointers to 24-bits internally to a theoretical PDP-8 Z-machine, and there's a lot of 16-bit math going on under the hood. There needs to be enough RAM available after loading whatever the OS needs and after loading the interpreter to hold 256 16-bit variables, the item table, and a few dozen K of the game file. On an 8-bit machine, there's room in 32Kbytes to hold the necessary overhead and still leave a few pages for the swappable part of the game file (I've done this on the 6502 and 1802, FWIW). It's true that it was more common to see Infocom games run on machines with _more_ than 32K (48K Apple, 48K TRS-80, 39K-free C-64...), but a V3 game will barely fit in 32K with overhead. The question, to me, them becomes, how much "waste" is there trying to juggle handfuls of 16-bit quantities in 24-bit spaces and is there enough room left over on a 32Kword machine to swap some non-volatile game pages in. One thing about OS/8 (and the PDP-8 architecture in general) is that the natural "page size" is 128 words, not 512 bytes as with so many "modern" machines. It'll be easier to find room for 3-12 PDP-8 pages than 3-5 pages of 512 bytes was on an 1802 running ElfOS. It's even crowded on a 32K PET with its 256-byte diskette sectors being the natural "page". I was planning on taking some baby-steps along the way - first, just import the game header, dump some stats and exit. Next, try a few simple opcodes - assign some variables, do some 16-bit math, then print the results. From there, it's possible to write some crafted Z-machine-abuse programs in Inform to stress-test the Z-machine - this is an important step in writing a new interpreter the opcodes are verified, it's reasonable tackle programs that are larger than free memory and test out the virtual-memory code. After all that, it's time to load Zork I and watch it play. It's been 20 years since I wrote any PDP-8 assembly code, but I could probably get back in the groove after a bit of effort. Fortunately, these days, with so many emulators running around, the development environment is much richer. Ultimately, though, the final test would be running on the real hardware, no matter how much emulation was used in development. Oh... one point I forgot to work in earlier - any simplistic Z-machine of this caliber would likely be limited to V3 games. The game volatile memory requirements for V5 is enough that it's not feasible to attempt to write an interpreter for an 8-bit machine with only 32Kbytes. There just isn't enough room to wedge in a 6K-8K interpreter, plus OS overhead _plus_ volatile game pages, let alone leave anything for non-volatile (i.e., swappable) game pages. I don't even know if 48K is enough. Have a look through the old game catalogs as to what games were supported on what platforms, and I think 64K is about the practical minimum for a V5 game. So I still think it's possible to write a V3 Z-machine for a 32Kword PDP-8, but my ideas have yet to escape as far as paper along any path of demonstrating it. -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 2-Sep-2008 at 05:50 Z South Pole Station PSC 468 Box 400 Temp -67.0 F (-55.0 C) Windchill -106.8 F (-77.1 C) APO AP 96598 Wind 14.4 kts Grid 35 Barometer 680.8 mb (10598 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html