What is a DEC VT-61/T ?

Al Kossow aek at bitsavers.org
Tue Jun 14 20:48:01 CDT 2005

Al Kossow wrote:
>  From memory, they are used with DEC's typesetting system (DECset)
> They were commonly used by newspapers.

here's a reference. They were used as terminals for DEC's transaction
processing system (TRAX)

Newsgroups: comp.os.vms
Message-ID: <9408202049.AA16873 at uu3.psi.com>
Date: Sat, 20 Aug 94 16:40:33 EDT
From: Jerry Leichter <leichter at lrw.com>
Subject: RE: What is block mode?

	This might be a dumb question but I see in the SET TERMINAL command a
	qualifier called /BLOCK_MODE. Can somebody please explain to me what
	this might be used for ? What software would one need on the VAX to
	talk to a  block mode terminal ?

"norris8016 at delphi.com" comments:

	That qualifier is a relic of the days when DEC sold the VT131 block
	mode terminal.  How well VMS handled such beasts I don't know.

while "CANTERA at cisv.jsc.nasa.gov" describes IBM's block mode terminals, which
transmit and receive blocks of characters - often whole screenfuls - at a

Both are more or less right.  A bit of background.  First, the reason the
qualifier exists at all is to help one write portable software - portable
among different terminals, that is.  At one time, on many earlier DEC OS's
and on VMS prior to perhaps V3 (I'm not sure of the timing), operating systems
kept very little information about terminals.  Programs issued "what are you"
escape sequences to terminals and acted based on the reply.  Unfortunately,
new terminals issued new replies - and programs stopped working.  Anyone who
used screen-oriented programs on, say, RSTS or RSX in the early '80's will
recall programs that worked fine on VT100's, but refused to work on the
functionally identical VT102.

The eventual solution was to (a) come up with a list of "relevent" terminal
characteristics; (b) centralize (in SET TERM) the knowledge of the connection
between particular terminals and these characteristics; (c) insist that
programs ask the OS about the specific characteristics they needed to operate,
rather than try to figure out exactly what kind of terminal they were talking
to.  In addition, (d), the terminal answerback sequences were re-designed so
that terminals, in addition to identifying themselves as "VT100" or "VT200
series", also reported their support of particular feature classes.  The
escape sequences involved are long and messy, and few programmers bother to
try to parse them - they rely on SET TERM/INQUIRE's ability to do so and set
the appropriate OS characteristics.

The /BLOCK characteristic is one of just those characteristics.  As "CANTERA"
notes, the protypical block mode terminals are used in IBM environments.  The
interaction looks very different from the typical interaction with an ANSI
terminal:  The host sends a large block of data defining a form with various
fields to be filled in to the terminal.  The user fills in the form.  Nothing
is sent back to the host:  The terminal positions the cursor to various fields
in the form, and can enforce various constraints (a field is required; a field
can only contain digits; a field is can hold up to 10 characters; and so on).
When the user has filled in all the fields, he hits "send".  The terminal
gathers all the data from all the fields into a large, structured block and
sends it to a host controller which receives it as one block, taking only on
interrupt (rather than an interrupt for each character, as is typical of a
DEC ASCII environment).  Where appropriate, this kind of terminal imposes much
less load on the host - IBM mainframes that by today's standards were less
powerful than a typical PC supported hundreds of such terminals.  Of course,
if you want to write a screen editor like EDT, such a terminal won't work.

As far as I know, DEC only made one true block mode terminal:  The VT61 (or
was it the VT62?  I can no longer remember?)  The VT61 was designed to be used
with a long-forgotten system called TRAX.  TRAX was a PDP-11-based dedicated
transaction-processing system.  A special terminal interface connected VT61's
to a TRAX system; communication was based on multi-drop polled DDCMP.  The
VT61 could do all sorts of fancy on-screen editing before sending data back
in a single DDCMP packet.  (The VT62 - or perhaps I have the numbers backward
- was a VT61 that used standard async lines.  I don't know what they were
supposed to be used for, and it's not clear to me that DEC ever actually
*sold* any.  Both terminals were based on the VT52, and did an impressive
amount of processing for their size, given the era in which they were built.
Within DEC, VT62's were used as VT52 replacements.  When used this way, their
main advantage was that, unlike the VT52, they supported reverse video.)

The VT130 and the VT131 that replaced it were "pseudo-block-mode" terminals.
They were, in a way, like the VT62:  ASCII terminals connected over async
lines that were able to do local editing and could send "blocks" of data -
which were typically received a character at a time using standard async
interfaces.  (In principle, you could build hardware to efficiently receive
whole delimited blocks, but I don't think anyone ever did - certainly, DEC
didn't.)  No DEC software ever used the block mode features, but a few third
party vendors did (for fill-in-the-form and similar applications).  When the
VT200 series was introduced, none of the terminals in the series supported
block mode.  VT13x users stayed with their existing terminals.

By the time the VT300 series was being designed, there was a clear demand from
those users for a new terminal to replace the aging VT13x's - which DEC was
actually still selling, I believe.  Given the changes in technology over the
years, the designers decided that it wasn't worth it create a special block
mode VT300.  Instead, the block mode features of the VT13x, with a few
additions, were made part of the definition of the VT330 and VT340.  (I don't
recall if the VT320, which wasn't a "from the ground up" re-design but mainly
a cost-reduced VT220, supported block mode.)  If you look in the VT330/340
documentation, you'll find a chapter on "local editing mode", a more accurate
description of the feature than "block mode" - but it's the same thing.
You'll also find a note that "software support is required to use these
features."  As far as I know, no DEC software has ever used these features for
anything - they were included entirely for users of non-DEC software who had
been relying on the VT13x's.

BTW, while it's not simple - it takes several keystrokes - it's possible to
use the VT130's local edit mode to pick up anything currently on the screen,
edit it, then send it to the host (i.e., on-screen cut and paste).  Handy
sometimes - but it's been long enough that I no longer remember how to do it!

							-- Jerry
						[Who was there when the VT300
						 series was being designed.]

More information about the cctalk mailing list