From: "Jason C Penney" To: z-machine@gmd.de Date sent: Thu, 15 Jan 1998 17:45:58 +0000 Subject: [z-machine] V6 and Machine Types Send reply to: jpenney@chelmsford.com Priority: normal Hi A while ago (September) there was some discussion about introducing a new machine type that could be used to signify a machine independent V6 interpreter (see messages with the subject "[Blorb] A question of machine types"). I'd like to expand upon that a bit, as there are some features present in Infocom's Dos V6 interpreters missing from the Amiga interpreters and vice versa. (NOTE: I know very little about the Mac V6 interpreters, or any others for that matter). I think that the machine independent V6 interpreter should be based on the best features of the existing interpreters. I see three (semi-resonable) options for the machine type/interpreter number idea (not counting "just forget it"): A) Create some sort of standardish, non machine specific V6 behavior, and assign a machine type (both 255 and 0 have been suggested) that can be used by all interpreters that support this. Other interpreters can still claim the machine type that there V6 support is based on. B) If all ports of a given interpreter (Frotz for example) that have V6 support are going to behave the same across platforms, assign a machine type to that interpreter (i.e. machine type 11 means that the interpreter is Frotz). C) We could define a sort of standard V6 header extension. Adding some more flags which could state flat out what is and what isn't supported. I still think a new interpreter number should be used to signify that this extension is present. The behaviors I am currently worried about are the following ones: Font Styles: ============ This one isn't that important, but I'm throwing it in there anyway. The Spec states: "In some interpreters (though this is not required) a combination of styles is possible (such as reverse video and bold). In these, changing to Roman should turn off all the other styles currently set." Maybe it's best not to worry about this, but if we take option C above, then I think this should be thrown in there. Window Height Changes: ====================== In V6 Frotz (at least Dos and Win) handles these very elegantly. In Infocom's own Dos interpreters, they are a mess. I wish I knew how Infocom's Amiga interpreter behaved. I'm not 100% sure on the details behind this, but basically, I think it would be nice if all modern interpreters could handle changes the way Frotz currently does. I realize this is hard to follow. If I can find a nice Dos screen capture programs, I'll put some examples on a web page or something. Colour Palette =============== Text --------------- Section 8.3 of the spec states: "Under Versions 5 and later, text printing has a current foreground and background colour. In Version 6, each window has its own pair. (Note that a Version 6 interpreter going under the Amiga interpreter number must use the same pair of colours for all windows. If either is changed, then the interpreter must change the colour of all text on the screen to match. This simulates the Amiga hardware, which used two logical colours for text and switched palette to change their physical colour.) " The same pair of colours for all windows thing should not be necessary on most systems. One of the nicer features of V6 is that each window has it's own set of values (for text colour and fonts and such). The Amiga interpreter disallows certain words being in a different colour (you should see the Terpetude colour test run on Dos Frotz in Amiga mode... lot's of flashing colours.) Pre-defined Colours ------------------- Section 8.3.1 states: "The following codes are used to refer to colours: -1 = the colour of the pixel under the cursor (if any) 0 = the current setting of this colour 1 = the default setting of this colour 2 = black 3 = red 4 = green 5 = yellow 6 = blue 7 = magenta 8 = cyan 9 = white 10 = darkish grey (MSDOS interpreter number) 10 = light grey (Amiga interpreter number) 11 = medium grey (ditto) 12 = dark grey (ditto) Colours 10, 11, 12 and -1 are available only in Version 6. In Version 6 the pictures in some graphics files use colours beyond the above: if so the result of "the colour under the cursor" is permitted to be stored with value 16 or greater. " I feel that the Amiga colour ought to be available in new modern V6 interpreters. Should colours 13-15 be defined to anything (probably not, but I might as well ask)? Other Thoughts ============== If we go with option C, I also think we might as well put a field that holds the colour depth available to the interpreter. An author may want to have control over whether certain images are displayed or skipped over if the colour depth is too low. Any thoughts? comments? Later, Jay ---- Jason C Penney (jpenney@chelmsford.com) Xarton Dragon -==- "The trouble with computers of course, is that they're very sophisticated idiots." -- The Doctor