IBM PALM processor

IBM PALM

Top-down view inside an IBM 5100; the PALM controller card is the processor module that sits on the A1 backplane alongside ROS, RAM and I/O cards (image: Wikimedia Commons, public domain).
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 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 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.

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

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

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:

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.

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.

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	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:

1. The one-to-one mapping of the 13 Dutchess gate arrays onto the PALM function blocks. Documented in IBM 5100 MIM SY31-0405 (PALM appendix) and IBM 5120 CSLM SY34-0193 — but not transcribed into any community-accessible secondary source.
2. The identity (manufacturer / part number) of the 3 TTL DIPs and 1 round metal-can device on the PALM board. High-resolution photos of the J2 card (e.g. at the Stuttgart Computer Museum) would allow identification by silkscreen, but no source has done this systematically.
3. The exact System/370 instruction subset emulated by PALM microcode. IBM did not publish this; the manuals deliberately omit the emulation layer.
4. Die-shot or photomicrograph of a Dutchess masterslice. No publicly available example.
5. 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.
6. 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).