>>>>Wally said: Let me define some symbol markers .. to show various things.<<<< >>Carl said: Wally, thanks, this is very helpful.<< Actually, Carl, I should probably thank you. Figuring out a way to show what is happening was helpful to me too. There is more going on than meets the eye, and sometimes a "drawing" helps, particularly when I want to be sure I understand something. It's nice to get feedback that stirs the pot, and causes such things to happen. BTW, I think it's important to understand that XyWrite's forward scan that is looking for a MATCHING right Guillemet is really a necessity for the SU and SV verbs, because the main thing that either of those verbs does is copy the relevant code into the indicated S/G, and getting the length correct is critical. Also, although there is a counting error, it doesn't seem to propagate into any other counting problem other than potentially missing that trailing guillemet. For example, it seems that the right amount of data is always copied, as long as the closing guillemet was seen. It wasn't clear to me that XyWrite does the forward scan for anything other then the SU and SV verbs. But I have come to believe that it is done for virtually every left guillemet that is encountered, and the fact that <EX> made it to the bottom of your page when there was no EOF seems to show that. I suspect XyWrite does the forward scan before it even looks at the verb following an encountered left guillemet. >>Carl said: BTW ... I don't view the screen as a "junk pile"<< Neither do I, and I'm cognizant that "free text" in "macros" is not only important, but, for many, "text phases" is all that they can get out of XPL (other than using macros written by someone else). But in this case, the screen did turn out to BE USED as a kind of junk pile for what XyWrite couldn't parse, so my obtuse so called humor gene went into overtime. >>Carl said: Out of curiosity, what's your environment of choice for running XyWrite?<< That's kind of complex question. I have a utility (not written by me) that one could describe as a TSR command shell enhancement, which has the property that it installs intercepts for the calls that COMMAND.COM makes to a DOS kernel, to fetch a command line from a user. My "shell program" often uses those intercepts to "feed" commands to COMMAND.COM, which COMMAND.COM then executes. Although the utility "could" use the DOS exec function instead of feeding commands to COMMAND.COM, that does work, at least not directly, if the "command" turns out to be a .BAT file. And, the utility has other reasons for using the approach that it uses. The problem is that not all COMMAND.COM's (or 'equivalents') use the same calls to prompt the user for input, hence my utility doesn't work with all COMMAND.COM "equivalents." It doesn't work with DR-DOS, for example, or most of the common COMMAND.COM enhancements that are floating around, such a Norton's "NDOS" (which was really written by someone else who's name I have forgotten but whose name is reasonably well known as the real author of that shell). Anyway, my utility works with all MS/PC DOS versions and also with the NTVDM used in the NT line to emulate a mostly "DOS compatible" environment. So, so far, I haven't done the installations and testing to see if "VDOS" and other "Virtual DOS machines" are compatible with my utility, but that utility is important enough to me that if doesn't work with a particular Virtual DOS machine, it will be that virtual machine that goes, and not my utility, until I've tried about every possibility. Which is a long way of saying that, so far, my environment for XY has been either "vanilla" real DOS running directly on the hardware, or the NTVDM running on 32 bit windows. All of my machines (other than Chromebooks) can multiboot both PC DOS 2000 and MSDOS 7.1 natively, along with one or more Windows versions (and, occasionally some Linux version, but I am not yet really what one would call a Linux user). Multibooting DOS on the actual hardware along either Window or Linux is really not all that easy any more, in part because DOS demands CHS addressing and CHS based "partition alignment, whereas Windows switched to largely incompatible "binary partition alignment with Vista, and Linux followed Windows on that score. But I expect that I am going to have to look at and adopt some other Virtual DOS machine bit not too long from now. So. A quick question about byte code 0FEh, and XyWrite 4. In XyWrite, the 0FFh byte has always been a byte that "triggers" an escape sequence, where XyWrite grabs two more bytes from the input stream, and then "decodes" the 3 bytes as either a "3 byte version of a 1 byte character" or as a XY primitive such as BC or XC or CL. But in XyWrite 4 (only), my recollection is that byte value 0FEh became a second trigger character, that defined some more 3 byte definitions that simple corresponded to additional "character graphics" characters. But I'll be darned if I can find any information on that topic at the moment. Could you refer me to any such information that you know of (or simply indicate the details as you know them, if that is easy enough). Wally Bass