I was just asked some questions about how RSTS identifies your processor type.
Since that topic might be of broader interest I figured I'd do some code
reading and summarize the logic.
In the RSTS initialization code (INIT.SYS), the first step is to identify what
your hardware looks like. That is a combination of CPU type, bus type, memory
layout, and peripheral configuration lookup. They aren't strictly separated
into sequential blocks for those four activities, though naturally you'd want
to know the bus type before you start looking for I/O devices on that bus.
What I describe here is in RSTS/E V10.1. The general idea of scanning the
hardware was introduced in V6B, and I believe is basically the same from that
time onward apart from the addition of support for more hardware types. Prior
to V6B, the assumption was that you had the hardware you specified during
SYSGEN, neither more nor less.
Here is an outline (not all the details) of the hardware scan flow:
1. If word 0 of the boot block contains a zero, this is a Pro (CT bus);
otherwise it isn't.
2. Make sure the MMU exist; if not, halt.
3. Check the CPU type (MFPT instruction). If it's an F-11, see if 177570
exist. If yes, 11/24 (Unibus); if no, 11/23 (Qbus). If it's a J-11, read the
board type register at 177750 and use the bus type bit to distinguish Qbus from
Unibus.
4. Check that there is a clock, and if possible determine the power line
frequency.
5. Check if there is a CPU cache, and whether there is a cache error address
register.
6. If Qbus, check whether there is memory above the 18 bit range.
7. Check that there is at least 96kW of memory (but the message says that 124kW
is required -- the actual check value was apparently overlooked and not
updated).
8. Check CPU features: EIS (required), FPP, FIS, switch register, display
register, MED, two register sets, system ID register, CIS, Data space.
9. If Unibus, check for UMR.
10. Find where memory is. This is done by looking at every 1kW address to see
if it answers. So unlike some other operating systems, RSTS will keep looking
if it finds a hole in memory. The kernel needs to be at 0 and contiguous, but
holes above that are not a problem.
11. Scan the I/O bus for peripherals. This uses the fixed addresses and float
rules for Unibus/Qbus (either, the code doesn't care) or the slot use bits and
device type register codes for the Pro.
12. Find the vectors, which for almost every device is done by making it
interrupt.
13. Identify specific device models if we care, like RL01 vs. RL02, Massbus
disk type, DMC/DMR/DMP, etc.
14. Find which of these devices we were booted from.
That's about it. Once you get past that point the INIT prompt appears and you
can ask what INIT found with "HARDWARE LIST".
Incidentally, RSTS doesn't try to identify the exact CPU type you have.
Instead, it cares about features or distinctions that affect the code. In a
number of cases it does report the type -- if MFPT works then "hardware list"
will report that information. But for older CPUs, it doesn't say explicitly,
though you can deduce it to some extent. If no type is given but there is
cache and more than 128 kW of memory, it's an 11/70. If MED is available, it's
an 11/60. If it has FIS, it can only be an 11/40. Etc...
paul
