Here is the boot program I'm trying to use:
 Memory Location       Content         Macro Instructions
 ---------------       -------         ------------------
 2000                  5000            Start:  CLR     R0
 2002                  5300            5$:     DEC     R0
 2004                  1376                    BME     5$
 2006                  12706                   MOV     #1070,SP
 2010                  1070
 2012                  12701                   MOV     #172522,R1
 2014                  172522
 2016                  12702                   MOV     #100001,R2
 2020                  100001
 2022                  10211                   MOV     R2,(R1)
 2024                  10211                   MOV     R2,(R1)
 2026                  22711           10$:    CMP     #122204,(R1)
 2030                  122204
 2032                  01375                   BNE     10$
 2034                  12704                   MOV     #MESS+20.R4
 2036                  2062
 2040                  05007                   CLR     PC
 2042                  46523           MESS:   .WORD   46523
                       00001                   .END 
Well, except for s/BME/BNE/ on the third line (address 2004) and
s/.R4/,R4/ on the twelfth (address 2034), this looks not entirely
unreasonable.  With those fixes, and changing the labels, the contents
given match what my assembler produces for that code (except for the
.end line; I don't know why your listing shows a value there).  (I had
to change the labels because my assembler doesn't accept labels
beginning with a digit, and it was easier to change the labels than to
change the assembler.)
  After I typed in the program, I typed 2000G, and it
just hung, the
 RUN light on.  Pressing Break on the terminal stopped it, and it
 printed 2026 on the screen. 
So it had sent the command to the tape but was sitting in the spin loop
at locations 2026 and 2032, waiting for the ack.
Given how small this is, and the control structure of the code, it
appears to be expecting the device at 172552 to DMA some boot code into
low memory; when this is done, as signaled by finding 122204 in what I
assume is the device's CSR, it jumps to it with the CLR PC.
  I don't see any ROMS, there is an empty socket on
the CPU card where
 a ROM might be able to go, and the ROMS on the tape controller are
 factory made (not EPROMS that may have been added later) 
It might be instructive to clear low memory first, then run the above
code, and see if low memory has changed.
For example,
        001764  012700  b:      mov     #b,r0
        001766  001764
        001770  012701          mov     #b/2,r1
        001772  000772
        001774  005040  x:      clr     -(r0)
        001776  077102          sob     r1,x
the rest of the code as above, and then use 1764G.  When you break it,
examine low memory (type 0/ and just hit return a bunch of times).  If
low memory isn't all 0, _something_ has changed it, and if you send me
the contents (a capture of the output when you hit return until you
find a bunch of all-0 memory locations) I can disassemble it for you.
Not that that will _necessarily_ help, but if the disassembly makes
sense, there is an excellent chance the hardware is connected
correctly.
  From what I have been able to tell, in the PDP-11, the
order of the
 cards matters, and their addresses need to be set manually, right?
 How to do this, I'm not sure. 
Order of cards matters in two ways: (1) the bus slots have chained
signals, and if you have any empty slots between the CPU and the last
card, you need to put jumper cards in them to pass along the chained
signals; and (2) card order determines priority for something - I
forget whether it's equal-priority interrupts or DMA bus grants or
what, but you want the cards for which timing is most important to be
closest to the CPU.
/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse(a)rodents.montreal.qc.ca
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B