Bill,
What are you doing with Switch 7?
You want SW7 OFF (i.e. don't inhibit end of pass message).
If SW7 is ON - you will get nothing on the console at the end of the pass and you have to infer it is working by not getting any halts or error printouts.
Diagnostics - by their nature need to be terse and wonderfully intuitive
! If they require too much of the machine to be operational - then they will probably never work - as the reason for using the diagnostics is that the machine itself is suspect. Writing 'good' diagnostics is an art form - you have to start out assuming that everything is/could be faulty and have to 'prove' things are working from the ground upwards. For example, the PDP-8 diagnostics HALT when they detect an error (the HALT address being the key error indicator). But - how do we know that the HALT instruction actually works? The first diagnostic for the PDP-8 clears the accumulator and then HALTS. If it doesn't halt at the correct address with the ACCUMULATOR cleared - then this is an error! We now have a good 'feeling' that the HALT instruction works and we can use it to indicate subsequent errors.
Unfortunately, you need the exact same documentation that goes with the diagnostic you have. In PDP-8 land this was because the address of the HALT instruction indicated the problem.
The PDP-11 variant appears to be more complex than the earlier PDP-8 and you should setup the switches to display the textual messages associated with the error. The messages may seem terse to you - but believe me when I say they are better than a HALT address and trying to decode what went wrong.
As to time - good diagnostics take time. One of our memory diagnostics takes 98
hours to test 512 KBYTES of DRAM. We also have a simple memory diagnostic that takes a few minutes - but guess what - it misses subtle errors in the RAM card. We tested 150 odd memory cards a while ago - and only one was faulty. The 98 hour diagnostic found it - the simple one didn't... Go figure.
The diagnostic should print a message (and the pass number) at the end of the pass (if enabled). If not - this should be considered a diagnostic failure. Unfortunately, some faults will result in the diagnostics failing to report errors - been there seen that. The CPU ends up erroneously looping because of (say) a JUMP fault.
I am currently restoring an 11/45 that I recently acquired. It will take me some time to get the hardware cleaned up and restored - but I am using the time to locate all the diagnostics and documentation that I can. I will ensure that basic functions of the processor work by writing my own 'simple' programs entered from the front panel. I will also test out the console serial port with a test program of my own. Only then will I start with the diagnostics.
When I was helping Marty out with his PDP-8 build (and I was coding the PDP-8 in LOGISIM) - the PDP-8 diagnostics were invaluable as they identified a few things that didn't work. But we only started to run them when we were sure that the basic hardware did actually work as expected (i.e. the machine must be - say - 95% working to get the diagnostics to work. The diagnostics then found a few things that didn't work).
I agree with swapping boards around to get the system basically to work - but then you have to run the basic diagnostics to give you confidence that the machine is actually working. Even then - you can't be 100% sure...
Don't be disheartened and keep at it. Read the documentation associated with the specific diagnostic and (if it is unclear) ask here and we will help out. The PDP-8 diagnostics were pretty accurate with their estimate of how long they would take - as there were fewer processor options. I agree that the description is (at best) confusing with the PDP-11 one you have identified. Most diagnostics start at low memory and work their way up memory as tests pass (especially if you switch off the relocation feature). I used this fact on the PDP-8 to follow the diagnostic progress. Again - you need a listing to follow.
Also - keep a notebook of everything you try. I started a notebook the day I picked up my 11/45. Every time I do something I note it down in the notebook. In your case, this would include how I loaded something, what the switch settings were and what I observed. As you point out - time seems to be a critical factor; so the time of starting a test and when you stopped it would be something to note down. Machine configuration when you are doing a test (e.g. cards installed, memory etc.). This all may sound like a ball ache - but in a few days or weeks you will want to know what you did and (if you haven't noted it down) you won't be able to remember. Also, when we ask questions like "was SW7 ON or OFF" and "how long did you wait since starting the diagnostic with SW7 OFF" you will be able to give us the answers.
I am not against trying to load RT11 and BASIC - if it works all well and good. But if it doesn't work - this configuration won't tell you anything (hence the reason for the DEC diagnostics in the first place). If you can't get the DEC diagnostics to work (barring not running them correctly of course) I wouldn't expect RT11 or BASIC to work (except by a fluke).
It would appear that most of the 11/40 and 11/45 diagnostics are common - so I will benefit directly from helping out here if I can. Can you provide links to the diagnostic tapes and documentation you are using and I will have a read myself and suggest a few things? If we are using the same things - we have a common frame-of-reference. It might take me a few days to catch up with reading this thread though.
Dave