The Core Memory Project

 

 

NCR Criterion Series
Special Thanks To

Ian Ormerod for his contribution to this page.

NCR Criterion
Click the name for details Click to see details
Click the name for details Click to see details
Click the name for details Click to see details
Click the name for details Click to see details
Click the name for details Click to see details
Criterion Lady
Criterion Lady Jeannie Van Arsdale
Jeannie Van Arsdale

NCR Criterion Series

Product History

A basic ground rule of the Criterion system design from the start was full compatibility with existing NCR Century software and user programs. The product strategy was NCR Criterionto initially introduce the hardware to run existing software, and subsequently to introduce new software as a second step. This approach eases the migration path for the user and NCR. It is an approach that lowers the risk during such a major product introduction.

Ground rules for the new software system were that it should run existing programs without change, and that the customer would be able to convert to it with very little effort or cost. NCR has fully achieved the objective for compatibility of the hardware. This has been demonstrated by both their internal testing and the experience of the customer pilot installation where systems running on a Century 200 were moved to a Criterion 8550 with no changes to the system or application programs and the customer operator required less than two hours training.

In order to satisfy the compatibility requirement, it was decided that the new software Virtual Resource Executive (VRX) would utilize B-series code, either unchanged or, where necessary, modernized, to meet the interfaces expected by existing NCR Century B-series programs. The B4 operating system was chosen as the starting point for developing VRX. Alongside the existing or modernized B-series code, a new set of software interfaces was designed and implemented. The goal of the new code was to introduce new capabilities primarily in the areas of virtual storage, data management, telecommunications, and COBOL '74.

 

Criterion Hardware

The Criterion mainframe was self-contained in a single cabinet which houses the Internal Transfer Bus (ITB), and several processor, memory, and input/output control subsystems which fit on the bus, together with the power supplies. This cabinet occupied 9.8 square feet and thus the Criterion mainframe required considerably less floor space than most present-day computer systems of equivalent power.

Most of the subsystems within the mainframe were implemented on 11" x 14" cards, and the primary logic circuitry was Emitter-Coupled Logic (ECL).

 

Internal Transfer Bus (ITB)

The focal point of the Criterion system architecture was the Internal Transfer Bus (ITB). It was a high-speed data path across which all Criterion subsystems communicate with each other: these include the Main Processor, the Service Processor, the Memory Subsystems, the Common Trunk Subsystems, and the Integrated Disc Controller.

The main advantage of a bus-oriented architecture is that it permits NCR to design hardware in a modular fashion, to satisfy a wide range of capabilities. When NCR need to add a certain hardware capability to the system (for example, a new type of peripheral controller, or a new type of main memory), they designed it in the form of a subsystem that fits on the bus.

Thus future enhancements, as well as field upgrades, were easily implemented - they take the form of additional cards that are simply added to the bus back-panel. In addition, this hardware modularity eases the task of fault isolation and correction, contributing to high system availability.

The use of the bus architecture was an extension of a technique used in smaller, slower systems to reduce costs of system element interconnection. The use of the bus in Criterion was primarily to provide an open ended and flexible architecture. The 72 megabyte per second bandwidth of the bus provided a wide margin to avoid contention between subsystems for bus access and for fast data transfer between subsystems such as a processor and memory.

This open-ended design accommodated architectural extensions such as multiple processors, future I/O subsystems, and future integrated controllers and is especially suited to distributed processing applications.

 

Criterion Firmware

The use of firmware technology was a major departure from the Century architecture to the Criterion system architecture.

Firmware was really a form of programmable hardware. In a firmware-based system such as Criterion, instead of having a processor with hard-wired control logic, NCR had a micro programmable processor executing firmware which is contained in a high-speed memory called a "control store." And they went one step further by making this a "writable control store," which is loaded with the required firmware from a flexible disc. Because the company could tailor the firmware to perform exactly the required functions, this gave the system much more power and flexibility, and it can use one processor for a variety of different functions, simply by selecting the firmware to load into its control store. Thus firmware gave the hardware a specific set of attributes or a "personality."

Firmware was used throughout the Criterion system for such functions as input/output control and micro- diagnostics. Where the firmware interfaces directly to software, it takes the form of a "Virtual Machine." A virtual machine is simply a machine, implemented in firmware, which executes software. It may be designed to emulate, or execute programs like an existing machine, as is the case with the Criterion RS firmware which emulates an NCR Century and runs existing B-series software. Or it may take the form of a new machine designed to match the needs of new software or to reflect the attributes of a programming language. In this latter case, the existence of firmware permits the virtual machine to be designed to execute instructions much closer to the source language than was previously feasible with hard-wired logic. Virtual machine commands may correspond nearly one-for-one with the verbs of the higher-level language as is the case with the Criterion COBOL Virtual Machine. This results in greatly improved performance for COBOL programs.

The Criterion Virtual Storage (VS) firmware included the COBOL Virtual Machine, as well as a virtual machine designed to match the needs of the new VRX operating system software. This VRX Virtual Machine is a superset of the NCR Century Virtual Machine, and, therefore, also satisfies the compatibility requirement that existing Century B-series programs must run under VRX.

The VS Firmware thus included two virtual machines: COBOL and VRX.

These reside together in firmware control store, and are executed concurrently as required by the software. This NCR called "Multiple Virtual Machine" operation. The switching between virtual machines was performed in a very few processor cycles by a firmware routine, and does not involve any control store load process or program awareness while the switching is occurring.

Firmware can also give the Criterion the "personality" of other machines although only the Century and COBOL Virtual Machines were offered at the beginning. Firmware was used extensively throughout the Criterion system. There were various subsystems on the bus, several of them were firmware-driven: the Main Processor, the Service Processor, the Integrated Communications Module, and the Integrated Disc Controller. Each of these subsystems has firmware loaded into its writable control store as part of the start-of-day procedure, under control of the Service Processor.

Firmware is a central architectural element to Criterion and brings to the system great flexibility, extension possibilities, and performance improvements over traditional architectural approaches.

The Main Processor is designed for fast interpretation and execution of object programs by firmware. The firmware executes out of a high-speed control store, which operates at the same cycle time as the main processor which is 112 ns. for the Model 8550 or 56 ns. for the Model 8570. Through the use of a pipeline, firmware instructions are executed effectively at the speed of one processor cycle per instruction.

The pipeline consists of three phases of instruction processing: Fetch, Interpretation, and Execution. Each phase requires one processor cycle; however, the pipeline is designed such that three firmware instructions are processed in parallel, one in each phase. This is made possible by the fact that each instruction in the firmware instruction set, with a few exceptions, has been designed to complete within the three cycles. The pipeline organization has been utilized in much larger systems to achieve similar results and the Criterion brings this technique now to its system class.

 

Memory Subsystem

The Memory Subsystem consists of one or two memory interface units, each of which may control up to four 64,000 byte memory cards; these may be further extended to provide up to 1 megabyte of main memory in the Criterion 8570 Model.

Memory technology is perhaps the technology that has changed most rapidly with respect to cost. Those days, by packaging the 4K MOS memory chip on 11" x 14" cards, NCR attained a density of 64,000 bytes per card. When they took into account the cost of the necessary memory interface and control hardware, this worked out to a cost of lless than one-twentieth of the cost of the core memory first used in the NCR Century 200 in 1970, which itself was about one-half the cost of the original NCR Century rod memory in 1968.

 

Input/Output Subsystems

Peripherals which used the NCR Century common trunk discipline may be connected to the Criterion system through one of three types of common trunk: low-speed, medium-speed, or high-speed. The trunks have been designed for various processing requirements, and can be selected for the most economical peripheral configuration. Thus, most Century peripheral devices and controllers can be utilized in the Criterion system including the complete line of Century communications equipment and terminals.

The new 6590 Data Module Disc unit interfaces to an Integrated Disc Controller (IDC), which is another firmware-driven subsystem that connects to the bus. The Integrated Disc Controller, in fact, is basically the same hardware unit as the Service Processor, but is driven by different firmware designed specifically to perform disc control functions.

In addition to the communications capability of the Century 621-103 Multiplexor, which allows connection of one to 255 lines depending on line speed, the Criterion offered a one to ten line communication capability for smaller terminal systems. This capability has been provided by an Integrated Communication Controller which connects to the bus. This controller used a microprocessor to emulate the operation of the 621-103 and provides the same facilities to the program and communication lines.

 

Service Processor

The Service Processor operated in parallel with the Main Processor, and was concerned primarily with input/output control and diagnostics. It controls and drives the card reader, flexible disc, console CRT, and any hard-copy console devices. It also performs the firmware load function, where firmware is read from the flexible disc and distributed to each firmware-driven subsystem.

The Service Processor has primary responsibility for error control and system diagnostics, including a start-of-day diagnostic which is run as part of the initial firmware load process. Should a malfunction occur in the system, the Service Processor provides the tools for detection and isolation of the problem. The diagnostics operate at the micro-program level and in addition to the usual fault detection and isolation facilities, offer two unique features.

One set of diagnostics are designed for customer operation. These programs can be loaded by the customer operator when errors are suspected. They will test the system and notify the operator if there is a failure and also display the most likely boards required to correct the failure. When the customer calls field engineering he can tell them what has been displayed and thus increase the likelihood of having the correct board for repair.

The second feature is Remote Diagnostics. By granting permission at the system console, the customer can allow connection of a remote CRT terminal as a dual console. The field engineer at this remote console can see all the console displays and through the terminal keyboard control the system operation of diagnostic programs. In this way, expertise deeper than that available at the customer's site or a local office can be utilized to solve the more difficult failure problems.

 

Criterion Software

The NCR Criterion is being offered as two different machines. With real storage firmware, it is an NCR Century machine which runs existing B-series software and user programs. With virtual storage firmware, it operates under control of the VRX operating system providing a virtual storage system.

 

B-series Software

The B-series Software offered with Criterion was the most current release and has been operating at pilot Criterion customer installations. The B1, B2, and B3 operating systems were available to Criterion users, together with the full set of Century B-series compilers, utilities, and applied programs.

The initial pilot site experiences have been totally successful, and have proved beyond any doubt that the compatibility between Criterion and the NCR Century is real.

 

Virtual Resource Executive (VRX)

With the VRX system NCR have maintained its commitment to compatibility, so that, by and large, any program running on any NCR Century system will run as is, without recompilation, under VRX. Similarly, all files supported on NCR Century systems are supported under VRX, as are the B-series compilers, utilities, and applied programs. A few obsolete peripherals, such as CRAM and 655 Disc, were not supported under VRX; but files using those peripherals can be quickly and easily transferred to newer, fully compatible devices.

VRX, while remaining compatible, was a new software system, offering many significant features which make it competitive with any software system in the industry. VRX represented a large software effort and investment by NCR, and was the culmination of three years of intensive work.

One of the primary goals of VRX has been to improve the usability of our software, and thereby, to reduce the time and cost required for users to develop their computer applications. This has been done by making the system more automatic, more responsive, and more interactive.

The Virtual Resources Executive is called "VIRTUAL," because it supports two new capabilities: Virtual Machines and Virtual Storage. The Multiple Virtual Machine operation of the VRX and COBOL Virtual Machines has already been covered. Virtual Storage, or Virtual Memory, was new to NCR, but had been available on competitive systems for several years.

This approach reduced the cost to develop and maintain programs and improves reliability for both user programs and system software.

Burroughs has had its own form of virtual storage for many years, and IBM popularized virtual storage on a wide scale when it was introduced on the System/370 in 1972. NCR's implementation of virtual storage in VRX is similar to the most sophisticated of IBM's several implementations known as OS/MVS, which has been available only on systems renting for over $30,000 per month. NCR considered their implementation of virtual storage to be a cost breakthrough, providing sophisticated capabilities on systems  below the cost of comparable competitive systems.

Another primary feature of VRX was a new data management system called the Criterion Access Method (CAM). Initially designed to support just Disc peripherals, CAM fully supported the input/output requirements of the COBOL '74 language. It supported three different organizations: sequential, relative, and indexed. These three access methods permit file organizations to be designed in an optimum way for each specific application.

VRX included new telecommunications software which supported two new programming interfaces for development of on-line systems; a Message Control System (MCS) interface, and a Low-Level Interface (LLI). The Message Control System was compatible with the COBOL '74 language, and provides a simple, terminal-insensitive interface to the application programmer. The Low-Level Interface is a more basic interface, giving the programmer more control over his telecommunications devices.

Two new compilers were provided with VRX: COBOL '74, and NEAT/VS.

The VRX COBOL '74 compiler was primarily a high-level implementation of the ANSI 1974 Standard. It produced object code for the COBOL Virtual Machine (CVM) which runs under VRX, and was designed to match the needs and characteristics of the COBOL language.

The NEAT/VS compiler was compatible with the NCR Century NEAT/3 language, and provided programming interfaces to the new software features available under VRX.

A new Link Editor was also supplied with VRX, to assist users in writing modular programs. The Link Editor binds together program modules written either in COBOL '74 or NEAT/VS, prior to program execution.

Throughout the design and implementation of VRX, a strong emphasis has been placed on performance and reliability. User programs should generally run faster under VRX than on comparable NCR Century systems. And the VRX software should prove more reliable and error-free than any previous NCR software system, due to the application of improved development tools, comprehensive programming and documentation standards, rigorous test programs and procedures and the modular structure of the programs.

With VRX, NCR offered a significant software advance which attracted both existing NCR Century users and users of competitive systems. This confidence has been supported by NCR analysis of major software features, which shows that VRX had a significant edge over competitive software systems in the same price range and compared favorably to systems priced much higher than Criterion.

 

Criterion Models

The basic Criterion 8550 system included a 112-nanosecond processor with 128KB of main memory, an integrated 600-card/minute reader, a 1,200-line/minute printer, and two 100-megabyte 658 disc units.

The basic Criterion 8570 system included a 56-nanosecond processor with 256KB of main memory, a 600-card/minute reader, a 1,200-line/minute printer, and three 100-megabyte 658 disc units.

Most Century peripherals and terminals could be transferred directly to Criterion systems. This included the 656, 657 and 658 disc units.

A new type of disc unit, the 6590 Data Module Disc, were available with Criterion. The 6590 had a capacity of 70 megabytes or 140 megabytes per dual disc unit; it had an 885KB/second transfer rate, and an average access time, including latency and seek time, of 35.1 milliseconds.

Three other new peripherals were available with Criterion. These were a 600-card/minute card reader, a 1,000-character/second paper tape reader, and a 173-character/second matrix printer.

 

 powered_by_google_135x3502
The Core Memory Project. Started 04.02.2005.
Copyright © Aleksandrs Guba. All Rights Reserved