ajp166 wrote:
I doubt very
much that the answer is YES! Otherwise, it would have been
easy to produce the 3rd party SCSI host adapters and there would have
been a lot more competition - even with the $ US 100 license fee.
There is a design
out there, crude and PIO only. It would certainly work
as IDE can PIO pretty fast. the only thing that makes Q-bus the least bit
hard is that it has a read before write, that can mess up some register o
riented devices with an out of sequence read.
Jerome Fine replies:
Actually, since I am not a VAX/VMS person, I was thinking more along
the lines of a PDP-11 and RT-11. But since I know that a Qbus host
adapter such as a CMD 220/M (CMD) and a SQ706A (Dialog) both
function for either PDP-11 CPUs or uVAX II CPUs on any OS which
uses the MSCP interface, I guess that I am too out of touch with the
problems of what an IDE Qbus controller might have difficulty with.
And in particular, I was sort of referring to using an IDE Qbus controller
with John Wilson's adaptation of the Russian HD(X).SYS that he has
so conveniently made available in E11. There has been some discussion
about producing an IDE/SCSI version of a Qbus controller which would
be able to be a REAL Qbus PDP-11 controller with an RT-11 software
device driver identical in code to the HD(X).SYS used with the E11
emulator. At some point, I even wrote the trivial modifications needed
to allow a 256 MByte (8 * 32 MByte partitions) for a 256 MByte
container file on a hard disk drive. In order to keep everything simple
just for testing purposes, I limited the UNIT number of the container
file to ZERO (MOUNT HD0: BIGFILE.DSK). Within RT-11, I
was still able to use all 8 * 32 MByte partitions as HD0: => HD7:
and I could have easily added extended device support as well and
allowed a container file of 2 GBytes and 64 partitions. In point of
fact, I have volunteered to produce such a full device driver for
RT-11 should anyone ever produce such as IDE Qbus controller
for a PDP-11. And for TSX-PLUS as well. Eventually, I would
also attempt to add the ability to have a mapping table (similar to
what is present in an MSCP device driver) which for both RT-11
and especially TSX-PLUS would allow different jobs to have
different mapping tables for at least some - probably half - of
the "logical" devices.
If anyone who is still using TSX-PLUS (on either real or emulated
hardware) could also use that for the current MSCP device driver,
I would be interested in helping make DU.TSX capable of allowing
"SET DU4: PORT=0,UNIT=1,PART=64.,JOB=16."
along with
"SET DU SHOW=16."
as an example of what I suggest would be useful and needed.
The addition of JOB in either RT-11 or TSX-PLUS as a mapping
table parameter would allow a huge increase in the number of
physical partitions that could used at the same time. It would also
be possible to extend the maximum partition number from 255.
to 65535. even without adding the JOB parameter, not that I
am recommending that option since taking care of 64 partitions
is already difficult enough. Using all 256 partitions on an 8 GByte
drive seems far too difficult and managing to keep track of more
than 1024 partitions on a 32 GBytes drive seems almost impossible
unless there was some over-riding need for a particular application
that required that much hard disk storage. The key point is that
both MSCP and the HD(X).SYS device drivers in RT-11 and
TSX-PLUS seem to allow a 32 bit block number from the
software point of view. Thus I see no technical reason from a
software point of view why that 32 bit block number could not
be passed to the hardware. But, managing 65536 (decimal)
partitions in an RT-11 environment using 4 TeraBytes of on-line
hard disk drive storage is not a situation I would recommend.
On the other hand, it could be done - from a software technical
point of view - if the hardware can manage 32 bit block numbers
which I understand is possible.
Anyone out there who wants to try? I would be very pleased to
swap some of my time for a couple of SCSI 32 GByte hard drives
to test out the software. The only problem is that the only SCSI
host adapters I have are the 50 pin type (CQD 220/M), so there
might be a problem if there are no drives larger than 8 Gbytes which
have the old SCSI-2 50 pin interface. On the other hand, if
an 8 GByte drive (there are many ST410800N drives available
for under $ US 100 each) is sufficient, I would be just as happy
to swap my time for 4 of those drives and enhance either the
DUX.SYS or the DU.TSX device drivers to allow a JOB
parameter. I don't expect anyone to actually ask!!!!!!!!!!!
Sincerely yours,
Jerome Fine
