The Core Memory Project



NEAT 399  Programming
A Programmer's Perspective:
   Subject: Be Afraid, Be Very 
   Afraid (NCR 399) :-) 

   I just happened to find your 
   NCR 399 page by mistake. 
   Oh my God! I can't believe 
   those are still around any -
   where! I would have 
   thought that anyone who 
   had ever programmed one 
   would have made it a per -
   sonal goal to destroy any 
   remaining ones. :-) 

   My first job out of school 
   was for NCR. I spent the 
   better part of three years 
   programming that monster 
   and installing them around 
   Massachussetts. When I 
   first started using it, we 
   only had two cassette tape 
   drives on it. To compile, 
   you had to have one tape 
   for your source, another 
   for the compiler, and 
   another for the linker, 
   and finally one to write 
   your object code to, It 
   would take about 30 minu-
   tes to compile a program, 
   and every 5 minutes or so 
   you had to change tapes.

   The programming language 
   is Neat/AM (AM=accounting 
   machine). The magnetic 
   ledgers were a piece of 
   ledger paper about 12" 
   wide by 16" long. They had 
   a piece of magnetec tape 
   glued to the back which 
   would store the information 
   printed on the front. 
   They were great transition 
   systems for the small 
   business which had always 
   used paper ledgers to keep 
   their books. The 399 let 
   them keep their ledgers, but 
   then they could feed the 
   ledgers one at a time into 
   the system where it would 
   be read onto tape at the 
   end of the month. 
   You would then have a 
   statement program, or 
   general ledger, or accounts 
   payable which would read 
   the tape and produce 
   checks, or customer 
   statements, etc. 

   You could also enter 
   patches into the console 
   after you had loaded a 
   program. (I was known as 
   "patches" by one of my 
   customers for a time :-) ).

   Oh well, enjoy it. It was 
   kind of like seeing an old 
   friend, after a long time, 
   well sort of... 

   Words to live by with a 399...
   "If all else fails hit Halt, then 
   Reset, then Compute :-).

   (taken from A Crufty Relic)

Been there done that.

My partners Assembler routines were magic - create command at position zero and the jump to zero. Worked a treat with the miniscule memory we had then however debugging could be an interesting exercise.
My own first attempt at standardization  generator/4gl call it what you will was in Neat/3 using hexadecimal tables that moved the appropriate 2 byte command into the position for the input statement.

Plus one had to pack all data using 4 bits for a number instead of 8. Again because an NCR 399/499 cost $30,000 in 1973 and took 4 men to carry it. The only problem came some years later when they tried to get Cobol programmers to extend it. By which time I was a Pick devotee - try restarting an NCR after a power failure, a Reality with core just popped up where it left off.

Peter McMurray


NCR 399 Programming Language

Internal operations and certain external functions of the NCR 399 system are programmed in the 399 mnemonic language, using near-English macro instructions designed specifically for accounting applications. The programmer must supply two types of information to the application program — data descriptions and procedural instructions. Data layout and coding worksheets are provided for the completion of this information.

The data layout worksheet is used to define the format of Data Layout Worksheetthe variables on which all arithmetic and data handling operations are to be performed. This data is stored in memory in the form of numeric or alphanumeric values provided as a part of the application program or as a result of previous operations. Each data field defined by the programmer will have a header associated with it in memory. This header contains information reflecting the format of the data field as specified by the programmer on the data layout worksheet. In addition to field length, data type, decimal position, and sign, such information as print position and paper advance code can be defined to achieve automatic print control.

If the data being defined is to be printed on the serial or line printer, the programmer can specify the column number where printing is to start and the number of lines to advance the paper after printing that data lield Then, when the data field is output to the printer, it will be printed automatically in the specified column and the paper advanced if necessary. This feature is especially advantageous when formatting and printing reports; it saves memory by eliminating unnecessary coding within the program.

The NCR 399 programmer need never be concerned with keeping track of actual data addresses in memory. Meaningful symbolic names are assigned to data fields in the program. Once the programmer assigns these names, he thereafter refers to data by name only; software automatically handles the hardware addressing.

Procedural instructions are entered on the 399 coding worksheet.Coding Worksheet These instructions: (1) define the functions that must be performed to achieve the end results of the application, and (2) specify the application data that is to be operated on by the interpreter. Instructions, which are variable in length, may contain up 10 three operand addresses.

The 399 language is made up of a comprehensive set of macro-instructions that control forms movement and printing, manipulate data, perform arithmetic functions, process tables, and transfer information to and from the I/O devices. Each macro is a software instruction that, when executed by the interpreter, initiates a series of hardware functions necessary to accomplish the specified task. For instance, when the programmer codes a PUT Serial Printer instruction, the interpreter initiates execution of all those internal functions required to print on a document inserted in the forms handler.

Functions that previously had to be performed manually by the operator now are accomplished under program control, resulting in faster, more efficient operation of the system with less chance of human error. These functions include such operations as positioning the serial printer for typing, rewinding the cassette tape, positioning forms to a specified printline, opening and closing the platen, and ejecting documents.

Simple Input/Output (I/O) instructions handle the normally complex operation of transferring data to and from peripheral units. For instance, to input data from an I/O device such as the card reader, the programmer need only code a GET Card Reader instruction. Issuance of the instruction causes data to be transferred from the card reader to an area in memory defined by the programmer. The instruction performs all necessary translation (from Hollerith card code to ASCII characters) and data formatting. Likewise, to punch a card, the programmer issues a PUT Card Punch instruction, which transfers data from memory to the card punch peripheral. Certain peripherals, such as the line printer, also provide control instructions that perform such functions as paper advance and print positioning.

Because each macro can initiate the performance of many functions, program length and complexity, and programming effort are reduced significantly. The 3-address structure of the language is another powerful feature that minimizes program length. For example, with just one instruction, a programmer can direct the 399 to add the contents of one address to the contents of another address and store the result in a third address.

Variations of the add instruction allow the programmer to:

(1) Add one series of individual consecutive fields to a second series of individual consecutive fields.

Add: A1 to B1 A2 to B2 A3 to B3

(2) Add a series of individual consecutive numeric fields to a single field.

Add: A1 to B A2 to B A3 to B

(3) Add a single numeric field to a series of consecutive fields.

Add: A to B1 A to B2 A to B3

Up to 31 consecutive fields can be affected by one add instruction. The subtract, multiply, divide, and move instructions operate in much the same manner.

The NCR 399 processor controlled both internal operations such as arithmetic, decision making, and data manipulation, and external functions suASCII Codech as typing and forms alignment and movement. Normally, a processor such as that used in the 399 must be programmed at the hardware level, which means that the user either must write lengthy, complex programs or sacrifice a certain degree of flexibility by relying entirely on packaged software provided by the manufacturer. Recognizing the need to ease the user’s programming burden while still providing him with the ability to tailor the system to his own requirements, NCR decided to take an interpretive approach to programming. This approach permits the user to interface with the hardware through the medium of a simple, problem-solving programming language, enabling him to concentrate on the requirements of his system rather than on the intricacies of the equipment.

NCR 399 software was designed specifically to solve accounting problems. It simplifies the programming of even the most difficult applications — payroll, accounts receivable/accounts payable, inventory, financial reporting, utility billing, and so on. The 399 programming language provides clear, concise, near-English macro instructions that describe the steps necessary to accomplish a specified task. These instructions are entered on special 399 programming worksheets and become the application program. As the 399 processor does not recognize near-English instructions, they must be translated into a format that can be interpreted for execution by the processor. This format consists of series of bits; translation to that format is performed by an assembler program.

Program assembly

When an error-free program has been assembled or reassembled on cassette, it is read into memory, and an interpreter is tailored to that particular application by a link loading process. All communication between the user program and the 399 processor is then controlled by the interpreter.

Program execution


Assembling 399 Programs

Each line coded on the programming worksheets is a source line; all the source lines for a given application constitute the source program. However, the source program is not executable by the processor in this form. It must be converted to a form compatible with the interpreter for execution by the 399 processor. This conversion is performed by the 399 assembler program, which is contained on the Master Software Cassette supplied with every 399 system.

NCR 399 application programs can be assembled directly on theAssembly Specifications for NCR 399 399 unit or, optionally, on an NCR Century system. The assembly process is controlled through entries on the appropriate assembler specification worksheet.

These parameter sheets are used to supply the assembler with information about the application program and the 399 system on which it will be run, and to request that certain optional functions be performed during the assembly process itself. The worksheets become a part of the source program for input to the assembler. The source program may be punched into cards or it may be input to the assembler through the 399 alphanumeric keyboard directly from the worksheets. The operator is guided through the assembly process by the lights on the status indicator panel, which are used to request and verify his responses, request cassette changes, and indicate errors.

The 399 assembler operates in two phases. The first is a preassembly phase, which validates certain portions of the source input and writes it to cassette in preparation for the next phase. The resultant programAssembly Specifications for NCR Century on cassette is called the reassembly master. Additionally, this phase calculates memory addresses for use with the associated symbolic reference names assigned by the programmer and builds a table that specifies which interpretive subroutines are to be included in the program.

The second phase reads one source line (one 80-character record) at a time, condenses it into a series of bits that indicate to the interpreter which routines to execute and on what data fields to operate, and records the assembled program on a cassette. A source program listing is printed on the serial printer as each statement is processed. Any errors encountered during assembly are printed as a notation preceding the erroneous source line.

Reassembly permits corrections, additions, or deletions to a previously assembled program. For instance, a program can be reassembled to correct errors detected during an initial assembly or to include additional logic when peripherals or memory are added to a system. Input to the assembler during the reassembly process includes the reassembly master (the cassette tape output during the first phase of assembly) and only those source lines affected by changes, eliminating the need to enter the entire program a second time. The program is modified by matching source lines, inserting new ones, and deleting old ones where necessary.

Programs can be assembled directly on a 399 system that includes two cassette handlers. If a system has only one cassette handler, NCR will provide, on a temporary basis, a second, plug-in cassette handler to permit program assembly. An NCR Century assembler is also available for assembling 399 programs.


Program Execution

The purpose of the assembly process is to convert an applicationApplication Program program into a format that can be used by the 399 interpreter for execution of the program. The assembled program contained on cassette is referred to as an unexecutable object program because it does not yet include the interpreter. To create an executable program, an interpreter must be tailored to that particular application. This is accomplished through a series of software programs called Linking Loader, which were written to the object program cassette during assembly. First, Linking Loader calls into memory the unexecutable object program from its cassette. Next, from the Master Software Cassette it calls into memory the basic interpreter and only those optional interpretives required by the program. The result is a memory-resident executable program.

The actual amount of memory allocated to the interpreter, user program, and data areas depends on application requirements. Once an executable program is built in memory, it can be processed and/or copied to cassette.

The interpreter is the software interface between the 399 language and the minicomputer and its peripherals. It controls all I/O devices and the sequence of program operations, ensuring that the proper routines are executed as necessary. The interpreter can be divided logically into three areas, or subsystems — executive control, internal operations, and I/O operations.

Automatic sequencing of operations within the 399 is performed by executive control, which uses instructions from the application program to perform the setup operations required by internal and I/O related subsystems, to control program sequencing, and to request operator input as required. In addition, the executive provides common routines that may be used by the operating subsystems, determines which operations program is to perform the application instruction, and transfers control accordingly.

The internal operations subsystem includes all those routines associated with arithmetics, data handling, and data formatting, as well as other standard routines designed to minimize the memory requirements of the interpreter.

The I/O operations subsystem performs all operations directly associated with peripheral devices and is responsible for hardware-related error detection and correction.

The interpreter’s normal sequence of operations begins with the executive, which reads and decodes an application instruction. Using the assembled instruction (the series of bits), it searches a table for the address of the designated macro routine. When the instruction is set up, control is transferred to the appropriate routine in the internal operations subsystem. I/O related routines are accessed by the internal operations subsystem as they are needed. Upon completion of all necessary operations, control is returned to the executive, which then reads and decodes the next program instruction.



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