Zane H. Healy wrote:
days. However, I won't be using the nice WQESD
ESDI controller that I've
got that makes partitioning disks easy. So I want to make sure I
understand how partitioning works under RT-11.
Doesn't it do the partitioning in
hardware anyway? Of course that is
easy... they become separate units...
Yes, the WQESD does the partitioning in the
Hardware. Kinda handy as it
allows multiple bootable RT-11 partitions, OR multiple bootable OS's.
Jerome Fine replies:
You forgot to say how big your ESDI drive is and which version of RT-11
you are using. If your ESDI drive is 256 MBytes or less (even up to
300 MBytes is not unreasonable) and you are using either the WQESD
or at least V5.3 of RT-11, then as you note, sufficient partitions are available
(maximum of 8 partitions up to V5.4G or RT-11). Note that with the standard
RT-11 distribution up to V5.4G, ONLY partition ZERO is bootable since
the boot code in the device driver of an RT-11 MSCP device is missing one
instruction (naturally the one which takes care of the partition number - this
can easily be modified in V5.4G - I have seen it in actual operation). And
in general (you would need 2 active devices otherwise) the hardware boot
code can do a HARDWARE BOOT of an RT-11 partition (ALWAYS
partition ZERO) ONLY (there was a discussion a while back in which it was
shown that with 2 active devices this can be somewhat modified) if the logical
and physical UNIT numbers match.
If you are using V5.5 or later, then extended device driver support is available
and 64 partitions are available. In addition, starting at least with V5.6 of RT-11,
NON-ZERO partitions are software bootable. Which means that you can
support an 8 GBytes disk drive and simultaneously use up to 64 partitions
(out of 256 on that 8 GByte drive) at one time using the partitions D00: to
D77: (64 total since numbers are actually - sort of - in octal). NOTE that
the standard DEC distribution allows only the first 8 partitions in the table
to be bootable although it is quite possible (I have seen one version that
allows ALL 64 partitions to be software bootable - actually watched D64:
being booted) to re-write the boot code and have all 64 partitions bootable.
Since I have probably given you too much to chew on, please respond with
any questions.
That should be
.SQUEEZE/OUTPUT:DU0: DL1:
.COPY/BOOT DU0:RT11FB.SYS DU0:
Whoops, manual even says that on the copy I
see. I guess I literally need
my eyes checked as I read the COPY/BOOT wrong.
We all do that on occasion - in my case, more often than not.
Squeeze is a
faster way of doing the copy when the output volume is
a freshly initialized volume. You could do it with a COPY/SYS...
Ah, OK I
understand, the COPY/SYS is how I've done it previously.
The only real difference is that with COPY/SYS you don't get a
"SQUEEZEd" directory the first time through. If you have more than
about 1500 files, that could be a problem. You would have to do
a multiple pass since the directory would become "full". Otherwise,
you can do the SQUEEZE afterwards and only the directory would
be modified if there were no empty spaces.
There are a
number of factors involved... you need to ensure that the
partitioning in the DU driver you are using to write to the DU device
is the same as the DU driver which gets written *to* that device. If
not, you could write the data just fine, but not be able to find it
easily.
Now is this the same specific copy of DU.SYS? In other words should I be
booting off RL, setting the partitions, then init'ing the drives, then
copying? Or is this simply saying that DU.SYS vs. DUX.SYS will have
problems?
Just to be sure, I always recommend that the DU(X).SYS file being
written to the device which will be booted is the device driver which is being
used to perform the COPY operation. Sometimes that is not possible,
but try to do so whenever you can. However, if you are using a version
of RT-11 on the target bootable partition which is not compatible with the
version of RT-11 that is doing the copy, that will not be possible.
