RSTS processor identification

[Bob Smith]

very nice! thans!! better than reading all the manuals and trying to
figure out the code!!
Stay well Paul!!
bob smith

On Fri, Mar 5, 2021 at 1:38 PM Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
>
> 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
>
>