>CLASSICCMP_at_trailing-edge.com wrote:
> [Snip]
> >effort it would be. Tim, maybe you could figure out what code
> >references the PART and PORT values and see if the 2 bits in
> >use for the PORT could be placed at the top of the word and
> >6 extra bits made available to the PART for a maximum number
> >of 16384 partitions and a 512 GByte drive.
> Sure, this is done fairly easily. You have to modify not only the
> SET overlay usage inside the DU handler, but also the parts of RESORC.SAV
> responsible for SHOW DEV:DU. (Working from memory, the relevant parts
> are in RESDEV.MAC on the source kit - I was fooling around with this
> earlier this year to add multi-CSR display capability.)
Jerome Fine replies:
OOOOOOOOOOOOPPPPPPPPPPPPPPPPSSSSSSSSS!!!!!
I forgot that "SHOW DEV:DU" in not in the device handler.
I guess I could add a bit in the device handler that is not used
at present (somewhere there must be a bit left over) that could
allow a different layout for the map table.
I have dabbled with a PATH Handler in RT-11 which allows
the same kind of search list as the logical name list in VMS
or DOS does for executables via the PATH. The only restriction
is that the PHn: allows only a maximum of 16 device names in the
list. Eventually, I will post the code to be used in the Freeware.
The reason I mention this is because I needed a method for the
user to "SHOW" the various device names associated with each
PATH device "PHn:", so I placed some code in the device handler
which allowed: "SET PH SHOW[=job number]". Since it is
possible to use overlays within SET commands, I just brought in
the code as required to analyse the table set up for each job.
After I finally had done this, I wondered why this procedure
was not used for the MSCP "SHOW DEV:DU" command
since it would have allowed the necessary code to remain
with the device driver rather than having RESORC always
have to co-ordinate all the time with any changes which occurred
in the device driver.
> The real question is, will I ever have so much RT-11 software/data that
> I need access to more than 8 Gbytes? I've got a wall of 8" floppies here,
> over 7000 floppies in total, but all 7000 floppies together (even assuming
> double density) are only 3.5 Gbytes! (And less than half of those 8" floppies
> are RT-11 stuff in the first place - the rest being WPS/8 and CP/M stuff.)
I suggest that an even better reason is that keeping track of 256 partitions
will be difficult enough. Keeping track of 16384 partitions would become
almost impossible. NO! Leave the code the way it is and allow ONLY
256 possible partitions.
One enhancement that I have added to DIR is a switch to:
"/VOLUME:starting-block-number[:nested-starting-block-number[...]]"
which allows DIR to produce the DIRECTORY of a DSK without
needing to MOUNT the DSK or the sub DSK files - up to any level
of nesting. I realize that very strange things can happen if the data
being read is not a DIRECTORY, but that can happen if the DSK
has just been CREATEd and MOUNTed without doing the "INIT LDn:"
command. So I don't feel that there is any inherent problem with
allowing DIR to do this, except that if DIR does not sufficiently
check the data in the first place (which it may not sufficiently
do in some cases), it could cause a problem even if the DSK had
first been MOUNTed but not INITIALIZEd. If there is any interest
in this feature, it will also be eventually put into Freeware.
> >Tim, do you have the search algorithm for alternate CSR addresses
> >when the standard CSR DU MSCP address of 172150 is either
> >not available at all or is a removable floppy with no media present?
> The "DEC standard" way of determining alternate CSR's is to follow
> the autoconfigure rules (see
>
> http://metalab.unc.edu/pub/academic/computer-science/history/pdp-11/hardware/alans.csr.paper
>
> for a nice writeup of how the rules work). Unfortunately the RT-11
> developers chose to ignore these rules in picking their "default" second
> CSR for RT-11, but of course you could choose to follow these rules
> by ignoring the SYSGEN-suggested secondary (and tertiary and whatever
> comes after) DU CSR's.
I probably already have. One of the systems which I have available has
about 6 MSCP device drivers. Naturally DU is present at 172150, but
I also have an VR (quad RQDX2,1), QR (dual RQDX3), HI (for Hitachi
ESDI drives), SE (for Seagate ESDI drives), CM (for a CQD host adapter)
which I intend to use with that 9.1 GByte Micropolis SCSI? drive and a
CD-ROM and a Zip drive. Since I already have a SE12400N of 2 GBytes,
I doubt that I will ever bother with the 9.1 GByte drive. But who can tell?
Sincerely yours,
Jerome Fine
Received on Tue Nov 09 1999 - 22:56:29 GMT