Any ideas as to where can I get more details on the various OSes boot sequence on the PDP11? Should have details like what disk block goes to which core address, how to find/load/jump to the kernel..etc. Paul Koning wrote: -- a8888b. d888888b. 8P"YP"Y88 Wai-Sun "Squidster" Chia 8|o||o|88 Technical Consultant (RHCE) 8' .88 Linux/Unix Development 8`._.' Y8. Consulting & Integration d/ `8b. HP Services Malaysia dP . Y8b. d8:' " `::88b d8" 'Y88b :8P ' :888 8a. : _a88P ._/"Yaa_: .| 88P| \ YP" `| 8P `. / \.___.d| .' `--..__)8888P`._.' "Phear the Penguins!" "I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." - Linus Torvalds -

Paul Koning wrote: 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.

Typically, for the -11's, the first block (block 0) of the device is loaded at address 0. The DEC bootblock standard calls for the first word to be a 5 (reset) and the second to be a branch to the rest of the code (so that locations 4/6 and 10/12 at a minimum are free for non-existent memory and illegal instruction traps). It is possible to write the primary boot block of a volume to contain the code to boot an entirely different device. For example, I have a machine which only knows how to boot from RX01/02, but I have an RL02 as well. I have one RX01 disk which has the RL01/02 primary boot code in block 0. So, when I boot dx0, the primary boot comes in off dx0, but the remainder of the boot process references dl0. Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL,ST| email: mbg at world.std.com | | Member of Technical Staff | megan at savaje.com | | SavaJe Technologies, Inc. | (s/ at /@/) | | 100 Apollo Drive | URL: http://world.std.com/~mbg/ | | Chelmsford, MA 01824 | "pdp-11 programmer - some assembler | | (978) 256 6521 (DEC '77-'98) | required." - mbg KB1FCA | +--------------------------------+-------------------------------------+

Jerome Fine replies: This is what I just found for RT-11: For V01-15 (1973), there is a "JMP addr" instruction at location zero. The VECTORs at 60, 60 and 100 are also used. I checked both the DecTape and RK05 device drivers. By V02.B (1975), there was a "NOP" at location zero followed by a "BR addr" instruction. The VECTORs at 60, 64 and 100 are NOT used. This usage is maintained for ALL subsequent versions of RT-11 running on a PDP-11 using RK05 or RL02 device drivers (when available). I assume that all other device drives would be the same. Starting with V05.03 of RT-11 from 1985 (a few earlier versions may also support the PRO hardware), I set up a BOOT image for a PRO device driver by: COPY/BOOT:DZ dev:RT11FB.SYS dev: I then checked the boot code in block zero of dev: and found NO differences at all (except for the code specific for "DZ"). There was a "NOP" in location zero followed by a "BR addr" instruction. VECTORs 60, 64 and 100 were all zeros. Somewhere (very buried, but might be found if it was essential), I have a bootable RX50 floppy that I tested on a PRO350 about 5 years (probably longer) ago. If there are any more questions, please ask. 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.

Hmmm. The PDP11/45 used bipolar PROMs for the CPU and floating point microcode. But the bootstrap board was a diode matrix. Now admittedly it could have been designed for the 11/20 (which was a couple of years earlier), and perhaps bipolar PROMs were not available then, but they were certainly around in 1972. The board I am thinking of has 32 locations of 16 bits, so 512 diodes. I have reprogrammed a couple... -tony