On Mon, 1 Sep 2008, Roger Ivie wrote: It's the pdp8-ness that made me take notice. I have a thing for getting z-machine interpreters running on weird platforms and right now the pdp8 and pdp11 strike my fancy. Recently someone ported my pet project, Frotz, to the iPhone. -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

Rick Murphy wrote: In 1965, I don't think many people expected a PDP8 to have games on a ~ 20 grand machine. What is wrong with the 4K chess program any how instead :)

Recent detailed analysis has shown that the aluminum foil hat operates as an antenna. On Mon, 1 Sep 2008, bfranchuk at jetnet.ab.ca wrote:

On Mon, 1 Sep 2008, Fred Cisin wrote: You are supposed to attach a tail of wire that will reach the ground even when you are standing to your tin foil hat. Just after Ben Franklain did his thing with the kite, such a hat only in copper was a fashion accessory in France along with a metal umbrella with a similar tail for milady. bs

On Tue, 2 Sep 2008, jd wrote: That is why a Cyberdeck is needed to overpower the OS when forcing one's way into a system.

Tony Duell wrote: A: Only if you both share the little wheel that goes around and around.

No, and he's not in a cage, Faraday or otherwise, either. I assume you noticed that 'PET' was entirely in upper case... -tony

On Wed, Sep 3, 2008 at 12:23 PM, Bryan Pope <bpope at wordstock.com> wrote: Just don't say it where the cats can hear you.

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

On Mon, Sep 01, 2008 at 11:45:00PM -0700, Eric Smith wrote: I suppose there could be a code advantage in splitting things up like that, but I don't see much of a in-core storage advantage, unless you pack, for example, 3 variables in 4 machine words (in which case, the code could get fairly messy). Sure... adding impure swap would make the larger games fit, at what might be a hefty performance penalty - but it should work. -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 2-Sep-2008 at 14:40 Z South Pole Station PSC 468 Box 400 Temp -54.4 F (-48.0 C) Windchill -93.5 F (-69.7 C) APO AP 96598 Wind 17.5 kts Grid 32 Barometer 680.5 mb (10609 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html

Hi, On Tue, Sep 02, 2008 at 06:19:56AM +0000, Ethan Dicks wrote: .... Is the 1802 Z-machine code available anywhere? One of these days I'm going to get one of my Quest Super-ELF machines set up again, and also build my ELF-2000. Yay! http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=287653015… Mark -- Mark G. Thomas (Mark at Misty.com) voice: 215-591-3695 http://mail-cleaner.com/

At 02:19 AM 9/2/2008, Ethan Dicks wrote: Interesting. Seems that there's workarounds for the memory limitations of the '8. Especially if you're willing to work to pack the data (3 8-bit bytes in 2 12-bit words.) Never say never, I guess. :-) -Rick

On Mon, Sep 01, 2008 at 11:35:51PM -0700, Eric Smith wrote: Did they? My first direct experiences with Infocom games were on the Apple II and C-64 (c. 1982-1983). I'd seen them once or twice before, but I only really got my hands onto them when I could run them at home. There weren't very many 32K Apple IIs - yes, they were sold, but the ones I saw were always expanded to 48K. The first C-64 interpreter didn't twiddle any of the memory banking, so it used the same memory space available to BASIC - 39K (it didn't even use the RAM block at $C000 - at one point, I loaded a PET font that I copied from a real PET ROM up there to get "cleaner" letters than the standard C-64 ROM font while I played). I think it should fit as well. Yes... as you say, one _can_ page impure data. Given the slow performance of any of the 8-bit paged intepreters, I have to admit that I didn't think of that at first, but it would work, though slowly. On the slowest platform I know, a C-64 w/1541 disk, it used to take many seconds between commands just to page in the _pure_ data. The TRS-80 and Apple II had much faster diskette interfaces, so were more limited by the speed of the media and the speed of the stepper, unlike the 1541 (which had those limitations as well, but the serial interface was the real bottleneck). I don't have any performance data, but I don't remember my RL01 being particularly slow on my PDP-8/a - certainly much faster than floppies. Thanks for pointing out what should have been an obvious path around memory limitations. It's given me a bit more to think about. -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 2-Sep-2008 at 14:40 Z South Pole Station PSC 468 Box 400 Temp -54.4 F (-48.0 C) Windchill -93.5 F (-69.7 C) APO AP 96598 Wind 17.5 kts Grid 32 Barometer 680.5 mb (10609 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html

Somewhere I have at least one Infocom game on a 3.5" floppy for the HP150. I think it runs on the HP110 too. I forget which game(s) I have, but can proably be persuaded to dig them out if anyone cares... -tony

Erik Klein wrote: Well the the only real thing to know is you need to "Have a British accent" when playing the game. I suspect it follows the book closely. PS: I could never when at those games since I never knew or could spell the words needed by the input parser.