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