Paul Koning wrote:
> >>>>> "wai-sun" == wai-sun chia <squidster_at_techie.com> writes:
> wai-sun> Hello list, I'm trying to figure out the boot sequence on
> wai-sun> both the RK05 and RL02 drive from a PDP. Here's how I
> wai-sun> understand it so far:
> wai-sun> 1. Get the bootstrap in core either via the FP or PTR.
> wai-sun> 2. Execute bootstrap and pull in the absolute loader from
> wai-sun> 1st. sector of 512 bytes or 256 words; i.e. copy 1st. sector
> wai-sun> of drive to core starting from 0 3. Execute absolute loader
> wai-sun> by a JMP 0. 4. ??? What happens next ???
> Typically, what happens next is that more initialization code is read
> in from the disk. How much and where it comes from depends on the OS.
> For example, in RT11 the bootstrap is 2 blocks long (block 2 is the
> rest). It reads the directory to find the kernel and loads that, then
> jumps to it. (Give or take some handwaving; Megan can improve on this
> in her sleep...)
Jerome Fine replies:
A bit of a correction for RT-11 might help.
As stated above, the primary hardware bootstrap program
is loaded in some manner (the same for ALL operating
systems) and reads block zero (of 512 bytes or 256 words
of the disk drive) into memory at location zero.
This secondary bootstrap program is then executed starting
at location zero.
A word of caution - For reasons on a PDP-11 which I don't
understand, the secondary bootstrap program avoids the
VECTORS for the console device at 60,64 and for the
LTC (line time clock) at 100. For all but the MSCP
device driver, the 512 bytes is more than adequate.
Blocks 2,3,4,5 were reserved for the tertiary bootstrap
program. For early versions of RT-11, only blocks 2 and
3 seem to have been needed. By V04.00, I think that
blocks 2,3,4 were required. By V05.00, blocks 2,3,4,5
were used. The secondary bootstrap program read the
tertiary bootstrap program blocks into memory starting at
location 1000 and then started execution at location 1000.
The secondary bootstrap program between 0 and 1000
was retained and that READ subroutine was usually used
by the tertiary bootstrap program.
In RT-11, DUP.SAV was used to write the secondary
and tertiary bootstrap programs onto the disk drive.
Starting with V05.03 of RT-11, MSCP devices were
supported under the DU(X).SYS device driver which
were larger than 65536 blocks or 32 MBytes. Each
group of 65536 blocks is called an RT-11 partition.
Starting with the first RT-11 partition which is numbered
PART=0, the SET command is used to:
SET DUn PORT=c, UNIT=u, PART=p
where n = logical unit number (0 <= n <=7) up to V05.04G
and (0 <= nn <= 77) but use Dnn starting with V05.05
where c = physical controller number (0 <= c <= 3)
u = physical unit number (usually the SCSI ID for SCSI drives)
p = physical RT-11 partition number (0<= p <=255)
For a hardware boot starting with the primary bootstrap
program which does NOT know anything about RT-11
partitions, c=p=0 and n=u. This requires:
SET DUn: PORT=0, UNIT=n, PART=0
to allow a hardware boot to be successful - in almost all cases
that are reasonable, although I have, just for fun, done it differently
just to prove it was possible.
With V05.06 of RT-11, DEC finally added the one extra
instruction to the secondary bootstrap program which allows
the DUP.SAV program to do a SOFTWARE boot from
RT-11 to a NON-ZERO partition. It is possible to force
DUP.SAV to follow exactly the same sequence by:
BOOT DUn:/FOREIGN
using the "/FOREIGN" switch so that the secondary bootstrap
program is read from block zero of the specified RT-11
partition. A NON-ZERO partition is still allowed and the
MSCP device driver allows the user to specify a map
relationship between DUn: and the RT-11 partition which
can be any combination of n, c, u and p - although if the
combination is not valid, it can't be booted.
There is one major restriction with the DEC version even
with an extended DU(X).SYS device driver operating
system. DEC limits the user to use a DUn: where 0 <= n <=7
This restriction is a software limitation and I have an enhanced
version of DU(X).SYS for boot values of Dnn: where
0 <= nn <= 77 (nn is regarded as octal, but "Dnn" is really a
RAD50 quantity with 64 possible "text" values where "8" and
"9" are permitted but not used in practice) and I have frequently
found it very useful to boot D62:, although finding space for all
the 64 map entries in the boot block of 512 bytes left ZERO
extra bytes remaining even when only one controller was used.
The reason that only 64 active partitions are allowed is that DEC
uses only 6 bits in each queue entry to specify the device number.
It should be possible to use at least 7 bits and maybe even 8 bits
in each queue entry for a total of 256 active partitions, although
I suspect that there is absolutely NO commercial interest in such an
enhancement at the present time, and certainly NO hobby interest
to justify the size of the effort.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
Received on Thu Jul 01 2004 - 22:01:27 BST