Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ OverviewProgress May 1981 - May 1982PERQ Locations September 1982Recognition of SUS Request December 19821. Support of Perqs and Suns2. PERQ User Notes3. Kent Software Tools4. Guide PNX 5.05. PERQ Software6. Mixing Modules8. User ForumPerq3A
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

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

Overview
Progress May 1981 - May 1982
PERQ Locations September 1982
Recognition of SUS Request December 1982
1. Support of Perqs and Suns
2. PERQ User Notes
3. Kent Software Tools
4. Guide PNX 5.0
5. PERQ Software
6. Mixing Modules
8. User Forum
Perq3A

Progress Report May 1981 - May 1982

F R A Hopgood

2 June 1982

Single User System Steering Group SUSSG/P3/82

1. INTRODUCTION

As this is the first meeting of the Steering Group, I have taken this opportunity to produce a detailed report of activities over the period since last May. Most of the history prior to that is included in the paper 'A Strategy for Single User Systems and Distributed Interactive Computing in SERC' produced by G Manning, F R A Hopgood and R W Witty.

The period between May 1981 and September 1981 was spent in getting the relevant SERC approvals for the project and negotiating an agreement with ICL. At the same time, ICL was in active negotiation with Three Rivers Computer Corporation (referred to as 3RCC in future).

Much of the information in this paper is of commercial significance to ICL. Members of the Steering Group should not release this information to any third party. SERC does have access to confidential information through its agreement with ICL which could cause ICL a great deal of harm if divulged to competitors, the press or the community in general.

2. SUMMER of 1981

Some of the comments made here are my interpretation of what happened and could, therefore, not be completely accurate.

The arrival of the first PERQs in the UK at the beginning of the year had speeded up negotiations with ICL and also made it feasible to demonstrate what the system was capable of doing. Our strategy, was, therefore, to put a paper proposing the strategy for single user systems to the relevant SERC committees in the spring and summer of 1981 with the aim of getting Council approval at the July 14 Council Meeting. At the same time, negotiations with ICL continued with the aim of ICL agreeing a marketing and manufacturing agreement with 3RCC and, as a result of this agreement, SERC and ICL agreeing a collaboration on software development and a commitment to standardise on PERQ systems.

Early in the year, ICF and DCS agreed to purchase 11 PERQ systems and this order was held up while negotiations proceeded. It was unclear whether the order should be placed with ICL or 3RCC.

2.1 SERC Activities

The Strategy paper was put to the Facility Committee for Computing on June 23 and it was strongly supported. Doubts were expressed that the proposed level of funding (5my per year) might be insufficient to achieve the necessary level of coordination and support across the full range of SERC computing interests. The FCC invited the Office to advise Council to strongly support the proposed policy for procurement of single user systems with a standard software environment. The proposal to develop UNIX as the initial operating system was fully supported. It also agreed that the new Central Computing Committee would be the appropriate body to look after the project on behalf of Council.

My own estimate of the manpower required to run the project was somewhere between 10 and 15my per year. I was persuaded to reduce the bid to 5my per year on the basis that the programme was of general interest to all projects both at the Laboratory and within SERC. Consequently, individual projects would provide manpower to assist the programme. So far, only the Engineering Board has provided manpower to assist the project via a 1my allocation from EBCC.

The Strategy paper was submitted to the Boards in parallel with it going to FCC. Also, the relevant EB Committees all discussed it. There was overall agreement that the policy was sound and the paper went to Council on July 14. Demonstrations of the PERQ were given to FCC, Council and other committees prior to their meetings. The report of the Council meeting was as follows:

Council welcomed the spirit of the proposed programme which it saw as a good example of encouraging UK technological developments through the support of academic research. The experiences of the Interactive Computing Facility had shown that developments of this kind would become important, and cheap computers were expected to play a significant part in the future of scientific research. The proposed activity was consistent with the intentions of the Department of Industry to assist the UK's computer industry.

Some concern was expressed over the resilience of the American parent company. A novel ingredient in the proposed programme was that in parallel with the development of new software systems it would be necessary to sustain the position of novel hardware in the market. A promising development of this kind could easily be overtaken if larger companies decided to enter the market: not only would hardware costs fall dramatically but they would be in a strong position to move quickly on software development. It was very important that ICL should be involved in manufacturing the next generation of hardware, as was proposed. The relative costs of hardware and software development could also be a reason for caution. Full software suites were costly products and there could be a danger that the cost of developing them fall on SERC so that in effect it was paying for the manufacturers to establish their market. The further possibility that SERC's efforts were made nugatory by the intervention of a major manufacturer could not be discounted. Notwithstanding the importance of what was proposed, the procedural and managerial aspects of the proposed programme must be handled with great care: there was a strong case for immediately adopting an available standard and moving an existing operating system to it, but subsequent developments should be considered critically.

The manpower and funds required for the current year could be made available from related heads of expenditure, notably the Interactive Computing Facility and the programmes in Distributed Computing Systems and Software Technology. RAL considered that the manpower reserved for the project would be sufficient to allow the early adoption of the UNIX operating system. The view was expressed that further software developments might require a very substantial effort, and that RAL might draw on the expertise of Government Establishments with relevant experience, notably RSRE.

The Council:

  1. approved the introduction of a scheme for the procurement and support of powerful single user computer systems with a standard software environment throughout the Council's activities;
  2. invited the Central Computing Committee to take responsibility for developing and monitoring this scheme, assisted by a central support unit at RAL for this purpose;
  3. authorised the Office to enter into an agreement with ICL relating to the PERQ and its next development with a view to this being the first approved system.

2.2 Negotiations with ICL

Negotiations with ICL had been long and protracted prior to the arrival of PERQs at the beginning of 1981. We had managed to get three systems from different sources, and these were used primarily as demonstration systems. They were shown to four ICL directors in April 1981 and the pace of negotiations were accelerated.

There was a major change in ICL at the end of April when Robb Wilmot took over as Managing Director. As a consequence, we became involved in discussions with several new people. A presentation on PERQ was given to Robb Wilmot on 28 May. It was about 8.00 am! I discussed SERC's interest in the product and we also discussed local area network strategies.

Negotiations continued between ICL and 3RCC during June and July with Robb Wilmot being personally involved! Ed Fredkin, the head of 3RCC and Jim Gay visited ICL on July 6-8 for discussions. ICL were pushing hard for marketing rights world wide and commitment by 3RCC that they would be the first company to announce a $10K PERQ.

SERC were anxious that ICL announced the agreement with 3RCC prior to the Apollo launch on August 3. A meeting took place between DoI and ICL on July 13 and it was anticipated that the agreement with 3RCC would be signed on July 14. However, negotiations with 3RCC dragged on mainly, in my view, because of the conditions being imposed by 3RCC.

We had purchased an Apollo for evaluation at much the same time as the initial PERQs arrived. Some discussions had taken place between ICL and Apollo in January 1981. However, Apollo were committed to world wide marketing themselves and the discussions came to nothing.

Bill Poduska, head of Apollo, visited the UK at the beginning of August to attend the Apollo UK launch. He tried to have discussions with Robb Wilmot but without success. However, Robb Wilmot was due to visit the USA in August to finalise the contract with 3RCC. He agreed to visit Apollo on the way.

Wilmot was impressed by the Apollo organisation and less happy with the rather disorganised situation at 3RCC. There was still a big gap between the terms 3RCC were insisting on and what ICL were prepared to offer. Wilmot returned to the UK and ICL considered whether to give up on the 3RCC deal and try and make an agreement with Apollo.

During August, I also visited both companies just before Wilmot. I was still convinced that 3RCC had the better product and were more aware of the developments required in this area. Tony Williams one of the RAL systems programmers, also visited both Apollo and 3RCC for extended periods coming to the same conclusion. Also, ICL's involvement with 3RCC enhanced the product much more than an involvement with Apollo. The major reasons for Apollo's interest in a deal with ICL was to get a foothold in the UK market.

A further meeting took place in the UK on August 28 between 3RCC (Ed Fredkin) and ICL. It was followed by a meeting between SERC and ICL. A paper was presented to that meeting by myself and Rob Witty giving a comparison of the 3RCC and Apollo systems. It concluded that the PERQ was significantly superior as a product at that time. The software was behind that of Apollo and 3RCC would need strong backing from Carnegie Mellon University to change this in 3RCC's favour. The long term plans were not very clear in either company. ICL would certainly increase the potential of 3RCC more than they would Apollo. ICL had experience that complements 3RCC whereas an ICL/Apollo deal hardly enhanced the product at all.

As a result of these meetings, ICL concluded an agreement with 3RCC that evening. The basis of the agreement was:

  1. ICL would market PERQ exclusively in Europe, Australia and South Africa. It also had non-exclusive rights in the rest of the world apart from North America and Japan.
  2. ICL would manufacture PERQs in the UK.
  3. ICL and 3RCC would cooperate in the planning and specification of new products.

The Memorandum of Understanding between SERC and ICL was signed on 23 September 1981.

The order for the 11 PERQs for ICF and DCS had been delayed while all this negotiation continued. The systems were finally ordered at the end of August and deliveries started at the end of September.

2.3 Staffing

Up to this point, most of the work had been done by myself, Rob Witty and Tony Williams. Jim Loveluck, a physicist, had moved from another RAL division in the summer and had begun to work on the communications aspects.

3. CARNEGIE MELLON UNIVERSITY

In 1979, Carnegie Mellon University (CMU) put an operations requirement to industry to collaborate in the design of a high quality personal computer for scientific research at a cost of about $10K by 1983. This project called SPICE envisaged CMU investing 100 man years of effort to define and implement a state-of-the-art program environment for a distributed set of personal workstations.

Nobody was able to match the CMU specification but the nearest company with a product was 3RCC with the PERQ. Consequently, CMU ordered around 40 PERQ systems for software development associated with the SPICE project and others.

The Project Leader for the SPICE project is Peter Hibbard. Rick Rashid is one of the main systems developers.

The SPICE operating system is seen as an ongoing research project which will evolve in time. Central to the SPICE developments is an operating system kernel called ACCENT. ON top of ACCENT, CMU are building a basic operating system called SALT for program development.

Negotiations have continued off and on between CMU and 3RCC as to whether SALT should be taken as the 3RCC operating system replacing the current POS operating system which provides a minimum of facilities.

4. UNIX

4.1 Introduction

The PERQ project team for ICL was set up in Bracknell in October under the leadership of John Parker initially and later Roger Ashbrooke. Its brief was to increase the software base on PERQ and ensure that manufacture of PERQs in the UK took place as early as possible. Transfers of staff from project to project seem as difficult to achieve as in SERC and the project has suffered until recently due to lack of staff.

A major requirement was the availability of a FORTRAN compiler on PERQ as early as possible. In SERC's view, this was most likely to be obtained by implementing UNIX in collaboration with ICL. ICL also saw the need for a FORTRAN compiler on top of the basic POS operating system in turn-key situations. As a result, agreement was reached that SERC and ICL would collaborate in mounting UNIX and, concurrently, ICL would place a contract for a stand-alone FORTRAN compiler translating into standard PERQ, Q-CODES. The FORTRAN compiler on POS was also of interest to 3RCC.

In November, Edinburgh Regional Computer Centre were awarded the contract to mount a FORTRAN compiler in competition with a USA software house.

Rob Witty, Len Ford and Tony Williams made an extended visit to CMU in November '81 to assess the applicability of the ACCENT kernel to base a UNIX development upon. It appeared to have all the properties required and, if available, would save a considerable amount of elapsed time before a UNIX implementation could be available.

CMU have a number of organisations as Industrial Affiliates and it was necessary to become a member before we would obtain access to the ACCENT software. The ACCENT software was still under development and Len Ford remained in Pittsburgh for the whole of November '81 getting familiar with ACCENT and helping CMU in the implementation.

4.2 UNIX Collaboration with ICL

A number of possible methods of implementing UNIX were discussed with ICL in October '81. The objective was to provide a full VT version of UNIX on the PERQ as an alternative to POS. Both SERC and ICL's application software team saw the need for a full 32-bit implementation. The three main strategies that emerged were:

  1. Implement the UNIX kernel and utilities (including the shell) using the existing PERQ Q-codes.
  2. Implement the UNIX C program interface (and hence utilities and shell) using the ACCENT kernel.
  3. Implement (via microcode) a target machine designed for the C language, and implement the UNIX kernel and utilities on that.

There were disadvantages with each approach:

  1. The existing Q-codes provided a limited address space per process and would only allow process swapping and not paging. The C to Q-code mapping looked as though it would be inefficient and difficult to implement.
  2. There was some doubt as to when ACCENT would be available in a debugged form. The efficiency of a UNIX implementation on top of UNIX was unclear. The major advantage of the second route was that it would shorten development time.
  3. Although the implementation of a C machine would be the most efficient implementation, it did require familiarity with PERQ microcoding and existing software would not be able to run.

It was finally agreed that the best chance of an early implementation was to do (2) and (3) in parallel. SERC agreed to do the implementation using the ACCENT kernel while ICL would implement on top of a microcoded C machine. Regular meetings would ensure that information concerning problems could be transferred between the two groups.

In the meantime, 3RCC had independently placed a contract with a Toronto based company to implement a 16-bit version of UNIX. This caused several periods of indecision in ICL management which were eventually dispelled when they visited the company and realised that there was no possibility of world wide support for the product from the Toronto company.

4.3 ACCENT UNIX

The function of the ACCENT kernel is to provide an execution environment for multiple processes including:

  1. Inter-process communication via typed (in the Pascal sense) messages.
  2. Virtual memory management (each process has a flat 2**32 16-bit word address space protected from other processes).
  3. Process Management (scheduler and interrupt control).
  4. Process creation and deletion and Unix 'fork'.
  5. Access to devices via inter-process communication.
  6. Support for language and application specific microcode.
  7. Rudimentary support for process monitoring and debugging.

For reasons of efficiency, a large number of basic facilities are supported in microcode.

The SERC approach has been to define a set of processes on top of ACCENT which provide the facilities required by the UNIX operating system. The main processes required were:

  1. File Server: this handles all access to the filestore. The filestore is in POS format.
  2. Registrar: this maintains a list of active processes, taking note of births and deaths of user processes.
  3. Switchboard: this handles the setting up and modification of pipes between processes.
  4. User Back End: maps Unix system calls to Accent. This part has been written in PERQ PASCAL.

The major part of UNIX is written in the C language and there is a 2-pass portable C compiler; consequently, rewriting the portable C compiler to generate the relevant ACCENT code, C language programs can run on the PERQ. As most of UNIX is written in C, this code can be recompiled using the new C compiler.

This is an over simplification of the real situation. The C compiler is not clean and PDP 11 code is generated from both passes of the compiler. Some assumptions are made about the lengths of certain data types which are applicable to a PDP 11. Many UNIX utilities are PDP 11 dependent and require some rewriting.

The common base policy requires all its languages to be interworkable at the procedure call level. Pascal can call Fortran 77 can call C in any order. This has meant considerable work in the F77 and C compilers pass 1 to make them truly 2 pass. A new common pass 2 has been produced. A new Linker has been produced to link C, F77 and Pascal to facilitate mixed language working. This compiler work is now complete except for the porting of the compilers themselves to PERQ/UNIX/ACCENT.

We had anticipated that UNIX would be up and running by Easter. The timescales were extremely tight and left no room for contingencies. In the event, we have not made that target date although a great deal of progress has been made.

A major problem has been the lack of stability in the CMU ACCENT kernel. We are still finding bugs in it and this has slowed progress. In addition, we have come across bugs in UNIX itself which only appear when it is run on a system different from a PDP 11.

  1. ACCENT: New Version delivered 28/5/82 which should cure all known bugs.
  2. File Server: Completed, tested, no known bugs.
  3. ACCENT processes (Switchboard, Registrar etc): Completed, tested, no known bugs.
  4. UNIX Shell: Completed, tested, Obscure bugs present in PDP 11 V7 UNIX.
  5. C Compiler: Completed, tested, no know bugs. First pass needs to be ported from PDP 11 to PERQ. Second pass needs porting from POS to ACCENT.
  6. Libraries: Completed, tested, no known bugs.
  7. F77 Compiler: Completed, tested, no known bugs.
  8. F77 Library : Almost complete.
  9. PERQ PASCAL (ISO PASCAL : Needs porting from POS to ACCENT due July '82 from UMIST)
  10. LINKER :Completed. Needs porting from POS to ACCENT.
  11. Essential UNIX Utilities : Work to be done including porting to ACCENT.
  12. Other UNIX Utilities applicable to PERQ : Work to be done including porting to ACCENT.
  13. Remaining UNIX Utilities not applicable to PERQ: Some alternative utilities have been provided. Work still to be done.

We are, therefore, able to obey UNIX shell commands on the PERQ and this indicates that the major part of the work is complete.

No attempt has been made to do any optimisation even when we can see quite clearly areas where this is applicable. The philosophy has been to get a working system first. Consequently, the performance at the moment is not impressive. A true assessment of its performance will need to wait until the performance improvements are added. Some quite major changes can be made by a few days work.

4.4 Microcoded C UNIX

The ICL developed microcoded C version of UNIX made a number of design decisions early on to limit the work to be done. The major ones were:

  1. Paging was not implemented : it was felt that without hardware assistance for paging there must be serious doubts about the performance on a PERQ. The order code was designed to allow development to a paged system without changing the order code definition.
  2. The implementation of the C machine imposes constraints on the storage available to a UNIX program. Effectively, it consists of the free store available. On a ½ Mbyte PERQ, the maximum program size (text, data and stack) is about 350 Kbytes.

Consequently, there are restrictions on the type of program that can be run in this implementation.

The major work required in the implementation was:

  1. Implementing the C-machine order code in microcode.
  2. Rewriting the machine dependent parts of UNIX.
  3. Resolving the problems in transferring from a PDP 11 architecture to that of the PERQ.

The two implementations have had similar problems in the last two areas.

The ICL implementation is at about the same level of development as that of SERC. Most of the basic system has been tested with no known bugs. The UNIX shell runs and some UNIX utilities still need to be reworded.

4.5 The Future

Negotiations continue between ICL, 3RCC, CMU and SERC. It is clear that only one version of UNIX should be supported long term.

A joint project team between the four parties is to consider the future operating system developments for the PERQ in June and July. It is likely that the CMU SALT operating system or a derivative from it will be the basis for an operating system specifically developed for the PERQ. The aim will be to allow UNIX to coexist with hat operating system.

Both ICL and 3RCC are likely to standardise on the SERC UNIX implementation based on ACCENT long term. ICL are currently looking at the work needed to bring this out as a fully supported ICL product. It is possible that if this turns out to be long, an interim release of either the ICL or Toronto UNIX might be made.

5. COMMUNICATIONS

5.1 Cambridge Ring

The SERC Common Base Policy requires the PERQ to interface to local area networks based on Cambridge Rings.

In order to do this quickly, RAL have developed an interface which allows the ring to be accessed via the Z80 controlled GPIB. The ring is regarded as just another device on the GPIB. The interface unit is designed to match the 50-way encoded interface originally developed by Logica for Polynet. This presents the station as a number of status and data registers. The RAL interface translates this node image as a single primary GPIB address, with each register having a separate secondary address. The design has been optimised to allow bulk transfers in one direction to take place with the minimum number of GPIB cycles, so that the ring can potentially be driven at full speed.

At the time of writing, the prototype interface is working and six more are being built. It is intended to go out to tender for a substantial number in the near future.

As currently implemented, the Z80 board has 1K RAM and 8K ROM. Due to inefficiencies in the software, the throughput to the GPIB via the Z80 is very low. Using the RAL ring interface, it has only been possible to achieve 1.1 Kbytes/sec throughout. The Z80 is soon to be recorded by 3RCC and this will allow DMA transfers between the GPIB and the Z80 buffer. This is expected to bring the throughput up to 20 Kbytes/sec.

A new I/O board is due near the end of 1982 which has 16K RAM and 4K ROM with 8K of RAM used for buffers. It is expected that a throughput of 250 Kbytes/sec will then be possible.

5.2 Ethernet

The PERQ has a fast I/O bus providing 128 addresses for communication with high speed devices. The number of devices that may be attached is limited by space in the backplane. Currently there is room for two more. Transfers take place into PERQ memory at 170 nanosecs per 16-bit word. The PERQ uses this interface for the Ethernet controller (it is likely that we shall build a Cambridge Ring interface in due course).

We currently have a single Ethernet board which is not a great deal of use. Additional Ethernet connections are on order as well as interfaces to a PDP 11 and LSI 11 from Interlan. The PERQ Ethernet is a standard DEC/Intel/Xerox ether and we should be able to make comparisons between the two technologies.

5.3 X25

To allow connection of the PERQ to other buses there is an option known as the LINK board. As currently configured and microcoded, this can be used to link two PERQs back to back, or can be attached to a standard DEC DR11C or DRV11. The latter allows the York X25 implementation for UNIX in a LSI 11 front end to be used on a PERQ.

It is an expensive solution but does allow a direct connection of a PERQ to the X25 network in a reasonably short timescale.

5.4 Software

RAL are currently implementing TSBSP and BBP to run on PDP 11 UNIX and it will be transferable to the PERQ. It is hoped that this will be running by the summer of 1982. This software presents the same transport service interface to user programs as the York X25 software so it should be possible to run the higher level packages of the York software unmodified.

A preliminary basic stock driver for the PERQ GPIB/Cambridge Ring interface has been written and tested. This driver runs under the 3RCC POS operating system and will require modification to run under UNIX.

As an interim measure, while the TSBSP software is under development, the Kent University Cambridge Ring handler is being implemented on the PERQ. The byte stream (BSP), initial connection (ICP) and file - transfer (FIP) protocol of this software have been implemented under POS, using the GPIB ring driver.

6. PERQ HARDWARE

6.1 Introduction

The agreement with 3RCC gave ICL the ability to manufacture PERQs in the UK? It was anticipated that future developments would be done by 3RCC with ICL acting in conjunction with 3RCC to define the necessary enhancements.

6.2 Manufacturing in the UK

The manufacturing of PERQs in the UK was done in three parts:

  1. Assemble 3RCC made PERQs.
  2. Fabricate all but boards in UK?
  3. Manufacture complete PERQ in UK.

ICL has broadly kept to all their timescales in this area. The first UK produced PERQ was delivered to SERC on 16 February and the first assembled PERQ was available in December. ICL can be congratulated at the speed with which they tooled up to manufacture in the UK. It was much earlier than we anticipated.

6.3 Reliability

SERC had a major problem with nearly all the system delivered. The power supply for 230 volt systems was inadequate and kept blowing up. This problem was finally cured near the end of December.

Most PERQ systems have a high incidence of breaking early on in their life. Once over this period, reliability improves enormously. ICL have been working hard with 3RCC to improve both the design and assembly of systems to improve reliability.

The design aim for the PERQ was to have an average one fault per system per year.

We are no where near achieving that figure yet. Between September and November 1981 we were averaging about 200 hours MTBF. This has now risen to well over 500 hours but more work is needed in this area.

We have some mature systems which have experienced MTBF well over 1000 hours.

6.4 Enhancements

The major hardware additions since the early systems were delivered are:

  1. Memory: ICL can now deliver both ½ Mbyte and 1 Mbyte systems. In fact they have stopped selling quarter Mbyte systems as they are more expensive than the 1 Mbyte systems.
  2. Ethernet: The PERQ ethernet connection is now available and is working at a number of organisations including IBM, and GMD in Germany.

Enhancements expected this year are:

  1. 16K Writable Control Store: prototype available at CMU. No firm date for the product release.
  2. Reworded I/O Board: this is explained in the Communications section and should be available in December.
  3. Versatek Printer-Plotter: interface available in November.

3RCC have a number of other developments in the pipeline. Firm dates for these are currently unavailable mainly due to internal changes within 3RCC.

Jim Marshall, ex DEC, has joined the company recently and is in charge of all short term developments. A new office is being opened in Boston. It is anticipated that firm dates for other enhancements will be available by the summer.

7. ICL SUPPORT FOR PERQ

The support of the PERQ Project in Bracknell has been less successful than ICL hoped mainly due to the difficulty of getting people to work in that area.

Consequently a decision was made at the end of March to move all the main support for PERQ to Dalkeith. The new Project leader is Ian Richie. Although, this is likely to cause some disruption, RAL sees a positive improvement coming from the move. The people at Dalkeith have good expertise in systems software and hardware. There is also less of a problem in making people available. We have had one meeting in Dalkeith and it is planned that some Dalkeith people will spend time at RAL in the near future. The ICL UNIX version will be completed at Bracknell.

One positive advantage already seen at Dalkeith is expertise in microcoding. The 3RCC floating point operations are in the process of being speeded up considerably. We will need to install these in our UNIX implementation.

The other major group concerned with PERQ in ICL is the group at Reading doing applications software. They have concentrated initially on providing a low level graphics package and a business graphics system. They are developing or have negotiated agreements for the development of a number of CAD packages. The areas covered by the end of the year will include Draughting and Graphical Numerical Control(GNC).

8. PERQ/DAP

ICL are looking at the possibility of putting a low cost 32 × 32 DAP on the PERQ. Each PE(Processing Element) will have 16 kbits of memory making 2 Mbytes in total.

The aim will be to attach the DAP to the PERQ initially via the I/O option board. This would allow transmission of data to the DAP at 10 Mbits/sec. A later enhancement will provide a fast I/O channel.

The complete DAP will be housed in a cabinet about the size of a PERQ. It consists of about 15 boards.

Connected to the DAP memory via a fast I/O channel (650 Mbits/secs) will be a video controller that will allow either video input or output. Thus a colour display could be connected directly to the DAP.

It is hoped that a prototype can be available by December 1982. Discussions are continuing with a number of university groups and SERC.

9. BTG

Discussions have taken place with British Technology Group concerning software developed jointly between SERC and ICL. The first item of interest is UNIX and we have been discussing a non-exclusive licence to ICL for use of our software. ICL would prefer a lump sum payment rather than a royalty per system sold.

Another meeting between SERC and BTG has been arranged to discuss appropriate royalty levels bearing in mind the effort being put in by ICL to develop the product and support it afterwards.

10. PERQ PRICES

ICL have announced new prices for PERQ as from 1st April 1982 which are a reduction of about 20% over the original prices. A ½ Mbyte system costs £19, 950 which is considerably less than the original price for a 256 kbyte system.

Other prices of interest are:

    1 Mbyte system       £22,150
    Ethernet connection  £ 2,250
    512 kbyte upgrade    £ 1,900
    1 Mbyte upgrade      £ 4,400

As ICL do not plan to sell 256 kbyte systems in the future, we are considering upgrading existing systems to 1 Mbyte.

SERC receives substantial discounts on the above prices as part of the agreement with ICL.

11. STAFFING

As can be seen in SUSSG/PS/82, a considerable amount of manpower has been used on the PERQ software developments in the period January to April 1982. As no manpower had been allocated for the project in 1981/2, we borrowed from the three areas suggested by Council - ICF, DCS and Software Technology.

In the current year, much of that effort will revert back to the existing projects. In particular, the Software Technology specially promoted programme formally started in April and Rob Witty will need to take charge of that work together with three other people. Rob is currently fully committed to helping the Alvey Committee decide what the UK response to the Japanese Fifth Generation initiative will be and we are already slipping on commitments in the Software Technology area. Consequently, Rob Witty will not be Project Leader of the PERQ project in the future. However, I have no other people at that level who can be spared to run the project. We are currently seeking a replacement from other Divisions on-site.

We have sufficient people at lower levels to keep the momentum of the project going as long as manpower allocations are provided by SERC. It will be necessary to get funding for any large scale collaborations with ICL via the collaborative grant route.

Our UNIX expertise largely resides in Colin Prosser. We have recently advertised for additional staff with UNIX experience and hope to recruit one or two people as a result of that.

12. SUMMARY

A great deal of work has been done in the short period between October and May, particularly in the area of systems software. We are now coming to a phase where the emphasis is likely to turn more to applications software development, user support and hardware developments. Of course, there is still a considerable amount of work to be done on the systems side.

⇑ 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