PDP 11/73 is ALIVE!

From: der Mouse <mouse_at_Rodents.Montreal.QC.CA>
Date: Sun Nov 23 13:33:21 2003

> 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_at_rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received on Sun Nov 23 2003 - 13:33:21 GMT