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@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 > >
