On Sun, 8 May 2005, Ethan Dicks wrote: I have the over-sized Sorcerer packaging and the "case file" Deadline packaging. Still looking for the saucer ;) -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

In message <f4eb766f05050813432f2d277a at mail.gmail.com> Ethan Dicks <ethan.dicks at gmail.com> wrote: I'm not sure just how powerful the 6100 is, but I doubt it would be too difficult to port one of the simpler Z-machine engines from Linux or BSD to whatever the DECmate runs (VMS?) Forgive my lack of knowledge of all things DEC.. My collection (if you could call it that) is predominantly microcomputers... Later. -- Phil. | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB, philpem at philpem.me.uk | ViewFinder, 10BaseT Ethernet, 2-slice, http://www.philpem.me.uk/ | 48xCD, ARCINv6c IDE, SCSI ... Flash Gordon exposed himself to all sorts of danger.

On Sun, 8 May 2005, Ethan Dicks wrote: I'll check my stash. I'm pretty sure I have a couple games that are for the Rainbow 100 (HHGTTG?) -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

On Sun, 8 May 2005, Ethan Dicks wrote: Porting a Z-Code interpreter to a new machine is a nice exercise. In my case I ported the Infocom interpreter from the InfoTaskforce (written in C) to the IBM 5110 (yes, the 5110, not the 5150) in machine language (yes, you can program that beast in machine language, it has a very nice instruction set IMHO). The binary's size is only 9.5kB and will run any V3 games. It includes save/restore, a paging mechanism for fetching needed non-resident code parts from disk (and throwing out LRU ones), line wrapping / 'more'-style pausing for the 64x16 display etc. The interpreter requires at least one 5114 disk drive and 16kB of RWS. If more RWS is available, less page swapping is needed during the game. Anyone interested in playing Zork on an IBM 5110 ? Christian

On 5/9/05, Christian Corti <cc at corti-net.de> wrote: Nice. I don't have a 5110, or I'd want it. I have a work in progress of porting a v3 interpreter to the PET, but I just haven't gotten around to finishing it. It starts up and displays text, but depending on the game, accepts input to one degree or another. I'm fairly certain I'm stepping on some zero page variable that I shouldn't be, and it's also being used by the kernel for CHARIN/CHROUT stuff (I/O to disk and the screen). This same program does work with the VIC-20 (as tested under VICE with 24K of RAM), but the screen size there makes it hard to play a game. Obviously, the nature of the 6502 makes writing an interpreter feasible (since Infocom directly supported the C-64, Apple II, and the Atari). Pretty much any 1MHz micro that has at least 32K of usable storage (48K or 64K is better) and a disk system with random block access (for the demand-paged virtual memory scheme used to keep only as much of the game in memory as needed at the moment) that is large enough to hold the game file (80-something K in the case of Zork I) is all that's required. The limiting factor in playing the game is disk speed, not CPU speed. With more memory, the game spends more time playing out of RAM than paging off the disk, but even a 32K machine should have enough to hold the varable store, the interpreter, and enough of the paged store to contain the parser and the present room code. Mapping all of this onto the PDP-8, however, is somewhat problematic... the Z-machine, the foundation of Infocom's success in the days of competing micro architectures, is a byte-oriented virtual machine with 16-bit (stored) pointers (depending on the interpreter that can be expanded to 17 or 18 bits like BCPLs BPTRs). I have often mused over the years how best to map that virtual machine onto the PDP-8, with no real progress. With large 16-bit and 32-bit host platforms (Amiga, Mac, UNIX, VMS, PC...), it is not necessary to implement a virtual memory scheme. With the PDP-8 and its own page-oriented memory system, it's certainly necessary, and doubly difficult. At least in the case of a 6502, the virtual memory routines simply hit a page boundary, pull in the next 256 bytes of the game to some available hole, and map the upper 8 bits of the Zpointers in software.