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.