23 Jun
2014
23 Jun
'14
4:28 a.m.
Pete Turnbull wrote:
On 20/06/2014 01:42, Peterson, Roe (LAI) wrote:
Which is why I asked Roe for the details of which version
of RT-11 and which monitor (Mapped or UnMapped) was
being used.
The real problem, as I mentioned in passing, was that DEC
never provided the feature:
SET device: NAME
to support multiple controllers so that:
COPY SY:DU(X).SYS SY:SC(X).SYS
SET SC: NAME (this command does NOT exist)
SET SC: CSR=160334 (this command does exist)
SET SC: VECTOR=130 (this command does exist)
could be used to set up additional device drivers for other
CSR / VECTOR pairs.
Another feature that was also missing until V05.06 was the
code to boot a non-zero partition. Prior to V05.06 of RT-11
(starting with V05.03 of RT-11 when partitions were first
supported for the MSCP device driver), all DEC versions
of the MSCP device driver supported non-zero partitions
as DATA ONLY.
And finally, even with V05.05 to V05.07 of RT-11, for
the DEC version of the MSCP device driver, ONLY the
first eight logical device names (DU0: to DU7:) can be
booted in any case even though with extended device
driver support, 64 partitions are available (D00: to D77:)
to be used starting with V05.05 of RT-11. The extra
code to support booting from all 64 partitions is not
difficult. What I found impossible was to support more
than one controller and still fit the code, and especially
the SET tables, within the single boot block allowed for
the device driver. The end result was just (with zero
words left over) able to fit, and even then the unit table
within the boot block had to be reduced to byte entries
Does anyone have RT-11 actually running with two
MSCP disk
controllers?
My 11/83 has a CMD CQD220A/TM at 172150, and an RQDX3 at 160334. The
rqdx3 has an rx33 floppy drive, and is set for starting LUN 4.
No matter what I do, RT-11 simply won't see the floppy.
I think but am not 100% sure I've run RT-11 with two MSCP controllers,
but I do know that the RT-11 DU: driver before 5.2 (or was 5.2 the last
broken one?) is broken and doesn't recognise an RQDX3 properly. I spend
a week once, tracking that down and making a patch for it. In essence,
the earlier drivers assumed a status register would be zero after
initialisation (which it is on RQDX1 and RQDX2), and checked for that
instead of checking the specific bits the MSCP spec calls for. One of
the other bits is non-zero on an RQDX3.
from the standard word entries in the other tables in
the
device driver.
At the time, I had not yet managed to think of the feature:
SET device: NAME
so an additional tiny file of parameters was used at
SYSGEN time to change the values that the NAME
feature would modify. MANY years later, I found I
needed the NAME feature again when I modified John
Wilson's code for HD.MAC and wanted a substitute
for the VM(X).SYS device driver which would be faster
and MUCH larger than is possible using real DEC
hardware and just a 4 MB memory as opposed to
the GB memory available now under current Windoze
hardware when Ersatz-11 is used to run RT-11 as
opposed to real DEC hardware. Of course, SimH
could also support an HD: device, but I have never
had the urge to figure out the needed code.
Even real DEC hardware could also have a custom
controller to support an HD: device, but since I am
not a hardware individual, I have never even considered
the possibility. Has anyone else? I ask a hardware
question so rarely, so perhaps when I do, one of
the really clever individuals who knows hardware
quite well could make a modest effort to determine
what might be needed to support an interface to
a current SATA hard drive of a TB which would
be able to interface a Qbus on a PDP-11. A bit
of overkill, obviously, considering what DEC ever
supported on a PDP-11.
Jerome Fine