From owner-z-machine@gmd.de Mon Mar 17 21:43:57 1997 Return-Path: owner-z-machine@gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id VAA16829 for ; Mon, 17 Mar 1997 21:43:53 -0600 Received: by mail2.gmd.de id AA04422 (5.67b8/IDA-1.5 for earendil@faeryland.tamu-commerce.edu); Tue, 18 Mar 1997 04:43:55 +0100 Date: Tue, 18 Mar 1997 04:43:55 +0100 Message-Id: <199703180343.AA04422@mail2.gmd.de> To: earendil@faeryland.tamu-commerce.edu From: Majordomo@gmd.de Subject: Welcome to z-machine Reply-To: Majordomo@gmd.de Status: RO X-Status: -- Welcome to the z-machine mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "z-machine-request@GMD.DE": unsubscribe Or you can send mail to "Majordomo@GMD.DE" with the following command in the body of your email message: unsubscribe z-machine earendil@faeryland.tamu-commerce.edu Here's the general information for the list you've subscribed to, in case you don't already have it: [Last updated on: Mon Jan 15 14:54:53 1996] The Z-machine is Infocom's imaginary computer, designed to run that company's line of high-quality text adventures. This list is a forum to discuss all aspects of this machine, its interpreters, and its compilers. From owner-z-machine@mail2.gmd.de Tue Mar 18 21:57:45 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id VAA01072 for ; Tue, 18 Mar 1997 21:57:44 -0600 Received: by mail2.gmd.de id AA14650 (5.67b8/IDA-1.5 for z-machine-out); Wed, 19 Mar 1997 03:29:31 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA16779 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 03:29:28 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA10264 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 03:29:26 +0100 Received: by wanda.vf.pond.com (8.6.12/gw.1.0) id VAA16952; Tue, 18 Mar 1997 21:30:15 -0500 Date: Tue, 18 Mar 1997 21:30:15 -0500 From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703190230.VAA16952@wanda.vf.pond.com> To: z-machine@gmd.de Subject: [z-machine] GNUSTO-Z? Stop the presses! Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Maybe I'm missing something, but it looks like the GNUSTO-Z save-format is missing a place for the initial program counter following the restore. From owner-z-machine@mail2.gmd.de Wed Mar 19 06:16:58 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id GAA03616 for ; Wed, 19 Mar 1997 06:16:53 -0600 Received: by mail2.gmd.de id AA31831 (5.67b8/IDA-1.5 for z-machine-out); Wed, 19 Mar 1997 12:48:06 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA30676 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 12:47:46 +0100 Received: from pigeon.doc.ic.ac.uk by mail.gmd.de with SMTP id AA26906 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 12:47:44 +0100 Received: from oak75.doc.ic.ac.uk [146.169.16.20] by pigeon.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0w7JqI-0007C7-00; Wed, 19 Mar 1997 11:47:42 +0000 Received: by oak75.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0w7JqB-0000YXC; Wed, 19 Mar 97 11:47 GMT Message-Id: From: "Martin Frost" Date: Wed, 19 Mar 1997 11:47:35 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: Re: [z-machine] GNUSTO-Z? Stop the presses! Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: >Maybe I'm missing something, but it looks like the GNUSTO-Z save-format is >missing a place for the initial program counter following the restore. *sheepish look* Erm, yes it appears to have gone missing from the document between the first draft (which contained it) and version 1.1 (current). Add the following extra clauses: 5.4.6 3 bytes ... initial PC on restore 5.7 It should be noted that the current state of the IFhd chunk means it has odd length (21 bytes). It should, of course, be written with a pad byte (as mentioned in 8.4.1). If noone else notices any silly omissions, I'll upload a modified version on Friday or Saturday (my last day before Easter holidays). Martin -- From owner-z-machine@mail2.gmd.de Wed Mar 19 13:11:52 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id NAA04713 for ; Wed, 19 Mar 1997 13:11:51 -0600 Received: by mail2.gmd.de id AA01235 (5.67b8/IDA-1.5 for z-machine-out); Wed, 19 Mar 1997 19:26:08 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA01443 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 19:26:04 +0100 Received: from relay-11.mail.demon.net by mail.gmd.de with SMTP id AA10207 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 19:26:00 +0100 Received: from elvw.demon.co.uk ([158.152.183.71]) by relay-11.mail.demon.net id aa1119991; 19 Mar 97 18:13 GMT Date: Wed, 19 Mar 1997 17:30:13 GMT From: John Wood Reply-To: john@elvw.demon.co.uk Message-Id: <2068@elvw.demon.co.uk> To: z-machine@gmd.de Subject: Re: [z-machine] Infix: what are sequence points? X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 58 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: On another thread, Martin Frost wrote, MF> It would seem sensible to stop at sequence points though - IIRC MF> Inform has these much like C. - and I was going to ask what sequence points were, until Graham Nelson proclaimed, GN> GN> At present, the sequence points are exactly the first instruction GN> compiled for every statement. Thus: GN> GN> (*) i = 56; GN> (*) for ((*) j=56; (*) j<255; (*) j++) (*) print j; GN> GN> The (*) markers are the sequence points. (At least I think GN> that's right.) Aha! And it already exists in the Inform compiler code. Excellent! GN> Does anyone want something substantially different to this? GN> I'm prepared to implement any reasonably clear definition of GN> "sequence point". The above sounds *fairly* intuitive - the only difference is that if I were on the "for" S.P. and sequence-single-stepped, I'd probably expect it to perform the first assignment, j=56 (unless visually prompted otherwise). I can live with this. GN> There is also the issue of whether a sequence point should GN> be linked to a specific character in the source code, rather GN> than only a specific line number and file (as at present). GN> Obviously I'm a lazy character, but I can put up with whichever GN> is decided. If you're going to be stepping through sequence points as in your "for" loop example, you *need* to be able to see how far you've got. Therefore, if we're not going to forget about them altogether (which would be a shame), we need the character position - even though this will make the debug files bigger still. Sorry. [I think we can make this a byte, and have 255 indicate "somewhere beyond char 254" - people using longer lines than that are asking for trouble! ;-p] [Incidentally, with character-precise sequence points Infix can check the source for loop statements. Is there a way to determine the first S.P. after the loop, without including more debug information?] MF> Might involve YA step command though - are we creating the EMACS of MF> debuggers? (esp. in light of desired programmable features...) I've no idea what YA stepping is, I'm afraid. As for the feature list - I tried to put in as much as possible so we could prune it. So far it's just grown! I'd like to categorise features as (a) essential for first release, (b) desirable for later, or (c) pipe-dreams that we should forget about if we're going to get anything done. John From owner-z-machine@mail2.gmd.de Wed Mar 19 13:40:57 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id NAA04787 for ; Wed, 19 Mar 1997 13:40:55 -0600 Received: by mail2.gmd.de id AA05706 (5.67b8/IDA-1.5 for z-machine-out); Wed, 19 Mar 1997 20:16:40 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA24162 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 20:16:35 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA13723 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 20:16:25 +0100 Received: from jokisch ([194.74.138.46]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAC1721 for ; Wed, 19 Mar 1997 20:07:06 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Infix Group: please post your list to my address Date: Wed, 19 Mar 1997 20:14:14 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970319190701.AAC1721@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: In response to John Wood: [About a function to run until the current loop is left:] > Good idea (and one I haven't seen in C debuggers). What information > is needed in a debug file to spot a loop? Or is there a reliable > algorithm for doing so? I suggest Inform produces additional debugging information to identify sequence points that mark the beginning of a loop. We must also know which Z-code interval corresponds to this loop. The interpreter needs to check: After every "return" or "throw": Have we returned to an earlier stack frame? After every "jump" or "branch": Have we left the Z-code interval while the stack frame is still the same? We probably cannot extend this scheme to arbitrary story files without debugging information. My problem here is that I cannot even think of a reasonable definition of a loop, let alone give an algorithm. [About the implementation of the undo function:] > > It is possible to create protocol of all changes in the dynamic > > memory. (Once I had already implemented this as a more economic > > way of storing undo states in Frotz.) > > Could you explain a little more? This sounds ideal. First of all, I understood that you suggest an undo function to return the Z-machine to its previous state. "previous" means "at the previous sequence point" for source level debugging or "before the last instruction" on Z-code level. "state" means the state of dynamic memory, the stack, SP, FP, PC. It does not include the screen, text buffer, window properties etc. My idea is that the interpreter never changes dynamic memory except by calling a set_byte function. This function writes the address and the old value at this address into a buffer. You can restore the state of the dynamic memory by reading this buffer backwards. While you do so, a) over-write the new values in the dynamic memory with the old ones, b) over-write the old values in the buffer with the new ones. Step b) is necessary to redo at a later time. Writing the protocol slows the interpreter down, and this is why I did not keep this algorithm in Frotz. However, the loss in performance is acceptable for a debugger, I think. Undo should not try to take back interrupts. For instance, on the end of a sound effect DOS Frotz calls its interpreter loop from a hardware interrupt routine! Even newline and time-out interrupts call the main loop. This cannot be undo by fiddling with the dynamic memory. Of course, one also needs to protocol any changes to the stack. [About grammar tables, action tables, dictionary etc.:] > > >10. z-machine tables: > > > > Not recommended. These tables aren't dynamic, anyway. And some of > > them serve different purposes under Inform. > > This is from the "Examining Data" section. I just meant for these > to be viewable in a sensible form - is this generally not possible? It is possible. However, these tables are not part of the Z-machine specification and their format tends to change often. I thought it would be easier if the programmer referred to his own source code or if he used the infodump utility. The game dictionary, however, is a different matter since it is part of the Z-machine specification. I can also think of games (like "Beyond Zork") that may want to build additional (dynamic) dictionaries at run-time. It would make sense to view those dictionaries. -- Stefan From owner-z-machine@mail2.gmd.de Wed Mar 19 13:47:06 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id NAA04813 for ; Wed, 19 Mar 1997 13:47:05 -0600 Received: by mail2.gmd.de id AA27771 (5.67b8/IDA-1.5 for z-machine-out); Wed, 19 Mar 1997 20:20:23 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA03307 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 20:20:20 +0100 Received: from relay-11.mail.demon.net by mail.gmd.de with SMTP id AA15838 (5.67b8/IDA-1.5 for ); Wed, 19 Mar 1997 20:20:11 +0100 Received: from elvw.demon.co.uk ([158.152.183.71]) by relay-11.mail.demon.net id aa1118998; 19 Mar 97 18:07 GMT Date: Wed, 19 Mar 1997 17:28:11 GMT From: John Wood Reply-To: john@elvw.demon.co.uk Message-Id: <2067@elvw.demon.co.uk> To: z-machine@gmd.de Subject: Re: [z-machine] Infix: Architecture and break points X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 128 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Stefan Jokisch wrote, > Have we already agreed on a code to be used as break point? No? > In this case I'd like vote for 2OP:0 (value 0) instead of NOP. > 2OP:0 seems to have been intended as break point. As somebody > already pointed out, there is no need to use a 0OP instruction > as break point. (Who knows, NOP might still be useful.) I have in the past used NOPs to get rid of code while debugging, so this seems reasonable to me. One thing I discussed with Bryan Scattergood was the possibility of Infix asking the Interpreter to set a breakpoint, which could then be handled in whatever way seemed sensible to the interpreter-writer. There would have to be some decision as to whether NOP/2OP:0 counted as a bkpt or not, though, anyway. > I have added an excerpt of the Frotz main loop to this mail in > order to show the use 2OP:0 as break point. > > I thought this was interesting. It reflects some of our ideas > on Infix program architecture. However, it probably needs some > enhancements to cope with the suggested Infix feature list. Definitely interesting. I've messed about with it a bit. Let's assume (close to) the full range of features listed. This means we might have watchpoints and/or consistency checks, or we might be single-stepping. There can thus be several reasons for doing debug stuff; we could combine these into a bit-map (infix_flags, say). I am assuming pressing the halt key will set the HALT_KEY_PRESSED bit - there seems no harm in getting the CODE_BYTE even when this has been pressed, and this eases code flow. Note I return the new value of infix_flags. This means that Infix can simply leave the SINGLE_STEPPING or WATCHPOINT_ACTIVE bits set to continue doing so, and automatically get called again next time. If we are sharing global data, infix_flags needn't be passed back and forth like this. void interpret (void) { do { zbyte opcode; CODE_BYTE (opcode) if (opcode == 0) infix_flags = Infix_PreInstruction(infix_flags|BREAKPOINT_HIT, &opcode); else if (infix_flags != 0) infix_flags = Infix_PreInstruction(infix_flags, &opcode); zargc = 0; ... } while (!finished); }/* interpret */ This is one of the simplest models from the POV of the Interpreter calling Infix. It would be convenient, however, if Infix was called at other times. A (possibly) more efficient way to handle watchpoints, for instance, could be implemented if the Interpreter calls Infix_*Changed() at appropriate times (as suggested earlier). Infix_EnteredRoutine() and Infix_ExitedRoutine() could be useful, too. Oh, here's a slightly modified Frotz main: /* This default may be changed to PAUSE_BEFORE_START in os_process_arguments: */ uint32 infix_flags = 0; int cdecl main (int argc, char *argv[]) { os_process_arguments (argc, argv); init_memory (); os_init_screen (); init_undo (); infix_flags = Infix_Initialise(infix_flags, story_name); do /* I'm not sure how much needs to be inside the loop. */ { z_restart (); interpret (); } while (infix_flags & RESTART_ZMACHINE); Infix_Reset(); reset_memory (); os_reset_screen (); return 0; }/* main */ I think we're approaching the point where we ought to come up with a draft proposal for the missing bits of the APIs. A few questions to consider: 1. Are you happy with the Interp_CapitalisedWords()/Infix_CapWords() naming convention? 2. Kevin Bracey's original scheme had pc, sp & fp passed to Infix in all cases except Infix_Initialise(). Is this the best way of sharing this information? 3. How do you feel about structures, such as: typedef struct stackframe_descriptor { int pc; // of the jump instruction int localCount; number locals[15]; // per @4.2.2 int argumentCount; number arguments[8]; // per @6.4.1 } stackframe_descriptor; [from Stephen van Egmond's doc] I know Kevin doesn't like them, and (presumably) Stephen does - what's the consensus? 4. Stephen has pointed out that certain things we will want in Infix (such as routines to get the first/next property of an object) map directly onto code the Interpreter has to implement anyway. Is it sensible to make these Interp_ functions and have the interpreter- writer expose them, rather than re-implementing them in Infix? More later. John From owner-z-machine@mail2.gmd.de Wed Mar 19 20:50:44 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id UAA06514 for ; Wed, 19 Mar 1997 20:50:42 -0600 Received: by mail2.gmd.de id AA24433 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 03:35:16 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA22490 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 03:35:14 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA31562 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 03:35:12 +0100 Received: by wanda.vf.pond.com (8.6.12/gw.1.0) id VAA24208; Wed, 19 Mar 1997 21:36:01 -0500 Date: Wed, 19 Mar 1997 21:36:01 -0500 From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703200236.VAA24208@wanda.vf.pond.com> To: z-machine@gmd.de Subject: [z-machine] GNUSTO-Z eval stack order Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: 4.7 Assigning each of the possible 7 supplied arguments a letter a-g in order, each bit is set if its respective argument is supplied. The evalation stack count allows the reconstruction of the chain of frame pointers for all possible stack models. Words on the evaluation stack are also stored most recent first. ^^^^ This is inconsistent with the order the frames are stored. Is this intentional? Also, is the order of 'UMem' or 'CMem' relative to 'Stks' specified? From owner-z-machine@mail2.gmd.de Thu Mar 20 05:25:01 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id FAA07877 for ; Thu, 20 Mar 1997 05:24:58 -0600 Received: by mail2.gmd.de id AA31663 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 11:54:39 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA30068 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 11:54:36 +0100 Received: from pigeon.doc.ic.ac.uk by mail.gmd.de with SMTP id AA31938 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 11:54:33 +0100 Received: from oak70.doc.ic.ac.uk [146.169.46.70] by pigeon.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0w7fUO-0002TB-00; Thu, 20 Mar 1997 10:54:32 +0000 Received: by oak70.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0w7fUN-0000YXC; Thu, 20 Mar 97 10:54 GMT Message-Id: From: "Martin Frost" Date: Thu, 20 Mar 1997 10:54:31 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: Re: [z-machine] Infix: what are sequence points? Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: >From John Wood: >On another thread, Martin Frost wrote, >MF> It would seem sensible to stop at sequence points though - IIRC >MF> Inform has these much like C. > - and I was going to ask what sequence points were, until Graham Nelson > proclaimed, >GN> At present, the sequence points are exactly the first instruction >GN> compiled for every statement. Thus: >GN> >GN> (*) i = 56; >GN> (*) for ((*) j=56; (*) j<255; (*) j++) (*) print j; >GN> >GN> The (*) markers are the sequence points. (At least I think >GN> that's right.) Does that mean that (a == 1) && (b == 2) has just one sequence point? It might be nice if it had two: (*) (a == 1) && (*) (b == 2), but this is not particularly important. When I originally brought up sequence points, I was actually referring to the ANSI C standard, where they are used to define when certain code has undefined behaviour (the canonical case being 'x = x++'). Effectively, only at a sequence point can one guarantee that all previous code has finished its side-effects. This allows compilers to optimise such code as they see fit. Inform does not need this sort of specification until someone else produces another compiler to compile Inform source... Inform, however, seems to have a quite adequate concept of a sequence point by inserting one at the start of every statement, so I think that I am just messing things up by bringing the ANSI C standard into this at all. Inform is not C. I'm sorry, I won't do it again :-) >GN> Does anyone want something substantially different to this? >GN> I'm prepared to implement any reasonably clear definition of >GN> "sequence point". I think the only likely extension is to stick a sequence point before the RHS of the && and || operators, since they involve implicit sequencing. >The above sounds *fairly* intuitive - the only difference is that if I >were on the "for" S.P. and sequence-single-stepped, I'd probably expect >it to perform the first assignment, j=56 (unless visually prompted >otherwise). I can live with this. I assume that you would be visually prompted, as the 'cursor' (or whatever) would have moved to the start of the 'j=56'. >GN> There is also the issue of whether a sequence point should >GN> be linked to a specific character in the source code, rather >GN> than only a specific line number and file (as at present). >GN> Obviously I'm a lazy character, but I can put up with whichever >GN> is decided. I think the character position *is* necessary, especially with sequence points in 'for' loops and the like. >[source character position] >[I think we can make this a byte, and have 255 indicate "somewhere > beyond char 254" - people using longer lines than that are asking for > trouble! ;-p] I agree. IMHO, the only time it is at all acceptable to have very long lines is when they are constant strings, and all the meaningful code is at the beginning. >MF> Might involve YA step command though - are we creating the EMACS of >MF> debuggers? (esp. in light of desired programmable features...) >I've no idea what YA stepping is, I'm afraid. YA == Yet Another. Sorry, I thought this one was fairly widely known (maybe it's only rg.roguelike.nethack). I was just referring to the fact that whenever anyone brings up a feature they really (really) want, it seems to involve a new style of stepping... >As for the feature list - >I tried to put in as much as possible so we could prune it. So far it's >just grown! I'd like to categorise features as (a) essential for first >release, (b) desirable for later, or (c) pipe-dreams that we should >forget about if we're going to get anything done. The trouble is that much of it falls in the (a) category, although I suppose quite a bit could be put in (b) if we're ruthless. Out of the features brought up so far, I think the only one deserving of (c) is "run the program and it debugs your program overnight while you sleep.", which although it might do for a PhD thesis is unlikely to be put in as a feature in the foreseeable future. (Actually, did anyone bring that up, or have I just made it up? I've just grepped the file containing all the posts on this topic and only one person mentioned sleep, and that was in the context of 'only 2 hours thereof'). Actually, I only replied to this to clarify YA. Oh well. Martin -- From owner-z-machine@mail2.gmd.de Thu Mar 20 06:11:36 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id GAA08006 for ; Thu, 20 Mar 1997 06:11:34 -0600 Received: by mail2.gmd.de id AA02950 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 12:48:03 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA03547 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 12:47:08 +0100 Received: from walter.doc.ic.ac.uk by mail.gmd.de with SMTP id AA07327 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 12:46:59 +0100 Received: from oak61.doc.ic.ac.uk [146.169.33.61] by walter.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0w7gI4-0000KI-00; Thu, 20 Mar 1997 11:45:52 +0000 Received: by oak61.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0w7gI3-0002CPC; Thu, 20 Mar 97 11:45 GMT Message-Id: From: "Martin Frost" Date: Thu, 20 Mar 1997 11:45:50 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: Re: [z-machine] Infix Group: please post your list to my address Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: >From Stefan Jokisch: >In response to John Wood: >We probably cannot extend this scheme to arbitrary story files without >debugging information. My problem here is that I cannot even think of >a reasonable definition of a loop, let alone give an algorithm. How about restricting it just to the 'normal' Inform looping constructs (while, for, objectloop etc)? If we have a source column stored with each sequence point (see other reply) then we can just do a simple check for these. >[not worthwhile adding display dictionary command] Aha! At last, a feature that would be nice but not essential (as opposed to (nearly, if not) all of the features so far). Better would be a scripting/ macro language in Infix so that a custom printing routine could be hacked together for printing any special-format tables that people have in their games. Maybe the best way to do this would be to allow Infix to read an extra Z-code file with printing routines in... (This is definitely a (b) and maybe a (c) (see John Wood's post for details of his feature classification). Martin -- From owner-z-machine@mail2.gmd.de Thu Mar 20 07:10:34 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id HAA08143 for ; Thu, 20 Mar 1997 07:10:26 -0600 Received: by mail2.gmd.de id AA07409 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 13:46:31 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA28511 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 13:46:28 +0100 Received: from walter.doc.ic.ac.uk by mail.gmd.de with SMTP id AA15739 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 13:46:25 +0100 Received: from oak61.doc.ic.ac.uk [146.169.33.61] by walter.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0w7hEb-0000VH-00; Thu, 20 Mar 1997 12:46:21 +0000 Received: by oak61.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0w7hEa-0002CPC; Thu, 20 Mar 97 12:46 GMT Message-Id: From: "Martin Frost" Date: Thu, 20 Mar 1997 12:46:19 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: Re: [z-machine] GNUSTO-Z eval stack order Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: >4.7 Assigning each of the possible 7 supplied arguments a letter a-g in > order, each bit is set if its respective argument is supplied. The > evalation stack count allows the reconstruction of the chain of frame > pointers for all possible stack models. Words on the evaluation stack > are also stored most recent first. > ^^^^ >This is inconsistent with the order the frames are stored. Is this >intentional? It is *sort of* intentional. The first draft specified most recent first for both stacks, on the (admittedly flawed) assumption that stacks are generally assumed to grow downward, and so this could make life easier for some interpreters. Since then, I realised that it was necessary to store the call stack least recent first, so that the unused portion is at the end, as otherwise either a preliminary length-finding pass or a block move afterward is necessary for downward *and* upward stacks (the length of the call stack cannot be deduced without scanning the whole chunk). The original most-recent-first order was retained for the eval stack, as its length is stored explicitly in the call stack frame, and so the words can be loaded in the correct place immediately. If people would prefer consistency, then I am quite prepared to change this such that both stacks are stored least-recent-first. Does the fact that you are finding all these errors mean that you are the first to try implementing the format? There is an error in paragraph 4.7, however, as the word 'also' is certainly inconsistent with the word 'most'... Which word gets changed will depend on whether people prefer consistency or (possible) ease of implementation. Maybe consistency is best (for independence of hardware byte-ordering and compiler structure/array packing, the stacks probably have to be written a byte/word at a time anyway, so (possibly) having to reverse the stacks while writing is no problem). What do other people think? >Also, is the order of 'UMem' or 'CMem' relative to 'Stks' specified? No. The only required ordering is that 'IFhd' comes before any of 'CMem', 'UMem', 'Stks'. General chunks ('ANNO', 'AUTH', '(c) ') and the other special chunk ('IntD') may appear anywhere. This can of course be changed if people require it, but I couldn't see any need for it. The general principle behind required chunk orderings is that a chunk comes *after* any chunk which is required to make sense of it. Therefore 'IFhd' comes early in the file, both so we can reject incorrect story files without reading the whole save file, and because it is required for decoding 'CMem' chunks. (It might be sensible to put 'IntD' chunks referring to the story file before 'IFhd'. Opinions?) Incidentally, I have noticed two further errors, albeit minor ones: section 2.2 proclaims the existence of an 'OSdp' chunk, which no longer exists - its functionality is replaced by an extended 'IntD' chunk. The section numbering on the 'IntD' line is also incorrect because of this. Therefore the last two lines of 2.2 change to a single line: 'IntD' 7.8 Mental note: it is a bad idea to write any sort of index while the document is unstable. The second minor error is that the expansion of the acronym 'QUETZAL' is missing an 'efficiently'. As I said, a minor error. On a related issue, is there a need for some sort of test suite to check that interpreters are writing the format correctly? Martin -- From owner-z-machine@mail2.gmd.de Thu Mar 20 07:59:25 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id HAA08286 for ; Thu, 20 Mar 1997 07:59:23 -0600 Received: by mail2.gmd.de id AA11297 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 14:34:40 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA30896 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 14:34:37 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA23486 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 14:34:35 +0100 Received: from jokisch ([194.74.138.36]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAA8453 for ; Thu, 20 Mar 1997 14:25:15 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: [z-machine] Yet another Unicode proposal Date: Thu, 20 Mar 1997 14:32:34 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970320132514.AAA8453@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: My latest idea is to introduce an opcode for printing all those Unicode characters which aren't listed in the Unicode table of the story file. This new opcode would have to be in the extended set of opcodes since all 1OP and VAR opcodes are already in use. It could print up to four Unicode characters which are given as arguments and send them to the output streams. On output stream #3 Unicode characters would still be replaced with "?". At first it looks as if this approach doesn't solve any problems whereas it obviously imposes new restrictions. However, there are two important reasons why I prefer this proposal to the use of 10-bit character codes: (i) simplicity Graham's proposal leads to 5 different character types: +---+-------------------------+-------+------------+ | 1 | characters in A0 | 26 | 3 bits | +---+-------------------------+-------+------------+ | 2 | characters in A1 and A2 | 50 | 6 bits | +---+-------------------------+-------+------------+ | 3 | ZSCII char's | ~192 | 20 bits | +---+-------------------------+-------+------------+ | 4 | preferred Unicode | ~256 | 20 bits | +---+-------------------------+-------+------------+ | 5 | general Unicode | ~64K | 20/40 bits | +---+-------------------------+-------+------------+ Note that types 1 and 2 can be freely selected from type 3; if the game doesn't set them then they default to the Latin alphabet plus punctuation marks. The 1st half of type 3 is made up of ASCII characters, whereas the 2nd half defaults to the standard set of accented characters -- unless the user makes his own selections from type 5. Type 4 can be any of the 256 character groups which make up type 5, though it is undefined by default. My proposal simplifies this a bit by merging types 4 and 5. (ii) clarity My design shows that games cannot use arbitrary Unicode characters in object names or dictionary words. Support for Unicode is an additional feature, not an integral part of the Z-machine. As far as Inform is concerned, I suggest to introduce a new command to print Unicode characters. This shouldn't be limited to four characters, of course. Every Unicode character that appears elsewhere must obviously belong to type 3, i.e. it must be listed in the Unicode table. In other words, Inform can easily decide whether a given Unicode is type 3 or not; the user need not bother (up to the point where Inform signals an "ZSCII table full" error). While we are at it, why not add another opcode to check for the availability of a given Unicode character? One last thought: If we are planning to keep our standard set of accented characters (*sigh*), then maybe we should throw in a few more characters. For instance, it takes only a few more accented characters to support Turkish. -- Stefan From owner-z-machine@mail2.gmd.de Thu Mar 20 08:52:23 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id IAA08423 for ; Thu, 20 Mar 1997 08:52:03 -0600 Received: by mail2.gmd.de id AA18297 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 15:29:57 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA13437 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 15:29:54 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA31165 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 15:29:49 +0100 Received: by wanda.vf.pond.com (8.6.12/gw.1.0) id JAA14196; Thu, 20 Mar 1997 09:30:33 -0500 Date: Thu, 20 Mar 1997 09:30:33 -0500 From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703201430.JAA14196@wanda.vf.pond.com> To: mdf@doc.ic.ac.uk, z-machine@gmd.de Subject: Re: [z-machine] GNUSTO-Z eval stack order Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: } call stack cannot be deduced without scanning the whole chunk). The original } most-recent-first order was retained for the eval stack, as its length is } stored explicitly in the call stack frame, and so the words can be loaded } in the correct place immediately. The reason I have problems with the inconsistency is that my stack is during writing, I'm scanning my interpreter stack from the bottom up. To write the evaluation stack in the other order requires either that I temporarily copy the evaluation stack (in reverse order), or that I reverse the scan partway through. Since I also build the stack from bottom up, there's similar problems during the read. } If people would prefer consistency, then I am quite prepared to change } this such that both stacks are stored least-recent-first. Does the fact } that you are finding all these errors mean that you are the first to try } implementing the format? Maybe. I'm trying to implement it for ZPlet, which has an unusual stack format. In its case, consistency and ease of implementation are the same. From owner-z-machine@mail2.gmd.de Thu Mar 20 11:40:23 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id LAA09088 for ; Thu, 20 Mar 1997 11:40:19 -0600 Received: by mail2.gmd.de id AA22631 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 18:18:11 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA30281 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 18:18:08 +0100 Received: from netcom4.netcom.com by mail.gmd.de with SMTP id AA16846 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 18:18:06 +0100 Received: from localhost (erkyrath@localhost) by netcom4.netcom.com (8.6.13/Netcom) id JAA21920; Thu, 20 Mar 1997 09:17:54 -0800 Date: Thu, 20 Mar 1997 09:17:54 -0800 (PST) From: Andrew Plotkin X-Sender: erkyrath@netcom4 To: Z-Machine List Subject: Re: [z-machine] GNUSTO-Z eval stack order In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: On Thu, 20 Mar 1997, Martin Frost wrote: > btw: I was wondering about a possible extension in allowing the UMem chunk > to contain the *whole* Z-code file. Although this would be wasteful for > general saving, it would be completely self-contained, and therefore would > not need any external references to story files. The IFhd chunk would then be > mainly redundant, although it would be needed to keep the initial PC. This > situation is currently an error (dynamic memory too long), but could be made > legal. The main problem would be that RESTART would either not make sense > or would just take us back to the saved state. > > What do people think about this? Yeeech. Having RESTART fail is not admissible. If you want to save the entire original game file in addition to the current memory state, that's at least consistent, but I think it's way outside the scope of what we're trying to accomplish here. --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves...." From owner-z-machine@mail2.gmd.de Thu Mar 20 12:00:58 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id MAA09171 for ; Thu, 20 Mar 1997 12:00:55 -0600 Received: by mail2.gmd.de id AA31992 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 18:33:35 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA32092 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 18:33:06 +0100 Received: from netcom4.netcom.com by mail.gmd.de with SMTP id AA13381 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 18:33:03 +0100 Received: from localhost (erkyrath@localhost) by netcom4.netcom.com (8.6.13/Netcom) id JAA25251; Thu, 20 Mar 1997 09:33:01 -0800 Date: Thu, 20 Mar 1997 09:33:01 -0800 (PST) From: Andrew Plotkin X-Sender: erkyrath@netcom4 To: Z-Machine List Subject: Re: [z-machine] Infix Group: please post your list to my address In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: On Thu, 20 Mar 1997, Martin Frost wrote: > >[not worthwhile adding display dictionary command] > > Aha! At last, a feature that would be nice but not essential (as opposed to > (nearly, if not) all of the features so far). Better would be a scripting/ > macro language in Infix so that a custom printing routine could be hacked > together for printing any special-format tables that people have in their > games. I have a slightly glazed expression in my eyes now. If a display-dictionary command is "not essential", how is a built-in scripting language *better*? I officially state: If I were the lead developer on this project, I'd already be bending code. I wouldn't be worrying about auto-detection of loops, or sequence points. I'd *rather* rip apart an existing chunk of code than never get around to implementing anything. On the same note, I'd rather have Infix know about and display Inform-version-specific tables. Using hardwired code. If Inform changes the format of that table, that command in Infix will break until a new version is released. As long as Infix can recognize this situation and display a graceful error rather than crashing, I'm ok with it. --Z The above is a rant, and should not be taken as suggestions on how to proceed with Infix. However, if it is decided that a scripting/macro language is going to be in the *first* release of Infix, I may just write my own debugger. Grn. --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." From owner-z-machine@mail2.gmd.de Thu Mar 20 12:59:01 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id MAA09550 for ; Thu, 20 Mar 1997 12:58:59 -0600 Received: by mail2.gmd.de id AA03943 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 19:23:32 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA07668 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 19:23:29 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA19563 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 19:23:27 +0100 Received: by wanda.vf.pond.com (8.6.12/gw.1.0) id NAA07876; Thu, 20 Mar 1997 13:19:54 -0500 Date: Thu, 20 Mar 1997 13:19:54 -0500 From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703201819.NAA07876@wanda.vf.pond.com> To: mdf@doc.ic.ac.uk, z-machine@gmd.de Subject: Re: [z-machine] GNUSTO-Z eval stack order Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: } btw: I was wondering about a possible extension in allowing the UMem chunk } to contain the *whole* Z-code file. Although this would be wasteful for } general saving, it would be completely self-contained, and therefore would } not need any external references to story files. The IFhd chunk would then be } mainly redundant, although it would be needed to keep the initial PC. This } situation is currently an error (dynamic memory too long), but could be made } legal. The main problem would be that RESTART would either not make sense } or would just take us back to the saved state. } What do people think about this? I'm with Andrew -- if we want to do something like this, better to include the original story file as a separate chunk in addition to the saved memory chunk. From owner-z-machine@mail2.gmd.de Thu Mar 20 14:51:08 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id OAA10030 for ; Thu, 20 Mar 1997 14:51:05 -0600 Received: by mail2.gmd.de id AA18941 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 21:24:01 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA06292 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 21:23:59 +0100 Received: from relay-7.mail.demon.net by mail.gmd.de with SMTP id AA28252 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 21:23:55 +0100 Received: from gnelson.demon.co.uk ([194.222.103.187]) by relay-6.mail.demon.net id aa0617430; 20 Mar 97 19:11 GMT Date: Thu, 20 Mar 1997 19:09:47 +0000 (GMT) From: Graham Nelson Subject: [z-machine] [Infix] Sequence points and DEBF format To: Z-Machine Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: none X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Right, then: here's the exact description of sequence points and the debugging file format from what will be the Inform 6.12 Technical Manual. Does anybody object? Please speak up quickly if so! (Note that Plotkinesque numbers are now introduced into the DEBF format.) --------------------------------------------------------------------- 12.4 Sequence points --------------- Inform marks certain positions in the code it compiles as being "sequence points". The idea is that the code can be regarded as a sequence of chunks, and the sequence points mark where these chunks begin. Roughly speaking, each different statement in Inform source code compiles to a different chunk, so that statements correspond closely to sequence points. Sequence points are marked in assembly trace output using the notation "<*>". For instance, the source code [ WorkOutSquares counter; counter = 0; while (counter < 100) { squares-->counter = counter*counter; counter = counter + 1; } ]; produces the traced output: 6 +00008 [ WorkOutSquares counter 7 +00009 <*> store counter short_0 8 +0000c .L0 8 +0000c <*> jl counter short_100 to L1 if FALSE 9 +00011 <*> mul counter counter -> sp 9 +00015 storew long_480 counter sp 10 +0001b <*> add counter short_1 -> counter 11 +0001f jump L0 11 +00022 .L1 12 +00022 rtrue The "<*>" in front of an instruction means "the position where this instruction begins is a sequence point". We could mark the four positions in the original source code as: [ WorkOutSquares counter; <*> counter = 0; <*> while (counter < 100) { <*> squares-->counter = counter*counter; <*> counter = counter + 1; } ]; Note that the open and close braces and square brackets don't normally cause sequence points. The exact rule is that every statement, action < > command, assignment or expression in void context is at a sequence point, except as shown in the examples below: for (<*> i=0: <*> i<45: <*> i++) ... "for" loops contain 0 to 3 sequence points, depending on whether there's any code compiled in the three parts of the specification. For instance for (::) <*> print "Madness!"; contains no sequence point corresponding to the "for" specification. <*> objectloop (<*> O ofclass Coin) <*> print (name) O; "objectloop" normally generates two sequence points: at the start, where the variable is initialised, and then where it's tested. However, loops over the contents of particular objects work differently: <*> objectloop (O in Mailbox) <*> print (name) O; (Because the test "O in Mailbox" is not actually being performed at run-time: instead, O is looping through the tree.) do <*> print counter++, " "; <*> until (counter < 17); Here the sequence point generated by the loop itself is attached to the "until" clause, not the "do" clause, because that's where the test is performed. "switch", "while" and "if" statements are not exceptions to the usual rule (1 statement = 1 sequence point at the beginning), but it might be useful to give some examples anyway: <*> switch(counter) { 1: <*> print "One^"; 2, 3: <*> print "Two or three^"; default: <*> print "Neither^"; } <*> if (i == 17) <*> print "i is 17"; else <*> print "i isn't 17"; <*> while (i<100) <*> print i++; The following is true: Except possibly in code explicitly assembled using the "@" notation, at each sequence point the Z-machine stack is empty and no important information is held in the global variables reserved by Inform as "registers": thus, it's safe for a debugger to switch execution from any sequence point in a routine to any other. No two sequence points can be at the same position in either the source code or the compiled code. Every sequence point corresponds to a definite position in the source code (because the veneer, i.e. the code compiled from within Inform itself, contains no sequence points). But the following is _not_ true: Sequence points occur in the same order in the source code as they do in compiled code Every routine contains at least one sequence point Inform uses sequence points only to generate debugging information files for Infix, and to annotate assembly tracing output. They do not affect the code compiled. 12.5 Format of debugging information files (for Infix) ------------------------------------------------- This is a provisional specification of a format which will probably change slightly in future releases. Support for the old -k option has been re-introduced in Inform 6.12 to assist development of Infix, the projected source-level debugger for Inform. (See the minor utility program "infact", updated to 6.12 format, which prints out the contents of a debugging information file in legible form.) A debugging information file begins with a six-byte header: 0,1 the bytes $DE and then $BF (DEBF = "Debugging File") 2,3 a word giving the version number of the format used (currently 0) 4,5 a word giving the current Inform version number, in its traditional decimal form: e.g. 1612 means "6.12" The remainder of the file consists of a sequence of records, terminated by an end-of-file record. These records may be in _any_ order unless otherwise noted. Each record begins with an identifying byte, for which constants looking like *_DBR are defined in Inform's source code. A "string" is a null-terminated string of ASCII chars. A "word" is a 16-bit unsigned number, high byte first. A "line" is a sequence of four bytes: the first is the file number, the next two are a line number (a word), and the last is a character number within that line. In all three cases -- file numbers, line numbers, character numbers -- counting begins at 1. The line reference 0:0:0 is however used to mean "no such line": for instance, the metaclass "Routine" is defined at line 0:0:0, because it's defined by the compiler, not in any source code. Character positions greater than 255 in any line are recorded simply as 255. An "address" is a 24-bit unsigned number, a sequence of three bytes (high byte, middle byte, low byte). All addresses are counted in bytes (rather than being Z-machine packed addresses). EOF_DBR (byte: 0) End of the debugging file. FILE_DBR (byte: 1) 1 byte, counting from 1 string string One of these records always appears before any reference to the source code file in question. CLASS_DBR (byte: 2) string line line OBJECT_DBR (byte: 3) word string line line GLOBAL_DBR (byte: 4) byte string ATTR_DBR (byte: 5) word string PROP_DBR (byte: 6) word string FAKE_ACTION_DBR (byte: 7) word string Note that the numbering of fake actions differs in Grammar Versions 1 and 2. ACTION_DBR (byte: 8) word string HEADER_DBR (byte: 9) 64 bytes This is provided in order to check that a debugging information file (probably) does match a given story file. ROUTINE_DBR (byte: 11) word line address string then for each local variable: string terminated by a zero byte. Note that the PC start address is in bytes, relative to the start of the story file's code area. Routines are numbered upward from 0, and in each case the ROUTINE_DBR, LINEREF_DBR and ROUTINE_END_DBR records occur in order. LINEREF_DBR (byte: 10) word word and then, for each sequence point: line word The PC offset for each sequence point is in bytes, from the start of the routine. (Note that the initial byte of the routine, giving the number of local variables for that routine, is at PC offset 0: thus the actual code begins at PC offset 1.) It is possible for a routine to have no sequence points (as in the veneer, or in the case of code reading simply "[; ];"). ROUTINE_END_DBR (byte: 14) word line address MAP_DBR (byte: 13) A sequence of records consisting of: string address terminated by a zero byte. The current names of structures consist of: "abbreviations table" "header extension" "alphabets table" "Unicode table" "property defaults" "object tree" "common properties" "class numbers" "individual properties" "global variables" "array space" "grammar table" "actions table" "parsing routines" "adjectives table" "dictionary" "code area" "strings area" Other names made be added later, and some of the above won't be present in all files ("Unicode table", for instance). Locations are byte addresses inside the story file. LINEREF_DBR records will probably be compressed in future releases. -- Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom From owner-z-machine@mail2.gmd.de Thu Mar 20 18:06:18 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id SAA10800 for ; Thu, 20 Mar 1997 18:06:17 -0600 Received: by mail2.gmd.de id AA22302 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 00:46:34 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA25248 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 00:46:30 +0100 Received: from relay-11.mail.demon.net by mail.gmd.de with SMTP id AA06078 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 00:46:27 +0100 Received: from gnelson.demon.co.uk ([194.222.103.187]) by relay-11.mail.demon.net id aa1109785; 20 Mar 97 23:18 GMT Date: Thu, 20 Mar 1997 23:14:52 +0000 (GMT) From: Graham Nelson Subject: [z-machine] Consolidated Unicode proposal To: Z-Machine Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: none X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Unicode support proposal: fourth version ---------------------------------------- This latest version accepts Stefan's counter-proposal into my last version (of 9th March), so that it's by now the joint work of at least four of us (myself, Stefan, Marnix and Andrew) -- all the same, I wrote the text below, and please argue with anything unreasonable. In particular, (c) below may well deserve further discussion. But I'd like to wrap up this debate reasonably soon now. I'm leaving out the background notes: just the proposal this time. (a) Unicode translation table ----------------------------- The table whose address is stored at $36 and $37 in the Z-machine header is called the "mouse data table" in the Z-machine standard documents published up to now: however, it looks as if Infocom intended this as "header extension" and I wish to use it as such. Formally, $36 and $37 are either 0 (meaning no extension) or give the byte address of the extension table, which is in read/write memory. This is a table of words. Word 0 The number of word entries in the table (not counting this entry) Word 1 Slot for mouse X-coordinate to be written by interpreter after a mouse click Word 2 Slot for mouse Y-coordinate to be written by interpreter after a mouse click Words 3, 4, ... are currently unallocated. I propose that Word 3, if present and non-zero, give the byte address of a new table called the "Unicode translation table". The Unicode translation table has the format: Byte 0 Number of "extra characters" (0 to a maximum of 97): call this value N and then one word for each extra character, giving a Unicode value. (The maximum possible size of this table is 195 bytes.) Recall that Unicode values are 16-bit: values under 256 agree with ISO Latin-1, whereas values over 256 cover non-Latin alphabets (e.g. $10AF means Georgian capital Zhar). Values in the Unicode "private use area" are specified by the ConScript Unicode Registry, who provide a common numbering for invented scripts. When this table does not exist, either because Word 3 in the header extension is absent or because it is zero, then the contents of the table are assumed to be the "standard 0.2 set". (This will be specified properly in Standard 1.0.) The following translation rule applies: ZSCII value Unicode value 09b to 09b + N - 1 as given in the table's list of words ZSCII codes of $100 to $3ff are not defined. (b) How much Unicode do interpreters need to know? -------------------------------------------------- An interpreter should correctly print a representation of every defined character Unicode under $0100, i.e. of every defined ISO Latin1 character. (But it's fine to print "ss" in place of German sharp s, for instance, if no glyph is available.) As far as reasonably possible, it should accept these character codes from the keyboard. An interpreter can print, or not print, Unicodes between $0100 and $FFFF in whatever way it likes. If asked to print a Unicode with it has no suitable picture of, it should print a question mark. A luxury-model interpreter might be configurable to use certain fonts to cover certain Unicode ranges, and to use a particular keyboard mapping. But this is not required. In other words, the minimum position is: treat the screen and keyboard as ISO Latin-1, and print all Unicodes of $0100 and above as a question mark. (c) Two new opcodes ------------------- The following opcodes are to be introduced into Version 5 and above (but not into Versions 3 or 4): @print_unicode code; @check_unicode code -> value; The "code" is a Unicode value and may or may not be in the Unicode translation table. (i) "print_unicode" is just like "print_char", but uses Unicode instead of Z-code. If stream 3 is active, then the value must be converted from Unicode to ZSCII before being entered into the byte array being written. Unicode values which can't be translated into ZSCII (e.g. because they're exotic and not in the Unicode translation table) must be converted to 63 (ZSCII for question mark). (ii) The "value" stored by "check_unicode" contains two bits of information: Bit 0: set if the interpreter can print this character Bit 1: set if the interpreter can read this character from the keyboard I propose that the opcodes should be placed in the set at: @print_unicode at EXT:11 @check_unicode at EXT:12 [Recall that in Infocom's specification, EXT:0 to EXT:10 were introduced in Version 5 (except for EXT:5 to EXT:8, although some people think these were defined but then never implemented or used); then EXT:16 to EXT:28 (and EXT:5 to EXT:8) were added in Version 6. Thus, up to now EXT:11 to EXT:15 has been an empty space in the specification.] Graham Nelson 20th March 1997 -- Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom From owner-z-machine@mail2.gmd.de Thu Mar 20 21:05:33 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id VAA11318 for ; Thu, 20 Mar 1997 21:05:32 -0600 Received: by mail2.gmd.de id AA00273 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 03:50:43 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA06911 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 03:50:11 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA12165 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 03:50:03 +0100 Received: by wanda.vf.pond.com (8.6.12/gw.1.0) id VAA29775; Thu, 20 Mar 1997 21:50:54 -0500 Date: Thu, 20 Mar 1997 21:50:54 -0500 From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703210250.VAA29775@wanda.vf.pond.com> To: z-machine@gmd.de Subject: [z-machine] Once more on GNUSTO-Z Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Last nit to pick, I think: In all non-V6 games, there is the possibility of an evaluation stack without an associated interpreter stack frame -- that is, the story file can push things before the first call instruction. The current format isn't clear on how this situation should be handled. I propose that a dummy stack frame record (with PC, local variables, flags, and argcount all zero) be first in the 'Stks' segment in this case. From owner-z-machine@mail2.gmd.de Fri Mar 21 04:34:05 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id EAA12665 for ; Fri, 21 Mar 1997 04:34:02 -0600 Received: by mail2.gmd.de id AA05297 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 11:12:09 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA21288 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 11:12:06 +0100 Received: from walter.doc.ic.ac.uk by mail.gmd.de with SMTP id AA06865 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 11:12:05 +0100 Received: from oak69.doc.ic.ac.uk [146.169.46.69] by walter.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0w81Iq-00035i-00; Fri, 21 Mar 1997 10:12:04 +0000 Received: by oak69.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0w81Ip-0000YnC; Fri, 21 Mar 97 10:12 GMT Message-Id: From: "Martin Frost" Date: Fri, 21 Mar 1997 10:12:03 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: Re: [z-machine] Infix Group: please post your list to my address Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: >On Thu, 20 Mar 1997, Martin Frost wrote: >If a display-dictionary command is "not essential", how is a built-in >scripting language *better*? It would be better. However, it is certainly not essential, and should not even be considered for the first release (unless someone already has this half of the code written and debugged). >On the same note, I'd rather have Infix know about and display >Inform-version-specific tables. Using hardwired code. If Inform changes >the format of that table, that command in Infix will break until a new >version is released. As long as Infix can recognize this situation and >display a graceful error rather than crashing, I'm ok with it. I'd suggest this be done, and then if Infix 42 implements a scripting language this can be reimplemented in terms of that language. NOTE: I am *not* advocating putting a scripting language in atm... >The above is a rant, and should not be taken as suggestions on how to >proceed with Infix. However, if it is decided that a scripting/macro >language is going to be in the *first* release of Infix, I may just write >my own debugger. As mentioned in passing :-) above, the suggestion for a scripting language was definitely *not* intended as a feature for the first release. >Grn. Is that "grin", "groan", or "grrrrrrrrr"? :-) Martin -- From owner-z-machine@mail2.gmd.de Fri Mar 21 04:57:41 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id EAA12705 for ; Fri, 21 Mar 1997 04:57:39 -0600 Received: by mail2.gmd.de id AA06790 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 11:30:16 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA09849 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 11:30:12 +0100 Received: from walter.doc.ic.ac.uk by mail.gmd.de with SMTP id AA13270 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 11:30:09 +0100 Received: from oak69.doc.ic.ac.uk [146.169.46.69] by walter.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0w81aK-00039H-00; Fri, 21 Mar 1997 10:30:08 +0000 Received: by oak69.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0w81aJ-0000YnC; Fri, 21 Mar 97 10:30 GMT Message-Id: From: "Martin Frost" Date: Fri, 21 Mar 1997 10:30:07 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: Re: [z-machine] Once more on GNUSTO-Z Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: >Last nit to pick, I think: Oh goody! I can actually upload a new version and know that it is at least implementable! >In all non-V6 games, there is the possibility of an evaluation stack without >an associated interpreter stack frame -- that is, the story file can push >things before the first call instruction. The current format isn't clear >on how this situation should be handled. I propose that a dummy stack frame >record (with PC, local variables, flags, and argcount all zero) be first >in the 'Stks' segment in this case. That was what I had in mind, but it's missing in the definition. Right then, I'll fix that, give it one last check and upload version 1.2! Martin From owner-z-machine@mail2.gmd.de Fri Mar 21 07:33:22 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id HAA13108 for ; Fri, 21 Mar 1997 07:33:17 -0600 Received: by mail2.gmd.de id AA19543 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 13:55:55 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA02754 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 13:55:51 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA19421 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 13:55:47 +0100 Received: from jokisch ([194.74.138.41]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAC16682 for ; Fri, 21 Mar 1997 13:46:22 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Infix: what are sequence points? Date: Fri, 21 Mar 1997 12:32:57 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970321124423.AAC16682@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: > An outsider's opinion: > step == move forward by SOURCE LINE > stepi == move forward by machine instruction > Similarly for next and nexti (which don't descend into subroutines) > Everything else is category (b). > > If you want to be able to stop at more than one position within a line, > then break that line up into multiple lines and recompile. This is something we've discussed before. Look at the Inform line world!"; v = 3 * which starts with incomplete string and which ends with an equally incomplete assignment. Apparently, you cannot execute such lines; instead, you can only execute the first statement that starts on a line. The next example for (i=0:i<=9:i++) for (j=0:j<=9:j++) for (k=0:k<=9:k++) causes even more trouble: It's not at all clear what "move forward by source line" means in such a case. Finally, a debugger that depends on source code formatting doesn't appeal to me. Note that stopping at sequence point *simplifies* things, whereas your proposal tends to make them more complicated. -- Stefan From owner-z-machine@mail2.gmd.de Fri Mar 21 09:51:39 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id JAA13416 for ; Fri, 21 Mar 1997 09:51:38 -0600 Received: by mail2.gmd.de id AA24143 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 16:16:23 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA32495 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 16:16:20 +0100 Received: from KNAVE.ECE.CMU.EDU by mail.gmd.de with SMTP id AA16576 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 16:16:14 +0100 Received: (jferro@localhost) by knave.ece.cmu.edu (8.6.11/8.6.4) id KAA16534; Fri, 21 Mar 1997 10:16:05 -0500 Date: Fri, 21 Mar 1997 10:16:05 -0500 From: "Jonathan R. Ferro" Message-Id: <199703211516.KAA16534@knave.ece.cmu.edu> Organization: Electrical and Computer Engineering, CMU X-Disclaimer: This disclaimer is not required by Leader Kibo. This article does not necessarily represent the opinions of Leader Kibo. Have a nice day! X-Exclaimer: Yow! To: z-machine@gmd.de In-Reply-To: <19970321124423.AAC16682@jokisch> (s.jokisch@avu.de) Subject: Re: [z-machine] Infix: what are sequence points? Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: "Stefan" == Stefan Jokisch offers the counterexamples: Stefan> world!"; v = 3 * Stefan> Stefan> for (i=0:i<=9:i++) for (j=0:j<=9:j++) for (k=0:k<=9:k++) Well, don't do that then! -- Jon From owner-z-machine@mail2.gmd.de Fri Mar 21 14:44:47 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id OAA14603 for ; Fri, 21 Mar 1997 14:44:45 -0600 Received: by mail2.gmd.de id AA29840 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 21:20:12 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA28878 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 21:20:08 +0100 Received: from relay-11.mail.demon.net by mail.gmd.de with SMTP id AA32358 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 21:20:05 +0100 Received: from elvw.demon.co.uk ([158.152.183.71]) by relay-11.mail.demon.net id aa1120176; 21 Mar 97 20:02 GMT Date: Fri, 21 Mar 1997 19:35:58 GMT From: John Wood Reply-To: john@elvw.demon.co.uk Message-Id: <2076@elvw.demon.co.uk> To: z-machine@gmd.de Subject: Re: [z-machine] Infix Group: please post your list to my address X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 66 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Stefan Jokisch wrote, > I suggest Inform produces additional debugging information to identify > sequence points that mark the beginning of a loop. We must also know > which Z-code interval corresponds to this loop. We'll need to come up with a modification to Graham's debug-file format if we're going to use extra debug information - and it would be nice to avoid growing it any more. The starts are easy to find with sequence points - just look for the characters "for", "while", etc - but the ends are less so. Can we use "secret knowledge" about how Inform encodes loops, and examine the jump/branch instructions following soon after this point in the code? I've no idea. > The interpreter needs to check: > > After every "return" or "throw": Have we returned to an > earlier stack frame? I've already suggested that an Infix function gets called on call and return - throw should be in there too. Infix can thus do the checking here... > After every "jump" or "branch": Have we left the Z-code > interval while the stack frame is still the same? ...if we also provide an Infix function to call in these cases. There's also the set_byte point (see below). I wonder if we're getting too many "call an Infix function" points? > We probably cannot extend this scheme to arbitrary story files without > debugging information. My problem here is that I cannot even think of > a reasonable definition of a loop, let alone give an algorithm. Agreed - we need to be practical about this. [later] > My idea is that the interpreter never changes dynamic memory except by > calling a set_byte function. This function writes the address and the > old value at this address into a buffer. You can restore the state of > the dynamic memory by reading this buffer backwards. While you do so, > > a) over-write the new values in the dynamic memory with the old ones, > b) over-write the old values in the buffer with the new ones. > > Step b) is necessary to redo at a later time. Good scheme - but I think it belongs in Infix rather than the interpreter. > Writing the protocol slows the interpreter down, and this is why I did > not keep this algorithm in Frotz. However, the loss in performance is > acceptable for a debugger, I think. I think so. > Undo should not try to take back interrupts. No, but if possible it should warn that you are undoing past an interrupt call (so the user is aware that there may be side effects). > Of course, one also needs to protocol any changes to the stack. Yes. John From owner-z-machine@mail2.gmd.de Fri Mar 21 14:50:39 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id OAA14644 for ; Fri, 21 Mar 1997 14:50:38 -0600 Received: by mail2.gmd.de id AA31884 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 21:26:52 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA21332 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 21:26:50 +0100 Received: from relay-11.mail.demon.net by mail.gmd.de with SMTP id AA02522 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 21:26:47 +0100 Received: from elvw.demon.co.uk ([158.152.183.71]) by relay-10.mail.demon.net id aa1014071; 21 Mar 97 20:02 GMT Date: Fri, 21 Mar 1997 19:37:15 GMT From: John Wood Reply-To: john@elvw.demon.co.uk Message-Id: <2077@elvw.demon.co.uk> To: z-machine@gmd.de Subject: Re: [z-machine] Infix: what are sequence points? X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 20 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Martin Frost wrote, > >I've no idea what YA stepping is, I'm afraid. > > YA == Yet Another. Sorry, I thought this one was fairly widely known > (maybe it's only rg.roguelike.nethack). I was just referring to the > fact that whenever anyone brings up a feature they really (really) > want, it seems to involve a new style of stepping... It does, doesn't it? ;-) It probably is well-known - I'm not very netslang-aware, and I assumed it was YA computing abbreviation like LALR. [Debugging overnight stuff snipped - but I enjoyed it!] > Actually, I only replied to this to clarify YA. Oh well. 8-) John From owner-z-machine@mail2.gmd.de Fri Mar 21 15:02:26 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id PAA14670 for ; Fri, 21 Mar 1997 15:01:52 -0600 Received: by mail2.gmd.de id AA29490 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 21:36:14 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA14967 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 21:36:12 +0100 Received: from relay-7.mail.demon.net by mail.gmd.de with SMTP id AA04100 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 21:36:10 +0100 Received: from elvw.demon.co.uk ([158.152.183.71]) by relay-6.mail.demon.net id aa0618745; 21 Mar 97 20:02 GMT Date: Fri, 21 Mar 1997 19:38:26 GMT From: John Wood Reply-To: john@elvw.demon.co.uk Message-Id: <2078@elvw.demon.co.uk> To: z-machine@gmd.de Subject: Re: [z-machine] Infix Group: please post your list to my address X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 59 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Andrew Plotkin wrote, > I have a slightly glazed expression in my eyes now. Join the club - I've had one for a few weeks... > If a display-dictionary command is "not essential", how is a built-in > scripting language *better*? Well, it's better in that it's more general - but it's no more essential. Ben & Jerry's "Fudge Behaving Badly" is (apparently) far better than Sainsbury's economy vanilla ice cream - but since I'm allergic to eggs and milk, I'll pass anyway. > I officially state: If I were the lead developer on this project, I'd > already be bending code. I wouldn't be worrying about auto-detection > of loops, or sequence points. I'd *rather* rip apart an existing chunk > of code than never get around to implementing anything. And if *I* were lead developer (er - am I?), I'd say we're not quite ready to code yet. An extra month in design can save two or three months implementation. OTOH, I think we're ready to start getting an actual design on paper. I intend to make a start on this next time I'm sober... > On the same note, I'd rather have Infix know about and display > Inform-version-specific tables. Yes. > Using hardwired code. If necessary. > If Inform changes the format of that table, that command in Infix will > break until a new version is released. As long as Infix can recognize > this situation and display a graceful error rather than crashing, I'm > ok with it. Yup - but can we place this in category (b) and postpone the decision anyway? It doesn't have much of an effect on the Interpreter, so I think we can. > The above is a rant, and should not be taken as suggestions on how to > proceed with Infix. Fair enough - and duly noted. > However, if it is decided that a scripting/macro language is going to > be in the *first* release of Infix, I may just write my own debugger. > Grn. 8-) If that happens, I'll join you... John [Who's been celebrating a key milestone with the rest of his company all afternoon - so, if this is even less coherent than my usual ramblings, you know who to blame...] From owner-z-machine@mail2.gmd.de Fri Mar 21 15:34:37 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id PAA14800 for ; Fri, 21 Mar 1997 15:34:36 -0600 Received: by mail2.gmd.de id AA20674 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 22:16:58 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA10761 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 22:16:56 +0100 Received: from netcom.netcom.com by mail.gmd.de with SMTP id AA06665 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 22:16:53 +0100 Received: from localhost (erkyrath@localhost) by netcom.netcom.com (8.6.13/Netcom) id NAA08841; Fri, 21 Mar 1997 13:16:46 -0800 Date: Fri, 21 Mar 1997 13:16:45 -0800 (PST) From: Andrew Plotkin X-Sender: erkyrath@netcom To: Z-Machine List Subject: Re: [z-machine] Consolidated Unicode proposal In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: On Thu, 20 Mar 1997, Graham Nelson wrote: > The following opcodes are to be introduced into Version 5 and above > (but not into Versions 3 or 4): > > @print_unicode code; > @check_unicode code -> value; > > The "code" is a Unicode value and may or may not be in the Unicode > translation table. I hate to keep bringing up the paranoid programmer's point of view, but I'd really be happier if there was some way for the game to tell if the interpreter supports these two opcodes. Ideally, we can add new opcodes to V5 and V8. In practice, any game which uses them will risk either crashing or producing an ugly (and irrecoverable) error -- depending on which interpreter is used. I guess the standard procedure is a header bit which is zero in the game file, and must be set 1 by the interpreter if it provides @print_opcode and @check_unicode. --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." From owner-z-machine@mail2.gmd.de Fri Mar 21 15:44:47 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id PAA14947 for ; Fri, 21 Mar 1997 15:44:45 -0600 Received: by mail2.gmd.de id AA30255 (5.67b8/IDA-1.5 for z-machine-out); Fri, 21 Mar 1997 22:08:49 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA18836 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 22:08:46 +0100 Received: from relay-11.mail.demon.net by mail.gmd.de with SMTP id AA05276 (5.67b8/IDA-1.5 for ); Fri, 21 Mar 1997 22:08:44 +0100 Received: from elvw.demon.co.uk ([158.152.183.71]) by relay-10.mail.demon.net id aa1014035; 21 Mar 97 20:02 GMT Date: Fri, 21 Mar 1997 19:34:41 GMT From: John Wood Reply-To: john@elvw.demon.co.uk Message-Id: <2075@elvw.demon.co.uk> To: z-machine@gmd.de Subject: Re: [z-machine] Infix: what are sequence points? X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 25 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Jonathan R. Ferro writes, > An outsider's opinion: But are you a potential Infix user? If so, your opinions are particularly valuable, since they're not coloured by having to implement anything. Not that *that* seems to have held any of us back from adding new features to the list... > step == move forward by SOURCE LINE > stepi == move forward by machine instruction > Similarly for next and nexti (which don't descend into subroutines) > Everything else is category (b). Now *that's* a minimal set! You'd probably want some inspection stuff too, otherwise the stepping's not going to do you any good. I think we should go for a set somewhere between yours and Martin's. > If you want to be able to stop at more than one position within a > line, then break that line up into multiple lines and recompile. Would you use a "steps" sequence-point version? That is, do you class it as category (b) (postpone for later) or (c) (forget it)? John From owner-z-machine@mail2.gmd.de Sat Mar 22 00:39:17 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id AAA16491 for ; Sat, 22 Mar 1997 00:39:16 -0600 Received: by mail2.gmd.de id AA17421 (5.67b8/IDA-1.5 for z-machine-out); Sat, 22 Mar 1997 07:24:45 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA26583 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 07:24:42 +0100 Received: from netcom17.netcom.com by mail.gmd.de with SMTP id AA24370 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 07:24:40 +0100 Received: from localhost (erkyrath@localhost) by netcom17.netcom.com (8.6.13/Netcom) id WAA07206; Fri, 21 Mar 1997 22:24:39 -0800 Date: Fri, 21 Mar 1997 22:24:38 -0800 (PST) From: Andrew Plotkin X-Sender: erkyrath@netcom17 To: Z-Machine List Subject: [z-machine] TerpEtude Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Vast excitement and discussion so far... Heh. Ok, two issues have come up that I know of. 1: The << and >> characters. Nobody has posted an opinion about which comes first. I have not found any information about which came first in the German version of Zork (that *is* where they're from, originally, right?) I vote that Graham decides, posts what he decides, puts it in the next version of the Z-spec and the next version of Inform, and the matter is closed. 2: "Pre-loading of input line" (or so I labelled it in the TerpEtude menu) This is the feature where the game calls @read buffer parse, and buffer->1 is not zero. According to the spec, "if byte 1 contains a positive value at the start of the input, then read assumes that number of characters are left over from an interrupted previous input, and writes the new characters after those already there." (Note that this has nothing to do with timed input.) When I implemented this in XZip and MaxZip, I assumed the interpreter should print this left-over text. In other words, if the game prints ">" and then calls @read buffer with buffer containing 160 5 'G' 'i' 'v' 'e' 'n' then the interpreter should print "Given" after the ">" and allow the user to edit those five letters, say by backspacing over them. Upon inspection of the Mac Infocom interpreter, I think I was wrong. The interpreter is supposed to assume that the *game* printed "Given". In other words, the game would actually print ">Given" before calling @read, and then the interpreter would let those last five characters stand as the editable input. I think the spec should make this clear, and also say that the game *must* print the pre-loaded text if it is to use this feature. If it doesn't, then the interpreter is going to do something strange. The current release of TerpEtude demonstrates this, since it does not in fact print the pre-loaded text. (What happens in the Mac Infocom interpreter is that it allows the user to backspace over N characters of the prompt.) Note that this is just a tremendous pain in my butt, since my interpreters like to display the user input in boldface. I'm going to have to delete the last N characters printed by the game and redisplay them in bold. Price of backwards compatibility... For timed input, this issue arises twice. First, there may be pre-loaded input when @read is called. This is the same case as above, only with four arguments to @read instead of two, so it should (I *hope*) be handled the same way. Second, a timer interrupt may occur with user input already in the buffer. If the timer interrupt prints some text, it's the *interpreter's* responsibility to re-print the already-typed input text for further user editing. This is not very consistent with the case described above, but it seems to be what the Mac Infocom interpreter does. TerpEtude *does* test this correctly, in the "Timed full-line input" test. Have I made any mistakes? --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." From owner-z-machine@mail2.gmd.de Sat Mar 22 03:08:49 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id DAA16864 for ; Sat, 22 Mar 1997 03:08:48 -0600 Received: by mail2.gmd.de id AA06103 (5.67b8/IDA-1.5 for z-machine-out); Sat, 22 Mar 1997 09:55:50 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA14029 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 09:55:48 +0100 Received: from hpcom.rz.hu-berlin.de by mail.gmd.de with SMTP id AA23871 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 09:55:47 +0100 Received: from ejoker.rz.hu-berlin.de by hpcom.rz.hu-berlin.de with SMTP (1.38.193.5/15.6-10.92) id AA02795; Sat, 22 Mar 1997 09:54:31 +0100 Received: from localhost by joker.rz.hu-berlin.de (8.6.4) id JAA14774; Sat, 22 Mar 1997 09:55:47 +0100 From: h0142kdd@rz.hu-berlin.de () Message-Id: <199703220855.JAA14774@joker.rz.hu-berlin.de> Subject: Re: [z-machine] TerpEtude To: z-machine@gmd.de Date: Sat, 22 Mar 1997 09:55:46 +0100 (MET) In-Reply-To: from "Andrew Plotkin" at Mar 21, 97 10:24:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: > Ok, two issues have come up that I know of. > > 1: The << and >> characters. Nobody has posted an opinion about which > comes first. I have not found any information about which came first in > the German version of Zork (that *is* where they're from, originally, > right?) >> comes first. Character code 162 is >>, 163 is <<. So Frotz and the Z-Spec 0.99 and TerpEtude are right, while Inform 6.11 is wrong. Now that was easy... -- Dave From owner-z-machine@mail2.gmd.de Sat Mar 22 07:34:00 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id HAA17459 for ; Sat, 22 Mar 1997 07:33:58 -0600 Received: by mail2.gmd.de id AA02437 (5.67b8/IDA-1.5 for z-machine-out); Sat, 22 Mar 1997 14:21:14 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA09552 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:21:11 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA02577 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:21:08 +0100 Received: from jokisch ([194.74.138.20]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAB22209 for ; Sat, 22 Mar 1997 14:11:42 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Infix Group: please post your list to my address Date: Sat, 22 Mar 1997 13:48:05 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970322131140.AAB22209@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: John Wood wrote: [About my proposal concerning stepping over loops:] > We'll need to come up with a modification to Graham's debug-file format > if we're going to use extra debug information - and it would be nice to > avoid growing it any more. The starts are easy to find with sequence > points - just look for the characters "for", "while", etc - but the ends > are less so. Can we use "secret knowledge" about how Inform encodes > loops, and examine the jump/branch instructions following soon after > this point in the code? I've no idea. IMO the Infix core should never ever refer to the source code! I still think we need additional debug information to implement stepping over loops. Anyway, I consider this a (b) feature, and we don't have to worry about this now. [About my proposal for undo and redo:] > Good scheme - but I think it belongs in Infix rather than the > interpreter. I agree with you here. Once again, I consider this a (b) feature. -- Stefan From owner-z-machine@mail2.gmd.de Sat Mar 22 07:36:57 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id HAA17465 for ; Sat, 22 Mar 1997 07:36:54 -0600 Received: by mail2.gmd.de id AA11514 (5.67b8/IDA-1.5 for z-machine-out); Sat, 22 Mar 1997 14:21:15 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA22281 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:21:13 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA30826 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:21:11 +0100 Received: from jokisch ([194.74.138.20]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAD22209 for ; Sat, 22 Mar 1997 14:11:45 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Infix Group: please post your list to my address Date: Sat, 22 Mar 1997 14:10:06 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970322131140.AAD22209@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Andrew Plotkin wrote: > I officially state: If I were the lead developer on this project, I'd > already be bending code. I wouldn't be worrying about auto-detection of > loops, or sequence points. I'd *rather* rip apart an existing chunk of > code than never get around to implementing anything. Although we surely must take care not to debate forever, I agree with John that a good design can save a lot of work in the end. This is especially true as this project involves several people, interpreters and Inform. How do you start coding, if you don't even know if the interpreter runs Infix or Infix runs the interpreter? If you don't know what the debugging information looks like? If you have no clear idea of what a program step is? And so forth... > On the same note, I'd rather have Infix know about and display > Inform-version-specific tables. Using hardwired code. If Inform changes > the format of that table, that command in Infix will break until a new > version is released. As long as Infix can recognize this situation and > display a graceful error rather than crashing, I'm ok with it. It seems several people want Infix to display grammar tables, though nobody has given a reason why he thinks so. My point is that grammar tables are most easily viewed in the source code; and there's always infodump to inspect the story file. Anyway, this shouldn't be an (a) feature. -- Stefan From owner-z-machine@mail2.gmd.de Sat Mar 22 07:38:40 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id HAA17474 for ; Sat, 22 Mar 1997 07:38:38 -0600 Received: by mail2.gmd.de id AA11762 (5.67b8/IDA-1.5 for z-machine-out); Sat, 22 Mar 1997 14:22:19 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA09849 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:22:17 +0100 Received: from walter.doc.ic.ac.uk by mail.gmd.de with SMTP id AB01936 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:22:15 +0100 Received: from oak43.doc.ic.ac.uk [146.169.32.43] by walter.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0w8QkM-0005OJ-00; Sat, 22 Mar 1997 13:22:10 +0000 Received: by oak43.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0w8QkL-00026jC; Sat, 22 Mar 97 13:22 GMT Message-Id: From: "Martin Frost" Date: Sat, 22 Mar 1997 13:22:09 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: [z-machine] Latest save-file format spec Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: I have uploaded the latest, corrected, version of the save-file spec to GMD. It is at ftp:/ftp.gmd.de/if-archive/infocom/interpreters/specification/savefile_12.txt I hope there are no further errors *sigh* Martin From owner-z-machine@mail2.gmd.de Sat Mar 22 07:38:51 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id HAA17478 for ; Sat, 22 Mar 1997 07:38:48 -0600 Received: by mail2.gmd.de id AA15538 (5.67b8/IDA-1.5 for z-machine-out); Sat, 22 Mar 1997 14:21:24 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA07680 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:21:22 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA01977 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:21:09 +0100 Received: from jokisch ([194.74.138.20]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAC22209 for ; Sat, 22 Mar 1997 14:11:44 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] TerpEtude Date: Sat, 22 Mar 1997 13:50:51 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970322131140.AAC22209@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Andrew Plotkin wrote: [shortened] > 2: "Pre-loading of input line" > > This is the feature where the game calls @read buffer parse, and buffer->1 > is not zero. According to the spec, "if byte 1 contains a positive value > at the start of the input, then read assumes that number of characters are > left over from an interrupted previous input, and writes the new > characters after those already there." > > When I implemented this in XZip and MaxZip, I assumed the interpreter > should print this left-over text. > > Upon inspection of the Mac Infocom interpreter, I think I was wrong. > > I think the spec should make this clear, and also say that the game *must* > print the pre-loaded text if it is to use this feature. > > Note that this is just a tremendous pain in my butt, since my interpreters > like to display the user input in boldface. I'm going to have to delete > the last N characters printed by the game and redisplay them in bold. > Price of backwards compatibility... > This feature is used by "Beyond Zork", "Zork Zero" and "Shogun". Yes, the game is responsible for printing the "left-over" text. The text need not necessarily be left over from any previous input line, it may as well be completely new. Maybe the Spec isn't clear enough. Personally, I think this is the most unfortunate feature of the Z-machine design. Consider the following side effects: Pre-loaded input lines are used while transscription is on. The game has already sent the text to the screen, i.e. the text is also written to the transscription file. Now the player deletes this text. Poor interpreter has no other choice than to remove the text from the transscription file. AFAIK, only Frotz gets this right and even Infocom's interpreters fail to produce a proper transscription file. Note that this is different in V6, since a) the games themselves take care to clear the transscription flag of the current window while they print the text, b) the interpreters are no longer responsible for sending the input lines to the transscription file. Another problem arises with recording and replaying of the player's input. Before an interpreter can print an input line from a command file, it has to the remove the pre-loaded text from the screen. To make things worse, Beyond Zork prints uppercase letters to the screen, whereas it writes lowercase letters to the input buffer. Naturally, this confuses every interpreter with proportional width fonts. I have no clue how to fix this, sorry. Finally, the pre-loaded text may contain accented character codes. True, this is a very exotic case, but a good interpreter should handle it. As you said, it's a tremendous pain. But if you observe the function key usage of the three games mentioned above, it can only work this way. > For timed input, this issue arises twice. First, there may be pre-loaded > input when @read is called. This is the same case as above, only with four > arguments to @read instead of two, so it should (I *hope*) be handled the > same way. > > Second, a timer interrupt may occur with user input already in the buffer. > If the timer interrupt prints some text, it's the *interpreter's* > responsibility to re-print the already-typed input text for further user > editing. This is not very consistent with the case described above, but it > seems to be what the Mac Infocom interpreter does. TerpEtude *does* test > this correctly, in the "Timed full-line input" test. > This is required by "Borderzone". More precisely you should say "if the timer interrupt prints some text to the same window..." since output activities in other windows don't count. Frotz re-draws the input line if the cursor is placed at the left margin; this works as Borderzone does not print a new prompt during its interrupt routines. I haven't tested how Infocom's interpreters detect this case. -- Stefan From owner-z-machine@mail2.gmd.de Sat Mar 22 07:40:23 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id HAA17489 for ; Sat, 22 Mar 1997 07:40:20 -0600 Received: by mail2.gmd.de id AA30060 (5.67b8/IDA-1.5 for z-machine-out); Sat, 22 Mar 1997 14:21:14 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA03255 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:21:11 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA02451 (5.67b8/IDA-1.5 for ); Sat, 22 Mar 1997 14:21:08 +0100 Received: from jokisch ([194.74.138.20]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAA22209 for ; Sat, 22 Mar 1997 14:11:41 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Consolidated Unicode proposal Date: Sat, 22 Mar 1997 11:42:22 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970322131140.AAA22209@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Andrew Plotkin wrote: > On Thu, 20 Mar 1997, Graham Nelson wrote: > > > The following opcodes are to be introduced into Version 5 and above > > (but not into Versions 3 or 4): > > > > @print_unicode code; > > @check_unicode code -> value; > > I hate to keep bringing up the paranoid programmer's point of view, but > I'd really be happier if there was some way for the game to tell if the > interpreter supports these two opcodes. Simple: A game only needs to check whether its interpreter complies to standard 1.0 or higher. I'm happy with the proposal as it is. -- Stefan From owner-z-machine@mail2.gmd.de Sat Mar 22 20:56:26 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id UAA19432 for ; Sat, 22 Mar 1997 20:56:25 -0600 Received: by mail2.gmd.de id AA30952 (5.67b8/IDA-1.5 for z-machine-out); Sun, 23 Mar 1997 03:45:31 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA16905 (5.67b8/IDA-1.5 for ); Sun, 23 Mar 1997 03:45:29 +0100 Received: from netcom16.netcom.com by mail.gmd.de with SMTP id AA25211 (5.67b8/IDA-1.5 for ); Sun, 23 Mar 1997 03:45:27 +0100 Received: from localhost (erkyrath@localhost) by netcom16.netcom.com (8.6.13/Netcom) id SAA20228; Sat, 22 Mar 1997 18:45:26 -0800 Date: Sat, 22 Mar 1997 18:45:25 -0800 (PST) From: Andrew Plotkin X-Sender: erkyrath@netcom16 To: Z-Machine List Subject: Re: [z-machine] Consolidated Unicode proposal In-Reply-To: <19970322131140.AAA22209@jokisch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: On Sat, 22 Mar 1997, Stefan Jokisch wrote: > Andrew Plotkin wrote: > > > On Thu, 20 Mar 1997, Graham Nelson wrote: > > > > > The following opcodes are to be introduced into Version 5 and above > > > (but not into Versions 3 or 4): > > > > > > @print_unicode code; > > > @check_unicode code -> value; > > > > I hate to keep bringing up the paranoid programmer's point of view, but > > I'd really be happier if there was some way for the game to tell if the > > interpreter supports these two opcodes. > > Simple: A game only needs to check whether its interpreter complies to > standard 1.0 or higher. Oif! Yes, that works very well. Sorry. Ok, not *great*, because what if I want to add Unicode support to MaxZip without otherwise making it 1.0-compliant? In theory, this encourages authors to make themselves 1.0-compliant. In practice, I'll probably just make it TerpEtude-compliant (which is hardly a definitive test, trust me) and stick the 1.0 notation in the header. I hope that's good enough for you. --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." From owner-z-machine@mail2.gmd.de Sun Mar 23 08:22:52 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id IAA21091 for ; Sun, 23 Mar 1997 08:22:51 -0600 Received: by mail2.gmd.de id AA11725 (5.67b8/IDA-1.5 for z-machine-out); Sun, 23 Mar 1997 15:01:13 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA08986 (5.67b8/IDA-1.5 for ); Sun, 23 Mar 1997 15:00:38 +0100 Received: from relay-7.mail.demon.net by mail.gmd.de with SMTP id AA06354 (5.67b8/IDA-1.5 for ); Sun, 23 Mar 1997 15:00:36 +0100 Received: from gnelson.demon.co.uk ([194.222.103.187]) by relay-5.mail.demon.net id aa0519600; 23 Mar 97 13:40 GMT Date: Sun, 23 Mar 1997 12:28:46 +0000 (GMT) From: Graham Nelson Subject: Re: [z-machine] Consolidated Unicode proposal To: Andrew Plotkin , Z-Machine Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: none X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: That drumbeat you hear is the court-martial being assembled. Andrew Plotkin, you are hereby charged that you did knowingly on Sun 23 Mar dare to speak aloud the words of mutiny against the Z-machine standard, by proposing to create a program which _falsely_ and _basely_ counterfeits its loyalty by pretending to be Standard 1.0 compliant when actually it is no such thing! Clerk of the court, please quote the email. > Ok, not *great*, because what if I want to add Unicode support to MaxZip > without otherwise making it 1.0-compliant? In theory, this encourages > authors to make themselves 1.0-compliant. In practice, I'll probably just > make it TerpEtude-compliant (which is hardly a definitive test, trust me) > and stick the 1.0 notation in the header. I hope that's good enough for > you. We will now hear pleas in mitigation. The defendant has been overworked, and his mind has been gradually warped by the preparation of a compact disc. Further, he has so tortured his own computer with the notorious "TerpEtude" that he is now callous and immune to the sight of computational suffering. Members of the jury, I ask you now to withdraw and consider your verdicts. [Ok, a serious reply. I do actually think it would be _very_ unfortunate to lie about compliance to the standard. But honestly, Standard 1.0 contains only tiny changes from 0.2 other than to support Unicode, so it's hard see why you'd want to put Unicode in and not bother with the rest.] -- Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom From owner-z-machine@mail2.gmd.de Sun Mar 23 10:46:22 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id KAA21434 for ; Sun, 23 Mar 1997 10:46:20 -0600 Received: by mail2.gmd.de id AA29180 (5.67b8/IDA-1.5 for z-machine-out); Sun, 23 Mar 1997 17:33:52 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA01060 (5.67b8/IDA-1.5 for ); Sun, 23 Mar 1997 17:33:49 +0100 Received: from relay-finch.mail.demon.net by mail.gmd.de with SMTP id AA15002 (5.67b8/IDA-1.5 for ); Sun, 23 Mar 1997 17:33:45 +0100 Received: from gnelson.demon.co.uk ([194.222.103.187]) by relay-finch.mail.demon.net id aa0023364; 23 Mar 97 16:32 GMT Date: Sun, 23 Mar 1997 16:32:23 +0000 (GMT) From: Graham Nelson Subject: [z-machine] Z-Machine Standard v 0.999 now out To: Z-Machine Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: none X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: With a certain sense of deja vu, I have posted another draft version of standard 1.0 to my own WWW area. This time the number is 0.999 (we've already been through 0.1, 0.2, 0.9 and 0.99), and the draft includes both the Unicode proposal (in the form we finally came to) and about a dozen corrections and clarifications since 0.99 in response to many emails. The section on "resources" also now includes ZPlet, Gnusto and this mailing list. So far as I know, it contains no errors and is complete except for one point which I don't understand -- the conflicting behaviour of two window attributes in V6 -- which I've asked Stefan to sort out for us. But who knows! There may be many more exciting misprints and blunders to find yet. The introduction notes where the major changes are. The document resides at: http://www.gnelson.demon.co.uk/spec999.tex (note: the previous version was just called spec.tex, but I've changed the name to prevent problems with Demon's proxy WWW server; all the same, you might have to wait a day or so for the file to become visible to the outside world). Many thanks to everyone who emailed. Standard 1.0 should be out, oh -- shall we say in a week or so? It's traditional to say this, anyway. -- Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom From owner-z-machine@mail2.gmd.de Mon Mar 24 15:35:33 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id PAA28098 for ; Mon, 24 Mar 1997 15:35:30 -0600 Received: by mail2.gmd.de id AA26841 (5.67b8/IDA-1.5 for z-machine-out); Mon, 24 Mar 1997 22:10:57 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA26337 (5.67b8/IDA-1.5 for ); Mon, 24 Mar 1997 22:10:54 +0100 Received: from mobius04.math.uwaterloo.ca by mail.gmd.de with SMTP id AA06105 (5.67b8/IDA-1.5 for ); Mon, 24 Mar 1997 22:10:48 +0100 Received: (from svanegmo@localhost) by mobius04.math.uwaterloo.ca (8.8.5/8.8.5) id QAA19104 for z-machine@gmd.de; Mon, 24 Mar 1997 16:10:38 -0500 From: Stephen van Egmond Message-Id: <199703242110.QAA19104@mobius04.math.uwaterloo.ca> Subject: [z-machine] Spec999.txt To: z-machine@gmd.de (ZMachine list) Date: Mon, 24 Mar 1997 16:10:34 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Is available at http://www.undergrad.math.uwaterloo.ca/~svanegmo/spec/ All the customary barbarisms introduced by dvi2tty remain in place: x == section symbol \this" == "this" Finally, unary minuses may be absent. ,,, (. .) +--oOO--(_)--OOo-----+ | Stephen Van Egmond +- svanegmo@undergrad.math.uwaterloo.ca +--- - - - | Bring your brain. From owner-z-machine@mail2.gmd.de Mon Mar 24 22:57:12 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id WAA30507 for ; Mon, 24 Mar 1997 22:57:11 -0600 Received: by mail2.gmd.de id AA10019 (5.67b8/IDA-1.5 for z-machine-out); Tue, 25 Mar 1997 05:45:19 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA11354 (5.67b8/IDA-1.5 for ); Tue, 25 Mar 1997 05:45:15 +0100 Received: from netcom13.netcom.com by mail.gmd.de with SMTP id AA22720 (5.67b8/IDA-1.5 for ); Tue, 25 Mar 1997 05:45:13 +0100 Received: from localhost (erkyrath@localhost) by netcom13.netcom.com (8.6.13/Netcom) id UAA06233; Mon, 24 Mar 1997 20:45:05 -0800 Date: Mon, 24 Mar 1997 20:45:04 -0800 (PST) From: Andrew Plotkin X-Sender: erkyrath@netcom13 Reply-To: Andrew Plotkin To: Z-Machine List Subject: Re: [z-machine] Standards compliance In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: On Sun, 23 Mar 1997, Graham Nelson wrote: > That drumbeat you hear is the court-martial being assembled. > Andrew Plotkin, you are hereby charged that you did knowingly > on Sun 23 Mar dare to speak aloud the words of mutiny against > the Z-machine standard, by proposing to create a program which > _falsely_ and _basely_ counterfeits its loyalty by pretending to > be Standard 1.0 compliant when actually it is no such thing! Your honor, I wish to state in opening that my client has just jumped into the ocean and sunk like a stone. He says he hopes you're happy. > > [...] what if I want to add Unicode support to MaxZip > > without otherwise making it 1.0-compliant? In theory, this encourages > > authors to make themselves 1.0-compliant. In practice, I'll probably just > > make it TerpEtude-compliant (which is hardly a definitive test, trust me) > > and stick the 1.0 notation in the header. I hope that's good enough for > > you. > [Ok, a serious reply. I do actually think it would be _very_ > unfortunate to lie about compliance to the standard. But honestly, > Standard 1.0 contains only tiny changes from 0.2 other than to > support Unicode, so it's hard see why you'd want to put Unicode > in and not bother with the rest.] Yes, but you understand, I've never tried to verify that my interpreters are 0.2-compliant *either*. I'm nearly sure they're not. I haven't tried to record the deviations; I deal with them as they come up, and "deal with" them doesn't necessarily mean "fix them." Example: SJ posted recently that if: > Pre-loaded input lines are used while transscription is on. The game > has already sent the text to the screen, i.e. the text is also written > to the transscription file. Now the player deletes this text. Poor > interpreter has no other choice than to remove the text from the > transscription file. Does MaxZip do this? Heck no. I have a long list of things to do first, before I fix that bug. Unicode support is somewhere on the list. I may well do a release after I put in Unicode and the associated opcodes, but before I fix that. What spec-number do I store in the header field? Or again: I've always ignored the @buffer_mode opcode, because my text-display routines are such that text is always word-wrapped. This may be technically wrong. I don't particularly care; I take the attitude that the Z-machine in MaxZip is outputting a stream of text to a smart text-stream module, rather than a rectangular raster, and so the whole concept of text buffering is meaningless. (If you agree with me, BTW, I'm sure I can find another example to prove my point. :) Up until now, I have quietly taken the position that my interpreters will not make any claim to compliance. That way I know I'm not lying. Now (or rather, when I get around to adding the unicode opcodes) I will have to make a choice. --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." From owner-z-machine@mail2.gmd.de Tue Mar 25 01:03:43 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id BAA30819 for ; Tue, 25 Mar 1997 01:03:42 -0600 Received: by mail2.gmd.de id AA21908 (5.67b8/IDA-1.5 for z-machine-out); Tue, 25 Mar 1997 07:52:51 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA20791 (5.67b8/IDA-1.5 for ); Tue, 25 Mar 1997 07:52:48 +0100 Received: from netcom13.netcom.com by mail.gmd.de with SMTP id AA27482 (5.67b8/IDA-1.5 for ); Tue, 25 Mar 1997 07:52:46 +0100 Received: from localhost (erkyrath@localhost) by netcom13.netcom.com (8.6.13/Netcom) id WAA15949; Mon, 24 Mar 1997 22:52:44 -0800 Date: Mon, 24 Mar 1997 22:52:44 -0800 (PST) From: Andrew Plotkin X-Sender: erkyrath@netcom13 To: Z-Machine List Subject: Re: [z-machine] Standards compliance In-Reply-To: <199703250645.BAA17510@cantor.math.uwaterloo.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: On Tue, 25 Mar 1997, Stephen van Egmond wrote: > > Up until now, I have quietly taken the position that my interpreters will > > not make any claim to compliance. That way I know I'm not lying. Now (or > > rather, when I get around to adding the unicode opcodes) I will have to > > make a choice. > > Then why fib? My understanding of this whole Specification business is > that users can expect common behaviour of interpreters which claim to be > compliant with the Spec. Because of the earlier statement: "If a game wishes to know whether the interpreter supports the new Unicode opcodes, it should check the header field to see if the spec-number is 1.0 or higher." Say someone does this. They release a Unicode game which checks this, and if the spec-number is less than 1.0, it prints an explanation and exits gracefully (without calling the Unicode opcodes at all.) Now I want to add Unicode support to my non-1.0-compliant interpreter. What do I do? The opcodes work; the game will work fine. I can either (A) fib, or (B) accept that the Unicode game will not run on my Unicode-supporting interpreter, or (C) convince the game author not to make that test -- so that his game crashes hard on other non-1.0-compliant interpreters, including Infocom's. --Z "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." From owner-z-machine@mail2.gmd.de Mon Mar 24 23:34:27 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id XAA30596 for ; Mon, 24 Mar 1997 23:34:26 -0600 Received: by mail2.gmd.de id AA15293 (5.67b8/IDA-1.5 for z-machine-out); Tue, 25 Mar 1997 06:24:42 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA14131 (5.67b8/IDA-1.5 for ); Tue, 25 Mar 1997 06:24:39 +0100 Received: from arl-img-4.compuserve.com by mail.gmd.de with SMTP id AA24592 (5.67b8/IDA-1.5 for ); Tue, 25 Mar 1997 06:24:37 +0100 Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id AAA29591; Tue, 25 Mar 1997 00:23:25 -0500 Date: 25 Mar 97 00:20:05 EST From: Bryan Scattergood <104312.2206@CompuServe.COM> To: "internet:graham@gnelson.demon.co.uk" Cc: "internet:erkyrath@netcom.com" , "internet:z-machine@gmd.de" Subject: Re: [z-machine] Consolidated Unicode pro Message-Id: <970325052004_104312.2206_IHS68-1@CompuServe.COM> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Graham Nelson wrote: << I do actually think it would be _very_ unfortunate to lie about compliance to the standard. But honestly, Standard 1.0 contains only tiny changes from 0.2 other than to support Unicode, so it's hard see why you'd want to put Unicode in and not bother with the rest. >> Well, speaking hypothetically, I could imagine wanting to add Unicode support to a non-0.2-compliant interpreter. And 'bothering with the rest' might be too much bother. In other words, while the ITF-derivative I maintain is still a long way from 0.2-compliance, *if* a killer Unicode game came out, I might be pressured by users into adding Unicode support. (A similar thing happened with Z8 support for Jigsaw: that jumped to the top of the todo list after a lot of user requests.) It may of course be impractical for other reasons (total lack of OS support for the required characters on the Psion, for instance), but that wouldn't stop the users from asking. Bryan From owner-z-machine@mail2.gmd.de Tue Mar 25 00:55:25 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id AAA30800 for ; Tue, 25 Mar 1997 00:55:24 -0600 Received: by mail2.gmd.de id AA12352 (5.67b8/IDA-1.5 for z-machine-out); Tue, 25 Mar 1997 07:45:48 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA22579 (5.67b8/IDA-1.5 for ); Tue, 25 Mar 1997 07:45:45 +0100 Received: from cantor.math.uwaterloo.ca by mail.gmd.de with SMTP id AA27192 (5.67b8/IDA-1.5 for ); Tue, 25 Mar 1997 07:45:42 +0100 Received: (from svanegmo@localhost) by cantor.math.uwaterloo.ca (8.8.5/8.8.5) id BAA17510; Tue, 25 Mar 1997 01:45:31 -0500 From: Stephen van Egmond Message-Id: <199703250645.BAA17510@cantor.math.uwaterloo.ca> Subject: Re: [z-machine] Standards compliance To: erkyrath@netcom.com Date: Tue, 25 Mar 1997 01:45:30 -0500 (EST) Cc: z-machine@gmd.de In-Reply-To: from "Andrew Plotkin" at Mar 24, 97 08:45:04 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: > > [Ok, a serious reply. I do actually think it would be _very_ > > unfortunate to lie about compliance to the standard. But honestly, > > Standard 1.0 contains only tiny changes from 0.2 other than to > > support Unicode, so it's hard see why you'd want to put Unicode > > in and not bother with the rest.] > > Yes, but you understand, I've never tried to verify that my interpreters > are 0.2-compliant *either*. ... > Up until now, I have quietly taken the position that my interpreters will > not make any claim to compliance. That way I know I'm not lying. Now (or > rather, when I get around to adding the unicode opcodes) I will have to > make a choice. Then why fib? My understanding of this whole Specification business is that users can expect common behaviour of interpreters which claim to be compliant with the Spec. The person who releases a game making use of Unicode wants to say that it will work with any Spec-1.0 interpreter and wants to be telling the truth. If, for instance, the BOZO interpreter (Binary Operation of Z-machine Oddities) lies about being Spec-1.0 compliant, we're right back where we started and we might as well not have a spec at all. If you're not 1.0-compliant, don't claim to be. Users (real users, not interpreter twiddlers like us) will find this as frustrating as you might if you were to discover that your compiler weren't *really* ANSI C even though it says so when you run it. /Steve From owner-z-machine@mail2.gmd.de Tue Mar 25 21:55:34 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id VAA02277 for ; Tue, 25 Mar 1997 21:55:32 -0600 Received: by mail2.gmd.de id AA32136 (5.67b8/IDA-1.5 for z-machine-out); Wed, 26 Mar 1997 04:45:48 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA05662 (5.67b8/IDA-1.5 for ); Wed, 26 Mar 1997 04:45:45 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA09625 (5.67b8/IDA-1.5 for ); Wed, 26 Mar 1997 04:45:44 +0100 Received: by wanda.vf.pond.com (8.8.5/gw.1.0) id WAA20002; Tue, 25 Mar 1997 22:46:36 -0500 (EST) Date: Tue, 25 Mar 1997 22:46:36 -0500 (EST) From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703260346.WAA20002@wanda.vf.pond.com> To: z-machine@gmd.de Subject: [z-machine] Quetzal save file example Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: I've placed a QUETZAL save file on my web page at http://www.pond.com/~russotto/zpletx/inmonument.ifzs It is for the version of Jigsaw stored in the same directory as "Jigsaw.z8". It was produced by the commands in the transcript file "monument.lis". I believe it to be correct, but I don't guarantee it. If you've written a QUETZAL reader which can't read this file, please tell me -- one of us has done something wrong! From owner-z-machine@mail2.gmd.de Wed Mar 26 11:26:38 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id LAA04270 for ; Wed, 26 Mar 1997 11:26:37 -0600 Received: by mail2.gmd.de id AA16736 (5.67b8/IDA-1.5 for z-machine-out); Wed, 26 Mar 1997 17:57:27 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA15930 (5.67b8/IDA-1.5 for ); Wed, 26 Mar 1997 17:57:24 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA31212 (5.67b8/IDA-1.5 for ); Wed, 26 Mar 1997 17:57:19 +0100 Received: from jokisch ([194.74.138.24]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAB26792 for ; Wed, 26 Mar 1997 17:47:40 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] TerpEtude Date: Wed, 26 Mar 1997 17:49:33 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970326164737.AAB26792@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Andrew Plotkin wrote: > > Frotz re-draws the input line if the cursor is placed at the left margin; > > this works as Borderzone does not print a new prompt during its interrupt > > routines. [snip] > > Gr. Would you be unhappy if you had to change this? It seems more correct > to redraw the input line exactly in cases where at least one character is > sent to the same window. [snip] This isn't specified, but you're probably right; I think the next Frotz should watch out for newlines being printed to the same window. -- Stefan From owner-z-machine@mail2.gmd.de Wed Mar 26 13:58:59 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id NAA05384 for ; Wed, 26 Mar 1997 13:58:54 -0600 Received: by mail2.gmd.de id AA30164 (5.67b8/IDA-1.5 for z-machine-out); Wed, 26 Mar 1997 20:34:07 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA26007 (5.67b8/IDA-1.5 for ); Wed, 26 Mar 1997 20:34:04 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA10418 (5.67b8/IDA-1.5 for ); Wed, 26 Mar 1997 20:33:59 +0100 Received: from jokisch ([194.74.138.23]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAA27619 for ; Wed, 26 Mar 1997 20:24:23 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] The Standard Date: Wed, 26 Mar 1997 20:32:46 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970326192422.AAA27619@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Yesterday I sent an e-mail to Graham that should have gone to our mailing list instead. Here is a new version of my mail -- only the last part has changed. ********** Graham Nelson wrote: > > > buffer_mode: What does it do in V6? It's used twice in each of the > > > V6 games, in a routine which prints out "[Please be patient...]" > > > (called by $verify, I think). It does not appear to change window > > > attributes. > > > > I admit this is a mystery. Frotz sets the "buffering" attribute of the > > current window accordingly, but Infocom's interpreters don't. Ignoring > > this opcode in Version 6 games also works. > > I've written: > > In Version 6, this opcode is redundant (the ``buffering'' window > attribute can be set instead). It is used twice in each of Infocom's > Version 6 story files, in the |$verify| routine. |Frotz| responds by > setting the current window's ``buffering'' attribute, while Infocom's > own interpreters respond by doing nothing. This standard leaves the > result of |buffer_mode| undefined in Version 6. > > Does that seem fair enough? Not quite. I've investigated this case further, and this is what I found: BUFFER_MODE is used twice by "Zork Zero", "Shogun" and "Arthur". It isn't used by "Journey". The opcode is always used in a routine K that requires one argument. K is supposed to be called from a loop that possibly takes considerable time to execute. The loop should call K once on every repeat, and a final call (with a negative argument) should be made after the loop has been finished. The effect of these calls is: a) nothing, if the number of repeats/calls is too small b) the string "[Please be patient.......]" otherwise In case of b) a dot will be printed every 16 calls (or 4 calls for slowish Apple II interpreters). The intention of K is to show the player that the program is still running, although its thinking process may take a while. K issues buffer_mode 0 after printing "[Please be patient.". On the above mentioned final call, K prints "]" and issues buffer_mode 1. The routine K has nothing to do with the $verify command. I believe it is used by the parser (which explains why Journey does not use it). However, I don't know when exactly K is called. Infocom's V6 interpreters for MS-DOS ignore the BUFFER_MODE opcode, though I'm not sure if this is true for all interpreters. Would somebody care to check his Mac or Amiga interpreters? Possible explanations: a) BUFFER_MODE is obsolete in V6 and the games shouldn't have used it. b) BUFFER_MODE is an alternative way to turn off word wrapping in V6, and the interpreters should have implemented it. c) (Warning, weird theory ahead!) We have to distinguish between text buffering and word wrapping. It is not possible to implement word wrapping without text buffering; however, it is feasible to continue text buffering while word wrapping is turned off. Frotz, for example, always writes text to a buffer; only when the contents of the buffer are flushed to the screen, the current status of word wrapping comes into play. The player won't notice, given that the time until the buffer is flushed is short enough. Note that an extremely rare problem occurs in routine K: the "." has to be printed *at once*. It is not enough to turn off word wrapping using WINDOW_STYLE; routine K must turn off text buffering using BUFFER_MODE! Suggestion: Keep the Spec simple. Just say that buffer_mode turns off text buffering; this should work for V6, too, no matter whether a), b) or c) is true. > But I'm stuck to know what to do about the following! Would you mind > drafting me a paragraph to go into the Standard? [The "following" was about window attribut bits 0 and 3.] To be honest, this subject wasn't clear to me, either, and therefore I did further research. The results are as follows: i) definitions "word wrapping": | Gallia omnis est | |divisa in partes tres | |quarum unam incolunt | |Belgae aliam... | "character wrapping": | Gallia omnis est div| |isa in partes tres qua| |rum unam incolunt Belg| |ae aliam... | "clipping": | Gallia omnis est div| | | | | | | ii) what the games expect +-------------+-------------+--------------------------------------------+ | attr bit #3 | attr bit #0 | desired effect | +=============+=============+============================================+ | clear | clear | | +-------------+-------------+ unknown -- never used? | | clear | set | | +-------------+-------------+--------------------------------------------+ | set | clear | clipping; | | | | occassionally (by accident) word wrapping | +-------------+-------------+--------------------------------------------+ | set | set | word wrapping | +-------------+-------------+--------------------------------------------+ The "accident" happens when "Zork Zero" R366, "Shogun" R292 and R295 print hints. It never occurs in MS-DOS story files. (Matthew, you were almost correct after all.) iii) what Infocom's interpreters do My knowledge about Mac and Amiga interpreters is limited -- could somebody verify the following? +-------------+-------------+--------------------------------------------+ | attr bit #3 | attr bit #0 | actual effect | +=============+=============+============================================+ | clear | clear | clipping | +-------------+-------------+--------------------------------------------+ | clear | set | character wrapping | +-------------+-------------+--------------------------------------------+ | set | clear | MS-DOS: clipping | | | | Amiga/Mac: word wrapping | +-------------+-------------+--------------------------------------------+ | set | set | word wrapping | +-------------+-------------+--------------------------------------------+ iv) what our interpreters should do The difficult case is bit #3 set / bit #0 clear. I suggest that modern interpreters use clipping in this case which is seemingly correct. The interpreter may provide a fix for the above mentioned story files. The fix would be: Use word wrapping instead of clipping. Word wrapping should be able to cope with SET_CURSOR and other evil status line operations. This works since V6 games never print over the right margin (except for a single space character every now and then -- but such a character gets deleted by the word wrapping algorithm, anyway). v) what new V6 games should do They should clear bit #0 when they want to turn off word wrapping. vi) what the Spec should say They Spec should give the following explanations: bit #0 -- "wrapping": When this bit is set, every text crossing the right margin is split and continued on the next line; otherwise text is clipped to stay inside the margins. bit #3 -- "word wrapping vs. character wrapping": This bit determines how line splitting works. If this bit is set, line splits will only occur on word breaks; otherwise line splits may occur after every character. This bit only takes effect when bit #0 ("wrapping") is also set. Remarks: Three story files (Zork Zero 366, Shogun 292 + 295) accidently turn off wrapping while printing hints. The interpreter may want to auto-detect these dtory files and use word wrapping instead of clipping... Some of Infocom's own interpreters always use word wrapping when bit #3 is set (presumably owing to a misunderstanding of the attribute bits). -- Stefan From owner-z-machine@mail2.gmd.de Thu Mar 27 13:16:34 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id NAA06886 for ; Thu, 27 Mar 1997 13:16:29 -0600 Received: by mail2.gmd.de id AA10350 (5.67b8/IDA-1.5 for z-machine-out); Thu, 27 Mar 1997 20:00:09 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA15204 (5.67b8/IDA-1.5 for ); Thu, 27 Mar 1997 20:00:02 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA19536 (5.67b8/IDA-1.5 for ); Thu, 27 Mar 1997 19:59:59 +0100 Received: by wanda.vf.pond.com (8.8.5/gw.1.0) id OAA06121; Thu, 27 Mar 1997 14:00:47 -0500 (EST) Date: Thu, 27 Mar 1997 14:00:47 -0500 (EST) From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703271900.OAA06121@wanda.vf.pond.com> To: s.jokisch@avu.de, z-machine@gmd.de Subject: Re: [z-machine] The Standard Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: } Infocom's V6 interpreters for MS-DOS ignore the BUFFER_MODE opcode, though } I'm not sure if this is true for all interpreters. Would somebody care to } check his Mac or Amiga interpreters? Sure, but you aren't going to like the answer. }iii) what Infocom's interpreters do }My knowledge about Mac and Amiga interpreters is limited -- could somebody }verify the following? }+-------------+-------------+--------------------------------------------+ }| attr bit #3 | attr bit #0 | actual effect | }+=============+=============+============================================+ }| clear | clear | clipping | }+-------------+-------------+--------------------------------------------+ }| clear | set | character wrapping | }+-------------+-------------+--------------------------------------------+ }| set | clear | MS-DOS: clipping | }| | | Amiga/Mac: word wrapping | }+-------------+-------------+--------------------------------------------+ }| set | set | word wrapping | }+-------------+-------------+--------------------------------------------+ When buffer_mode is on, Mac interpreters (6.1, 6.5, 6.9) do word wrapping in ALL cases. When buffer_mode is off, they do character wrapping in all cases. Attributes 3 and 0 are ignored. The Mac interpreters never clip. In order to work with current story files (which, aside from a few test programs, are presumably all that exist for V6), I suggest that new interpreters always word wrap if bit 3 is set. From owner-z-machine@mail2.gmd.de Fri Mar 28 09:43:57 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id JAA13164 for ; Fri, 28 Mar 1997 09:43:56 -0600 Received: by mail2.gmd.de id AA29476 (5.67b8/IDA-1.5 for z-machine-out); Fri, 28 Mar 1997 16:31:04 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA07726 (5.67b8/IDA-1.5 for ); Fri, 28 Mar 1997 16:31:02 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA31694 (5.67b8/IDA-1.5 for ); Fri, 28 Mar 1997 16:31:00 +0100 Received: by wanda.vf.pond.com (8.8.5/gw.1.0) id KAA00314; Fri, 28 Mar 1997 10:31:53 -0500 (EST) Date: Fri, 28 Mar 1997 10:31:53 -0500 (EST) From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703281531.KAA00314@wanda.vf.pond.com> To: z-machine@gmd.de Subject: [z-machine] One more data point on attributes Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: The Apple II interpreter takes bit 0 to mean "word wrapping vs clipping", and ignores bit 3. Buffer_mode doesn't change the formatting either. From owner-z-machine@mail2.gmd.de Fri Mar 28 12:12:09 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id MAA13934 for ; Fri, 28 Mar 1997 12:12:08 -0600 Received: by mail2.gmd.de id AA18327 (5.67b8/IDA-1.5 for z-machine-out); Fri, 28 Mar 1997 19:00:42 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA11234 (5.67b8/IDA-1.5 for ); Fri, 28 Mar 1997 19:00:39 +0100 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA04067 (5.67b8/IDA-1.5 for ); Fri, 28 Mar 1997 19:00:33 +0100 Received: from jokisch ([194.74.138.27]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAA11824 for ; Fri, 28 Mar 1997 18:50:48 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Word wrapping in V6 (was: The Standard) Date: Fri, 28 Mar 1997 18:58:18 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970328175047.AAA11824@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: We are still struggling to find out when word wrapping is necessary in V6. Thanks to Matthew for checking Infocom's Mac interpreters. I was able to experiment with Infocom's first Amiga interpreter and I also made further discoveries concering Infocom's DOS interpreters. Let me summarize: * * * * * * * * * * a) Mac interpreters ....ignore window attributes #0 and #3. They word-wrap when buffer mode is on, and they character-wrap if it is not. b) Amiga interpreter ....ignores window attributes #0 and #3, too. In contrast to the Mac, this interpreter uses clipping if buffer mode is off. BUGS: * Clipping respects the left margin, but ignores the right one. c) DOS interpreters ....ignore the BUFFER_MODE opcode. The meaning of window attributes #0 and #3 is given in the table below. The first line of this table is different from the first line in my previous mail: +-------------+-------------+--------------------------------------------+ | attr bit #3 | attr bit #0 | effect | +=============+=============+============================================+ | clear | clear | clipping (ignoring both margins) | +-------------+-------------+--------------------------------------------+ | clear | set | character wrapping | +-------------+-------------+--------------------------------------------+ | set | clear | clipping (between margins) | +-------------+-------------+--------------------------------------------+ | set | set | word wrapping | +-------------+-------------+--------------------------------------------+ BUGS: * If WINDOW_STYLE has only two operands, the interpreters use the current window number (!) as "operation to perform". * When proportional width fonts are used, the interpreters tend to clip words like "crawling" to "cral" (guess why). d) Apple II interpreters Only little we know. However, the behaviour of the Apple II story file of Shogun indicates that this is similar to the DOS interpreters. e) the story files ....rarely use the BUFFER_MODE opcode. If they do then only to print text immediately (without buffering). For status lines and the like attribute #0 is cleared. Attribute #3 (which is set by default) is never changed. BUGS: Shogun 292 + 295 and Zork Zero 366 don't set attribute #0 when they print hints (which require word wrapping). * * * * * * * * * * What are we going to do about this mess? Matthew proposes > In order to work with current story files (which, aside from a few > test programs, are presumably all that exist for V6), I suggest that > new interpreters always word wrap if bit 3 is set. but this seems pretty arbitrary considering the above observations. In a similar discussion (about newline interrupts) we have decided for a "clean" specification. Consequently, the interpreter has to auto-detect certain story files and provide special fixes to run them. (In our case the fix is bullet-proof word wrapping all the time.) I propose: * BUFFER_MODE turns off text buffering like it always did. * Attribute #0 toggles between word wrapping and clipping. * Attribute #3 is left unspecified ("unknown"). The remarks should warn the user about Infocom's interpreters, and they should warn the interpreter author about the previously mentioned story files. Admittedly, I'm not sure if this proposal is particularly clever. -- Stefan From owner-z-machine@mail2.gmd.de Fri Mar 28 13:50:17 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id NAA14205 for ; Fri, 28 Mar 1997 13:50:14 -0600 Received: by mail2.gmd.de id AA07732 (5.67b8/IDA-1.5 for z-machine-out); Fri, 28 Mar 1997 20:31:20 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA14375 (5.67b8/IDA-1.5 for ); Fri, 28 Mar 1997 20:31:13 +0100 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA08395 (5.67b8/IDA-1.5 for ); Fri, 28 Mar 1997 20:31:10 +0100 Received: by wanda.vf.pond.com (8.8.5/gw.1.0) id OAA20269; Fri, 28 Mar 1997 14:31:42 -0500 (EST) Date: Fri, 28 Mar 1997 14:31:42 -0500 (EST) From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199703281931.OAA20269@wanda.vf.pond.com> To: s.jokisch@avu.de, z-machine@gmd.de Subject: Re: [z-machine] Word wrapping in V6 (was: The Standard) Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: }In a similar discussion (about newline interrupts) we have decided for a }"clean" specification. Consequently, the interpreter has to auto-detect }certain story files and provide special fixes to run them. (In our case }the fix is bullet-proof word wrapping all the time.) I propose: }* BUFFER_MODE turns off text buffering like it always did. }* Attribute #0 toggles between word wrapping and clipping. }* Attribute #3 is left unspecified ("unknown"). }The remarks should warn the user about Infocom's interpreters, and they }should warn the interpreter author about the previously mentioned story }files. Admittedly, I'm not sure if this proposal is particularly clever. My objection to this proposal is that I'm not sure how buffer_mode should work across window boundaries. If we're trying for "clean", it seems more sensible to use a window attribute. The intent of my proposal was to allow all three cases without any special casing. But for a cleaner spec (at the expense of special cases for a few story files): * Attribute #0 toggles between wrapping and clipping. * Attribute #3 turns format buffering on and off. With buffering off and wrapping on, character wrapping will occur. * Both margins are always respected. * BUFFER_MODE is deprecated, and should be ignored. * Special case for the Mac & Amiga versions of Shogun and Zork Zero - turn word wrapping on at all times. (Ignore the funny routine which calls buffer_mode) or, if necessary: * BUFFER_MODE turns off ALL buffering, so characters printed appear immediately on the screen. However, I really don't think adding that feature is worth the cluttering of the spec. From owner-z-machine@mail2.gmd.de Sun Mar 30 15:28:51 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id PAA07673 for ; Sun, 30 Mar 1997 15:28:50 -0600 Received: by mail2.gmd.de id AA08936 (5.67b8/IDA-1.5 for z-machine-out); Sun, 30 Mar 1997 23:08:30 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA06037 (5.67b8/IDA-1.5 for ); Sun, 30 Mar 1997 23:08:22 +0200 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA30034 (5.67b8/IDA-1.5 for ); Sun, 30 Mar 1997 23:07:02 +0200 Received: from jokisch ([194.74.138.27]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAA22817 for ; Sun, 30 Mar 1997 22:57:07 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Word wrapping in V6 (was: The Standard) Date: Sun, 30 Mar 1997 22:46:14 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970330205706.AAA22817@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Once again thanks to Matthew, this time for testing Apple II interpreters. Apparently, Mac, DOS, Amiga and Apple II interpreters all follow their own interpretation of the window attributes #0 and #3 and the buffer mode. No surprise this issue seemed so confusing; the Infocom people themselves had no clear idea what exactly the correct behaviour is. I agree to Matthew's last proposal: > * Attribute #0 toggles between wrapping and clipping. > * Attribute #3 turns format buffering on and off. With buffering off and > wrapping on, character wrapping will occur. > * Both margins are always respected. > * BUFFER_MODE is deprecated, and should be ignored. I think the Spec should mention that Infocom's V6 games might turn off text buffering using BUFFER_MODE for printing [Please be patient.......] while they work on something else in the background. -- Stefan From owner-z-machine@mail2.gmd.de Tue Apr 1 09:25:19 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id JAA14490 for ; Tue, 1 Apr 1997 09:25:17 -0600 Received: by mail2.gmd.de id AA08270 (5.67b8/IDA-1.5 for z-machine-out); Tue, 1 Apr 1997 15:56:47 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA17969 (5.67b8/IDA-1.5 for ); Tue, 1 Apr 1997 15:56:43 +0200 Received: from relay-7.mail.demon.net by mail.gmd.de with SMTP id AA15779 (5.67b8/IDA-1.5 for ); Tue, 1 Apr 1997 15:56:41 +0200 Received: from gnelson.demon.co.uk ([194.222.103.187]) by relay-5.mail.demon.net id aa0512286; 1 Apr 97 12:48 BST Date: Tue, 01 Apr 1997 12:46:44 +0100 (BST) From: Graham Nelson Subject: [z-machine] Word-wrapping in V6: draft To: Z-Machine Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: none X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: The current text in draft Standard 0.999 reads: 8.8.3.1 There are four attributes, numbered as follows: 1: character wrapping 2: scrolling 3: text copied to output stream 2 (the transcript, if selected) 4: buffered printing Each can be turned on or off, using the window_style opcode. 8.8.3.1.1 Character wrapping takes place (if set) when printing a character would push beyond the right-hand edge of the window: if set, then the character is printed on the left of the next line. If it is clear, then text is printed along the line but clipped to the window size. One query: Stefan and Matthew have been talking about the attributes as #0 to #3, not 1 to 4. Who is right? I.e., what is the correct numbering as used by the window_style opcode? Now to try a revised draft, based on what Stefan and Matthew have uncovered: ---------------- 8.8.3.1.1 In every window, at any given time, one of the following three rules applies to text running up to the right-hand margin: "buffering", where new-lines are printed in between words as needed; "character wrapping", where new-lines are printed in between characters as needed; or "character clipping", where printing is allowed to go straight over the right margin, but no pixels are plotted on the right-hand side of it. For instance, suppose the word "abacus" must be printed when the cursor is near the right margin. Under "buffering", a newline and then "abacus" will be printed; under "character wrapping", "ab", then a newline, then "acus" will be printed; under "character clipping", "ab" and the left-hand edge of the letter "a" will be printed. 8.8.3.1.2 If attribute 4 is set, "buffering" takes place. 8.8.3.1.3 If attribute 4 is clear and attribute 1 is set, "character wrapping" takes place. If attributes 4 and 1 are both clear, "character clipping" takes place. 8.8.3.1.4 The opcode "buffer_mode" has no effect in Version 6, so the above behaviour must be controlled using "window_style". 8.8.3.1.5 Because of bugs in the original code, the following story files are exceptions to S 8.8.3.1.2 and 8.8.3.1.3: 296.881019, 366.890323, 292.890314, 295.890321 (the Macintosh and Amiga forms of "Zork Zero" and "Shogun"). In these story files alone, every window always has "buffering": attributes 1 and 4, and the opcode "buffer_mode", are ignored. ---------------- and in the notes at the foot of section 8: ---------------- Infocom's Version 6 interpreters seriously disagree on the meaning of window attributes 1 and 4 and the opcode "buffer_mode": Apple II MSDOS Macintosh Amiga A1 off, A4 off clipping(LR) clipping() --- --- A1 off, A4 on clipping(LR) clipping(LR) --- --- A1 on, A4 off buffering wrapping --- --- A1 on, A4 on buffering buffering --- --- buffer_mode off --- --- wrapping clipping(L) buffer_mode on --- --- buffering buffering Here "---" means that the interpreter ignores the given state, and the presence of L, R or both after "clipping" indicates which of the left and right margins are respected. The Amiga behaviour may be due to a bug, and two bugs have also been found in the MSDOS implementation. In any case, the existing story files use the above features incorrectly, so there is no authoritative specification. This standard imposes the following: Standard A1 off, A4 off clipping(LR) A1 off, A4 on buffering A1 on, A4 off wrapping A1 on, A4 on buffering buffer_mode off --- buffer_mode on --- Story files use "buffer_mode" (under all the interpreters) only in order to remove "buffering" while printing "Please wait..." if an operation seems to be going slowly. Thus, ignoring "buffer_mode" is no problem on a reasonably fast modern machine. ---------------- Comments, anyone? This is the last known issue to be resolved before finally publishing Standard 1.0. -- Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom From owner-z-machine@mail2.gmd.de Tue Apr 1 11:52:49 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id LAA15166 for ; Tue, 1 Apr 1997 11:52:46 -0600 Received: by mail2.gmd.de id AA31916 (5.67b8/IDA-1.5 for z-machine-out); Tue, 1 Apr 1997 19:27:54 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA17220 (5.67b8/IDA-1.5 for ); Tue, 1 Apr 1997 19:27:51 +0200 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA31626 (5.67b8/IDA-1.5 for ); Tue, 1 Apr 1997 19:27:47 +0200 Received: from jokisch ([194.74.138.39]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAD14187 for ; Tue, 1 Apr 1997 19:17:51 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Word-wrapping in V6: draft Date: Tue, 1 Apr 1997 19:25:48 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970401171745.AAD14187@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: > One query: Stefan and Matthew have been talking about the attributes > as #0 to #3, not 1 to 4. Who is right? I.e., what is the correct > numbering as used by the window_style opcode? "WINDOW_STYLE" and "GET_WIND_PROP window 14 ->s" use bits #0 to #3. > 8.8.3.1.1 In every window, at any given time, one of the following > three rules applies to text running up to the right-hand margin: > "buffering", where new-lines are printed in between words as needed; > "character wrapping", where new-lines are printed in between > characters as needed; or "character clipping", where printing is > allowed to go straight over the right margin, but no pixels are > plotted on the right-hand side of it. For instance, suppose the > word "abacus" must be printed when the cursor is near the right > margin. Under "buffering", a newline and then "abacus" will be > printed; under "character wrapping", "ab", then a newline, then "acus" > will be printed; under "character clipping", "ab" and the left-hand > edge of the letter "a" will be printed. Neither Frotz nor Infocom interpreters would print the left-hand edge of the "a". Frotz would print "ab" and move the cursor to the right margin to make sure no further characters can be printed in this line. This is important when proportional width fonts are used. > 8.8.3.1.2 If attribute 4 [#3] is set, "buffering" takes place. Attribute #3 is always set. Only attribute #0 has different default settings for window 0 and other windows; only attribute #0 is ever changed by the games themselves. We shouldn't make attribute #3 the "master switch" to toggle word wrapping on and off. I can see only two reasonable definitions: 1) the proposal Matthew and me agreed on 2) the Apple II behaviour The latter would leave the meaning of bit #3 unspecified. > 8.8.3.1.5 Because of bugs in the original code, the following > story files are exceptions to S 8.8.3.1.2 and 8.8.3.1.3: > 296.881019, 366.890323, 292.890314, 295.890321 (the Macintosh > and Amiga forms of "Zork Zero" and "Shogun"). In these story files > alone, every window always has "buffering": attributes 1 [#0] and > 4 [#3], and the opcode "buffer_mode", are ignored. Four remarks: 1) In these games BUFFER_MODE doesn't cause more trouble than in it does in every other V6 game, and therefore I wouldn't mention it here. 2) Similarly, attribute #3 is always set and there's no use in mentioning it here. 3) For some reason the Mac version of Zork Zero (296.881019) does *not* have this bug. 4) Instead of "every window" you should write "window 0"; this suffices to work-around the bug. -- Stefan From owner-z-machine@mail2.gmd.de Tue Apr 1 18:24:38 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id SAA17914 for ; Tue, 1 Apr 1997 18:24:36 -0600 Received: by mail2.gmd.de id AA27081 (5.67b8/IDA-1.5 for z-machine-out); Wed, 2 Apr 1997 02:06:26 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA15540 (5.67b8/IDA-1.5 for ); Wed, 2 Apr 1997 02:06:24 +0200 Received: from tcemail.indy.tce.com (inet-gw.indy.tce.com) by mail.gmd.de with SMTP id AA24319 (5.67b8/IDA-1.5 for ); Wed, 2 Apr 1997 02:06:22 +0200 Received: (from uucp@localhost) by tcemail.indy.tce.com (8.8.4/8.8.3) id TAA22240 for ; Tue, 1 Apr 1997 19:05:59 -0500 (EST) Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma022224; Tue Apr 1 19:05:46 1997 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <3341A44A@MSMAIL.INDY.TCE.COM>; Tue, 01 Apr 97 19:11:54 EST From: King Dale To: "'z-machine@GMD.DE'" Subject: [z-machine] Version 1 or 2 story files Date: Tue, 01 Apr 97 16:58:00 EST Message-Id: <3341A44A@MSMAIL.INDY.TCE.COM> Encoding: 14 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: A I am working on a Java Zmachine interpreter and I am looking for some version 1 or version 2 story files to do some testing and get the thing up and going. Once I have it working with the simpler V1 and V2 story files I can move on to adding the features of the other versions. The only versions gmd.de seems to stock are V3, V5, and V8. I'm sure I actually own some version 1 or 2 games (I have the original Zork from PS software (or something like that) and Starcross in the white saucer container along with several other games (Z3, HHGTTG)) but they are all for Apple ][ and I don't have any good way to get them to any other machine. TIA Dale King From owner-z-machine@mail2.gmd.de Tue Apr 1 21:40:07 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id VAA18865 for ; Tue, 1 Apr 1997 21:40:06 -0600 Received: by mail2.gmd.de id AA08600 (5.67b8/IDA-1.5 for z-machine-out); Wed, 2 Apr 1997 05:23:27 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA03978 (5.67b8/IDA-1.5 for ); Wed, 2 Apr 1997 05:23:23 +0200 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA00957 (5.67b8/IDA-1.5 for ); Wed, 2 Apr 1997 05:23:21 +0200 Received: by wanda.vf.pond.com (8.8.5/gw.1.0) id WAA08356; Tue, 1 Apr 1997 22:24:13 -0500 (EST) Date: Tue, 1 Apr 1997 22:24:13 -0500 (EST) From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199704020324.WAA08356@wanda.vf.pond.com> To: KingD@rnd1.indy.tce.com, z-machine@gmd.de Subject: Re: [z-machine] Version 1 or 2 story files Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: A } I am working on a Java Zmachine interpreter and I am looking for some } version 1 or version 2 story files to do some testing and get the thing } up and going. Once I have it working with the simpler V1 and V2 story } files I can move on to adding the features of the other versions. The } only versions gmd.de seems to stock are V3, V5, and V8. I'm sure I } actually own some version 1 or 2 games (I have the original Zork from PS } software (or something like that) and Starcross in the white saucer } container along with several other games (Z3, HHGTTG)) but they are all } for Apple ][ and I don't have any good way to get them to any other } machine. I have the 15.UG3UA5 V2 version of Zork I datafile already extracted, if you want it. I believe it was a Personal Software release, though it may have been the first post-PS Infocom release. It came in a zip-lock bag, anyway. You're probably better off starting with V3, just leaving off the split_screen opcode (which is only used by Seastalker). It's not much more complex than V1-2, there's a lot more datafiles to test with, and it lacks some of the alphabet idiosyncracies of the older versions. If you ever do transfer those old games, let me know. I've been collecting the old datafiles. From owner-z-machine@mail2.gmd.de Wed Apr 2 12:12:41 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id MAA20556 for ; Wed, 2 Apr 1997 12:12:40 -0600 Received: by mail2.gmd.de id AA08457 (5.67b8/IDA-1.5 for z-machine-out); Wed, 2 Apr 1997 19:57:33 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA09678 (5.67b8/IDA-1.5 for ); Wed, 2 Apr 1997 19:57:30 +0200 Received: from relay-11.mail.demon.net by mail.gmd.de with SMTP id AA25558 (5.67b8/IDA-1.5 for ); Wed, 2 Apr 1997 19:57:28 +0200 Received: from elvw.demon.co.uk ([158.152.183.71]) by relay-10.mail.demon.net id aa1002351; 2 Apr 97 18:16 BST Date: Wed, 2 Apr 1997 16:44:41 GMT From: John Wood Reply-To: john@elvw.demon.co.uk Message-Id: <2096@elvw.demon.co.uk> To: z-machine@gmd.de Subject: [z-machine] Infix Design X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 10 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: I thought I'd post this just in case everybody thinks the Infix project is dead and buried. I'm currently writing up a (very) preliminary design proposal, but due to being short of time this is not likely to appear until the weekend after next at the earliest. If anybody's been holding back any major insights, now would be the time to post them! John From owner-z-machine@mail2.gmd.de Wed Apr 2 17:17:27 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id RAA21929 for ; Wed, 2 Apr 1997 17:16:54 -0600 Received: by mail2.gmd.de id AA21468 (5.67b8/IDA-1.5 for z-machine-out); Thu, 3 Apr 1997 00:59:51 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA20239 (5.67b8/IDA-1.5 for ); Thu, 3 Apr 1997 00:59:48 +0200 Received: from relay-11.mail.demon.net by mail.gmd.de with SMTP id AA09271 (5.67b8/IDA-1.5 for ); Thu, 3 Apr 1997 00:59:46 +0200 Received: from gnelson.demon.co.uk ([194.222.103.187]) by relay-11.mail.demon.net id aa1111555; 2 Apr 97 23:30 BST Date: Wed, 02 Apr 1997 23:30:37 +0100 (BST) From: Graham Nelson Subject: Re: [z-machine] Infix Design To: Z-Machine Mailing List In-Reply-To: <2096@elvw.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: none X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: On Wed 02 Apr, John Wood wrote: > I thought I'd post this just in case everybody thinks the Infix project > is dead and buried. > > I'm currently writing up a (very) preliminary design proposal, but due > to being short of time this is not likely to appear until the weekend > after next at the earliest. If anybody's been holding back any major > insights, now would be the time to post them! Excellent news. I look forward to the first bending of code -- please note that Inform 6.12 already generates suitable debugging information (including information about arrays, the lack of which caused some comment on this mailing list when the draft specification was posted). -- Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom From owner-z-machine@mail2.gmd.de Fri Apr 4 11:25:33 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id LAA29478 for ; Fri, 4 Apr 1997 11:25:30 -0600 Received: by mail2.gmd.de id AA28944 (5.67b8/IDA-1.5 for z-machine-out); Fri, 4 Apr 1997 19:09:07 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA01456 (5.67b8/IDA-1.5 for ); Fri, 4 Apr 1997 19:09:03 +0200 Received: from dns.speednet.it by mail.gmd.de with SMTP id AA15144 (5.67b8/IDA-1.5 for ); Fri, 4 Apr 1997 19:07:38 +0200 Received: from default (ppp-0.speednet.it [194.247.170.174]) by dns.speednet.it (8.8.5/8.6.9) with ESMTP id TAA12924 for ; Fri, 4 Apr 1997 19:05:26 +0200 Message-Id: <199704041705.TAA12924@dns.speednet.it> From: "Giovanni Riccardi" To: Subject: [z-machine] Infix Date: Fri, 4 Apr 1997 19:08:04 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Sorry for Infix Newsletter, but during last days my provider had some problems with his server and I found my hard disk damaged. So it seems that I've lost Newsletter #3 file I was working to. I hope to post it as soon as possible Bye Giovanni From owner-z-machine@mail2.gmd.de Sat Apr 5 08:01:36 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id IAA31475 for ; Sat, 5 Apr 1997 08:01:35 -0600 Received: by mail2.gmd.de id AA06243 (5.67b8/IDA-1.5 for z-machine-out); Sat, 5 Apr 1997 15:40:46 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA06622 (5.67b8/IDA-1.5 for ); Sat, 5 Apr 1997 15:40:40 +0200 Received: from relay-7.mail.demon.net by mail.gmd.de with SMTP id AA22571 (5.67b8/IDA-1.5 for ); Sat, 5 Apr 1997 15:40:38 +0200 Received: from gnelson.demon.co.uk ([194.222.103.187]) by relay-6.mail.demon.net id aa0610538; 5 Apr 97 14:32 BST Date: Sat, 05 Apr 1997 14:31:03 +0100 (BST) From: Graham Nelson Subject: [z-machine] Patch to make Inform 6.13 To: Z-Machine Mailing List , Bjorn Gustavsson , David Kinder , Bob Newell , Magnus Olsson , Robert Pelak , Torbjorn Andersson Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: none X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: How to patch Inform 6.12 to 6.13 ================================ Apologies for this unorthodox means of distribution. But two minor defects have been found in 6.12 which I'd like to put right quickly: one bug, one compilation difficulty. As the changes can be made with a text editor in about two minutes, I'm simply circulating the changes, though the corrected source code will reach ftp.gmd.de in due course. "text.c", lines 373-4: d1 = character_digit_value[text_in[i]]; d2 = character_digit_value[text_in[i+1]]; should read d1 = character_digit_value[text_in[i+1]]; d2 = character_digit_value[text_in[i+2]]; and this will fix the problem of not being able to compile string escapes like "The door leads @00.", as used in the example game "Museum of Inform". "chars.c", line 88-91: char *alphabet[3] = { /* The alphabet table. */ "abcdefghijklmnopqrstuvwxyz", "ABCDEFGHIJKLMNOPQRSTUVWXYZ", " ^0123456789.,!?_#'~/\\-:()" }; should read: char alphabet[3][27]; /* The alphabet table. */ "header.h", line 1714: extern char *alphabet[3]; should read: extern char alphabet[3][27]; The ANSI C standard doesn't require that strings defined explicitly are writable: so on some machines, the definition in 6.12 caused memory exception errors. E.g., the "gcc" compiler needed the option "-fwritable-strings" set in order to stop 6.12 from crashing out. (Note that the array dimensions 3x27 allow room for a null character terminating each row of letters.) Finally, the version numbers at lines 33-4 of "header.h" should now be: #define RELEASE_DATE "5th April 1997" #define RELEASE_NUMBER 1613 Sorry! Graham -- Graham Nelson | graham@gnelson.demon.co.uk | Oxford, United Kingdom From owner-z-machine@mail2.gmd.de Thu Mar 20 10:19:59 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id KAA08756 for ; Thu, 20 Mar 1997 10:19:58 -0600 Received: by mail2.gmd.de id AA02962 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 16:46:48 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA19496 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 16:46:45 +0100 Received: from pigeon.doc.ic.ac.uk by mail.gmd.de with SMTP id AA07477 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 16:46:11 +0100 Received: from oak6.doc.ic.ac.uk [146.169.33.11] by pigeon.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0w7k2F-0003Of-00; Thu, 20 Mar 1997 15:45:47 +0000 Received: by oak6.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0w7k2D-0000huC; Thu, 20 Mar 97 15:45 GMT Message-Id: From: "Martin Frost" Date: Thu, 20 Mar 1997 15:45:45 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: Re: [z-machine] GNUSTO-Z eval stack order Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: >The reason I have problems with the inconsistency is that my stack is >during writing, I'm scanning my interpreter stack from the bottom >up. To write the evaluation stack in the other order requires either >that I temporarily copy the evaluation stack (in reverse order), or that I >reverse the scan partway through. Since I also build the stack from >bottom up, there's similar problems during the read. >Maybe. I'm trying to implement it for ZPlet, which has an unusual >stack format. In its case, consistency and ease of implementation are >the same. OK then. Let's change the definition to say that both stacks are written least-recent-first. (change the single word 'most' in the last line of 4.7 to 'least'). Such are the privileges of being the first implementor. I hope there are no more errors or omissions... btw: I was wondering about a possible extension in allowing the UMem chunk to contain the *whole* Z-code file. Although this would be wasteful for general saving, it would be completely self-contained, and therefore would not need any external references to story files. The IFhd chunk would then be mainly redundant, although it would be needed to keep the initial PC. This situation is currently an error (dynamic memory too long), but could be made legal. The main problem would be that RESTART would either not make sense or would just take us back to the saved state. What do people think about this? Martin -- From owner-z-machine@mail2.gmd.de Thu Mar 20 10:21:25 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id KAA08770 for ; Thu, 20 Mar 1997 10:21:22 -0600 Received: by mail2.gmd.de id AA11071 (5.67b8/IDA-1.5 for z-machine-out); Thu, 20 Mar 1997 17:02:31 +0100 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA27229 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 17:02:28 +0100 Received: from KNAVE.ECE.CMU.EDU by mail.gmd.de with SMTP id AA28957 (5.67b8/IDA-1.5 for ); Thu, 20 Mar 1997 17:02:23 +0100 Received: (jferro@localhost) by knave.ece.cmu.edu (8.6.11/8.6.4) id LAA26136; Thu, 20 Mar 1997 11:02:18 -0500 Date: Thu, 20 Mar 1997 11:02:18 -0500 From: "Jonathan R. Ferro" Message-Id: <199703201602.LAA26136@knave.ece.cmu.edu> Organization: Electrical and Computer Engineering, CMU X-Disclaimer: This disclaimer is not required by Leader Kibo. This article does not necessarily represent the opinions of Leader Kibo. Have a nice day! X-Exclaimer: Yow! To: z-machine@gmd.de In-Reply-To: (mdf@doc.ic.ac.uk) Subject: Re: [z-machine] Infix: what are sequence points? Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: An outsider's opinion: step == move forward by SOURCE LINE stepi == move forward by machine instruction Similarly for next and nexti (which don't descend into subroutines) Everything else is category (b). If you want to be able to stop at more than one position within a line, then break that line up into multiple lines and recompile. -- Jon From owner-z-machine@mail2.gmd.de Tue Apr 29 20:58:58 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id UAA21413 for ; Tue, 29 Apr 1997 20:58:54 -0500 Received: by mail2.gmd.de id AA03031 (5.67b8/IDA-1.5 for z-machine-out); Wed, 30 Apr 1997 03:49:11 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA24563 (5.67b8/IDA-1.5 for ); Wed, 30 Apr 1997 03:49:06 +0200 Received: from wanda.vf.pond.com by mail.gmd.de with SMTP id AA23415 (5.67b8/IDA-1.5 for ); Wed, 30 Apr 1997 03:49:00 +0200 Received: by wanda.vf.pond.com (8.8.5/gw.1.0) id VAA05987; Tue, 29 Apr 1997 21:49:56 -0400 (EDT) Date: Tue, 29 Apr 1997 21:49:56 -0400 (EDT) From: russotto@pond.com (Matthew T. Russotto) Message-Id: <199704300149.VAA05987@wanda.vf.pond.com> To: z-machine@gmd.de Subject: [z-machine] Z-Machine common save file format extension (Macintosh) Cc: mdf@doc.ic.ac.uk Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: I'd like to propose the following MacOS IntD chunk: 4 bytes 'IntD' chunk ID 4 bytes n chunk length (variable) 4 bytes 'MACS' Operating System ID 1 byte 00000010 flags (s set, c clear) 1 byte 0 contents ID 2 bytes 0 reserved 4 bytes ' ' Interpreter ID n - 12 bytes ... A MacOS alias record referencing the story file, as returned by NewAlias. The purpose of this chunk is to allow a Mac interpreter to find a story file given a save file, using the System 7 ResolveAlias call. Aliases are only meaningful on the same network they are created on. This chunk can appear anywhere in the file. BTW, the reason for including this chunk rather than storing the alias in the resource fork is that the latter strategy can double the size of save files. I propose 'MACS' as the OS id because that's the creator signature of the Mac System file. From owner-z-machine@mail2.gmd.de Thu May 1 11:43:16 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id LAA05080 for ; Thu, 1 May 1997 11:43:09 -0500 Received: by mail2.gmd.de id AA21843 (5.67b8/IDA-1.5 for z-machine-out); Thu, 1 May 1997 18:16:59 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA13909 (5.67b8/IDA-1.5 for ); Thu, 1 May 1997 18:16:56 +0200 Received: from pigeon.doc.ic.ac.uk by mail.gmd.de with SMTP id AA08359 (5.67b8/IDA-1.5 for ); Thu, 1 May 1997 18:16:55 +0200 Received: from oak75.doc.ic.ac.uk [146.169.16.20] by pigeon.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0wMyXN-00042X-00; Thu, 1 May 1997 17:16:53 +0100 Received: by oak75.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0wMyXM-0000YbC; Thu, 1 May 97 17:16 BST Message-Id: From: "Martin Frost" Date: Thu, 1 May 1997 17:16:52 +0100 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: [z-machine] Re: Z-Machine common save file format extension (Macintosh) Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: >I'd like to propose the following MacOS IntD chunk: > [snipped details] Looks fine to me. I've added it to the spec as a registered IntD type. While on the subject of QUETZAL, I've added support for it to ZIP (a few minor changes plus new save/restore code). This seems to work on the UNIX version, and I see no reason why it shouldn't work on other versions. I've also written a simple utility to check the sanity of QUETZAL files (checks as much as possible without requiring the story file). If anyone is interested in diffs/source, please mail me (and specify what sort of archives, etc you can read). I'll be putting all the stuff on a web page soon, but if anyone wants things urgently, I can mail them to you. Oh, and the inmonument.ifzs file appears to be valid. Martin From owner-z-machine@mail2.gmd.de Fri May 2 15:04:36 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id PAA09095 for ; Fri, 2 May 1997 15:04:33 -0500 Received: by mail2.gmd.de id AA13394 (5.67b8/IDA-1.5 for z-machine-out); Fri, 2 May 1997 21:46:39 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA26778 (5.67b8/IDA-1.5 for ); Fri, 2 May 1997 21:46:35 +0200 Received: from Clouso.CRIM.CA by mail.gmd.de with SMTP id AA15760 (5.67b8/IDA-1.5 for ); Fri, 2 May 1997 21:46:21 +0200 Received: from aragorn.hydro.qc.ca (aragorn.hydro.qc.ca [199.22.23.2]) by clouso.crim.ca (8.6.11/8.6.11) with ESMTP id PAA08031 for <@CLOUSO.CRIM.CA:z-machine@gmd.de>; Fri, 2 May 1997 15:46:10 -0400 From: ptrembl@sgiserv.cdst.hydro.qc.ca Received: tid PAA20261; Fri, 2 May 1997 15:33:11 -0400 Received: from macptremblay.atft.hydro.qc.ca by sgiserv.cdst.hydro.qc.ca via SMTP (931110.SGI/930416.SGI) for @CLOUSO.CRIM.CA:z-machine@gmd.de id AA11461; Fri, 2 May 97 15:16:40 -0400 Date: Fri, 2 May 97 15:16:40 -0400 Message-Id: <9705021916.AA11461@sgiserv.cdst.hydro.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: z-machine@gmd.de Subject: Re: [z-machine] Z-Machine common save file format extension (Macintosh) Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: A MacOs alias record has more than 12 bytes but less than 1K. MacOs decide how many bytes it should have. I store it in the resource fork in MultiAventures because it apply to any flavors of interpreters (AdvSys, Level9, etc) , and leave the saved position platform independant. Note that MacOs can resolve an Alias record even if the user move the story file and/or the saved file where he whish to on his hard disk, or rename both the story file and/or the story file. > >I'd like to propose the following MacOS IntD chunk: > >4 bytes 'IntD' chunk ID >4 bytes n chunk length (variable) >4 bytes 'MACS' Operating System ID >1 byte 00000010 flags (s set, c clear) >1 byte 0 contents ID >2 bytes 0 reserved >4 bytes ' ' Interpreter ID >n - 12 bytes ... A MacOS alias record referencing the story > file, as returned by NewAlias. > >The purpose of this chunk is to allow a Mac interpreter to find a story >file given a save file, using the System 7 ResolveAlias call. Aliases >are only meaningful on the same network they are created on. This >chunk can appear anywhere in the file. > >BTW, the reason for including this chunk rather than storing the alias >in the resource fork is that the latter strategy can double the size >of save files. > >I propose 'MACS' as the OS id because that's the creator signature of >the Mac System file. +-------------------------------------------------------------------------= -+ | Pierre Tremblay Hydro-Qu=E9bec = | | Division Edifice Raycom = | | ptrembl@sgiserv.cdst.hydro.qc.ca 5100 rue Sherbrooke Est, 8i=E8me = | | Tel. (514) 251-3115 Montr=E9al, Qu=E9bec = | | Fax (514) 251-3110 HIV 3R9 = | +-------------------------------------------------------------------------= -+ From owner-z-machine@mail2.gmd.de Tue May 13 16:17:28 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id QAA19377 for ; Tue, 13 May 1997 16:17:26 -0500 Received: by mail2.gmd.de id AA17822 (5.67b8/IDA-1.5 for z-machine-out); Tue, 13 May 1997 22:56:08 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA20694 (5.67b8/IDA-1.5 for ); Tue, 13 May 1997 22:55:59 +0200 Received: from punt-2.mail.demon.net (relay-11.mail.demon.net) by mail.gmd.de with SMTP id AA23127 (5.67b8/IDA-1.5 for ); Tue, 13 May 1997 22:55:48 +0200 Received: from elvw.demon.co.uk ([158.152.183.71]) by punt-2.mail.demon.net id aa1113455; 13 May 97 18:27 BST Message-Id: Date: Tue, 13 May 1997 18:23:22 +0100 To: z-machine@gmd.de From: John Wood Subject: [z-machine] Infix Design Proposal (half-baked) Mime-Version: 1.0 X-Mailer: Turnpike Version 1.12 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: INFIX DESIGN PROPOSAL ===================== OK, discussion on Infix seems to have halted, so I'm going to put forward a design. Consider this a Request For Comments. [Update: I haven't had any time to work on this for about a fortnight, so rather than trying fruitlessly to finalise it I'm going to put it out in it's current state to get some feedback. I know there's stuff here that needs changing/filling out - but please tell me, rather than assume I know what needs doing!] This is heavily based on a message from Kevin Bracey , posted as part of his discussions with Stefan Jokisch . I have also incorporated a lot of the ideas presented by Stephen van Egmond on his web page. Various other people also contributed ideas. In the following, I use code modified from Frotz 2.22 as my example of how to integrate the debugging features. However, if this project gets off the ground I propose that Stefan be in charge of producing the real "Infrotz". 1. BASICS ========= 1.1 Objects ----------- Although we are using C rather than C++, an object-oriented design is still applicable. We can identify two major players, the Interpreter and Infix, and a minor player, the Infix UI ("Minor" in terms of interface breadth, not necessarily quantity of code - a GUI could be the most extensive object from this point of view). There is also the Interpreter UI, but this is irrelevant to us (although it may share common code with a particular implementation of the Infix UI). Hopefully the implementation of Infix itself will be machine- independent; the same will not be true of the Interpreter and Infix UI. 1.2 Flow of Control ------------------- The interpreter is responsible for the main program loop. For example: /* main * * Prepare and run the game. */ int cdecl main(int argc, char *argv[]) { os_process_arguments(argc, argv); init_memory(); os_init_screen(); init_undo(); Infix_Initialise(story_name); do /* I'm not sure how much needs to be inside the loop. */ { z_restart(); interpret(); } while (Infix_GetFlags() & RESTART_ZMACHINE); Infix_Reset(); reset_memory (); os_reset_screen(); return 0; }/* main */ /* interpret * * Z-code interpreter main loop */ void interpret(void) { do { zbyte opcode; CODE_BYTE(opcode) Infix_PreInstruction(&opcode); zargc = 0; ... } while (!finished); }/* interpret */ 1.3 Design Philosophy --------------------- While trying to avoid too much extra work for interpreter-authors, I have taken up Stephen's idea of passing on to the Interpreter responsibility for activities that it needs to perform anyway (such as iterating through object properties). This means that there are more Interpreter functions than need necessarily be present, but in many cases they can be simple wrappers. 1.4 Naming Conventions ---------------------- Interface functions should begin with an object identifier, separated from the name by an underscore. Possibilities are: Interp_ Infix_ InfixUI_ The name should take the form of an imperative verb, or else describe when it is called. Each word should begin with an uppercase letter. For instance, Interp_ReadByte Infix_OnByteChange There are no exported variables, just functions. Data types should be entirely lowercase, with words separated by underscores. Structure members and parameters should begin with a lowercase letter, and any following words should begin with an uppercase letter. Constants and enumerated values should be entirely uppercase, with words separated by underscores. English spelling is used throughout ( let's see if *that* one slips through... 8-p ) 1.5 Header File --------------- There will be one header file, called "Infix.h" (or similar). First will come the definitions of data types, constants and flags; then the APIs. The first section will be heavily platform-dependent (and interpreter-dependent) - I imagine it will look somewhat like the start of the Inform header. The APIs should be platform independent. 1.6 Data Types -------------- The types int32, uint32 & uchar are defined as in the Inform source. The types zbyte & zword are defined as in the Frotz source (assumed to be (at least?) 8-bit and 16-bit, respectively). zaddress is typedef'd to int32, though only the low 24 bits are used - the rest must be 0. zresult is typedef'd to int32, but is an enumeration of possible errors. Z_OK may be assumed to be 0; Z_NOTIMPL means that the feature has not been coded yet. Other common return values include Z_UNSUPPORTED, Z_OUT_OF_RANGE, and Z_NOT_FOUND. The reason that it is not an actual enum is that the interpreter author may want to add interpreter-specific errors. fileid and linepos are typedef'd to uchar; linenum is typedef'd to zword. The following structures are also defined. Note the alternative versions of src_ref - the smaller version will be used unless/until sequence points are added to the source debugging information. /* Source reference */ typedef struct src_ref { fileid file; #ifdef INFIX_SEQUENCE_POINTS linepos pos; #endif linenum line; } src_ref; /* Source range */ typedef struct src_range { src_ref start; src_ref end; } src_range; /* Source definition */ typedef struct src_def { const char* name; src_range pos; } src_def; /* Routine definition */ typedef struct routine_def { int32 number; src_def defn; zaddress start; zaddress end; int32 localCount; const char* localNames[15]; } routine_def; /* Statement definition */ typedef struct stmt_def { src_def defn; zaddress start; zaddress end; } stmt_def; /* Object descriptor */ typedef struct zobject { int32 number; uchar attributes[6]; int32 parent, sibling, child; int32 propertyCount; } zobject; /* Property descriptor */ typedef struct zproperty { int32 number; int32 length; uchar data[64]; } zproperty; /* Stackframe descriptor */ typedef struct zstackframe { const zbyte* pc; int32 localCount; int32 parameterCount; uchar locals[15]; uchar parameters[8]; } stackframe_desc; Note I am currently assuming there is no need to worry about alignment in structures since the Infix code will be compiled and linked with the Interpreter. This may not be a valid assumption. 1.7 Flags --------- #define PAUSE_BEFORE_START (1<<0) #define RESTART_ZMACHINE (1<<1) ... 1.8 Calling Conventions ----------------------- With a few exceptions, all interface functions return a zresult. Functions which also need to return a value must be passed a pointer to the variable in which to store the return value. This is by convention the last parameter, except in the case of variable-sized copied data (such as strings), when a pointer to a buffer is followed by the size of the buffer. Whenever possible, strings are obtained by passing a pointer to a const char*, but this is only feasible when the object is storing (and not changing) the string in question. If we are allowed to use asserts, result pointers should be asserted, since they must be non-null to fulfill the contract; otherwise, "real" checks along the lines of "if (NULL==ptr) return Z_BAD_RESULT_POINTER;" should be used. The exceptions to the zresult rule above are: 1. Infix_GetFlags(). This is only required to provide easy read-only access to the Infix flags variable, and as such cannot fail. 2. Functions returning counts of items, such as Infix_GetClassCount(). These are allowed to return zero, so the addition of result codes only complicates things. 3. Notifications such as Infix_Restored(). We don't want to clutter up the interpreter code too much at these points, so there's no point returning anything. 2. THE INTERPRETER INTERFACE ============================ 2.1 Reading Data ---------------- These are the low-level reads: zresult Interp_ReadByte(zaddress addr, zbyte* value) { /* Check for valid addr, and return Z_INVALID_ADDRESS if not */ LOW_BYTE(addr,*value) return Z_OK; } zresult Interp_ReadWord(zaddress addr, zword* value) /* Similarly */ zresult Interp_ReadLocal(uint32 fp, int32 local, zword* value); These are higher-level reads: zresult Interp_ReadHeaderEntry(int32 index, zbyte* value); int32 Interp_GetObjectCount(); zresult Interp_GetObject(int32 objectNumber, zobject* object); zresult Interp_GetFirstProperty(int32 objectNumber, zproperty* property); zresult Interp_GetNextProperty(int32 objectNumber, zproperty* property); zresult Interp_GetObjectParent(int32 objectNumber, zobject* parent); zresult Interp_GetObjectChild(int32 objectNumber, zobject* child); zresult Interp_GetObjectSibling(int32 objectNumber, zobject* sibling); zresult Interp_GetWindowProperty(int32 windowNumber, int32 propertyNumber, zword* property); 2.2 Writing Data ---------------- When z-data is changed by the Interpreter, Infix needs to be notified. Frotz definitions could be changed (approximately) as follows, to make this easy: #define JUST_SET_BYTE(addr,v) { zmp[addr]=v; } #define JUST_SET_WORD(addr,v) { zmp[addr]=hi(v); zmp[addr+1]=lo(v); } #define SET_BYTE(addr,v) { Infix_OnByteChange(addr,v); \ JUST_SET_BYTE(addr,v); } #define SET_WORD(addr,v) { Infix_OnWordChange(addr,v); \ JUST_SET_WORD(addr,v); } I don't suggest an Infix_OnPCChange() because this case should be handled adequately by Infix_PreInstruction(). zresult Interp_WriteByte(zaddress addr, zbyte value) { /* Check for valid addr, and return Z_INVALID_ADDRESS if not */ JUST_SET_BYTE(addr,value) return Z_OK; } zresult Interp_WriteWord(zaddress addr, zword value) /* Similarly */ zresult Interp_WriteLocal(uint32 fp, int32 local, zword value); zresult Interp_WriteHeaderEntry(int32 index, zbyte value); zresult Interp_RemoveObject(int32 objectNumber); zresult Interp_InsertObject(int32 objectNumber, int32 parentNumber); 2.3 Process Control ------------------- zresult Interp_Finish(void); zresult Interp_ClearBreakpoint(zaddress addr, uint32 range); zresult Interp_SetBreakpoint(zaddress addr, uint32 range); 2.4 Simple Debug Helper ----------------------- zresult Interp_PrintDebug(const char *message); 2.5 Random Number Generation ---------------------------- zresult Interp_GetRNGSeed(uint32* seed); zresult Interp_RandomiseRNGSeed(); zresult Interp_SetRNGSeed(uint32 seed); 2.6 Iterators ------------- zresult Interp_TraverseObjectTree(void (*tell)(zobject*)); zresult Interp_TraverseDictionary(void (*tell)(const char* entry)); zresult Interp_TraverseParseTable(void (*tell)(const char* entry)); zresult Interp_TraverseAbbreviations(void (*tell)(const char* entry)); 3. THE INFIX INTERFACE ====================== 3.1 Basics ---------- zresult Infix_Initialise(const char* storyName); zresult Infix_Reset(); uint32 Infix_GetFlags(); 3.2 Notifications ----------------- void Infix_OnByteChange(zaddress addr, zbyte newValue); void Infix_OnWordChange(zaddress addr, zword newValue); void Infix_OnVariableChange(uint32 fp, int32 number, zword newValue); void Infix_EnteredRoutine(uint32 pc, uint32 sp, uint32 fp); void Infix_ExitedRoutine(uint32 pc, uint32 sp, uint32 fp); void Infix_Loaded(uint32 pc, uint32 sp, uint32 fp); void Infix_Restored(uint32 pc, uint32 sp, uint32 fp); void Infix_BreakPressed(uint32 pc, uint32 sp, uint32 fp); void Infix_PreInstruction(zbyte instruction); void Infix_RuntimeError(uint32 pc, uint32 sp, uint32 fp, uint32 errorCode); 3.3 Breakpoint/Watchpoint Handling ---------------------------------- zresult Infix_SetRunMode(uint32 mode); //mode: Go / StepOver / //TraceInto / OutOfLoop zresult Infix_SetTemporarySourceBreakpoint(src_ref pos); zresult Infix_SetTemporaryZCodeBreakpoint(zaddress addr, uint32 range); zresult Infix_SetSourceBreakpoint(src_ref pos, uint32 count, char* condition); zresult Infix_SetZCodeBreakpoint(zaddress addr, uint32 range, uint32 count, char* condition); zresult Infix_SetAttributeWatchpoint(int32 objectNumber, int32 attribute, uint32 count, char* condition); zresult Infix_SetPropertyWatchpoint(int32 objectNumber, int32 property, uint32 count, char* condition); zresult Infix_SetVariableWatchpoint(uint32 fp, int32 variable, uint32 count, char* condition); zresult Infix_SetZCodeWatchpoint(zaddress addr, uint32 range, uint32 count, char* condition); zresult Infix_ClearSourceBreakpoint(src_ref pos); zresult Infix_ClearZCodeBreakpoint(zaddress addr); zresult Infix_ClearAttributeWatchpoint(int32 objectNumber, int32 attribute); zresult Infix_ClearPropertyWatchpoint(int32 objectNumber, int32 property); zresult Infix_ClearVariableWatchpoint(uint32 fp, int32 variable); zresult Infix_ClearZCodeWatchpoint(zaddress addr); zresult Infix_CheckObjectTree(); 3.4 Source display & Code Disassembly ------------------------------------- zresult Infix_GetSource(zaddress addr, const stmt_def** stmt); zresult Infix_GetSourceLine(fileid id, linenum line, const char** name); zresult Infix_Disassemble(zaddress addr, char* buffer, int32 buflen); 3.5 Data display ---------------- zresult Infix_GetSourceFileName(fileid id, const char** name); zresult Infix_GetSourceIncludeName(fileid id, const char** name); uint32 Infix_GetClassCount(); zresult Infix_GetClassDef( uint32 index, const src_def** def ); zresult Infix_GetObjectDef( zword number, const src_def** def ); zresult Infix_GetGlobalName(zword id, const char** name); zresult Infix_GetAttributeName(zword id, const char** name); zresult Infix_GetPropertyName(zword id, const char** name); zresult Infix_GetActionName(zword id, const char** name); zresult Infix_GetFakeActionName(zword id, const char** name); uint32 Infix_GetTableCount(); zresult Infix_GetTableAddress(zword id, zaddress* addr); zresult Infix_GetTableName(zword id, const char** name); 3.6 Error Handling ------------------ zresult Infix_GetLastError(); char* Infix_GetErrorMessage(zresult errorCode); 3.7 Miscellaneous ----------------- zresult Infix_Restart(); zresult Infix_Undo(); zresult Infix_Redo(); zresult Infix_UnwindStack(); zresult Infix_RewindStack(); zresult EvaluateExpression(char* expression, int32* value); lots of useful calls like "EnumerateVariables", "GetObjectInfo" 4. THE UI INTERFACE =================== 4.1 Basic Command Processing ---------------------------- void InfixTextUI_ProcessCommand(const char *cmd); OnBreak OnWatchChange This is obviously the section that needs most work. -- John G. Wood | john@elvw.demon.co.uk | Oxford, United Kingdom From owner-z-machine@mail2.gmd.de Sun May 18 11:37:30 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id LAA00829 for ; Sun, 18 May 1997 11:37:28 -0500 Received: by mail2.gmd.de id AA20244 (5.67b8/IDA-1.5 for z-machine-out); Sun, 18 May 1997 18:20:55 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA08158 (5.67b8/IDA-1.5 for ); Sun, 18 May 1997 18:20:52 +0200 Received: from camelot.netcom.net.uk by mail.gmd.de with SMTP id AA27685 (5.67b8/IDA-1.5 for ); Sun, 18 May 1997 18:20:50 +0200 Received: from netcomuk.co.uk (markk@dialup-07-38.netcomuk.co.uk [194.42.229.230]) by camelot.netcom.net.uk (8.8.5/8.7.3) with SMTP id RAA00754 for ; Sun, 18 May 1997 17:20:46 +0100 (BST) From: Mark Knibbs To: z-machine@gmd.de Date: Sun, 18 May 1997 17:12:54 -0000 Message-Id: X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck Subject: [z-machine] Infocom's Amiga V6 interpreters Mime-Version: 1.0 Content-Type: text/plain Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Hi, I am currently disassembling one of Infocom's V6 interpreters, partly in order to figure out the Amiga graphics format. If anyone has anything which might help me do this (I already have the spec. documents from ftp.gmd.de), please let me know. One thing I have come across is that the code for read_mouse seems to just return dummy values, and not actually read the mouse at all. It returns 1,1 coordinates and 0 for the button and menu words. [This is with interpreter 6.14, as included with Arthur.] Am I correct in saying this? Did any V6 story files need the read_mouse opcode to return real values? I can post a list of lots of other information on the interpreter if anyone is interested. -- Mark From owner-z-machine@mail2.gmd.de Mon May 19 05:08:11 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id FAA02460 for ; Mon, 19 May 1997 05:08:10 -0500 Received: by mail2.gmd.de id AA21078 (5.67b8/IDA-1.5 for z-machine-out); Mon, 19 May 1997 11:57:54 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA21919 (5.67b8/IDA-1.5 for ); Mon, 19 May 1997 11:57:49 +0200 Received: from monham02.monis.co.uk by mail.gmd.de with SMTP id AA17252 (5.67b8/IDA-1.5 for ); Mon, 19 May 1997 11:57:47 +0200 Received: from host159.monis.co.uk by monham02.monis.co.uk (5.x/UUNET PIPEX simple 1.29) id AA01118; Mon, 19 May 1997 11:02:19 +0100 Received: by host159.monis.co.uk with Microsoft Mail id <01BC6443.6384B840@host159.monis.co.uk>; Mon, 19 May 1997 10:57:05 +0100 Message-Id: <01BC6443.6384B840@host159.monis.co.uk> From: David Kinder To: "z-machine@gmd.de" , "'Mark Knibbs'" Subject: RE: [z-machine] Infocom's Amiga V6 interpreters Date: Mon, 19 May 1997 10:57:02 +0100 Encoding: 13 TEXT Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: One thing I have come across is that the code for read_mouse seems to just return dummy values, and not actually read the mouse at all. It returns 1,1 coordinates and 0 for the button and menu words. [This is with interpreter 6.14, as included with Arthur.] Am I correct in saying this? Did any V6 story files need the read_mouse opcode to return real values? The mouse button co-ordinates are certainly used by some game files. For example, in all the V6 games you can select an item in the help sections by clicking on it. David From owner-z-machine@mail2.gmd.de Mon May 19 12:53:52 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id MAA01179 for ; Mon, 19 May 1997 12:53:50 -0500 Received: by mail2.gmd.de id AA24896 (5.67b8/IDA-1.5 for z-machine-out); Mon, 19 May 1997 19:21:41 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA24837 (5.67b8/IDA-1.5 for ); Mon, 19 May 1997 19:21:39 +0200 Received: from punt-1.mail.demon.net (punt-2a.mail.demon.net) by mail.gmd.de with SMTP id AA10340 (5.67b8/IDA-1.5 for ); Mon, 19 May 1997 19:20:06 +0200 Received: from gnelson.demon.co.uk ([194.222.103.187]) by punt-1.mail.demon.net id aa0624223; 19 May 97 18:04 BST Date: Mon, 19 May 1997 16:34:33 +0100 (BST) From: Graham Nelson Subject: [z-machine] Somebody please help Mark! To: Z-Machine Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 X-Organization: none X-Mailer: ANT RISCOS Marcel [ver 1.09] Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Could somebody arrange for this? I'm not sure how to do it. Thanks. (Graham) ---------- Forwarded message ---------- From: Mark Knibbs Hello, Could I be added to the distribution list for the Z-machine newsletter, if you are still maintaining this? I am currently disassembling one of Infocom's Amiga V6 interpreters, with the eventual aim of documenting the graphics format used. This should be helpful with regard to the specification more generally, since it is quite easy for me to produce fully commented source code. Regards, -- Mark Knibbs markk@netcomuk.co.uk From owner-z-machine@mail2.gmd.de Tue May 20 03:33:21 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id DAA03163 for ; Tue, 20 May 1997 03:33:19 -0500 Received: by mail2.gmd.de id AA19064 (5.67b8/IDA-1.5 for z-machine-out); Tue, 20 May 1997 10:13:57 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA19744 (5.67b8/IDA-1.5 for ); Tue, 20 May 1997 10:13:53 +0200 Received: from iraun1.ira.uka.de by mail.gmd.de with SMTP id AA28301 (5.67b8/IDA-1.5 for ); Tue, 20 May 1997 10:13:47 +0200 Received: from szs.ira.uka.de (actually szs_serv.ira.uka.de) by iraun1 with SMTP (PP); Tue, 20 May 1997 10:11:37 +0200 Received: (from kessinger@localhost) by szs.ira.uka.de (8.8.4/8.8.4) id JAA08400 for z-machine@gmd.de; Tue, 20 May 1997 09:19:23 +0200 Message-Id: X-Mailer: XFMail 1.1 [p0] on Linux Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Date: Tue, 20 May 1997 09:15:46 +0200 (CEST) From: kessinger@szs.ira.uka.de To: z-machine@gmd.de Subject: [z-machine] InCorrect debugger Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: I put up a WWW-page for the incorrect debugger at http://szswww.ira.uka.de/people/kessinger/incorrect.html for those who didn't follow the discussion in raif: InCorrect is a source debugger for inform running on=20 Linux X/Motif Does somebody have a log of the debugger discussion (I'm=20 new on this list, so I missed it) Ingo=20 ---------------------------------- E-Mail: kessinger@szs.ira.uka.de Date: 20-May-97 Time: 09:15:46 ---------------------------------- From owner-z-machine@mail2.gmd.de Tue May 20 11:19:58 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id LAA03849 for ; Tue, 20 May 1997 11:19:57 -0500 Received: by mail2.gmd.de id AA19629 (5.67b8/IDA-1.5 for z-machine-out); Tue, 20 May 1997 18:04:55 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA25043 (5.67b8/IDA-1.5 for ); Tue, 20 May 1997 18:04:51 +0200 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA28723 (5.67b8/IDA-1.5 for ); Tue, 20 May 1997 18:04:48 +0200 Received: from jokisch ([194.74.138.21]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAB28402 for ; Tue, 20 May 1997 18:02:24 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Infocom's Amiga V6 interpreters Date: Tue, 20 May 1997 18:03:03 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970520160221.AAB28402@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Mark Knibbs wrote: > I am currently disassembling one of Infocom's V6 interpreters, partly > in order to figure out the Amiga graphics format. The Amiga pictures are the same as the MCGA pictures which are available at the if-archive. The format is different though. >Did any V6 story files need the read_mouse opcode to return real values? Journey supports menus on Macintosh interpreters and it needs READ_MOUSE to figure out which menu option was selected after READ_CHAR has reported a menu click. This opcode wasn't used anywhere else. > I can post a list of lots of other information on the interpreter if > anyone is interested. Please go ahead! -- Stefan From owner-z-machine@mail2.gmd.de Wed May 21 06:06:47 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id GAA07543 for ; Wed, 21 May 1997 06:06:44 -0500 Received: by mail2.gmd.de id AA14934 (5.67b8/IDA-1.5 for z-machine-out); Wed, 21 May 1997 12:30:36 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA30285 (5.67b8/IDA-1.5 for ); Wed, 21 May 1997 12:30:32 +0200 Received: from walter.doc.ic.ac.uk by mail.gmd.de with SMTP id AA04230 (5.67b8/IDA-1.5 for ); Wed, 21 May 1997 12:30:30 +0200 Received: from oak47.doc.ic.ac.uk [146.169.16.21] by walter.doc.ic.ac.uk with smtp (Exim 0.55 #3) id E0wU8f7-0005DZ-00; Wed, 21 May 1997 11:30:29 +0100 Received: by oak47.doc.ic.ac.uk (Smail3.1.29.1 #1) id m0wU8f6-0002oSC; Wed, 21 May 97 11:30 BST Message-Id: From: "Daniel Collins" Date: Wed, 21 May 1997 11:30:28 +0100 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: z-machine@gmd.de Subject: [z-machine] New Spec? Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Hi, Just wondered what was happening on the latest Z-Machine specification? I have 0.2, and saw an post from Graham Nelson about 0.999 in March, but can't seem to locate it in any of the usual places. Also, about the Z Machine newsletter, is it still about? Again, I can only find one edition (#1)! How does someone get put on its distribution list? Onto more concrete matters, 2 questions on the spec itself. 1. Section 3.7 creating Z-strings, > For example, "i" is encrypted as > 14, 5, 5, 5, 5, 5, 5, 5, 5 $48a5 $14a5 $49a5 ^ I make the actual sequence $38a5 $14a5 $49a5 ^ I guess this is just a typo in the spec, but can someone check it for me? 2. In looking at the random number generator, I can see how to generate the "predictable" values (using the suggestions that Graham makes), but for the "random" ones, how often should the generator be re-seeded? I would guess from reading the spec, at Z-Machine start/restart and when the argument to random is 0. Is that right? I am looking at the Z-Machine for a simulation project, hence the interest. Thanks, Daniel Collins (d.w.collins@ic.ac.uk / MSc Computing) -- From owner-z-machine@mail2.gmd.de Wed May 21 12:52:50 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id MAA09936 for ; Wed, 21 May 1997 12:52:10 -0500 Received: by mail2.gmd.de id AA00740 (5.67b8/IDA-1.5 for z-machine-out); Wed, 21 May 1997 19:31:04 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA06169 (5.67b8/IDA-1.5 for ); Wed, 21 May 1997 19:30:32 +0200 Received: from avalon.netcom.net.uk by mail.gmd.de with SMTP id AA22875 (5.67b8/IDA-1.5 for ); Wed, 21 May 1997 19:30:30 +0200 Received: from netcomuk.co.uk (markk@dialup-14-51.netcomuk.co.uk [194.42.231.179]) by avalon.netcom.net.uk (8.8.5/8.7.3) with SMTP id SAA04071 for ; Wed, 21 May 1997 18:30:24 +0100 (BST) From: markk To: Z-Machine list Date: Wed, 21 May 1997 18:25:51 -0000 Message-Id: X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck Subject: [z-machine] Amiga Interpreter 6.14 information Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Information Gleaned From Amiga Interpreter 6.14 Disassembly =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please email me or the z-machine list if you have any comments or correct= ions for the information here. This is very much a work-in-progress. More information will be available as I disassemble more of the interpreter. I= f you would to see commented code for certain routines, let me know. Important things to note: =B7 set_colour can take a third argument (window id); =B7 behaviour of picture_data; =B7 'Unknown1' field in picture file explained; =B7 output_stream instruction changes and clarification; =B7 set_font can take a single argument. For those who are interested, I can make the current disassembly availabl= e. To view it you will need: =B7 A Commodore Amiga; =B7 The ReSource disassembler (this is a commercial program, but a demo v= ersion is available on Aminet which can load but not save '.rs' files); =B7 The Amiga interpreter 6.14 executable. Mail me for more information. -- Mark Knibbs markk@netcomuk.co.uk Notes on Implementation of Specific Instructions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D input_stream ------------ Instruction does nothing (NOP / RTS). make_menu --------- This is basically a no-op. The branch is not taken. This instruction shou= ld be fairly easy to implement properly on an Amiga interpreter. Any volunte= ers? output_stream ------------- Graham Nelson writes: >output stream VAR:243 13 3 output_stream number > 5 output_stream number table > 6 output_stream number table width > If stream is 0, nothing happens. If it is positive, then= that > stream is selected; if negative, deselected. (Recall tha= t > several different streams can be selected at once.) > When stream 3 is selected, a table must be given into whi= ch > text can be printed. The first word always holds the num= ber of > characters printed, the actual text being stored at bytes= > table+2 onward. It is not the interpreter's responsibili= ty to > worry about the length of this table being overrun. In V= ersion > 6, a width field may optionally be given: if this is non= -zero, > text will then be justified as if it were in the window w= ith > that number (if width is positive) or a box -width pixels= wide > (if negative). Then the table will contain not ordinary = text > but formatted text: see print_form. Output_stream does nothing if stream number argument is not one of -3, -2= , -1, 1, 2, 3. When selecting or deselecting stream 2 (transcript), bit 0 of Fl= ags2 in the game header is set or cleared as appropriate. Table and width arguments are ignored if stream<>3. Calling with stream 3= and width not specified has the same effect calling with width=3D999. In othe= r words, you should not use a specify a width of 999. The interpreter uses = this value internally to determine whether a width was specified or not. It is probably not legal to call 'output_stream 3' (i.e., not to give a t= able address). I'm not sure what would happen in this case. For stream 3, the first word of the table is set to the table width (or 9= 99 if no width was specified), not the number of characters printed. The first = word is only set to the number of characters printed when the stream is desele= cted. window_style ------------ Does nothing if operation is not one of 0, 1, 2 or 3. draw_picture, erase_picture --------------------------- (These are essentially the same routine, differing in how a flag is set. = This is just a comment on how the Infocom interpreter is designed, it doesn't affect the specification.) =46rom Graham Nelson's specification: >Displays the picture with the given number. (y; x) coordinates >(of the top left of the picture) are optional: if they are >zero or not supplied, then the picture appears in the current >window at the current cursor position. It is illegal to call >this with an invalid picture number. Calling with X or Y coordinate < 0 has same effect as if that coordinate = =3D 1. If X argument =3D 0, then the current cursor X position is used as the X coordinate. If Y argument =3D 0, then the current cursor Y position is us= ed as the Y coordinate. picture_data ------------ =46rom Graham Nelson's specification: >Asks the interpreter for data on the picture with the given >number. If the picture number is valid, a branch occurs and >information is written to the table: the height in the first >word, the width in the second, in pixels. Otherwise, if the >picture number is zero, the interpreter writes the highest >legal picture number into the first word of the table and the >release number of the picture file into the second word. >Otherwise, nothing happens. This is not entirely correct. If an invalid (and non-zero) picture number= is given, the table is written as if the image width =3D height =3D 16 pixel= s, and the branch is not taken. Stefan Jokisch writes: >It is the "number of pictures" instead of the "highest legal >picture number". The DOS version of "Zork Zero" shows the >release number on the screen, other versions of "Zork Zero" >do not. The Amiga interpreter cannot handle "picture_info 0" >properly. I assume he means 'picture_data 0'. In this case the Amiga 6.14 interpret= er writes the number of pictures to the first word, but writes an unpredicta= ble value to the second. picture_table ------------- Does nothing if called with argument =3D 0. [several] --------- In many routines (e.g. window_size), if an out of range window id is used= the interpreter will show a warning ('Bad WID'), but the routine will functio= n as if the window id used was -3, the currently selected window. set_colour ---------- Graham Nelson writes: >set colour 2OP:27 1B 5 set_colour foreground background > If coloured text is available, set text to be > foreground-against-background. (One Version 5 game uses = this: > `Beyond Zork' (Paul David Doherty reports it as used "76 = times > in 870915 and 870917, 58 times in 871221") and from the > structure of the table it clearly logically belongs in ve= rsion > 5.) Set_colour can take a THIRD argument, which is a window id. If this is no= t present, the currently selected window is affected. set_cursor ---------- If line argument is -1 or -2, the second argument (column) is ignored. It= may be any value. Line and column arguments which are too high or too low are= 'clipped'. So if both are too high (i.e. larger than window size), the cu= rsor will be positioned at the bottom right of the window. In particular, a li= ne argument of <=3D -3 is equivalent to a line argument of 1. set_font -------- If called with a single argument, affects the currently selected window. buffer_mode ----------- Stefan Jokisch writes: >Does anybody know what this opcode does in V6? On the Amiga 6.14 interpreter: if flag is not 0 or 1 nothing happens. If flag =3D 1, MOVE.W #1,(-$A6,A6). If flag =3D 0, CLR.W (-$A6,A6). This sets/clears some kind of buffering flag. I need to do more work on t= his. General information =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Mouse position as reported to the Z-machine is constrained where necessar= y. The actual Amiga mouse pointer movement is not affected. However: When th= e mouse is constrained to a window, and the pointer moves outside of that window, the mouse position as far as the Z-machine is concerned remains a= t the last position before the mouse moved out of the window. Until the mou= se pointer is moved back within the window, of course. The Amiga V6.14 interpreter supports games which want pictures, colours o= r neither. The screen depth used in each case is is: 4 (16 colours) for pictures, 3 (8 colours) for colours, 1 (2 colours) for neither. The sequence to determine the screen depth to use is: IF picture bit set THEN depth =3D 4 ELSE IF colour bit set THEN depth =3D 3 ELSE depth =3D 1 There are routines which I call SetBackgroundColour and SetForegroundColo= ur. Only SetBackgroundColour has the feature whereby -1 as argument reads col= our of pixel under cursor. SetForegroundColour does not do this. More work ne= eds to be done. Amiga Pic.Data file format =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D The descriptions (e.g. 'Part') are derived from the Frotz source code. Offset Size What ------ ---- ---- 0 b 'Part' -- Must be <=3D$10 1 b Flags -- ??? 2 w 'Unknown1' -- This is the *word* offset in the pic.d= ata file, after the $10 byte header, of the start of the pale= tte data(?). It is doubled for use as a byte offset by the interpreter. At least for the Arthur pic.data, the follow= ing relationship holds: ('Unknown1')*2 =3D $10 + (Images * InfoSize) It may be that in all known picture files the palette dat= a comes directly after the info table, so it is not essenti= al to know or use the 'Unknown1' value. However, I assume that = THIS IS NOT NECESSARILY THE CASE, so interpreters *should* use= this. 4 w Images -- As for PC, number of images. 6 w Link -- This is ignored by the Amiga interpret= er. 8 b InfoSize. Size of information area for each picture. This= specifies a number of bytes to allocate for each image. (= E.g. 500 images, InfoSize =3D 10 would cause a 5000 byte block= to be allocated.) This number of bytes are then read from offse= t $10 in the Pic file. (I think that) the interpreter assum= es this number is even. For the Arthur pic.data file (and all others?), InfoSize = =3D 14 9 b Unused -- ??? $A w Checksum -- ??? $C w Unknown2 -- ??? $E w Version -- ??? $10 Table of info data for each picture. Each entry is InfoSi= ze bytes long (14). The entries are in order of increasing PIC_NUMBER (from 1 to $A9 inclusive for Arthur). The pict= ure numbers are not necessarily contiguous, but *must* be increasing. The search function in the interpreter relies= on this being the case. InfoSize table format for Amiga graphics file =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Offset Size Purpose ------ ---- ------- 0 w Picture number 2 w Width 4 w Height 6 w Flags? 8,9,10 b MAYBE pointer to colour table (offset from start of Pic f= ile) OR ZERO 11,12,13 b Pointer to colour table (offset from start of Pic file) O= R ZERO 8, 11 are the most significant bytes. 14 w DataOffset. This field may not be present (and probably i= sn't) The colour table mentioned above consists of: 1 byte number of entries =3D NumEntries. Must be <=3D 16. 3 bytes x NumEntries Colour specifications for each colour. 1 byte for r= ed, green and blue (24-bit resolution), in that order. When loading the palette information, if the colour table pointer is zero= , there is no palette table and the screen palette is not changed. If certain flag(s) (bit 1?) are set in the flags field of the info table = for a particular picture, the interpreter assumes that there is an additional f= ield present in the InfoSize structure, which I'll call DataOffset. This is a = word offset to a table $100 bytes long. This table is loaded by the interprete= r. Graham Nelson's Specification document unclear =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >12.4.1 In Versions 1 to 3, a property table has header: > > > -----byte---- --some even number of bytes--- Not just in versions 1 to 3. V6 also. Probably all versions? Graham Nelson writes (about the story header format): > 1E 4 * * Interpreter number > 1F 4 * * Interpreter version (single ASCII character) The Amiga 6.14 interpreter writes $04 to offset $1E, and $0E to offset $1= F. So the 'Interpreter version' field is NOT an ASCII character. Indeed, $0E =3D= 14 is the sub-version of the interpreter reported by typing 'Version' during th= e game. > 27 5 * * Font width in units (defined as width of a '0') Definition of width is probably interpreter specific. The Amiga 6.14 interpreter uses the font width for a fixed-width font, or the width of '= m' for a proportional font. Perhaps the ideal definition would be 'width of widest character in the font'? >8.8.3.2.4 The foreground colour is stored in the upper byte of the colou= r data > property, the background colour in the lower byte. This use of 'upper byte' and 'lower byte' is confusing, given the z-machi= ne byte ordering. If two consecutive bytes in memory hold $12 and $34, these= would represent the word $1234 to the z-machine. Is the 'upper byte' of t= his word $12 (as makes sense), or is it $34, being the byte at the higher add= ress? (In fact, the 'lower byte' is $12, the byte with a lower address.) From owner-z-machine@mail2.gmd.de Wed May 21 13:40:47 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id NAA10223 for ; Wed, 21 May 1997 13:40:46 -0500 Received: by mail2.gmd.de id AA12643 (5.67b8/IDA-1.5 for z-machine-out); Wed, 21 May 1997 20:17:14 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA12143 (5.67b8/IDA-1.5 for ); Wed, 21 May 1997 20:17:08 +0200 Received: from frodo.AVU.de by mail.gmd.de with SMTP id AA28310 (5.67b8/IDA-1.5 for ); Wed, 21 May 1997 20:16:59 +0200 Received: from jokisch ([194.74.138.36]) by frodo.AVU.de (Netscape Mail Server v2.0) with ESMTP id AAA2574 for ; Wed, 21 May 1997 20:14:24 +0200 From: s.jokisch@avu.de (Stefan Jokisch) To: "--- Z-machine" Subject: Re: [z-machine] Infocom's Amiga V6 interpreters Date: Tue, 20 May 1997 19:21:21 +0200 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <19970521181423.AAA2574@jokisch> Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: > The mouse button co-ordinates are certainly used by some > game files. For example, in all the V6 games you can select > an item in the help sections by clicking on it. Yes, but the mouse coordinates are also written to the mouse table. The READ_MOUSE opcode wasn't used for this purpose. -- Stefan From owner-z-machine@mail2.gmd.de Thu May 22 12:49:13 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id MAA14246 for ; Thu, 22 May 1997 12:49:05 -0500 Received: by mail2.gmd.de id AA31306 (5.67b8/IDA-1.5 for z-machine-out); Thu, 22 May 1997 19:06:08 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA31756 (5.67b8/IDA-1.5 for ); Thu, 22 May 1997 19:06:03 +0200 Received: from avalon.netcom.net.uk by mail.gmd.de with SMTP id AA08587 (5.67b8/IDA-1.5 for ); Thu, 22 May 1997 19:06:00 +0200 Received: from netcomuk.co.uk (markk@dialup-06-53.netcomuk.co.uk [194.42.229.181]) by avalon.netcom.net.uk (8.8.5/8.7.3) with SMTP id SAA16496 for ; Thu, 22 May 1997 18:05:56 +0100 (BST) From: markk To: Z-Machine list Date: Thu, 22 May 1997 17:56:56 -0000 Message-Id: X-Mailer: YAM 1.3.4 [020] - Amiga Mailer by Marcel Beck Subject: [z-machine] More Amiga Interpreter 6.14 information Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Things of note in this message: =B7 correction of mistakes in spec. regarding random, and full disassembl= y of the random function in the Infocom interpreter; =B7 explanation of picture_table; =B7 read_mouse dummy routine disassembly. -- Mark markk@netcomuk.co.uk General =3D=3D=3D=3D=3D=3D=3D The core z-machine interpreter is written in assembly language, with the remainder written in C. The Amiga interpreter cannot load pictures with compressed size > 25Kb. S= o this gives an upper limit for picture size. Notes on Implementation of Specific Instructions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D erase_line ---------- Marnix Klooster writes: > Erase a rectangle of the current window with the cursor position as= its > top left corner; use the current background colour. [Question: Is= this > correct for all versions?] The height of this rectangle (in units) = is the > height of the current style in V4-5, and 1 in V6. Its width is n -= 1 if n > is greater than 1; otherwise it is the distance from the cursor pos= ition > to the right margin. n defaults to 1. [Question: Is the operand > mandatory in V6? Is 0 an illegal value for it?] If the operand is <=3D 0, this does nothing more than flush buffered text= =2E So 0 is not an illegal value for it (according to this interpreter implementat= ion). The operand may be mandatory. get_prop -------- Graham Nelson writes: >get prop 2OP:17 11 get_prop object property > Read property from object (resulting in the default value i= f it > had no such declared property). If the property has length= 1, > the value is only that byte. Otherwise, the first two byte= s of > the property are taken as a word value. (It is legal to ap= ply > get_prop to an array property, i.e. a property of length > greater than 2, but ITF behaves strangely in this case.) Stefan Jokisch writes in response to this: > Almost every interpreter will react strangely. This should be > illegal. Agreed. The interpreter 6.14 implementation of get_prop does not check bi= t 7 = of the property size/number byte. If the property has a second size byte (i.e., bit 7 is set), the value returned does not make sense: The interpreter checks bit 6 of the first size/number byte. If set, the w= ord following the first size/number byte is returned. This is: (property size)<<8 + (first byte of property data) If bit 6 is clear, the value returned is the byte following the first siz= e/ number byte, which is is the property size. I can't see any reason why this would be specified behaviour. Therefore, = it is almost certain that get_prop for a property with a second size byte sh= ould be illegal. je -- This instruction can take a variable number of operands. output_stream ------------- Under circumstances which I have yet to determine exactly, if stream 3 is= selected using a specified width, the following happens when stream 3 is deselected: the (unused) area at the end of the stream is filled with byt= es 0, 1, $20, repeating in that sequence, and then two zero bytes. This prob= ably fills to the end of the stream. [I have yet to fully understand this.] random ------ Graham Nelson writes: > The author suggests the following algorithm: > 1.In "random" mode, the generator uses the host computer's clock to = obtain > a random sequence of bits. > 2.In "predictable" mode, the generator should store the seed value S= =2E If > S < 1000 it should then internally generate > > 1, 2, 3, ... , S, 1, 2, 3, ... , S, 1, ... > > so that random n produces the next entry in this sequence modulo n= =2E If > S >=3D 1000 then S is used as a seed in a standard seeded random-n= umber > generator. (The rising sequence is useful for testing, since it w= ill > produce all possible values in sequence. On the other hand, a see= ded > but fairly random generator is useful for testing entire scripts.)= This 'S >=3D 1000' idea does not exist in the Infocom interpreter. I woul= d recommend that this not be included in any standard document. Where n is a positive number, calling random with range =3D -n returns n = and causes the future sequence of numbers output to be: 1, 2, ..., n-1, n, 1, 2, ..., etc. Marnix Klooster writes: >RANDOM s --- VAR:$7 > > If s >0, the result is a random number between 1 and s, inclusive. = If > s <0, the random generator is seeded with s and the result is 0. If= s is > 0, all future random numbers will be `really random,' and the result= is 0. > See also section 2.6. When in predictable mode 'random s ' has the same effect for any positive s. It returns the next number in the sequence. This number is N= OT NECESSARILY <=3D s! The maximum before 'looping back' to 1 is determined by the previous call 'random -n ' for positive n. If s < 0, the random generator is put into predictable mode with maximum return value -s. and the result is -s, NOT 0. In this specific implementation there is no concept of re-seeding the ran= dom number generator. Random mode is just that. The 'random key' fields that = you see in the disassembly below are initialised using the system uptime duri= ng interpreter initialisation. It is not possible to produce a definite sequence of 'random' numbers as Graham Nelson mentions. You either get an increasing sequence (in predict= able mode) or random numbers (in random mode). Here is a disassembly of the Infocom random code. ; random range random TST.W D7 ;Extraneous instruction, could rem= ove TST.W D0 ;Check range argument BLT.B .SetSeed ;If negative, set 'seed' to -range= BEQ.B .RandomModeOn ;If 0, go into random mode TST.W (-$52,A6) ;Random or predictable mode? BNE.B .PredictableMode ; If we get here, we're in random mode, with positive argument. MOVE.W (-$50,A6),D1 ;Get random key 1 SWAP D1 MOVE.W (-$4E,A6),D1 ;Get random key 2 MOVE.W D1,(-$50,A6) ;Put key 2 in key 1 SWAP D1 ;So original key 1 in D1.W LSR.L #1,D1 ;Shift right by 1 bit EOR.W D1,(-$4E,A6) ;Exclusive-or with key 2 MOVE.W (-$4E,A6),D1 ANDI.L #$7FFF,D1 ;Clear high bit of key 2 DIVU.W D0,D1 ;Divide by range SWAP D1 ;Quotient in upper, remainder in l= ower ADDQ.W #1,D1 ;Add 1 to return number in 1,...,r= ange MOVE.W D1,D0 BRA.W StoreValueInSpecifiedVariable =2ESetSeed NEG.W D0 =2ERandomModeOn MOVE.W D0,(-$52,A6) ;Set predictable range (0 for rand= om) BRA.B .Done =2EPredictableMode MOVE.W (-$54,A6),D0 ;Get previous value ADDQ.W #1,D0 ;Add 1 CMP.W (-$52,A6),D0 ;Compare with maximum value BLE.B .Done MOVEQ #1,D0 ;Start again at 1 =2EDone MOVE.W D0,(-$54,A6) ;Save value for next call to ran= dom BRA.W StoreValueInSpecifiedVariable picture_table ------------- Graham Nelson writes: >picture table EXT:284 1C 6 picture_table table > (Warning: this is only a conjecture.) Given a table of p= icture > numbers, load in these pictures from disc into a cache fo= r > convenient rapid plotting later. (For instance, the > peggleboard sprites in `Zork Zero'.) Does nothing if called with argument =3D 0. The Amiga interpreter uses a = cache size of $1400 =3D 5Kb. If allocation of this memory fails there is no cac= hing, but the game still works properly. Games should presumably not rely too heavily on having a large cache size. (It would be a simple matter to pat= ch the Amiga interpreter to use a larger cache.) The table is a (word) list of picture numbers, terminated with a zero wor= d. The maximum table size is 512 bytes (only the first 512 bytes of a longer= table will be read). Images with a compressed size of > 1Kb will not be put into the cache. Th= is instruction is designed for caching small images rather than large ones. Calling picture_table flushes the cache of its previous contents. Cache contents remain until the next call to picture_table. The Amiga interpreter cache organisation is as follows. Other interpreter= s may well be similar. A 10-byte information entry for each picture comes first. Space for these= is 'allocated' before any image data is read. Each entry is 10 bytes long: Byte Size Purpose 0-1 w Picture number 2-5 l Pointer to 3-byte unpacked size & compressed picture = data 6-9 l Length of 3-byte unpacked size & compressed picture d= ata The actual picture data is stored in the cache after all 10-byte entries.= The compressed data is stored after three bytes which (I assume) give the uncompressed size. A more appropriate name for this opcode might be 'cache_pictures'. piracy ------ Always takes the branch. read_mouse ---------- This is a dummy routine in the Amiga 6.14 interpreter. Here's a disassemb= ly: ; Called with table address in D0.W read_mouse BSR.W RELABS ;Get pointer to table MOVEA.L A0,A1 BSR.W One_in_D0D1_Zero_in_D2D3 ;Set up registers MOVEA.L A1,A0 BSR.W PutWord ;Mouse Y coordinate MOVE.W D1,D0 BSR.W PutWord ;X coordinate MOVE.W D2,D0 BSR.W PutWord ;Button bits MOVE.W D3,D0 BRA.W PutWord ;Menu word [PutWord is similar to MOVE.W D0,(A0)+, but allows for odd addresses.] From owner-z-machine@mail2.gmd.de Mon Jun 2 16:16:06 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id QAA12982 for ; Mon, 2 Jun 1997 16:16:03 -0500 Received: by mail2.gmd.de id AA15573 (5.67b8/IDA-1.5 for z-machine-out); Mon, 2 Jun 1997 22:51:34 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA13852 (5.67b8/IDA-1.5 for ); Mon, 2 Jun 1997 22:51:30 +0200 Received: from dns.speednet.it by mail.gmd.de with SMTP id AA11805 (5.67b8/IDA-1.5 for ); Mon, 2 Jun 1997 22:45:24 +0200 Received: from default (ppp-5.speednet.it [194.247.170.179]) by dns.speednet.it (8.8.5/8.6.9) with SMTP id WAA08523 for ; Mon, 2 Jun 1997 22:40:45 +0200 Message-Id: <199706022040.WAA08523@dns.speednet.it> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Giovanni Riccardi" To: "z-machine mailing list" Subject: [z-machine] Formatted text and simle graphic Date: Mon, 2 Jun 1997 22:46:48 +0200 X-Priority: 3 X-Msmail-Priority: Normal Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: Lots of discussions there were during the years on the use of graphic in text adventures. I think text adventures as interactive novels (so, similar to books) just as I think graphic adventures as interactive movies. But imagine some books without images or formatted text (J.R.R. Tolkien's "Lord of the Rings" without the map of Middle Earth or runes and tengwars!!!!) I think we should do something to implement these features in the Z-Machine. I imagine an HTML-like extension to Inform just like this: .Object At_End_Of_Road "At End Of Road" . with description . "

You are standing at the end of a road before a small . brick building.

Around you is a forest. A small . stream flows out of the building and down a gully.

", where B stand for Boldface and P for paragraph. Here is a list of some typesetting instructions that could be useful to add: - Use the font "xyz" - Bold - Italic - Underlined text - Font size

- Paragraph Inform should produce a specific z-code for those interpreters that support all of this (a new z-machine format or simply an extensions of the old .z5 and .z8 formats). Other istructions to include simple graphics (not too colors!! only for maps and this kind of things) could be implemented after the type typesetting extension.. I hope to post as soon as possible a formal proposal. Bye, Giovanni ----------------------- Giovanni Riccardi g.riccardi@speednet.it Terracina Italy ----------------------- From owner-z-machine@mail2.gmd.de Mon Jun 2 17:46:13 1997 Return-Path: owner-z-machine@mail2.gmd.de Received: from mail2.gmd.de (omega.gmd.de [129.26.8.84]) by faeryland.tamu-commerce.edu (8.8.5/8.7.3) with SMTP id RAA13340 for ; Mon, 2 Jun 1997 17:46:12 -0500 Received: by mail2.gmd.de id AA23876 (5.67b8/IDA-1.5 for z-machine-out); Tue, 3 Jun 1997 00:32:33 +0200 Received: from mail.gmd.de (postix) by mail2.gmd.de with SMTP id AA23700 (5.67b8/IDA-1.5 for ); Tue, 3 Jun 1997 00:32:30 +0200 Received: from sparc09.cs.lafayette.edu by mail.gmd.de with SMTP id AA16399 (5.67b8/IDA-1.5 for ); Tue, 3 Jun 1997 00:32:17 +0200 Received: from ultra27.cs.lafayette.edu by sparc09.cs.lafayette.edu (SMI-8.6/SMI-SVR4) id SAA07688; Mon, 2 Jun 1997 18:29:34 -0400 Received: from localhost by ultra27.cs.lafayette.edu (SMI-8.6/SMI-SVR4) id SAA01029; Mon, 2 Jun 1997 18:23:57 -0400 Date: Mon, 2 Jun 1997 18:23:57 -0400 (EDT) From: Jesse Burneko To: z-machine@gmd.de Cc: z-machine mailing list Subject: Re: [z-machine] Formatted text and simle graphic In-Reply-To: <199706022040.WAA08523@dns.speednet.it> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-z-machine@mail2.gmd.de Precedence: bulk Status: RO X-Status: > Lots of discussions there were during the years on the use of graphic > in text adventures. I think text adventures as interactive novels (so, > similar to books) just as I think graphic adventures as interactive > movies. But imagine some books without images or formatted text (J.R.R. > Tolkien's "Lord of the Rings" without the map of Middle Earth or runes > and tengwars!!!!) I agree that graphics should be included in the Z-Machine for the purposes you have named. I, however, do not feel an extension is needed. It seems to me that the existing z6 format is sufficient although new releases of inform should make it easier to use this format. The other problem is the lack of interpreters that support it. The other thing I think one needs is a better understanding of graphics format used by Infocom and perhaps a converter utility that will take popular graphics formats and covert them to the one used by Infocom. Sort of a reverse of the existing pix2gif program. -Jesse Burneko- burnekoj@cs.lafayette.edu www.cs.lafayette.edu/~burnekoj