IBM 1130

IBM 1130 Console

IBM 1130 with IBM 1442 Card Reader/Punch.

The IBM 1130 Computing System, introduced in 1965, was IBM's least-expensive computer at that time. It was aimed at price-sensitive, computing-intensive technical markets like education and engineering, succeeding the IBM 1620 in that market segment. The IBM 1800, introduced in 1966, was a process control variant of the 1130 with two extra instructions (CMP and DCM) and extra I/O capabilities. The IBM 1500 instructional system was introduced by IBM on March 31, 1966 and was based around either an IBM 1130 or an IBM 1800 computer, it supported up to 32 student work stations each with a variety of audiovisual capabilities.

Description

The 1130 became quite popular, perhaps 10,000 1130s were manufactured. The 1130 and its non-IBM clones gave many people their first feel of "personal computing." Its price-performance ratio was good and it notably included inexpensive, removable disk storage, with a reliable, easy to use disk operating system that supported several high level languages. The low price and well balanced feature set made interactive "open shop" program development available to a large number of users for the first time. The 1130 holds a place in computing history in part because of the fondness its former users hold for it.

Processor and memory

A double width SLT card from an IBM 1130. The square metal cans contain the hybrid circuits.

The IBM 1130 used System/360 electronics packaging called Solid Logic Technology (SLT) and had a 16-bit binary architecture, not very different from later minicomputers like the PDP-11 or Data General Nova.

The address space was 15-bits, limiting the 1130 to 32,768 16-bit words (65,536 bytes) of core memory. Both direct and indirect addressing capabilities were implemented.

IBM 1130s with an 'A' in their model number were delivered with 4,096 words of core memory, 'B' models with 8,092 words of core memory, 'C' models with 16,384 words, and 'D' models with the maximum supported 32,768 words of core memory.

Operating system

Part of the reason for the enduring memories of the IBM 1130 was that the human operator was required to perform much of the operation.^{[citation needed]} The IBM 1130 did not have an operating system. Instead, it used a monitor program. Nearly all systems had at least one disc drive, and on that was stored the components of DMS or DM2 (Disk Monitor system, release 2) while resident at the start of the core memory was the Skeleton Supervisor, which when a task ended, organized the loading of the next task. This typically involved reading the next card from the card reader, which should start with // JOB card etc. In other words, the operating system's task was to read through the deck of cards the human operator loaded into the card reader, initiating the tasks identified by the command cards such as // JOB for the start of a new user's "job", // DUP for the Disk Utility Program (to delete files, or add the file in the temporary area to the file collection) and // XEQ to execute some named program from those on disc. This in turn meant that no data deck could involve a card that began "// "; on detecting such a sequence the standard card reader routine would declare end-of-input to the running task, and reserve that card's content for the supervisor.

The skeleton supervisor was tiny by modern standards, containing assorted system details such as interrupt responders plus just the card reader and disc driver and routines to load the interpreter of the // commands. A task's first available memory started with address /01FE (hexadecimal) or word 510, thus the skeleton supervisor required just 1020 bytes. When the IBM 1130 was started, even though the skeleton supervisor would still be in memory (ferrite core memory retains its state without power) and probably intact, it was usual to initiate the bootstrap process by loading a special card from the card reader, which contained code to read the contents of sector zero of the disc drive. The requirements for handling the "operation complete" interrupt from the disc drive were part of the data in that first sector. The whole process took about a second to complete.

A particular task may involve additional I/O devices, so device drivers would be incorporated as part of the loading of that task, which might also call for the replacement of the basic disc driver by a more advanced driver. While the task was running, the monitor was inactive, aside from device drivers and their interrupts: all CPU time was entirely devoted to the task's activities. On the other hand, there was no memory protection, nor disc file protection. While the skeleton supervisor was not a large target there could still be mishaps, but the recovery time of restarting the system was brief. If the operating system on disc was damaged, reloading it from the special binary deck involved reading some four thousand cards.

The file system was straightforward. All files were contiguous. A file started at some sector and continued unbroken to its last sector, thus there was no fragmentation. Free space started after the last named file, and might be partially occupied by a temporary file, as might be produced by a compiler. If a file was to be modified, the usual process via // DUP commands was first to delete it, which would require all following files to be moved back to close the gap, and then the temporary file was declared to be the (new version of) the file. Rarely modified files would thus sink towards the start of the disc as new files or new versions were appended, and frequently modified files would jostle amongst each other towards the end of the disc. Disc space was at a premium, so program source files were normally kept as decks of cards. Users having larger requirements would arrange to have a disc of their own containing the operating system but only their files and would have to replace the "pool" system disc with theirs and restart the system when their turn at being operator came. A system with a second disc drive that could be devoted entirely to some user's code and data provided a great sense of spaciousness.

Software

Much programming was done in Fortran. The 1130 Fortran compiler could run on a machine with only 4,096 words of core. To maximize speed and conserve space, the operating system and compilers were written entirely in assembly language, and employed techniques seen less frequently today including tight integration of code and data as well as self-modifying code. The compiler was broken into many small "phases" that were linked to successively, each phase performing its own modifications of the representation of the source on their way towards machine code. Thus the first phase would read the source statements into memory, discarding comment lines, squeezing out all spaces (fortran syntax is unusual in that spaces are nowhere significant outside text literals) concatenating continuation lines and identifying labels, and performing no syntax checking beyond what might be discovered during this stage. It was available in a disk resident version, as well as on 8-channel punched paper tape or punched cards. In order to permit the use of programs that were too large to fit in main memory "all at one time", the implementation of the Fortran language permitted any subroutine to be designated as a "LOCAL", which stood for "Load-on-Call Subroutine". The operating system would also designate the floating-point arithmetic routines LOCAL at need. This use of disk-resident (overlay) code required the executable code for such a subroutine to be "loaded" [read] from disk in to main memory, (if it was not already present in main memory) when that subroutine was "called" (invoked). A collection of say six such routines would require only as much storage as the largest, rather than the total amount for all six.

Other programming languages available on the 1130 included: APL, BASIC, COBOL, FORTH, PL/I and RPG. Even an Algol compiler, but in French, so "Debut ...Fin;" rather than "Begin ... End;" and with all messages in French, so "Bonne compilation" was the goal. Eastern Michigan University developed a Fortran IV compiler for the 1130, known as Fortran-EMU as an alternative to the Fortran II compiler provided by IBM. It added many features, including the LOGICAL data type, enhanced diagnostics, and six-letter variable names. Oklahoma State University developed an ALGOL 68 compiler [1], the compiler was written in ANSI Fortran 1966.

Peripheral devices

2315 compatible disk cartridge.(dimensions 1 3/8 x 15 in.)

IBM 1442 card reader/punch

IBM 1627 drum plotter.

The basic 1130 came with an IBM 2310 voice-coil actuated disk drive, called "Ramkit", from IBM's General Products Division in San Jose. These read pizza-box-sized 2315 single platter cartridges that held 512 K words or 1 M byte (less than a 3.5" HD floppy). Disk memory was used to store the operating system, object code, and data, but not source code. The last was kept on punched cards. The disk operating system was called DMS or DM2 (for Disk Monitor System, Release 2).

The console typewriter used an IBM Selectric mechanism, which meant one could change the type by replacing a hollow, golf-ball sized type element. There was a special type element available for APL, a powerful array-oriented programming language using a special symbolic notation. A row of 16 toggle switches on the console typewriter could be individually tested from within programs, using the Fortran statement IF (SENSE SWITCH i), for example.

Other available peripherals included:

• Printers - the IBM 1132 and IBM 1403 lineprinters
• Punched-card - the IBM 1442 card reader/punch and the IBM 2501 card reader
• Paper Tape - the IBM 1055 paper tape punch, the IBM 1054 paper tape reader, and the IBM 1134 paper tape reader
• Disk - the IBM 2311 Disk Drive
• Magnetic Tape - From 1968, IBM 2415 Magnetic tape data storage drives were available as an RPQ.
• Graphics - IBM 2250 Graphic Display Unit and the IBM 1627 drum plotter.
• Communications - Synchronous Communications Adapter (SCA). The IBM 1130 MTCA, for Multiple Terminal Control Adapter, was announced late in the product life of the 1130; it allowed up to four 2741 terminals to be connected to an IBM 1130, for use with APL.

A standard 1130 had a 3.6 microsecond memory cycle time, with a more expensive model equipped with 2.2 µs memory cycle time. (You could use the latter with a 1403 printer connected through a 1133 multiplexer.) To further tap the low end of the market, IBM introduced the 1130 Model 4, with a 5.6 µs cycle time - at a lower price of course. The Model 4's 1132 printer was derated as well, but the slower CPU still could not keep up with it. (The 1132 used the CPU to determine when to fire the print wheels as they rotated, a very compute intensive function.) Careful readers of the 1130 hardware manual discovered that when the printer interrupt level (1) or the 1442 column interrupt (0) was on, the 1130 Model 4 ran at the faster 3.6 us cycle time. Some users of the Model 4 would write a phony printer driver that turned on level 1 and left it on for the duration of the compute-intensive part of their application. No I/O could take place during this time as even the 1442 used a level 4 interrupt to mark the end of the card. Level 0 was the highest interrupt level and level 5 was the lowest.

IBM 1130 Models

IBM implemented five models of the 1131 Central Processing Unit which was the primary processing component of the IBM 1130 Computing Systems.

	Storage Speed
Storage Size	3.6-microsec. storage cycle no internal disk	3.6-microsec. storage cycle plus disks	3.6-microsec. storage cycle (70% performance) single disk	2.2-microsec. storage cycle plus disks	2.2-microsec. storage cycle (no internal disk)
4096 words	Model 1A	Model 2A	Model 4A	---	---
8192 words	Model 1B	Model 2B	Model 4B	Model 3B	Model 5B
16,384 words	Model 1C	Model 2C	---	Model 3C	Model 5C
32,768 words	Model 1D	Model 2D	---	Model 3D	Model 5D

The IBM 1800 was a variant of the IBM 1130 with additional features for process control applications. Just as the IBM 1130 was a successor to the IBM 1620, the IBM 1800 was a successor to the IBM 1710. The IBM 1500 was a multi user educational system based on the 1130 and 1800.

Chronology

• Feb. 11, 1965 - IBM introduces the 1130 (Models A1, A2, B1 and B2). Also announced is the IBM 1132 printer, the lowest cost online computer printer ever announced by IBM at that time.
• Fourth Quarter 1965 - First customer shipments begin from the San Jose plant.
• April, 1966 - 1800 ships.
• August 9, 1966 - IBM rolls out the 1130 synchronous communications adapter, which permits the small 1130 system to be connected by regular leased telephone lines to, and function as a communications terminal for, any model of the IBM System/360.
• April 17, 1967 - A four-way expansion of the 1130 is announced (Models B3, C2, C3, D2 and D3), involving:
  • five times the disk storage and four times the magnetic core memory size;
  • an additional processing speed almost 40 percent faster than previously available;
  • More and faster peripheral equipment, including an optical mark reader;
  • an improved commercial programming package.
• January 1968 - First shipments begin of the 1130 Models B3, C2, C3, D2 and D3.
• July 1968 - The Boca Raton plant begins shipping the 1130.
• July 22, 1971 - 1130 Models 4A and 4B are introduced at new levels of economy.
• September 1971 - First customer shipments begin of the 1130 Model 4.
• May 31, 1972 - Models 1C, 1D, 5B, 5C and 5D are announced.

Influence of the 1130

Punched card containing a self-loading 1130 program that would copy the deck of cards placed after it in the input hopper.

• Brian Utley was the 1130s Project Manager during its development and introduction. Brian said at the third 11/30 party that before IBM Marketing named the 1130 it was known as the Small Engineering Computer System or SECS. The initial architecture was 18 bits but was changed to 16 bits due to the influence of the System/360 development. The full dialogue of his 2005 presentation is available at IBM1130.org.

• Notable software designer Grady Booch got his first exposure to programming on an IBM 1130:

... I pounded the doors at the local IBM sales office until a salesman took pity on me. After we chatted for a while, he handed me a Fortran [manual]. I'm sure he gave it to me thinking, "I'll never hear from this kid again." I returned the following week saying, "This is really cool. I've read the whole thing and have written a small program. Where can I find a computer?" The fellow, to my delight, found me programming time on an IBM 1130 on weekends and late-evening hours. That was my first programming experience, and I must thank that anonymous IBM salesman for launching my career. Thank you, IBM.

• LISP guru Guy Steele wrote a LISP interpreter for the IBM 1130 when he was in high school (Boston Latin School, which had an IBM 1130 for student use). His code and documentation for LISP 1.6, along with a summary of current work in getting it to run under simulation, is available at IBM1130.org.

• Chuck Moore wanted to call his new language "Fourth" but the IBM 1130 operating system was limited to five-character names, so it wound up being called FORTH.

• Dan Bricklin creator of the VisiCalc program got his start in programming when he learned and used the IBM 1130 as part of the National Science Foundation Computer/Math Summer Project for high school students, given at the University of Pennsylvania in 1966.

• An IBM 1130 with 8 kilowords of core was used for the world's first full-time Search for Extraterrestrial Intelligence research at The Ohio State University Radio Observatory.

• Charles Goldfarb, the father of SGML, describes a job installing a typesetting system based on an IBM 1130 that "eventually changed my career", driving him towards generic markup:

The system was an IBM 1130 computer, a machine the size of a desk with 8KB of main memory, a 512KB disk drive, a Teletype CX paper tape reader and BRPE paper tape punch, and a Photon 713 photomechanical typesetter. The assignment was my first experience with managing a machine-readable document database: I learned to roll the punched paper tape carefully so that it could be stored neatly in cylindrical waste paper baskets.
In the meantime, though I didn't know about it, the roots of generalized markup were being planted. Historically, electronic manuscripts contained control codes or macros that caused the document to be formatted in a particular way ("specific coding"). In contrast, generic coding, which began in the late 1960s, uses descriptive tags (for example, "heading", rather than "format-17").

• Alan Kay used the IBM 1130 in early GUI work for his Ph.D. thesis in 1969.

Software oddities

• In an early version of the operating system, file headers written by FORTRAN and the early RPG compiler were not compatible. Before using the other language, the file had to be copied.

• The index registers were replicated in core memory at locations 1, 2 and 3. Index register 0 (IAR) was a genuine hardware register, and memory word zero usually was set to contain a BR *-1, which is to say, a jump to itself. This would trap any jump to location zero, which would surely be an error.

• The Fortran compiler built the arrays backwards in memory. Variables and arrays declared COMMON started at the highest address, and larger programs would be broken into pieces. Each separate program would choose which to invoke next according to the task's logic, and all would rely on the COMMON storage retaining data across the stages.

• A disk sector had 320 words or 640 bytes.

• There was an urban legend at the time of introduction that since it was a small scientific machine, the model number of the IBM 1130 was obtained from multiplying the model number of the IBM 360 by π.

• Another possible reason the number 1130 was chosen was that when an impasse was reached in a meeting of the product planners that had been convened to select the machine number, one of the planners mentioned that it was 11:30 and time to go to lunch. Another planner then exclaimed: “that’s it, we’ll call it the 1130”.

• Another reason for the 1130 model number was it was IBM's 11th Computer Design and it had 30 instructions hence 1130.

Instruction set overview

Main Registers:
IAR = Instruction Address Register
ACC = Accumulator
EXT = Extension Register
XRx = Index Registers x = 1,2,3

Condition indicators
+ Positive
- Negative
Z Zero
O Overflow
C Carry
E Even

1130 Instruction Set Mnemonics:
LD   = Load ACC                   STO  = Store ACC
LDD  = Load Double (ACC & EXT)    STD  = Store Double (ACC & EXT)
LDX  = Load Index                 STX  = Store Index
LDS  = Load Status                STS  = Store Status
A    = Add ACC                    AD   = Add Double
S    = Subtract ACC               SD   = Subtract Double
M    = Multiply                   D    = Divide
AND  = Boolean And                OR   = Boolean Or
XOR  = Boolean Exclusive Or
SLA  = Shift Left ACC             SLT  = Shift Left ACC & EXT
SLCA = Shift Left and Count ACC   SLC  = Shift Left and Count ACC & EXT
SRA  = Shift Right ACC            SRT  = Shift Right ACC & EXT
RTE  = Rotate Right ACC & EXT     XCH  = Exchange ACC and EXT
MDM  = Modify Memory
B    = Branch
BSC  = Branch or Skip on Condition (Modifier dependent)
       i.e. BP BNP BN BNN BZ BNZ BC BO BOD
BSI  = Branch and Store IAR
MDX  = Modify Index and Skip (Increment IAR one if a sign change or becomes zero)
WAIT = Halt                       NOP  = No Operation
XIO  = Execute I/O

1800 Additional Instruction Mnemonics:
CMP  = Compare ACC                DCM  = Double Compare ACC & EXT

Short instruction format (one 16 bit word):
                       1
Bits    0...45678......5
        OP---FTTDisp----

OP    is Operation
F     is format 0 = Short
TT    is Tag
Disp  is Displacement

Long instruction format (two 16 bit words):
                       1               1
Bits    0...456789.....50..............5
        OP---FTTIMod----Address---------

OP    is Operation
F     is format 1 = Long
TT    is Tag
I     is Indirect bit
Mod   is Modifier

Effective Address Calulation (EA):
          F = 0            | F = 1, I = 0     | F = 1, I = 1
          Direct Addressing| Direct Addressing| Indirect Addressing
-------------------------------------------------------------------
TT = 00 | EA = Displ + IAR | EA = Add         | EA = C/Add
TT = 01 | EA = Displ + XR1 | EA = Add + XR1   | EA = C/Add + XR1
TT = 10 | EA = Displ + XR2 | EA = Add + XR2   | EA = C/Add + XR2
TT = 11 | EA = Displ + XR3 | EA = Add + XR2   | EA = C/Add + XR3
-------------------------------------------------------------------
    Disp = Contents of displacement field
     Add = Contents of address field of instruction
       C = Contents of location specified by Add or Add + XR

The design did not employ a stack, neither in hardware nor in software. A subroutine SIMPL would be organised as follows:

SIMPL: DC     *-*    This is the entry point, filled with a zero initially (DC = Define Constant).
       (whatever the routine does)
       B    I SIMPL  Return by an Indirect branch, to the address found in location SIMPL.
       END    SIMPL  Instructs the assembler that the source for routine SIMPLE is complete.
       (other code)
       BSI  L SIMPL  To invoke SIMPL. L is for Long, if the destination were more than -128 or +127 words away.
       (more code)

Thus the BSI (or CALL) would store at address SIMPL the current value of IAR which would thereby be the return address. The initial value there would be zero, since "*" represents the current address during assembly so that *-* evaluates to zero but is visually distinct. Without extra arrangements to protect the return address, recursion would be impossible (if SIMPL invoked itself or a routine that invoked it, its original return address would be overwritten) and re-entrancy is precluded also for the same reason. Thus, a routine invoked during the processing of an interrupt must not invoke any routine that could have been interrupted. Additional conventions attended parameters, which might follow the BSI instruction either as values or as addresses of values, etc. Routine SIMPL might modify its return address value while accessing those parameters, and would certainly have to increment the value by the correct number of words so that the return would be to the address following the parameters.

By convention, library routines were invoked via index register three. This register would point at a series of entry point addresses, so that a particular routine would be a small offset into that table, thereby enabling the one-word instruction format to be used. Since floating-point arithmetic was performed by software, there would be many invocations of such routines. This protocol is hidden in the assembler source code example by the usage of LIBF. Fortran programs would only ever use index register one, so that register two was unused.

The convention of having a zero as the initial value at the entry point meant that if alas a return was made through the value of an entry point that had not been entered through, execution would jump to location zero of memory, which contained a jump to itself so as to entrap such mistakes.

Programming Examples

The examples can be executed on the IBM 1130 emulator available at IBM 1130.org.

Sample Assembler program deck

The following listing shows a card deck that compiles and runs an Assembler program that lists a deck of cards to the line printer.
The following code Copyright (c) 2006 Kym Farnik. Code published under MIT license. See: http://www.opensource.org/licenses/mit-license.php

 // JOB 
 // ASM
 *LIST
                     * LCARD.ASM - LIST A DECK OF CARDS TO LINE PRINTER
                     *
                     * COPYRIGHT (C) 2006 KYM FARNIK. 
                     * CODE PUBLISHED UNDER MIT LICENSE. 
                     *
                     * PROGRAM
                     *    NEW PAGE ON PRINTER
                     * A  READ A CARD
                     *    CONVERT FORMAT
                     *    PRINT A LINE ON PRINTER
                     *    GOTO A
                     *
                     START LIBF    PRNT1    GOTO NEW PAGE ON 1132
                           DC      /3100    PRINTER CHANNEL 1-NEW PAGE
                     *
                     NEXTC LIBF    CARD0    READ FROM 1442 CARD READER
                           DC      /1000    CONTROL TO READ
                           DC      CBUFF    STORE 80 COLUMNS
                     CINP  LIBF    CARD0
                           DC      0
                           B       CINP     LOOP UNTIL CARD IS READ
                     *
                           LIBF    ZIPCO    CONVERT CARD TO PRINTER
                           DC      /1100    UNPACKED IN, PACKED OUT
                           DC      CBUFF+1  INPUT BUFFER
                           DC      PBUFF+1  OUTPUT BUFFER
                           DC      80       CHARACTER COUNT
                           CALL    HLEBC    HOLLERITH TO EBCDIC
                     *
                           LIBF    PRNT1    PRINT 80 CHARACTERS
                           DC      /2000    CONTROL CODE TO PRINT
                           DC      PBUFF    PRINT BUFFER
                           DC      PERR     PRINT ERROR
                     POUT  LIBF    PRNT1    CHECK FOR PRINT COMPLETE
                           DC      0
                           B       POUT     LOOP UNTIL COMPLETE
                     *
                           B       NEXTC    READ NEXT CARD
                     *
                     * DATA
                     *
                     CBUFF DC      80       80 COLUMNS PER CARD
                           BSS     80
                     *
                     PBUFF DC      40       40 WORDS 80 CHARACTERS
                           BSS     40
                     *
                     PERR  DC      0
                           B    I  PERR     THIS RETURNS TO THE
                     *                       PRINTER ERROR HANDLER
                     *                       WHICH WILL TERMINATE THE PROGRAM
                     *
                           END     START    PROGRAM ENTRY POINT
 // XEQ
 TEST DATA 1
 HELLO WORLD
 TEST DATA 2

In this job, the assembler leaves the result of its assembly in the temporary area of the system disc, and the XEQ command executes the content of the temporary area. The odd-looking "END START" has two meanings: end of assembler source, and the name of the entry point of the routine, which has the label START. Assembler source starts with column 21 of the card, not column one. In systems without a disc drive, the assembler would punch code into the start of the card just read (the card reader was actually a reader-punch, with the punch station after the read station) and then read the next card. To handle forward branches and the like, the assembler's second pass literally involved a second pass of the cards through the reader/punch. And should you need to change the source deck, you would have to duplicate the cards to obtain a deck with blanks at the start ready for the next try through the assembler.

The assembler I/O routines are typically asynchronous: the command to read a card initiates that operation and control is returned at once to the calling routine which can proceed with other activity. In this example there is no attempt at overlapping input and output with double or multi-buffering; the routine simply loops to CIMP until such time the query to CARD0 determines that the operation has been completed (which the reader had signalled via an interrupt, recognised by CARD0) and returns one word further on, thus hopping the jump back to CIMP.

The convention for buffers is that there be a word count, followed by that number of words of storage - thus the BSS 80 reserves eighty words of storage. The card buffer requires eighty words of storage, because the card reader reads the hole pattern as-is, there being twelve rows for holes or not for each of the eighty columns of the card. Thus each sixteen-bit word holds a twelve-bit sequence with ones for each hole in that column. The library routine ZIPCO packs two twelve-bit patterns into one word, but still using the card reader encodement. The console keyboard also generates twelve-bit patterns, just as if it were a card punch: this is called Hollerith code. The printer however requires EBCDIC encodements, thus the conversion from Hollerith to EBCDIC via HLEBC [except, I don't see any parameters!] after which the output area is ready for presentation to the printer, and again, the routine loops until the printer driver reports "complete" whereupon the next card is requested. This example contains no testing to determine when to stop, which would be decided by the operator instead as the card reader was being supplied with additional handfulls of cards. A more polite routine would check whether the card just read started with //, as would mark the start of the next job's deck. Such checking would have to be done at the right stage in the sequence of code conversions!

This sequential style of input and output is simple, and now usual on modern computers (certainly in DOS-derived systems), but would be unable to run the I/O devices at their best speed. The card reader in particular required close attention: only a few milliseconds after it reports "operation complete" on reading a card it will commence the card reader stop sequence, after which a new read command will have to wait to initiate another read cycle. Thus, the IBM 1402 reader could read 400 cards/minute at full speed, but, with just a little hesitancy in the read commands, its throughput dropped to 200/minute and then slower speeds still. A Fortran program could not complete even the simplest input processing in time, and so was condemned to wait for the reader's slower rate. With buffering, the card reader control could be overlapped with processing, so that the entire 150 millisecond interval between reading cards was available for processing, not just a few crucial milliseconds after each card, and the reader could be run at full speed through large data decks. But the extra complexity and buffer areas required memory, and this was often at a premium. There was a hierarchy of device drivers: those ending in Z were for Fortran, thus DISKZ, while assembler programmers might use DISK0, and DISK1 provided superior performance again when reading multiple disc sectors. But one had to attend to details: DISCZ started its sector addressing with the first available unused sector, the others started with sector zero of the disc. A "read" would obtain the bootstrap loader, and a write...

Sample Fortran IV program deck

The following listing shows a card deck that compiles and runs a Fortran program and Fortran subroutine for the IBM 1130 when running DM2.
The following code Copyright (c) 2005 Kym Farnik. Code published under MIT license. See: http://www.opensource.org/licenses/mit-license.php

 // JOB 
 // FOR
 *LIST SOURCE PROGRAM
 *ONE WORD INTEGERS
 C-------------------------------------------------------   
 C COMPUTE THE CRITICAL VALUES FOR A QUADRATIC EQN
 C 0=A*X**2+B*X+C
 C RETURNS DISCRIMINANT, ROOTS, VERTEX, FOCAL LENGTH, FOCAL POINT
 C X1 AND X2 ARE THE ROOTS
 C-------------------------------------------------------   
       SUBROUTINE QUADR(A,B,C,DISCR,X1,X2,VX,VY,FL,FPY)
       REAL A,B,C,DISCR,X1,X2,VX,VY,FL,FPY

 C DISCRIMINANT, VERTEX, FOCAL LENGTH, FOCAL POINT Y
       DISCR = B**2.0 - 4.0*A*C
       VX = -B / (2.0*A)
       VY = A*VX**2.0 + B*VX + C
       FL = 1.0 / (A * 4.0)
       FPY = VY + FL
       FL = ABS(FL)

 C COMPUTE THE ROOTS BASED ON THE DISCRIMINANT
       IF(DISCR) 110,120,130

 C -VE DISCRIMINANT, TWO COMPLEX ROOTS, REAL=X1, IMG=+/-X2
 110   X1 = -B / (2.0*A)
       X2 = SQRT(-DISCR) / (2.0*A)
       RETURN
       
 C ZERO DISCRIMINANT, ONE REAL ROOT
 120   X1 = -B / (2.0*A)
       X2 = X1
       RETURN 

 C +VE DISCRIMINANT, TWO REAL ROOTS
 130   X1 = (-B + SQRT(DISCR)) / (2.0*A)
       X2 = (-B - SQRT(DISCR)) / (2.0*A)
       RETURN
 C
 C NEXT STORE SUBROUTINE ON DISK USING DUP
       END
 // DUP
 *DELETE             QUADR
 *STORE      WS  UA  QUADR
 // JOB
 // FOR
 *LIST SOURCE PROGRAM   
 *IOCS(CARD,1132 PRINTER)   
 *ONE WORD INTEGERS   
 C-------------------------------------------------------   
 C PROCESS DATA CARDS WITH A,B,C
 C UNTIL A=0
 C-------------------------------------------------------   

       DATA ICARD,IPRT /2,3/
       REAL A,B,C
       REAL DISCR,XR1,XR2,VX,VY,FL,FPY

       WRITE(IPRT,901)
 901   FORMAT(' ------------------------------------------------------')

 C READ A B C, IF A=0 THEN EXIT
 100   READ(ICARD,801)A,B,C
 801   FORMAT(3F8.3)

 C     EXIT WHEN A IS ZERO
       IF (A) 110,9000,110

 C PRINT A B C 
 110   WRITE(IPRT,902)A,B,C
 902   FORMAT(' QUADRATIC A=',F8.3,' B=',F8.3,' C=',F8.3)

 C COMPUTE AND PRINT THE CRITICAL VALUES
       CALL QUADR(A,B,C,DISCR,XR1,XR2,VX,VY,FL,FPY)
       WRITE(IPRT,903) DISCR
 903   FORMAT(' DISCRIMINANT=',F9.4)
       WRITE(IPRT,904) VX,VY
 904   FORMAT(' VERTEX X=',F9.4,'  Y=',F9.4)
       WRITE(IPRT,905) FL
 905   FORMAT(' FOCAL LENGTH=',F9.4)
       WRITE(IPRT,906) VX,FPY
 906   FORMAT(' FOCAL POINT X=',F9.4,'  Y='F9.4)

       IF (DISCR) 120,130,140

 C -VE DISCRIMINANT, TWO COMPLEX ROOTS
 120   WRITE(IPRT,913) XR1, XR2
 913   FORMAT(' COMPLEX ROOTS =(',F9.4,'  +/-',F9.4,'I)')
       GO TO 200
       
 C ZERO DISCRIMINANT, ONE REAL ROOT
 130   WRITE(IPRT,912) XR1
 912   FORMAT(' ROOT  X =',F9.4)
       GO TO 200

 C +VE DISCRIMINANT, TWO REAL ROOTS
 140   WRITE(IPRT,911) XR1, XR2
 911   FORMAT(' ROOTS X1=',F9.4,'   X2=',F9.4)
 C --- GO TO 200

 C END OF QUAD
 200   WRITE(IPRT,901)
       GO TO 100

 C END OF PROGRAM
 C DATA FOLLOWS XEQ CARD
 9000  CALL EXIT   
       END   
 // XEQ
 +001.000+000.000+000.000
 +001.000+002.000+003.000
 +002.000+002.000+000.000
 +002.000+000.000-004.000
 +000.500+000.000-004.000
 +000.250+002.000-002.000
 -004.000+000.000-004.000
 +002.730-007.200-003.750
 +000.000+000.000+000.000

Sample APL \ 1130 session

The following image shows a simple APL \ 1130 session. This session was performed via the 1130 simulator available from IBM 1130.org

The above session shows a signon, addition of the integers 1 to 100, generation of an addition table for the integers 1..5 and a sign off.

See also

• IBM mainframe
• List of IBM products

External links

• IBM Archive: IBM 1130 press releases, chronology, photos, facts folder.
• IBM 1130.org Norm Aleks and Brian Knittel site which has significant information about the 1130 and a downloadable simulator that supports the DMS R2V12 and APL environments.
• www.ibm1130.net is Howard Shubs' site dedicated to the 1130.
• Arnold Reinhold's personal account of the 1130. Text from here has been incorporated into this article with permission
• A set of PDFs made up of scanned IBM 1130 manuals
• Kym Farnik's page on Retro Computing specifically the 1130
• A discussion about the (then) Angle Park computing centre which was equipped with IBM 1130's
• Bob Rosenbloom's IBM 1130 Photos
• IBM 1130 material at Columbia University, Computing History site.