IBM 1130
| Company type | Computer system |
|---|---|
| Industry | Computer hardware |
| Predecessor | IBM 1620 |
| Founded | 1965 |
| Successor | IBM 1800 |
| Products | 16-bit binary computer system, disk storage, printers, programming languages support |
| Parent | IBM |
The IBM 1130 Computing System, launched in 1965, represented IBM's most affordable computer offering at that time. This 16-bit binary machine was designed to meet the needs of cost-conscious, computation-heavy technical sectors like education and engineering, effectively replacing the decimal-based IBM 1620 in this market niche. Typical configurations included a 1 megabyte disk drive for storing the operating system, compilers, and object files, while source programs were kept on punched cards. The primary programming language was Fortran, with additional support for languages such as APL.
Additionally, the 1130 functioned as an intelligent front-end processor for the IBM 2250 Graphics Display Unit or as a remote job entry (RJE) terminal connected to a System/360 mainframe.
Description
Approximately 10,000 units of the IBM 1130 were manufactured. This system is notable for making computing accessible by delivering a strong price-to-performance ratio, featuring economical removable disk storage and software available in various high-level languages. Its price started near $32,000 ($41,000 including the disk drive), offering a well-rounded platform conducive to interactive "open shop" program development environments.
The IBM 1130 utilized the same Solid Logic Technology (SLT) electronics modules found in the System/360, incorporating a 16-bit binary architecture akin to subsequent minicomputer designs such as the PDP-11 and Data General Nova. With a 15-bit address space, its memory was capped at words (), employing magnetic-core memory accessed on word boundaries through direct, indirect, and indexed addressing modes.
Models
IBM released five variants of the 1131 Central Processing Unit, distinguished by core memory cycle times and disk storage options. The suffix letters (A–D) denote the amount of core memory installed.
The IBM 1131 CPU weighs roughly 760 lb (345 kg) for models 1A, 1B, 2A, 2B, 4A, and 4B; other models weigh about 1050 lb (477 kg).
| Memory cycle time | |||||
|---|---|---|---|---|---|
| Core memory | 3.6 μs, no internal disk |
3.6 μs, plus disks |
2.2 μs, plus disks |
5.9 μs (3.6 μs: see below), single disk |
2.2 μs, no internal disk |
| 4096 words | Model 1A | Model 2A | — | Model 4A | — |
| 8192 words | Model 1B | Model 2B | Model 3B | Model 4B | Model 5B |
| 16,384 words | Model 1C | Model 2C | Model 3C | — | Model 5C |
| 32,768 words | Model 1D | Model 2D | Model 3D | — | Model 5D |
Model 4 presented a budget-friendly alternative with a slower core memory cycle of 5.9 μs but could accelerate to a faster rate of 3.6 μs during specific high-level interrupts through simple field modifications, thereby improving performance unexpectedly.
The IBM 1132 printer relies on CPU timing for print wheel activation rather than built-in logic circuits. When paired with Model 4 CPUs, printers operate at reduced speeds due to processor limitations; however, during critical interrupts—such as level 0 card-reader or level 1 printer interrupts—the CPU temporarily switches to the faster cycle time of 3.6 μs. Some operators exploited this behavior by creating custom printer drivers that maintained elevated processor speeds but at the cost of disabling lower-priority interrupts momentarily, which impacted responsiveness of devices like the card reader’s end-of-card signal (level 4).
Subsequent models
Introduced in November 1964, the IBM 1800 represents a specialized version of the IBM 1130, designed specifically for process control tasks. This model incorporates hardware index registers, adds two new instructions (CMP and DCM), and offers improved interrupt handling alongside enhanced I/O functionality. The IBM 1800 followed the IBM 1710, just as the IBM 1130 was the successor to the IBM 1620.
The IBM 1500 system serves as a multi-user educational platform, built around either an IBM 1130 or IBM 1800 core. It supports up to 32 individual student terminals and integrates various audio-visual components.
Beyond these systems, IBM did not develop further compatible successors to the 1130. Although the IBM System/7 and IBM Series/1 are minicomputers aimed at process control and general-purpose use respectively, their architectures differ significantly from that of the 1130.
Timeline
- February 11, 1965 – IBM launches the 1130 (Models 1A, 1B, 2A, and 2B) along with the IBM 1132 printer, which was IBM's most affordable online computer printer at that time.
- Fourth quarter of 1965 – Initial customer deliveries from the San Jose manufacturing facility.
- March 31, 1966 – Debut of the IBM 1500 educational system.
- April 1966 – Release of the IBM 1800.
- August 9, 1966 – Introduction of the synchronous communications adapter for the 1130, enabling leased-line connections to any IBM System/360 model.
- April 17, 1967 – Announcement of a four-model expansion for the 1130 (Models 2C, 2D, 3B, 3C, and 3D) featuring:
- A fivefold increase in disk capacity and quadrupled core memory;
- Processing speeds improved by nearly 40%;
- Upgraded peripherals including an optical mark reader;
- Enhanced commercial software packages.
- January 1968 – Commencement of shipments for expanded models (2C, 2D, 3B, 3C, and 3D).
- July 1968 – Production begins at the Boca Raton plant.
- July 22, 1971 – Release of cost-effective Models 4A and 4B.
- September 1971 – First customer shipments of Model 4.
- May 31, 1972 – Announcement of Models 1C, 1D, 5B, 5C, and 5D.
- In 1973 – The Xerox 530 was marketed as a potential replacement for IBM’s customer base; initial orders were described as "encouraging" by early the following year.
Software
To achieve high performance while minimizing memory usage, both the operating system and compilers were written entirely in assembly language, employing methods such as interleaving code with data and implementing self-modifying code.
Most programming by users was conducted in Fortran. The Fortran compiler for the IBM 1130 operates on systems with as little as 4,096 words of core memory; however, compiled programs could require more. This multi-pass compiler processes source code through several stages to generate executable machine code. For instance, its initial phase reads source lines to eliminate comments and extraneous spaces outside string literals, merges continuation lines, and identifies labels. The compiler was distributed on disk, punched paper tape, or punched cards.
The predominant operating system is Disk Monitor System Version 2 (DM2), released in 1967. DM2 is a single-tasking batch OS that requires a minimum of four kilobytes of core memory plus one integrated model 2310 disk drive. Its compact Supervisor includes first-level interrupt handlers, disk drivers, and interpreters for job control commands. Device drivers for additional I/O peripherals are loaded per job execution and can replace the basic disk driver with more advanced versions. While a job runs, only a minimal Skeleton Supervisor—approximately one kilobyte—remains resident to maximize CPU availability for user tasks. Upon job completion or cancellation, control transfers to the Monitor Control Record Analyzer (MCRA) to prepare for subsequent jobs. Additional utilities include a core dump tool (DUMP) and Disk Utility Program (DUP).
For configurations without disk drives, a Card/Paper Tape Programming System was available.
Device drivers follow a naming hierarchy: those ending with Z (e.g., DISKZ) are intended for Fortran use; assembly programmers might prefer DISK0 or the faster DISK1 versions. DISKZ drivers begin addressing from the first free sector on disk; others start at sector zero but risk overwriting bootstrap loaders if used improperly.
Other programming languages supported on this system include:
A French-language version of an ALGOL compiler substituted standard keywords like "Begin ... End;" with French equivalents "Debut ... Fin;", and all compiler messages were presented in French.
Eastern Michigan University developed Fortran-EMU—an enhanced Fortran IV compiler providing additional capabilities not supported by IBM’s version such as LOGICAL data types and six-character variable names. This compiler was distributed via punched cards within a restricted disk image format designed to prevent unauthorized copying of other modules.
Oklahoma State University produced an ALGOL 68 compiler implemented in ANSI Fortran from the year 1966.
The University of Michigan created an interpreter for the FOCAL language.
IBM also offered an extensive software library including both supported (Type I and II) and unsupported (Type III and IV) programs.
Primarily aimed at scientific users, the IBM 1130 featured numerous specialized programs such as:
- Scientific Subroutine Package
- Drawing and Plotting Subroutines
- Electric Power System Load Flow Analysis
- Multiple Regression Analysis
- Electrical Distribution Fault Current Calculations
- Pipe Stress Analysis
- COGO coordinate geometry routines
- Continuous System Modeling Program (CSMP III)
- Linear Programming Optimization Subroutine System
- Structural Engineering Solver (STRESS)
- Statistical Analysis System
Additionally, it served smaller enterprises with data processing solutions like:
- Commercial Subroutine Package for the IBM 1130
- Student Information Management System
- Critical Path Method/Program Evaluation Review Technique (CPM/PERT)
Specialized applications also included:
- Remote Job Entry (RJE)
- Typesetting software
Job control
Batch processing on the 1130 is governed by control records embedded within the primary input stream, whether from card or paper tape readers. These records fall into two categories: monitor control records and supervisor control records.
Monitor control records
Monitor control records begin with //␢, where "␢" denotes a space, followed by a pseudo-operation code in columns 4 through 7.
| Control record | Purpose |
|---|---|
//␢* comments |
Comments that appear in the job listing (columns 5–80) |
//␢JOB |
Indicates the commencement of a job |
//␢ASM |
Calls the Assembler |
//␢FOR |
Initiates the FORTRAN compiler |
//␢PAUS |
Halts system operation until the console START key is pressed |
//␢TYP |
Redirects output/input between printer and console |
//␢TEND |
Reverses the effect of //␢TYP
|
//␢DUP |
Launches the Disk Utility Program |
//␢XEQ |
Loads and transfers control to a main program |
The JOB record may include a "T" in column 8, signifying that any files created during the job will be deleted once it concludes. Additionally, columns 11 to 15 can specify a cartridge label, which is verified prior to execution.
For the XEQ record, columns 8 through 12 may specify the program name to be executed; if left blank, the program residing in Working Storage is run. Placing an "L" in column 14 prompts printing of a core map when using Disk System Format. Following Supervisor Control Records such as LOCAL, NOCAL, or FILES include counts in columns 16 and 17. Column 19 optionally selects the disk driver routine: "0", "1", or "N" correspond to DISK1, DISK2, or DISKN respectively; any other character defaults to DISKZ (the FORTRAN disk routine).
Supervisor control records
Supervisor control records commence with an asterisk (*) in column 1, followed by a command character in column 2. Principal commands include *LOCAL, *NOCAL, and *FILES, which regulate program linking for use with the // XEQ statement or DUP commands.
| Control record | Description |
|---|---|
*LOCAL |
Enumerates subprograms loaded as overlays during runtime rather than linked with the main program |
*NOCAL |
Specifies subprograms linked into the main program but never invoked—commonly used for debugging or interrupt handlers |
*FILES |
Associates File Identification Numbers from FORTRAN or Assembler source with named disk files |
Operating procedure
The IBM 1130 required constant operator involvement, typically executing "jobs" defined by decks of punched cards. Operators fed jobs into the card reader and separated completed jobs to return them along with printed results. They also observed system status to detect stalled jobs and could press the key to advance to subsequent jobs.
Jobs were initiated by a punched card starting with // JOB. Cards beginning with // represented Supervisor commands rather than user data. Examples include // DUP, which runs the Disk Utility Program for file management, and // XEQ, which executes programs stored on disk. When a user program attempts to read a command card, the reader signals end-of-input and retains that card for Supervisor processing.
- Initial Program Load (IPL)
Unlike IBM System/360 models, the IBM 1130 boots (IPL's) exclusively from external devices such as card readers or paper tape readers. The bootstrap process reads a single card containing binary code that loads sector zero of the disk drive; this sector then handles interrupts and prepares the system for punched-card job processing. This boot sequence typically completes within approximately one second.
- Recovery procedures
During startup, the Supervisor remains resident in core memory, which preserves its state even without power. If a user program becomes unresponsive, the Supervisor can terminate it and proceed to the next job card. However, there is no safeguard preventing corruptions of Supervisor code or erroneous disk writes caused by malfunctioning programs, occasionally necessitating a full system reboot. System software stored on disk can be restored by reloading roughly 4,000 binary-coded punched cards (equivalent to about two boxes).
Disk Structure
The IBM 2310 disk drive organizes data into sectors containing 320 words (640 bytes) plus an additional single word for the sector address. A cylinder is formed by two tracks located on the upper and lower surfaces of the 2315 drive, or alternatively, on the top and bottom surfaces of each of the six platters (excluding the outermost surfaces) within the 1316 disk pack utilized by the 2311. Each cylinder comprises eight sectors per surface, each accessed by its own dedicated read-write head. These sectors are logically segmented into sixteen disk blocks, each consisting of 20 words (40 bytes), which function as the fundamental unit for file allocation.
The system distinguishes between system cartridges, which contain the monitor, utility programs, and user data, and nonsystem cartridges, which store only user data. Regardless of type, all cartridges include information in cylinder 0 such as the defective cylinder table, cartridge identification, and bootstrap code. When booted from a nonsystem cartridge, the bootstrap program generates an error message; however, on system cartridges, it initiates the cold-start routine followed by loading a communications area and the resident monitor. The System Location Equivalence Table (SLET), located in sectors three through five, serves as a directory for all phases of the monitor program, with other control information occupying the remainder of the first track.
System cartridges contain the Disk Monitor software and may optionally include additional utilities such as a FORTRAN compiler, an Assembler, and a core image buffer designed for linking relocatable programs. They also maintain user file directories known as the Fixed Location Equivalence Table (FLET) and Location Equivalence Table (LET).
Beyond these system-reserved sections, cartridges are divided into up to three logical areas: fixed area, user area, and working storage. The fixed area’s size is determined by DUP commands and stores programs or data in core image format; files here are not repacked upon deletion. The user area accommodates programs and data in any format; its boundary with working storage is dynamic, expanding or contracting depending on file additions or deletions. Typically, when files are updated, the previous version is deleted via DUP to free space before saving a new version under the same filename. Files that undergo infrequent changes tend to be positioned near the beginning of the disk, whereas those modified frequently remain closer to the end.
Following the user area is working storage, which occupies any leftover space on the cartridge and holds a single temporary file created by either system or user operations—such as compiler outputs—which may be erased after job completion unless explicitly saved elsewhere.
All files on disk are stored as contiguous blocks to prevent fragmentation. While programs have permission to modify named files, they cannot increase their size beyond what was originally allocated; therefore, multiple files must be pre-allocated using DUP.
Because disk capacity is limited, source code is often maintained as card decks. Users with greater storage requirements might keep personal disks containing their own files along with a copy of the operating system, substituting these for the shared system disk during execution. Systems equipped with a second dedicated disk drive provide enhanced storage options for individual users.
Disk Monitor System version 1 performs disk initialization through the Disk Pack Initialization Routine (DPIR), which scans disks to write sector addresses, mark defective cylinders, and assign cartridge IDs within cylinder zero. DPIR operates as a standalone program loaded from cards or paper tape and allows cartridge ID input via the console.
Version 2 employs the Disk Cartridge Initialization Program (DCIP), extending capabilities to include copying, dumping, patching, analyzing, and comparing disks.
Disk Utility Program (DUP)
The Disk Utility Program (DUP) oversees the transfer of programs, subroutines, and data. It is activated through the job control statement // DUP, followed by various control cards:
| Command | Description |
|---|---|
| *STORE | Save a program in Disk System Format (relocatable object) |
| *STORECI | Save a program in Core Image Format (fully linked and relocated) |
| *STOREDATA | Save a data file onto disk |
| *STOREDATACI | Reload a dumped core image program |
| *STOREMOD | Create or update a disk file |
| *DUMP | Extract a data file from disk |
| *DUMPDATA | Extract arbitrary disk sectors |
| *DUMPLET | Display the disk Location Equivalence Table (LET) and Fixed Location Equivalence Table (FLET), if available |
| *DELETE | Remove a program or data file |
Additional commands enable system operators to manage the Fixed Area, uninstall compilers or assemblers, and restore sector addresses.
Operands must be entered in fixed columns: source device codes occupy columns 13–14, while destination codes are in columns 17–18. Recognized device codes include:
- UA – User Area
- FX – Fixed Area (contiguous disk space)
- WS – Working Storage
- CD – Punched Card or primary input device (or PT for Paper Tape)
- PR – Printer
Depending on the DUP function, program names and count fields are specified within columns 21–25 and 27–30.
The STORECI command transforms programs into the Core Image Format using the Core Image Builder, which enables faster loading by linking less frequently used programs at runtime, thereby optimizing disk usage.
For instance, DUP can transfer contents from working storage to user area storage by naming the target file; it automatically adjusts storage allocations to accommodate this transfer.
Peripheral devices
Disk storage holds the operating system, object code, and data files, while source code remains on punched cards.
The IBM 1130 system was equipped with the IBM 2310 disk drive featuring a voice-coil actuator ("Ramkit") developed by IBM's General Products Division. Its IBM 2315 cartridges contain a single platter with a capacity of 512,000 words (roughly 1MB), transferring data at rates up to 35,000 words per second (70 KB/sec) using cycle stealing.
The IBM 1053 console typewriter incorporates an IBM Selectric mechanism that allows for interchangeable type elements, including a specialized element designed for APL programming. The console also features a set of 16 toggle switches that can be read programmatically for input control.
Available peripheral devices included:
- Printers – IBM 1132 (40–80 lines per minute) and IBM 1403 line printers (340–600 lines per minute)
- Punched-card – IBM 1442 card reader/punch and IBM 2501 card reader
- Paper tape – IBM 1055 punch, IBM 1054 reader, and IBM 1134 reader
- Disk – IBM 2311 Disk Drive
- Magnetic tape – Beginning in 1968, IBM 2415 tape drives offered as RPQ
- Graphics – IBM 2250 Graphic Display Unit
- Color Pen Plotter – IBM 1627 drum plotter
- Optical Mark Reader – IBM 1231 Optical Mark Page Reader
- Communications – Synchronous Communications Adapter (SCA); starting in 1970, the MTCA supported up to four IBM 2741 terminals for APL usage
To reduce complexity and cost, peripherals depend extensively on CPU processing. For example, the card reader issues high-priority interrupts for each column read; if these interrupts are not serviced promptly, data loss occurs. Likewise, the IBM 1132 printer relies on CPU software to construct print bitmaps in real time to sustain printing speed.
Peripheral units handle device-specific codes that the CPU converts to or from EBCDIC during processing.
Instruction Set Summary
The instruction set utilizes both concise (single-word) and extended (two-word) instruction formats. Most operations involving computation, loading, and storing reference a single register, typically the accumulator (ACC), along with a memory address. In the short format, this memory address is specified by an 8-bit signed displacement relative to the current instruction address or through an index register; the long format uses a complete 15-bit address which may include indexing and indirect addressing. Memory addressing is performed in word units.
The IBM 1130 inherently supports binary data in single-precision (16-bit) and double-precision (32-bit) forms, stored using big-endian byte order. Floating-point numbers in both standard (32-bit) and extended (48-bit) precision, as well as decimal data types, are handled through software subroutines.
Conditional branching depends on either the state of the accumulator or status flags such as carry and overflow set by previous instructions. Control transfer can be executed via a skip operation—which assumes the following instruction is short—or a branch. A skip occurs if any of the specified conditions are satisfied; otherwise, a branch takes place.
Primary Registers:
IAR = Instruction Address Register
ACC = Accumulator
EXT = Extension Register
XRx = Index Registers: x = 1,2,3
These are implemented as memory locations 1, 2, and 3 rather than dedicated hardware registers.
Condition Codes:
Z Accumulator equals zero
- Accumulator negative
+ Accumulator positive
E Accumulator even
C Carry flag cleared
O Overflow flag cleared
1130 Instruction 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 to ACC AD = Add Double
S = Subtract from 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
BSC = Branch or Skip on Condition (modifier dependent)
Examples: BP BNP BN BNN BZ BNZ BC BO BOD
BOSC - Branch Out or Skip Conditionally (alternative to BSC with bit 9 set)
Used to exit current interrupt level.
BSI = Branch and Store IAR
MDX = Modify Index and Skip (increments IAR by one if sign changes or zero encountered)
WAIT = Halt NOP = No Operation (alternative for SLA with zero)
XIO = Execute I/O
Additional Instructions for Model 1800:
CMP = Compare ACC DCM = Double Compare ACC & EXT
Equivalent Mnemonics:
SKP - Skip on condition, synonymous with short BSC
B - Unconditional branch, equivalent to BSC without conditions
BP - Branch if Accumulator Positive (+)
BNP - Branch if Accumulator Not Positive
BN - Branch if Accumulator Negative (-)
BNN - Branch if Accumulator Not Negative
BZ - Branch if Accumulator Zero (Z)
BNZ - Branch if Accumulator Not Zero
BC - Branch on Carry flag set/cleared condition
BO - Branch on Overflow flag set/cleared condition
BOD - Branch if Accumulator Odd (odd parity)
MDM - Modify Memory, equivalent to unindexed long-format MDX
XCH - Exchange ACC and EXT registers, same as RTE with count of 16
Short Instruction Format (one word of sixteen bits):
Bit Position
Bits 0...45678......5
OP---FTTDisp----
OP Operation code identifier
F Format bit: 0 for short format
TT Tag field indicating addressing mode
Disp Displacement value
Long Instruction Format (two words of sixteen bits each):
Bit Position
Bits 0...456789.....50..............5
OP---FTTIMod----Address---------
OP Operation code identifier
F Format bit: 1 for long format
TT Tag field indicating addressing mode
I Indirect addressing bit
Mod Modifier bits
Effective Address Computation (EA):
F=0 | F=1,I=0 | F=1,I=1
Direct Addr | Direct Addr | Indirect Addr
-------------------------------------------------------------------
TT=00 | EA=Disp+IAR | EA=Add | EA=C+Add
TT=01 | EA=Disp+XR1 | EA=Add+XR1 | EA=C+Add+XR1
TT=10 | EA=Disp+XR2 | EA=Add+XR2 | EA=C+Add+XR2
TT=11 | EA=Disp+XR3 | EA=Add+XR3 | EA=C+Add+XR3
-------------------------------------------------------------------
Disp=Displacement field content
Add=Address field content
C=Contents at Add or Add plus XR
| 15 | 14 | 13 | 12 | 11 | 10 | 09 | 08 | 07 | 06 | 05 | 04 | 03 | 02 | 01 | 00 | |
| Accumulator | ||||||||||||||||
| ACC | Accumulator | |||||||||||||||
| Q | Extension | |||||||||||||||
| Index Registers | ||||||||||||||||
| IAR | Instruction Address | |||||||||||||||
| XR1 | Index Register One | |||||||||||||||
| XR2 | Index Register Two | |||||||||||||||
| XR3 | Index Register Three | |||||||||||||||
| Status Flags | ||||||||||||||||
| "O" | "C" | |||||||||||||||
- Designated Memory Regions
Specific low memory locations are allocated for hardware-related or conventional purposes:
| Address | Function |
|---|---|
| /0000 | Traditionally holds an infinite loop instruction (B *-1) serving as a trap until operator intervention.
|
| /0001 | Location of XR1 index register; facilitates direct data transfer among index registers. |
| /0002 | Location of XR2 index register. |
| /0003 | Location of XR3 index register. |
| /0008 | Interrupt handler address for Level 0—1442 card reader/punch "column ready" signal. |
| /0009 | Interrupt handler address for Level 1—1132 printer and communications adapter. |
| /000A=10 | Interrupt handler address for Level 2—disk storage channel. |
| /000B=11 | Interrupt handler address for Level 3—1627 plotter channel. |
| /000C=12 | Interrupt handler address for Level 4—paper tape devices, console, card readers/punches, printers, optical mark reader. |
| /000D=13 | Interrupt handler address for Level 5—console stop/interruption switches. |
| /0020=32 | Beginning of scan field for IBM1132 printer (/0020–/0027). |
| /0026=38 | Endpoint of full word scan field. |
| /0027=39 | Partial word scan range covering printer columns. |
| /0038=56 | Entry point for EXIT to Supervisor / Return to Monitor routines. |
Subprograms
The 1130 system does not incorporate built-in hardware support for a stack. Instead, most subprograms employ the BSI (Branch and Store IAR) instruction, which saves the return address (IAR) at the target location and transfers control to the subsequent address (destination+1). Returning from the subprogram is accomplished by performing an indirect branch through this stored return address. This technique of embedding the return address directly in code was also prevalent in contemporary machines such as the Hewlett-Packard HP 2100, DEC PDP-8, and Scientific Data Systems SDS 920.
A typical subprogram, for instance SIMPL, might be organized in this manner:
SIMPL: DC *-* Entry point initialized to zero.
(subroutine instructions)
B I SIMPL Return via indirect branch through SIMPL.
END SIMPL Denotes end of the subprogram.
To invoke SIMPL, calls use:
BSI L SIMPL Call to SIMPL; 'L' is required if target is beyond ±127 words.
The CALL pseudo-opcode generally abstracts this call mechanism. At assembly time, the entry point is defined with the pseudo-op DC *-*, which sets a constant zero that serves as a placeholder for the return address at runtime. The entry point need not be the initial word of the routine; preceding instructions can be placed before it, allowing returns by branching to SIMPL-1.
When executed, BSI replaces *-* with the current IAR (the instruction immediately following BSI). The subprogram runs and returns by branching indirectly through SIMPL, resuming execution immediately after the original call.
This method prohibits recursion and complicates reentrancy since recursive invocations overwrite the stored return address. Additionally, interrupt service routines must avoid invoking subprograms that were interrupted.
Parameters can be transmitted inline following BSI or passed via index registers XR1 and XR2. When passing inline parameters, it is necessary to adjust the return address so that the indirect branch bypasses them. Single-integer functions typically utilize the accumulator for both input and output values; floating-point functions employ a dedicated floating-point accumulator area.
By coding zero at the entry point, if a subprogram returns without having been called, execution will jump to location zero. Usually, location zero contains a self-branch instruction which halts execution visibly on the console, indicating program failure.
Linkage to library routines
For subprograms invoked frequently—such as those performing floating-point arithmetic—minimizing call size to a single word is essential. These "library routines" use the LIBF protocol, which is more intricate than CALL but abstracts these complexities away from assembly-language programmers.
Library routines are accessed through index register XR3. (In Fortran subprograms, XR1 carries parameters and return addresses; XR2 remains unused.) XR3 points to an array of three-word transfer vectors, with its first element located 128 words before XR3’s value. To call a library routine, programmers use the LIBF pseudo-operation, which generates a one-word indexed branch instruction (BSI 3 disp) where 'disp' specifies displacement to the start of the routine’s transfer vector.
During program assembly, the linkage loader sets up these transfer vectors. For example, a transfer vector entry for routine SIMPL appears as:
DC *-* Word where BSI stores return address.
B L SIMPL Branch to library routine entry point.
When SIMPL is declared LIBF, its code is altered by the loader so that its transfer vector address resides at SIMPL+2. Unlike CALL subprograms that begin with a DC directive holding the return address, LIBF routines start directly with executable instructions:
SIMPL STX 1 RCVR1+1 Save caller’s XR1 register.
LDX I1 *-* Loader fills this with transfer vector pointer.
This indirect LDX instruction loads XR1 via the transfer vector to reference either the stored return address or inline parameters following BSI. Parameters are accessed through XR1 (incremented beyond the return address), and returning occurs as follows:
STX 1 RETN+1 Save XR1 for return. RCVR1 LDX L1 *-* Restore caller’s original XR1. RETN B L *-* Return instruction modified dynamically at runtime.
For instance, if a LIBF call occurs at address 100, control returns to 101 after executing BSI 3 disp. Should SIMPL’s transfer vector start at address 2000, then 'disp' is set so that XR3 + disp equals 2000. Executing BSI stores return address 101 at location 2000 and jumps to 2001, where a two-word jump redirects control to SIMPL’s actual entry point (e.g., address 300). At address 301, LDX I1 2000 loads return address (101) indirectly into XR1.
Before exiting, SIMPL ensures RETN contains B L 101, returning control correctly to the caller. If inline parameters follow BSI at location 101, SIMPL increments XR1 accordingly so that branching skips past them.
When using inline parameters after BSI, SIMPL accesses them via indexed addressing off XR1 (LD 1 0, LD 1 1, etc.). For indirect parameters, instructions like LD I1 n retrieve their values. Prior to returning, SIMPL advances XR1 beyond all parameters (e.g., MDX 1 n) so RETN+1 points correctly past them.
A LIBF routine that does not restore XR1 may omit these steps and return with B 1 n, skipping inline parameters altogether. However, this approach disrupts compatibility with other LIBF calls expecting XR1 preservation.
Although more complex than CALL, LIBF reduces memory usage for frequently invoked subprograms by requiring only one word per call plus three words per transfer vector entry and some additional code within each routine. In contrast, CALL demands two words per invocation due to addressing constraints.
It is necessary for XR3 to point directly at transfer vectors rather than an indirect dispatch table because indirect BSI instructions occupy two words and would eliminate LIBF’s size advantage. Due to using an eight-bit displacement in a one-word instruction, LIBF can support approximately up to 85 distinct entries.
Code alteration
Earlier sections reveal that code and data are closely intertwined. Within the 1130 programming environment, it is typical to alter instruction address fields as well as entire instructions themselves.
Through the Fortran compiler
When compiling subprograms that include parameters, the Fortran compiler produces self-modifying code. It constructs a table listing every location where parameters are referenced and inserts a call to at the beginning of the subprogram. This routine utilizes the table to update each parameter reference’s address field with the actual address during execution, performing this adjustment on every invocation.
For instance, a Fortran statement such as compiles into:
BSI L SIMPL DC X (address of X)
Although parameters can be accessed indirectly within the subprogram, the compiler opts for direct addressing. During execution, modifies instructions like:
LD I1 0
to become
LD L X
Benefits of this approach include:
- Direct addressing consumes fewer memory cycles compared to indirect indexed instructions.
- It provides precise parameter addresses required when passing parameters to other subprograms (for example, floating-point LIBF routines).
Drawbacks involve runtime overhead and additional memory usage for the reference table. The table size equals five plus the total number of parameters and references; if this exceeds 511 entries, compilation is aborted. To optimize performance for frequently referenced parameters, programmers may copy them into local variables.
By the programmer
Altering complete instructions was a frequent practice. Although the 1130 supports an OR instruction, Fortran syntax does not include it natively. An integer function named IOR implements logical OR within expressions such as: <syntaxhighlight lang="fortranfixed">
M = 3*IOR(I,J) + 5
</syntaxhighlight> The compiler embeds addresses of I and J inline, expecting the result to be returned in the accumulator. The resulting compiled code appears as:
BSI L IOR (jump to IOR) DC I (address of I) DC J (address of J)
The assembler routine IOR does not calculate OR directly; instead, it overwrites these four words with:
LD L I (load I) OR L J (OR with J)
After this replacement, control returns to the original call point. The BSI instruction is substituted by these two instructions that perform a machine-level OR on I and J, leaving the outcome in the accumulator.
This self-modification happens only once per program execution; subsequent calls run more efficiently. Comparable functions can be devised for other operations.
However, functions such as IOR cannot operate on subprogram parameters because they interfere with . The modification performed by IOR shifts variable address locations, causing to update incorrect words during later calls and thus disrupting parameter referencing.
Extended precision
The 1130 FORTRAN supports two floating-point formats: a 32-bit "standard precision" and a 40-bit "extended precision" format.
Standard precision employs a 24-bit two's complement significand, while extended precision uses a 32-bit two's complement significand that takes advantage of the CPU’s native 32-bit integer capabilities. The extended format spans three 16-bit words, with the upper eight bits of the first word unused. Both formats utilize an 8-bit exponent biased by 128. All floating-point calculations are implemented in software.
Enabling the *EXTENDED PRECISION compiler option instructs the FORTRAN compiler to represent all floating-point data using 40 bits; mixing these formats within a program is not supported.
Extensive Fortran Applications
The limited core memory capacity, ranging from 4,096 to 32,768 words, imposed restrictions on program size. Nevertheless, FORTRAN introduced mechanisms to handle larger applications within these constraints.
- LOCAL subprogram overlays
Subprograms could be flagged as "LOCAL" (Load-on-Call) overlays, residing on disk and loaded into memory only upon invocation. This approach enabled multiple subprograms to share the same memory space, requiring allocation solely for the largest active subprogram at any given time. A limitation was that LOCAL subprograms were prohibited from calling one another, whether directly or indirectly.
- Phased program execution
Large-scale programs were often divided into separately compiled segments or phases (such as PART1, PART2, PART3). Execution commenced with // XEQ PART1, and control transferred between phases through the CALL LINK command. Although the subsequent phase’s name was hardcoded, program logic could dynamically determine which phase to invoke next. Notably, the FORTRAN compiler itself utilized this phased structure.
- COMMON storage area
Programs loaded at lower core memory addresses while COMMON variables and arrays occupied higher memory locations. By declaring COMMON consistently across phases, data sharing was enabled. Some phases could omit COMMON declarations if their code did not access shared storage. Additionally, COMMON facilitated data exchange between main programs and subprograms within a phase; however, data preservation was not guaranteed when transitioning between phases.
Programming Illustrations
These examples are executable on the IBM 1130 emulator available at IBM 1130.org.
Example assembler card deck
Presented below is a card deck that assembles and executes an assembler program designed to print a deck of cards on the line printer.
// JOB
// ASM
*LIST
* LCARD.ASM - PRINT A DECK OF CARDS TO LINE PRINTER
*
* 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 RETURNS TO PRINTER ERROR HANDLER,
WHICH TERMINATES THE PROGRAM
*
END START PROGRAM ENTRY POINT
// XEQ
TEST DATA 1
HELLO WORLD
TEST DATA 2
In this job stream, the assembler writes its output into a temporary system disk location; the XEQ command then runs it. The END START directive signals both the conclusion of source code and specifies the entry point labeled START.
Assembler source code begins at column 21 on each punched card. In systems without disk drives, the assembler would punch assembled code onto the card just read before fetching the next card; forward references required a second pass through the reader/punch device. Programmers duplicated cards with columns 1–20 left blank to facilitate source modifications.
Buffers start with a word count defined by DC, followed by reserved space using BSS. The card buffer (CBUFF) consists of 80 words, each representing one punched column's Hollerith encoding. The printer buffer (PBUFF) contains packed text in EBCDIC format with two characters per word (8-bit packing). Conversion from Hollerith code to EBCDIC is performed by the ZIPCO library routine using the HLEBC table; this routine is invoked via a CALL instruction supplying its address.
Once converted, data in PBUFF is sent to the printer driver PRNT1, which loops until printing completes before proceeding to read the next card.
This sample does not include termination logic; a complete program would detect cards beginning with // as job delimiters and halt reading by checking for Hollerith codes representing / prior to conversion.
Asynchronous I/O and system efficiency
Initiating a card read operation via CARD0 triggers the process and promptly returns control to the caller, permitting continued execution. Nonetheless, the sample program does not utilize input-output overlap through buffering; instead, it repeatedly cycles back to CIMP for polling. Once CARD0 detects the card reader's completion interrupt, it exits the polling loop and proceeds.
The provided example routines do not exploit the maximum throughput potential of I/O devices. For instance, the IBM 1442 card reader could handle up to 400 cards per minute at peak performance, yet minor delays in issuing read commands often reduced this rate by half. Fortran applications struggled to keep pace with input processing, frequently causing motor stoppages that increased mechanical wear. Employing buffering techniques could have enabled simultaneous card reader control and data processing, allowing full-speed operation on substantial data sets; however, limited memory capacity commonly restricted such implementations.
Even when using assembly language and double buffering, printing a deck from the IBM 2501 reader—which operated at 1,000 cards per minute—was constrained by the slow conversion of card hole patterns to EBCDIC characters via EBPRT on a line printer. More optimized software solutions like ZIPCO and HLEBC were necessary to overcome this bottleneck.
Example APL\1130 interaction
A brief APL \ 1130 demonstration includes user sign-in, calculating the sum of integers from 1 to 100, creating an addition matrix for numbers 1 through 5, and logging out. This session was executed using the 1130 simulator accessible through IBM 1130.org.
Competing systems
In the same year as the IBM 1130’s release, Digital Equipment Corporation launched the smaller, more affordable, and more widely adopted 12-bit PDP-8, which achieved recognition as the first commercially successful minicomputer.
Legacy of the IBM 1130
- Brian Utley, who managed the 1130 project during its development and introduction phases, revealed that its initial designation was Small Engineering Computer System (SECS). The system’s architecture transitioned from 18 bits to 16 bits under the influence of System/360 design principles.
- Renowned software architect Grady Booch began his programming journey on an IBM 1130 after gaining access through an IBM sales representative.
- LISP specialist Guy Steele developed a LISP interpreter for the IBM 1130 while still in high school; both his source code and accompanying documentation are preserved at IBM1130.org.
- Chuck Moore coined the name FORTH for his programming language due to the IBM 1130 operating system’s restriction on five-character identifiers.
- Dan Bricklin, inventor of VisiCalc, first programmed on an IBM 1130 during a National Science Foundation summer research initiative.
- The inaugural dedicated Search for Extraterrestrial Intelligence project at Ohio State University’s Big Ear Observatory operated on an IBM 1130 equipped with 8 kilowords of core memory; this system detected the famous Wow! signal.
- Charles Goldfarb, acknowledged as the pioneer of SGML, credits his experience installing an IBM 1130-based typesetting system as a key inspiration behind his work on generic markup languages.
- During his doctoral studies, Alan Kay utilized an IBM 1130 to develop early graphical user interface concepts, although its limited computational power imposed constraints.
- Starting in 1969, Hutchinson Central Technical High School implemented one of the first comprehensive four-year high school computer science programs using the IBM 1130.
- An engineer formerly with IBM joined Signetics and incorporated architectural elements from the IBM 1130 into Signetics’ single-chip processor model 2650.
1130s in the Present Day
Out of approximately 10,000 IBM 1130 units manufactured, the following examples are verified to still exist as of 2025:
- A fully operational 1130 system is maintained by ACONIT in Grenoble, France.
- The Computer History Museum located in Mountain View, California possesses an intact 1130 machine.
- COSECANS, based in Basel, Switzerland, safeguards one unit.
- The National Museum of Computing (TNMOC) at Bletchley Park in the UK holds a complete IBM 1130 system.
- The University of Stuttgart in Germany runs a working 1130 computer.
- Carl Claunch has restored or is in the process of restoring multiple IBM 1130 systems for organizations such as the System Source Computer Museum and the Vintage Computer Federation museum.
Myths and Theories
Various theories have been proposed regarding the origin of the IBM 1130 model number:
- It might originate from multiplying 360 (as seen in IBM 360) by π, symbolizing its emphasis on scientific computing.
- Another idea is that the name refers to 11:30 AM, allegedly the time when naming discussions reached a deadlock.
- Alternatively, it could signify IBM’s eleventh computer design featuring thirty instructions.
Some conjecture that the existence of the IBM 1130 could explain why no "11/30" model was introduced within the PDP-11 series.
See also
External links
- IBM Archive: IBM 1130 includes press releases, timelines, photographs, and factual information.
- IBM 1130.org A comprehensive site by Norm Aleks and Brian Knittel featuring extensive data and a downloadable simulator supporting DMS R2V12 and APL environments.
- www.ibm1130.net Howard Shubs’ dedicated resource for the IBM 1130.
- Arnold Reinhold’s personal narrative about the 1130, shared with permission.
- Digitized IBM 1130 manuals available in PDF format.
- Kym Farnik’s Retro Computing page focusing on the IBM 1130.
- Discussion regarding the Angle Park computing center equipped with IBM 1130 machines.
- Bob Rosenbloom’s photographic archive of IBM 1130 systems.
- IBM 1130 documentation at Columbia University’s Computing History collection.
- Flickr album containing detailed images by Peter Vaughan of an IBM 1130 displayed at The National Museum of Computing