Debugging Emulex UC07 SCSI in PDP-11/03

I've just bought an Emulex UC07 MSCP-compatible SCSI controller via eBay, and I'm trying to use it in my PDP-11V03-L system. It's not working for me, and I'd like to try to figure out whether it's a bad UC07, malfunctioning operator, or other problem with my system before I contact the eBay seller about it.

I was initially able to enter F.R.D. (the built-in configuration utility) after a few false starts, but now I can't even do that. The board passes its self-checks, the status register appears to contain the right value, and the troubleshooting flow chart in the UC07 manual leads me to "Call Emulex for support". Right…

I think that I have the UC07 jumpered correctly. Terminator power is on, all DIP switches are off except for 5 and 6 on the larger one (to enable MSCP mode and LSI-11 autoboot mode), and interrupt priority is set to the default position. I removed wire W6 (W5 was already removed) on the CPU board to select Mode 0. When I go through the ODT incantation to enter F.R.D., the UC07 status register values appear to indicate that it correctly copied its code into RAM, but when I jump to the code, it either keeps running without any terminal response or it halts to ODT at various addresses. As I said, I was originally able to enter F.R.D. a few times, so it at least was sorta-working… but now I can't get into F.R.D at all.

I've experimented with different backplane slots with no luck, and I've tried swapping out my RAM board with another (untested) one, also with no change in behavior. I presently have these cards in the backplane, from top to bottom:

1. M7270 LSI-11/02 CPU
2. M8044-DB 32k-word RAM
3. UC07
4. M8029 RXV21 RX02 controller
5. M8043 DLV11-J quad async port
6. empty
7. empty
8. empty
9. M8012-YA BDV11 bootstrap/terminator

My SCSI device is an Aztecmonster CF board. I was not able to get it to respond when I managed to get F.R.D. running, but that may be a separate issue since I also couldn't get it to work properly in my Amiga 3000. For now, I have the SCSI cable unplugged at the UC07 end. I've ordered a couple of SCSI2SD boards to try out.

To make things even more fun, my RX02 drive 0 seems to be flaky, so I can't reliably boot to RT-11 from floppy right now. I haven't seen any other signs of problems with the system.

Are there any obvious mistakes in what I'm trying to do? Does anybody have suggestions for other things to try?

The only suggestions I have is to try to simplify things as much as possible when debugging the basic F.R.D. operation.

Remove the M8029 RXV21 (and shift up the M8043 DLV11-J).
Disable autoboot on the UC07.
Configure the CPU to power-up mode 1, directly into ODT.

If you still can't reliably get into F.R.D. on the UC07 after that I don't know what else could be done to simplify your configuration for test purposes.

Thanks, I'll try that. I guess if it still doesn't work, then I'll try to find some way to test out my CPU and RAM to make sure they have no problems, and then contact the seller if my system seems to be working 100%. I can boot from tu58em if needed.

Have you tried without the BDV11 installed and the UC07 being the last board i.e. CPU, memory, DLV11, UC07?

I have not tried that. With the BDV11 removed, the bus would be unterminated.

I know that in smaller systems,
with the 4-slot H9270 backplane, for example,
you can usually run without termination.

You may be able to get away without the termination,
if only for testing purposes. It might help to eliminate
any possible interference from the BDV11.

(Even though I am assuming that you've
disabled ALL of the BDV11 bootstrap and testing functionality. . .)

I forgot -- is your BDV11 set to terminate BDAL18 - BDAL21 ?




T

It's an 18 bit backplane, I think. 9 slots, Q18-CD configuration. So I don't know what's there for the BDAL18-21 signals. I'll go study the LSI-11/02 and BDV11 prints to see what's going on there…

BTW, no luck in the reduced configuration that gslick suggested.

have you tried without the BDV11?

The BDV11 prints show that it terminates BDAL18-21. I don't have prints for my LSI-11/02 processor board, so I don't know if it's doing anything bad with those lines. Hmm, I think I have an M9300 bus terminator. Maybe I could try replacing the BDV-11 with that so the bus is terminated and no boot PROMs are present.

NF6X said:

Hmm, I think I have an M9300 bus terminator. Maybe I could try replacing the BDV-11 with that so the bus is terminated and no boot PROMs are present.

Click to expand...

Brain fart! That's a Unibus terminator.

Removing the BDV11 doesn't help. I verified again that I can boot RT-11 from tu58em. Well, I guess I need to contact the seller and see if he'll exchange the board for a different one.

If only you had picked up a Q-Bus MicroVAX you'd have another system to double check things with.

LOL! But seriously, I'll probably want to add some sort of disk emulation to the Unibus 730 to save wear on the drives...

I didn't mean to suggest that you should have picked up a Q-Bus MicroVAX instead of your Unibus 11/730, but rather that you could pick one up in addition to it. You can never have too many. (Well, I suppose you can, but it takes a while to get to that point...)

Oh, I understood. I have a PDP-11/44 project and a PDT-11 project (or is it VT-103? Manuals say VT-103, name plate on the front says PDT-11). So, I'll have some redundancy in both the Unibus and Qbus departments eventually.

I've found that the Quad CPU modules (11/23+, 11/73+)
are very helpful to have, because of the diagnostics.

In particular, the "memory map" function is great,
since you can pop in (some) unknown boards,
and see what address/CSR it's sitting at.




T

I might have a quad width CPU board or two in my pile. I ought to try them out.

I can tell that the UC07 is at the proper address and is responding, at least, but things go downhill when I try to run the code that it DMAs into RAM.

NF6X said:

When I go through the ODT incantation to enter F.R.D., the UC07 status register values appear to indicate that it correctly copied its code into RAM, but when I jump to the code, it either keeps running without any terminal response or it halts to ODT at various addresses. As I said, I was originally able to enter F.R.D. a few times, so it at least was sorta-working… but now I can't get into F.R.D at all.

Click to expand...

AFAIK the UC07 will use NPR/DMA to transfer the F.R.D into memory. Since the RX02 also use NPR it may be some problem with NPR in your system. Can you run the RX02 diagnostics to verify its operation?

When the UC07 has transferred the F.R.D into memory does it show valid instructions? Or is it just random data? Try disassembling the dump you could get from odt.

Thanks for the suggestions! If both my UC07 and RX02 problems have a common root cause such as flaky NPR/DMA, then maybe I can fix both at the same time. I haven't used XXDP before, so I'll need to figure out how to boot it up and use it. I think I'll dig out my quad width CPU board(s) and try them out first. I have a couple of spare LSI-11/02 boards, but one failed to come up with an ODT prompt, and the other is marked "NFG DO NOT USE" so I didn't even try it.

If you have never run XXDP on the system you should really do that before going any further. At least run both CPU and memory diagnostics and make sure those pass.