IBM PALM processor

IBM PALM

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; 8-bit ALU; four interrupt levels each with its own bank of 16 general-purpose 16-bit registers (64 architectural registers visible to the programmer simultaneously); no hardware stack; no conditional branch — all conditional flow is test-and-skip
Data width	16-bit register file and ISA; 8-bit ALU; 18-bit Storage Read/Write Bus (16 data + 2 parity); 9-bit I/O bus each direction (8 data + 1 parity)
Address width	16-bit Storage Address Bus (64 KB byte-addressed); SAB bit 0 = card-select between the two executable-ROS cards giving 128 KB executable-code addressing; bank-switching in microcode for larger configurations
Clock rate	15.1 MHz crystal oscillator producing 66.2 ns "MCC" (multiclock cycle) pulses on the controller card. Per-instruction cycle composition: I-phase = 14 MCC fixed (3 + 8 + 3); E-phase = 1–5 E-cycles of 3 or 8 MCC each, up to 40 MCC maximum. Typical native instruction throughput 1.13–5.30 µs from RWS, 1.13–2.05 µs from ROS (per SY31-0405-3 Figure 11)
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 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 that IBM's own public-facing documentation refers to only as "the controller" (the term "PALM" never appears in IBM's customer-facing manuals for the 5100, 5110 or 5120). PALM was used in the IBM 5100 Portable Computer (1975), the IBM 5110 Computing System (1978), and the IBM 5120 Computing System (1980).

The PALM architecture is unusual in that it executes a narrow native 16-bit instruction set in hardware, and uses higher-level interpreter ROS to run instruction sets from other IBM machines:

• The APL environment runs on top of an IBM System/360 emulator written in PALM microcode in the executable ROS, which then executes the APL interpreter from the non-executable language ROS in System/360 object code. This was confirmed by direct disassembly of the APL executable ROS — only S/360 opcodes appear in the dispatch, no S/370-specific instructions.
• The BASIC environment runs on top of a separate microcode interpreter that emulates the IBM System/3 Model 6 instruction subset; the BASIC interpreter is itself System/3 object code from System/3 BASIC.

The S/360 emulator is therefore APL-only. BASIC uses the System/3 emulator. IBM did not disclose either emulator in the customer documentation; the existence of the S/360 emulator is documented only by reverse engineering of the executable ROS (Corti and Stepleton 2007–2019) and by IBM engineers' later off-the-record confirmations in the alt.folklore.computers archives. This is the source of the John Titor folklore — the claim "the 5100 secretly contained a System/360 emulator" turns out to be substantively true at the architectural level.

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.

First Public IBM Use of the Term "PALM"

The earliest publicly accessible IBM document using the term "PALM" is the GENASM PALM manual by H. J. Myers (1977, IBM Internal Use Only). GENASM was IBM's macro-assembler generator for the PALM target machine; "PALM" in the title refers to file index 6 on the GENASM distribution tape (the PALM target-machine definition file).

No public-facing IBM manual from the 5100 / 5110 / 5120 product line uses the term "PALM" — not the 5100 Maintenance Information Manual (SY31-0405), not the 5110 MIM (SY31-0550), not the 5120 Computing System Logic Manual (SY34-0193), and not the user-language reference manuals. IBM's customer-facing terminology is always "the controller" (the card in slot G2 on the 5100 / J2 on the 5110). The word "PALM" was internal-only until the late-1980s / 1990s, when it leaked into the IBM Archives and the Roberson IEEE-Proceedings paper retrospectively associated it with the controller architecture.

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". The SCAMP prototype itself is preserved at the Smithsonian National Museum of American History (object record nmah_334628).

The SCAMP prototype at the Smithsonian National Museum of American History. SCAMP carried the first PALM board, and is the direct ancestor of every IBM 5100/5110/5120 (and indirectly of the IBM PC). Image: Wikimedia Commons, CC BY-SA 2.0.

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

PALM 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; full per-instruction table at Per-Instruction Timing below)
Native instruction width	16 bits (one "halfword")
General-purpose registers	64 × 16-bit (16 registers per interrupt level × 4 interrupt levels); memory-mapped at $0000–$007F
Program Counter	R0 in each register bank (memory-mapped at offset 0 in the bank)
Link Register (IBM convention)	R1 in each bank — auto-loaded with PC+4 on a not-taken jump, enabling the IBM subroutine-call idiom
Interrupt levels	4 (level 0 normal execution; level 1 communications; level 2 mass storage / printer / serial; level 3 keyboard); higher level = higher priority; switch is automatic at instruction boundaries
Process check	Parity error or invalid X/Y device address halts the processor and lights front-panel "PROCESS CHECK" lamp; jumper J2-S07 to J2-S09 on the 5110 (equivalent G2 pins on the 5100) can be removed to disable the halt for diagnostics

Cycle Timing Reconciled

PALM clock-cycle structure: each machine cycle is built from 8 clock pulses of 66.2 ns each (529.6 ns total). An instruction phase takes 3 cycles; an execution phase takes 1–3 cycles depending on the instruction. (Diagram: Christian Corti, Stuttgart Computer Museum.)

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:

PALM interrupt levels

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.

PALM native opcode groups (top nibble of the instruction word)

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 top-nibble 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, cross-referenced with Appendix C of the SY31-0405 5100 Maintenance Information Manual (which contains the same opcode set with abbreviated descriptions, and which was omitted from the 5110 MIM SY31-0550).

IBM Chapter 2 Mnemonics (Full Detail)

The IBM internal "Chapter 2" microinstruction reference (transcribed in full by Corti at the Stuttgart Computer Museum) and SY31-0405-3 Appendix C together document every native PALM opcode with IBM's own mnemonics. The encoding pattern: all instructions are 16-bit halfwords; the top 4 bits select the opcode class; opcode 0 is overloaded — the low 4 bits of byte 0 (the "AM modifier") select one of 16 ALU / move / halfword operations.

IBM Chapter 2 native PALM microinstruction set (SY31-0405-3 Appendix C / IBM Sindelfingen Chapter 2)

Opcode pattern	IBM mnemonic	Function
0xy0–4	MVM2 / MVM1 / MVP1 / MVP2 / MOVE	Move halfword (with optional pre-decrement / pre-increment of ±1 or ±2 on the source pointer)
0xy5–7	AND / ORB / XOR	8-bit logical operations on the low byte
0xy8 / 0xy9	ADD / SUB	8-bit arithmetic with carry / borrow propagation into the high byte
0xyA / 0xyB	ADDS1 / ADDS2	"Add special" — multi-byte carry / borrow propagation for synthesised wider arithmetic
0xyC / 0xyD	HTL / LTH	Byte swap — High-to-Low / Low-to-High within a register
0xyE / 0xyF	GETR / GETA	I/O get-to-register; GETA performs an 8-way priority decode of Bus In bits to add 0 / 2 / 4 / 6 / 8 / A / C / E to the destination — see GETA priority encoder below
1ijj	CTL	I/O control command (sends a control byte to a device)
2xii / 3xii	LDHD / STHD	Direct halfword load / store — direct addresses are limited to the first 256 halfwords (the page-0 region)
4ix?	PUTB	I/O put-byte, with auto-modification of an indirect register if specified
5xy? / 7xy?	STHI / STBI	Indirect store, halfword / byte (uses Ry as pointer with optional pre/post inc/dec)
6xy? / Dxy?	LDBI / LDHI	Indirect load, byte / halfword
8xii	EMIT	Load 8-bit immediate into the low byte of register Rx
9xii	CLRI	Clear bits via 8-bit mask (logical AND-NOT immediate)
Axii	ADDI	Add 8-bit immediate with implicit +1 (so ADDI 0x00 adds 1, ADDI 0xFF adds 256)
Bxii	SETI	Set bits via 8-bit mask (logical OR immediate)
Cxy?	JLE / JLO / JEQ / JNO / JALL / JALLM / JNOM / JHAM / JHI / JHE / JHL / JSB / JSN / JSNM / JSM / JHSNM	Test-and-skip family. Modifier bits 8–F flip each test to its "skip-on-false" variant. There are no real jumps — all flow control is built from these conditional skips
E0x?	SHFTR / ROTR	Shift / rotate the low byte (rotate-by-4 = nibble swap; rotate-by-3, -1 also encodable)
Eix?	GETB / GETRB	I/O byte fetch / status fetch
Fxii	SUBI	Subtract 8-bit immediate with implicit −1 (so SUBI 0x00 subtracts 1)

No Hardware Stack, No Conditional Branch

PALM has no PUSH / POP, no CALL / RET, no JMP / Bcc in its native instruction set. All flow control is built from:

• Conditional skip (opcode group C) — skips the next halfword if the test passes.
• Direct write to R0 (the program counter / IAR) — by `MOVE R0, Rx`, `LDHI R0, *(Ry)`, or `ADDI R0, imm` / `SUBI R0, imm`.

Subroutine calls are an IBM idiom: increment R0 by 2 into a "link register" (any register the programmer designates — R1 by IBM convention) to capture the return address, then overwrite R0 with the call target. Return is `MOVE R0, R1`. Recursive or nested calls require the programmer to build their own stack in RWS — there is no hardware stack pointer.

This skip-and-write model is uncommon among 1970s ISAs and reflects PALM's strict role as a microcode interpreter rather than a general-purpose programming target. The interpreters running on top of PALM (the System/360 emulator and the System/3 emulator) provide higher-level control flow to their code.

GETA Priority Encoder (8-Way Hardware Dispatch)

The GETA instruction (opcode `0xyF`) is one of PALM's most distinctive hardware features. GETA performs an 8-way priority decode of the 8 bits on Bus In, mapping the position of the leftmost zero into an addend of 0, 2, 4, 6, 8, A, C, or E (always even), which is then added to the destination register.

When the destination register is R0 (the IAR), GETA becomes an 8-way computed dispatch in a single instruction — the canonical "jump table in hardware" mechanism used throughout the executable ROS to dispatch I/O interrupts and emulated S/360 opcode classes. Without GETA the same dispatch would require a longer skip-chain.

Per-Instruction Timing (SY31-0405-3 Figure 11)

The 5100 MIM Figure 11 (transcribed by Corti from the IBM Sindelfingen archive) gives the per-instruction execution time when fetching from RWS. The bracketed values are the equivalent times when executing out of executable ROS — ROS execution is faster than RWS because the storage timing differs.

Native PALM per-instruction execution time (from RWS; bracketed values from ROS)

Instruction	From RWS	From ROS
MOVE, MVM1, MVM2, MVP1, MVP2	3.97 µs	1.52 µs
AND, ORB, XOR, ADD, SUB, ADDS1, ADDS2, HTL, LTH, GETR, GETA	4.63 µs	1.72 µs
CTL	2.65 µs	1.13 µs
PUTB	3.97 µs	2.05 µs
GETB, LDHI, LDBI, STHI, STBI	4.63 µs	2.05 µs
LDHD, STHD	3.97 µs	1.52 µs
EMIT	2.65 µs	1.13 µs
CLRI, ADDI, SUBI, SETI	3.97 µs	1.52 µs
All jumps (C-group skips)	5.30 µs	1.92 µs
Shift / rotate (E0xC–F)	1.72 µs	—

ROS execution is 2–3× faster than RWS execution for the same opcodes, which is part of why so much of the executive ROS is structured as monolithic ROS-resident code rather than RWS-loaded routines.

PALM Is Self-Hosting

PALM is sufficiently capable as a programming target that it can host its own assembler. IBM's GENASM PALM (H. J. Myers, 1977) is a macro-assembler generator that runs on the 5100 itself and produces PALM machine code from PALM assembly source. The full assembler build time from source on a 5100 is reported at approximately 45 minutes. This means that within IBM, PALM was used as a self-hosting development platform for its own microcode — a notable property for a 1973-era board-level processor.

The modern equivalent is Alfred Arnold's Macro Assembler AS (build 1.42 Bld 231, October 2022), which adds PALM as a target architecture with synthetic pseudo-opcodes — BRA, RET, CALL, JMP, LWI — layered over the IBM Chapter 2 mnemonics, giving restorers and emulator developers a modern toolchain for PALM code.

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

RWS (Read-Write Storage) memory map of the IBM 5110 as seen by PALM. The first 128 bytes are the memory-mapped register-bank window; the remaining RWS is general-purpose RAM. (Diagram: Christian Corti, Stuttgart Computer Museum.)

Storage Address Register (SAR) bit-field layout. (Diagram: Christian Corti, Stuttgart Computer Museum.)

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:

PALM I/O device addresses (5110 / 5120; 5100 mostly compatible)

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:

IBM Dutchess masterslice gate array

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.

IBM 5100 chassis interior — the PALM card mounts on the A1 backplane alongside ROS, RWS and I/O cards. The PALM card carries 13 bipolar gate arrays in metal cans on a single multi-layer PCB. Image: Wikimedia Commons, public domain.

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.

Identified ICs on the PALM (Card J2) controller card

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.

Smaller ICs on the PALM board (transcribed from the J2 card photograph)

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

Data-flow diagram of the IBM PALM processor reverse-engineered by Christian Corti from an actual 5110 controller card. Shows the Read Data Register (RDR), Storage Address Register (SAR), Operation Register, Storage Data Register (SDR), the 8-bit-wide Arithmetic Logic Unit, the Control ROS Unit, the four-banked register file, and the connections to the three external buses (Storage Address Bus, Storage R/W Bus, and I/O Data Bus). (Diagram: Christian Corti, Stuttgart Computer Museum, ©1999–2017, used with attribution.)

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.

PALM internal function blocks

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	Width unverified	The microcode store on the controller card; the Op Reg indexes into this ROS to produce the control word that drives the rest of the cycle. The 256 × 32-bit figure that previously appeared on this page is a Wikipedia talk-page rumour not confirmed by SY31-0405-3
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 best described as a microprogrammed processor that runs three layered instruction sets at different times:

1. Native PALM ISA (16-bit halfword instructions, decoded by the control ROS on the controller card) — used by IBM's own diagnostics, the GENASM-assembled microcode, and the executive ROS itself.
2. IBM System/360 subset — implemented by an emulator written in native PALM microcode, sitting in the executable ROS. Used only by the APL environment.
3. IBM System/3 Model 6 subset — implemented by a separate emulator in PALM microcode. Used only by the BASIC environment.

The System/360 Emulator (APL only)

The APL executable ROS contains an IBM System/360 emulator written in PALM microcode. The non-executable APL ROS (cards C2 / D2 / D4 on the 5100) contains the APL interpreter as System/360 object code, which the executive ROS interprets opcode-by-opcode.

This is confirmed by two independent reverse-engineering efforts:

• Christian Corti (Stuttgart Computer Museum) disassembled the executive ROS in his `aplros.asm` file: "The APL executable ROS is mainly a System/360 emulator that executes the APL interpreter in 360 code from the non-executable ROS."
• Brett W. Hill (voidstar.blog) reviewed the same disassembly and found only System/360 opcodes in the dispatch handlers — no System/370-specific instructions.

The earlier widely-circulated claim that PALM contained an "IBM System/370 emulator" is not borne out by direct examination of the executive ROS. The confusion arises because IBM's APL implementation on mainframes (APLSV) ran on System/370 — but the 5100's port of APLSV was compiled / re-targeted to System/360 object code for execution on PALM, not S/370 code.

The full System/360 opcode subset implemented by the emulator is not published; the canonical source for the actual subset is Corti's `aplros.asm` file at `ftp://ftp.informatik.uni-stuttgart.de/pub/cm/ibm/ibm5110/`. Inference from public material:

• Out of scope: floating-point hardware (APL uses software FP routines), decimal arithmetic, privileged S/360 instructions (SVC, LPSW, storage protection).
• In scope: integer and logical instructions, the addressing modes APL needs, character / packed-data operations the interpreter exercises.

The System/3 Emulator (BASIC only)

The BASIC environment is built on a separate System/3 Model 6 emulator. The BASIC interpreter is itself System/3 object code, and the executable BASIC ROS interprets that code via the System/3 emulator.

Native PALM ISA Word Size

Native PALM instructions are 16-bit halfwords. An older internet rumour (preserved in the Wikipedia talk page) claims that the control ROS on the PALM card itself is "32 bits wide" internally — but this claim cannot be confirmed in any primary source the wiki has access to. The SY31-0405-3 MIM describes the control ROS unit functionally but does not state its width. Treat the "32-bit internal microcode" figure as unverified. What is verified is that the ISA exposed to the executable ROS and to GENASM-generated PALM programs is the 16-bit halfword instruction set documented in IBM "Chapter 2" and in SY31-0405-3 Appendix C.

Card Complement Around PALM

The PALM controller card does not stand alone — it is one of about a dozen cards on the IBM A1 backplane in the 5100 / 5110 / 5120, all of which it talks to over the Storage Address, Storage R/W and I/O buses. From the 5100 MIM SY31-0405-3 §4 layout diagram (p. 4-19):

5100 A1 backplane card complement

Slot	Card	Function
C2 / D2 / D4	APL ROS (non-executable)	APL interpreter as System/360 object code; accessed via I/O DA=1
C4	BASIC ROS (non-executable, 36 KB)	BASIC interpreter as System/3 object code; accessed via I/O DA=1
E2	ROS Control / common ROS	Mux logic + common operator-message text
F2	Base I/O	Bus-In / Bus-Out / strobes interface to the controller card
G2	Controller (PALM)	The 13-Dutchess processor card; this article's subject
H2	BASIC executable ROS	PALM microcode implementing the System/3 emulator + I/O + diagnostics for BASIC mode
H4	APL executable ROS	PALM microcode implementing the System/360 emulator + I/O + diagnostics for APL mode
J2	Display adapter	Generates the 5-inch CRT video, cycle-stealing from RWS for the frame buffer at $0200–$05FF
K2 / K4 / L2 / L4 / M2 / M4 / N2 / N4	R/W storage (RWS)	Up to eight 8 KB RAM cards = 64 KB max system RWS
A2	I/O cable driver	External-bus repower for peripherals (5103 printer, 5106 tape, etc.)

The 5110 reorganises this: the controller card is in slot J2 instead of G2, RWS uses two 16 KB cards instead of eight 8 KB cards, and a second executable-ROS card is on a different slot. The Stuttgart Computer Museum's Boards and Connectors page documents the 5110 A1 backplane in full, including the Y1, Z2, Z3 and Z4 cable pinouts.

A key consequence of the storage architecture: data fetches are always from RWS — executable ROS cannot be read as data from a running PALM program. `LDHD`, `LDHI`, `LDBI` and the indirect-load family all address RWS only. This is why extracting the executive ROS for reverse engineering required a hardware trick (see Executive ROS Extraction below).

Memory Map of the Running System

The first 128 bytes of RWS are memory-mapped to the four banks of 16 registers (with the active bank window changing with the current interrupt level). The remainder of RWS is general-purpose RAM, with certain addresses reserved for I/O status bytes that the executable ROS keeps up to date.

Selected RWS addresses (5100 / 5110)

Address	Contents
$0000–$001F	Register file, interrupt level 0 (R0L0 = IAR; R1L0 = link register)
$0020–$003F	Register file, interrupt level 1
$0040–$005F	Register file, interrupt level 2
$0055	Printer Status Byte A (low byte of R10L2)
$0057	Printer Status Byte B (low byte of R11L2)
$0060–$007F	Register file, interrupt level 3
$008F	Tape Status Byte
$00A8	Last byte of RWS (5100) — varies; 5110 last byte is $00AA
$00AC	Address of the RWS / ROS switch routine
$00AE	Address of the I/O supervisor
$00E8 / $00E9	Disk Status Byte A / B (5110 only)
$0200–$05FF	Display buffer (memory-mapped 64 × 16-character screen)

The I/O supervisor exposes a 14-byte IOCB (I/O Control Block) for each device; the layout is documented at the Stuttgart Computer Museum's IOCB page.

ROS Organisation

The 5100 / 5110 ROS comes in two distinct flavours:

• Executable ROS — directly addressable by the Storage Address Bus. Contains PALM microcode the controller fetches and executes through I-phase / E-phase cycles. The executive ROS includes the System/360 emulator (APL mode) or the System/3 emulator (BASIC mode), all of the I/O drivers, and the Diagnostic Control Program.
• Non-executable ROS — accessed only as a peripheral via device address 1 (Common + Language ROS) or device address 2 (Executable ROS on 5110; used for bank switching). Contains the APL interpreter (S/360 object code) and the BASIC interpreter (S/3 object code) plus the operator-message common ROS.

The non-executable ROS is read a byte at a time by:

1. `CTL DA=1, command-byte` to load the 16-bit ROS address.
2. `PUTB DA=1, high-byte ; PUTB DA=1, low-byte` to clock the address into the ROS counter.
3. `GETB DA=1, Rx` reads the byte at that address and auto-increments the counter for the next read.

Three control lines coordinate the access — −Restart, −Set, −Sample-and-Reset — driven by ROS access clocks MCC2, MCC3 and MCC4. MCC4 resets the array between transfers; (MCC2 × MCC3) gates the data out.

Notably, bit 0 of the CTL byte to DA=1 is "ROS write enable" — Corti speculates this almost certainly existed so IBM developers could test new ROS images on production hardware without burning new mask ROMs (the 5100 development era overlapped with 1702 / 2708 EPROM technology).

Executive ROS Extraction

Because executable ROS cannot be read as data from a running PALM program (see Card Complement above), reverse-engineering the executive ROS required exploiting a hardware feature of the 5100 / 5110 boot sequence:

1. On the very first machine cycle after power-on, the display adapter shows the 512 bytes of executive ROS at whatever address the SAB jumpers point to (default 0x0000).
2. The internal Single-Step switch (accessible through the case via two screws) lets the field engineer freeze the machine on that first cycle.
3. Pulling the SAB jumpers to different addresses lets you walk through all 128 × 512-byte = 64 KB pages of executive ROS, photographing each frozen frame.

Christian Corti applied this to the 5110 between 2007 and 2012, photographing every page at high resolution and OCR-ing the result.

Tom Stepleton and Corti repeated the procedure on a 5100 in January 2019, using AI-guided OCR followed by manual correction. The full project notebook is at `github.com/stepleton/5100ExecutableROSDecode`; the decoded ROS images are archived at `archive.org/details/ibm_5100_ros`.

The non-executable ROS — APL on C2 / D2 / D4 (5100) and BASIC on C4 — is extracted in software, not by display-trickery, because it is reachable as an I/O device. A small PALM program written via the Diagnostic Control Program loops `CTL DA=1, #$04 ; PUTB-addr ; GETB-data` to dump non-executable ROS into RWS, then a DCP-driven RWS-to-disk dump and a KERMIT transfer to a modern host completes the extraction. The full DCP listing is documented by Corti at the Stuttgart Computer Museum's "Extracting the non-executable ROS" page.

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.

Known Gaps in Documentation

This article documents PALM at the level supported by publicly available primary and reverse-engineering sources. The following details are documented in IBM's CE manuals but not transcribed into any widely-mirrored secondary source, and remain open gaps:

1. Function-block to gate-array mapping. The 13 Dutchess gate array part numbers are identified on this page (see Identified ICs on the PALM Board above), but which function each chip implements (ALU, register file, microcode sequencer, bus interface, etc.) is documented only in IBM 5100 MIM SY31-0405 §4 "Theory" / "5100 Controller Description" and IBM 5120 CSLM SY34-0193, neither of which uses the term "PALM" or names individual gate-array part numbers. SY31-0405 §4 documents the function blocks as named signals (RDR, SAR, Op Reg, SDR, ALU Reg, ALU, Control ROS Unit) but stops short of saying "function block X is implemented by chip part-number Y". Closing this gap requires direct gate-level tracing of the controller card against the CSLM logic flowcharts.
2. Function of the small 210086-C / M-210086-C DIPs. The part numbers are now recorded from the J2 card photograph but the function within the controller is not documented in any source the wiki has access to. The 7825 / 7828 date codes (weeks 25 and 28 of 1978) confirm the J2 card was built mid-1978, consistent with a 1978 5110.
3. Exact System/360 instruction subset emulated. The canonical source is Corti's `aplros.asm` (the disassembled APL executable ROS) at `ftp://ftp.informatik.uni-stuttgart.de/pub/cm/ibm/ibm5110/`. No source enumerates the subset as a discrete instruction list. The previous version of this page identified the emulator as "System/370" — that claim is incorrect; direct disassembly shows only S/360 opcodes.
4. Exact System/3 Model 6 instruction subset emulated by the BASIC ROS. Same status — emulator exists, opcode list not published.
5. Die-shot or photomicrograph of a Dutchess masterslice. None located publicly.
6. Use of PALM in other IBM products as an embedded controller. Wikipedia speculates ("It is likely PALM was also used in other IBM products as an embedded controller") but no source has identified a specific product. Speculation on Hacker News thread 14483823 about the IBM 3274 cluster controller is anecdotal (vt240 noted "square metal cans, many of them socketed" matching the visual signature of IBM masterslice modules of the period) but unverified against IBM documentation.
7. Exact PALM board dimensions, weight and per-card power draw. Y1 power-feed cable on the 5110 A1 backplane supplies +5 V, +8.5 V, +12 V, −5 V, −12 V to the controller card among others — exact controller-only current draw not separately documented.
8. Roberson 1976 Proceedings of the IEEE paper full text. Available only through paywalled IEEE Xplore or behind environment blocklists. Cited extensively for the 1.75 µs average microinstruction figure, but the wiki cannot independently verify against the original.
9. Internal width of the control ROS / microcode store on the controller card. Wikipedia-talk-page claim of "256 × 32 bits" cannot be confirmed against SY31-0405-3, which describes the control ROS unit functionally without giving width. Treat as unverified.

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).