5 Mar
2021
5 Mar
'21
10:38 a.m.
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
5 Mar
5 Mar
11:43 a.m.
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
3:02 p.m.
New subject: [simh] RSTS processor identification
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
3:11 p.m.
New subject: [simh] RSTS processor identification
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:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
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
3:55 p.m.
New subject: [simh] RSTS processor identification
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
4:14 p.m.
New subject: [simh] RSTS processor identification
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.
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.
Maybe this weekend I'll hack that SSD floppy thingie and load up the
P/OS 3.2 disks to see how that works.
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.
4:22 p.m.
New subject: [simh] RSTS processor identification
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
5:33 p.m.
New subject: [simh] RSTS processor identification
On Mar 5, 2021, at 7:22 PM, Johnny Billquist via
cctalk <cctalk at classiccmp.org> wrote:
...
The most embarassing blunder with the Pro is that the bus supports DMA, but no I/O cards
use it. Even though a bunch of them should have -- hard disk controller obviously,
network adapter possibly as well.
I/D and supervisor mode work fine on RSTS. :-)
The explanation I heard for the slow J-11 clock is that the original J-11 spec called for
it to operate at 20 MHz. When Harris failed to deliver and the max useable clock speed
ended up to be 18 MHz, most designs had no trouble. But the Pro support chips were
designed to run synchronous with the CPU clock and for various other reasons needed a
clock frequency that's a multiple of 10 MHz, so when 20 MHz was ruled out that left 10
MHz as the only alternative.
I would have liked better comms. The USART has such a tiny FIFO that you can't run it
at higher than 9600 bps even with the J-11 CPU. At least not with RSTS; perhaps a lighter
weight OS can do better. The printer port is worse, that one can't run DDCMP reliably
at more than 4800 bps. I normally run DDCMP on the PC3XC, which is a 4-line serial card
that uses two dual UART chips (2681?) with reasonable FIFO.
paul
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.
6:02 p.m.
New subject: [simh] RSTS processor identification
On 2021-03-06 02:33, Paul Koning wrote:
That's another good point about weird things about the Pro.
On Mar 5, 2021, at 7:22 PM, Johnny Billquist via
cctalk <cctalk at classiccmp.org> wrote:
...
The most embarassing blunder with the Pro is that the bus supports DMA, but no I/O cards
use it. Even though a bunch of them should have -- hard disk controller obviously,
network adapter possibly as well. 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. I/D and supervisor mode work fine on RSTS. :-)
Really? That's nice. I would have loved to try and build a version of
the latest RSX for the Pro, but unfortunately the code for the disk
controllers are missing for me.
The handling of the screen and keyboard are still in the RSX sources.
The explanation I heard for the slow J-11 clock is
that the original J-11 spec called for it to operate at 20 MHz. When Harris failed to
deliver and the max useable clock speed ended up to be 18 MHz, most designs had no
trouble. But the Pro support chips were designed to run synchronous with the CPU clock
and for various other reasons needed a clock frequency that's a multiple of 10 MHz, so
when 20 MHz was ruled out that left 10 MHz as the only alternative.
I do think it sounds weird that the support chips would require a clock
that is a multiple of 10 MHz. But I wouldn't know for sure.
Somewhere else I read/heard that they didn't work reliable above 10 MHz,
but for the F11 that was ok. When the -380 came, they just reused those
support chips.
Also, no caches. The -380 could have been so much better...
I would have liked better comms. The USART has such a
tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU. At
least not with RSTS; perhaps a lighter weight OS can do better. The printer port is
worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP
on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with
reasonable FIFO.
Hmm. I'm pretty sure I was running my -380 with the printer port for
DDCMP on HECnet for a while, and at 9600 bps.
But with P/OS, you are not using the console port as such. That's all on
the graphics side.
But unless I'm confused, that's the same port. The printer port just can
also be the console port, if you short pins 8-9, right? Except it won't
fully work the same as the DL11, since interrupts work differently. But
polled I/O will work the same.
But I would expect the speed characteristics to be the same for the
console as for the printer port.
Johnny
--
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
6 Mar
6 Mar
6:56 a.m.
New subject: [simh] RSTS processor identification
Johnny Billquist wrote:
On 2021-03-06 02:33, Paul Koning wrote:
The 6502 CPU in the BBC Micro operates at 2 MHz but periperals such as the
6522 Versatile Interface Adapters contain timers which only run at their
expected speed when used with a 1 MHz clock. I wonder could it be that the
Pro support chips would run ok at 18 MHz but there would have been
difficulties with programming timers etc which are clocked at an odd speed?
(The BBC Micro got around this problem by running the CPU at 2 MHz and
stretching the clock cycle to 1 MHz when accessing the VIAs. The clock
circuit is a real birds nest...)
Regards,
Peter Coghlan.
The explanation I heard for the slow J-11 clock is that the original J-11
spec called for it to operate at 20 MHz. When Harris failed to deliver
and the max useable clock speed ended up to be 18 MHz, most designs had
no trouble. But the Pro support chips were designed to run synchronous
with the CPU clock and for various other reasons needed a clock frequency
that's a multiple of 10 MHz, so when 20 MHz was ruled out that left 10 MHz
as the only alternative.
I do think it sounds weird that the support chips would require a clock
that is a multiple of 10 MHz. But I wouldn't know for sure.
Somewhere else I read/heard that they didn't work reliable above 10 MHz,
but for the F11 that was ok. When the -380 came, they just reused those
support chips.
7 Mar
7 Mar
2 p.m.
New subject: [simh] RSTS processor identification
On Mar 5, 2021, at 9:02 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-03-06 02:33, Paul Koning wrote:
DDCMP runs fairly well on RSTS with the printer port at 9600, but I get some overruns. My
guess is that the terminal driver (which is front ending the DDCMP machinery) isn't as
lightweight as the equivalent on RSX. Or do you bypass the terminal driver and get a
separate comms-specific driver for this case?
> ...
I would have liked better comms. The USART has
such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU.
At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is
worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP
on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with
reasonable FIFO.
Hmm. I'm pretty sure I was running my -380 with the printer port for DDCMP on HECnet
for a while, and at 9600 bps. But with P/OS, you are not using the console port as
such. That's all on the graphics side.
But unless I'm confused, that's the same port. The printer port just can also be
the console port, if you short pins 8-9, right? Except it won't fully work the same as
the DL11, since interrupts work differently. But polled I/O will work the same.
But I would expect the speed characteristics to be the same for the console as for the
printer port.
Correct, printer and console are actually the same thing. If you use the console cable
(pin 8 connected to 9) then that materializes a DL11-like CSR set at 177560. Yes, with
polled I/O such as the ODT microcode uses that works just like a real DL11, but for
interrupts it's different. In RSTS, either way that port becomes a terminal port.
RSTS does have support for the graphics module, in "glass TTY" mode within the
initialization code and full VT220 emulation in RSTS proper. Well, except for blink mode,
and no bold in 132 column mode.
paul
3:42 p.m.
New subject: [simh] RSTS processor identification
On 2021-03-07 23:00, Paul Koning wrote:
I realized I might have spoken too soon. There is also a comm port, and
now I'm unsure if DECnet isn't running over that one actually.
Anyway, in RSX, when running DDCMP on the serial port, DECnet has its
own device driver. So not talking through any terminal device driver,
which have all kind of features and capabilities expected for a terminal
line.
Same with normal RSX, which is why you have to dedicate the whole
controller to either DECnet or TT. You can't mix.
Well, in P/OS you do have the option of also play graphics, and do
different resolutions. But the "terminal" handling for it have similar
limitations. I think blink isn't working the same as in a VT100, nor is
reverse (if I remember correctly). And of course, smooth scrolling do
not work you you don't scroll the whole screen, since the hardware isn't
capable, and doing it in software would be way too slow.
There was even a window system available, which sortof reminds of
Windows before 3.1. Played a little with it. It works, but it's a bit
limited. But from the pure graphics point of view, it's nice.
Johnny
--
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
On Mar 5, 2021, at 9:02 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2021-03-06 02:33, Paul Koning wrote:
DDCMP runs fairly well on RSTS with the printer port at 9600, but I get some overruns.
My guess is that the terminal driver (which is front ending the DDCMP machinery) isn't
as lightweight as the equivalent on RSX. Or do you bypass the terminal driver and get a
separate comms-specific driver for this case? > ...
I would have liked better comms. The USART has
such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU.
At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is
worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP
on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with
reasonable FIFO.
Hmm. I'm pretty sure I was running my -380 with the printer port for DDCMP on HECnet
for a while, and at 9600 bps. But with P/OS,
you are not using the console port as such. That's all on the graphics side.
But unless I'm confused, that's the same port. The printer port just can also be
the console port, if you short pins 8-9, right? Except it won't fully work the same as
the DL11, since interrupts work differently. But polled I/O will work the same.
But I would expect the speed characteristics to be the same for the console as for the
printer port.
Correct, printer and console are actually the same thing. If you use the console cable
(pin 8 connected to 9) then that materializes a DL11-like CSR set at 177560. Yes, with
polled I/O such as the ODT microcode uses that works just like a real DL11, but for
interrupts it's different. In RSTS, either way that port becomes a terminal port.
RSTS does have support for the graphics module, in "glass TTY" mode within the
initialization code and full VT220 emulation in RSTS proper. Well, except for blink mode,
and no bold in 132 column mode.
8 Mar
8 Mar
6:40 a.m.
New subject: [simh] RSTS processor identification
On Mar 7, 2021, at 6:42 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-03-07 23:00, Paul Koning wrote:
I realized I might have spoken too soon. There is also a comm port, and now I'm
unsure if DECnet isn't running over that one actually.
That would make a difference. The printer port is a 2661 on the Pro 350, or the gate
array equivalent on the Pro 380. Either way, it's a UART without a FIFO. The comm
port is an 8274, which has a 3 byte FIFO. So does the 2681 dual UART, which is what the 4
port comm card uses. In my tests, that FIFO makes the difference between running reliably
at 9600 baud, and getting frequent overrun errors.
On Mar 5,
2021, at 9:02 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2021-03-06 02:33, Paul Koning wrote:
DDCMP runs fairly well on RSTS with the printer port
at 9600, but I get some overruns. My guess is that the terminal driver (which is front
ending the DDCMP machinery) isn't as lightweight as the equivalent on RSX. Or do you
bypass the terminal driver and get a separate comms-specific driver for this case? > ...
I would have liked better comms. The USART has
such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU.
At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is
worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP
on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with
reasonable FIFO.
Hmm. I'm pretty sure I was running my -380 with the printer port for DDCMP on HECnet
for a while, and at 9600 bps. Anyway, in RSX, when running DDCMP on the serial port,
DECnet has its own device driver. So not talking through any terminal device driver, which
have all kind of features and capabilities expected for a terminal line.
Same with normal RSX, which is why you have to dedicate the whole controller to either
DECnet or TT. You can't mix.
That's probably more efficient. In RSTS I added the DDCMP support as an
"auxiliary" function attached to the terminal driver, so the regular terminal
driver does the device control and then diverts the data stream to/from the DDCMP driver.
It's a bit like how Linux does these things, I forgot what term they use. In fact, it
would be possible to add DDCMP support to Linux in the same way if someone wants to try
that... :-)
But with P/OS, you are not using the console port as
such. That's all on the graphics side.
But unless I'm confused, that's the same port. The printer port just can also be
the console port, if you short pins 8-9, right? Except it won't fully work the same as
the DL11, since interrupts work differently. But polled I/O will work the same.
But I would expect the speed characteristics to be the same for the console as for the
printer port.
Correct, printer and console are actually the same thing. If you use
the console cable (pin 8 connected to 9) then that materializes a DL11-like CSR set at
177560. Yes, with polled I/O such as the ODT microcode uses that works just like a real
DL11, but for interrupts it's different. In RSTS, either way that port becomes a
terminal port.
RSTS does have support for the graphics module, in "glass TTY" mode within the
initialization code and full VT220 emulation in RSTS proper. Well, except for blink mode,
and no bold in 132 column mode.
9:06 a.m.
New subject: [simh] RSTS processor identification
On 2021-03-08 15:40, Paul Koning wrote:
Definitely more efficient from a software point of view.
Having two DHV11 in the machine, while only using 1 port on one of them,
and couple on the other, might be considered less efficient from another
point of view. ;-)
You could, of course, have done it through the terminal driver in RSX,
if you really wanted to. But I suspect they just felt the overhead
wasn't attractive.
I did SLIP in my TCP/IP going through the normal terminal driver.
Well, in P/OS you do have the option of also play graphics, and do different resolutions.
But the "terminal" handling for it have similar limitations. I think blink
isn't working the same as in a VT100, nor is reverse (if I remember correctly). And of
course, smooth scrolling do not work you you don't scroll the whole screen, since the
hardware isn't capable, and doing it in software would be way too slow.
Right, I forgot about partial smooth scroll. Blink could be done fairly easily with EBO
through the color lookup table; I haven't bothered doing that. Same for bold.
Reverse wasn't a problem in my experience.
That jogged my brain. It wasn't reverse that was a problem. Bold was
where it could be a bit funny. Or possibly bold in combination with
something (reverse?).
The Pro would really have benefited from some hardware acceleration of
the graphics. The PDP-11 wasn't exactly a speed daemon when it came to
moving those pixels around...
Johnny
--
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
On Mar 7, 2021, at 6:42 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2021-03-07 23:00, Paul Koning wrote:
That's probably more efficient. In RSTS I added the DDCMP support as an
"auxiliary" function attached to the terminal driver, so the regular terminal
driver does the device control and then diverts the data stream to/from the DDCMP driver.
It's a bit like how Linux does these things, I forgot what term they use. In fact, it
would be possible to add DDCMP support to Linux in the same way if someone wants to try
that... :-) > On Mar 5, 2021, at 9:02 PM, Johnny Billquist
<bqt at softjar.se> wrote:
>
> On 2021-03-06 02:33, Paul Koning wrote:
>>> ...
>
Anyway, in RSX, when running DDCMP on the serial port, DECnet has its own
device driver. So not talking through any terminal device driver, which have all kind of
features and capabilities expected for a terminal line.
Same with normal RSX, which is why you have to dedicate the whole controller to either
DECnet or TT. You can't mix. But with P/OS,
you are not using the console port as such. That's all on the graphics side.
But unless I'm confused, that's the same port. The printer port just can also be
the console port, if you short pins 8-9, right? Except it won't fully work the same as
the DL11, since interrupts work differently. But polled I/O will work the same.
But I would expect the speed characteristics to be the same for the console as for the
printer port.
Correct, printer and console are actually the same thing. If you use
the console cable (pin 8 connected to 9) then that materializes a DL11-like CSR set at
177560. Yes, with polled I/O such as the ODT microcode uses that works just like a real
DL11, but for interrupts it's different. In RSTS, either way that port becomes a
terminal port.
RSTS does have support for the graphics module, in "glass TTY" mode within the
initialization code and full VT220 emulation in RSTS proper. Well, except for blink mode,
and no bold in 132 column mode.
6:58 a.m.
New subject: [simh] RSTS processor identification
On Mar 5, 2021, at 9:02 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-03-06 02:33, Paul Koning wrote:
...
The 380 has an entirely different core design. Instead of lots of discrete support chips
including a pile of screwball Intel chips, it uses a pair of gate arrays that incorporate
all those functions. Or more precisely, the subset that the OS actually needs. This is
really obvious when you compare the 350 and 380 documentation for the interrupt
controllers -- the 350 uses Intel chips, the 380 only implements a tiny subset of what
those chips do.
I'm guessing here, but a possible reason for the 10 MHz issue is if the support chips
use that clock, and use a synchronous design for the clock boundary crossing rather than
an asynchronous design. It's entirely possible to design a chip that has an outside
interface with an unrelated clock frequency, but it's harder to do and harder to get
right.
paul
The explanation I heard for the slow J-11 clock
is that the original J-11 spec called for it to operate at 20 MHz. When Harris failed to
deliver and the max useable clock speed ended up to be 18 MHz, most designs had no
trouble. But the Pro support chips were designed to run synchronous with the CPU clock
and for various other reasons needed a clock frequency that's a multiple of 10 MHz, so
when 20 MHz was ruled out that left 10 MHz as the only alternative.
I do think it sounds weird that the support chips would require a clock that is a
multiple of 10 MHz. But I wouldn't know for sure.
Somewhere else I read/heard that they didn't work reliable above 10 MHz, but for the
F11 that was ok. When the -380 came, they just reused those support chips.
5 Mar
5 Mar
6:15 p.m.
New subject: [simh] RSTS processor identification
> 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.
That sucks. I sometimes wonder how hard it would be to code the hard
disk driver, if it doesn't do DMA it's probably simple as dirt to be
honest. Any idea if it worked like MCSP or was it totally off the wall?
The most embarassing blunder with the Pro is that the
bus supports DMA, but no I/O cards use it. Even though a bunch of them should have --
hard disk controller obviously, network adapter possibly as well.
I think they used an intel chipset to handle the CTI bus, so the normal
Q-Bus DMA methods just doesn't work. Hm. Wonder if the problem is they
just didn't build the driver to support DMA, or if they found some
problem that made DMA just not work at all....
The 380 *was* a mess, mine is a formidable bit of kit with DECNA and
everything, but without I/D space it's really not too very useful as
more than a really nice VT terminal.
8 Mar
8 Mar
6:55 a.m.
New subject: [simh] RSTS processor identification
On Mar 5, 2021, at 9:15 PM, Chris Zach via cctalk
<cctalk at classiccmp.org> wrote:
The Pro hard disk driver is indeed pretty simple. Nothing like DDCMP; it's more like
an old style disk controller with CSRs to tell the device what to do. Basically, you
convert linear sector number to cylinder/track/sector (which requires knowing the specific
drive type), then load that into the CSRs along with a command. Then for a write
operation you write the words of data, 256 of them, to the data buffer CSR. For a read,
you wait for the data ready interrupt, then read the data one word at a time from that
same CSR. Repeat for the next sector.
The floppy is similar except that the transfer is byte-at-a-time, and the address mapping
is more complicated because the software has to deal with the sector interleave, track
skew, and funny cylinder numbering.
An entirely different odd design is the Pro Ethernet card, which uses the evil 82568
Ethernet chip. That does DMA -- into a 64kW memory that's part of the DECNA card. So
the OS would allocate Ethernet buffers to that memory space and can then do DMA.
That's not too bad, and 64kW is a decent amount of memory. The real problem is that
the 82568 is by far the worst DMA engine design ever created. It actually implements
design errors that were well understood and well documented (and solved) 20 years earlier,
but such considerations never stopped Intel.
> 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.
That sucks. I sometimes wonder how hard it would be to code the hard disk driver, if it
doesn't do DMA it's probably simple as dirt to be honest. Any idea if it worked
like MCSP or was it totally off the wall? The most
embarassing blunder with the Pro is that the bus supports DMA, but no I/O cards use it.
Even though a bunch of them should have -- hard disk controller obviously, network adapter
possibly as well.
I think they used an intel chipset to handle the CTI bus, so the normal Q-Bus DMA methods
just doesn't work. Hm. Wonder if the problem is they just didn't build the driver
to support DMA, or if they found some problem that made DMA just not work at all....
The 380 *was* a mess, mine is a formidable bit of kit
with DECNA and everything, but without I/D space it's really not too very useful as
more than a really nice VT terminal.
I/D space is just an OS issue; it works fine in the 380. As for a VT terminal, it's
actually reasonably good at that but not great; the video can't quite do the full
VT220 video.
paul
5 Mar
5 Mar
6:22 p.m.
New subject: [simh] RSTS processor identification
On Fri, Mar 5, 2021 at 6:33 PM Paul Koning via cctalk <cctalk at classiccmp.org>
wrote:
I would have liked better comms. The USART has such a
tiny FIFO that you
can't run it at higher than 9600 bps even with the J-11 CPU. At least not
with RSTS; perhaps a lighter weight OS can do better. The printer port is
worse, that one can't run DDCMP reliably at more than 4800 bps. I normally
run DDCMP on the PC3XC, which is a 4-line serial card that uses two dual
UART chips (2681?) with reasonable FIFO.
There seem to be a great many models of Unibus and Qbus multi-port async
serial boards, which present different register-level interfaces, e.g. for
Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered "best",
for each bus, for use with a multitasking OS like RSTS/E or RSX-11M+?
7:05 p.m.
New subject: [simh] RSTS processor identification
There seem to be a great many models of Unibus and
Qbus multi-port async
serial boards, which present different register-level interfaces, e.g. for
Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered "best",
for each bus, for use with a multitasking OS like RSTS/E or RSX-11M+?
Depends on your use case. The mighty DLV11 is nice, but it's interrupt
driven so every time you shove a character out it takes bus cycles and
every time a character comes in you have to drop what you're doing. The
DLV11-J will run down your system if used for interactive users as it's
4 DLV11's.
DZV is a step up, you at least have an incoming FIFO, can program the
baud rates in software, and they can afford to buffer a bit. But a bunch
of DZV11's can sink your bus as well, so you go to the DHV11.
DHV11 is what you need for a lot of users: Bigger FIFO buffer for input,
DMA access to do a lot of characters in a few bus cycles, and oddly
enough intelligence to do things like automatically send XON and XOFF
without having to bother the CPU. Apparently you can send and receive on
all 8 channels at 9600 baud simultaneously which is pretty good.
Going above this you start to get into the DMC11 type boards which have
hardware support for DDCMP and the like. That's what you want if you're
going to do DECNET Phase III over serial lines. You can do it with the
other boards but the CPU is going to have to deal with the framing and
whatnot.
But by then you just do ethernet.
C
7:26 p.m.
New subject: [simh] RSTS processor identification
On Fri, Mar 5, 2021 at 7:05 PM Chris Zach via cctalk
<cctalk at classiccmp.org> wrote:
And then isn't the M3107 DHQ11 slightly better than the M3104 DHV11?
DHQ11 User Guide, EK-DHQ11-UG-002
The main application of the DHQ11 is for interactive terminal
handling; it can also be used for data concentration and real-time
processing. It has two programming modes, DHV11 and DHU11. The
register sets in these modes are compatible with those of the DHV11
and DHU11 respectively. The preferred mode of operation is DHU11 mode.
The main features of the DHQ11 are:
For transmission: DMA transfers; or for each line, program transfers
to a 1-character transmit buffer in DHV11 mode, or to a 64-character
transmit FIFO in DHU11 mode.
For receive: a 256-entry FIFO buffer for received characters, dataset
status changes, and diagnostic information.
(And also, the M3118 CXA16 and M3119 CXY08 are essentially equivalent
to the M3107 DHQ11 from a software and performance point of view, but
in S-handle card form factor?)
There seem to be a great many models of Unibus
and Qbus multi-port async
serial boards, which present different register-level interfaces, e.g. for
Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered "best",
for each bus, for use with a multitasking OS like RSTS/E or RSX-11M+?
DHV11 is what you need for a lot of users: Bigger FIFO buffer for input,
DMA access to do a lot of characters in a few bus cycles, and oddly
enough intelligence to do things like automatically send XON and XOFF
without having to bother the CPU. Apparently you can send and receive on
all 8 channels at 9600 baud simultaneously which is pretty good.
7:08 p.m.
New subject: [simh] RSTS processor identification
On 2021-03-06 03:22, Eric Smith wrote:
On Fri, Mar 5, 2021 at 6:33 PM Paul Koning via cctalk
<cctalk at classiccmp.org <mailto:cctalk at classiccmp.org>> wrote:
I would have liked better comms.? The USART has such a tiny FIFO
that you can't run it at higher than 9600 bps even with the J-11
CPU.? At least not with RSTS; perhaps a lighter weight OS can do
better.? The printer port is worse, that one can't run DDCMP
reliably at more than 4800 bps.? I normally run DDCMP on the PC3XC,
which is a 4-line serial card that uses two dual UART chips (2681?)
with reasonable FIFO.
There seem to be a great many models of Unibus and Qbus multi-port async
serial boards, which present different register-level interfaces, e.g.
for Unibus, DH11, DHU11, DJ11, DM11, DZ11 . Which ones are considered
"best", for each bus, for use with a multitasking OS like RSTS/E or
RSX-11M+?
In general, you should pick a controller that can do as much as possible
with DMA.
Which means DH11 or DHU11 for Unibus.
Similar with Qbus: DHV11.
Johnny
--
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
1384
days inactive
1387
days old
20 comments
7 participants
participants (7)
-
bobsmithofd＠gmail.com -
bqt＠softjar.se -
cctalk＠beyondthepale.ie -
cz＠alembic.crystel.com -
glen.slick＠gmail.com -
paulkoning＠comcast.net -
spacewar＠gmail.com