The VT52 had a broken ESC key, and with RT-11 up and running I was motivated to dig in and fix it (you need that ESC key if you are going to run the K52 editor). Pulling the keycap and giving things a look over, the leaf contacts and the plastic plunger that activate the key looked fine. Need to get at the keyboard module itself to troubleshoot, and on a VT52 that means opening the thing all the way up and pulling the main boards. In we go...

Extracted the keyboard module, powered it from my bench supply, and used a breadboard and some jumpers to drive the key select decoders. Key closure on the back of the module was intermittent, but some flexure of the entire keyboard PCB seemed to be affecting it. Replaced/reflowed the solder on the back of the key switch and that seems to have fixed it.

Back together, working well now. Test drove it for a while under RT-11...

Okay, the system is working well enough now to start attempting recovery and archive of the dozen or so RK05 packs that I have on-hand. These were all obtained (along with the RK05 drives, controller and power supply) in a surplus auction downstream of Stanford's Hansen Experimental Physics Lab, sometime in the early '90s.

The packs date from the mid-70's to early-80's, and the labels indicate contents related to experiments and research projects taking place at the lab at that time. One particular pack seems associated with the Stanford Gravity Wave Project, which built early resonant mass detectors. Other packs labeled "FEL" would be related to early free-electron laser research. Many of the names on the packs are are readily found on related scientific publications from the time.

The process for dealing with these packs involves opening them up for inspection and cleaning before mounting them, with hopes of avoiding beating up or destroying the drive heads and/or media with head crashes. Much has been written about pack cleaning on the classiccmp mailing lists and in the vcfed forums, but briefly the process involves some clean-room gloves, lint-free wipes, and anhydrous isopropyl alcohol. The outside of the pack is first cleaned of dust and grime, then the packs are opened and inspected and the disk surfaces given a scrub with the wipes and alcohol. If a pack seems in good enough shape to mount, it is spun up and run in a drive with head load disabled for about a half-hour. This gets a good air-flow over the disk to blow out remaining loose particulates and also lets the disk come up to thermal equilibrium. After that the heads are loaded, with a finger standing by on the unload switch in case there are any bad noises...

I've already been dealing with two of the packs extensively during the restoration: one is an RKDP diagnostics pack, and the other was a backup pack of same. I was able to capture a complete, error-free image of the RKDP pack using PDP11GUI. This seems to be an earlier version of this disk that what is already available on bitsavers; I've sent the bits to Al Kossow, but as I understand it his project has a big backlog at the moment so it may be a while before he can consider my submission. In the meantime, for those interested, the disk image is available here.

The RKDP backup disk was used as a test pack during the RK11/RK05 restoration work, and thus was overwritten by the RK05 diagnostic read/write tests. It now contains a bootable RT-11 image, written via PDP11GUI. Mixed results on the other packs so far: some have had severe head crashes (see pic below) or are otherwise damaged to the point that I am hesitant to mount them. Some have been mysteriously unreadable. It looks like I can expect about 50% recovery. Results so far are tabulated here. I hope to be able to make other recovered images available soon, but since they contain original research materials I am trying to contact the authors for permission first.

Not much technical in this post, except the big ticket news: after all the recent repairs and generating a fresh RT-11 pack RT-11 BOOTS FROM DISK!

It's been a very long road getting here, but the machine finally has a working, full-featured, operating system, capable of supporting self-hosted program development. Spent a few enjoyable hours editing, assembling, linking, and debugging some small MACRO-11 hacks directly on the machine, using the native RT-11 tools. This is probably a 40 year high-water-mark of functionality for these particular bits of hardware. Very satisfying!

Next up will be to clean and inspect the dozen or so RK05 packs that I have on hand, and retrieve and archive whatever content I can. That should let me clear off a few packs to create some space to experiment with some additional operating systems, including 6th Edition Unix.

After a lot of recent progress with the RK11, suffered a setback: after trying once again to image a fresh RT-11 pack, the machine began to behave erratically at boot. Sometimes the boot monitor would run fine, sometimes it would run for a while and then take a machine exception or vector off to bad address, and sometimes the machine would fail to boot at all, immediately taking exceptions of various sorts. Getting so close, but then lost a lot of ground; I guess that's sort of the way it is going to be with a machine that is this old...

So, back to the top without a working boot monitor. Microcode sequencing and seemed to be working fine -- exam/deposit/step working reliably from the front panel. Checked execution of the first few instructions of the boot ROM in detail, a branch and some single operand instructions, and they seemed to execute correctly.

Assuming some sort of new failure in the CPU, I prepared to instrument the Unibus with the HP logic analyzer; it seemed that way I could trigger on machine exceptions then look back over the captured address traces for a pattern. To make sense of those, I'd need a listing of the boot ROM in hand. Noel Chiappa has a dump for this and a partial disassembly on his site here, but is it the same as mine? Better check...

Started to run through Noel's listing and compare to the ROM contents on my machine via front panel exam. Sure enough, there seemed to be some words different in a few places. Maybe the CPU is fine, and the ROM card is failing? Swapped out the M9301 for a simpler M792 diode matrix boot ROM, and sure enough -- was able to boot straight away off my RKDP pack, and from there reliably beat up the CPU with diagnostics. So, great news: just a failing M9301!

Alright, so now I want to capture a dump of the M9301 so I can systematically compare with Noel's listing to see if there's a pattern in failed/flaky bits to help guide my repair. For this I need a memory dump utility that I can toggle in from the front panel. Came up with this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

001000  012705  START:  MOV     #177564,R5      ;CONSOLE XCSR
        177564
001004  012700  L0:     MOV     #177570,R0      ;SWITCH REGISTER
        177570
001010  000000          HALT
001012  011004          MOV     @R0,R4          ;READ ADDR FROM SWITCHES
001014  000000          HALT
001016  011003          MOV     @R0,R3          ;READ COUNT FROM SWITCHES
001020  012401  L1:     MOV     (R4)+,R1        ;GET NEXT WORD TO DUMP
001022  012702          MOV     #6,R2           ;SIX DIGITS TO PRINT
        000006
001026  005000          CLR     R0              ;R0 GETS MSB R1
001030  073027          ASHC    #1,R0
        000001
001034  062700  L2:     ADD     #60,R0          ;MAKE INTO ASCII DIGIT
        000060
001040  010065          MOV     R0,2(R5)        ;OUTPUT
        000002
001044  105715          TSTB    (R5)
001046  100376          BPL     .-2
001050  005000          CLR     R0              ;R0 GETS 3 MSB R1
001052  073027          ASHC    #3,R0
        000003
001056  077212          SOB     R2,L2           ;LOOP DIGITS
001060  012765          MOV     #15,2(R5)       ;OUTPUT '\R'
        000015
        000002
001066  105715          TSTB    (R5)
001070  100376          BPL     .-2
001072  012765          MOV     #12,2(R5)       ;OUTPUT '\N'
        000012
        000002
001100  105715          TSTB    (R5)
001102  100376          BPL     .-2
001104  077333          SOB     R3,L1           ;LOOP WORDS
001106  000736          BR      L0              ;START OVER

Executed this a few times and got slightly different results, then things settled into a pattern where the lowest nybble of every word was consistently zeroed but everything else was fine. Smoking gun pointing to a single PROM on the M9301. Pulled and reseated that chip, and did the same for the other three while I was at it, and ... everything 100% after that. Wow, really should have just tried that first...

Well, at least I'm up and running again! The memory dump program might come in useful again at some other time, and as a byproduct after I fixed my M9301 I got 100% agreement with Noel's listing. So I think that listing can be considered authoritative now; good enough to generate replacement PROMs should anybody ever need to do so.

Okay, back from travel and picked up the thread on the RK11 interrupt problem this weekend. Put the KM11 in the first slot on the RK11 which allows to monitor interrupt request. An interrupt can be very easily generated from the front panel by writing bit 6 (Interrupt on Done Enable) on in the RKCS register at 777404. Did this, and noticed that interrupt request logic on the RK11 went active, but never cleared.

Checked bus request and grant continuity all the way through to the CPU backplane and back and that looked fine (the RK11 in its default configuration uses BR5).

Chased bus request with a logic probe all the way to the CPU backplane, and it was being asserted correctly. Looking at BG5, however, I noticed it was always asserted, even if BR5 was inactive. Disconnected all peripherals and terminated the Unibus directly on the CPU backplane, and this was still the case. So there was problem with BG5 in the CPU itself.

Threw the CPU UBC card out on extenders, and took a look at BG5 logic with a logic probe. The 8881 driver for this signal (E42 on sheet UBCD of the engineering drawings) had failed -- pins 8 and 9 were high, but pin 10, BG5, was not being driven low. Pulled this chip, put in a socket and a replacement, and the BG was then working properly. That's three repairs total to this poor old UBC card so far! Was able to then verify from the front panel that the processor fielded interrupt 220 in response to setting the IDE bit in RKCS. Progress!

Back to the MAINDEC ZRKK -- interrupt test now passes, and the diagnostic continues. BUT... error output now on test octal 57, which is working out the "hardware pole" feature of the controller. Thought this might be due to the RK11 being configured for two RK05 drives, but I have restored/connected only the first. Rejumpered the G740 flipchip for a single drive, but this didn't seem to help. Hmmm, will need to read the diagnostic source to see what it is trying to do...

Replaced the failed 7401 in the RKDA to RKDB data path, and verified that the RKDB stuck bit 11 problem was fixed. Ran the system for another couple hours to rewrite a fresh RT-11 pack, then another problem developed: read operations would successfully obtain the bus, but would never complete.

Some investigation with a KM11 on the RK11 controller showed that POLE was now incorrectly asserted continuously (did they mean "poll"?). Tracked this down to a failed 7420 (E1 on the M141 at A26, sheet RK11-C-12). Replaced, and reads were working again. I guess with a machine this age there is going to be a lot of this sort of thing where marginal parts give up after a few hours of use. Hopefully after some prolonged operation things will settle down a little bit...

In any case, still unable to boot any of my RT-11 packs. I Decided to step back and run MAINDEC diagnostic ZRKK. This is the RK11 dynamic diagnostic that destructively modifies a pack, and I had not previously run it -- I had just optimistically jumped to trying to boot existing packs after the drive restore and calibration. The diagnostic ran successfully for a while, through various format and read and write tests over the whole pack (encouraging!), then hung up consistently on test 35 (octal), which tests whether the RK11 interrupts the processor correctly when IDE is set.

So it could be the case that my RT-11 boots hang up when they first start trying to make use of interrupts. Verified that I can run MAINDEC ZKWA, which tests interrupts from the KW11-L line clock, so interrupt fielding in the CPU looks good.

Re-ran MAINDEC ZRKK, and noted that the CPU is waiting in micro-state BRK.00 (154) on page FLOWS 12 of the engineering drawings. This state has a wait for Unibus INTR to be asserted, so it looks like a problem with interrupt signaling on the RK11 side.

I have a bit of travel coming up, so I probably won't get back to this for a week or two. But the next sensible step I think will be to work with a logic analyzer on the backplane of the RK11, slot A6 where the M7820 interrupt control flipchip goes, and see what is/isn't happening with the interrupt signaling on that end. I suspect there will probably be a failed IC on the M7820.

Decided to use the disk utilities provided in PDP11GUI to write a fresh RT-11 pack. PDP11GUI successfully assembled and downloaded a driver, then took a little under 2 hours to download the pack image over the console serial line and write the pack without indicating any errors.

The resulting pack fared no better at boot than any of my existing legacy packs, however. I attempted to verify the pack via PDP11GUI, and noticed that the controller was indicating checksum errors for every sector on cylinders 64-127 and 192-202 (that is, whenever bit 11 of the RKDA was set). Tried this on several other packs, including the RKDP pack which had previously booted, and found that these errors were returned for these cylinders on all packs, so definitely a controller or drive issue, and not specific to any particular pack.

Verified that bit 11 of the RKDA could be read and written normally, and that when so addressed the RK05 drive would mechanically seek to the correct cylinders. Programmed some format-mode reads (these just return sector headers) manually via the front panel, and verified that the sector headers were being returned correctly from disk for the affected cylinders.

Tried a few flipchip swaps to see if the affected bit would move: B18 and B19 (adder; sheet RK11-C-14; no change), A21 and B21 (RKDB; sheet RK11-C-10; no change).

Programmed some all-mode reads (these return preamble, header, data, and postamble) manually via the front panel. These showed that during reads of affected cylinders, bit 11 was stuck always on. When reading unaffected cylinders, bit 11 turned on and off normally. So it seemed bit 11 was "leaking" from RKDA to RKDB.

Seeing this, tried a few more swaps: A15 and B15 (internal bus, sheet RK11-C-20, no change), A23 and B23 (RKDB data path; sheet RK11-C-21; bingo!). Stuck bit went away on this last swap. So it looks like a failed 7401, E2 on the M149 in slot A23. Pulled, socketed, and put some 7401 on order at Jameco where I can pick them up tomorrow on my way in to work. Getting closer!

Took a little of time to sort through BC11 cables to find a good one for drive interfacing, but in the end I found one that worked okay and got the seek tester code from the previous post working reliably. At this point I mounted one of the recently cleaned RK05 packs, but found that the M9301 bootstrap would hang the bus on the first read operation.

A little scoping around on the RK11-C showed that it was asserting NPR to the processor, but never receiving NPG. A quick check of NPG continuity on the backplane showed a missing jumper on one slot of my DD11-D. Wrapped this on, verified NPG continuity all the way out to the RK11, but still no joy. Turns out the CPU is not asserting NPG at all.

Threw the CPU UBC card out on extenders and had a go at chasing though the NPG logic with a logic probe. Turns out to be a failed 8881 bus driver for NPG at the end of the line (E55 on KB11-A drawing UBCD). Pulled, socketed, replaced.

After this, the CPU was asserting NPG, but the signaling still looked a little squirrelly. Turns out that there are jumpers (W1-W5) on the M9301 bootstrap terminator that need to be installed to provide grant pull-ups when they are not otherwise provided internally by the processor (and the 11/45 is one such case). After installing the jumpers, NPG signaling looked solid.

Tried mounting a booting a few packs. Packs marked as having RT-11 would run for a short while and then hang. But an RKDP pack successfully booted! Wow, that feels pretty good after about two years of working seriously on this restoration. :-)

Going to stop here on a high note, and pick up trying to get a good RT-11 boot next time.

Okay, disassembled and cleaned a few RK05 cartidges, following advice from the vcfed forum and cctalk mailing list (cleanroom gloves and wipes, 99% anyhydrous isoprop). Was surprised to find foam inside the hub on the disks (see pic below) but folks on vcfed advise that it is high-density polyeurethane and not subject to decay to the same extent as the other DEC foams, so I left it be.

Mounted one of the cleaned packs, and let it spin in the drive for a few hours with head load disabled in order to get a good flush on the air filtration system, let the various bearings on the drive loosen up, and make sure the replacement head retract batteries got a good charge. Drive ran quiet and balanced.

After that, took a deep breath and let the heads load -- no crash! Proceeded to work through the dynamic off-line calibration procedure for the head positioning servo system. This involves jumpering the control electronics on the drive to strobe simulated cylinder addresses from the sector counter. That provides a convenient source of oscillating seeks that can be used to calibrate the servos. Video here shows head load, a four cylinder oscillating seek, and a scope trace of the resulting sine position output of the electro-optical carriage position sensor:

Surprisingly, after about thirty years of non-operation, all of the servo calibration was within specified error bars, so no adjustments were necessary! At this point I decided to go for broke, cabled the drive to the RK11-C controller and attempted a boot. Some cncouraging front panel indicator activity, but soon halted with a seek error flagged in RKER. Not too surprising.

Okay, on to debugging the drive online with the controller, then. Worked up the following test code, inspired by something in one of the RK05 SPI workbooks. This reads two cylinder addresses from the high and low bytes of the front panel switches, and instructs the controller to instruct the drive to seek alternately between them:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

        177570                          SW=177570
        177400                          RKDS=177400
        177404                          RKCS=177404
        177412                          RKDA=177412
000000                                  .ASECT
        001000                          .=1000
001000  012706  000700          START:  MOV     #700,SP         ;INIT STACK POINTER
001004  013700  177570          L0:     MOV     @#SW,R0         ;RETRIEVE SWITCHES
001010  000300                          SWAB    R0              ;LOWER SWITCHES TO UPPER
001012  004767  000012                  JSR     PC,SEEK         ;DO THE SEEK
001016  013700  177570                  MOV     @#SW,R0         ;RETRIEVE SWITCHES
001022  004767  000002                  JSR     PC,SEEK         ;DO THE SEEK
001026  000766                          BR      L0              ;START OVER
001030  042700  000377          SEEK:   BIC     #377,R0         ;MASK OFF LOWER BYTE
001034  072027  177775                  ASH     #-3,R0          ;SHIFT OVER TO CYL ADDRESS
001040  105737  177404          L1:     TSTB    @#RKCS          ;CHECK RKCS RDY BIT
001044  100375                          BPL     L1              ;LOOP IF BUSY
001046  032737  000100  177400  L2:     BIT     #100,@#RKDS     ;CHECK RKDS ARDY BIT
001054  001774                          BEQ     L2              ;LOOP IF BUSY
001056  010037  177412                  MOV     R0,@#RKDA       ;WRITE SEEK TARGET TO RKDA
001062  012737  000011  177404          MOV     #11,@#RKCS      ;WRITE SEEK CMD + GO TO RKCS
001070  000207                          RTS     PC              ;RETURN TO CALLER
        001000                          .END    START

At first this code was generating no seek activity on the drive. Decided to try swapping out the BC11-A drive cable, and that produced some limited success -- drive seeks, but some bits of the cylinder address are still apparently not making it across the cable.

The BC11-A cables are problematic. They seem flaky and fragile, and many of my spares seem bad. Any given cable may beep out fine on the bench, and yet fail consistently in use... It looks like what's up next is a voyage through my box of spares, swapping in cables looking for one that works reliably. Failing that, I'll need work on some sort of modern replacement, since original BC11-A in good shape are getting hard to find. It will be sad if at the end of this journey I can't boot the machine for mere lack of a good cable between the drives and controller!

A quick note: rejumpered a spare M105 address decoder, and swapped it in for the one that was in the RK11. SSYN waveform is greatly improved (see before/after shots below), so looks like a bad driver on the original M105.