Re: New XYENC 1/13/09 release

[wbass@xxxxxxxx]

Carl Distefano wrote on Mon, 19 Jan 2009 02:08:19 -0500

>Here's QDF1.PM for Xy4

Cool. Not being a XY IVer, I'll probably start butting out of the QDFx
business. I'll continue to include my lastest take on an XY III version in
XYENC releases, but I'll be happy to see what becomes of it elsewhere. I
think that I've gotten the ball rolling with a reasonable "proof of
concept" release, but I'm not going to try to be a major force in whatever
ongoing evolution it might see. Especially not in XyWrite IV land.

However, I think I'm in the best position to do the ongoing maintenance of
XYENC and XYDEC programs, and you can consider me absolutely committed to
do any maintenance to those programs that seems appropriate. The tools
without such a committment probably wouldn't be worth much.

>Wally Bass wrote on Sun, 18 Jan 2009 18:54:42 -0700

>>BTW, another question. Do you have any idea how closely
>>the NB 8.0 set of primitive functions matches those in XY
>>IV?

>They're a superset of Xy4's. NB expands the function set by
>using 131d|83h in the third byte, in addition to 128-
>130d|80-82h. The mnemonics work out as shown below; the
>ones starting with "BM", on the next-to-last line, have
>131d in the third byte (some of these, like àL, àR, àB, and
>àE, are placeholders, not working funcs)

>[table provided]

Thanks yet again for the info, Carl.

Unhappily, there's a problem there -- the "-D" primitive code (after
"VB"). That's their first use of minus as the first character, and the
resulting XYENCoding of "'-D" conflicts with my "'-" encoding for
underscore. (Sometimes, I really do wish that the XyWrite developers were
just a tad more disiplined.)

I can (and probably will) do a new encoding for underscore (I think that
even "'_" (rsquote,underscore) would be okay, which in a way is nicer, but
I haven't really thought it throught yet). But anything that accomodates
the -D function primitive will result in a true version level
incompatability between XYENC versions at the data level, which I had
hoped to avoid.

For the moment, I think this means "don't build up much of a 'permanent'
library of XYENC encoded stuff yet, until this one has been thunk
through."

In doing XYENC, I was thinking at the time "gee, it's good that work on
XyWrite has stopped, so that the encoding question isn't a moving target."
Wasn't really thinking about NB at the time, I'm afraid. Sigh.

Another possibility is to just say "sorry, you NB folks -- we support you,
but your "-D" primitive is going to look like "'*D" (or something) under
XYENC. It'll still encode and decode to the original -- its just going to
'look wrong'".

Any opinions on which path to take? I'm inclined to bite the bullet and
make the change -- we're pretty early on the XYENC path, and we should be
able to clean out the incompatable history, in my view.

On the details side: the table you posted has WC in it twice in a row. I
think the second of those should be WL. That occurs just where byte three
of the encoding goes to 0FDh the first time through (for the WC
primitive), and because of the various evils of the 0FDh byte, as I
recall, XyWrite III at least was prone to displaying the next item in the
table incorrectly. Also, the entry after "BX" in your table is "M<",
whereas I have that as "MN". But the table does agree with what I have for
XY IV other than those two, which is good.

For the additional entries, what is your confidence level? Which release
of NB were they obtained from, or do they correspond to?

TIA for your thoughts and help.

Wally Bass