[simh] RSTS processor identification

Fri Mar 5 17:11:08 CST 2021

How can you run m+ on an 11/23 or a 40? I thought it needed I/d space to run thus I can see it on a 45.

On March 5, 2021 6:02:45 PM EST, Johnny Billquist via cctalk <cctalk at classiccmp.org> wrote:
>Nice writeup, Paul. And very interesting.
>
>Just in case anyone wonder about RSX, here is how it's done in M+:
>
>1. Test if SYSID register exists
>    If SYSID register exists:
>    2. Test if high bit of KISDR0 can be set and read back
>       If high bit can be set and read back => 11/74 CPU
>       If high bit cannot be set and read back => 11/70 CPU
>3. Try MFPT instruction
>    If that succeeds:
>      If R0 == 1 => 11/44 CPU
>      If R0 == 3:
>        4. Try to read maintenance register
>           If register exists => XT CPU (Pro)
>           5. If register does not exist, try writing to SWR
>              If fail to write => 11/23 CPU
>              If succeed to write => 11/24 CPU
>      If R0 is something else, it is a J11 CPU, see more below.
>6. Execute OP-codes 076600,000400
>    If that succeeds => 11/60 CPU
>    If that fails:
>    7. Execute OP-code 106700
>       If that succeeds => 11/34 CPU
>       If that fails:
>       8. Try to read PIRQ register
>          If that succeeds => 11/45 CPU
>          If that fails:
>            CPU is one of: 11-/04/05/10/15/20/40
>            M+ will just assume 11/40, since that is the only possible
>           model that could possibly be running this code. => 11/40 CPU
>
>
>For J11 processors, after point 3, we get into a J11 probing.
>9. If R0 <> 5, it is not a J11 processor after all. => Unknown CPU
>10. Read maintenance register
>     If fail => Unknown CPU
>11. Check bits 4-7 of maintenance register:
>     == 4: => 11/53 CPU
>     == 3: => 11/73 CPU (not KDJ11)
>     == 1: Write KISDR7+1 to KISDR7+1
>             Check if W bit in KISDR7 was set.
>               If set => M11 CPU
>             Try opcodes 076660,156227
>               If succeed => N11 CPU
>     == 2: => 11/83 or 11/84 CPU (see step 12)
>     == 5: => 11/93 or 11/94 CPU (see step 12)
>12. Check if Unibus system based on maintenance register
>     If Unibus system indicated, try read Unibus map register
>     If Unibus map exist: => Unibus system. CPU 11/84 or 11/94 (see 11)
>13. Qbus system. CPU 11/83 or 11/93 (see 11)
>
>
>Note: M11 processor is called 11/95
>Note: N11 processor is called 11/97
>
>That concludes how RSX-11M-PLUS decides what CPU you have at boot.
>
>There are then probes for TOY, clock and memory, but that's a different
>
>story.
>
>If anyone wants more information, the code is in LB:[12,10]SAVSIZ.MAC, 
>routine $STCPU. But I'm happy to also answer any questions.
>
>Also note that while doing these tests/probes, RSX is catching the 
>illegal instruction trap, and just resumes execution but sets carry. So
>
>for some of these tests, the carry is cleared, and the instruction is 
>attempted, and then there is a check if carry got set, as a way of 
>seeing if it worked or not. The specific opcodes are for maintenance 
>instructions that either are harmless on other models, or trap. And 
>which do not affect the carry if executed on the assumed processor 
>tested for.
>
>Non-existant memory is also trapped, and execution resumed with carry 
>set. Same kind of idea...
>
>   Johnny
>
>On 2021-03-05 19:38, Paul Koning 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
>> 
>> 
>> 
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Groups.io Links: You receive all messages sent to this group.
>> View/Reply Online (#551): https://groups.io/g/simh/message/551
>> Mute This Topic: https://groups.io/mt/81110197/4814011
>> Group Owner: simh+owner at groups.io
>> Unsubscribe:
>https://groups.io/g/simh/leave/8625569/4814011/104597204/xyzzy
>[bqt at softjar.se]
>> -=-=-=-=-=-=-=-=-=-=-=-
>> 
>> 
>
>-- 
>Johnny Billquist                  || "I'm on a bus
>                                   ||  on a psychedelic trip
>email: bqt at softjar.se             ||  Reading murder books
>pdp is alive!                     ||  tryin' to stay hip" - B. Idol

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.