In our last exciting episode, after a minor setback I got the Lambda’s SDU to load programs from 9-track tape. Now it’s time to see if I can actually test the hardware with the available diagnostics.
Tape Images
Tape images of the Lambda Release and System tapes are available online. Daniel Seagraves has been working on updating the system and has his latest and greatest are available here. A tape image is a file that contains a bit-for-bit copy of the data on the original tape. Using this file in conjunction with a real 9-track drive allows an exact copy of the original media to be made. In my case, I have an HP 7980S 9-track drive connected to a Linux PC for occasions such as these. At the museum we have an M4 Data 9-track drive set up to do the same thing. The old unix workhorse tool “dd” can be used to write these files back to tape, one at a time:
$ dd if=file1 of=/dev/nst0 bs=1024
(Your UNIX might name tape devices differently, consult your local system administrator for more information.)
Data on 9-track tapes is typically stored as a sequence of files, each file being separated by a file mark. The Lambda Release tape contains five such files, the first two being relevant for diagnostics and installation, and the remainder containing Lisp load bands and microcode that get copied onto disk when a Lisp system is installed.
The first file on tape is actually an executable used by the SDU — it is a tiny 2K program that can extract files from UNIX tar archives on tape and execute them. Not coincidentally, this program is called “tar.” The second tape file is an actual tar archive that contains a variety of utility programs and diagnostics. Here’s a rundown of the interesting files we have at our disposal:
- 3com – Diagnostic for the Multibus 3Com Ethernet controller
- 2181 – Diagnostic for the Interphase 2181 SMD controller
- cpu – Diagnostic for the 68010 UNIX processor
- lam – Diagnostic for the Lambda’s Lisp processors
- load – Utility for loading a new system: partitioning disks and copying files from tape.
- ram – Diagnostic for testing NuBus memory
- setup – Utility for configuring the system
- vcmem – Diagnostic for testing the VCMEM (console interface) boards.
The unfortunate thing is: there is no documentation for most of these beyond searching for strings in the files that might reveal secrets. Daniel worked out the syntax for some of them while writing his LambdaDelta emulator, but a lot of details are still mysterious.
In case you missed it, I summarized the hardware in the system along with a huge pile of pictures of the installed boards in an earlier post — it might be helpful to reacquaint yourself to get some context for the following diagnostic runs. Plus pictures are pretty.
I arbitrarily decided to start by testing the NuBus memory boards, starting with the 16mb board in slot 9 (which I’d moved from slot 12 since the last writeup). The diagnostic is loaded and executed using the aforementioned tar program as below. The “-v” is the verbose flag, so we’ll get more detailed output. the “-S 9” indicates to the diagnostic that we want to test the board in slot 12.
SDU Monitor version 102 >> reset >> /tar/ram -v -S 9 ram: error 6 test 1 bad reset state, addr=0xf9ffdfe0, =0x1, should=0x4 ram: error11 test 3 bad configuration rom ram: error 1 test 6 bad check bits 0xffff, should be 0xc, data 0x0 ram: error 1 test 7 bad check bits 0xffff, should be 0xc, data 0xffffffff ram: error 7 test 8 for dbe w/flags off, DBE isn't on ram: error 7 test 9 for dbe w/flags off, DBE isn't on ram: status fill addr 0xf9000000 ram: status fill addr 0xf9002000 ... [elided for brevity] ... ram: status fill addr 0xf903c000 ram: status fill addr 0xf903e000 ram: status fill check addr 0xf9000000 ram: status fill check addr 0xf9002000 ... [elided for brevity] ... ram: status fill check addr 0xf903c000 ram: status fill check addr 0xf903e000
Well, the first few lines don’t look exactly promising what with all the errors being reported. The test does continue on to fill and check regions of the memory but only up through address 0xf907e000 (the first 512KB of memory on the board, that is). Thereafter:
ram: status fill check addr 0xf907c000 ram: status fill check addr 0xf907e000 ram: status block of length 0x4000 at 0xf9000000 ram: status stepsize 4 forward ram: error 4 test 16 addr 0xf9000004 is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf9000008 is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf900000c is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf9000010 is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf9000014 is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf9000018 is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf900001c is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf9000020 is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf9000024 is 0xffffffff sb 0x0 (data f/o) ram: error 4 test 16 addr 0xf9000028 is 0xffffffff sb 0x0 (data f/o)
And so on and so forth, probably across the entire region from 0xf9000000-0xf907ffff. This would take a long time to run to completion (remember, this output is coming across a 9600bps serial line — each line takes about a second to print) so I wasn’t about to test this theory. The output appears to be indicating that memory reads are returning all 1’s (0xffffffff) where they’re supposed to be 0 (0x0).
So this isn’t looking very good, but there’s a twist: These diagnostics fail identically under Daniel’s emulator. After some further discussion with Daniel it turns out these diagnostics do not apply to the memory boards I have installed in the system (or that the emulator simulates). The Memory boards that were available at the time of the Lambda’s introduction were tiny in capacity: Half megabyte boards were standard and it was only later that larger (1, 2, 4, 8, and 16mb boards) were developed. The only memory boards I have are the later 4 and 16mb boards and these use different control registers and as a result the available diagnostics don’t work properly. If there ever was a diagnostic written for these newer, larger RAM boards, it has been lost to the ages.
This means that I won’t be able to do a thorough check of the memory boards, at least not yet. But maybe I can test the Lisp CPU? I slotted the RG, CM, MI and DP boards into the first four slots of the backplane and started up the lam diagnostic program:
SDU Monitor version 102 >> reset >> /tar/lam -v /tar/lam version 6 compiled by wer on Wed Mar 28 15:24:02 1984 from machine capricorn setting up maps initializing lambda starting conreg = 344 PMR passed ones test passed zeros test TRAM-ADR passed ones test passed zeros test TRAM passed ones test passed zeros test loading tram; double-double disk timed out; unit=0x0 cmd=0x8F stat=0x0 err=0x0 disk unit 0 not ready can't open c.tram-d-d SPY: passed ones test passed zeros test HPTR: Previous uinst destination sequence was non-zero after force-source-code-word during lam-execute-r Previous uinst destination sequence was non-zero after force-source-code-word during lam-execute-r Previous uinst destination sequence was non-zero after force-source-code-word ... [and so on and so forth] ...
Testing starts off looking pretty good — the control registers and TRAM (“Timing RAM”) tests pass, and then it tries to load a TRAM file from disk. Aww. I don’t have a disk connected yet, and even if I did it wouldn’t have any files on it. And to add insult to injury, as it turns out even the file it’s trying to load (“double-double”) is unavailable — like the later RAM diagnostics, it is lost to the ages. The TRAM controls the speed of the execution of the lisp processor and the “double-double” TRAM file causes the processor to run slowly enough that the SDU can interrogate it while running diagnostics. Without a running disk containing that file I won’t be able to proceed here.
So, as with the memory I can verify that the processor’s hardware is there and at least responding to the outside world, but I cannot do a complete test. Well, shucks, this is getting kind of disappointing.
The vcmem diagnostic tests the VCMEM board — this board contains the display controller and memory that drives the high-resolution terminals that I restored in a previous writeup. It also contains the serial interfaces for the terminal’s keyboard and mouse. Perhaps it’s finally time to test out the High-Resolution Terminals for real. I made some space on the bench next to the Lambda and set the terminal and keyboard up there, and grabbed one of the two console cables and plugged it in. After powering up the Lambda, I was greeted with a display full of garbage!
This may not look like much, but this was a good sign: The monitor was syncing to the video signal, and the display (while full of random pixels) is crisp and clear and stable. The garbage being displayed was likely due to the video memory being uninitialized: Nothing had yet cleared the memory or reset the VCMEM registers. There is an SDU command called “ttyset” that assigns the SDU’s console to various devices; currently I’d been starting the Lambda up in a mode that forces it to use the serial port on the back as the console, but by executing
>> ttyset keytty
The SDU will start using the High-Resolution terminal as the console instead. And, sure enough, executing this caused the display to clear and then:
There we are, a valid display on the screen! The keyboard appeared to work properly and I was able to issue commands to the SDU using it. So even without running the vcmem diagnostic, it’s apparent that the VCMEM board is at least minimally functional. But I really wanted to see one of these diagnostics do its job, so I ran it anyway:
SDU Monitor version 102 /tar/vcmem -v -S 8 vcmem: status addr = 0xf8020000 vcmem: status fill addr 0xf8020000 ... [elided again for brevity] ... vcmem: status fill addr 0xf803e000 vcmem: status fill check addr 0xf8020000 vcmem: status fill check addr 0xf8022000 vcmem: status fill check addr 0xf8024000 vcmem: status fill check addr 0xf8026000 ... vcmem: status fill check addr 0xf8036000 vcmem: status fill check addr 0xf8038000 vcmem: status fill check addr 0xf803a000 vcmem: status fill check addr 0xf803c000 vcmem: status fill check addr 0xf803e000
As the test continued, patterns on the screen slowly changed, reflecting the memory being tested. Many different memory patterns are tested over the next 15 minutes.
vcmem: status movi block at 0xf803c000 vcmem: status movi stepsize 2 forward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 vcmem: status movi stepsize 2 backward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 vcmem: status movi stepsize 4 forward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 vcmem: status movi stepsize 4 backward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 vcmem: status movi stepsize 8 forward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 vcmem: status movi stepsize 8 backward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 ... [elided] ... vcmem: status movi stepsize 4096 forward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 vcmem: status movi stepsize 4096 backward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 vcmem: status movi stepsize 8192 forward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000 vcmem: status movi stepsize 8192 backward vcmem: status movi checking 0x0000 writing 0xffff vcmem: status movi checking 0xffff writing 0x0000
And at last the test finished with no errors reported, leaving a test pattern on the display. How about that, a diagnostic that works with the hardware I have.
Looking crisp, clear, and nice and straight. This monitor is working fine — what about the other one? As you might recall, I got two High-Resolution Terminals with this system and pre-emptively cleaned and replaced all the capacitors in both of them. The second of these would not display anything on the screen when powered up (unlike the first) though I was seeing evidence that it was otherwise working. Now that I’d verified that the VCMEM board was working and producing a valid video signal, I thought I’d see if I could get anything out of the second monitor.
Lo and behold: it works! I soon discovered the reason for the difference in behavior between the two monitors: The potentiometer (aka “knob”) that controls the contrast on this display is non-functional; with it turned up on the first monitor you can see the retrace, with it turned down it disappears. Interestingly the broken contrast control doesn’t seem to have a detrimental effect on the display, as seen above.
So that’s a VCMEM board, two High-Resolution Terminals, and the keyboard tested successfully, with the CPU and Memory boards only partially covered. I have yet to test the Ethernet and Disk controllers. The 3com test runs:
SDU Monitor version 102 >> /tar/3com -v 3com: status Reading station address rom start addr=0xff030600 3com: status Reading station address ram start addr=0xff030400 3com: status Transmit buffer: 0xff030800 to 0xff030fff. 3com: status Receive A buffer: 0xff031000 to 0xff0317ff. 3com: status Receive B buffer: 0xff031800 to 0xff031fff. 3com: status Receive buffer A - 0x1000 to 0x17ff. 3com: status Receive buffer B - 0x1800 to 0x1fff. >>
No errors reported and the test exits without complaining so it looks like things are OK here. Now onto the disk controller. I don’t have a disk hooked up at the moment, but after a bit of digging into the test’s binary, it looks like the “-C” option should run controller-only tests:
SDU Monitor version 102 >>/tar/2181 -C Initializing controller 2181: error 3 test 0 Alarm went off - gave up waiting for IO completion 2181: error 3 test 0 Alarm went off - gave up waiting for IO completion 2181: error 10 test 0 no completion (either ok or error) from iopb status iopb: cyl=0 head=0 sector=0 (TRACK 0) 87 11 00 00 00 00 00 00 00 00 00 00 10 00 c5 62 00 40 00 00 00 00 c5 3a 2181: error 3 test 0 Alarm went off - gave up waiting for IO completion 2181: error 3 test 0 Alarm went off - gave up waiting for IO completion 2181: error 10 test 0 no completion (either ok or error) from iopb status iopb: cyl=0 head=0 sector=0 (TRACK 0) 87 11 00 00 00 00 00 00 00 00 00 00 10 00 c5 62 00 40 00 00 00 00 c5 3a 2181: error 3 test 0 Alarm went off - gave up waiting for IO completion 2181: error 3 test 0 Alarm went off - gave up waiting for IO completion 2181: error 10 test 0 no completion (either ok or error) from iopb status iopb: cyl=0 head=0 sector=0 (TRACK 0) 87 11 00 00 00 00 00 00 00 00 00 00 10 00 c5 62 00 40 00 00 00 00 c5 3a 2181: error 3 test 0 Alarm went off - gave up waiting for IO completion
This portends a problem. The output seems to indicate that the test is asking the controller to do something and then report a status (either “OK” or “Error”) and the controller isn’t responding at all within the allotted time, so the diagnostic gives up and reports a problem.
This could be caused by the lack of a disk, perhaps the “-C” option isn’t really doing what it seems like it should, but my hacker sense wass tingling, and my thought was that there was a real problem here.
Compounding this problem is a lack of any technical information on the Interphase SMD 2181 controller. Not even a user’s manual. The Lambda came with a huge stack of (very moldy) documentation, including binders covering the hardware: “Hardware 1” and “Hardware 3.” There’s supposed to be a “Hardware 2” binder but it’s missing… and guess which binder contains the 2181 manual? Sigh.
There are two LEDs on the controller itself and at power-up they both come on, one solid, one dim. In many cases LEDs such as these are used to indicate self-test status — but lacking documentation I have no way to interpret this pattern. I put out a call on the Interwebs to see if I could scare up anything, but to no avail.
Looks like my diagnostic pass at the system was a mixed bag: Outdated diagnostics, meager documentation, and what looks like a bad disk controller combined with the success of the consoles and at least a basic verification of most of the Lambda’s hardware.
In my next installment, I’ll hook up a disk and see if I can’t suss out the problem with the Interphase 2181. Until then, keep on chooglin’.
