[simh] RSTS processor identification
Johnny Billquist
bqt at softjar.se
Fri Mar 5 18:22:08 CST 2021
On 2021-03-06 01:14, Chris Zach wrote:
> Ah ok. For some reason I always thought the 23 could only run M, which
> is still a fine platform. I'd be amazed if they got all the extra cool
> features like disk caching working without I/D.
Officially, you need the 11/23+. The original 11/23 is not supported,
since that only had 18-bit addressing.
Disk caching and so on is not a problem. It takes some memory, but if
you have 22-bit addressing, then it's just a question of grabbing some
more of all that free memory you have. ;-)
However, on machines without split I/D space, what you normally have
problems with in M+ is that system pool is very small. You have to be
rather careful what you do with the system.
But that's the way it is. Both on the 11/23+ and the 11/24.
> But when I think about it, it makes sense: P/OS is basically M+ all the
> way and runs on the Pro/350. But P/OS 2.0 will not allow you to run
> split I/D applications on a 380 although you can compile them.
Right.
> Maybe this weekend I'll hack that SSD floppy thingie and load up the
> P/OS 3.2 disks to see how that works.
Can't run split I/D space on any version of P/OS. Neither does it
support supervisor mode. Also, the J11 on the Pro-380 is running a bit
on the slow side. Rather sad, but I guess they didn't want to improve
the support chips on the Pro, which limited speed, and they didn't want
to start having Pro software that didn't run on all models, which
prevented the I/D space and supervisor mode.
In the end I would probably just put it down to additional ways DEC
themselves crippled the Pro, which otherwise could have been a much
better machine.
Johnny
>
> C
>
> On 3/5/2021 6:55 PM, Johnny Billquist wrote:
>> The 11/23 is officially supported, and does indeed lack I/D space
>> (also true of the 11/24). Which implies that split I/D space is not
>> actually a requirement for RSX-11M-PLUS. That would also be clear by
>> reading the SPD.
>>
>> However, officially, there is a requirement for 22-bit addressing.
>> Which means that both 11/40 and 11/60 is not supported. However, it is
>> possible to run RSX-11M-PLUS on those machines. But you need to enable
>> unsupported builds in order to do a SYSGEN for those machines.
>>
>> Also, this means that actually the 11/45 is not officially supported,
>> as opposed to the 11/24 which is...
>>
>> Johnny
>>
>> On 2021-03-06 00:11, Chris Zach wrote:
>>> 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
>>> <https://groups.io/g/simh/message/551>
>>> Mute This Topic: https://groups.io/mt/81110197/4814011
>>> <https://groups.io/mt/81110197/4814011>
>>> Group Owner: simh+owner at groups.io
>>> Unsubscribe:
>>> https://groups.io/g/simh/leave/8625569/4814011/104597204/xyzzy
>>> <https://groups.io/g/simh/leave/8625569/4814011/104597204/xyzzy>
>>> [bqt at softjar.se]
>>> ------------------------------------------------------------------------
>>>
>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
--
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
More information about the cctech
mailing list