Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ OverviewC&C 1980SERC Council 1981ICL Management August 1981UNIX Strategy October 1981Guidelines September 1982PERQ News December 1982Guidelines January 1983
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACDSingle User SystemsPERQ PapersCritical
ACDSingle User SystemsPERQ PapersCritical
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
C&C 1980
SERC Council 1981
ICL Management August 1981
UNIX Strategy October 1981
Guidelines September 1982
PERQ News December 1982
Guidelines January 1983

The PERQ Computer

SCIENCE RESEARCH COUNCIL

RUTHERFORD AND APPLETON LABORATORIES

COMPUTING DIVISION

SINGLE USER SYSTEMS

28 August 1981

F R A Hopgood (with R W Witty)

Paper produced for meeting with ICL on the evening of the 28 August 1981. ICL were proposing to switch from Three Rivers to Apollo. Bob Hopgood flew back from the USA the day before to head off this change, drafting the paper on the plane on the way back.

1. INTRODUCTION

We have put forward a proposal to SERC that we should have a co-ordinated programme of development in this area to avoid duplication. The major features of such a system are:

  1. High Speed Processor
  2. Quality A4 display
  3. Large Virtual Memory local to system
  4. Ability to interconnect easily with other servers and clients

We see its applicability in all areas from office automation, real time control, software workstations, CAD, AI research etc.

We have supported the ICL initiative with Three Rivers on the basis that it gives us the ability to provide such a co-ordinated programme using a supplier with a UK involvement which we would hope would lead to a UK product for the Mark 2 version. We are not interested in a marketing operation or one with no clear long term Mark 2 project of greater power and quality.

We should be clear that we have two objectives. First and foremost to provide the vehicles required by the research community. If possible, our second objective to help UK industry.

2. APOLLO and PERQ

There are a number of single user systems on the market which fall into broad classes. The first are the bit-slice microcoded systems while the second use standard microprocessors and depend on Silicon Valley for additional performance. Of the former, the Xerox PARC developments stand out as the prime example of what is possible starting with the Alto and developing through the Dolphin and Dorado; other examples which are not really in production are the Symbolics LISP machine and BBN's activities. PERQ is the best value for money in this category and clearly benefits from the Xerox work. It is less costly and more powerful than the Xerox Dolphin - its nearest equivalent.

The microprocessor based systems can be divided into 8-bit and 16-bit versions. The major entry in the 16-bit field is the IBM Personal Computer System coming in at 4 × Apple in performance. Chromatics produce a good colour system and companies such as Terak will also be in this field. Apollo is a significant member of this class being at the high cost high performance end. Needing less development, this market is the more volatile and new systems will appear as and when Silicon Valley produce devices.

3. COMPARISON

A quick thumbnail comparison of the two products is as follows:

High Speed Processor

PERQ has a considerable performance edge - probably a factor of 2 and this will be even greater in the floating point area where Apollo is having to do in software what Three Rivers will do in microcode. Both have similar plans for floating point hardware.

PERQ has am intimate display/processor connection which ensures good display performance which we regard as essential. The rasterop hardware and separate cursor bit plane ensures quality interaction - essential for devices of this type. The quality of the user interface is of paramount importance. Apollo have attempted to achieve good display performances by high speed I/O operations. The lack of rasterop makes some operations impossible even though they are highly desirable. For example, movement of non-rectangular entities is almost impossible on Apollo.

Because Apollo will need to change the low level architecture as Silicon Valley changes, it will be possible to only provide a standard interface at the programming language level. This has both advantages and disadvantages. Experience at Xerox and Carnegie suggest that different microcodes may be necessary for different application areas. Currently Xerox have four major microcodes - MESA, LISP, SMALLTALK and BCPL. The latter is mainly historical. MESA is being used in the Office Automation systems while SMALLTALK in the CAI quality interaction area. Carnegie have found it impossible to do VLSI without providing microcodes specifically aimed at this application.

In an SERC environment, the ability to change the microcode is a feature which we do not wish to encourage indiscriminate use of but one which may be essential for adequate performance in particular areas.

Competition in the microprocessor based systems will be intense. Apollo can get strong competition from companies such as IBM and DEC. Its major assets are a strong management team with good hardware and operating system experience. It will probably survive due to its ability to move quite quickly - PRIME all over again.

QUALITY DISPLAY

Three Rivers have a long history of producing world class displays. Both their refresh display and colour display systems in the past have been state of-the-art.

The PERQ A4 display is the best on the market and that includes the display manufacturers themselves, VMI. At SIGGRAPH, the PERQ display was significantly crisper than the VMI display although both used the same tube and you would have thought the manufacturers' would know their own system. Three Rivers know the display business. The PERQ display is superior to all the Xerox systems - the current market leaders.

Apollo have no display experience. The current A4 display is running at 30HZ and is unuseable in many application areas. Apollo plan to go to 60Hz and it is clear that the system was designed on that basis. However, will Apollo have the technical ability to produce the same quality as Three Rivers even if they use the same tube? Probably not.

The lack of awareness of the graphic requirements is exhibited in the lack of input devices on the Apollo as announced, no special hardware for cursor movement and the decision not to implement rasterop. Apollo will learn in an imitative way. Will that be sufficient to capture the market? Apollo's future plans for a touch pad already rejected by Three Rivers in favour of a mouse would indicate Three Rivers has a strong edge in the display area.

MEMORY

Both systems are committed to going to 1Mbyte systems. The people at Apollo have done it before and you must assume that they will get this right before Three Rivers. Apollo have allowed space for the new PRIAM large disc and will get it into the field. Three Rivers have unfortunately banked on the Shugart and cannot get the PRIAM into their cage. Certainly Apollo have an edge here. The future may well be with smaller size discs but, currently Apollo have a distinct advantage if larger memory sizes and high cost systems are of interest. Similarly, they have interfaced 300Mbyte drives - but not a type easily available in UK.

COMMUNICATIONS

Three Rivers have the standard Ethernet connection working and are well placed to go with de facto standards - particularly INTEL chips. Putting other devices on a PERQ LAN should be relatively easy.

The Apollo approach has been to build a token ring which is an intimate part of the device. There is a strong interaction between the network and disc controller to ensure good network performance. It will not be easy to connect other devices to the ring other than via Apollos. This is a manufacturer's standard like PRIMENET which is undesirable in the SERC environment. It ensures long term dependence on this LAN technique. Ability to gateway to other networks mayor may not solve the problem.

Apollo has a clear advantage at the moment in terms of network support - software is up and running but it does lock you into their total system concept.

DEVELOPMENTS

Both companies have similar short term developments - larger memories, colour displays, bigger discs, cheaper systems etc. The Apollo colour display will be a lower quality product than the Three Rivers. The Apollo implementation sounds a bit of a pig and may well not perform.

My view is that innovation will come from Three Rivers and they will get the products right. Less clear that Apollo are capable of making decisions of the right quality.

COLLABORATION

Three Rivers has a strong collaboration with Carnegie Mellon which will greatly add to the viability of the product. IBM have also bought 4 systems and wish to use it for proto typing systems. The Apollo collaborators are not of the same quality. Brown are definitely second class and both companies have involvement with Yale.

SERC and CMU would significantly move the external support clearly to Three Rivers advantage. SERC going with Apollo would not compensate for the heavy CMU involvement which must not be underestimated. They have multi million dollar projects which depend on PERQ and the people involved are world class.

PRODUCTION

Neither production facilities are very good. Three Rivers are cramped for space. However, they have more equipment, do more themselves, do better environmental testing etc. Apollo do understand how to produce in quantity and will have less trouble in getting up to volume. Both companies have similar capacity for producing systems - ICL would be a significant improvement on either.

4. CONCLUSIONS

At the moment there is no question that Three Rivers have the better hardware which is more appropriate to SERC's requirements. ICL marketing Apollo's will have little effect on that statement.

Apollo software is better in some areas and will develop along the lines that PRIME have taken in the past. The Three Rivers software position depends entirely on CMU - the indication is that this will change things in PERQ's favour but this will not be clear until the autumn. My own estimate is that it will appear and will be good.

Long term plans are not very clear in either company. ICL would certainly benefit Three Rivers more than it would Apollo. ICL has experience that complements Three Rivers. An ICL/Three Rivers consortium does increase the viability of PERQ in as far as the weakness will be eliminated by ICL. An ICL/Apollo deal hardly enhances the product.

5. MACHINES AS OF TODAY

PERQ APOLLO

1. Microcoded

  1. LISP, POP2, etc
  2. Floating point microcode < 5 µsec FP ADD

1. Not microcoded

  1. Cannot do tailoring
  2. Software floating point 150 µsec FP ADD

2. Rasterop

  1. can do non rectangular moves (shadow mask)
  2. homogeneous memory
  3. can execute out of display memory
  4. parity on all store
  5. PERQ got wider data paths where it matters therefore faster
  6. PERQ got hardware line drawing
  7. PERQ can do very fast smooth scrolling 1 scan line at a time (Williams seen it)
  8. hardware works out optimum order to move rectangles to get movement right
  9. easy to draw and erase lines

2. Bit mover

  1. cannot do non rectangular moves
  2. speed penalty when moving into display buffer from program memory (speed differences)
  3. cannot execute out of display memory
  4. drops pixels because no parity on display memory
  5. cannot do Troff simulator because char generator works only on rectangular areas
  6. to get speed need to store font in display memory. Makes font changing slower
  7. slower data paths
  8. no hardware line drawing, rubber band lines problem because no XOR
  9. Nelson claimed rasterop no good at scrolling. Rubbish.
  10. bit mover must be explicitly programmed as to which way to do moves
  11. assembler routine to draw line, nothing to erase lines so slow

3. Ethernet/Camb Ring

  1. ethernet working
  2. Cambridge Ring by 1Q82 (RAL)
  3. easy to build into UNIX. Already done for Ring by RAL.

3. Non standard LAN

  1. token ring working
  2. hard to put on ring/ethernet because must be done by multibus
  3. Token ring built intimately into system so other LANs must be peripherals and hard to connect into operating system (Mike Greata said this)

4. IEEE 488

  1. industry standard

4. MULTI BUS

  1. not industry standard because cannot handle multiple master controllers

5. CURSOR

  1. 64 × 64 separate cursor excellent (Xerox 16 x 16)
  1. no cursor hardware, failed to understand!

6. DEVELOPMENT

PERQ APOLLO

1. Network

Industry compatible, gateways easy

1. Network

Home grown, incompatible

2. B/W DISPLAY

Excellent already

2. B/W DISPLAY

b/w tube in test rig, 2 characters, not on Apollo, VMI tube

3. PERFORMANCE

  1. half VAX, P550
  2. floating pt microcode; P550 speed; will both use 8087 fp chip for industry standard
  3. 16K writable control store very soon will allow speed ups of critical functions + paging etc
  4. 1 Mbyte board soon
  5. CMU microcode for paging and floating point is good and fast

3. PERFORMANCE

  1. Apollo + cache + floating pt chip will still only be P250-P550, says Greata
  2. Caltech say currently one-third VAX but operating system response equivalent to 4 user VAX
  3. 1 Mbyte board soon

4. COLOUR and RASTEROP

  1. handwaving
  2. 3RCC know will need 2 Mbytes, must be homogeneous and all in address space. Must be Rasterop but no known solution for colour. Must be parallel else degrades speed for colour.
  3. no work in progress

4. COLOUR AND RASTEROP

  1. handwaving
  2. Do not understand. Propose serial changes to each bit plane in turn. Planes not all in address space and again not homogeneous. Therefore memory not available to programmer. Do not know how to do rasterop.
  3. not actively working on it as far as Tony Williams could see
  4. no known plans for b/w rasterop

5. INPUT DEVICES

  1. already had touch pad working and abandoned. Integral bit switch.
  2. already got bit pad, pen and puck
  3. 2 mice including 6 degree freedom inertial mouse.

5. INPUT DEVICES

  1. developing touch pad; too small; poor for resolution; needs separate hand to use button to signal hit (two hands!)
  2. Brown tried bit pad on serial line. Was failure because no cursor hardware. NO PLANS FOR CURSOR!
  3. No plans for mice

6. VLSI, GATE ARRAYS

  1. no plans that Williams saw.

6. VLSI, GATE ARRAYS

  1. Williams saw no evidence of any gate array work

7. ARCHITECTURE RIGHT

  1. Intimate Memory/Display connection
  2. Bit slice for power
  3. Microcode
  4. HW Paging eventually

7. ARCHITECTURE RIGHT

  1. loose coupling via I/O + bandwidth
  2. Depends on Silicon Valley; 432 in trouble, order code correct. No long term commitment to any architecture
  3. Inflexible - only able to work at programming language level

8. PERIPHERALS

  1. 1 Mbyte Sept delivery
  2. Stay with disc
  3. No plans

8. PERIPHERALS

  1. 1 Mbyte designed and prototype
  2. 66 Mbyte Winchester
  3. 300 Mbyte drive

9. HARDWARE

  1. Getting OK

9. HARDWARE

  1. Excellent board design

10. PERFORMANCE

  1. Best value on market. Fl Pt microcode will be fast.
  2. No low cost

10. PERFORMANCE

  1. Well below PERQ. Even with enhancements may not get there. No fl pt.
  2. low cost - complete redesign

7. SOFTWARE AND USERS

PERQ APOLLO

CMU

31 + 10 PERQs

  1. Super Unix process to process already working + Ada, LISP, CFS etc.
  2. big team, impressive
  3. Unix will run on Spice and software can move between both.
  4. Unix will be ahead of Apollo on system.
  5. good graphics and interaction
  6. Bell N done Pascal interpreter for Smalltalk 80
  7. Lucas done C compiler so Unix not too far away. Will be released by 3RCC.
  8. USS Carl Vincent contract.
  9. Ron Becker Unix contract approved.

Brown, MIT, Caltech

  1. Apollo have not got process to process working, only file access, ie the easy stuff.
  2. Brown - 2-3 people, small unimpressive.
  3. Brown doing C compiler to port Unix tools, not real Unix.
  4. MIT only small project on document editor, unimpressive.
  5. Caltech small project to use Apollo as controller for Caltech colour display as don't believe Apollo can do it for couple of years.
  6. no idea on graphics at all.

8. A NOTE ON RASTEROP

In PERQs and APOLLOs the picture is represented as a bitmap, ie a 2-D array of bits. Setting bits to 0/1 sets the picture elements (pixels) to black/white. The crucial question is how can one efficiently manipulate pictures held as bitmaps? One needs to draw, move, erase, transform etc points, vectors and arbitrarily shaped subpictures by changing lots of individual bits rapidly.

The canonical manipulation order is agreed by graphics experts to be Rasterop. Rasterop is a bitwise logical transformation (AND, OR, XOR, NOT etc) performed on two rectangular bitmaps, the resultant bit map being written into one of the two original bitmaps.

Rasterop = destination := Lfunction (source, destination)
                            AND        both 2D bitmaps
                            OR
                            XOR
                            NOT
                            etc

For example, to cause a subpicture to move across the top of the main picture leaving the main picture underneath unchanged requires two steps:

  1. XOR moving picture into main picture (subpicture appears).
  2. XOR moving picture into main picture (same as 1.) (subpicture disappears leaving main picture unchanged - property of XOR).

This is how rapid motion is achieved on a PERQ via two simple machine code instructions.

If only a simple bit block move function is available (APOLLO) then the sequence is:

  1. save copy of main picture area to be changed.
  2. copy in moving subpicture.
  3. reinstate main picture from saved copy.

Thus Rasterop is minimally 50% faster. However, Rasterop is much faster still if, as is the case, the order in which the scan lines needs to be manipulated is crucial (get it wrong and picture flickers - analogous to page thrashing). The PERQ hardware performs this crucial function. The APOLLO bit mover requires software routines.

A rectangular bit mover cannot cope with non rectangular areas. Rasterop can handle these by using a shadow masking technique exploiting ANDs, ORs etc to remove non-rectilinearity rapidly. Bit mover must run software routines to handle bits individually which is chronically slow.

TECHNICAL COMPARISON - CURRENT PRODUCT

PERQ APOLLO

Processor

  • 0.5 VAX, microcoded 4K WCS
  • f1 pt about 5 µsecs (microcode).
  • Paging via microcode
  • Initimate memory/display connection.

Processor

  • 1/4 - 1/3 VAX, microprocessor
  • software fl pt about 150 µsecs.
  • Paging is hardware development.
  • Loose coupling via I/O and bandwidth.

Display

  • Excellent A4 display, 60 Hz - 3RCC video expertise.
  • Microcoded Vectors.
  • Rasterop + 64 × 64 cursor.
  • Bit-pad input with 4-button puck.

Display

  • Poor quality 30 Hz.
  • Slow software vectors.
  • No rasterop or cursor hardware - significant redesign to implement but no plans.
  • No effective graphic input device.

Memory

  • Current disc and memory features have little to choose between them.

Memory

  • Current disc and memory features have little to choose between them.

Networking

  • CMU 3-Mbit ether and Xerox/DEC/Intel
  • 10 MHz ethernet both working.

Networking

  • Private token ring is central part of design.

Collaborators

  • Over 30 people at CMU on three Multi-Million dollar research projects.
  • VLSI design software already on PERQs

Collaborators

  • Small scale (2-3 people) involvement at Brown, Yale etc.

TECHNICAL COMPARISON - FUTURE PRODUCTS

PERQ APOLLO

Processor

  • 16K WCS allowing speed up of critical functions.
  • Hardware fl pt and paging.
  • Replace Z80 by 8086 I/O processor.

Processor

  • Increase performance to about 0.5 VAX possibly by a completely new microprocessor + hardware cache.
  • Hardware fl pt and paging.

Display

  • Colour Display 1024 × 1280 x (4 or 8) bits/pixel. All bits in address space. Maps into 30 bit colour table.
  • Two mouse designs for input.

Display

  • B and W Display - 60 Hz. No plans for rasterop or cursor.
  • Colour Display 800 × 1024 × 4 bits/pixel. Only 1 bit in address space at a time. Maps into 24 colour table. Pan and Zoom Rasterop
  • Touch Pad input - already rejected by 3RCC.

Memory

  • 1 Mbyte and 2 Mbyte boards.
  • No firm plans for larger disc.

Memory

  • 1 Mbyte board.
  • 66 Mbyte disc.

Networking

  • Flexible - adding devices or using Cambridge Ring feasible.

Networking

  • Apollo token ring means devices difficult to interface.

Software

  • CMU SPICE Operating System; GRAPHICS + UNIX from Advanced Computer Techniques.

Software

  • DOMAIN operating system.
  • No full UNIX implementation.
⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site