IBM PALM processor
The IBM PALM is a 16-bit board-level microprocessor designed and built by IBM General Systems Division at Boca Raton, Florida, in the early 1970s. PALM is built from 13 bipolar masterslice gate arrays on a single PCB — it is not a single integrated circuit but a complete processor module sometimes called by IBM itself "the controller" rather than "the processor". PALM was used in the IBM 5100 Portable Computer (1975), the IBM 5110 Computing System (1978), and the IBM 5120 Computing System (1980).
 | |
| The IBM PALM controller card (Card J2) — all 13 bipolar "Dutchess" gate arrays in metal-can packages are visible, with the central round metal-can oscillator and three small DIP devices in the upper-middle region. (Photograph: Christian Corti, Stuttgart Computer Museum, ©1999–2017, used with attribution.) | |
| Specifications | |
|---|---|
| Developer | IBM General Systems Division, Boca Raton, Florida — "PALM Development Group" led by Roger Abernathy |
| Manufacturer | IBM |
| Type | Board-level 16-bit microprocessor (built from bipolar masterslice gate arrays, not a single integrated circuit) |
| Introduced | 1973 (in the SCAMP prototype); 1975 in the first production machine, the IBM 5100 |
| Discontinued | c. 1982 (last production machine, the IBM 5120, withdrawn 10 December 1982) |
| Architecture | Proprietary 16-bit microcoded architecture with four interrupt levels and 64 general-purpose registers (16 × 4 banks) |
| Data width | 16 bits (storage); 8 bits + parity (I/O) |
| Address width | 16 bits (64 KB direct); bank-switching extends in microcode |
| Clock rate | 15.1 MHz master oscillator → 66.2 ns clock pulse → eight pulses per machine cycle → ≈ 1.89 MHz effective machine-cycle clock; ≈ 530 ns per machine cycle; ≈ 1.75 µs average microinstruction execution time |
| Transistors / gates | 13 bipolar "Dutchess" masterslice gate arrays in square metal cans, each carrying ~134 logic gates of Schottky-TTL-compatible bipolar silicon |
| Package | Multi-board controller card (not a single chip) — 13 × metal-can gate arrays + 3 × TTL DIPs + 1 × round metal-can device on a single multi-layer PCB with gold-plated edge connector |
| Used in | IBM 5100 (1975), IBM 5110 (1978), IBM 5120 (1980) |
The PALM architecture is unusual in that it executes a narrow native 16-bit instruction set in hardware, and uses microcode interpretation to run higher-level instruction sets — including emulators of subsets of the IBM System/360, System/370 and System/3 instruction sets — so that the unmodified APLSV interpreter (from System/370 APL) and the System/3 Model 6 BASIC interpreter can run on the 5100 family in their original binary form. This emulation capability is what gives the 5100 its later notoriety in the John Titor Internet folklore.
Name and Acronym Expansion
Two acronym expansions are in circulation in IBM-attributed sources, and they are not equivalent:
- "Put All Logic in Microcode" — used by Paul J. Friedl in the November 1983 PC Magazine SCAMP retrospective (Friedl was the SCAMP project lead and an IBM insider), and by hands-on owners citing the IBM 5100 Maintenance Information Manual SY31-0405.
- "Program All Logic in Microcode" — used in the Roberson 1976 IEEE Proceedings paper (the formal external IEEE publication on the 5100) and consequently by Wikipedia.
Both forms appear in IBM-originated documentation. The 5100 development team in Boca Raton appears to have used "Put"; the formal IEEE paper used "Program". This page records both rather than picking one.[1][2]
Origin: SCAMP, 1973
PALM was originally developed for the SCAMP (Special Computer APL Machine Portable) prototype built at the IBM Los Gatos Scientific Center / Palo Alto Scientific Center under Dr. Paul J. Friedl between January and June 1973. SCAMP was commissioned by IBM General Systems Division (Atlanta) — specifically GSD engineer Dave Slattery — to demonstrate a self-contained portable computer that could run the APL programming environment.
SCAMP's hardware was sourced across multiple IBM divisions:
- Processor — the PALM board, from the PALM Development Group at IBM Boca Raton (led by Roger Abernathy).
- Memory cards — from IBM Germany.
- Keyboard — from IBM Raleigh, North Carolina.
- CRT — sourced from Ball Brothers, Inc.
- Secondary storage — a Norelco / Philips audio cassette deck.
SCAMP ran an IBM 1130 minicomputer emulator in PALM microcode, allowing it to host APL\1130 (APL for the IBM 1130). The prototype was demonstrated to IBM management in late 1973 and led directly to the IBM 5100 production programme.
PC Magazine in November 1983 retroactively called SCAMP "the world's first personal computer".[3] The SCAMP prototype itself is preserved at the Smithsonian National Museum of American History (object record nmah_334628).
Evolution Across the 5100, 5110 and 5120
The PALM module itself does not change between SCAMP, the 5100, the 5110 and the 5120. All three production machines use the same PALM controller card — designated Card J2 on the A1 backplane in the 5110 hardware-design documentation. What changes between machines is the surrounding ROS (Read-Only Storage):
- SCAMP (1973) — ROS holds an IBM 1130 emulator and APL\1130.
- IBM 5100 (1975) — ROS adds the APLSV interpreter (System/370 APL semantics) and a port of System/3 BASIC.
- IBM 5110 (1978) — same interpreters plus EBCDIC character set support and IEEE-488 / RS-232 I/O ROS.
- IBM 5120 (1980) — same interpreters, both APL and BASIC in ROM as standard, plus support for built-in 8-inch floppy drives.
This page treats the PALM hardware as constant; the differences are in the executable and language ROS that wrap it, not in PALM itself.
Architecture Summary
| Parameter | Value |
|---|---|
| Data path width | 16 bits (storage); 8 bits + parity (I/O) |
| Address bus width | 16 bits (64 KB directly addressable; bank-switching in microcode for larger configurations) |
| Storage Address Bus | 16 bits |
| Storage R/W Bus | 18 bits (16 data + 2 parity, one parity bit per byte) |
| I/O Data Bus | 8 bits + 1 parity, each direction (Bus In active-high; Bus Out active-low) |
| Master oscillator | 15.1 MHz on the processor card |
| Clock pulse | 66.2 ns |
| Machine cycle | 8 clock pulses ≈ 529.6 ns |
| Effective machine-cycle clock | ≈ 1.89 MHz |
| Average microinstruction time | ≈ 1.75 µs (per Roberson 1976) |
| Native instruction width | 16 bits (one "halfword") |
| General-purpose registers | 64 × 16-bit (16 registers per interrupt level × 4 interrupt levels) |
| Program Counter | R0 in each register bank (memory-mapped at offset 0 in the bank) |
| Interrupt levels | 4 (level 0 normal execution; level 1 communications; level 2 mass storage / printer / serial; level 3 keyboard) |
| Control ROS (on PALM module) | 256 × 32-bit microcode store |
| Executable ROS (off-PALM) | ~16K × 18-bit per language (16K × 18 for BASIC; another 16K × 18 for APL) |
| Process check | Parity error or invalid X/Y device address halts the processor and lights front-panel "PROCESS CHECK" lamp (unless an interlock jumper is removed) |
Cycle Timing Reconciled
The widely-quoted figures "1.9 MHz" and "530 ns cycle" are reconciled by the underlying clock hierarchy:
- The processor card carries a 15.1 MHz master oscillator.
- Each clock pulse is 66.2 ns wide.
- A machine cycle consists of eight clock pulses: 8 × 66.2 ns = 529.6 ns ≈ 530 ns.
- The effective machine-cycle clock is therefore 1 / 529.6 ns ≈ 1.89 MHz — rounded to "1.9 MHz" in most secondary sources.
A native PALM instruction takes one instruction phase (3 machine cycles) plus one execution phase (1–3 machine cycles depending on the instruction). The instruction phase loads the Storage Address Register from R0 (the program counter), fetches the instruction into the Operation Register, then increments R0 by 2. The execution phase performs the ALU operation, register write-back, or I/O transfer. The 1.75 µs "average microinstruction time" quoted by Roberson 1976 corresponds to a 3-cycle instruction; longer instructions reach ~2.6 µs.
Register File
PALM has 64 general-purpose 16-bit registers, organised as four banks of 16 registers. Each bank is the complete register state for one of the four hardware interrupt levels. When an interrupt is taken, the hardware switches to that level's bank in a single cycle — there is no software state-save overhead.
The registers physically live on the PALM processor card, but they are also memory-mapped to the first 128 bytes of Read-Write Storage (RWS / RAM) for each bank. This means microcode and high-level code can address the registers either by register number (R0–R15) or by memory address (0x00–0x7F in the current bank's window).
- R0 in each bank is the program counter (instruction pointer).
- R1–R15 are general-purpose; convention assigns specific roles in the interpreters (R1 stack pointer, R2 frame pointer, etc.) but the hardware imposes nothing.
Interrupt Architecture
Four hardware interrupt levels, in priority order:
| Level | Priority | Source(s) |
|---|---|---|
| 0 | Lowest (normal execution) | User program / interpreter |
| 1 | Higher | BSCA / Asynchronous Communications adapter |
| 2 | Higher | Tape drive, diskette drive, printer, Serial I/O |
| 3 | Highest | Keyboard |
The keyboard is the highest-priority interrupt source — appropriate for an interactive APL workstation where user input must never be missed.
Switching to a higher level changes the register bank in one cycle; no state is saved because each level has its own complete bank.
Native Instruction Set
PALM has a 16-bit native instruction set — all instructions are exactly one halfword (16 bits). The top 4 bits (the high nibble of the first byte) select the opcode group. The bottom 12 bits encode operands, addressing modes, and condition codes.
| Top nibble | Mnemonic family | Operation |
|---|---|---|
| 0 | ALU register-register | ADD, SUB, AND, OR, XOR, MOVE, INC, DEC, MHL (move high to low), MLH (move low to high), GETB (get byte), GETADD (get address), ADDH, etc. |
| 1 | CTL | Control byte to device (I/O write of a control byte) |
| 2 | LDHD | Load halfword direct (from a direct address) |
| 3 | STHD | Store halfword direct |
| 4 | PUTB | Put byte to I/O device |
| 5 | STHI | Store halfword indirect via register Ry |
| 6 | LDBI | Load byte indirect |
| 7 | STBI | Store byte indirect |
| 8 | EMIT / LBI | Load byte immediate |
| 9 | CLRI | Clear bits immediate (mask off bits) |
| A | ADDI | Add immediate (value +1, so ADDI 0 means add 1) |
| B | SETI | Set bits immediate (OR a mask) |
| C | Jump / Skip | Conditional skip family — there are no traditional jump instructions |
| D | LDHI / LWI | Load halfword indirect; LWI synthetic load-word-immediate |
| E | ROTR / SHFTR / GETB / STAT | Rotate right, shift right, get byte from register, get status |
| F | SUBI | Subtract immediate (value +1, so SUBI 0 means subtract 1) |
This table is reconstructed by the Stuttgart Computer Museum from a recovered IBM-internal "Chapter 2" PALM machine-language document held by the IBM Museum in Sindelfingen.[4]
Branching by Skip, Not by Jump
A defining feature of the PALM native instruction set is that there are no JUMP, BRANCH or CALL opcodes. The opcode group C (Jump/Skip) provides conditional skips — instructions that conditionally skip the next instruction.
Branching is therefore synthesised in microcode and in software:
- Short relative jumps (±256 bytes) — ADD or SUB an immediate to R0 (the program counter) under a condition mask. The ADDI / SUBI groups (top nibble A / F) take an 8-bit immediate with an implicit +1 (so ADDI 0 means add 1, ADDI 255 means add 256), giving the ±256-byte range.
- Long jumps — load R0 with the target address using LDHI or LWI.
- CALL / RETURN — software convention: push the return address onto a software stack (managed in R1 by convention), then load R0 with the target. RETURN pops and restores R0.
This is consistent with the architecture's bias toward implementing higher-level languages in microcode rather than in native code: the native instruction set is deliberately small and orthogonal, and the interpreters above it (APL, BASIC, the S/370 / S/3 emulators) provide the higher-level control flow.
Addressing Modes
The native PALM instruction set supports the following addressing modes:
- Register direct — Rx (or Ry) — a 4-bit register number addresses one of 16 registers in the current bank.
- Immediate 8-bit — used by LBI, ADDI, SUBI, CLRI, SETI.
- Direct 4-bit — used to select an I/O device (one of 16 devices via the 4 × 4 X/Y matrix).
- Direct 8-bit (as 9-bit byte address) — used by the MOVE direct opcodes; the high bit (bit 15) is implicitly 0, restricting the direct address range to the first 256 bytes of RWS (which is exactly the register-bank memory-mapped window).
- Register indirect — *(Ry) — uses Ry as a pointer. Optional pre- or post-increment / decrement of ±1, ±2, ±3, ±4 bytes (only specific values are encoded; not arbitrary ±n).
- Synthetic addressing modes — Load Word Immediate (LWI) and PC-relative (ADD/SUB to R0) are not separate opcodes but software conventions assembled from the native ones.
Bus and Memory Map
PALM uses three physically separate buses on the A1 backplane:
- Storage Address Bus — 16 bits, output from PALM, reaches RWS and Executable ROS.
- Storage R/W Bus — 18 bits (16 data + 2 parity), bidirectional between PALM and storage.
- I/O Bus — 8 bits + parity, plus control strobes (Put Strobe, Get Strobe, Control Strobe, Op Code E); bidirectional between PALM and Base I/O / peripheral cards.
The memory map is unusual in that ROS is accessed as both memory and I/O:
- RWS (RAM) — accessed only through the Storage Address Bus / Storage R/W Bus.
- Executable ROS — accessed through the Storage Address Bus for instruction fetch and as an I/O device (address 2) for the bank-switching scheme.
- Common / Language ROS (APL and BASIC interpreters) — accessed only as an I/O device (address 1), never as memory. PALM treats the language ROS as a peripheral and fetches interpreter code through the I/O bus, byte-by-byte.
This is an architecturally distinctive design: it means the language interpreters cannot be jumped into directly — they must be invoked through the I/O subsystem.
I/O Architecture
The I/O bus carries 4 X-select lines and 4 Y-select lines; exactly one X and one Y must be active for a valid device address. This 4 × 4 matrix gives 16 possible device addresses, of which the following are defined in the 5110:
| Address | Device |
|---|---|
| 0 | Graphics / processor |
| 1 | Common + Language ROS (APL / BASIC interpreters) |
| 2 | Executable ROS (monitor / diagnostics) |
| 3 | Diskette Sort |
| 4 | Keyboard |
| 5 | Printer |
| 6 | BSCA (Binary Synchronous Communications Adapter) |
| 7 | Parallel I/O |
| 8 | Async / Serial I/O |
| 9 | (unused on some configurations) |
| A | Serial I/O (BASIC) |
| B | (unused) |
| C | Print-Plot (BASIC) |
| D | Diskette adapter (5114 control) |
| E | Tape drive |
| F | Reset I/O |
The I/O bus is open-collector and daisy-chained, terminated by a 300 Ω pull-up or an IBM terminator box on the last card. Transfers are handshaked: Put Strobe validates a byte on Bus Out (to peripheral); Get Strobe validates a byte on Bus In (from peripheral); Control Strobe identifies a CTL byte as a command rather than data; Op Code E is decoded directly from the STAT opcode for non-data transfers.
A parity error on the storage R/W bus or an invalid X/Y device-address pattern triggers Machine Check, which halts the processor unless a jumper on the backplane is removed; the front-panel PROCESS CHECK lamp illuminates.
Physical Implementation
The PALM module is a single multi-layer printed circuit board with a gold-plated edge connector that mates with the A1 system backplane (in the 5110 documentation, it is identified as Card J2 — Controller). The board carries:
- 13 × bipolar masterslice gate arrays in square metal-can packages.
- 3 × conventional TTL DIPs.
- 1 × round metal-can device (most plausibly the 15.1 MHz oscillator can — likely but not explicitly confirmed in published sources).
The gate arrays are the heart of the implementation.
Dutchess Masterslice Gate Arrays
The 13 gate arrays on the PALM board are IBM's "Dutchess" masterslice — an uncommitted-logic-array (ULA) family fabricated by IBM at its bipolar facility (most likely IBM East Fishkill, New York, though this is not explicitly stated in published sources for PALM specifically).
Dutchess specifications:
| Parameter | Value |
|---|---|
| Logic family | Bipolar, Schottky-TTL-compatible |
| Supply voltage | +5 V |
| Gate count per array | ~134 logic gates |
| Internal logic mix | 60 × three-input NAND + 40 × four-input NAND + 34 × two-input NOR off-chip drivers |
| Propagation delay | ≈ 10 ns per gate |
| Package | Square metal can with leadframe |
| Personalisation | Metal mask (final aluminum interconnect layer) — the same wafer can be cut into different logic functions by changing only the metal layers |
A masterslice (also known as a sea-of-gates ULA in later terminology) is a wafer pre-fabricated with a fixed array of unconnected transistors. The specific logic function of each chip is set by the metal interconnect layers added at the end of fabrication — this lets IBM build 13 different gate-array functions on the PALM board from the same underlying silicon.
Dutchess was IBM's bipolar workhorse masterslice family for small-system controllers in the early 1970s and predates the larger IBM ECL families used in System/370 mainframes.
Identified ICs on the PALM Board
The 13 Dutchess gate arrays are visible and labelled with IBM part numbers in Christian Corti's high-resolution photograph of the J2 controller card. The IBM part-number format on this generation of Dutchess parts is aaaaaa IBM nn where aaaaaa is a 7-digit IBM part number identifying the specific personalisation of the masterslice, and nn is the IBM family designator (here, 22 — denoting the Dutchess family in this configuration). A second line gives a date / lot code in the form 1-yyy nnnn where yyy appears to be a 3-digit week-of-fab code and nnnn a serial sequence.
The following IC identifications are transcribed directly from the J2 card photograph. Identification of which logical function each part performs (ALU, register file, microcode sequencer, etc.) is documented in IBM's SY31-0405 (5100 MIM) and SY34-0193 (5120 CSLM) — but cannot be derived from the photograph alone, and is listed below as not yet mapped.
| Position (row, col) | IBM part number | Family | Date / lot code | Logical function (from CSLM) | Notes |
|---|---|---|---|---|---|
| 1, 1 (top-left) | 2706597 | IBM 22 | 1-841 1062 | Not yet mapped | Same part also at position 4, 1 |
| 1, 3 (top-right) | 1554466 | IBM 22 | 1-849 2247 | Not yet mapped | |
| 2, 1 | 5564251 | IBM 22 | 1-849 2865 | Not yet mapped | Same part also at position 3, 1 |
| 2, 3 | 2706506 | IBM 22 | 1-842 1304 | Not yet mapped | |
| 3, 1 | 5564251 | IBM 22 | 1-849 2865 | Not yet mapped | |
| 3, 2 (centre) | 1554469 | IBM 22 | 1-849 2746 | Not yet mapped | |
| 3, 3 | 5564255 | IBM 22 | 1-839 0937 | Not yet mapped | |
| 4, 1 | 2706597 | IBM 22 | 1-847 2327 | Not yet mapped | |
| 4, 2 | 2706503 | IBM 22 | 1-839 0923 | Not yet mapped | |
| 4, 3 | 1554468 | IBM 22 | 1-849 2631 | Not yet mapped | |
| 5, 1 (bottom-left) | 1554470 | IBM 22 | 1-844 6469 | Not yet mapped | |
| 5, 2 | 2706505 | IBM 22 | 1-842 1516 | Not yet mapped | |
| 5, 3 (bottom-right) | 1554467 | IBM 22 | 1-843 1454 | Not yet mapped |
That gives 13 Dutchess gate arrays (with two repeats — 2706597 appears twice and 5564251 appears twice — leaving 11 unique masterslice personalisations across the 13 sockets). The repeats are consistent with multiple functions implemented from the same masterslice metal-mask design (the same gate array used twice for byte-paired data paths, for example).
Other identified board devices
Three smaller devices are visible in the upper-middle region of the J2 card, between the row-1 and row-2 Dutchess arrays. These are the 3 conventional TTL DIPs referenced by Wikipedia and PC Magazine.
| Position | Marking | Device type | Notes |
|---|---|---|---|
| Upper-middle, left | 210086-C, LC 7676.20, 7828 CT | Small DIP | Function not identified from photograph alone |
| Upper-middle, right | M-210086-C, LC 7676/20, 7825 2 CT | Small DIP | Same base part number as above; "M-" prefix variant |
| Top-centre (green-marked) | Round metal-can with green dot indicator | Crystal oscillator can | Most plausibly the 15.1 MHz master oscillator that produces the 66.2 ns clock pulse. The green dot is consistent with an IBM marking convention for tuned / specified crystals |
The "210086-C" and "M-210086-C" markings appear on small DIPs with date codes 7825 / 7828 (the 25th and 28th week of 1978), which is consistent with this specific J2 card being from a 1978 5110 — the date codes are slightly later than the row-1 gate array codes (which include weeks 841, 842, 843, 844, 847, 849 of 1978 by the "1-yyy" convention).
The Stuttgart photograph also shows a board edge marking 16078496458VG41 (probably an IBM card serial / FRU number) and additional small surface-mount components and decoupling capacitors near the right edge of the board.
Reading the IBM 22 family designator
The IBM 22 family designator on every Dutchess part on this card is consistent across the entire 13-IC complement, confirming they are all the same masterslice variant. Different metal-mask personalisations produce the different 7-digit base part numbers (2706597, 1554466, 5564251, 2706506, 1554469, 5564255, 2706503, 1554468, 1554470, 2706505, 1554467) but the underlying silicon is the same Dutchess wafer.
The Dutchess gate count (~134 logic gates per chip) and the 13-chip board complement therefore give the PALM processor an effective gate count of approximately 13 × 134 ≈ 1,740 logic gates of bipolar Schottky-TTL logic — comparable in raw gate count to the early-generation single-chip CPUs of the same era (Intel 8080 ≈ 4,500 transistors / equivalent to a few hundred gates; PALM has more gates but spread across 13 packages).
Function Blocks of PALM
The Stuttgart Computer Museum's reverse-engineered data-flow diagram of the PALM module identifies the following logical function blocks. The exact one-to-one mapping of these blocks onto the 13 Dutchess gate arrays is documented in IBM's SY31-0405 Maintenance Information Manual (5100) and SY34-0193 Computing System Logic Manual (5120) — but is not extracted in any widely-mirrored secondary source. Restorers needing this mapping must consult those PDFs directly.
| Block | Width | Function |
|---|---|---|
| Read Data Register (RDR) | 18 bits | Latch for data read from RWS or ROS (16 + 2 parity) |
| Storage Address Register (SAR) | 16 bits | Holds the address of the current storage access |
| Operation Register (Op Reg) | 16 bits | Holds the current instruction (fed to the control ROS for microcode lookup) |
| Storage Data Register (SDR) | 8 bits | Latch for the byte to be written to RWS (write side of the R/W bus) |
| ALU Register (A) | 16 bits | First operand to the ALU; also the ALU output destination |
| Arithmetic Logic Unit (ALU) | 8 bits | Performs ADD, SUB, AND, OR, XOR, NOT — the ALU is 8 bits wide; 16-bit operations are done in two passes |
| Control ROS | 256 × 32 bits | The microcode store on the PALM module itself; the Op Reg indexes into this ROS to produce the 32-bit control word that drives the rest of the cycle |
| Register File | 16 × 16 × 4 = 64 × 16 bits | General-purpose registers — 16 per interrupt level × 4 levels |
| Oscillator / Clock generator | — | 15.1 MHz crystal-controlled oscillator producing the 66.2 ns clock pulse |
| Interrupt Level Logic | — | Detects pending interrupts on levels 1, 2, 3 and arbitrates which bank is currently active |
The 8-bit-wide ALU is one of PALM's most distinctive features — a 16-bit machine with an 8-bit-wide arithmetic data path. Sixteen-bit ADD or SUB therefore takes two ALU passes (one per byte), with carry propagation between passes managed by the control ROS sequencer.
Microcode and Emulated Instruction Sets
PALM is most often described in IBM literature as a microprogrammed processor — meaning the small 16-bit native instruction set is itself implemented by a 32-bit-wide microcode store on the PALM module, and that microcode can also implement higher-level emulated instruction sets.
The 5100 family uses two emulation layers:
- PALM microcode → System/370 APL bytecode → APL primitives (for the APL environment).
- PALM microcode → System/3 Model 6 instruction subset → BASIC primitives (for the BASIC environment).
The APL interpreter is a slightly modified APLSV (APL Shared Variables) — IBM's System/370 APL implementation. PALM microcode emulates enough of the System/370 instruction set that the unmodified APLSV object code can run.
The BASIC interpreter is a port of IBM's System/3 Model 6 BASIC — PALM microcode emulates enough of the System/3 instruction set that the BASIC interpreter, which is itself emulated S/3 code, runs unchanged.
Crucially, the System/370 emulator is APL-only — BASIC uses the System/3 emulator instead. This was confirmed by IBM engineers on the alt.folklore.computers thread "John Titor was right? IBM 5100" — IBM never disclosed the emulator's existence in customer-facing literature.
This layered emulation explains why the IBM 5100 became famous in the John Titor Internet hoax in 2000–2001: the central claim of the hoax — that the 5100 secretly contained an IBM System/360 emulator — is substantially true at the architectural level.
What is in the S/370 / S/3 Subsets
The exact subset of System/370 (and System/3) instructions emulated by PALM microcode is not documented in any publicly available source that this article's research could locate. IBM did not disclose the subset; the manuals describe the user-facing APL and BASIC interpreters but not the emulation layer beneath them.
Reasonable inferences (not verified):
- Floating-point hardware — out of scope (APLSV uses software floating-point routines anyway on the 5100).
- Decimal arithmetic (S/370 packed decimal instructions) — likely out of scope.
- Privileged S/370 instructions (SVC, LPSW, STORAGE PROTECTION ops) — out of scope.
- Integer and logical instructions as exercised by APLSV bytecode — in scope.
- Memory addressing modes as used by APLSV — in scope.
The S/370 subset is therefore "what APLSV actually exercises", not "all of S/370".
Process Check and Diagnostic Features
The front-panel PROCESS CHECK indicator lights when:
- A storage parity error is detected (the 2 parity bits on the R/W bus do not match the data).
- An invalid X/Y device address pattern is presented on the I/O bus (more than one X line active, or more than one Y line, or none).
- Certain illegal opcodes are decoded.
By default the processor halts on Process Check. A jumper on the backplane can be removed to disable the halt for diagnostic purposes (so the processor continues running with parity errors logged but not fatal).
The front-panel "Display Registers / RAM Hex" switch on the 5100 shows the first 512 bytes of RWS — which is the register-bank memory-mapped window — live in hex on the 5-inch CRT. This is the field engineer's primary diagnostic tool when the system cannot reach the BASIC / APL banner.
A Diagnostic ROS mode is entered via a keyboard sequence at power-on; in this mode the operator can read and write RAM, video memory, PALM registers, interrupt vectors and the clock counter in hex — effectively assembly-language access to PALM without an operating system.
Significance
- Predates the Intel 8086 (June 1978) by ~3 years and the Intel 8080 (April 1974) by months (SCAMP, with PALM, was running in June 1973).
- Not a single-chip CPU. IBM in the 1970s used "microprocessor" to mean "processor that executes microcode to implement a higher-level instruction set" — not the modern meaning of "single integrated circuit". The Roberson 1976 IEEE paper title — "A Microprocessor-based portable computer: The IBM 5100" — uses "microprocessor" in this sense.
- The only IBM CPU of its generation. The IBM 801 RISC project at IBM Research/Yorktown Heights began in 1975 and is a completely independent programme; there is no architectural lineage between PALM and 801. The 5100 / 5110 / 5120 are the only commercial IBM machines built on PALM.
- First IBM emulation-by-microcode implementation in a small machine. The pattern of "small computer that emulates a larger architecture in microcode to run unmodified mainframe binaries" was later reused by IBM in the XT/370 (1983), where an IBM PC XT was fitted with a System/370 emulator card.
- Cultural footprint. The 5100 — and through it, PALM — became famous in the John Titor Internet hoax of 2000–2001 for being claimed to secretly emulate a System/360. The claim is substantively true.
Known Gaps in Documentation
This article documents PALM at the level supported by publicly available sources. The following details are documented in IBM's CE manuals but not in any widely-mirrored secondary source, and are listed as gaps for future research:
- The one-to-one mapping of the 13 Dutchess gate arrays onto the PALM function blocks. The IBM part numbers for all 13 gate arrays are now identified on this page (see "Identified ICs on the PALM Board" above), but which function each part implements (ALU, register file, microcode sequencer, bus interface, etc.) is documented only in IBM 5100 MIM SY31-0405 (PALM appendix) and IBM 5120 CSLM SY34-0193, and has not been transcribed into any community-accessible secondary source.
- The function (not just the part number) of the 3 TTL DIPs and 1 round metal-can device on the PALM board. The part numbers 210086-C / M-210086-C for the small DIPs and the visual identification of the round metal can as a crystal-oscillator can are now recorded here. The exact role of the 210086-C devices in the PALM design is documented in the CSLM but not in any secondary source.
- The exact System/370 instruction subset emulated by PALM microcode. IBM did not publish this; the manuals deliberately omit the emulation layer.
- Die-shot or photomicrograph of a Dutchess masterslice. No publicly available example.
- Whether PALM was used in any other IBM product as an embedded controller. Wikipedia notes "It is likely PALM was also used in other IBM products as an embedded controller" — no cited example. Speculation on Hacker News about the IBM 3274 cluster controller is unverified.
- Exact PALM board dimensions, weight and per-card power draw. Not separately documented from the rest of the A1 backplane card family.
Related Pages
- IBM 5100 — first production machine with PALM (1975)
- IBM 5110 — successor (1978)
- IBM 5120 — last production machine with PALM (1980, also designated 5110 Model 3)
- IBM 5100 Maintenance Guide — chassis-level service
- IBM 5110 Maintenance Guide
- IBM 5120 Maintenance Guide
References
- Roberson, D. A. "A Microprocessor-based portable computer: The IBM 5100." Proceedings of the IEEE 64(6): 994–999, June 1976. DOI 10.1109/PROC.1976.10253.
- Friedl, P. J. "SCAMP: The Missing Link In The PC's Past?" PC Magazine 2(6): 190–197, November 1983.
- IBM. IBM 5100 Maintenance Information Manual, SY31-0405-3, October 1979.
- IBM. IBM 5110 Maintenance Information Manual, SY31-0550-2, February 1979.
- IBM. IBM 5120 Computing System Logic Manual, SY34-0193-0, December 1979.
- Wikipedia. "IBM PALM processor" article (general overview, with primary-source citations to Roberson 1976).
- Wikipedia. "IBM 5100" article (System/370 emulator discussion).
- Corti, C. Stuttgart Computer Museum, IBM 5110 Hardware Pages — reverse-engineered hardware breakdown with photographs of the J2 controller card, opcode tables, and data-flow diagram. Subsequently corroborated against the IBM-internal "Chapter 2" PALM machine-language document recovered from the IBM Museum at Sindelfingen.
- Dunfield, D. Daves Old Computers — IBM 5100 — community restoration site with PALM-board photographs and SY31-0405 reference.
- Smithsonian National Museum of American History, object record nmah_334628 (SCAMP).
- ↑ Friedl, P. J. "SCAMP: The Missing Link In The PC's Past?" PC Magazine 2(6): 190–197, November 1983.
- ↑ Roberson, D. A. "A Microprocessor-based portable computer: The IBM 5100." Proceedings of the IEEE 64(6): 994–999, June 1976.
- ↑ Friedl 1983, PC Magazine.
- ↑ Corti, C. Stuttgart Computer Museum IBM 5110 hardware pages, http://computermuseum.informatik.uni-stuttgart.de/dev/ibm_5110/technik/en/ — "Opcodes" section.