🚀 go-pugleaf

In article <1991Feb19.043620.12415@cs.utk.edu> shuford@cs.utk.edu
(Richard Shuford) writes:
+---------------
| In my opinion, a major handicap for NAPLPS was that for a long time the
| only equipment available for encoding the images was a special computer
| sold in the United States only by AT&T, costing tens of thousands of
| dollars.  This major capital start-up expense delayed or killed a lot of
| creative ideas for using the NAPLPS protocol and/or teletex.  Eventually
| there were some cheaper encoding products, based on an Apple or IBM
| PC-type platform, but the initial enthusiasm had already declined.
+---------------

Historical trivia: During the development of the Fortune Systems 32:16
desktop Unix computer (circa 1981), we had a big internal argument about
whether the Fortune-supplied ASCII terminals were going to used ANSI X3.64
or NAPLPS for their character sets and control codes. X3.64 was (and is)
largely identified in many people's minds as being "vt100", mainly because
DEC was one of the first volume terminal manufacturers to embrace X3.64,
although by 1981 dozens of manufacturers had publicly announced support
for X3.64.

But the marketing guys said, "AT&T is bigger than DEC", and NAPLPS won.

Of course, look around today and compare the number of async 80x24 terminals
that do X3.64 ("vt100 compatible") versus the number that do NAPLPS...  ;-}


-Rob

p.s.
The Fortune terminal used only the ASCII and character-block-graphics
subset of NAPLPS, so it wasn't "really" a NAPLPS terminal, in the sense
of any kind of videotext capability.

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311