Ultracomputer Prototype Note _#9                  Jim Lipkis

Trip Report                                    
Visit to Silicon Valley, Calif.
March 21-24, 1982.

The Bad News  (in general)

The purpose of the trip was to gather information on 68000-based Unix
systems, in particular Lucasfilms Unix, and related hardware and
software for the Ultracomuter prototype machine.  I spoke with
individuals at a number of companies which are interested (from
different standpoints) in microprocessor or small-workstation Unix
systems.  The strong consensus is that it will be some time, possibly
four to twelve months, before integrated systems are available from any
vendor.  Neither hardware nor software components are available
pre-packaged in useful or maintainable configurations. 
The companies were: 

Valid Logic Systems Inc., which is collaborating with Lucasfilms on
development of Unix, and manufacturing their own hardware, including the
processor board--about which more later. 

Fairchild Semiconductors (Advanced Research _& Development Div.), which
has plans for 68000-based Unix and Smalltalk workstations in their new
AI research lab. 

Lang Systems, which is interested in business graphics on 68000s for an
artwork imaging system. 

Dysan, manufacturer of diskettes and other magnetic media and disk
devices. 

I found unusually strong agreement on the following points, considering
the usual divergent pattern of Silicon Valley "popular wisdom". 

First, everyone agreed with our basic choice of operating system and
processor.  Despite Unix's (claimed) weaknesses in the areas of device
support, inter-process communication, etc., nothing in sight approaches
it for portability or general-purpose program environment.  The MC68000
is the only 16-bit processor being considered (by anyone I've talked to)
for any new research or product application.  (The 8086/iAPX286 is still
thriving but its strength, in my view, is in the commercial business-
and personal-computer world where software compatibility is an
overriding consideration.)  The only hesitation concerned the Motorola
MC68451 memory management chip, which no one has yet seen or tested and
is not yet second-sourced by any other semiconductor house.  It is
apparently a brand-new replacement for an older MMU chip that had severe
performance problems and was withdrawn. 

Unfortunately, the 68000-based systems industry is currently in a state
of chaos.  Although a substantial number of small companies, such as
Wicat, are working on and have "announced" complete 68000-based Unix
systems, all seem to have encountered difficulties and no integrated
systems have yet become available.  The result is that the (potential)
68000/Unix community has split into two groups:  those who need a system
for their particular purposes NOW and are therefore building their own;
and those preferring to wait until reliable systems (or at least
reliable components) are available commercially.  Of the people I talked
to directly, Lucasfilms and Valid are in the former category.  Neither
is in the Unix or microcomputer business; both are developing graphics
workstations (for cinematic special effects and CAD respectively) and
decided that they had no choice but spend considerable effort on
non-graphics-related hardware and software development first.  Lang and
Fairchild ARD have decided to wait a year or so to see if usable
68000/Unix systems become available. 

The Bad News (specifics) 

The remainder of this report will outline the current situation as I see
it with respect to specific hardware and software components. Finally, I
will propose a course by which we might take advantage of work done by
Valid and Lucasfilms so as to obtain a 68000/Unix system as early as
possible during 1982. 

68000 Processor Boards.  

[The processor board typically includes
memory management hardware (segment and/or page tables), bus interface,
some PROM for local diagnostics or a local debugger, one or two UARTs
(asynchronous serial ports), some RAM, timer(s), and miscellaneous
registers, LED indicators, etc. in addition to the CPU chip itself.] 

The incipient standard in 68000 processor boards is the Sun, developed
over the last few years by a group of Stanford University's premier
hardware designers (Forest Baskett, Andy Bechtolsheim, Vaughn Pratt, and
others).  The Sun processor board is in use in a number of applications,
including Unix systems, and is available commercially from at least two
licensed vendors.  Several vendors have plans to market complete
Sun-based Unix systems including disks, Ethernet interface, and
graphics. These machines will be packaged around high-resolution bit-map
displays and as a result will be fairly expensive ($25K range).  None
will be on the market for several months.  Stanford and Lucasfilms both
have some expirimental systems running Lucasfilms Unix on the Sun, but
most potential users have been held off by the lack of integrated
systems. Fairchild, for example, has acquired a number of Sun processor
boards but not yet put them to any use. 

Furthermore, problems have arisen with the design of the Sun processor
board itself.  One of the major design features of the board is access
to on-board memory with no waiting, i.e., with no processor wait cycles
required.  While this has been achieved, access to non-local memory has
turned out to be very slow, requiring on the order of 7-8 wait cycles
according to one measurement (or estimate?).  Since local memory is
limited to (I believe) 256K of RAM, the software must then deal with the
dichotomy between high-speed local memory and low-speed bus memory, or
suffer a fairly severe performance penalty.  The bus interface is now
being (or has recently been) slightly redesigned to alleviate this
problem. 

However, there are remaining problems with the bus interface and the
memory map.  After cataloguing a substantial number of such flaws in the
Sun board, the people at Valid decided to design and build their own,
again despite their original intention to build the CAD system out of
off-the-shelf components to as great a degree as possible.  The person I
spoke to at Cadlinc, one of the Sun OEM licensees, also claimed that
flaws in the Sun board prompted them to make some design changes in
their manufactured version. 

The point of all this is that there are substantial difficulties in
designing a seemingly straightforward component like a high-quality
processor board, even given the fully self-contained CPU chip.  Most of
the people I spoke to are skeptical that a company like Wicat, with no
experience in the field, will be able to build and support their own
68000 board without at least as many problems as the Stanford group has
had.  No commercially-developed processor board other than the Sun has
yet become available, although some are expected in the fairly near
future.  The Fortune Systems machine, for example, has been mentioned as
a better prospect than Wicat.  (We cannot use the Fortune machine,
however, because of addressing limitations and because no source code is
provided.) 

(It is true that Wicat successfully built the current System 150
processor.  However, it has no memory map hardware; we know nothing
about provision or support of on-board diagnostics, UARTs for testing,
etc.; and its multibus interface is probably weak--rumors from people
who have visited Orem, Utah, suggest that access to bus memory is VERY
slow, and this could get much worse when memory mapping tables are
added.) 

Device interfaces 

Multibus device controllers present as many problems as 68000 processor
boards.  Many companies have rushed disk, tape, and telecommunications
controllers to the market since the emergence of Intel's multibus as a
de facto and also IEEE-mandated standard for 16-bit processors.  Poor
overall quality has been the result to date.  The chances that any
individual card, obtained from a relatively reputable vendor, will work
reliably are said to be appallingly low. 

A further problem is that device control protocols are highly variable
among different controllers.  Because the multibus is a very new
interface, and because the devices sitting on all "sides" of it are new
and produced by different companies, there is no hard standard for the
bus protocols.  (The unibus, by contrast, was well defined by the
protocols of the PDP11 processor and miscellaneous DEC devices and
software.  Even so there have been occasional problems with non-DEC
unibus peripherals that violate the unibus standard in subtle but
visible ways.)  The result is that timing and sequence of bus signals
cannot be assumed by the programmer.  It is possible to write device
drivers for multibus devices, of course, but one is likely to end up
debugging the controller and its documentation along with the software. 

Devices 

A large percentage of the newer secondary-storage peripherals are based
on new technology that is not yet quite mature.  High unreliability is
again the result.  The new generation of high-density 5 1/4" Winchester
disks is particularly prone to this syndrome.  Because the medium (disk
pack) is nonremovable the impact of disk failures is magnified.
Furthermore, the Unix file system is less than robust on the most
reliable hardware and can be extraordinarily sensitive to occasional
disk errors.  (Two weeks before my visit to Valid, one Unix system was
down for two days while a system programmer worked nonstop to patch the
file system back together.)  Of course some manufacturers' disk drives
are more reliable than others; care must be taken in selecting products.
 It is likely that the newest, highest-density products (e.g., the 16 MB
micro-Winchester packaged with the Wicat) will present the most
problems, however. 

These problems are being addressed commercially in several ways.  The
CDC Lark drive is a micro-Winchester packaged with an ultra-high density
removable diskette with the same capacity as the hard disk.  The
diskette can be removed and reloaded for backup.  Other manufacturers
are using similar approaches including cassette-like devices and,
evenutally, removable hard disks.  Naturally none of these are available
quite yet. 

Software 

It is clear that porting Unix to a 68000 (or anything else) is far less
trivial than one might imagine.  The original port of what is now known
as Lucasfilms Unix or Sun Unix was done at MIT a couple of years ago (by
John Gula).  This included the code generator for the C compiler, the
small part of the Unix kernel written in assembly language, and some
device drivers--in theory, all that's required to port Unix to a new
processor.  Several person-years of further development, done jointly by
Lucasfilms and Valid, turned out to be needed to produce a clean
implementation of the system.  I don't have details, but the work
primarily involved debugging and portabilizing (i.e., ferreting out
residual PDP11 dependencies), device support, some performance work, and
bootstrap utilities.  This development is continuing at both Lucasfilms
(actually its new subsidiary, Sprocket Systems) and Valid. 

Lucasfilms Unix is now almost certainly the furthest developed of any
68000-based Unix system (with the possible exception of those within
Bell Labs).  It has the further advantage of being available in source
form to universities.  This applies only to software obtained directly
from Lucasfilms or Valid, however.  The vendors of integrated Sun
systems (such as Cadlinc) are developing their own modified versions of
the Lucasfilms software to package with their machines.  The result is
that the source code for the system actually running on, say, the
Cadlinc Sun workstation will be unavailable to us.  This is another
obstacle to our use of commercial Sun processors. 

Proposal  (a path out of the swamp?) 

The previous paragraph contains some compelling arguments for using the
Lucasfilms Unix system.  It is available with source for a nominal fee,
and we have a promise of some amount of assistance from Mark Seiden of
Valid (who recently worked at IBM Yorktown Heights, and, long ago, at
Courant).  Officially, the system comes with no maintenance commitment
whatsoever. 

I believe the arguments for using Unix in general for our prototype
machine are clear, but will not take the matter up here. 

The question of hardware thus remains.  It appears that our only course,
other than waiting for many months, is to assemble our own development
system on which to run the Lucasfilms software.  This entails taking on
a somewhat greater responsibility for hardware interfacing and
maintenance than we have foreseen in the past.  There will be no option
of shipping the entire machine back to some single vendor (like Wicat)
when something breaks mysteriously.  However, we can minimize the impact
of many of the problems mentioned above by configuring the machine
carefully. 

First, we can obtain the same basic components (processor board, device
controllers, and even devices) that are being used in the machines at
Valid, Lucasfilms, and Stanford that currently run Lucasfilms Unix. The
Valid processor board (developed for use in lieu of the Sun) is
available for around $3500.  Valid will also sell us multibus memory
boards.  The card rack, power supply, disks, and controllers used by
Valid are available from retail distributors.  Because the hardware will
then correspond at least generically to that on which the software has
been developed, we should have little or no messy interface debugging to
do (involving either device controllers, memory management hardware, or
processor board facilities).  Strapping options and other interfacing
decisions will have been made for us.  Unquestionably, though, we will
end up learning a great deal more about the hardware components,
interfaces, and software device drivers than if we were purchasing a
turnkey system.  Since this is only the beginning of the Ultracomputer
prototype project, extra familiarity with the hardware, etc. at this
stage can only be a benefit. 

Second, we can maintain some control over the quality of peripheral
devices, especially disks, by taking advantage of experience gained with
different vendors' equipment at Valid, Lucasfilms and Stanford. 

Finally, we can decrease our vulnerability to disk failures and file
system crashes by adding a tape drive to the configuration.  Valid uses
a half-inch IBM style tape drive that is surprisingly cheap (I believe
$3-4K), and they consider it essential for backup. 

I am working on getting more information regarding hardware components.
We have documentation on the Valid processor board but not on any other
parts of the Valid system.  Since Stanford is running Lucasfilms Unix on
their own hand-assembled systems as well, we should (and will) talk to
them as well as Valid when compiling a detailed list of hardware
options.  A more detailed version of this proposal will be forthcoming
at a later date. 

(One more point regarding the Valid system.  An early prototype of their
real product, a CAD system based on Unix, is going to IBM Yorktown
Heights.  This machine would be a superset of ours, assuming we ended up
duplicating Valid's machine component by component.  Cooperation with
Yorktown might then be helpful for both hardware and software
maintenance.)