[comp.sys.att] Info about the AT&T 620 terminal

friedl@vsi.UUCP (Stephen J. Friedl) (06/24/88)

Hi folks,

     For those interested, here is a mini-review of the AT&T 620
terminal.  It has a mouse, bitmapped graphics, and a couple of
windows that the 3B2 knows how to drive in the layers
environment.  We had one of these on loan from a customer for a
while and got to know it "well".  In short, these are pretty
sorry terminals.

     The blink and dim attributes don't work (confirmed with
Hotline), and the terminal only does pseudo 132-column mode.  You
see 80 of the 132 columns it maintains internally -- you can
"scroll" sideways to get the ones you can't see.

     The terminal scrolls horridly.  It paints the screen OK, but
when it hits the bottom, it becomes obvious that the processor is
doing characters on a pixel basis because the movement "shimmers"
down the screen as the bits are moved.  It is not anything like
smooth scroll, and the effect is really terrible (can you say
"BLIT"?  Neither can the 620).  I did some tests and find that
timing the dump of a dozen /etc/termcap files shows around
3100bps throughput.

     I didn't have the right windows/layers software loaded on my
3B2, so I can't judge that (the 615's multi-tasking is so
sluggish on an unloaded 3B2/400 that we really can't use it).  My
customer runs Ficor Autograph (in Tek 4014 mode, probably) and
really likes it.  However, I've seen graphics on the Wyse 99GT
looking just as good for one third the price (the 99's are really
nice terminals).

     Feedback is welcome.

     Steve

-- 
Steve Friedl    V-Systems, Inc. (714) 545-6442      3B2-kind-of-guy
friedl@vsi.com     {backbones}!vsi.com!friedl    attmail!vsi!friedl

Nancy Reagan on the Mac-II architecture: "Just say Nu"

gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/24/88)

In article <727@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>... here is a mini-review of the AT&T 620 terminal.

I don't have much experience with the 615 or 620, so I'll defer to
your experience with those.  However, the 630 is really spiffy.  I
replaced my 5620 (and Dave Prosser's "myx" environment) with a 630
some time ago and in practically every way the 630 is superior.
(The notable exception is that the top of the monitor is not flat
enough to set my ThinkJet printer on.)

The 630 is a true descendant of Rob Pike's Blit.  Programs for
downloading to a 5620 typically require very little editing to work
with the 630, and the 630 has several significant new features:
	font caching (avoids subsequent downloading)
	process image caching (ditto)
	IPC
	text layer scroll bars and banners
	scroll lock key
	built-in mouse-based text editing (cut, snarf, paste, send,
		etc. in the same layer or between layers)
	settable default initial layer size
	local processes (no host channel)
	"walking" menus
	dual host support (7 channels each in layers mode)
	built-in text printing support
	amber phosphor (I hear that white is now available)
	ROM cartridge slot for custom/alternate firmware

Mine is configured with an additional I/O board and is connected
to a printer, our building terminal port contention switcher (PACX),
and a Sun-3/50M.  I actually prefer the 630 user interface to SunTools
for most purposes, although obviously stuff that insists on using the
SunTools environment has to be run on the Sun console.

630 host support software is available; so far as I know, it consists
at present just of the cross-compilation environment (CCS or SGS),
"layers", "jim" mouse-based text editor ("sam" precursor), icon editor
(and lots of icons), font downloader (and several constant-width fonts), 
process uncacher, terminal memory usage display, "dmdpi" debugger, and
demos and programming examples.  This is available in source form for
UNIX System V and also for 4.3BSD; contact AT&T Teletype (Skokie, IL)
for details.

I also have a version of "proof" (troff output viewer), "cip" (pic
drawer), "sam", and some other tools ported to the 630.  Recently I
posted my own version of "dmdp" (screen image printer) adapted to
work with the 630.  Most of the useful 5620 tools now exist for the
630 in some form, although I don't know how you obtain them without
porting them yourself.  Presumably AT&T Teletype is working on this..

csg@pyramid.pyramid.com (Carl S. Gutekunst) (06/26/88)

In article <727@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>In short, these are pretty sorry terminals.

*SIGH* What I find "sorry" is people who review a product without even having
tried it in its primary operating mode. Yes, it is bitmapped, so the scrolling
is slow. Yes, it does 132 column mode in a peculariar way. (May I see a show
of hands of people who use 132 column mode on *anything?*) And I'd say that
blink and dim attributes would be a little tough to implement on a bitmap.

But it also does 6 windows, arbitrary sized, if you are running the "layers"
software on your host. The window interface is pleasent, easy to use and easy
to learn. It is sufficiently VT-220 compatible that a lot of turnkey applica-
tions that depend on the VT-220 -- Oracle, fer instance -- run perfectly, in
all six windows concurrently. And you can download stuff to the 620, just like
you can to the old 5620; this means troff previewer, pic editor, and lots of
other graphics tools. You can get most of the cut/paste/fonts capability of
the 630 by bringing up myx.

Why were you unhappy with the 615? Ours work fine -- again, in layers mode.

The part that's *really* sorry, though, is AT&T's truly awful support for the
entire 600 family of terminals. They've been making quite a splash at trade
shows now, and even put glossy brochures in _Unix_Review_. What they *don't*
tell you is:

- There are only two computer vendors in the whole world that support layers:
  AT&T and Pyramid. Anywhere else, you have to start from source and install
  it yourself. There are kernel versions for System V and 4.3BSD, and a user-
  level version for 4.nBSD using sockets. This latter version is painful, as
  you lose most of the performance gains you get by having the window manager
  in the terminal. So if you don't have kernel source, life will be rough.

- All of the really fancy software, like editors, compilers, and graphics
  tools, are unsupported software in the UNIX Toolchest. You buy source, cross
  compile, and download. If your host machine is anything other than a System
  V VAX or 3B2, you'll have a little porting work to do. (On a really non-VAX
  architecture like a Pyramid or SPARC, you'll have a lot of porting work.)
  If you have problems, you're on your own. (I've gotten far more help from
  Doug Gwyn that from AT&T, excluding direct support from AT&T Skokie nee
  Teletype Corp.)

The terminals are excellent. The software is very good. The Skokie people did
a terrific job; they worked with us through beta test of all the terminals,
and even sent their lead engineers onsite (California) to fix terminal bugs
that only showed up on the Pyramid. But I think they're getting screwed by the
UNIX folks since a properly supported 620 and 630 is a serious competitor to a
Sun Workstation.

Of course, all the evidence I have at this point is circumstantial, based on
(1) oodles of support from Skokie, (2) endless drivel and foot-dragging from
New Jersey, and (3) all the good software being put in the Unix Toolchest. If
someone from AT&T wants to tell me otherwise, I'm all ears! But don't give me
the "we're too big a company for that" stuff; I know that's true of DEC, which
is organized into lots of different internal units. AT&T, on the other hand,
is highly interwoven, with vigorous political turf battles between units. 

<csg>

gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/26/88)

In article <28765@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
> There are kernel versions [of layers] for System V and 4.3BSD, and a user-
> level version for 4.nBSD using sockets. This latter version is painful, as
> you lose most of the performance gains you get by having the window manager
> in the terminal.

Actually the user-level version uses ptys for host layer I/O (with
multiplexing done by select()).  That is considerably slower than kernel-
level multiplexing, mainly due to the high rate of context switches.
This is apparent when emulating a CRT in a layer, but it is much less
important for typical downloaded interactive front-end processes.
Keith Muller's latest version, which I think is available from AT&T
Teletype, now supports the hostagent feature (i.e. window manipulation
directly from host processes), and that feature does use sockets (this
wouldn't be necessary if ioctls worked right over ptys, as they do on
streams).  I didn't bother with hostagent in the CWI/BRL version, since
there isn't much that depends on it other than a couple of trade-show
demos.

I think Carl is right -- if AT&T knew how to push layers, these terminals
could be rather successful.  I don't know what I would do without one
(and I don't want to find out, at least not until something like Plan 9
is ready to take its place).

friedl@vsi.UUCP (Stephen J. Friedl) (06/26/88)

In article <8161@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> I think Carl is right -- if AT&T knew how to push layers, these terminals
> could be rather successful.  I don't know what I would do without one
> (and I don't want to find out, at least not until something like Plan 9
> is ready to take its place).

Responding to both Doug and Carl: I've seen layers run on the 615 and
the 620, and it is really neat to see.  It has been our experience,
however, that the 3B2/400 just doesn't have the processor horsepower
to make it work well.  Interactive work in layers on the 615 is so sluggish
that we use a pair of terminals rather than run layers -- it's that bad.
Has anybody had other experiences with this?

-- 
Steve Friedl     V-Systems, Inc. (714) 545-6442     3B2-kind-of-guy
friedl@vsi.com     {backbones}!vsi.com!friedl    attmail!vsi!friedl

Nancy Reagan on the Free Software Foundation : "Just say GNU"

gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/27/88)

In article <733@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>Interactive work in layers on the 615 is so sluggish that we use a pair
>of terminals rather than run layers -- it's that bad.

There must be some system problem; layers protocol throughput should be
close to the nominal connection baud rate on a 3B2/400.  It sounds like
you're getting 1-character packets rather than umpteen-character packets.
That is fixable; nag your AT&T support service.

jlt@ttrdc.UUCP (Jeffrey R. Light) (06/27/88)

GWYN at Ballistic Research Lab commented that "...in practically every
way the 630 is superior. (The notable exception is that the top of the
monitor is not flat enough to set my ThinkJet printer on.)..."

Well THAT's just the way we planned it.  The 630MTG has a tilt and swivel
base that was designed to support the MONITOR and NOT an additional printer.

By the way, the monitor runs cool without a fan to avoid that constant
background noise, therefore it is important to have good air flow through
the monitor.  The slope on the cover is great enough to avoid looking like
a storage shelf.

Jeff Light    AT&T Data Systems Group, Skokie IL    312-982-2731   ttrdc!jlt

dibble@cs.rochester.edu (Peter C. Dibble) (06/28/88)

I looked hard for the "best" large-screen multi-window terminal on the market
early this year.  The 630 MTG was the result.  I bought one and I am pleased 
with it.

Scrolling _is_ a bit slow, but considering that it is scrolling a bitmap
it's not bad.  It's certainly not 19.2 kb.  It looks like something between
4800 and 9600 Baud.  It doesn't look strange while scrolling.  Perhaps that
is unique to the 615?

I use the terminal most with OS-9 where I can only use the two standard
windows.  I wish I could use more of the power of this terminal, but even
trivial things like peeling a window and saving it for reference, or cutting
some text out of a window and sending it to the computer (with the mouse)
are useful enough that I forgive this terminal for its slow scrolling.

Does anyone have an idea where I can get enough information about the
630's operating system to write code for it?  I bought the Software
Development Guide and found nothing in there but fluff about C programming
and utilities.  I don't even know how to _invoke_ the operating system yet!
I imagine that I could learn enough from the source package but I would
rather do this without using secret stuff.  I'd like to be able to
give OS-9 support for the terminal away when I'm done with it.

Peter Dibble
dibble@cs.rochester.edu

berg@sdencore.UUCP (mike bergknoff) (06/29/88)

>From: csg@pyramid.pyramid.com (Carl S. Gutekunst)
>*SIGH* What I find "sorry" is people who review a product without even having
> ...
>- There are only two computer vendors in the whole world that support layers:
>  AT&T and Pyramid. Anywhere else, you have to start from source and install
>  it yourself.

I won't state what I find "sorry" about this posting except to note that
Encores UMAX V for the Multimax supports layers. Encores implementation
is unique in that when connecting to the Multimax from an Annex terminal server
via the "call" command, the xt driver actually runs inside the Annex. When
connecting to the Multimax via the Annex "rlogin" or "telnet" protocols,
the xt driver runs on the Multimax as an in-kernel line discipline multiplexing
the pseudo tty connection.

ronc@cerebus.UUCP (Ronald O. Christian) (06/29/88)

In article <28765@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>[...] Yes, it does 132 column mode in a peculariar way. (May I see a show
>of hands of people who use 132 column mode on *anything?*)

I'm waving my hand here.  (Don't you see? :-)  I run vi in 132 column
mode when I'm editing wide files.  (Our L.sys file for instance.)  After
a day in 132 mode, 80 column mode looks really strange.  It seems like
a terminal that scrolls sideways wouldn't be much more useful than the
standard 80 column mode with wraparound.


				Ron
-- 

      Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.)
      {amdahl, pyramid, sun, unisoft, uunet}!cerebus!ronc

      Calling all Fujitsu Usenet sites!  Contact cerebus!ronc or
      ronc@fai.com to establish uucp connection.