At a time window of 10 microseconds we can examine the various UNIBUS accesses when the CPU starts to execute code from the M9312 BOOT-ROM:
Signals
Involved signals are:
PROCCLK: the CPU clock driving the micro machine.
Addr: the lower 11 bit of an address on the UNIBUS
IOpage: "1", if the bits 17:12 of the UNIBUS address are 776000. Then, the actual UNIBUS address is 776000 + Addr.
IOPage is an auxillary signal generated by the UNIBUS adapter. By condesing 5 upper address lines into one "IOPage" signal, even a small logic analyzers of the "34 channel class" can be used to trace UNIBUS.
Data: the 16-bit UNIBUS DATA lines. They are interpreted at the edge of SSYN. (I cheated a bit: the value labels are painted by myself, since softwre could not write them into the remaining space).
BUScycle: the type of a UNIBUS cycle, as given by the control lines C1 and C0. "0" means DATI (read), "2" means: DATO = write.
MSYNC is the signal from the Bus master(the CPU): to peripherals (here ROM), that Adrress and Control cycle are set up.
SSYNC is signal from the peripheral that it is ready. In case of DATI it has put data onto the BUS, in case of DATO it has accepted DATA and written it to memory or a register.
What you see
Shown are the first UNIBUS accesses after the micro code self test ends (mark "A").
Let's now decode the UNIBUS traffic by hand. Be warned, this is an annoying job! But you have to do it if your PDP-11 is freaking out and you try to debug it.
Because the logic analyzer displays hexadecimal numbers, some re-calculation to octal is needed. And keep in mind that the M9312 boot strap terminator manipulates the regular Power-On sequence.
The address of an UNIBUS cycle is valid if the CPU sets MSYN from Low to High. Data is valid if the bus slave (the BOOT ROM) acknowledges with SSYN going High. All bus cycles are of type "DATI" (BUScycle = 0)
The first three decoded UNIBUS cycles after power-on selftest are these:
Analyzer display |
Interpretation |
||||
Marker |
Addr |
Data |
Addr |
Data |
Info |
B | IOpage, 0x1616 |
0x01E0 | 760000 + 13026 = 773026 |
740 |
Fetch power fail vector 26, |
C | IOpage, 0x1614 |
0xEA10 | 760000 + 13026 = 773024 |
165020 | Power fail vector 24, Load Program counter R7 |
D | IOpage, 0x0A10 |
0x0A03 |
760000 |
5003 |
Fetch instruction pointed to by "765020" is the 18-bit equivalent of Data "5003" is the instruction "clr r3" |
You see: at first the CPU Program Counter and Program Status word are fetched from the power fail vector at address octal 24. The M9312 boot strap terminator overrides these addresses and forces the CPU to load the start vector from 773024 and 773026, which are addresses decoded by the M9312 itself of course.
So the PC is loaded with 165020 by M9312, which is the standard entry point of the BOOT ROM code on the M9312. The logical 16-bit address "165020" is converted to the 18-bit UNIBUS address "765020" by CPU logic, since it points to the IO page.
The start up code executed there is listed in the M9312 Field Maintenance Print Set:
The very first instruction to be executed is indeed a "clr r3" at 165020 !
Speed?
You can also make an estimation of the PDP-11/34's speed now.
Apparently, the machine needs 2.5µs per data fetch from the UNIBUS ... this translates to a frequency of 400kHz, you'd expect the 11/34 to run much faster!
This slow speed is caused by the BOOT ROM. On M9312 the code resides in an 4-bit-width ROM, which must be accessed four-time for every 16-bit access. A typical "price-vs-performance" trade-off. So after the CPU has requested data by rising MSYN, it is waiting for SSYN most of the time. In this period even PROCCLK is stopped, the micro machine is suspended.
Compare the slow frequency of PROC CLK in Phase 3 with that of the micro self test in Phase 2 were the CPU is executing micro code at full speed!