PiDP-8/I Software

IOT Device Assignments
Log In
Help

Motivation

The PDP-8 instruction set includes the in/out transfer (IOT) instruction to allow the CPU to communicate with devices.

Uncommonly for PDP-8 instructions, IOT instructions break down nicely by their octal digits. For example, the KSF instruction (60318) means:

Digit(s) Meaning
6 first digit, 6 = "IOT instruction"
03 next two = device ID, 03 = read from console Teletype
1 final digit = device-specific op-code, 1 = "skip on keyboard flag (KSF)"

As you can see, the middle two octal digits are a device ID, which uniquely identifies a particular device on the computer's bus. Two octal digits is 6 bits, giving 64 unique device ID codes. The large number of available PDP-8 peripherals and that small code space means there are conflicts.

These device IDs were mostly assigned by DEC, with some left unassigned. Although you can find tables of IOT codes in various DEC manuals, I started this article because I could not find a single definitive list across the entire history of PDP-8 hardware. This article is meant to be used by a person reading through a piece of PDP-8 assembly code who wants guidance toward more specific and detailed documentation. The goal is that any time your assembly listing shows an instruction beginning with "6", you should be able to use the table below to find the manual where that instruction is documented.

Status

This document is a work in progress. The PDP-8 is pretty well fixed in history, but I have not yet reviewed anywhere near all of the relevant docs on IOT instruction assignments.

My current goal is to get through the main sources: all editions of DEC's Small Computer Handbook, the User's Manual for each major version of PDP-8, DEC's "Introduction to Programming: PDP-8 Family," and Krten's iot.h.

After that, it should just be a matter of occasional refinements.

Known Mappings

The following table tells you what a given IOT device code means, where it can be found, and what it controls. For example, it tells you that device code 63 might refer to an RF08 controller on a PDP-8/I, controlling an RS08 fixed-head hard disk drive. The reasons for "might" are explained below.

ID(s) Interface Bus Device(s) Controlled
00 CPU all all PDP-8s: interrupt on and off (ION/IOF); NPD
00 CPU O PDP-8/e and later: refined to add CAF, GTF, RTF, SGT, SKON, SRQ; NPD
01 PR8/I P high-speed perforated paper tape reader
01 PR8-E O PR8-EA or PR8-EB high-speed perforated paper tape reader
02 PP8/I P Royal McBee high-speed paper tape punch
02 PR8-E O PP8-EA or PP8-EB high-speed paper tape punch
01-02 PC8-E O PC04/PC05 high-speed paper tape reader/punch (more)
03 CPU all teleprinter keyboard input / teleprinter's paper tape reader
04 CPU all teleprinter output / teleprinter's paper tape punch
05-06 VC8/I P oscilloscope or other X-Y point-plot display: Type 30N, 338, etc.
07 ? ? Light Pen Type 370, used with Display Type 30N or 338
05-07 KV8/I P storage tube display
10 MP8/I P memory parity; NPD
10 KP8/I P power failure automatic restart; NPD
11-12 bus P DC02-A 4-terminal controller and DC02-D single terminal interface; BA08
11-12 bus N DC02-E 4-terminal controller and DC02-D single terminal interface; BA12
11-12 bus N DC02-F 8-terminal controller and DC02-G single terminal interface; BA12
11-12 bus N fifth non-console Teletype on PT08, after 46-47
13 KW8/I P real-time clock; NPD
13-17 ? ? Display Type 338
20-27 MC8/I P memory extension MM8/I
30-37 n/a n/a for customer use; never used by DEC
40-47 DL8/I P Data Communications System Type 680
40-41 bus N first non-console Teletype on PT08
42-43 bus N second non-console Teletype
44-45 bus N third non-console Teletype
46-47 bus N fourth non-console Teletype
50-52 VP8/I P Incremental Plotter
53-54 bus N Scanning Digital Voltmeters (voltage A/D) Types AF01A-AF04A
55 bus N Type AA01A 3-channel DAC
55 bus N Type AA05 24-channel DAC and 40-channel Type AA07 expansion
57 bus N AF04A Scanning Digital Voltmeter D/A feature
55-57 ? ? Sample-and-Hold D/A Converter Type AC01A
60-61 ? N Type 165B PDP-6 Interface
60-62 ? N Serial Magnetic Drum Type 251
60-62 bus N Serial Drum System Type RM08
60-62 bus N DF32 hard disk & controller combo; expansion via DS32
60-64 bus N RF08 Control for RS08 fixed-head hard disk drive
63, 67 ? ? Card Reader Type 451
63, 67 ? ? Card Reader Type CR8/I
60-66 bus P Type DP01AA synchronous modem interface
65-66 ? ? Automatic Line Printer Type 645
65-66 LE8-E O line printer controller
70-72 bus N TC58 Control for 1-8 DECtape Transport Types TU10, TU20, TU30
70-75 DL8/I P DC08 Telegraph Line Option for Type 680/I
70-72 bus N/P TR02 Control for TU22, TU25, and TU28 DECtape Transports
76-77 bus N Type TC01 Control for 1-8 TU55 DECtape Transports
76-77 bus N/P Type TC08 Control for 1-8 TU55 DECtape Transports
76-77 TD8-E O Control for single and dual TU56 DECtape Transports

ID

The first column gives one or more device ID codes in octal. Yes, octal: there is no "gap" between codes 07 and 10!

Where a range (e.g. 60-62) is given, all IDs in the range are used by that peripheral, inclusively.

In rare cases, a device uses multiple discontiguous device ID codes, so they are given as a list instead. For example, Card Reader Type 451 uses ID codes 63 and 67.

The reason some devices use multiple device ID codes is that there are only 3 bits left in the IOT instruction for describing the operation desired, and in the earliest PDP-8 computers, you couldn't set more than one bit at once due to the way the IOT instruction was decoded. If a given peripheral needed more than 3 or 8 (2³) commands, the designer would use multiple device IDs to get enough instruction combinations. A common scheme was to use 3 codes: one to read data, another to write data, and a third to control the device's internal state.

Conflicts

Many of the IDs in this table appear in more than one row.

These are sometimes simple conflicts, such as between the DP01AA synchronous modem interface and the RF08 disk controller: you can have one or the other in a given PDP-8 computer system, not both at the same time.

More often, a reused device ID represents some kind of "replacement," as with the RF08/RS08 effectively replacing the earlier DF32: a DF32 assembly plus the maximum of three DS32 expansion disk drives holds half what a single RS08 disk drive does, so there is no good reason to have both a DF32 and an RF08 disk controller in a single PDP-8 computer.

Another good example is the Data Communications System Type 680, which uses eight device ID codes to control up to 128 Teletypes, telegraph lines, or other serial terminals. Those codes overlap the IOT device codes for the PT08, where each pair of codes is used much more simply, one for sending to a single terminal and one for receiving from it. If you wanted more than the 5 non-console terminals allowed by the PT08 or you didn't want to chew up 10 IOT codes doing it, you'd almost certainly switch entirely to the Type 680, rather than expend special efforts to use both in a single computer system.

Interface

There were many different ways of interfacing devices to the PDP-8 family of computers, in part because of bus complexities, in part because there were so many different computers in the family over their 20 year production span, and in part because of the variety of peripherals available. This column gives the short name of the device on the computer's backplane or expansion bus that processes the IOT device ID code.

Before we get to the meaning of the values you can find in this column, let me make it clear that the only reason we're giving a value here is in case you are a programmer and find a reference to one of these interfaces and need to understand how that maps to IOT instructions. We are not greatly concerned with helping people to reassemble working PDP-8 computers.

Another important reason we give interfacing details is for paired devices and device controllers. For instance, we mention the "TC55" on the same row as "TC01" in the main data table, even though it is only the TC01 that processes the IOT device ID codes on that row, because you might be dealing with a program whose comments talk only about the TU55.

CPU

When this column contains "CPU," it means the interface is part of the CPU proper. See the Bus column for the specific CPU type(s) meant.

Sometimes a part of the CPU has a short name, so we give that here instead of "CPU." For example, the high-speed paper tape punch/reader circuitry built into the PDP-8/I, called the PP8/I and PR8/I. Even though these devices are part of the CPU proper — you can't buy the CPU without getting these devices — we give their short name here for the benefit of programmers running across these names in comments and such.

Bus

Many PDP-8 peripherals were able to talk directly to the PDP-8 bus, and did not need a device-specific card in the CPU backplane or expansion bus. These are marked "bus" in the Interface column, with the Bus column giving the peripheral's required logic type.

Sometimes other cards are necessary, such as the KD8/L data break interface, usually used for high-speed data storage peripherals. This document doesn't give such details for each peripheral, since we are primarily concerned here with helping assembly programmers understand IOT instructions found in programs, not with the physical assembly of PDP-8 family computers.

Sometimes a bus peripheral is just a controller for another peripheral, as with the TC01 controller for the TU55 DECtape transport. We put "bus" in this column rather than "TC01" because the TC01 isn't a card that plugs directly into the CPU backplane or expansion bus. It's mounted in the rack and connected to the bus with cabling, which daisy chains from one such peripheral to the next.

So far, we've only got negative logic peripherals designed for use with the original negibus PDP-8 computers. These can be used by posibus machines like the late-model PDP-8/I, the PDP-8/L, and the PDP-12 by adding the DW08-A I/O conversion panel. There must be positive logic peripherals that can be used by a negibus PDP-8 through use of a DW08-B I/O conversion panel, but we haven't come across any yet.

?

When there is just a question mark in this column, it means we have not yet found documentation telling how this device interfaces to the computer. The highest likelihood is that these are negative-logic bus peripherals. If you have these details, please tell us: file a bug, post to our forum, etc.

Other

When some other value is given in this column, it means the named card either is the device addressed by the given IOT device ID code(s) or it is a device-specific card that plugs into the backplane to convert between the bus signaling and that required by the peripheral device.

There is a common case that should not be confused with this one. The TC01 controller for the TU55 DECtape transport is an example of this: the TC01 isn't a card for the PDP-8 backplane, it is an interface between the PDP-8 negibus and between 1 and 8 tape transports. The TC01 talks directly to the PDP-8 negibus, so we don't put "TC01" in the Interface column for the TU55 IOT line in the table above.

When using this sort of DECtape system with a posibus PDP-8, the required DW08-A I/O conversion panel is also not the interface in the sense meant by the main data table above, because it doesn't process the IOT device ID code: the TC01 does.

As the electronics became denser in later machines, DEC was able to get many devices and device controllers onto a single card. Where not CPU-internal, the controller card and its associated device got different names, which is why the primary table above has this column in addition to the Device(s) Controlled column.

Flip-Chip Interfaces

The design of the early PDP-8 computers allows for peripherals that did not talk directly to the computer's bus and which did not have a dedicated controller card for that bus. Instead, you could install some number of generic Flip-Chip bus interfacing cards. We have not come across documentation for any peripherals that document such an arrangement, so no rows in the main data table above are marked this way. We assume the DEC manuals talk about this possibility for custom devices designed by end users, with the Flip-Chip cards offered by DEC to let the customer avoid designing their own custom cards.

Bus

DEC used several incompatible bus designs in the PDP-8 series. This column tells you which machines the given interface could be found on:

Bus Compatible PDP-8 Type(s)
N "negibus" used on the PDP-8 ("straight eight"), PDP-8/S, LINC-8, and early PDP-8/I computers
P "posibus" used on the later PDP-8/I computers and on all PDP-8/L and PDP-12 computers
O OMNIBUS machines: PDP-8/e, PDP-8/f, PDP-8/m, and PDP-8/a computers
A PDP-8/a only ("hex" card size)

Devices marked N/P were available in both positive and negative logic variants.

There were converters for the transition machines:

Cards with a "/I" suffix usually also came in a "/L" variant for the PDP-8/L. I don't know if there are material differences between the two, or if DEC just renamed them to make the nomenclature within a given machine consistent. I haven't bothered to give duplicate entries in the main data table above when I've found the same function provided under both names.

Device(s) Controlled

This column is merely a convenience to allow you to search this article by device type. Strictly speaking, the actual devices are off-topic for this article, since IOT instruction processing stops at the computer interface electronics, whether that's a single device-specific card or a group of generic Flip-Chip cards.

This separation allows for replacement peripherals, such as an LE8-E work-alike to print to a Centronics-style parallel PC printer from a PDP-8/e. The card merely has to respond to the same IOT instructions on the OMNIBUS as the original; the PDP-8/e and its software doesn't need to know that the printer or its electrical interface standard didn't even exist when the computer it's inserted into was designed.

Sometimes the brief reference in this column actually refers to a family of devices used to provide a service, as with the Type 680 Data Communications System. The DL8/I interface card talks to a Type 685 serial line multiplexer, which talks to an optional Type 684 patch panel, which talks to one or more Type 682 or 683 terminal interfaces. The DL8/I also talks to the DC08{A,C,CS,D,EB,F,FX,H,J} series of devices. We try to link to more detailed external sources in such cases.

Another common case is that a single short DEC product name encompasses many elements with their own names. For example, the RM08 drum memory system includes not just the drum memory unit proper, but also a Type 779 power supply, electronics on over a hundred individually named cards, and the racks, cable assemblies and other hardware to hold it all together.

Peripherals vs Built-In Facilities

We find it helpful to make a distinction between devices internal to the processor and bus chassis and those that are external peripherals.

In the main table above, "NPD" means "no peripheral device," and it's applied to devices where the functionality is entirely internal to the chassis holding the CPU and expansion bus when this option is fitted. This sort of option affects either the CPU or some device directly connected to it, or it provides a self-contained facility.

Everything not marked NPD above controls a device mounted separately from the CPU chassis. It could be mounted near the CPU in the same rack, it could be in another rack connected to the main rack with cabling, or it might be outside the computer rack(s) entirely, as with the Teletype often used with early PDP-8s. Collectively, we call these "peripheral devices." Since there are more of these than the NPDs, we don't bother to mark these "PD."

We cannot always make this clear distinction in the PDP-8 family. For example, the PDP-8/I computer comes with a 4 kiW field of core memory built into the processor. To get additional core memory, you add the MC8/I option to the processor, which includes a second 4 kiW field of core, for 8 kiW internal total, but it also includes memory controller circuitry allowing you to mount up to six MM8/I modules external to the processor, each of which provides another 4 kiW field of core, for a maximum of 32 kiW. The MC8/I handles memory-related IOT instructions like CDF, instruction 62x1, where x is the field number. All of this together is the computer's memory subsystem, which is absolutely core (pardon the pun) to the operation of the computer, yet it's not all internal to the processor chassis and it's addressed via IOT instructions, as if it was an external peripheral.

Fortunately, with most PDP-8 devices, there is a clear "PD" vs NPD distinction.

Unassigned Customer Device Codes

Device ID codes 30-37 were explicitly set aside by DEC for customer use, but DEC reserved only codes 00, 03, and 04 exclusively for themselves. DEC documentation encouraged customers to use any device code they like except for these three if they ran out of space in the 30-37 range. For example, if a customer's application didn't require anything more than the console terminal, they were free to use the 40-47 range, since that range is used for devices that control secondary terminals.

License and Credits

This document was compiled from DEC documentation, the liberally relicensed header iot.h from Robert Krten's d8tape PDP-8 disassembler, and other sources by Warren Young. The compilation and prose are copyrighted © 2017-2019 and licensed under the SIMH license.