Re: Some XY IV encoding and U2 questions (Carl/Robert)

[Carl Distefano cld@xxxxxxxx]

Reply to note from wbass@xxxxxxxx Tue, 23 Dec 2008 00:35:46 -
0700 (MST)

Wally:

This is a big topic. I'll give someo brief answers. Robert may have
more to say.

> My understanding is that XyWrite III has three kinds of
> encodings of "Characters"
>
> 1. "normal" characters, represented in a single byte,
> 2. "normal" characters, but encoded in 3 bytes.
> 3. functional primitives, encoded in three bytes.

Right. We usually refer to category 2 as, e.g., a "3-byte 'A'", and
to category 3 as "[3-byte] functions".

> Now, to these encodings, XyWrite IV adds two new encodings:
>
> 4. 3 byte data encodings for about 654 new "characters" ...
> encoded with a leading 0FEh...

Right. This is the character set developed for the scalable Speedo
fonts, for screen display and printing, that were bundled with
Signature and XyWrite 4.

> 5. A new, additional, 3 byte representation of the normal 256
> characters, this time encoded as 0FFh,0C0h,80h, plus the code
> value of the base character, with the last encoding therefore
> being 0FFh, 0C1h,07Fh.

Right again. These are SEarch-wildcard-types of characters (although
only a few of them actually function as wildcards). There's a U2
routine, REV, that allows you to generate these chars on the fly, by
typing the corresponding normal, 1-byte chars.

> Now, the questions:
>
> 1. Are there other new encodings in XyWrite IV, besides 4 and 5
> above? (Or other encodings in XyWrite III that I missed?)

In terms of *types* of characters, that's it: printable chars,
functions, and wildcards. I don't know of any others. The standard
encodings for bytes 2 and 3 are:

1) Printable chars: Bytes 2 and 3 are the two-digit hex value of the
1-byte character. E.g., in a 3-byte "A", bytes 2 and 3 are "41" (41h
being the hex representation of the Ascii-65 [decimal] "A").

2) Functions: Byte 2 is Ascii 128, 129, or 130 [decimal]; byte 3 is
any odd-numbered character 1-247.

3) Reverse-video wildcards: The range for bytes is (192,128) -
(193,127) [decimal]. The value of byte-3 plus 128, modulo 256,
equals the standard, 1-byte character.

As you mention in your post, there are also many non-standard
encodings of these three types of chars that will still display
properly in XyWrite (3 or 4). In general, when bytes 2 and 3 are in
the range (0,0)-(127,255) [decimal], what you see on the screen in
XyWrite is a printable char; in the range (128,0)-(192,127) you see
a function or a function-like char; and in the range (192,128)-
(255,255) you see a reverse-video wildcard.

> 2. I downloaded the xyweb119.zip file from serve.com, which
> yeilds a XYWWWEB.U2 file dated 10/21/07. In that file, I found
> the following encodings, at the indicated offsets:
...
> These encodings don't seem to me to be encodings that XyWrite
> IV would generated on it's own in a normal way ... and
> therefore, I surmise that they were generated by some non-
> conventional way.
...
> 2a. Are these encodings that XyWrite IV would generate
> "normally," other than by techniques such as the "change
> command" above?
>
> 2b. If so, what do they mean?
...
> 2c. If not, was there a purpose for using "invalid" (or at
> least "non-standard") encodings in the U2 file? If so, what was
> the purpose?

If both bytes 2 and 3 can be displayed on the screen in XyWrite, you
can produce the character conventionally, e.g., by assigning it to a
key in the KBD file. So, for example, the 3-byte "A" above would be
assigned to a key with
nn=NO,[3-byte 255],4,1

If one or both of bytes 2 or 3 is a character that can't be
displayed in XyWrite (examples are Ascii-0, 26, 253, 254 [Xy4] and
255), then special methods are required -- specifically, you use XPL
to concatenate the three bytes.

Typically when a non-standard 3-byter appears in our code, it's for
parsing purposes -- to parse individual bytes, which often are
"hot", or undisplayable, characters, into Save/Gets. For example,
the non-standard func @1 [255-128-2] is used to get Ascii-2 into a
S/G. (Ascii-2 is a reserved character in XyWrite's Help/Menu system,
so you can't use it directly in code that's stored in a Xy Help
file, such as U2.)

> 2d. I surmise that XyWrite IV takes any 0FFh prefix encoded
> triple with a 2nd byte >=0C0h, and translates it the a
> corrsponding 1 byte code (but with the "search"/MD78
> inflection) by taking the last byte of the triple and inverting
> bit 7.

Just so. This is true for all 3-byte characters of the "wildcard"
type, both standard and non-standard encodings (see above).

As I said, Robert may have more to say on this subject. If you
haven't done so already, I strongly recommend reading his
CTRLCHAR.TXT, which is geared to Xy3 but applies, with a few
exceptions, to Xy4 as well. For a summary of changes re 3-byters
introduced with Xy4, read the "Coffee Break" section of STACK.DOC,
the documentation for Robert's classic command-history utility. Both
of these texts are available at http://users.datarealm.com/xywwweb/.

Hope this helps.

--
Carl Distefano
cld@xxxxxxxx