🚀 go-pugleaf

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..