11/93 Rebuild - SCSI HD now boots RT11
allisonportable at gmail.com
Fri May 31 15:20:47 CDT 2019
On 05/31/2019 03:27 PM, Rod Smallwood via cctalk wrote:
> On 31/05/2019 19:40, allison via cctalk wrote:
>> On 05/31/2019 02:04 PM, Rod Smallwood via cctalk wrote:
>>> Well I now have a bootable SCSI drive on my 11/93. Its not RSTS/E
>>> (yet) but it is RT 11 and reliable.
>>> Its a bit baseline but it runs.
>>> So next up was to see if we could get the RQDX3 to co-exist with the
>>> SCSI controller.
>>> I switched the base address to 160336 and it does not stop the SCSI
>>> drive booting as DU0.
>>> Had the RQDX3 been on the normal base address I think you would get the
>>> HD as DU0 and the two halves of an RX50 as the next two drives.
>>> But what happens to the RX50's when you move the RQDX3 to 160336 ?
>> Under RT-11 you have to do a SET CSR and sometimes Vector when you move
>> a device off the default. Its how I could have two DD (tu58) on teo
>> serial ports. Same for RX02, RL02, with RQDX3 (with RD52 and RX33)
>> where the RQDX was set to a nonstandard address.
>> As I remember the CMD controller is nominally the same as RQDX3 for the
>> same address. so likely RQDX at the secondary address (see the manual)
>> will be treated well if not use the set utility. It only comes to mind
>> as I had two RQDX3s in one machine to make RD52 to RD52 copies at one
>> point. Also my BA123 uVAX-II has both CMD SCSI controller (Rz56 x2) and
>> RQDX3 for RD52 wher the RD52 was the swap and page disk (QD540s are fast
>> but only 31mb) and by having independent channels helped with system
>> RSTS/E the conventions for non standard device addresses are different
>> but there is a mechanism for addressing that. I've not used that.
>> Any of the PDP11 unix again there is a way but the process varies with
>> version and is unknown to me. I tried once to get V^ to talk to more
>> than RL02.
>> In the end first make sure you using the suggested secondary controller
>> address. Then use the OS dependent tools for installing additional
> OK lets see if I can understand whats going on.
> 1. The CQD sits at the normal 17772150 base address
> 2. RQDX3 is at the alternate 17760334 base address.
OK good address and non interfering.
> 3. The map function in the 11/93 monitor sees both
> 4. The SCSI drive boots RT11 with the RQDX3 in place.
OK that means the RQDX is not causing issues but likely the
OS does not see it as the DU/DUX driver is not configured to
see that address and the 11/93 map function does not communicate
with the OS. So unless the OS is told that RQDX3 is additional
334Q address its not even going to bother with it or by it.
> 5. So if I connect an RX50 through the cable splitter as normal then
> what device(s) is(are) the RX50
No idea, until you set the du1 (the other is du0 I memory hasn't
croaked) its a non sequitur.
So at the prompt >set du1 CSR=17760334< or something along those
lines (syntax) will connect the controller to the OS. At this
point since I've not done it in a decade you may need to init
the device and media, copy stuff to it then set the boot device.
Beats me! Never got a 11/93. Latest Qbus-11 I have is a J11 -11/73
the smaller dual width card (no PMI). Never seen the map function.
However having said that, the CPU may know what disks are there but
once the boot operating gets to the disk resident boot then the OS
has to be up to it meaning all the initial setups in place or if the
device was bootable a script (or manual entry) that loads and set up
everything. That much is certain for RT-11. For example I run RT11XM
from VM: [memory disk], however first you have to init VM: and put stuff
there and set it up so you can boot it. So happens I do that from DD
(tu58 tape) but I've done it from RX02, RL02, and DU.
For RSTS and others the game is different but you first muct boot from a
device already know to the copy of the OS on a device that the system
knows how to boot from.
One thing that is consistent is that the boot for any device is often
the same in that it calls for the device to access the bootable track
and sector or base LBA, the MSCP devices [cmd or RQDXn] have their own
thing where the controller knows the place for a given media it can use.
In that case the system boot in rom is a message to "give me the boot
block at xxxxxx ram address" and transfers to that.
More information about the cctalk