My rough understanding of the lights-and-switches console that many PDP-11 models had is that they were not hardwired into the CPU itself or anything, but implemented as just another Unibus device. What sort of control protocol did the console device expose?

Was it possible for software to read the switches and drive the lights directly or was the console too autonomous for that? E.g. I found this tutorial on using a console as UNIBUS diagnostic tool without even a running CPU.

Specifically, I'm wondering if it were possible to switch the console into a mode where it wasn't actually debugging the CPU but instead providing a custom user interface? Like a "whack-a-mole game" where an arbitrary data/address bit would flash and the player had half a second to flip the corresponding switch. Or — perhaps a better use of company/university computing resources — if the PDP-11 had been programmed as an industrial controller, the console lights could be relabelled as individual status indicators and the switches used independently to turn on/off a bunch of actual aspects of the equipment being operated.


There's an address in the I/O page that when read, reads the switches.

The same address may correspond to a write-only display register on some processors; i.e., reading gets the switches, writing sets the display register. I think that only the 11/45 and 11/70, and variants thereof, permit writes. Even then, whether the display register is actually shown in the lights depends on the position of a physical selector knob.

The address is

777570  Console switch and display register

Source: PDP11 04/05/10/35/40/45 Processor Handbook 1975-1976

The RSX-11M operating system (and similar, but this is the one I used) could include a GSSW$ (get sense switches) directive (system call) to allow any task to read the switches. There was no equivalent lights directive.

However, 11M also permitted "privileged tasks" to access the I/O page directly, so such a task could read and write 777570 directly. See above as to whether the write resulted in changing lights, though.

Alternatively, as you posted in a comment, if a WAIT instruction was executed, the content of R0 would be displayed in lights (subject to the aforementioned control knob being set to "data paths" on 11/45 or 11/70). This was possible even if the processor did not have actual display-register support.

I wouldn't really call any of this "accessing the console" raw or otherwise, though. You don't have control of the console in any significant sense -- just the ability to read the switch register and update the data lights. Sufficient for whack-a-mole, though.

As a footnote, the phrase you used, "not wired into the CPU", doesn't seem likely to describe the situation. The console could access data paths within the CPU. On some models you could display microcode state. On a WAIT the lights showed the content of R0, Etc. The console had a Unibus address for reading switches and writing a display register, as I describe in this answer. But all those other console functions make it look to me (programmer, not H/W engineer) like it was heavily integrated with the CPU.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.