🚀 go-pugleaf

In article <1992Apr7.000402.69@unixg.ubc.ca> jeffrey@squid.tram.com writes:
>If you write a program and run it in place of the default Windowproc
>you lose *all* of the escape code handling!

Of course -- your application may have other uses for the data stream.

>This means that if I want to do any of the fancy curses-style
>processing, I have to either one of two things.  First off, I can
>re-implement the Windowproc to handle all the escape sequences I want.

This has been done, in the new-S package (licensed by AT&T).  There
were a few bugs which I have fixed in our version; if you want the
"diff" listing showing the bug fixes, let me know.

>The second option ... is to use the ROM image of Windowproc as a sort
>of library.

What I would also like to know is how one can do this decently.  Even
if you build in your own terminal emulator, you still lose the scroll
bars and mouse editing.  I'd like to be able to construct essentially
the following in the terminal

	HOST_CHANNEL <----> FILTER <----> DEFAULT_WINDOWPROC

where the "FILTER" is a downloaded application that inspects data
traffic and either passes it along or else consumes it with some
special action.  For example, in the case of the S terminal part,
it would look for a "begin graphics mode" code and once seen would
intercept all subsequent data, making plots etc. until an "end
graphics mode" code were seen.  (While not in graphics mode, one
would have full use of the Windowproc text support features.)

This is basically a job for "STREAMS", which the 630 doesn't appear
to have, but perhaps there is an adequate substitute available.  If
so, I hope somebody tells us about it!

In article <18443@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <1992Apr7.000402.69@unixg.ubc.ca> I write:
>>re-implement the Windowproc to handle all the escape sequences I want.
>
>This has been done, in the new-S package (licensed by AT&T).  There
>were a few bugs which I have fixed in our version; if you want the
>"diff" listing showing the bug fixes, let me know.

Uh-oh.  You said the naughty word - licenced.  Us poor starving grad
students are outta luck when it comes to that.  And since it's really
a part of S, that means you have to licence the entire package and
not just the driver.  It seems unusual to licence drivers (as opposed
to the code that uses them).

>>The second option ... is to use the ROM image of Windowproc as a sort
>>of library.
>What I would also like to know is how one can do this decently.

I never said that I had all the ideas worked out! :-)  I came to this
conclusion because I seem to recall that there was a "memory map" of
the old 5620 roms in the back of the programmers manual. I thought
that maybe you could call upon these routines like 6502 assembler
programmers used to call on the ROM routines that drove BASIC
interpreters.  Maybe we can "persuade" the folks at Bell Labs to make
available the source to Windowproc (yeah, and I'm still waiting for
3B1 source code!).  If not the source, how about relocatable objects?

A second thought - has anyone tried either the TEK or HP24?? emulator
for the 630?  How well does it work?  Could something be designed like
that?

>Even
>if you build in your own terminal emulator, you still lose the scroll
>bars and mouse editing.

Come to think of it, I don't remember seeing *anything* at all in the
programming manuals for use of the scroll bars and/or the mouse
yank/put functions.  That means there's a lot of novel code in the
ROMS, and it'd be nice to use it.  The only problem that I can forsee
is that there had better be a symbol table of sorts, else whatever you
write will be stuck with absolute addresses (and therefore is limited
by the ROM release in your 630).

>I'd like to be able to construct essentially
>the following in the terminal
>
>	HOST_CHANNEL <----> FILTER <----> DEFAULT_WINDOWPROC
>
>where the "FILTER" is a downloaded application that inspects data
>traffic and either passes it along or else consumes it with some
>special action.  For example, in the case of the S terminal part,
>it would look for a "begin graphics mode" code and once seen would
>intercept all subsequent data, making plots etc. until an "end
>graphics mode" code were seen.  (While not in graphics mode, one
>would have full use of the Windowproc text support features.)

While this filter (which is exactly what I'm looking to do, BTW) would
be nice on the 630's processor, can't you do something with a pty or
stream and filter the code on the host side of things?  I don't know
enough about either the XT driver scheme or STREAMS as to the
feasability of this project.

>This is basically a job for "STREAMS", which the 630 doesn't appear
>to have, but perhaps there is an adequate substitute available.  If
>so, I hope somebody tells us about it!

I have another brilliant question.  What is the most current release
of the 630 development (compiler) tools?  I seem to have 1.1 and I
fear that it's a bit dated.  Was there anything else released?  I am
still hopping mad about the fact that proof and cip for the 630 is
available only via toolchest.  I have to pick up not only the
licencing tab, but also a long-distance phone bill.  Donna talk to me
about Ma Bell's stupid code distribution methods!

j
--
Jeffrey L. Bromberger--- System Manager --- Tramway Unix Consulting
jeffrey@tram.com        Anywhere!{van-bc,ccnysci,icus}!tram!jeffrey

In article <1992Apr10.190848.11132@unixg.ubc.ca> jeffrey@squid.tram.com (Jeffrey L. Bromberger) writes:
>In article <18443@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>This has been done, in the new-S package (licensed by AT&T).
>Uh-oh.  You said the naughty word - licenced.  Us poor starving grad
>students are outta luck when it comes to that.

You might try contacting RAB, who seems like a nice guy, who might
give you permission to obtain the 630 terminal emulator (driver)
from S without paying a licensing fee.  Have him drop me a note if
it is okay and I'll send you our updated version.

>Maybe we can "persuade" the folks at Bell Labs to make available the
>source to Windowproc ...

I don't think it's controlled by the Labs, but when I inquired some
time ago about this for the 5620 I was told that AT&T Teletype had
decided definitely that it would "never" be made available.

>A second thought - has anyone tried either the TEK or HP24?? emulator
>for the 630?  How well does it work?  Could something be designed like
>that?

The tek4014 and hp2621 utilities are similar in principle to the S
driver.  However, they differ in internal design and also, obviously,
with respect to the terminal characteristics that they emulate.

They work well enough.  Again, I've fixed several bugs etc. in our
local copy of the sources for these.  (I wish there were a convenient
way to feed these back to the developers.)

>Come to think of it, I don't remember seeing *anything* at all in the
>programming manuals for use of the scroll bars and/or the mouse
>yank/put functions.

They're specifically coded into the windowproc terminal emulator.
Unfortunately, there is nothing analogous built into any of the other
terminal emulators mentioned previously.  If I had the code I'd add
this functionality to the S driver.  (Much of the needed scroll bar
code, different in detail, is available in the "sam" sources.  Mouse
text editing is the hard part.)

>The only problem that I can forsee
>is that there had better be a symbol table of sorts, else whatever you
>write will be stuck with absolute addresses (and therefore is limited
>by the ROM release in your 630).

The commercial Blit family ROMs use a "vector table" of entry points
etc.  While the code moves around from release to release, the addresses
are stored into the same locations within the vector, so the functions
can be accessed by indirection.  Look at the Blit software development
standard headers to see how this works.

>>	HOST_CHANNEL <----> FILTER <----> DEFAULT_WINDOWPROC
>>where the "FILTER" is a downloaded application that inspects data
>>traffic and either passes it along or else consumes it with some
>>special action.
>While this filter (which is exactly what I'm looking to do, BTW) would
>be nice on the 630's processor, can't you do something with a pty or
>stream and filter the code on the host side of things?

No, the problem is that the "special actions" are all things that cannot
be communicated to the default windowproc over the serial connection.
Direct access to the terminal firmware is required, thus the code must
be downloaded to the terminal.  Unfortunately, downloading it shuts down
the windowproc for that layer, and I don't know how to splice in a new one.

>I have another brilliant question.  What is the most current release
>of the 630 development (compiler) tools?  I seem to have 1.1 and I
>fear that it's a bit dated.  Was there anything else released?

Hey, you appear to have a newer release than I do.  Again, ours has
been substantially worked over to fix problems, and I'd be reluctant
at this point to upgrade to a newer release anyway.  If it ain't broke,
don't try to fix it.

>still hopping mad about the fact that proof and cip for the 630 is
>available only via toolchest.

You're lucky that it's available at all..