Byte Article Page 5

Photo 5 (Click to Enlarge)

As we used the cube, we couldn't help being impressed by the crisp quality of its display. This is no accident: the 17-inch NeXT monochrome monitor has an ample 1120- by 832-pixel display that contains more pixels than most 19-inch monitors (which usually have 1024 by 768 pixels). The monitor has a 94-dpi screen, as compared to the Macintosh's 72-dpi screen. However, this display is only 2 bits (four gray levels) deep. The graphic interface looks very good and makes effective use of the four gray levels.

A 17-inch monitor was chosen for the video display as a compromise between display size and weight. On the monitor's base are two small tractor-style wheels that let you move the monitor easily across a table surface (see photo 5).

The video display has a bandwidth of 100 MHz, with a vertical refresh rate of 68.3 Hz. The monitor uses the positive and negative 12 V DC supplied by the cube's monitor port for power. Inside the monitor's housing are two boards. A step-up transformer on the first board generates the high-voltages required to drive the video tube. The second board handles the rest of the I/O managed by the monitor: keyboard, mouse, and sound.

The 84-key keyboard connects to a port located on the monitor's base. The keyboard also has cursor keys, a numeric keypad, a power-on/power-off key, and pairs of keys that control the volume and screen brightness (pressing one key increases the chosen output; pressing the other decreases it). There are two Command keys and two Alt keys (located on opposite sides of the keyboard) that are mapped separately. There are no PC-style function keys. A two-button opto-mechanical mouse also connects to a port on the keyboard.

There are also left- and right -channel analog stereo jacks, and a jack for stereo headphones on the monitor's base. There's also a jack for a microphone so you can record sounds through the monitor, say, for voice mail. This port uses a telephone codec input that's sampled at 8 kHz, and it uses 8-bit Mu-law scaling for the digitize data. The data is saved within a Sound object that can be utilized by the NeXT Unix mail facility or by NeXT applications.

The Software

As much as the NeXT hardware represents an impressive step forward in areas such as digital signal processing, optical disk storage, and VLSI technology, the NeXT system software is a step forward for software technology. The system offers an easy-to-use graphical interface to Unix and an object-oriented programming environment for programmers and software developers.

It's an understatement to say that NeXT expects Unix to catch on. Steve Jobs told us, "I believe this with every bone of my body: Unix will be the prime operating system of every major company in the 1990s."

So it's not surprising that the cube is a Unix-based system. It features a proprietary windowing system that is designed to shield the Unix command-line interface (CLI) from the user, substituting simple point-and-click mouse operations to manage files and execute applications. NeXT also uses Adobe Systems' PostScript imaging model (often referred to as Display PostScript) to display all text and graphics on the screen. Display PostScript is an extension of the PostScript page-description language (see the text box "Display PostScript").

The NeXT system software also includes development tools for building application interfaces and integrating objects into application programs. These tools are called the Interface Builder and Application Kit, respectively.

Display PostScript

Display PostScript is an extension of Adobe's PostScript page-description language (PDL) and is designed as an imaging model for graphics displays. In theory, software developers could write the display portions of their applications just once using Display PostScript: These applications would run without modification on any computer and operating system that supports Display PostScript. Another major benefit is that the image on the screen would reproduce identically on a printer supporting the PostScript PDL.

Display PostScript is device-independent, and important feature when you consider that specific dimensional sizing is display-dependent in most graphics handlers. For example, if you write a Display PostScript routine to draw a 2-inch square on the screen, the routine will always draw a 2-inch square on any display supporting Display PostScript, regardless of the resolution, color capability, or size of the output device. In other words, Display PostScript permits a "non--unitized" description of an image until it is interpreted for a particular display.

This non-unitized approach is in contrast to pixel-based graphics handlers that can only handle proportional sizing. Of course, you can also specify proportional sizing and Display PostScript. Additionally, Display PostScript automatically uses the maximum color capabilities of the host display, whether it has just black and white, or 16 million colors. The programmer does not have to worry about the characteristics of the output device while writing the application.

The core of Display PostScript is called the DPS Kernel. The DPS Kernel is an interpreter that translates PostScript routines into the images on the screen and is designed to be machine-independent. The DPS Kernel is supplied precompiled in object format to the OEM.

In addition to the Kernel, Adobe supplies the OEM with "front- and back-end" adapters that consist of source code for interfacing to the display devices, the operating system, and the windowing system. The Display PostScript adapters become part of the host computer manufacturer's system software. Of course, modifying these adapters for the host computer system is not a trivial task, and it is usually undertaken by the OEM as a joint or cooperative effort with Adobe Systems. Again, the important point here is that the software developer need not worry about these "adapters."

The main underlying concept of Display PostScript is to isolate the display operation from not only the host computer's operating system but also from its windowing system. The core of Display PostScript fits inside the host windowing system, which in this case is the NeXT windowing system, although it could be anything from Microsoft Windows to X-Windows to QuickDraw.

While the windowing system handles functions such as cut, paste, and copy, and manages the window boxes on the screen, Display PostScript handles the actual painting of the window's contents. DOS, routines for displaying icons, text fonts, and graphics images have to be written only once using Display PostScript. However, the software developer still has to write separate window calls for each windowing system.

Programmers can use the Display PostScript language directly, or they can use a library of C procedures called PSWrap, which is recognized and interpreted by the DPS Kernel.

NeXT fully supports the PSWrap library, but has added many of its own procedures. Some of these are used by the Application Get to create and manage windows; other procedures handle events, mouse, and cursor operations; and still other support "compositeing."

The composite procedures are multibit pixel operators designed by NeXT's sister company, PIXAR. Each pixel has two values associated with it: its data value (or color), and its alpha value (the data's transparency or opacity). On the cube's 2-bit display, composite and makes an icon transparent as it moves over another object on the screen. These compositing operators are easily expandable and will while the NeXT software to migrate to color displays when the time comes.

From brief glimpses of alpha versions of Display PostScript, several industry observers have concluded that Display PostScript has serious performance problems-- it is too slow. Adobe Systems vehemently denies this and says critics have jumped to conclusions based on preliminary demonstrations. Adobe says Display PostScript is very fast provided the code is written properly.

A number of techniques have been developed to improve Display PostScript's performance, including a binary pre-processor (described below), graphic state objects (multiple PostScript graphic states they can be switched quickly by changing a pointer), and user paths (an aggregate of PostScript drawing commands that represent a PostScript path). NeXT uses these techniques and its own compositing functions to boost the speed of display.

As an example of how binary encoding works, say we want to issue the PostScript operator 72 426 moveto. Normally the DPS kernel would have to translate the ASCII digits 72 and four to six into a floating-point format, and the ASCII moveto operator into a binary code. A lookup table uses this binary code in the DPS Kernel to steer execution to the routine that implements the moveto operation. A NeXT application normally calls a PSWrap function, PSmoveto( ), that passes the IEEE 75 for floating-point values of the numbers to the DPS Kernel, along with the corresponding binary code for moveto. This effectively eliminates the overhead of the ASCII translation stage for the DPS Kernel. The NeXT DPS Kernel can process ASCII PostScript commands if required.

Display PostScript has one major limitation in that it does not support three-dimensional imaging. It is therefore not suitable for CAD software. Adobe admits that Display PostScript is not intended for high-and mechanical design applications. (Steve Jobs said that NeXT will support the Renderman Standard, which he called "the PostScript of three-dimensional graphics.")

Display PostScript has some very compelling features for software designers and for end-users. It could greatly facilitate the porting of software applications across incompatible hardware systems.

But the various competitors for display standards-- such as IBM and Apple-- will have to make some compromises before Display PostScript can succeed. Until these compromises are made, both the end-user and the software developer will continue to be plagued by an incompatible world of competing display standards.