Previous: intecolor-vhr19-28-apr-84---16-may-84- Up: ../grinfo.html Next: pgm-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 BITGRAPH and SUN.