Previous: intecolor-vhr19-28-apr-84---16-may-84- Up: ../grinfo.html Next: pgm-06-nov-81-

MICROANGELO-IM-1 [06-Nov-81]

 We have recently received two  Microangelo IM-1 graphics terminals  and
 an interface for them is now operational.  The Microangelo is  actually
 a graphics board attached  to a monitor, and  is manufactured by  SCION
 Corporation in  Vienna, VA.   SCION has  recently produced  a  graphics
 system for  use  by  the  U.S.  Congress.   The  Microangelo  has  been
 advertised in the beginning pages of Byte Magazine for more than a year
 now, but  is only  available from  SCION with  an S-100  bus, which  is
 suitable for connection to microcomputers, but not to big machines.  We
 found a company,  Form and  Substance, in  West Lake  Village, CA,  who
 produce a finished Microangelo terminal, which they call the IM-1, with
 a standard RS-232C interface and a 15-inch green-phosphor Ball  monitor
 giving 85  characters  on  40  lines,  and  a  dot  resolution  of  512
 horizontal by 480 vertical.  Form and Substance bid these at $3000,  an
 extremely attractive price for a graphics terminal of this  resolution.

 Apart from  the price,  the  Microangelo has  a  feature which  is  not
 available in any other graphics terminal  that I am aware of.  One  can
 upgrade the terminal to grey scale  simply be adding extra boards,  and
 by changing the monitor, one can  convert to color.  By the time  about
 $10K has been  spent, one  has a  color terminal  with 256  displayable
 colors from a choice of over 16 million.

 The documentation  supplied by  the two  companies is  excellent.   The
 Microangelo is driven by an 8-bit 4-MHz Zilog Z80A microprocessor  (and
 conversations with  SCION  indicate  that  a  16-bit  Motorola  MC68000
 replacement may be in the works).  All of the ROM-resident driving Z80A
 subroutines are described in the Microangelo User's Manual, with  name,
 entry point  address,  arguments,  registers  modified,  and  function,
 allowing them to be called from user Z80A code which can be  downloaded
 from  the  host.   Besides  code,  individual  characters  or  complete
 character sets (defined on  a fixed grid 6  horizontal by 12  vertical)
 can be downloaded into one of two 128-character ASCII sets in memory.

 The Microangelo can also on request transfer a memory block of any size
 from any  address  back to  the  host.   This makes  it  possible,  for
 example, to get  the screen  bit map  back to  the host,  and Form  and
 Substance will  supply  a low-cost  Anodex  dot matrix  printer  to  be
 attached to the host which can be used to print the screen image.   The
 screen image  of 512  x 480  bits corresponds  to 30720  bytes, so  the
 transmission time can be significant.  We have a student implementing a
 run-length encoding scheme which I  expect will compress this to  about
 2000 bytes.

 With Screenware  PAK I,  the  Microangelo acts  as  a very  dumb  glass
 terminal, and  has commands  to  set and  read text,  alphanumeric  and
 graphics cursors,  tracking  cross, and  crosshairs,  as well  as  draw
 absolute vectors light, dark, or complemented.  Rectangular regions can
 be filled  light,  dark, or  complemented.   The Microangelo  can  also
 complement the entire bit map, so at plot termination we complement  it
 twice to flash the screen, telling the user the plot is done.   Support
 for a light pen is provided,  with the interrupt handling intrinsic  to
 that device being carried out entirely by the Microangelo, so that  the
 host software need only  query the Microangelo for  the last light  pen
 position.  This can make a light pen  as convenient to handle as a  bit
 pad, although it still has the problem that the user has to hold it  up
 to the screen, partially  obscuring it from view,  and getting a  tired
 arm in the bargain.

 Graphics commands consist of a one-byte opcode, followed by 0, 1, 2  or
 4  data   bytes.   Vectors   are   always  4   bytes,  so   that   when
 higher-resolution screens and microprocessors  with more memory  become
 available, the same commands will be able to address up to 65K dots  in
 each direction.  We are ordering Screenware PAK II (about $400) on  ROM
 for both our  terminals, because  this doubles the  speed, extends  the
 graphics  primitives  to  circles,  relative  vectors,   user-definable
 objects, and filling of  arbitrary polygons, and importantly,  provides
 for a split screen, so that  alphanumerics appear in a separate  window
 and do not overwrite the graphics.  PAK II also makes the terminal more
 intelligent as  an  alphanumeric  display, with  cursor  motion,  clear
 screen, clear  to  end-of-line and  clear  from cursor  to  end-of-page
 commands which are important for support by screen-based editors.

 On the minus side, there are  at least six areas where the  Microangelo
 could be better.  First, and most serious for us, is that it uses 8-bit
 characters, with the  setting of  the high-order  bit (codes  128..255)
 indicating  a  graphics  opcode.   Although  this  makes  for  a  clean
 interface without the tedious  bit packing that  is necessary for  most
 Tektronix  terminals,  on  DEC-10   and  -20  computers,  it   requires
 modification to  the  system  monitor to  support  the  Microangelo  in
 alphanumeric mode.  The reason  for this is  that DIGITAL decided  with
 the -10's and -20's (and possibly others of their products) that  since
 ASCII is a 7-bit code,  the 8-th bit can be  used as a parity bit  when
 text  is   transmitted,  with   obvious  disastrous   results  on   the
 Microangelo.  Since our DEC-20/60 is  a research machine over which  we
 have full control, the  monitor changes are no  real problem, but  most
 DEC installations  would probably  not act  favorably to  a request  to
 patch the  monitor just  to  support one  kind  of terminal.   The  I/O
 package that we use for all  <PLOT79> graphics terminal I/O uses  8-bit
 bytes instead of regular 7-bit text bytes (padded to 8 by the monitor),
 so the Microangelo  could still be  used as a  graphics display on  DEC
 systems without monitor patching.

 The second  problem  with  the  Microangelo is  the  speed,  which  the
 Microangelo MA512 board limits  to 3000 baud  (higher speeds result  in
 loss of characters).  Screenware PAK II is claimed to increase this  to
 6000 baud, but this is still below the 9600 baud used for almost all of
 our terminals.   High baud  rates are  essential for  effective use  of
 screen-based editors like EMACS,  which I spend most  of my day  using,
 and it  is frustrating  that with  a terminal  that can  show 40  lines
 instead of the usual 24, that a  lower speed must be accepted.  I  hope
 that SCION gets an MC68000 version on the market, since that  processor
 should be able to offer substantially better performance.

 The third problem  is that even  with Screenware PAK  II, the  terminal
 does not emulate any existing industry-standard terminal type, such  as
 the DEC VT52  and VT100, or  the ANSI screen  terminal standard.   This
 means that in order to support it decently on the DEC-20, we will  have
 to write code to support it in  EMACS, and add code to the system  EXEC
 to know about the different terminal  commands.  It may be that we  can
 use the downloading  of code to  install a VT52  emulator, which  would
 remove this  problem.   I have  urged  SCION to  rewrite  the  terminal
 emulation code,  and they  did offer  to  consider it  if I  sent  them
 detailed specifications.  The local approach may be faster, however.

 The fourth  problem  is  that  the  coordinate  clipping  algorithm  is
 unsatisfactory.  It is not as bad as on the Tektronix terminals,  where
 only the low-order 10  or 12 coordinate  bits are transmitted;  vectors
 which are partially visible can then be totally reversed in  direction.
 The Microangelo instead moves an out-of-range 16-bit coordinate to  the
 nearest edge  of  the  9-bit  resolution screen.   This  results  in  a
 translated vector  whose direction  may be  changed somewhat,  but  not
 reversed.  Given that one has a Z80A microprocessor to program, I think
 the trouble should have been taken to do the job properly, since a  few
 instructions would suffice  to determine  whether a vector  was out  of
 bounds and therefore required clipping  by a fancier algorithm than  is
 normally used for  vector generation.   With Screenware  PAK II,  where
 circles (but  not arcs)  can be  selected by  an opcode  followed by  a
 one-byte radius, a screen filling circle can be drawn.  However, if  it
 crosses a screen edge, the out of bounds arc wraps around to the  other
 side.  I feel strongly that circle  and circular arc primitives are  of
 little use in the  vast majority of  graphics applications, although  a
 more general Bezier  or B-spline  curve representation  could be  quite
 valuable.  However,  if the  device  has any  intelligence at  all,  it
 certainly ought to be able to clip correctly.

 A fifth problem is  due to the 16-bit  address space limitation of  the
 Z80A -- graphics and text must share the same memory, making the  split
 screen support of Screenware PAK II essential for interactive  graphics
 use.   The  Terak  displays,   on  the  other   hand,  use  an   LSI-11
 microprocessor with double the address space, so they keep the graphics
 and alphanumeric screen images in separate sections of memory.

 The sixth  problem  is  that  since the  Microangelo  MA512  board  was
 designed only  for graphics,  it is  not aware  of the  existence of  a
 keyboard;  that  is  connected  to  the  host  only  through  Form  and
 Substance's S-100/RS-232C parallel to serial interface.  Thus, niceties
 such as downloadable  keys and  command transmission  from keyboard  to
 display excluding the host(e.g.  for  screen clear) are not  available.
 It may be possible to obtain an intelligent keyboard that will do this,
 but we have not yet investigated that.

 The Microangelo so far appears to be one of the few graphics  terminals
 with acceptable resolution at a reasonable price (for us, not more than
 about $4K).  There are two terminals on the near horizon which offer  a
 1024  by  768  display  on   an  MC68000-based  system.   See   entries