The chassis was fitted with a 4MB memory card, a third party eight channel DZV-11, a ethernet card and a CMD CQD-220 SCSI controller with a 18GB SCSI disk in an external case.

To get BSD onto the disk, I hooked it up to a PC running simh and prepared a suitable disk image.

One problem I encountered was that the standard MSCP driver wasn’t fully compatible with the CMD CQD-220 controller. To resolve this it is necessary to compile a patched boot block. This can be found here:  rauboot.s (original site).

To install, I fired up the disk image I was planning on using in SIMH and performed the following steps:

• cd /usr/src/sys/mdec/
• mv rauboot.s rauboot.s.orig
• vi rauboot.s
• i (For insert)
• pasted in above copy of rauboot.s
• after the paste completed, ESC :wq!  (write and quite)
• make    (rebuilds the mdec files)
• cp rauboot /mdec
• dd if=/mdec/rauboot of=/rra0a count=1

Once the disk image was prepared and working, the SCSI disk was hooked up to the SIMH box (running under linux) and the ‘dd’ command used to copy the disk image onto the disk.

Having done that, the disk was reconnected to the PDP and booted up into BSD 2.11. The ethernet was connected up to my office network (via a AUI transceiver). The /etc/netstart and /etc/hosts files were tweaked to assign the box an IP, subnet and gateway on the local network and /etc/inetd.conf modified to enable the FTP server. The PDP was then rebooted into multiuser mode and the network confirmed to be workin

However it has left me with a desire to find an interesting practical use for my machines. One of my earliest computing experiences and fondest memories was playing Essex MUD via the JANET network and so I’ve decided to write a MUD for the PDP-11 and use a mixture of terminals and micros to provide user access and to control non-player characters.

The game will be written in C under BSD 2.11 with DZ11’s providing shell access. The game itself will run as a single process, non-blocking daemon accessed via sockets. This has the advantage of providing serial and network (using telnet) access to the game.

Initially I will develop the game under SIMH, with a uPDP-11/73 with an RD54 used as the production machine. Ultimately I hope to move it all over to a UNIBUS machine, either an 11/40 or one of my 11/70s, but I’ll start simple to begin with.

Non player characters will be implemented on BBC micros in BASIC. The BBCs will interact with the PDP via serial.

I expect development to take 2-3 months of evenings and I’ll report back here regularly on how things are progressing. Once something is working I’ll put a simh version online for people to play with.

• M050 – 50mA indicator and relay driver
• M100 x 2 – Bus data interface
• M107 x 6 – Device selector PDP-8, Non Omnibus
• M113 x 15 – 2-input NAND gates (x10)
• M137 x 4 – high speed 4-input power NAND Gates
• M139 x 4 – 8-input NAND gate (x3) (pinout different from M119)
• M141 x4 – AND/NOR gates
• M155 x4 – 4-line to 16-line Decoder
• M159 – Arithmetric/logic unit
• M160 x5 – AND/NOR Gate module
• M161 x4 – Binary to Octal/Decimal Decoder
• M169 x4 – Gating Module
• M178 x8 – 8×6 data mixer
• M190 x4 – ?
• M191 – ALU Look-Ahead Logic
• M202 x4 – J-K flip flop module
• M203 – eight Set-Reset flip flop module
• M204 x3 – General purpose buffer and counter module
• M205 x4 – five -"D" FLIP FLOPS
• M206 x4 – Six General purpose flip-flops
• M207 x2 – Six General purpose flip-flops
• M211 x2 – Binary up/down counter (6 bits wide)
• M212 x4 – 6-Bit L-R Shift Register
• M214 x2 – ?
• M216 x5 – Six flop-flops
• M217 x4 – Clock Register
• M238 x4 – Dual 4-bit binary synchronous up/down counter
• M245 x4 – Dual 4-bit shift register
• M304 x4 – One-shot delay (PC15)
• M307 x4 – Integrating one-shot module
• M310 x4 – Delay line
• M360 x2 – Variable delay
• M401 x4 – Variable clock
• M405 x3 – Crystal clock
• M452 x4 – Variable (TTY) clock (for PC15)
• M501 – Schmitt trigger
• M503 x4 – Schmitt Trigger
• M506 x4 – Negative input converter
• M508 x4 – Bus converter
• M510 – Positive bus receiver (for PC15)
• M516 x8 – Positive bus receiver
• M514 – Bus transceiver
• M602 x2 – Pulse Generator (amplifier)
• M606 x5 – Pulse Generator (for PC15)
• M611 x4 – high speed Power inverter
• M617 x5 – 4-input NOR buffers (x6)
• M622 – Positive Pulse Receiver (for PC15)
• M623 x 2 – Bus driver
• M627 x4 – Power amplifier module
• M640 – ?
• M650 x4 – Negative output converter
• M660 x5 – Positive level cable driver
• M661 x9 – Positive level driver
• M712 x2 – ?
• M719 x2 – KW-12 Clock Input Synchronizer
• M720 x4 – Memory detection
• M870 – Simple Clock
• M906 x3 – Cable terminator
• M921 – Device code jumper select
• M939×2 – ?

G7273 X 10 – U – Bus Grant & Non-processor grant
M105 X 8 – Q -Device selector for PDP-11
M4002 – U – KWV11-C Programmable Real-Time Clock
M7390 – Unknown
M7513 – Q – RQDX extender for RQDX1
M7555 X 20 – Q – RQDX3 MFM Winchester and floppy disk controller
M7559 – Q – TQK70 TMSCP controller for TK70
M7680 – ? – RK05
M780 – U – KL11 Teletype transmitter & receiver for KL11, 110 baud
M7800 X 3 – U – DL11 Async transmitter & receiver
M7816 – U – DQ11-AB Bus selectors and block check
M7820 – U – KW11 Interrupt control, 7-bits, 1 per PDP11 peripheral
M7822 – U – DU11 Synchronous serial line interface.
M7823 – U – KW11-W Watchdog timer module
M7846 X 3 – U – RX11 RX01 floppy disk controller
M7860 X 2 – U – DR11-C M786+M105+M7821; general device interface to PDP11
M7864 – U – DR11-L DR11-L, 2 word unibus input interface
M7946 – Q – RXV11 RX01 8″ floppy disk controller
M8020 – Q – DPV11-M Single-line serial EIA sync interface
M8300 – O – KK8E Major registers
M8310 – O – KK8E Major register control
M848 X 2 – O – KP8E Power fail and auto-restart
M8554 – U – DTE20 (Unibus Interrupt Control) [ KL-10D ]
M8946 – Unknown
M8951 – Unknown
M920 – U – UNIBUS connector
M930 X 5 – U – Bus terminator
M9312 – U – Bootstrap terminator
M9396 – Unknown
M935 X 2 – OMNIBUS bridge
M981 – Unknown
M9970 – U – M997, H854 Facing Edge

I archived them using John Wilsons excellent PUTR utility using a PC fitted with a 5.25″ floppy drive (as drive B:). Here is the process I used:

• Start up PUTR
• Mount the RX50 in foreign mode with:MOUNT B: /FOREIGN /RX50
• Then for each floppy:COPY/DEV/FILE B: [imagename]

Here are the initial set of disk images I have created. I’ve not had a chance to look at them in detail, but there looks like there is plenty of stuff that is of interested to the general community:

I have the following to work my way through:

• 40 RL02 packs
• 24 RL01 packs
• ~250 RX01 and RX02 floppies
• ~100 RX50s
• 24 TU56 tapes
• ~100 TU58 tapes
• 28 RK05 packs

Software wise, these will yield a mixture of XXDP, RT-11, RSX-11/M, RSX-11/M PLUS, and Unix software. As I complete them I will put any useful finds online to download for others to use.

The lid was then removed and the innards cleaned out. All the sound proofing foam was removed as it had started to turn to mush. A couple of the mounting pillars which hold the lid to the case have sheered off and so these will need to be glued back into place.

With the terminal cleaned, power was cautiously applied and the voltages confirmed to be correct.

Having confirmed the power was ok, paper was loaded and a serial loop back plugged into the serial port and the terminal was powered back on. Typing on the keyboard resulted in activity from the print head although no actual print (the ribbon was dried out). I then help SETUP and T together to put the console into test print mode and the head went into over overdrive and slowly but surely the ribbon started to deliver ink. The print quality is fairly good, although the first row appears to be dead.

Next on the todo list is to fit a new ribbon (I have 4 on the way) and see if I can restore line 1 to life.

[Show as slideshow]

I plan to use the TC11 and TU56 on my forthcoming 11/40 rebuild.

TC11

TU55

TU55

TU55

This has largely been a painless process, largely aided by the set of LSI-11 maintenance manuals I recently got hold of. Compared with their large UNIBUS brothers, the QBUS family of machines are relatively easy to rebuild as the backplanes are much simpler with no wirewrap and much more generalistic (there are no slots dedicated to a particular peripheral). Often its just a case of planning the board layout using a simple set of rules to determine their placement and all fires up well. When it doesn’t it is often just a case of reducing the setup to a simple working configuration and building it back up from there.

For anyone attempting to rebuild a QBUS machines, here are my tips:

1. If you machine is already populated with boards, carefully take note of the locations of each board in your system and then strip all the boards out.
2. Carefully clean/vacuum the chassis to remove any crud/hair/dust that has built up within it
3. Apply power to the empty chassis, for 5 seconds, 10 seconds, 30 seconds, 1 minute to confirm the power supply is working. Check the fans are all spinning whilst doing this.
4. With a multimeter, check all the DC voltages coming from the PSU
5. If all is well, start with a simple setup of a CPU, memory, SLU and bootstrap. If you are lucky you may have a CPU board with onboard bootstrap and SLU (KDF-11B or KDJ-11B), in which case you will just have to insert 2 cards.
6. Hook up a console and setup it to the appropriate baud rate for your SLU (9600 baud is the most common if you don’t know this), set your HALT switch to the down (halt) position.
7. Power on the machine. If all goes well you should see:173000
   @
8. This is an ODT prompt, an interactive utility that allows you to toggle code into memory and start the CPU running.
9. Confirm you can write to memory by depositing some values and reading them back. For example:@1000/ 0000000 123123
   @1000/ 123123

   In the above, the bolder characters are what you need to type. This deposited the value 123123 into location 1000 and then read it back (confirming that the value we had deposited had correctly been stored into memory). Try it for a few locations

10. If all is well, move the HALT switch to the up position (non-HALTED) and hit restart. If all is well, the machine should now start its bootstrap. If you have a bootstrap board or a KDF-11B you should see a "START ?" prompt. If you have a KDJ-11B, you should see a countdown as it steps through its diagnostics before giving you a menu of options.
11. If this fails, then you need to look at the status LEDs on your various boards to get clues as to the nature of the failure. These vary from CPU to CPU:
    • KDJ-11B: This has the best diagnostic output in the form of a seven segment display. This should give you a hex number detailing the nature of the problem. If you refer to uPDP-11 documention you should find a table of codes detailing the nature of the fault.
    • KDJ-11A: 4 LEDs on the CPU card should give you a rough indication of the fault
    • KDF-11B: 4 LEDS on CPU