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.
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:
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.
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.
A quick thumbnail comparison of the two products is as follows:
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.
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.
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.
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.
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.
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.
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.
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.
PERQ | APOLLO |
---|---|
1. Microcoded
|
1. Not microcoded
|
2. Rasterop
|
2. Bit mover
|
3. Ethernet/Camb Ring
|
3. Non standard LAN
|
4. IEEE 488
|
4. MULTI BUS
|
5. CURSOR
|
|
PERQ | APOLLO |
---|---|
1. NetworkIndustry compatible, gateways easy |
1. NetworkHome grown, incompatible |
2. B/W DISPLAYExcellent already |
2. B/W DISPLAYb/w tube in test rig, 2 characters, not on Apollo, VMI tube |
3. PERFORMANCE
|
3. PERFORMANCE
|
4. COLOUR and RASTEROP
|
4. COLOUR AND RASTEROP
|
5. INPUT DEVICES
|
5. INPUT DEVICES
|
6. VLSI, GATE ARRAYS
|
6. VLSI, GATE ARRAYS
|
7. ARCHITECTURE RIGHT
|
7. ARCHITECTURE RIGHT
|
8. PERIPHERALS
|
8. PERIPHERALS
|
9. HARDWARE
|
9. HARDWARE
|
10. PERFORMANCE
|
10. PERFORMANCE
|
PERQ | APOLLO |
---|---|
CMU31 + 10 PERQs
|
Brown, MIT, Caltech
|
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:
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:
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.
PERQ | APOLLO |
---|---|
Processor
|
Processor
|
Display
|
Display
|
Memory
|
Memory
|
Networking
|
Networking
|
Collaborators
|
Collaborators
|
PERQ | APOLLO |
---|---|
Processor
|
Processor
|
Display
|
Display
|
Memory
|
Memory
|
Networking
|
Networking
|
Software
|
Software
|