The major problem initially was getting there! The plane was due to leave at 12.30 and I got to Heathrow at about 11.00 to be told that the plane was leaving on time to Boston. At about 11.45, the plane was delayed to 15.45 and I attempted to get on a different flight. However, as I had an Apex ticket they were only allowing transfers into equivalent classes and all the Tourist sections on the planes going out were full. So much for the Lab's policy of sending everybody Apex.
We boarded the plane about 15.10 and that was just the time that the Canadian air traffic controllers came out in sympathy with the USA strikers. They decided that we should stay in the plane while they tried to negotiate a new route to USA not involving the Canadian air space. This apparently needs discussion at Government level. To cut a long story short we eventually left at 24.00 after having seen the film and had our regulation two meals before we got off the ground.
On the approach to Boston, it was found that the plane had a fault on it and the only spare was in New York. The plane would not be able to get off again if it landed so we diverted to New York and had the plane repaired - now 7.00 am UK time. British Airways now decided that the plane should fly direct to Philadelphia (its second stop) leaving the Boston passengers in New York to find their own way to Boston. This was received by so much animosity (there were only 40 going to Philadelphia) that the pilot rang British Airways and eventually decided to go to Boston. Eventually arrived in Boston at 10.00 am UK time (5.00 am US) and got to the Hotel at 6.00 am US time - I had a meeting at 8.00 am! My trip to Apollo was not as successful as it might have been.
The only consolation was that it was the only plane that got across the Atlantic in the afternoon. Even so, 19 hours on a plane is no joke especially as they had run out of almost everything several hours before the end of the flight.
I had breakfast with Bill Poduska and he took me out to the new Apollo office block (19 Alpha Rd, Chelmsford, Mass 01824).
We spent most of the morning discussing Apollo's future products - enhancements and trends. Minor enhancements to be announced soon are a streaming tape drive capable of running at 25 ips stop start and 100 ips continuous. It uses standard magnetic tapes and is a box similar to the Apollo processor with room at the base for a tape rack.
The future products seem to be in the two directions of keeping price same and improving performance and lowering price on a current model.
The performance enhancements include:
They are thinking of adding pan and zoom to both the B & W and colour displays. Zoom will be 1 - 16 times. May add raster ops.
Currently looking at new Hitachi monitor shown at this year's SIGGRAPH.
To get to a low cost version, they are aiming for a complete redesign taking account of products that have come on the market in the interim period. Aim will be for a half price system by 1Q83. This will have less clearly differentiable boards for each function. Thus, a discless version will be based on the current model.
I was impressed by the quality of the Apollo boards - some fine line etching. One board is currently 4 plane and they will move that to a 2 plane board with perhaps earth, power inside layers.
Order book seems strong - they have delivered 40-50 systems and now have a 90-day delivery from order - will soon be shipping 10 systems a week. Systems have been shipped to Harvard, Brown, MIT, Yale, Univ Pennsylvania, Cal Tech, Utah, Bell Labs, CDC, Amdahl + a number of commercial companies.
Apollo are keen that we get at least 3 nodes so that we can do a proper evaluation - Gerry Stanley agreed that if we ordered a system in the Autumn they would loan us a third for 9 months so that we could do a proper evaluation of the total system. I was shown 9 nodes working on the ring and it was impossible to tell whether files were coming from the node you were attached to or a remote node.
PASCAL will be available in September.
After lunch, I visited the manufacturing area. They seem to get displays already housed from outside. The cover on the keyboard seemed to be fitted locally. Population of boards is done under contract. The chassis is made up of quite small pieces so there is about 6 hours of work putting the chassis together and another 8 hours testing systems after putting boards in. Currently running at 6 per week the manufacturing side said.
I saw at least 15 displays in stock, 20 systems were under test and it was clear that Apollo themselves were not short of systems. They had at least 11 for software development. They have one for every two people at the moment but will aim for one each.
The afternoon was spent discussing points missed in the morning:
The purpose of this visit was partly to give the ANSI chairman, Peter Bono, a copy of the GKS issues for the next review round and also to get a view of where the ANSI contingent anticipate to be major areas still to be resolved in GKS.
There appears to be good agreement between UK and USA that input, segment storage are still major issues. They seem to be unhappy about pixel arrays and would like to see them removed. Their view is rotation etc is not very sensible and if you insist that all normal primitives have to be rotatable then all you can do is implement pixel arrays with the generalised draw primitive.
The major problem is still whether ANSI will adopt GKS as an ANSI standard even if they vote for it as an ISO standard. They seem to have the view that there only can be a single language binding for a specific language and you have to program at the user level in that binding. I pointed out that the UK felt it was perfectly acceptable to define a shell around GKS of, say, FORTRAN routines which give you a different user view of the standard. They feel that some compromise in this direction may be what is needed to placate the small core people. I felt that the UK always believed this was reasonable. I agreed to contact Peter Bono again before I left.
Also at Intermetrics I saw a very powerful cockpit simulation system that Jim Michener was working on. It used an Aydin display that had been microcoded and hardware added to do fast rotation and perspective.
I picked up a copy of the ANSI issues for the Cosener's meeting on GKS.
Most of the morning was spent in discussions with Jim Gay and Miles Barel. The afternoon consisted of a tour of the facility plus discussion with Brian Rosen. My general impression was that they are much less organised than Apollo but have more production and test equipment for expansion. Their future plans seem much less firm.
They have now delivered 100 systems and are currently producing about 6 systems a week. They hope to be up to 50 per month by the end of the year according to Jim Gay. Nine of our 11 systems were in the dispatch area awaiting an export licence and the other two were in final test. ICL have ordered three systems for demonstration purposes and it is clear that they intend taking 3 of our slots for their own. One system in the dispatch area had got SERC crossed out and replaced by ICL. Jim Gay had said Charles Hughes had done it!
There is obviously no problem in getting our systems to us. Main change is the LED display saying where it has got through the start-up cycle is now underneath the keyboard.
By April they hope to be up to 70 to 80 a month.
ICL want their systems for taking to shows in Europe. There is a show in Paris and the reason they have been trying to get the source of the Editor is to change the EDIT commands to French.
3RCC have delivered, systems to IBM which they think are installed in Yorktown and Cambridge.
Major immediate enhancement is a 3-button pad in place of the pen that you can get for the Bit Pad - very much easier to use. I have asked Jim Gay to add these to our order for all machines. Cost is about £100 each. I hope we can get at least one shipped with the 11 systems - but it looks doubtful. Could buy direct from Summagraphics.
They still use the VMI monitor. At SIGGRAPH there were 3 on display and 3RCC's was easily the best. VMI have since visited Three Rivers to see how they improve the about quality - Rosen said it was just taking care with the video. Rosen mentioned that he thought Ball Bros were going to produce one. He had looked for a Japanese system at NCC without success. Xerox's STAR tube is made by Xerox themselves 1204 × 808 38 Hz interlaced.
At one stage they were rejecting 1 in 3 of the VMI tubes but that is no longer the case.
They have a different approach from Apollo in that they populate the boards themselves and flow solder them - Apollo do it under contract. The chassis comes already as a single piece not bolted together as at Apollo. Time to put together from start of printed circuit board being populated to system going out is 6 weeks. They were proud of a heat room they have for testing systems - Apollo does no heat testing. They admitted that automatic placement would not be easy with the offset chips on the memory board.
They have a Redac design system and a VAX 11/780 for business/stock control.
The number of systems in final test was about 10 - probably less than Apollo. They are very cramped for space. Jim Gay said that they had to get a new building within the next two months. They have one likely site quite close to the development facility where Brian Rosen now works.
They have set up branch offices in LA and Hertford Connecticut - possibly going to have offices at Chicago, Atlanta and Dallas.
General impression was that these were very vague and probably depended very much on CMU. My overall feeling was that they would carry on developing their own operating system a bit further but anticipated that CMU would eventually produce an operating system that they could switch to.
The CMU Navy Contract requires them to have an operating system under which they can develop SPICE. 3RCC and CMU seem to have agreed a joint effort to produce this with a specification for a multi-processing operating system that suited them both. Consequently 3RCC have decided to bring their own operating system work to an orderly conclusion. However, Jim Gay has failed to get CMU to define a specification of the operating system and 3RCC have no commitment as yet to release it to customers. They seem to have little real control over what CMU do. Main people involved in the project are George Robin, Sam Harbinson and Peter Hibbard.
The original timescales were to have it running by September but now not likely to be ready until November.
Three Rivers are keen that UNIX should be available on the PERQ but they do not want to support it - they would like that done by a reputable company. They have approached Ron Baecker's company - Human Resources Corporation who have produced a proposal. Apparently it will need front end funding as Baecker does not have the resources to spare and the hope would be to start within a month and it would take 6 months assuming agreement was reached. Jim Gay wanted to be sure that whoever implemented UNIX for the PERQ had the right mixture of UNIX knowledge and Graphics.
Three Rivers were aware of the need for FORTRAN and felt it would be possible to port the UNIX FORTRAN to run on the CMU operating system. Have discussed an agreement with Advanced Computer Techniques. Some decision concerning the state of FORTRAN, UNIX and the CMU Op Sys would be made in September. There would be a Board meeting on 25 Aug when the Baecker proposal would be discussed. My own view is that Three Rivers will think it is too expensive and will wait. As Jim Gay said to me - We can wait longer than your people. We managed to get a copy of the Baecker proposal and it is 10 months in duration.
Discussions with ICL continue. One snag was whether they should sign an interim agreement or go for a much wider one initially. They have now decided to go for the interim agreement. Wilmot would be in the USA on 25 August and they hoped to get it settled then. Jim Gay seemed to think it was ICL bureaucracy that was the problem. 3RCC had made some amendments to the original ICL proposal which they had both agreed. ICL were insisting that a revised agreement needed to be produced before it was signed, whereas 3RCC were happy to sign the original + amendments. It was also slowed down by ICL's insistence that they brought the next copy over by hand each time and then insisting on waiting until somebody was coming!
People have been over from ICL mainly from Letchworth Development Centre as far as 3RCC could see.
The longer term ones were extremely vague. On the short timescales they have the following enhancements:
I spent most of the time with Sam Harbison of the SPICE project. Project was started 2 years ago and currently uses a DEC10KL, 8 VAX 11/780s, 20 Altos + PERQs. The VAXs run Berkeley UNIX. They are aiming for a system that would be commercially viable in 1985. Initially the intention with the original SPICE specification was to work with a manufacturer in defining the project's hardware. When that fell through, PERQ had just appeared and so they decided to use it ordering first 5 and then another 28 systems. Currently CMU have 31 PERQs plus 6 more soon to be delivered. They have 5 systems on their local 3 Mbit ETHER. Only other modification that they are doing is to put a microsec clock on it so that they can do performance measurement.
They have 3 main milestones of which the first is SPICE81 which is an initial environment which they can use to develop SPICE proper. This is called SALT, has a kernel ACCENT and is the Operating System that 3RCC will take over.
Funding is complicated as Robotics, Distributed Sensor Network and GANDALF (Program Environments) all have funded PERQs. Estimate is about $1.5M per year. They have 8 faculties working on the project under Peter Hibbard. We have a complete set of papers that they gave to an industrial presentation. It was suggested that we should get to Peter Hibbard and try and get affiliation to the industrial presentations.
LISP is currently being emulated on DEC20 using BLISS. Should move both the microcode emulator and LISP to PERQ in due course.
CMU confirmed that they would give the operating system to 3RCC. A maintenance agreement is being negotiated between 3RCC and the Navy to support it. ZOG will run on top of the operating system. They hope to write a C compiler eventually and put the UNIX utilities on top.
3RCC should release it by end of year. CMU will have it working in September. It is clear from further discussion that quite a few pieces are still undefined.
The operating system is mainly designed for the 16K WCS system. Microcode space will be tight on 4K version. They are talking about paging in the less used parts. CMU are really aiming for it to run on PERQ Mk 2, 1-5 MIPS, 1 Mbyte, 32 bit addressing, 100 Mbyte disc.
Only language available initially will be PASCAL but ADA will also be available. It now runs on the PERQ and they will give it to 3RCC.
Operating system is a message passing system between processes which can reside on a number of systems. Message is sent to a PORT which can queue messages to a user specified level.
Feasible to have multiple PORTS between two processes. They have speeded up basic process swap time to about 60 microsecs.
Virtual Memory is being implemented - with program all in store, no paging, address calculation reduces speed of a program from 20 secs to 34 secs.
Address space is split between operating system and user. Operating system address space is shared across all processes. Sending large amounts of data from one process to another is done by just changing page table entries. If process that receives the data, changes it at this stage, copy will be made.
The disc is mapped into the virtual address space completely.
They have a low-level priority driven scheduler working on a round-robin basis which will eventually be placed in the microcode. On top will be a HLS that the user can modify.
Display is handled by a process called CANVAS. All output is defined as messages to CANVAS.
An Environment is defined which is another process that contains data, defaults etc.
We had a look around their large amount of equipment - PERQs and ALTOs everywhere. All of the PERQs had the puck in place of the pen.
After lunch we had some discussions with Raj Reddy on the Robotics projects which include the Distributed Sensor Net. This is a set of microphones set above a railway track with trains on it. Project is to locate train. They will use PERQs for most of their work.
Most interesting to laboratory were two demonstrations of programs running on the PERQ which used the dial circuit design. One was a PCB design program while the other scanned VLSI masks for errors in lines.
We had some discussion of UNIX. View was that WHITESMITH UNIX was much preferable to Western Electric as they charged no more for commercial users.
They have a linotype photo typesetter which is controlled by a PERQ. Tommy Thomas would be keen to develop it for the UK (Murgenthal is US company marketed by Linotype Paul UK).
Cliff Pavelin and I were given this Overview before we started our site visits by Brian Holmes in White Plains. There was little of interest other than we got a general overview of the IBM organisation - 7,000 products, $26 billion, subdivided into US, Europe and Middle East, Rest. Large computer systems still accounted for 82% of the profits. Major breakdown is:
This has been the major breakdown for the last 5-7 years.
In the European area, Germany dominated ($4.7B) followed by France ($2B) and UK ($1B).
IBM have one or two companies that they own - Science Research Associates Inc (publishing house) and IBM Instruments Inc (chemical, medical). They also have money in Discovision Associates (home videodiscs) and Satellite Business Systems (satellite comms).
Outside the group structure is the Research Division - Yorktown et al which are non-profit making organisations.
After the briefing, we had lunch with Len Branscombe who is IBM's Chief Scientist and reports directly into the president's Office. We talked around array processors, personal computer systems (he didn't like the PERQ!) etc.
Poughkeepsie was in the throes of a complete reorganisation under two Directors, one responsible for high powered scientific systems and the other for business systems in general. The two people are Bob Carberry and Jim Cannavino respectively. Cannavino had got a large promotion in the reorganisation - the person he reported to now reported to him. Gordon had arranged for us to have lunch and dinner with the two which was either unusual perceptiveness on Gordon's part or rather lucky - probably a mixture of both.
Gordon McBride was the IBM Account Representative at RAL
I will try and leave detailed MVS/CMS/VM technical comment to Cliff's trip report.
The Poughkeepsie visit was quite useful and we came away with some general impressions of where things were going plus some more specific information not available for wide circulation.
Specific presentations etc we had included:
This was an overview of IBM technology advances resulting in TCMs on 3081. Most of it can be found in standard literature - it is clear that TCM can handle twice the circuits with the current technology. It is overcooked - plastic spaces to lower the cooking effectiveness. The 3081 is 60% less energy and 55% less floor space than equivalent 3033 which is half the power. It is clear that they can go to faster logic and have plans to provide more exotic heat sinks on chip if it is necessary.
The helium atmosphere is partly used to stop corrosion.
Later we went on a plant our and saw TCMs being put together and mounted in 3081s. Poughkeepsie mainly puts the systems together and they are shipped out to another plant for testing. There is a great deal of automation in the chip placement, ceramic assembly etc. Operators actually measure ceramics and place chips but they have high powered displays with large magnification to do this. Some of these will eventually be done automatically.
There were about 10 3081s being assembled. All very casual - not feverish working at all. No double shift working - very different from DEC.
We also had' dinner with John Eilert and Hugh Walsh (in charge of scientific engineering for large systems reporting to Carberry).
Major point made was current simplicity of 3081 internal architecture. 85% of all instructions executed on 3033 are from a set of 25 - of those the 3033 has been optimised so that 19 are done in 1 cycle and the rest in 2 cycles. The 3081 is not optimised at all. Philosophy is keep it simple for initial release and do refinements later - it has been done before on 3033 and can be done again.
The point was made that the 3033N had been priced as a commercial machine and was very cost effective in the floating point scientific environment.
Cache misses on 3081 are expensive due to large difference in machine speed between memory and cache. Also with the 3081 running a program on either processor each time it was swapped, it is necessary to kill the cache - effectively flush it out - on a program swap. MVS can be set up to let batch take precedence on one processor to keep cache kills to a minimum.
IBM have been working on 32-bit addressing. It is a major problem for both MVS and VM. General view was that VM would be as difficult to change as MVS.
MVS/SP2 had been overtaken by MVS/SP3 and consequently would not be generally released. MVS/SP1 was mainly a performance increase, MVS/SP operations management improvements.
MVS3.8 was now broken down into a number of separate components, JES/Base Control Program, VTAM/TCAM, Data Management. Enhancements to each designed to be mutually independent. Enhancements to BCP and JES can be done independently to allow a gradual move to new releases.
General view was that JES3 would replace JES2 eventually.
MVS/SP3 would be available October 1981 and would have extended addressing support. It should give increased throughput, better TSO (swaps cause all pages to be moved on block to a contiguous area of disc) etc. SP3 should improve performance on a 3033 by 20-25%. It is also more robust and will remove 20% of all unscheduled IPCs. Estimated about 4 man months at site to install.
Emphasis at Poughkeepsie is on VM while Endicott does CMS. There had been a slip up in synchronisation between VM and MVS developments. MVS/SP3 will not run under VM until mid 1981. Aim will be to get MVS V=R overhead down to 4-5%. There was little new here and I will leave Cliff to fill out any details.
It was clear that IBM have been actively assessing vector processors of various architectures. Seemed to favour CRAY rather than CYBER like systems. Felt they had to be more integrated into the 370 architecture. Felt NAS had done a poor job and only added a minimal set of vector orders. Performance assessment of NAS vector processor was that it was very slow. IBM had placed a 3081 against a NAS system with vector processor at SLAC.
Charlie Tuller is highly entertaining as a speaker. He speculated over ways the 3081 might develop in the 80s. He made a number of points:
We started by discussing the proposed exchange with Yorktown. Sandagopan has now widened it to include all the Research labs. He had circulated our CVs to several places. Art Stein, due to children's education, will not be coming until June 1982, although he will visit the laboratory in October 1981.
They currently have two 3033 MPs and a 370/168 MP, the latter running MVS/TSO while the 3033s run VM/CMS. Hoping to get a 3081 next year. They have 1,000 3277 terminals hardwired to the system with a subset being switchable. Their VM system is heavily modified and Cliff got a good account of their changes and mode of working while I gave a talk.
The main points of interest to me was that they had modified the system so much it took them 4-6 months to get a new release installed. Still did not have VM/SP up.
Currently run 500 CMS users on 3033 MP. Their aim is 4/10 sec response to simple commands on 5 min average. Allocation of time is done on a 20-day average. If your usage in last 20 days goes above average, you lose priority by a small amount. Gradually make it more and more difficult to work.
Three systems are run by 12 operators - 5 on main shift and 3 at night.
4-7 people did all MVS developments (2 on JES3 + TSO mail facility) (2 on changes/installing new systems) (1 performance measurement).
Yorktown have a number of office facilities running under VM. All users add to the set of facilities. There appears to be no policy or direction. Among the facilities we were shown were room reservation scheme, message passing, document production, telephone directories, photo typesetter utilities, graphics to documents put in by cut and paste at the moment.
On the whole there are a lot of facilities but with no coherence - typical research department mess!
This was supposed to be a short visit but turned out a great deal more interesting than we anticipated. The centre is quite small with only 38 people but they have 25 students in the summer and 10-15 during the school year.
Major computing is 370/158 running VM/CMS and a 4331. They run about 70-80 users on 2 Mbytes with one 2305.
L.H.Seawright described their work on Distributed Processing which was aimed, rather like the ICF, at putting into the field a large number of 4331 systems and have all maintenance, operation etc controlled centrally. I have two papers on the topic. The most likely area of application initially was hospitals where there was a need for local facilities but not with the usual overheads.
All the connections use VNET and it was the main reason for implementing PASS THRU - started at CSC but then took over somebody else's code. They can down line load operating systems and have built an INTEL 8030 system which effectively acts as an operator. You can dial up 8030 and see if 4331 is powered up. If not, 8030 can do that.
They are working on doing archiving over the network. CMS files to be archived are staged onto another volume and shipped across network in off-peak periods.
They have a VM real time monitor which samples data on all systems. If a particular function is above a threshold value, it will notify the central operator who can then take action. Most of the monitoring is done by measuring Queue Drops - reasons for particular tasks being on a queue waiting for I/O, memory, run list too long etc.
They also worked on the 3101 ASCII terminal support both in line and block mode.
They have given this the name Distributed Interactive Computing and aim to provide CMS facilities on a terminal - called CNS Cambridge Nano System.
The current version is a Motorola Development System based on a 68000 on top of which they have emulated the 370 order code. Thus system looks like:
The CMS is standard apart from cutting out VSAM but all OS simulation left in. All compilers will run locally.
The CMS Assist gives Instruction Traces, facilities of CP-Diagnose. Actual I/O done by calling appropriate VERSADOS routine. Aim is to eventually eliminate VERSADOS in a rewrite.
Needs 256 Kbytes of space for CMS for Editors etc but 384 K if you want to compile. There is timer support so all files are date stamped. They need about 3/4 Mbyte to run VERSADOS etc. Aim is for it to be made available at $6K - $10K.
The communications support allows you to transfer files backwards and forwards to a 360 and also look like a terminal. They aim to implement a spool package to allow several jobs to be running centrally under your control while still working locally. Even now you can work with a job running in 360 and locally at same time.
They estimate that they run at about 370 KIPs which is more than average user gets from CMS on a main frame. We saw a demo which was impressive when editing files - local response as good as mainframe if not better. Compilation was awful due to speed of the floppy disks. They need to change these for Winchesters in which case it could be an effective terminal.
Personal On-line Integrated Text Editor. Their aim is to produce a high quality text editor as an IBM terminal. All their work is based on PERQs. They have 3 early systems, one of which is loaned to YALE University to do the algebraic formula part.
The aim is to bring together the editing and formatting phases so that you edit the formatted document. Due to late delivery of the PERQ, they have done all the developments so far on IBM Colour Terminals.
System is still in an early stage of development but it will allow you to create a formatted document and edit it - automatically repaginate. You have menus on the screen and more than one text window. Thus you can display two documents and move text from one to another. A complete trace of all transactions is kept and it is possible to reverse each of these. Thus if system goes down it can just go through all your changes to get you back to where you were. Alternatively, any mistake can be removed by just backing up a few commands.
John Prager is from Cambridge and a lot of these ideas stem from an SRC Research Grant that was done there by Richards! Whether John Prager worked on that grant I do not know.
The aim is to include graphics, voice annotations, handwritten text, tables with associated functions like VISI-CALC etc.
There is a good HELP facility with it and when transferred to the PERQ should look impressive.
We had a demo of the PERQ. They admitted, like us, that all they had managed to do were a number of demos. They would be interested in swapping demos with us. I suggested we send them a floppy with ours and get theirs back in return.
Main novelties they had were:
They went to the PERQ User Group meeting which was not too impressive. Seemed to know less about CMU and current state of PERQ software than we did.
The newly announced IBM Personal Computer System (note that is an IBM Trade Mark - nobody else had taken it) was developed at CSC. Unfortunately the prototype was broken while we were there so we could not see it in action.
It is 16-bit INTEL 8088 based with 40 KB ROM containing a BASIC interpreter and self test code. Memory is parity checked and can go from 16K up to 256K. Standard peripherals include a voice output, cassettes etc.
Keyboard is higher quality than standard APPLE. 83 keys, 10 numeric key pad, 10 function keys which you can use as a chord.
Standard monochrome display is 25 by 80 chars. Character box is 9 by 14 and character itself is 7 by 9. The 256 character set includes graphics, scientific symbols, word processing and games.
Colour display comes either as a quality monitor or adapt for home TV. Characters are 7 by 7 in an 8 by 8 character box. TV only allows 25 by 40 chars whereas monitor allows 25 by 80.
There are 16 foreground colours for the screen area and 8 background colours for the surrounding border.
You can output pixels 320 by 200 by 4 or 640 by 200 by B & W. There is a separate separate 16 KB frame buffer.
You use the standard BASIC graphics to drive it.
The Matrix printer is produced by EPSON and runs at 80 cps, bi-directional, tabs, 132 chars/line, 12 char styles with a cartridge ribbon.
There is an Async Comms Adaptor board developed by CSC allowing 50-9600 K baud connection to host. It allows communication with CMS files.
Software, apart from comms link, is also bought in. Softech provide BASIC (ROM, Disk and Advanced versions), PASCAl. Seattle Computer Products provide the Disc Operating System. Other software includes VISICALC, EASYWRITER and ADVENTURE.
Planned developments include CP/M-86 and UCSD p-System. News to me was that UCSD includes a FORTRAN compiler and assembler as well as link Editor. The FORTRAN is being added by Softech.
The speed is about 4 times an APPLE and rather more expensive. It looks very robust. IBM have developed a whole new plant to build these.
The major reason for visiting Precision Visuals was to swap copies of BSI and ANSI GKS issues. Precision Visuals market GSPC CORE system as DIGRAF which has been through a number of iterations attempting to keep up with the definition as it changes.
NOAA - National Oceanic and Atmospheric Administration is equivalent to Appleton in USA. Mike Pitteway was visiting for the summer and I decided that it was a good opportunity to have a look around. They used to be part of NBS and still look after the TIME for USA so they have quite a lot of dealings with RGO.
They had all recently been to a conference in Washington where Henry Rishbeth was awarded his international medal.
The Department runs an INTERDATA 8/32 and they use a central CYBER system and FR80. I did not pick up a great deal of relevant information. Major worry was that Reagen administration had just reduced their budget from about $150M to $60M! Projects were being closed down as a result and new projects would not be started. Apparently there had been a gradual build up in the Carter administration.
Unfortunately, Rod Burstall had been called back to England at the weekend because one of his children was ill. Henry Thompson, also of Edinburgh and currently head of AI Department, showed us around instead. We saw Altos, Dolphins and Dorados.
Both Dolphin and Dorado can have the larger STAR display with a resolution of 1000 by 700. The quality is significantly worse than the PERQ and I was not impressed by its quality.
The Dolphin is very noisy compared with a PERQ. It seemed to have a number of fans pushing air straight out at you and I found it uncomfortable. Unless your office was air conditioned, you would not like it in your office and even then the noise would be distracting. It has 30 Mbyte drive and costs about $60K. A guess would be that Dolphin is half a PERQ in performance. Even so, on some AI problems, its elapsed times for certain calculations was better than a DEC10KL. Normal rating would be half DEC10KA on single job cpu time.
There are four microcoded architectures - BCPL, LISP (Robert Rae has byte code specification), SMALLTALK and MESA.
In demonstrations, you had to keep reloading microcode as you switched between them. MESA has been issued as part of the software for STAR - PARC are continuing to develop it further. The view was that it took the four best LISP people in the world 2.5 years to implement the XEROX/BBN INTERLISP. They were sceptical that UK would have sufficient effort to reimplement it on a PERQ thus reason for Thompson/Bundy grant application to CSC for Dolphins. General view was that INTERLISP needed 600 Kbytes and 16K WCS to run (Dolphin only seemed to have 4K WCS).
At the moment there is a layered approach to its production with some BCPL code at the bottom. Even pen tracking is done at a high level in the software. Woefully slow - performed worse than a PERQ even on a Dorado.
There is a central filestore called IVY available to all the Altos, Dolphins and Dorados - they can be mixed on an Ether. Getting a file over network rather than locally gives about 20% decrease in speed.
Most of the demos we saw were either in the LISP system or MESA. Some of the software was quite old while other parts - particularly of the LISP system, was relatively new. Nothing very impressive. Most of SMALLTAlK development has moved to a different part of PARC in another building. The BYTE issue on SMALLTAlK was written by PARC. It should be possible to write to PARC to get a copy of SMALLTAlK-80 - contact Ira Goldberg.
The Dorado is a monster. Over half a rack of very hot ECL logic. It has an 8in diameter filtering pipe blowing air over the logic. Dorados were kept in a machine room with long dedicated lines to the displays in offices and terminal pool - hardly distributed computing. The Dorado was impressively fast - either 10 or 5 times a Dolphin - we were given both figures at different times. Standard memory is 1 Mbyte although one system has 2 Mbytes. About 10 to 12 people have personal Dorados with 12 public machines that you can book for 3 hour sessions.
The Dorado LISP system is complete and the CEDAR project, MESA based operating system is under development.
Dorado has 60 nanosec cache cycle time with 98-99.5% hit rate so effectively runs at an execution speed of about 100 nanosecs.
We spent some time over lunch with Jim Horning, Jim Mitchell (regards to Rob) and Jim Murrey discussing MESA. They are still working on extensions - improvements to garbage collect etc. Nothing very solid came out of the discussion.
Apparently Xerox have problems with STAR. It cannot pass the new USA radiation standards and so they have to install some before the date in October when it becomes law. The software has grown so that it will not fit into the 192K so they will have to double memory to 384K at no extra cost (prices already announced).
You can hardly call the Dorado a personal computer and the PERQ is more impressive than a Dolphin. Consequently, I was not over impressed by the devices. Altos are still around but only used by secretaries and students - how the poor live!
We met yet another new person, John Nilson. The old contact, Reed Eller, had managed to get a Vice Presidency at some other company with an offer he could not refuse.
There was little advance on the software situation, UNIVAC software was fully developed, MASSNET software was available for IBM but not SUSS. They are contracted to produce CDC MASSNET software for all three CDC operating systems, also for Honeywell. It is clear that UNIVAC is their main subject area and they have now installed a UNIVAC system in house - we have a plan of their machine room, an organogram and MTBF for JPL and their own system.
They have a MASSNET order from Westinghouse for an IBM system. Westinghouse want to connect VAX, IBM and UNIVAC with IBM system running VM and VAX connected to DECNET network. The MASSNET implementation runs under MVS and communicates to CMS via MVS.
It was clear that the MVS SUSS software would not be started until they had a firm order and that seemed likely to be a problem which would cause us problems. We spent a great deal of time discussing this.
The SUSS software originally envisaged all access to data being on a record level basis. They now have decided to implement a FILE transfer protocol for UNIVAC and may go this way for other systems.
They have concluded an OEM deal with CDC and CDC will now use M860 in place of their old mass storage system which they will phase out. Masstor have also sold an M860 to Dept of Agriculture to run in place of IBM MSS independent of SUSS software. System will be rather similar to CDC mass storage software with staging to disc going via the host cpu.
We saw an M860 in operation in the machine room. The Berkeley system is the first to be delivered to a customer and that was under development.
An interesting order is a MASSNET system for General Electric which will link IBM Honeywell and CDC on a single site and then link several of such systems together initially by land lines and later satellite communication.
We spent some time discussing the size of system we need. Rule of thumbs were that MCS could support an average throughput of 200 KB/sec while an MC6 would support 600 KB/sec. Cost of an MC6 is about $350K - $425K depending on configuration. The M860 is cheaper than the M850.
After discussion, we came round to suggesting the following scenario as a way forward:
This approach seems to be the only one that will get Masstor to start the software development early and yet for us not to pay for it. Delivery times from date of order will be ATL (3 months), Processor (5-6 months) and M860 (2-3 months).
We suggested that we would insist on software running under MVS/SP. In their letter to us, Masstor would also indicate the position with respect to MVT.
Cliff has full details of MTBF. Some examples of Fujitsu kit are tape (11,000 hrs), MC6 (6,000 hrs), discs (20,000 hrs +), ATL (700 hrs). Up time of ATL including initial period was 98.6%.
Masstor have concluded an OEM agreement with Magnuson to use their processors in place of Fujitsu in some bids. In my view, this was because of the sensitivity of bidding Japanese processors for some government tenders.
