9 Nov
1999
9 Nov
'99
11:01 a.m.
In regard the the maximum size of the drive, the DEC
implementation
allowed a partition number of 377 Octal (255 decimal) as the maximum
since the two word table uses the UNIT for the first word and the
second word split (one byte each) between the partition and the port
(controller) which is almost a complete waste since the DEC
implementation allows only a maximum of four ports in any case
(only 2 bits required). Since all 16 high order bits of the 32 bit block
number are available, it would be possible (but not trivial) to allow
a much larger partition number and make better use of the map table.
Since I don't have a 9.1 GByte Micropolis (slurp slurp slurp) for a
system with RT-11, I have not bothered to determine how much
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.)
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.)
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/hardwar…
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.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
9 Nov
9 Nov
2:56 p.m.
CLASSICCMP(a)trailing-edge.com wrote:
[Snip]
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.
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.) 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/hardwar…
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.
9127
days inactive
9127
days old
1 comments
2 participants
participants (2)
-
CLASSICCMP＠trailing-edge.com -
jhfine＠idirect.com