Due to the late arrival of UNIX, ICL had been selling systems with POS Consequently, a large volume of software had built up on POS. as the operating system. By early in 1983, the following major packages were available from ICL:
Over 50 sites in the UK were actively using the software and these would be a problem during 1983 in getting the software available under PNX up to the same standard so that support for POS could be run down.
The major language available under POS was PASCAL. A PERQ running POS was effectively a PASCAL engine and good performance could be obtained from it. Consequently, users had moved a considerable amount of code to PASCAL. Front-end systems for FORTRAN packages had been written in PASCAL. The need for PASCAL was, therefore, more crucial than one would have expected if systems had not been shipped with POS initially.
ICL's major aim was to produce a PASCAL in line with the ICL range compatible compiler. Although capable of running standard ISO PASCAL, it had a number of facilities that had been used by ICL's office automation software on other systems. As ICL wished to port these to the PERQ as part of the DoI Office Pilot, there was a strong desire that the PASCAL compiler be compatible with the other ICL products.
The approach adopted was for ICL's 2900 compiler experts to do the work at Bracknell cross-compiling from the 2900 system. The original intention was to have a general release around June 1983. Problems arose in this exercise. Effectively, the port required extensions to both the C compiler and assembler. As Dalkeith were concerned with getting PNX releases out of the door progress on PASCAL was limited by the availability of crucial manpower.
Progress was not helped during the year when ICL senior management directed effort on to another project for a while during the implementation. There was also rivalry between Bracknell and Dalkeith which did not make for a smooth operation.
A pre-release for academic sites finally arrived in July 1983 and SERC contracted UMIST to do a preliminary evaluation of the compiler. The major conclusions were:
Execution speeds were difficult to compare with POS due to differences in the standard integer length. However, the view was that I/O performance was significantly better (nearly a factor of 2) over the POS system.
On compute bound jobs, the speed varied between 10 and 25% of a VAX 11/750. It was significantly worse than POS PASCAL due to the tuning of the POS machine to PASCAL.
During the year, ICL worked on the compiler in order to improve its performance By December 1983, compile time speed was around 135 - 200 lines a minute but with plans to increase this to 1000 lines a minute. Work on the C back- end was put in progress to remove the identifier length constraints. The large object code files were not cured in PNX 2.0 and required a further release of the operating system.
By the end of 1983, the PERQ PNX system had a usable PASCAL but it would require considerable work before good performance could be obtained.
The original plan was for GKS to be available by October 1983. The ISO standard itself was still receiving minor modifications and the FORTRAN binding did not stabilise until mid 1985. Consequently, this date was always likely to be altered by events external to the project.
In the event there was slippage partly caused by ICL withdrawing effort on the project due to lack of funds and partly due to the SERC staff spending time working on the standard itself and the production of the formal ISO document.
By March 1983, there was clearly going to be some slippage, and GKS was rescheduled for field release in February 1984.
A major advantage of running UNIX on a single user workstation is that it allows the operator to perform more than one task at a time. He can be executing one program while editing a second, transferring files with a third while allowing a large compilation to proceed in the background. To control such an environment requires the operator to be aware of the current state of each process and to be able to rapidly switch context so that he can control whichever task requires attention. That is the basic function of the window manager.
The ACCENT UNIX project had generated a sophisticated window manager capable near the end of the project of controlling both POS and Accent-UNIX environments at the same time. Now, work was needed to produce an environment of similar quality under PNX.
Understanding of window managers was in its infancy at that time and a collaborative proposal had been put into SERC by RAL and ICL to do the research and development necessary to produce a high quality product. Due to changes in SERC procedures, the advent of Alvey and the slowness of the MMI Directorate getting started, that proposal, although judged of alpha quality, is still unfunded in November 1985!
Meanwhile, an interim window manager was developed by ICL with SERC input near the end of 1982 and was available with the early release of PNX. It had some idiosyncratic behaviour including all typed input being directed to a master window in terms of echoing and being moved to the correct window on completion of a line of text. This was far from satisfactory from the operators point of view but it did mean a multi- process environment with reasonable access was available early on.
Progress in defining a window manager was complicated by a desire from ICL that they and Three Rivers produced a joint product that could be moved to whichever operating system they decided to support long term. Early in 1983, Gordon Dougan of ICL had discussions with Brad Myers of Three Rivers to define a joint approach. Brad Myers had already done work on Window Management systems at Xerox PARC and CMU. He wanted to produce a sophisticated state-of-the-art window manager while Gordon Dougan and ICL wanted to provide the kernel of a window management system on top of which users could build facilities of their own. The Brad Myers work eventually produced an excellent window manager SAPPHIRE with many unique features running on top of ACCENT.
ICL continued to make changes to their window manager enhancing it during the year. Its major problem was not that it did not give users a basic facility but that window management functions were having to be built into software that was being developed using the window manager.
As part of the collaboration with ICL, it was decided that RAL would implement an Editor on the PERQ (later called Spy) targeted at the environment available on a high quality single user system. A survey of available screen editors had been undertaken and no suitable editor had been found. The major goal was to make as much as possible of any operation visible to the user. Editing commands should be almost exclusively invoked using the mouse with a mixture of menu styles appropriate to particular operations. Uniformity of operation was important for ease of learning. It was targeted at the scientific professional and should allow such a person to work efficiently. The editor needed to support the ability to work on multiple files performing move and copy operations on arbitrary blocks of text simply by moving the mouse and making the relevant command selections. The aim was to provide high quality feedback to the user. The power of the PERQ graphics allowed the possibility for the first time of fast changes in space allocation, continuous rate-controlled scrolling, dynamic updating etc.
Many of these features could have made use of a sophisticated window manager (for example, multiple file editing could have been done by having one window per file). However, as the functionality of the current window manager was limited, the decision was made to decouple the two and have Spy implement the window management functions it required within its own environment.
The functionality and user interface of Spy was defined by February 1983 with the aim of finalising it after comment by April 1983. It was hoped to produce a Field Test release by June 1983 and produce a general release in the Autumn.
These timescales were kept to with only minor slippage. By November 1983, Spy had been given to ICL to release with PNX 2.0. A pre-release had been made during the summer to SERC users and favourable comments received. Extensions to the system continued in 1984. The SPY editor was a major software development produced to tight timescales and greatly enhanced the ability of users to develop programs on the PERQ. There are few editors on the market today that compare with Spy. The high speed graphics of the PERQ make it difficult for competitors to achieve Spy functionality on their systems.
There was a great deal of interest in the PERQ project from the computer science community in general and the AI community in particular. As a result, attempts were made to mount the relevant AI software on the PERQ. A contract was placed with Edinburgh University to mount LISP on the PERQ.
CPROLOG (an interpreter) had been mounted on the PERQ by Edinburgh and a joint contract between ICL and SERC funded the implementation of a high performance PROLOG system for the PERQ at Edinburgh.
Discussions had started with Sussex University near the end of 1982 and this resulted in a contract to mount POPLOG on the PERQ in 1983.
All three projects were held up by the poor performance and functionality of the virtual memory system available under the early releases of PNX. As a result, progress was slower than anticipated but compilers were available during 1983. The major conclusions were:
In general, although performance was not ideal, useful work could be done on the PERQ as easily as the other major languages. Some grant holders added expert system shells on top of the basic languages. A good implementation of OPS5 was available early on. However, neither the PROLOG nor LISP implementations were comprehensive and significant work was still required to make the PERQ an effective AI machine.
The PERQ provides an excellent interface for previewing textual output on the screen. With the needs of the scientific community in mind, RAL were mainly responsible for getting the text processing facilities under UNIX up and running early on. The major utility, troff, was ported by RAL and available in January 1983 and associated utilities such as pic followed.
A major requirement was a server facility to provide high quality printed documents including diagrams and pictures. The first meeting on the topic took place between Newcastle, Kent, Logica and RAL in 1981. The Single User System Steering Group believed this was an urgent priority and papers went to the Group in 1982 and early in 1983 proposing a policy.
Output to a printing device from a variety of sources need to be merged at some level where the protocol or print file format is capable of handling mixed text and graphics using a variety of fonts. Once this has been established, a device is required to translate that format into an image on paper. The major requirements of such a server are, therefore, as follows:
Rather than attempt to define new facilities, the aim was to use existing software where possible. A variety of formatters existed under UNIX but all tended to produce low level device dependent output. The only print file format generally available was the Xerox Press format, which was proprietary. Fonts were available from a number of sources but had different methods of specification and were often available only on certain devices or with certain packages. Neither communications or spooling software were available to handle the output.
A short-term strategy was defined in March 1983 which aimed at a text-only service initially. This would use T.I.troff (typesetter independent troff) as its print file format and provide drivers to a typewriter quality output device. Fonts would be obtained from a variety of sources which would interface to this software. Communications and spooling software available with UNIX would be adapted for this service.
A second phase was to enhance the basic service by allowing graphics to be intermixed with text.
A third phase was to incorporate GKS graphical output using the GKS metafile as the print file format input.
Output devices to be considered were letter-quality printers, Canon laser printers and Versateks.
The SUSSG agreed that a short-term solution should be implemented as soon as possible, but the longer term strategy was not PERQ-specific and that it should be raised at the Central Computing Committee as a SERC-wide problem. The lack of manpower available to the project made it difficult to see how the more global problems could be solved without additional effort and support from CCC.
The matter was raised at CCC but it was clear that the Committee neither understood the problem nor was sympathetic to increasing the manpower available. Consequently, activities continued at a low level. SUSSG did agree that the crux of the problem was getting the print file format correct and RAL, in conjunction with Prof Newman, agreed to come forward with a proposal.
During 1983, the Toshiba TB 2100 Model G was chosen as the basic letter-quality printer. This gave a resolution of 180 dots per inch, reasonable speed, and a range of fonts. User-defined fonts were downline loadable into the device. This was available early in 1984 providing the phase one text only service.
Developments were done to provide mixed text and graphics using the FR80 microfile plotter as the output device. Previewing of FR80 output was made available on the PERQ. This software was later used to produce a number of books both internally and for university researchers.
In July 1983, discussions were held between ICL, RAL and John Warnock of a small USA company, Adobe. These were concerned with Adobe's plans to define a print file format called POSTSCRIPT which would be freely available on a variety of devices with high quality output.
This was clearly the most promising approach and contacts were maintained with Adobe. By 1984, Adobe had published POSTSCRIPT and had it available in ROMs on the new low cost CANON laser printers. Eventually, this was the format agreed as a Common Base print file format for all Alvey activities both on Single User Systems and Multi User Systems.
SUSSG and the group at RAL identified the problems in this area early on; they did provide a consistent plan forward; they were able to provide some facilities early on and they homed in on the de facto standard earlier than the rest of the SERC community.
The year 1983 started with almost no software on the PERQ and concluded with a reasonable set of basic software albeit deficient in some areas and with poor performance if the user was expecting performance comparable to a stand-alone VAX. or PRIME system. It was in a state where it could be used for real development work.
Unfortunately, people who had put up POS early on, did find that they were going back to a more primitive system in some respects. Thus the added functionality of UNIX had to be assessed against a lower performance in FORTRAN and PASCAL compilation and execution.
Many of the criticisms levelled against the PERQ Project as a whole are due to this transition from POS to PNX and the late start to the project itself. If 1983 had been the year when PERQs first arrived, the community would have accepted the rate of software development in 1983 as being at least respectable. However, due to earlier delays, the community were less tolerant and there was a great deal of unwarranted criticism as to the rate of development in 1983 itself, given the manpower available.
