[cctalk] Re: RSTS/E questions.

[Paul Koning via cctalk]

> On Dec 24, 2023, at 9:23 AM, Bill Gunshannon via cctalk 
>  wrote:
> 
> 
> 
> I am back to playing with RSTS/E 10.1 again and have a couple questions
> if there is still anyone around with experience.
> 
> First:  Is there a way to change the allowed length for passwords?

The minimum length defaults to 6; the max is 6 for passwords that can be looked 
up (not hashed) and 14 otherwise.  The max is fixed.  You can change the min by 
patching module OVR, address ..MPWD to the value you want.

> Second:  Is there a way to make login take the assigned name rather than
> the x,x format for logins?  I seem to remember using a system once that
> did but I have no idea if it was legit or a local hack.  Although I have
> no problem using local hacks.  :-)

No.  There was a "named accounts" A/D project in the V8.0 era, and fragments of 
that may have made it out the door in that version.  It worked reasonably well 
in the development systems at the time, as I recall.  But it was never 
finished.  If any of it remained in the code, that was all removed by V9.  
Interestingly enough, it certainly could have been done in V9 more easily than 
in V8, given the new file structure, but none of that was ever undertaken that 
I know of.

FYA, another incomplete piece of work (this one in V9.0) was "installed files". 
 Those were files left permanently open, so you could access them without a 
directory search.  That wasn't all that interesting, but a variant of that 
operation would install the file with an associated privilege mask.  The idea 
was for "privileged programs" to be selectively privileged, just as account are 
in V9 and later.  I got that working but we never did the followup work needed 
to sort out exactly what privs each privileged program actually needs, so the 
old approach (all or nothing) continued to be in use.

> Need to get a system going and maybe even join HECNET.
> I really wish there was TCP/IP for RSTS.

I found one for V8.0, described as by "Stacken, Royal Institute Of Technology, 
Stockholm, Sweden".   I haven't tried to use it.  A logical approach would be 
to update it for V10.1 and hook it to the standard Ethernet drivers in that 
release.  The original comes with a DELUA driver, and a document describing it 
-- in Swedish.  It's clearly not the same API as the Ethernet drivers in RSTS, 
which have an extended set of "I/O service" function codes for use by kernel 
components like DECnet or LAT.  So, minimally,  porting that code would involve 
updating it to that API.

I forgot where I found this code.  Johnny, do you know about it?

paul

[cctalk] RSTS/E questions.

[Bill Gunshannon via cctalk]

I am back to playing with RSTS/E 10.1 again and have a couple questions
if there is still anyone around with experience.

First:  Is there a way to change the allowed length for passwords?

Second:  Is there a way to make login take the assigned name rather than
the x,x format for logins?  I seem to remember using a system once that
did but I have no idea if it was legit or a local hack.  Although I have
no problem using local hacks.  :-)

Need to get a system going and maybe even join HECNET.
I really wish there was TCP/IP for RSTS.

bill

[cctalk] Re: Two items for RSTS/E

[Paul Koning via cctalk]

> On Nov 20, 2023, at 10:05 PM, Tim Sneddon via cctalk  
> wrote:
> 
> On Tue, 21 Nov 2023 at 06:13, Paul Koning via cctalk 
> wrote:
> 
>> I just pushed two additions to https://github.com/pkoning2/decstuff :
>> 
>> In "patches" a new patch for the DEUNA driver.  This fixes a problem seen
>> when doing user (as opposed to DECnet) I/O, as well as two errors that show
>> up when using units beyond the first.
>> 
>> Directory "ntp" is new.  This is a simple NTP protocol client for RSTS,
>> which will synchronize the system clock with an NTP server on the LAN.  It
>> includes handling of timezone rules, so the right thing will happen at
>> daylight savings time (summer time) boundaries.  The clock is maintained to
>> the full RSTS resolution -- typically 1/50th or 1/60th second, but can be
>> as low as 10 ms if the KW-11/P clock is used.
>> 
> 
> This is awesome! Thanks, Paul.

Glad you like it.  Comments welcome.

When I first posted this I still had trouble with the QNA driver.  Those are 
now fixed (patch file patches/xhdvr.cmd) so it now works on both UNA and QNA 
devices.

I've tested this in SIMH.  I would expect it to work on real hardware too, but 
I don't have any to try, so reports on actual machines would be particularly 
interesting.

paul

[cctalk] Re: Two items for RSTS/E

[Tim Sneddon via cctalk]

On Tue, 21 Nov 2023 at 06:13, Paul Koning via cctalk 
wrote:

> I just pushed two additions to https://github.com/pkoning2/decstuff :
>
> In "patches" a new patch for the DEUNA driver.  This fixes a problem seen
> when doing user (as opposed to DECnet) I/O, as well as two errors that show
> up when using units beyond the first.
>
> Directory "ntp" is new.  This is a simple NTP protocol client for RSTS,
> which will synchronize the system clock with an NTP server on the LAN.  It
> includes handling of timezone rules, so the right thing will happen at
> daylight savings time (summer time) boundaries.  The clock is maintained to
> the full RSTS resolution -- typically 1/50th or 1/60th second, but can be
> as low as 10 ms if the KW-11/P clock is used.
>

This is awesome! Thanks, Paul.

Regards, Tim.

[cctalk] Two items for RSTS/E

[Paul Koning via cctalk]

I just pushed two additions to https://github.com/pkoning2/decstuff :

In "patches" a new patch for the DEUNA driver.  This fixes a problem seen when 
doing user (as opposed to DECnet) I/O, as well as two errors that show up when 
using units beyond the first.  

Directory "ntp" is new.  This is a simple NTP protocol client for RSTS, which 
will synchronize the system clock with an NTP server on the LAN.  It includes 
handling of timezone rules, so the right thing will happen at daylight savings 
time (summer time) boundaries.  The clock is maintained to the full RSTS 
resolution -- typically 1/50th or 1/60th second, but can be as low as 10 ms if 
the KW-11/P clock is used.

paul

[cctalk] Re: Installing DEC C on RSTS/E

[Paul Koning via cctalk]

Short for mim.stupi.net  -- Johnny's web server where I 
found an assortment of RSX manuals, including a whole bunch of layered product 
manuals that carry over to other PDP-11 operating systems as well.  A lot of 
them don't seem to be on Bitsavers.  Among them are installation manuals for 
things like DEC C, APL, and Datatrieve.

So now I have DEC C installed, and it works.  Its generated code is 
surprisingly bad, though.  Loading a sequence of structure fields by loading 
the base address into a register once for each assignment is a rather obvious 
bad idea.  So while GCC is not exactly stellar on PDP-11 (or VAX) code 
generation, it does better than that.

paul

> On Nov 8, 2023, at 10:50 AM, Lee Courtney via cctalk  
> wrote:
> 
> Not related to the original question, but what is "STUPI?"
> 
> TIA!
> 
> Lee C.
> 
> On Tue, Nov 7, 2023 at 11:10 PM Paul Koning via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> 
>> 
>>> On Nov 7, 2023, at 8:49 PM, Paul Koning  wrote:
>>> 
>>> Hi...  I'm seriously rusty on official RSTS installation procedures.
>> I'm trying to install DEC C using the C_V1_2.tap file from the bitsavers
>> bits/DEC/pdp11/rsts directory.  It's actually a TPC file, in spite of what
>> the extension suggests.  Once I supply the correct format, SIMH recognizes
>> it and RSTS can see the tape contents.
>>> 
>>> Then I try @[0,1]install c81.  Point to the tape, answer the
>> destination, and then it asks me for the "library" tape and complains when
>> I give it the C tape again (labels don't match).
>>> 
>>> So what is it looking for?  Does anyone have the C installation
>> procedure handy?
>>> 
>>>  paul
>> 
>> Never mind... (a) C81 is COBOL (!!) not C.  And I found the C installation
>> manual on STUPI.  Off & running now.
>> 
>>paul
>> 
>> 
> 
> -- 
> Lee Courtney
> +1-650-704-3934 cell

[cctalk] Re: Installing DEC C on RSTS/E

[Paul Koning via cctalk]

> On Nov 8, 2023, at 1:54 PM, ben via cctalk  wrote:
> 
> On 2023-11-07 7:05 p.m., Paul Koning via cctalk wrote:
>>> On Nov 7, 2023, at 8:49 PM, Paul Koning  wrote:
>>> 
>>> Hi...  I'm seriously rusty on official RSTS installation procedures.  I'm 
>>> trying to install DEC C using the C_V1_2.tap file from the bitsavers 
>>> bits/DEC/pdp11/rsts directory.  It's actually a TPC file, in spite of what 
>>> the extension suggests.  Once I supply the correct format, SIMH recognizes 
>>> it and RSTS can see the tape contents.
>>> 
>>> Then I try @[0,1]install c81.  Point to the tape, answer the destination, 
>>> and then it asks me for the "library" tape and complains when I give it the 
>>> C tape again (labels don't match).
>>> 
>>> So what is it looking for?  Does anyone have the C installation procedure 
>>> handy?
>>> 
>>> paul
>> Never mind... (a) C81 is COBOL (!!) not C.  And I found the C installation 
>> manual on STUPI.  Off & running now.
>>  paul
> Come one, don't hide you are a CLOSET COBOL PROGRAMMER.

Not me, but my younger sister is an expert (RPG also).  She observed that 
"COBOL is the programming language that gives you writer's cramp".

> Will COBOL (C81) run on a regular 11, or does it need to be upgraded?

I don't remember.  Possibly it can use CIS if present but I don't think it 
requires that.

paul

[cctalk] Re: Installing DEC C on RSTS/E

[ben via cctalk]

On 2023-11-07 7:05 p.m., Paul Koning via cctalk wrote:




On Nov 7, 2023, at 8:49 PM, Paul Koning  wrote:

Hi...  I'm seriously rusty on official RSTS installation procedures.  I'm 
trying to install DEC C using the C_V1_2.tap file from the bitsavers 
bits/DEC/pdp11/rsts directory.  It's actually a TPC file, in spite of what the 
extension suggests.  Once I supply the correct format, SIMH recognizes it and 
RSTS can see the tape contents.

Then I try @[0,1]install c81.  Point to the tape, answer the destination, and then it 
asks me for the "library" tape and complains when I give it the C tape again 
(labels don't match).

So what is it looking for?  Does anyone have the C installation procedure handy?

paul


Never mind... (a) C81 is COBOL (!!) not C.  And I found the C installation manual 
on STUPI.  Off & running now.

paul


Come one, don't hide you are a CLOSET COBOL PROGRAMMER.
Will COBOL (C81) run on a regular 11, or does it need to be upgraded?

[cctalk] Re: Installing DEC C on RSTS/E

[Lee Courtney via cctalk]

Not related to the original question, but what is "STUPI?"

TIA!

Lee C.

On Tue, Nov 7, 2023 at 11:10 PM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> > On Nov 7, 2023, at 8:49 PM, Paul Koning  wrote:
> >
> > Hi...  I'm seriously rusty on official RSTS installation procedures.
> I'm trying to install DEC C using the C_V1_2.tap file from the bitsavers
> bits/DEC/pdp11/rsts directory.  It's actually a TPC file, in spite of what
> the extension suggests.  Once I supply the correct format, SIMH recognizes
> it and RSTS can see the tape contents.
> >
> > Then I try @[0,1]install c81.  Point to the tape, answer the
> destination, and then it asks me for the "library" tape and complains when
> I give it the C tape again (labels don't match).
> >
> > So what is it looking for?  Does anyone have the C installation
> procedure handy?
> >
> >   paul
>
> Never mind... (a) C81 is COBOL (!!) not C.  And I found the C installation
> manual on STUPI.  Off & running now.
>
> paul
>
>

-- 
Lee Courtney
+1-650-704-3934 cell

[cctalk] Re: Installing DEC C on RSTS/E

[Paul Koning via cctalk]

> On Nov 7, 2023, at 8:49 PM, Paul Koning  wrote:
> 
> Hi...  I'm seriously rusty on official RSTS installation procedures.  I'm 
> trying to install DEC C using the C_V1_2.tap file from the bitsavers 
> bits/DEC/pdp11/rsts directory.  It's actually a TPC file, in spite of what 
> the extension suggests.  Once I supply the correct format, SIMH recognizes it 
> and RSTS can see the tape contents.
> 
> Then I try @[0,1]install c81.  Point to the tape, answer the destination, and 
> then it asks me for the "library" tape and complains when I give it the C 
> tape again (labels don't match).
> 
> So what is it looking for?  Does anyone have the C installation procedure 
> handy?
> 
>   paul

Never mind... (a) C81 is COBOL (!!) not C.  And I found the C installation 
manual on STUPI.  Off & running now.

paul

[cctalk] Installing DEC C on RSTS/E

[Paul Koning via cctalk]

Hi...  I'm seriously rusty on official RSTS installation procedures.  I'm 
trying to install DEC C using the C_V1_2.tap file from the bitsavers 
bits/DEC/pdp11/rsts directory.  It's actually a TPC file, in spite of what the 
extension suggests.  Once I supply the correct format, SIMH recognizes it and 
RSTS can see the tape contents.

Then I try @[0,1]install c81.  Point to the tape, answer the destination, and 
then it asks me for the "library" tape and complains when I give it the C tape 
again (labels don't match).

So what is it looking for?  Does anyone have the C installation procedure handy?

paul

Re: RSTS/E version numbers

[Paul Koning via cctalk]

> On May 31, 2021, at 1:55 PM, Antonio Carlini  wrote:
> 
> On 31/05/2021 15:04, Paul Koning wrote:
>> 
>> The earlier rule was that the first number is the major version, the letter 
>> is the minor version.  As of V7 it changed to major number dot minor number. 
>>  In either case, the dash number suffix is the baselevel number (development 
>> build cycle number).  Those typically restart at 0 or 1 for each release, so 
>> V5C-01 indicates only one baselevel was done for that minor release.  That 
>> may not be true in all cases; I doubt that V4B had 17 baselevels so that 
>> number probably wasn't reset between V4A and V4B.
> Looking at them I guess RT-11 does something similar: V2, V02B, V02C. I can 
> (just about :-)) cope with the seemingly optional leading 0, but would there 
> have been a V2A? There was for IAS. Actually IAS had V3, V3.1, V3.2, V3.2A, 
> V3.2B and V3.2C. So IAS went major.minor in a sort of half-hearted way :-)
> 
>> Sometimes version numbers seem to be missing.  I don't know if anyone ever 
>> saw V1, and I also never saw V3B though I have seen V3A and V3C.
>> 
> The "80th Birthday Memo" (http://www.silverware.co.uk/rsts_80th_birthday.htm) 
> says that V1 never made it out of the door. V2A-19 was the first to ship.
> 
> The "DEC 1957 to he Present" book 
> (http://gordonbell.azurewebsites.net/digital/dec%201957%20to%20present%201978.pdf)
>  confirms the FY in which RSTS-11 shipped but not the version number.
> 
> The earliest manuals online seem to be the V4.x ones available on bitsavers.

Yes, which makes experiments with older versions a bit tricky because the 
startup dialog is different (and cryptic).  I have the basic info somewhere, I 
should write it up.

paul

Re: RSTS/E version numbers

[Antonio Carlini via cctalk]

On 31/05/2021 15:04, Paul Koning wrote:


The earlier rule was that the first number is the major version, the letter is 
the minor version.  As of V7 it changed to major number dot minor number.  In 
either case, the dash number suffix is the baselevel number (development build 
cycle number).  Those typically restart at 0 or 1 for each release, so V5C-01 
indicates only one baselevel was done for that minor release.  That may not be 
true in all cases; I doubt that V4B had 17 baselevels so that number probably 
wasn't reset between V4A and V4B.
Looking at them I guess RT-11 does something similar: V2, V02B, V02C. I 
can (just about :-)) cope with the seemingly optional leading 0, but 
would there have been a V2A? There was for IAS. Actually IAS had V3, 
V3.1, V3.2, V3.2A, V3.2B and V3.2C. So IAS went major.minor in a sort of 
half-hearted way :-)



Sometimes version numbers seem to be missing.  I don't know if anyone ever saw 
V1, and I also never saw V3B though I have seen V3A and V3C.

The "80th Birthday Memo" 
(http://www.silverware.co.uk/rsts_80th_birthday.htm) says that V1 never 
made it out of the door. V2A-19 was the first to ship.


The "DEC 1957 to he Present" book 
(http://gordonbell.azurewebsites.net/digital/dec%201957%20to%20present%201978.pdf) 
confirms the FY in which RSTS-11 shipped but not the version number.


The earliest manuals online seem to be the V4.x ones available on bitsavers.


Antonio


--
Antonio Carlini
anto...@acarlini.com

Re: RSTS/E version numbers

[Paul Koning via cctalk]

> On May 31, 2021, at 10:04 AM, Paul Koning via cctalk  
> wrote:
> 
> 
> 
>> On May 31, 2021, at 8:06 AM, Antonio Carlini via cctalk 
>>  wrote:
>> 
>> Can someone explain RSTS/E version numbers to me?
>> 
>> They seem to be all over the place: V2A-19, V4A-12, V4B-17, V5A-21, V5B-24, 
>> V5C-01, V6A-02, V6B-02, V6C-03.
>> 
>> Then it seems to have switched scheme but the "-number" suffix reappears: 
>> V7.0, V7.2, V8.0-06.
>> 
>> Any clarification would be helpful.
> 
> I think this might have been part of a general DEC change in version 
> numbering conventions. 
> 
> The earlier rule was that the first number is the major version, the letter 
> is the minor version.  As of V7 it changed to major number dot minor number.  
> In either case, the dash number suffix is the baselevel number (development 
> build cycle number).  Those typically restart at 0 or 1 for each release, so 
> V5C-01 indicates only one baselevel was done for that minor release.  That 
> may not be true in all cases; I doubt that V4B had 17 baselevels so that 
> number probably wasn't reset between V4A and V4B.
> 
> The definition of "minor release" was not always applied consistently.  For 
> example, V6B was the first release that was built natively (using RT-11 
> emulation) rather than using DOS.  And its the first release that did bus 
> probing at startup to figure out the peripheral configuration and adjust the 
> running monitor to match.  That seems like a pretty large change, but for 
> some reason it didn't prompt a new major number.
> 
> The notation change happened part way through the V7.0 development cycle.  I 
> remember a memo from management entitled "RSTS V7A canceled" :-) .

Found it.  See 
http://bitsavers.org/magazines/RSTS_Professional/RSTS_Professional_V02_N03_198009.pdf,
 page number 6 (8th page in the PDF file).

paul

Re: RSTS/E version numbers

[Paul Koning via cctalk]

> On May 31, 2021, at 8:06 AM, Antonio Carlini via cctalk 
>  wrote:
> 
> Can someone explain RSTS/E version numbers to me?
> 
> They seem to be all over the place: V2A-19, V4A-12, V4B-17, V5A-21, V5B-24, 
> V5C-01, V6A-02, V6B-02, V6C-03.
> 
> Then it seems to have switched scheme but the "-number" suffix reappears: 
> V7.0, V7.2, V8.0-06.
> 
> Any clarification would be helpful.

I think this might have been part of a general DEC change in version numbering 
conventions. 

The earlier rule was that the first number is the major version, the letter is 
the minor version.  As of V7 it changed to major number dot minor number.  In 
either case, the dash number suffix is the baselevel number (development build 
cycle number).  Those typically restart at 0 or 1 for each release, so V5C-01 
indicates only one baselevel was done for that minor release.  That may not be 
true in all cases; I doubt that V4B had 17 baselevels so that number probably 
wasn't reset between V4A and V4B.

The definition of "minor release" was not always applied consistently.  For 
example, V6B was the first release that was built natively (using RT-11 
emulation) rather than using DOS.  And its the first release that did bus 
probing at startup to figure out the peripheral configuration and adjust the 
running monitor to match.  That seems like a pretty large change, but for some 
reason it didn't prompt a new major number.

The notation change happened part way through the V7.0 development cycle.  I 
remember a memo from management entitled "RSTS V7A canceled" :-) .

Sometimes version numbers seem to be missing.  I don't know if anyone ever saw 
V1, and I also never saw V3B though I have seen V3A and V3C.

paul

RSTS/E version numbers

[Antonio Carlini via cctalk]

Can someone explain RSTS/E version numbers to me?

They seem to be all over the place: V2A-19, V4A-12, V4B-17, V5A-21, 
V5B-24, V5C-01, V6A-02, V6B-02, V6C-03.


Then it seems to have switched scheme but the "-number" suffix 
reappears: V7.0, V7.2, V8.0-06.



Any clarification would be helpful.


Antonio


--

Antonio Carlini
anto...@acarlini.com

Re: [HECnet] RSTS/E patches

[Paul Koning via cctalk]

The patches I posted are mostly for both.  The kdj11e.cmd patch is for a 
problem seen on SIMH that probably can't happen on real hardware.  The nsp1.pat 
file Tony mentioned is certainly more likely on SIMH but I suspect could happen 
on real hardware also.  In any case, none of them will create problems on real 
hardware.

paul

> On Sep 15, 2020, at 9:20 AM, W2HX via cctalk  wrote:
> 
> Are these patches discussed below only for patching SIMH to fix problems with 
> it? Or are these fixes that are for actual PDP hardware implementations of 
> RSTS?
> 
> -Original Message-
> From: cctalk  On Behalf Of Tony Nicholson via 
> cctalk
> Sent: Monday, September 14, 2020 6:10 PM
> To: hec...@update.uu.se
> Cc: cctalk@classiccmp.org
> Subject: Re: [HECnet] RSTS/E patches
> 
> On Tue, Sep 15, 2020 at 7:28 AM Paul Koning  wrote:
> 
>> I previously created a Github repository for various DEC things, 
>> including updated DECnet/E utilities.  I thought that the RSTS patches 
>> I had posted in the past were there also, but that wasn't the case.
>> 
>> I've added a "patches" subdirectory, which contains the patches I have 
>> collected.  I just added a new one, which fixes a bug encountered when 
>> running SIMH set to be an 11/94.  In that case (and possibly some 
>> other similar variations) RSTS tries to figure out the line frequency 
>> and gets it wrong because SIMH executes much faster.
>> 
>> https://github.com/pkoning2/decstuff is the repository.
>> 
>>paul
>> 
>> 
> Thanks for this Paul.
> 
> There's also your NSP1.PAT patch to improve data flow using RSTS/E V10.1 
> under SIMH (posted to the SIMH mailing list in May 2016).
> 
> You'll find it and the NSP1.TXT describing it in my repository at
> 
> https://github.com/agn453/RSTS-E
> 
> in the "decnete" subdirectory.
> 
> I've recently joined HECnet and will be making some of my updates available 
> soon.
> 
> Tony
> 
> --
> Tony Nicholson 

RE: [HECnet] RSTS/E patches

[W2HX via cctalk]

Are these patches discussed below only for patching SIMH to fix problems with 
it? Or are these fixes that are for actual PDP hardware implementations of RSTS?

-Original Message-
From: cctalk  On Behalf Of Tony Nicholson via 
cctalk
Sent: Monday, September 14, 2020 6:10 PM
To: hec...@update.uu.se
Cc: cctalk@classiccmp.org
Subject: Re: [HECnet] RSTS/E patches

On Tue, Sep 15, 2020 at 7:28 AM Paul Koning  wrote:

> I previously created a Github repository for various DEC things, 
> including updated DECnet/E utilities.  I thought that the RSTS patches 
> I had posted in the past were there also, but that wasn't the case.
>
> I've added a "patches" subdirectory, which contains the patches I have 
> collected.  I just added a new one, which fixes a bug encountered when 
> running SIMH set to be an 11/94.  In that case (and possibly some 
> other similar variations) RSTS tries to figure out the line frequency 
> and gets it wrong because SIMH executes much faster.
>
> https://github.com/pkoning2/decstuff is the repository.
>
> paul
>
>
Thanks for this Paul.

There's also your NSP1.PAT patch to improve data flow using RSTS/E V10.1 under 
SIMH (posted to the SIMH mailing list in May 2016).

You'll find it and the NSP1.TXT describing it in my repository at

https://github.com/agn453/RSTS-E

in the "decnete" subdirectory.

I've recently joined HECnet and will be making some of my updates available 
soon.

Tony

--
Tony Nicholson 

Re: [HECnet] RSTS/E patches

[Tony Nicholson via cctalk]

On Tue, Sep 15, 2020 at 7:28 AM Paul Koning  wrote:

> I previously created a Github repository for various DEC things, including
> updated DECnet/E utilities.  I thought that the RSTS patches I had posted
> in the past were there also, but that wasn't the case.
>
> I've added a "patches" subdirectory, which contains the patches I have
> collected.  I just added a new one, which fixes a bug encountered when
> running SIMH set to be an 11/94.  In that case (and possibly some other
> similar variations) RSTS tries to figure out the line frequency and gets it
> wrong because SIMH executes much faster.
>
> https://github.com/pkoning2/decstuff is the repository.
>
> paul
>
>
Thanks for this Paul.

There's also your NSP1.PAT patch to improve data flow using RSTS/E V10.1
under SIMH (posted to the SIMH mailing list in May 2016).

You'll find it and the NSP1.TXT describing it in my repository at

https://github.com/agn453/RSTS-E

in the "decnete" subdirectory.

I've recently joined HECnet and will be making some of my updates available
soon.

Tony

-- 
Tony Nicholson 

RSTS/E patches

[Paul Koning via cctalk]

I previously created a Github repository for various DEC things, including 
updated DECnet/E utilities.  I thought that the RSTS patches I had posted in 
the past were there also, but that wasn't the case.

I've added a "patches" subdirectory, which contains the patches I have 
collected.  I just added a new one, which fixes a bug encountered when running 
SIMH set to be an 11/94.  In that case (and possibly some other similar 
variations) RSTS tries to figure out the line frequency and gets it wrong 
because SIMH executes much faster.

https://github.com/pkoning2/decstuff is the repository.

paul

Re: RSTS/E has just had its 50th Birthday...

[Ethan Dicks via cctalk]

On Sun, Jun 28, 2020 at 2:36 PM Paul Koning via cctalk
 wrote:
> > Err, I expect that that was RSTS-11 in June, 1970, not RSTS-E. Since RSTS-11
> > (which I learned to program on; happy memories :-) was a BASIC-PLUS only
> > system, and ran on a PDP-11/20, I suspect it was a fairly different 
> > operating
> > system (although no doubt it's BASIC-PLUS interpreter was ported to RSTS-E).
> >
> > I think RSTS/E needed the -11/45, introduced around June 1972; sources
> > give 1973 for RSTS/E.

I came to RSTS some time later (not counting dialling from a
DECwriter, I first really used RSTS/E in 1984) but with the difference
between RSTS-11 and RSTS/E, I went over David Ahl's "101 BASIC
Computing Games" to figure out from the code, from the run listings,
and from the descriptions, which of the many systems were used.  I
found references identifying about 40% of the games, and relevant to
this thread, ANIMAL and BLKJAC mention RSTS-11, several mention RSTS/E
(ACEYDU, FIPFOP, HOCKEY, HURKLE, MUGWMP, SALVO, and SYNONM), and one
mentions the EduSystem 70 (HRMABI).  In various places I've found
mention of the EduSystem 60 (single-user on a 4K PDP-11/20), the
EduSystem 70 (up to 8 users on a 16K PDP-11/20), and the EduSystem 80
(up to 16 users on a 24K PDP-11/20 and a specific mention or RSTS-11).
The EduSystem handbook (1973 publication date) only covers up to the
EduSystem 50 so I don't have configuration details of any of the
systems.

As I mention from time to time, I have an 11/20 that needs extensive
restoration work (it was rescued from the dumpster at work after my
supervisor stripped out fans and PSUs) and I'd love to find things to
run on it other than paper tape and toggle-in programs.  Finding a
copy of an EduSystem distro would be fantastic for demos.

Cheers,

-ethan

Re: RSTS/E has just had its 50th Birthday...

[Peter Dick via cctalk]

Good morning Noel

Thanks for the link  While I appreciate "retired" might describe your 
current status, I was looking for a better description of how you 
were/are involved with RSTS.


And...

You might be amused to learn I was the author of the RSTS 80th Birthday 
document.  It was "frozen" in late April 1990...


Bye/P




On 29/06/2020 01:05, Noel Chiappa wrote:

 > From: Peter Dick  
 
 > Question: how do the three of you (Noel) cctalk@classiccmp.org and Paul

 > Koning fit together?

CCTalk is a mailing list for people who collect antique ('classic') computers;
Paul and I are both members.  I collect PDP-11's (I used them in school from
'72 to '76, and worked with them from '77 to the mid-80's). Jay West, who
maintains the list, forwarded your email query about RSTS/E to the list.
(Paul you can find in the RSTS 80th birthday spoof, BTW.)

  Noel

Re: RSTS/E has just had its 50th Birthday...

[John H. Reinhardt via cctalk]

On 6/28/2020 6:16 PM, Paul Koning via cctalk wrote:

I don't remember if any of the material in bits/pdp11/rsts on Bitsavers is 
RSTS-11. There is the material from PDP-10 tapes that was discussed here in the 
past year, which I identified as very early RSTS sources. I don't know yet if 
they are complete enough to run, that would be an interesting experiment.
FWIW, there's a RSTS/E V10.1 source master copy (including DECnet/E and build 
control files) among the Bitsavers materials.

Has anyone ever posted any of the V6 or V7 sources?  I see the V8 and V10.1 
sources on Bitsavers.

paul



--
John H. Reinhardt
  PRRT  #8909
  C HS  #11530
  N-Trak   #7566

Re: RSTS/E has just had its 50th Birthday...

[Noel Chiappa via cctalk]

> From: Peter Dick  

> Question: how do the three of you (Noel) cctalk@classiccmp.org and Paul
> Koning fit together?

CCTalk is a mailing list for people who collect antique ('classic') computers;
Paul and I are both members.  I collect PDP-11's (I used them in school from
'72 to '76, and worked with them from '77 to the mid-80's). Jay West, who
maintains the list, forwarded your email query about RSTS/E to the list.
(Paul you can find in the RSTS 80th birthday spoof, BTW.)

  Noel

Re: RSTS/E has just had its 50th Birthday...

[Paul Koning via cctalk]

> On Jun 28, 2020, at 5:08 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Paul Koning
> 
>> RSTS/E of course has a bunch of new stuff in it to deal with mapping,
>> but the bulk of the code carries over from RSTS-11.
> 
> I was assuming that the basic intermal environment was sufficiently different
> that not a lot of the OS-level code could carry over, but I guess not.
> 
> DId you actually work on RSTS-11 internals (I don't know your exact dates at
> DEC), or did you just read the source?

Mostly I read the source, starting in university where we were running RSTS-11. 
 I started working on it at DEC in the V7.0 era, for DECnet V2.0.

> And speaking of which, are any RSTS-11 sources still extant? I found the RSTS
> directory on BitSavers, but it seems to have only manuals.

I don't remember if any of the material in bits/pdp11/rsts on Bitsavers is 
RSTS-11.  There is the material from PDP-10 tapes that was discussed here in 
the past year, which I identified as very early RSTS sources.  I don't know yet 
if they are complete enough to run, that would be an interesting experiment.

FWIW, there's a RSTS/E V10.1 source master copy (including DECnet/E and build 
control files) among the Bitsavers materials.

paul

Re: RSTS/E has just had its 50th Birthday...

[Noel Chiappa via cctalk]

> From: Paul Koning

    > RSTS/E of course has a bunch of new stuff in it to deal with mapping,
> but the bulk of the code carries over from RSTS-11.

I was assuming that the basic intermal environment was sufficiently different
that not a lot of the OS-level code could carry over, but I guess not.

DId you actually work on RSTS-11 internals (I don't know your exact dates at
DEC), or did you just read the source?

And speaking of which, are any RSTS-11 sources still extant? I found the RSTS
directory on BitSavers, but it seems to have only manuals.

  Noel

Re: RSTS/E has just had its 50th Birthday...

[Paul Koning via cctalk]

> On Jun 28, 2020, at 3:36 PM, Al Kossow via cctalk  
> wrote:
> 
> 
>> This means RSTS/E, the Greatest Operating System ever, has just turned 50 
>> years old.
> 
> Now, we all need to dig out the "RSTS 50th birthday" paper from eons ago..

You mean the 80th birthday spoof?  It's on line.  Probably several places; here 
is one: http://elvira.stacken.kth.se/rsts/rsts_80th_birthday.html 
<http://elvira.stacken.kth.se/rsts/rsts_80th_birthday.html>

paul

Re: FW: RSTS/E has just had its 50th Birthday...

[Al Kossow via cctalk]

This means RSTS/E, the Greatest Operating System ever, has just turned 50 years 
old.


Now, we all need to dig out the "RSTS 50th birthday" paper from eons ago..

Re: RSTS/E has just had its 50th Birthday...

[Paul Koning via cctalk]

> On Jun 28, 2020, at 2:24 PM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Peter Dick
> 
>> As I expect you know, RSTS was 'born' on 11th June 1970 as shown when
>> you print DATE$(1%) ...
>> This means RSTS/E, the Greatest Operating System ever, has just turned
>> 50 years old.
> 
> Err, I expect that that was RSTS-11 in June, 1970, not RSTS-E. Since RSTS-11
> (which I learned to program on; happy memories :-) was a BASIC-PLUS only
> system, and ran on a PDP-11/20, I suspect it was a fairly different operating
> system (although no doubt it's BASIC-PLUS interpreter was ported to RSTS-E).
> 
> I think RSTS/E needed the -11/45, introduced around June 1972; sources
> give 1973 for RSTS/E.
> 
>   Noel

RSTS/E of course has a bunch of new stuff in it to deal with mapping, but the 
bulk of the code carries over from RSTS-11.  For example, the file system code 
is basically the same, as is a large fraction of driver code as well as core 
kernel services.

RSTS/E did lose some oddball things, such as the fact that RSTS-11 did 
BASIC-PLUS string garbage collection through a file processor overlay.  

paul

FW: RSTS/E has just had its 50th Birthday...

[jwest--- via cctalk]

Please copy cctalk/cctech on any responses to Peter.

 

J

 

From: Peter Dick  
Sent: Saturday, June 27, 2020 4:34 PM
To: jw...@classiccmp.org
Subject: RSTS/E has just had its 50th Birthday...

 

Hi.  I stumbled on your wonderful PDP11.ORG website.

As I expect you know, RSTS was “born” on 11th June 1970 as shown when you print 
DATE$(1%) with Star Date format selected.

This means RSTS/E, the Greatest Operating System ever, has just turned 50 years 
old.

We would like to mark this historic moment by collecting a total of 50 memories 
from those of us who used RSTS/E at some time, obviously the earlier the 
better.  Or if you are still running old Basic Plus code, then the later the 
better!   I will then collate these memories and email them out to everyone who 
takes part. 

What memories?  It doesn’t matter.  Funny / technical / life changing / 
surprise / show how times have changed / whatever …

Length?  It doesn’t matter.  Your name will be included but not your email 
address unless you specifically want it included.

Please email contributions to 50ye...@silverware.co.uk 
<mailto:50ye...@silverware.co.uk> 

Bye/P

Peter Dick, ex Chairman DECUS UK RSTS SIG.

Re: HDDs (Was: PDP-11/45 RSTS/E boot problem

[Liam Proven via cctalk]

On Tue, 19 Feb 2019 at 22:00, Fred Cisin via cctalk
 wrote:
>
> Yes.
> I was thinking in terms of slightly older drives than that, particularly
> 5.25"
> Getting at the slider on newer drives wouldn't be practical.

Probably not. I suspect that ITRO 90+ % of the people I work with have
never seen a 5¼" hard disk. CD-R or DVD, yes, but they're possibly
unaware that HDs used to come in that formfactor.

I've had arguments with people over the meaning of "full height" and
"half height" before, because to them, the physically biggest drive
they've ever seen, in ancient kit (to them), is a CD drive. So
logically that _must_ mean "full height" because nothing is bigger,
therefore they redefined all the terms in their heads...

> The RAMAC came out in 1956?  The platters are 24" diameter.  Each platter
> was almost 100K!  But, with 50 platters, it maxed out at almost 5MB.
> When Nikita Khruschev made a peace mission to USA, they took him on a tour
> of the RAMAC facility.  But, they wouldn't let him go to DisneyLand! (THAT
> had repercussions in the Cuban missile crisis)

11 years before I came out, then.

I've seen and played a bit with some machines with 8" floppies, but I
think that's the biggest. I never saw the VAX 11-780 I learned Fortran
on.

> You could run Xenix on an XT!

True, but I think it wasn't a lot of use for commercial multiuser
accounts systems. They were the main market for Xenix for my
employers, early in my career. My 1st job sold Tetra, mainly
TetraPlan.

Checks... huh, later bought by Sage:
https://www.theregister.co.uk/1999/03/08/accounting_for_sages_move/

Later, I worked for places that sold other things, like SystemsUnion.
Happily a market I left long ago and have forgotten about.

> The stock IBM XT HDD controller (Xebec) had physical solder pads for drive
> type, and supported 5MB, 10MB, 15MB, and 25MB drives.  The 25 was, of
> course, best (if you could get one) and would permit a 10MB DOS partition
> dual booting with 15MB Xenix.  Was that the first "dual boot" in the
> PC world?  (or was there a CP/M-86 dual boot option once they added HDD
> support?)

DOS+ could dual-boot with PC DOS, as I recall. I think CDOS could too.
So, probably.

I'm quite glad the XT was fading away as I got into the PC business.
They were weird and constrained.

Still, not knowing about them means people working on PCs now don't
know where it came from...
> I used a lot of ST4096 drives.  Needed a second AT power supply for the
> second one.

Ha! Yes, I can believe that. IBM did under-spec the PSUs, though.

> I use 2TB 2.5" 7.5mm Seagate/Samsung drives for MP4s of movies in
> laptops and with a Seagate GoFlex-TV (media streamer with SATA slot)
> But, I finally filled 2TB
> Currently, that is the largest 7.5mm 2.5" drive available.  But SSDs are
> now available in 2TB, so when that price comes down, . . .
>
>
> Heard about the NSA Utah Data Center?
> https://nsa.gov1.info/utah-data-center/
> That's a LottaBytes!

O_o

Reminds me... I should buy a few more tibs, consolidate and rearrange
some stuff.

I wonder why megs and gigs caught on, but there's no common shorthand
for terabytes?

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

HDDs (Was: PDP-11/45 RSTS/E boot problem

[Fred Cisin via cctalk]

One of the moxt common causes of a terrible ear-piercing high whine is the
spindle contact.  Many old drives had a springy piece that rubbed against
the end of the spindle.  Over time, it would wear a divot, polish that,
and start to squeal.  A very light pressure on it would test that
hypothesis.  Not enough pressure to muffle the sound, and certaianly not
enough pressure to slow the spindle!  Or, pulling up on it, away from the
spindle.  Some people claimed that you could just rip it off.  Don't.
Best is to twist it very slightly sideways, so that it can start wearing a
new divot.


On Tue, 19 Feb 2019, Liam Proven via cctalk wrote:

It was a 3½" EIDE drive. 8GB one, I think, but might have been
smaller. I didn't want to open it to do that, although there was a
time when custom PC builders "de-lidded" hard disks and fitted them
with little acrylic windows so you could see the head move. Not sure
I'd want to trust my data to that...


Yes.
I was thinking in terms of slightly older drives than that, particularly 
5.25"

Getting at the slider on newer drives wouldn't be practical.


Well, there don't seem to be many 350 RAMAC disks still running.
(I'm trying to decide what to use as a base to make a patio table out of a
[crashed] RAMAC 24" platter)

Conceded.
And thank you for the reminder that I'm not old yet.


The RAMAC came out in 1956?  The platters are 24" diameter.  Each platter 
was almost 100K!  But, with 50 platters, it maxed out at almost 5MB.
When Nikita Khruschev made a peace mission to USA, they took him on a tour 
of the RAMAC facility.  But, they wouldn't let him go to DisneyLand! (THAT 
had repercussions in the Cuban missile crisis)



My first machine with a hard disk was my work PC in my first job: an
IBM PC-AT, with a 20 MB FS/FH 5¼" ST-506 drive, probably a Seagate
ST-4026. I added a second drive to the machine, a 15 MB one, and put
Xenix/286 on it.


You could run Xenix on an XT!
The stock IBM XT HDD controller (Xebec) had physical solder pads for drive 
type, and supported 5MB, 10MB, 15MB, and 25MB drives.  The 25 was, of 
course, best (if you could get one) and would permit a 10MB DOS partition 
dual booting with 15MB Xenix.  Was that the first "dual boot" in the 
PC world?  (or was there a CP/M-86 dual boot option once they added HDD 
support?)



A few years ago I bought a surplus 2½" 1 TB drive from a chap who'd
bought a new notebook and put an SSD in it before use. So, 2nd hand
but unused.
It cost me CzK 1000, about £30 at the time.
£30 for a terabyte. I was in a state of shock. It was so tiny, too.
I found an online capacity comparator thing.


I used a lot of ST4096 drives.  Needed a second AT power supply for the 
second one.

You'd need a pile of those Seagate drives the size of a _space
shuttle_ to hold a terabyte.
https://liam-on-linux.livejournal.com/53353.html


I use 2TB 2.5" 7.5mm Seagate/Samsung drives for MP4s of movies in 
laptops and with a Seagate GoFlex-TV (media streamer with SATA slot)
But, I finally filled 2TB 
Currently, that is the largest 7.5mm 2.5" drive available.  But SSDs are 
now available in 2TB, so when that price comes down, . . .



Heard about the NSA Utah Data Center?
https://nsa.gov1.info/utah-data-center/
That's a LottaBytes!

--
Grumpy Ol' Fred ci...@xenosoft.com

Re: PDP-11/45 RSTS/E boot problem

[Liam Proven via cctalk]

On Mon, 18 Feb 2019 at 22:16, Fred Cisin via cctalk
 wrote:
>
> One of the moxt common causes of a terrible ear-piercing high whine is the
> spindle contact.  Many old drives had a springy piece that rubbed against
> the end of the spindle.  Over time, it would wear a divot, polish that,
> and start to squeal.  A very light pressure on it would test that
> hypothesis.  Not enough pressure to muffle the sound, and certaianly not
> enough pressure to slow the spindle!  Or, pulling up on it, away from the
> spindle.  Some people claimed that you could just rip it off.  Don't.
> Best is to twist it very slightly sideways, so that it can start wearing a
> new divot.

It was a 3½" EIDE drive. 8GB one, I think, but might have been
smaller. I didn't want to open it to do that, although there was a
time when custom PC builders "de-lidded" hard disks and fitted them
with little acrylic windows so you could see the head move. Not sure
I'd want to trust my data to that...

> Well, there don't seem to be many 350 RAMAC disks still running.
>
> (I'm trying to decide what to use as a base to make a patio table out of a
> [crashed] RAMAC 24" platter)

Conceded.

And thank you for the reminder that I'm not old yet.

My first machine with a hard disk was my work PC in my first job: an
IBM PC-AT, with a 20 MB FS/FH 5¼" ST-506 drive, probably a Seagate
ST-4026. I added a second drive to the machine, a 15 MB one, and put
Xenix/286 on it.

A few years ago I bought a surplus 2½" 1 TB drive from a chap who'd
bought a new notebook and put an SSD in it before use. So, 2nd hand
but unused.

It cost me CzK 1000, about £30 at the time.

£30 for a terabyte. I was in a state of shock. It was so tiny, too.

I found an online capacity comparator thing.

You'd need a pile of those Seagate drives the size of a _space
shuttle_ to hold a terabyte.

https://liam-on-linux.livejournal.com/53353.html

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 18, 2019, at 4:47 PM, Jay Jaeger via cctalk  
> wrote:
> 
> On 2/18/2019 3:38 PM, Paul Koning via cctalk wrote:
>> 
>> ...
>> Then again, I remember our college RS64 (drive for the RC11) which developed 
>> a bad motor bearing.  ...
>> 
> 
> Nice of the FE to do that.
> 
> The Univ. of Wisconsin CS Department had one of those, but the platter
> went bad.  They just flipped the platter upside down and got more use
> out of it.

Yes, that was a feature.  You had to reformat it, which required getting the 
timing track writer box from Maynard.  I have seen that done on an RS11 (RF11) 
drive on our RSTS system; it crashed some heads and was rebuilt completely (new 
heads, new platter, new motor).

> The Univ. of Wisconsin ECE Department also had one - the two machines
> were nearly twins.  I *have* *that* one - and it still ran when I tried
> it a year or so ago.

Neat.  You can run RT11 on it if you add the boot loader and driver, at least 
old versions.  DOS V4 also supports it.  And older versions of RSTS can use it 
as a swap disk.

paul

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/18/2019 3:38 PM, Paul Koning via cctalk wrote:
> 
> 
>> On Feb 18, 2019, at 4:16 PM, Fred Cisin via cctalk  
>> wrote:
>>
>> On Mon, 18 Feb 2019, Liam Proven via cctalk wrote:
>>> Well that is the thing, of course. I had that with one old IDE disk,
>>> too. It made a terrible ear-piercing high whine that I associate with
>>> a failing disk... but it passed every diagnostic I could throw at it,
>>> so I used it for non-critical stuff and in testbed machines.
>>
>> One of the moxt common causes of a terrible ear-piercing high whine is the 
>> spindle contact.  Many old drives had a springy piece that rubbed against 
>> the end of the spindle.  
> 
> Then again, I remember our college RS64 (drive for the RC11) which developed 
> a bad motor bearing.  Since the platter is mounted directly on the motor 
> spindle that was a problem.  And it was not under contract, so replacing the 
> motor would have set back the department a substantial sum.  So the DEC FS 
> engineer removed the motor and carried it to Appleton Electric Motor Co., 
> which pulled the old bearing, pressed on a replacement, and handed it back.  
> Jim reinstalled the motor, all was well.  Didn't even lose any data bits.
> 
>   paul
> 

Nice of the FE to do that.

The Univ. of Wisconsin CS Department had one of those, but the platter
went bad.  They just flipped the platter upside down and got more use
out of it.

The Univ. of Wisconsin ECE Department also had one - the two machines
were nearly twins.  I *have* *that* one - and it still ran when I tried
it a year or so ago.

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 18, 2019, at 4:16 PM, Fred Cisin via cctalk  
> wrote:
> 
> On Mon, 18 Feb 2019, Liam Proven via cctalk wrote:
>> Well that is the thing, of course. I had that with one old IDE disk,
>> too. It made a terrible ear-piercing high whine that I associate with
>> a failing disk... but it passed every diagnostic I could throw at it,
>> so I used it for non-critical stuff and in testbed machines.
> 
> One of the moxt common causes of a terrible ear-piercing high whine is the 
> spindle contact.  Many old drives had a springy piece that rubbed against the 
> end of the spindle.  

Then again, I remember our college RS64 (drive for the RC11) which developed a 
bad motor bearing.  Since the platter is mounted directly on the motor spindle 
that was a problem.  And it was not under contract, so replacing the motor 
would have set back the department a substantial sum.  So the DEC FS engineer 
removed the motor and carried it to Appleton Electric Motor Co., which pulled 
the old bearing, pressed on a replacement, and handed it back.  Jim reinstalled 
the motor, all was well.  Didn't even lose any data bits.

paul

Re: PDP-11/45 RSTS/E boot problem

[Fred Cisin via cctalk]

On Mon, 18 Feb 2019, Liam Proven via cctalk wrote:

Well that is the thing, of course. I had that with one old IDE disk,
too. It made a terrible ear-piercing high whine that I associate with
a failing disk... but it passed every diagnostic I could throw at it,
so I used it for non-critical stuff and in testbed machines.


One of the moxt common causes of a terrible ear-piercing high whine is the 
spindle contact.  Many old drives had a springy piece that rubbed against 
the end of the spindle.  Over time, it would wear a divot, polish that, 
and start to squeal.  A very light pressure on it would test that 
hypothesis.  Not enough pressure to muffle the sound, and certaianly not 
enough pressure to slow the spindle!  Or, pulling up on it, away from the 
spindle.  Some people claimed that you could just rip it off.  Don't.
Best is to twist it very slightly sideways, so that it can start wearing a 
new divot.



My experience is extensive enough that _anyone's_ justifications of
why they won't use Brand X disks get ignored,


Well, there don't seem to be many 350 RAMAC disks still running.

(I'm trying to decide what to use as a base to make a patio table out of a 
[crashed] RAMAC 24" platter)


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: PDP-11/45 RSTS/E boot problem

[Liam Proven via cctalk]

On Sat, 16 Feb 2019 at 01:43, Peter Coghlan via cctalk
 wrote:
>   Days turned into weeks, weeks into months and months into
> years.  It continued to occasionally make the same ghastly noises that
> never should be heard coming from a hard disk but with absolutely no sign
> of any errors being logged or damage to data whatsoever.  The noises seem
> to be associated with seek activity because I have never heard them when
> the disk is just spinning but otherwise idle.  I eventually retired it
> and replaced it with a much larger one, purely because I ran out of
> space on it.  Any thoughts on what might be happening with it?

Ha!

Well that is the thing, of course. I had that with one old IDE disk,
too. It made a terrible ear-piercing high whine that I associate with
a failing disk... but it passed every diagnostic I could throw at it,
so I used it for non-critical stuff and in testbed machines.

For about 4 or 5 *years*. It was one reason to run machines with the
case covers on, to muffle the noise. But it ran faultlessly for years.
I think in the end I sold it on to someone, with a warning of course.
That's how I dispose of all kit -- pass it on to a new owner. I try
never to scrap or recycle anything at all.

That's the problem with rule-of-thumb diagnoses. Sometimes they fail.
But more often, things fail with no warning, so it's still useful.

This is why I disregard everyone's accounts of hard disk brands they
won't touch. I did PC tech support for ~25 years. I've seen every make
of hard drive ever fail randomly, and I've seen every make of hard
drive ever work flawlessly for years even when vilely abused.

My experience is extensive enough that _anyone's_ justifications of
why they won't use Brand X disks get ignored, because if I took them,
I would not use _any_brand of disk. Everyone who's been around a bit
has a horror story and the intersection in the Venn diagram, while
small, excludes all vendors ever.

I've never seen any one make that is significantly worse than any other.

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: PDP-11/45 RSTS/E boot problem

[Peter Coghlan via cctalk]

Liam Proven wrote:
> 
> And some of my younger colleagues thought it was strange that I could
> predict hard disk failures from the running noises they made, and
> later than that, whether WinNT's bus-mastering DMA-mode disk
> controller device driver was installed from the sound of the disk
> accesses while the machine booted.
>

The little 8GB SCA system disk in my Alphaserver 800 started making
awful bloodcurdling clattering noises a few years ago.  The first time
I heard it, I was convinced that the works were splattered all over the
inside of the HDA casing and the machine was only continuing to run
because of what was left in the disk cache or something like that.  I
started running a backup in case I might be able to salvage some part of
the contents.  Despite several more heartstopping clunks and clatters
while the backup was running, it ran to completion, with no errors logged
to my complete surprise.  I ran an ANALYZE /DISK /READ which attempts to
read all blocks on the disk that are allocated to files.  Again, several
more awful clanks and clatters but it completed with no errors.  I lined
up a replacement disk for it but I was curious to see how exactly it
was going to fail so I decided to keep on using it for a while to see
what happens.  Days turned into weeks, weeks into months and months into
years.  It continued to occasionally make the same ghastly noises that
never should be heard coming from a hard disk but with absolutely no sign
of any errors being logged or damage to data whatsoever.  The noises seem
to be associated with seek activity because I have never heard them when
the disk is just spinning but otherwise idle.  I eventually retired it
and replaced it with a much larger one, purely because I ran out of
space on it.  Any thoughts on what might be happening with it?

Regards,
Peter Coghlan.

Re: PDP-11/45 RSTS/E boot problem

[Peter Coghlan via cctalk]

Jeffrey S. Worley wrote:
> 
> Back in 2000-ish, I was upgrading my DG MV4000/dc to 8mb so as to be
> able to run the snazzy AOS/VS II tapes I'd got along with the 9 track
> drive I hacked onto the machine...
> 
> The install would start and then bomb at a certain point every time.  I
> decided to work the machine hard and then pull the board and give a
> good SNIFF.  This is a 15x15 inch board populated with 256kx1 drams. 
> The time in the machine got the board cooking nicely, and when I
> smelled a certain charred smell in the vicinity of a 74ls04, I knew it
> was that magic black smoke.  I pulled a 74HCT04 from a known-good isa
> card, socketed the spot and viola!  Working 8mb board.  It isn't
> ALLWAYS the most expensive chip, thank God, and sometimes even us not-
> as-bright guys come off with a win.
>

About 20 years earlier than that, one of my friends at school asked me to
fix his Jupiter Ace which had stopped working.  I told him I didn't hold
out much hope for success because I didn't have the vaguest idea how his
little machine worked at that time but I agreed to wave my multimeter in
the general direction of it's power supply.  I opened it up and quickly
found that the voltages seemed very reasonable and I prodded around the
board rather aimlessly looking for some part that looked guilty.  I soon
noticed that one of the eight identical chips in a row at the bottom of
the board was getting hot enough to burn my finger while the others
remained cool and calm.  I can't remember where I got a replacement 4116
or 4164 or whatever it was - I probably had to get it mail order but once
it was soldered in with fingers crossed that nothing else was wrong, the
machine came right back to life.  Sometimes you just get lucky.  I wish I
could be that lucky with some of my own stuff now.

Regards,
Peter Coghlan.

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Paul Koning

> Studied it for a while, took out a small hammer, whacked the device at
> some spot, and reported "fixed".

That reminds me of an amusing story from the first time I went to see 'Star
Wars; I went with a group of people from Tech Sq. It has that scene where
they're about to make the jump to hyperspace in the 'Falcon', and it won't
go; so one of them (I think Solo) jumps up and whacks a particular spot on
the bulkhead with his fist, and away she goes.

We all found this terribly amusing, since one of the DEC time-sharing systems
on the 9th floor had a sticky relay in the power controller, and when you'd
try to power it on or off from the front panel, the relay would stick, and
nothing would happen. So the procedure was to go around the back, open a
particular door, reach in, and whack the power controller behind it in a
particular spot with the side of your fist, and away it went!

Noel

Re: PDP-11/45 RSTS/E boot problem

[Liam Proven via cctalk]

On Fri, 15 Feb 2019 at 14:59, Paul Koning  wrote:
>
> Speaking of sounds made by machines, there is a famous security paper from a 
> few years ago in which researchers read the encryption keys out of 
> smartphones by listening to the sounds made by the device while it was 
> execution the crypto algorithms.

... wow.

> These hardware wizard stories remind me of a legendary repair wizard, 
> non-computer industrial devices I think.  He was called in to fix a tricky 
> problem at the customer site.  Studied it for a while, took out a small 
> hammer, whacked the device at some spot, and reported "fixed".  He then sent 
> in a bill for $500.
>
> Customer challenged that with a demand to itemize the work.  The itemized 
> bill came back like this:
>
> 1. Applying impact to the device: $5
> 2. Knowing where and how to apply the impact: $495

110 years old, and still apt.

https://quoteinvestigator.com/2017/03/06/tap/

I first encountered it in the form of one of the AI Koans. I guess
these are probably familiar to all here, but in case:

http://people.cs.uchicago.edu/~wiseman/humor/ai-koans.html

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 15, 2019, at 6:06 AM, Liam Proven via cctalk  
> wrote:
> 
> On Fri, 15 Feb 2019 at 04:34, Jeffrey S. Worley via cctalk
>  wrote:
>> 
>> The install would start and then bomb at a certain point every time.  I
>> decided to work the machine hard and then pull the board and give a
>> good SNIFF.
> 
> Got a nose for a hardware fault, eh? ;-)
> 
> And some of my younger colleagues thought it was strange that I could
> predict hard disk failures from the running noises they made, and
> later than that, whether WinNT's bus-mastering DMA-mode disk
> controller device driver was installed from the sound of the disk
> accesses while the machine booted.

Speaking of sounds made by machines, there is a famous security paper from a 
few years ago in which researchers read the encryption keys out of smartphones 
by listening to the sounds made by the device while it was execution the crypto 
algorithms.

These hardware wizard stories remind me of a legendary repair wizard, 
non-computer industrial devices I think.  He was called in to fix a tricky 
problem at the customer site.  Studied it for a while, took out a small hammer, 
whacked the device at some spot, and reported "fixed".  He then sent in a bill 
for $500.

Customer challenged that with a demand to itemize the work.  The itemized bill 
came back like this:

1. Applying impact to the device: $5
2. Knowing where and how to apply the impact: $495

   paul

Re: PDP-11/45 RSTS/E boot problem

[Peter Coghlan via cctalk]

Fritz Mueller wrote:
> 
> That's right -- I wasn't without an army, it was just a very small and
> quite dedicated army! :-)
> 
> I think I'd have gone down many blind alleys without help and perspective
> provided by others here, and in particular a lot guidance provided by Noel
> over the past couple weeks in private correspondence enabling the use of
> V6 as a test case and investigative tool.  For this I am very grateful.
> 

I very much enjoyed following the story of tracking down this fault.
Thanks for sharing it.

> 
> As those of you who have worked on these machines know, they are just so
> damn serviceable, by design.  It's very empowering!
> 

I wish that this was also the case with several DEC Alphas I have with
cache failures that are not nearly so serviceable or empowering  :-(

Regards,
Peter Coghlan.

>
>   --FritzM.
>

Re: PDP-11/45 RSTS/E boot problem

[Liam Proven via cctalk]

On Fri, 15 Feb 2019 at 04:34, Jeffrey S. Worley via cctalk
 wrote:
>
> The install would start and then bomb at a certain point every time.  I
> decided to work the machine hard and then pull the board and give a
> good SNIFF.

Got a nose for a hardware fault, eh? ;-)

And some of my younger colleagues thought it was strange that I could
predict hard disk failures from the running noises they made, and
later than that, whether WinNT's bus-mastering DMA-mode disk
controller device driver was installed from the sound of the disk
accesses while the machine booted.

BTW, Jeff, Gmail bottom-quotes just fine. I'm using the web interface
right now. Just hit Ctrl-A, trim as needed and move the cursor. Yes,
it's a pain on mobile, so I try not to answer on mobiles!

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: PDP-11/45 RSTS/E boot problem

[William Pechter via cctalk]

> Message: 2
> Date: Wed, 13 Feb 2019 15:03:41 -0500
> From: Paul Koning 
> To: Jay Jaeger , "General Discussion: On-Topic and
>     Off-Topic Posts" 
> Subject: Re: PDP-11/45 RSTS/E boot problem
> Message-ID: 
> Content-Type: text/plain;    charset=us-ascii
>
>
> > On Feb 13, 2019, at 1:20 PM, Jay Jaeger via cctalk
>  wrote:
> >
> > ...
> > Maybe that story about FE's using Unix as a test to confirm operation
> > even when diagnostics said the machine was OK was not so much just a
> > legend?
>
> It still fels like a legend.  My experience with DEC field service
> engineers is that they used the diagnostics.  In the PDP-11 era, Unix
> knowledge around DEC was pretty sparse, especially early on when it
> could be found only in the Telephone Products Group (Armando
> Stettner).  RSTS would be more plausible, but I never saw that in the
> hads of FS engineers either.
> By and large diagnostics would find problems. I've seen a number in
> the 1970s, including a messy data path failure in the 11/45 MMU where
> we (college students) did the initial diagnosis while the FS engineer
> was on his way. My suspicion is that things not solved by diagnostics
> would be escalated to the "wizard from Maynard". And they'd probably
> start replacing whole subsystems. I've seen that once, when our
> college RSTS-11 system (11/20, 16 DL-11 lines) was crashing on average
> once a day for months. DEC brought in several of those "wizards". The
> "fix" was to replace the 11/20 by a "spare part" -- an 11/45 with more
> memory, a DH11, and RSTS/E. Decades later I was told that the wizards
> actually pinned the blame on the college FM broadcast transmitter,
> about 200 feet down the hall from the computer center. That may well
> be, though I didn't heard that at the time. RSTS did get used in
> manufacturing, at Final Assembly & Test sites like Westminster MA and
> Salem NH, where PDP-11 systems large enough to run RSTS/E were
> subjected to a load test of exerciser programs running under that OS.
> The way it was explained to us is that a system that would be happy
> with such a test would also be happy with any customer application.
> It's not clear if that was because RSTS would load things more than
> most, or was more finicky about hardware glitches than most, but it
> certainly was the practice for quite some time. Of course, not all
> PDP-11 configurations could be tested that way. paul

I guess the experience in NJ was a bit different since AT had two
dedicated Field Service offices who handled their sites including Bell Labs.

I was on the Commercial/Government side from 81-86 and we didn't get to
play with RSTS on customer sites at all (but sometimes we got to play in
the in-house machines in Princeton or on our own hardware).

It was a bit different in the Vax side since many diags were run under
VAX/VMS and as a brand new hire I was doing Vax installs -- including
installing the VMS 2.x and 3.x on 11/780's and 11/750's at install time.

If they had paid for software installation -- the software guys would
wipe and reinstall.
If not we left the pack and prayed the customer wouldn't wipe the diags
that we installed on the disk when we build the VMS pack.  Realistically
the only thing the customer needed to do after we got done was tweak the
systen parameters, check the swap etc. and lay on the layered products
like languages.

Things got much more interesting when the VMS3.x and 4.x got CI780's and
HSC50's.  That was more involved than the easy VMS 2.x-3.x install.

As far as the 11/70's -- I'm building a pidp1170... My last 11/70
install was around 84 or so when I put in a late DECDatasystem 570 blue
11/70 with the FCC Cabinets at AT in Freehold.

As far as the Wizard from Maynard -- one story from my branch support
guy (rumored to be about his
brother on the 11/70 line in (I think in Westminster MA... not Salem or
other NH plants) had an intermittant 11/70 that would crash every couple
of days and they could run all the diags and DEC X11 with no issues. 
They called over their in-house wizard who ran toggle-in programs from
the front panel -- playing the switches like piano keys with both
hands.   After about a half hour his comment was "Clean the terminator
fingers."

Machine ran like a SOB once the gold fingers were cleaned.

Weirdest 11/70 mess I had was after I left DEC to work for a third party
maintenance group.  Their regional support was in Dallas.  I was in NJ. 
They couldn't find their support guy so they rushed me on a plane to
Chicago to work with two techs who were babysitting a mess they had no
clue on.

The site was WW Granger in Skokie and I arrived at 3AM...  They had a 5
or 6 story warehouse which was a totally robotic automated site picking
water heaters and other industrial equ

Re: PDP-11/45 RSTS/E boot problem

[Jeffrey S. Worley via cctalk]

I got a laugh out of this anecdote.  Of course, folks heard me chuckle
and I tried to share the joke but  Way too geeky for public
consumption.

Back in 2000-ish, I was upgrading my DG MV4000/dc to 8mb so as to be
able to run the snazzy AOS/VS II tapes I'd got along with the 9 track
drive I hacked onto the machine...

The install would start and then bomb at a certain point every time.  I
decided to work the machine hard and then pull the board and give a
good SNIFF.  This is a 15x15 inch board populated with 256kx1 drams. 
The time in the machine got the board cooking nicely, and when I
smelled a certain charred smell in the vicinity of a 74ls04, I knew it
was that magic black smoke.  I pulled a 74HCT04 from a known-good isa
card, socketed the spot and viola!  Working 8mb board.  It isn't
ALLWAYS the most expensive chip, thank God, and sometimes even us not-
as-bright guys come off with a win.

I really enjoy reading this list even though I don't contribute all
that often or anything of much value.  It is a pleasure to watch you
guys work.

Jeff


On Thu, 2019-02-14 at 12:00 -0600, cctalk-requ...@classiccmp.org wrote:
> Re: PDP-11/45 RSTS/E boot problem

> When our 11/45 failed in the MMU in 1975, my classmate Josh Rosen
traced the failing path on the schematics.  When Jim Newport the field
service engineer showed up, Josh described the diagnostics result that
pointed at the failed path, and added "This is the failed chip"
(pointing to one particular chip.

Jim asked "Why that one?"  Josh answered "because that is the most
expensive chip".

It turned out he was right.

paul

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

That's right -- I wasn't without an army, it was just a very small and quite 
dedicated army! :-)

I think I'd have gone down many blind alleys without help and perspective 
provided by others here, and in particular a lot guidance provided by Noel over 
the past couple weeks in private correspondence enabling the use of V6 as a 
test case and investigative tool.  For this I am very grateful.

As those of you who have worked on these machines know, they are just so damn 
serviceable, by design.  It's very empowering!

--FritzM.

PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Paul Koning

> or a backup team of subsystem experts at the home office to call on.

Actually, the actual hardware problem wasn't too hard for Fritz to find, I
gather, once we knew exactly was failing (the RK11), and how (at 017, the
XM incremented). It's not like it was a comes-and-goes kind of problem (it
was quite solid and repeatable), or anything like that, so I'm not sure a
'team of experts' would really have helped.

And the exact details on the failure were also pretty easy to find, once we
got past a lot of other distractions! Once it became clear that the pure text
was getting trashed, it was pretty easy (modulo some confusion caused by the
differing OS images in the 'Ritchie' and 'Wellsch' distros :-) to stop the
machine once it had a) assembled the pure text in main memory, and b) swapped
it out.

Looking at the copy in main memory verified it was good _before_ it was
swapped, looking at the arguments on the stack gave us the disk block it was
written to, and looking at the actual contents of the RK (which PDP11GUI has a
mode to do) showed us the first 02400 bytes were good, and then it was
trash. Bingo!

Then, looking at the RK registers after the transfer had completed showed
something had gone wrong in the hardware - the address left showing
afterward was not the start_address+size - the XM had incremented
inappropriately! And since the start address for the transfer in physical
memory was 0165400, and 0165400+2400 = 017, that sounded pretty
suspicious!

So, that all happened pretty quickly. Really, the part that took the longest
was getting past all the confusing noise: my confusion about R5, the
malfunctioning front panel, the different versions of the OS, etc, etc.

Noel

Re: PDP-11/45 RSTS/E boot problem

[Alan Frisbie via cctalk]

Ethan Dicks  wrote:

> I have had an RK11-C for a long time that I've never tried to
> power up (I got an RKV11-D and used that on Qbus machines
> instead).

Wow, someone else with an RKV11-D!  I thought I was the only
person who had one.   I modified mine (using the dead bug
technique) to add 18-bit addressing instead of just 16, and
ran it successfully with RT-11 and RSX-11M on my 11/73 system.

I have had DEC people visit my place, look at the RKV11-D, and
say "DEC never made anything like that!".  :-)

Alan "and I don't exist either" Frisbie

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Jerry Weiss

> I am trying to understand how the diagnostics didn't reveal this defect.

Vondada #12: "Diagnostics are highly efficient in finding solved problems." :-)

Noel

PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

[oops, accidentally replied directly instead of to the list]

On 2/13/19 12:54 PM, Ethan Dicks wrote:
> It's interesting that it was a bad 7430 in [your RK11-C].  I find that for 
> equipment of that vintage, my usual suspects are failed 7474s and failed 
> 7440s, probably 80% of the total.  Behind that, it goes 7420s and then maybe 
> 7430s.

Looking back over my repair log, my totals just within the RK11-C were:

2x 7430 (M119, M795)
1x 7420 (M141)
1x 7401 (M149)
1x 7400 (M203)

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

On 2/13/19 5:20 PM, Jerry Weiss wrote:
I am trying to understand how the diagnostics didn't reveal this 
defect.  I see in the source for the diagnostic DZRKH-F there are tests 
for address in the 28K-32K range and also for the 32K boundary.


So, to catch this defect the diagnostic would have to have a test or 
tests which crossed _specifically_ the 30K boundary within a transfer.


The detailed symptom was a false overflow into the ex.mem bits on the 
30K boundary, causing a skip forward in bus addresses during the transfer.


The detailed fail on the 7430 (E34 on the M795) was that it acted as if 
input pin 11 was always H.


Now, all this said, I don't think I have ever run ZRKH!  I *did* run and 
pass the earlier ZRKA, ZRKB, and ZRKC, but somehow missed ZRKH...  I'm 
wondering now how different it is from ZRKC?  Will have to take a look...


--FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Jon Elson via cctalk]

On 02/13/2019 10:40 AM, Noel Chiappa via cctalk wrote:

He's also had to do a tremendous amount of work on it to get it running,
starting with building an entire new power harness.
Yes, the 5V power harness between the regulators and the 
backplane were a real mess on the 11/45 we got second hand.  
I probably SHOULD have rebuilt the entire harness and 
replaced all the Mate-n-Lock connectors on the regulators, 
too, but we were always just wanting to get the machine 
running again.


Jon

Re: PDP-11/45 RSTS/E boot problem

[Jerry Weiss via cctalk]

On 2/13/19 1:43 AM, Fritz Mueller via cctalk wrote:

SUCCESS!!

Put the M795 out on an extender, loaded 16 in RKBAR, and had a look around 
with a logic probe.  Narrowed it down to E34 (a 7430 8-input NAND).  Pulled, 
socketed, replaced, and off she goes!

I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.

*THAT* was a really fun and rewarding hunt :-)  First message in the thread was 
back on Dec 30, 2018.  Lots of debugging and failed DRAM repairs, then the 
final long assault to this single, failed gate...

Thanks to all here for the help and resources, and particular shout-outs for 
Noel and Paul who gave generously of their time and attention working through 
the densest bits, both on and off the list.

I predict a long happy weekend and a big power bill at the end of the month :-)

 cheers,
   --FritzM.



Congratulations.  Well Done.

I am trying to understand how the diagnostics didn't reveal this 
defect.  I see in the source for the diagnostic DZRKH-F there are tests 
for address in the 28K-32K range and also for the 32K boundary.


I'm trying to make sense of the M795 to get a better understanding. Any 
addition data on how the 7430 failed (input bad, output bad, etc ?)


  Jerry

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 13, 2019, at 3:03 PM, Paul Koning  wrote:
> 
> ...
> My suspicion is that things not solved by diagnostics would be escalated to 
> the "wizard from Maynard".  And they'd probably start replacing whole 
> subsystems. 

This says that Fritz actually was a new "Wizard from Maynard" in solving this 
problem.  Only more so -- because he didn't have the luxury of just swapping 
out whole sections of the machine with new kits, or a backup team of subsystem 
experts at the home office to call on.

That confirms it's really a very impressive performance.

paul

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 13, 2019, at 3:54 PM, Ethan Dicks via cctalk  
> wrote:
> 
> ...
> It's interesting that it was a bad 7430 in yours.  I find that for
> equipment of that vintage, my usual suspects are failed 7474s and
> failed 7440s, probably 80% of the total.  Behind that, it goes 7420s
> and then maybe 7430s.

When our 11/45 failed in the MMU in 1975, my classmate Josh Rosen traced the 
failing path on the schematics.  When Jim Newport the field service engineer 
showed up, Josh described the diagnostics result that pointed at the failed 
path, and added "This is the failed chip" (pointing to one particular chip.

Jim asked "Why that one?"  Josh answered "because that is the most expensive 
chip".

It turned out he was right.

paul

Re: PDP-11/45 RSTS/E boot problem

[Ethan Dicks via cctalk]

On Wed, Feb 13, 2019 at 2:43 AM Fritz Mueller via cctalk
 wrote:
>
> SUCCESS!!

Outstanding!

> Put the M795 out on an extender, loaded 16 in RKBAR, and had a look 
> around with a logic probe.  Narrowed it down to E34 (a 7430 8-input NAND).  
> Pulled, socketed, replaced, and off she goes!
>
> I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.

Nice.

I have had an RK11-C for a long time that I've never tried to power up
(I got an RKV11-D and used that on Qbus machines instead).  The saga
has been interesting for me as I contemplate getting mine working in
the next couple of years.  I had to look up the M795.  I had forgotten
there was one dual-height module in the entire controller.

It's interesting that it was a bad 7430 in yours.  I find that for
equipment of that vintage, my usual suspects are failed 7474s and
failed 7440s, probably 80% of the total.  Behind that, it goes 7420s
and then maybe 7430s.

-ethan

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 13, 2019, at 1:20 PM, Jay Jaeger via cctalk  
> wrote:
> 
> ...
> Maybe that story about FE's using Unix as a test to confirm operation
> even when diagnostics said the machine was OK was not so much just a
> legend?

It still fels like a legend.  My experience with DEC field service engineers is 
that they used the diagnostics.  In the PDP-11 era, Unix knowledge around DEC 
was pretty sparse, especially early on when it could be found only in the 
Telephone Products Group (Armando Stettner).  RSTS would be more plausible, but 
I never saw that in the hads of FS engineers either.

By and large diagnostics would find problems.  I've seen a number in the 1970s, 
including a messy data path failure in the 11/45 MMU where we (college 
students) did the initial diagnosis while the FS engineer was on his way.

My suspicion is that things not solved by diagnostics would be escalated to the 
"wizard from Maynard".  And they'd probably start replacing whole subsystems.  
I've seen that once, when our college RSTS-11 system (11/20, 16 DL-11 lines) 
was crashing on average once a day for months.  DEC brought in several of those 
"wizards".  The "fix" was to replace the 11/20 by a "spare part" -- an 11/45 
with more memory, a DH11, and RSTS/E.

Decades later I was told that the wizards actually pinned the blame on the 
college FM broadcast transmitter, about 200 feet down the hall from the 
computer center.  That may well be, though I didn't heard that at the time.

RSTS did get used in manufacturing, at Final Assembly & Test sites like 
Westminster MA and Salem NH, where PDP-11 systems large enough to run RSTS/E 
were subjected to a load test of exerciser programs running under that OS.  The 
way it was explained to us is that a system that would be happy with such a 
test would also be happy with any customer application.  It's not clear if that 
was because RSTS would load things more than most, or was more finicky about 
hardware glitches than most, but it certainly was the practice for quite some 
time.  Of course, not all PDP-11 configurations could be tested that way.

paul

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/13/2019 1:43 AM, Fritz Mueller via cctalk wrote:
> SUCCESS!!
> 
> Put the M795 out on an extender, loaded 16 in RKBAR, and had a look 
> around with a logic probe.  Narrowed it down to E34 (a 7430 8-input NAND).  
> Pulled, socketed, replaced, and off she goes!
> 
> I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.
> 
> *THAT* was a really fun and rewarding hunt :-)  First message in the thread 
> was back on Dec 30, 2018.  Lots of debugging and failed DRAM repairs, then 
> the final long assault to this single, failed gate...
> 
> Thanks to all here for the help and resources, and particular shout-outs for 
> Noel and Paul who gave generously of their time and attention working through 
> the densest bits, both on and off the list.
> 
> I predict a long happy weekend and a big power bill at the end of the month 
> :-)
> 
> cheers,
>   --FritzM.
> 
> 

Congratulations.As another poster mentioned, it has been fascinating
to watch and learn, day by day, as you worked on the problem with Noel
and Paul's help.

And I learned a little bit more about my 11/45 (that it indeed had had a
processor field upgrade), which I had not looked at very closely before.

Maybe that story about FE's using Unix as a test to confirm operation
even when diagnostics said the machine was OK was not so much just a
legend?

PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Alan Frisbie

> I am finding this entire discussion extremely fascinating! Every day I
> look forward to reading the latest twists in the plot.

I forgot to mention the most amazing part of the whole story: he first
acquired the machine while he was a student (I think?) at CMU, decades ago,
and has been dragging it around the country with him ever since!

He's also had to do a tremendous amount of work on it to get it running,
starting with building an entire new power harness. He's also had to find and
fix a long list of failures, all over the machine; there were bad chips on
almost every board in it.

Fritz has written most of the whole adventure up:

 http://fritzm.github.io/category/pdp-11.html

it's an incredible story.

Noel

Re: PDP-11/45 RSTS/E boot problem

[Jon Elson via cctalk]

On 02/13/2019 01:43 AM, Fritz Mueller via cctalk wrote:

SUCCESS!!

Put the M795 out on an extender, loaded 16 in RKBAR, and had a look around 
with a logic probe.  Narrowed it down to E34 (a 7430 8-input NAND).  Pulled, 
socketed, replaced, and off she goes!


WOW!  Good detective work, that certainly was a WEIRD 
problem, and not where I thought it was going to be.


Glad you got it solved!

Jon

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Alan Frisbie

> I am finding this entire discussion extremely fascinating! Every day I
> look forward to reading the latest twists in the plot.

:-)

> The ideas, hunches, tests, dead ends, and results are an excellent
> example of the debugging process.

Yeah, and it was a Duesie of a problem, too.

Although once we got clear of the bad data from the console and my confusion
about R5, and it became clear that in the Unix failure, the pure text was
being damaged, from that point it was pretty straightforward to track it down
(albeit one that needed detailed understanding of how V6 handled pure texts -
and luckily I'd come to understand that part of the system a bit while getting
the QSIC running).

Fritz's lucky discovery, early on, that it was location dependent was also a
big help.

Noel

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 13, 2019, at 2:43 AM, Fritz Mueller via cctalk  
> wrote:
> 
> SUCCESS!!
> 
> Put the M795 out on an extender, loaded 16 in RKBAR, and had a look 
> around with a logic probe.  Narrowed it down to E34 (a 7430 8-input NAND).  
> Pulled, socketed, replaced, and off she goes!
> 
> I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.

Congratulations.  You have successfully performed a repair of the type done at 
customer sites by highly trained DEC field service personnel.  They were the 
ones who traveled with an oscilloscope, a tool case including soldering iron, 
and a case full of replacement chips.

One difference is that the diagnostics didn't point to the problem, which in my 
experience is rather an unusual situation.  Nicely done.

paul

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

SUCCESS!!

Put the M795 out on an extender, loaded 16 in RKBAR, and had a look around 
with a logic probe.  Narrowed it down to E34 (a 7430 8-input NAND).  Pulled, 
socketed, replaced, and off she goes!

I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.

*THAT* was a really fun and rewarding hunt :-)  First message in the thread was 
back on Dec 30, 2018.  Lots of debugging and failed DRAM repairs, then the 
final long assault to this single, failed gate...

Thanks to all here for the help and resources, and particular shout-outs for 
Noel and Paul who gave generously of their time and attention working through 
the densest bits, both on and off the list.

I predict a long happy weekend and a big power bill at the end of the month :-)

cheers,
  --FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Alan Frisbie via cctalk]

> > > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!
> >
> > No; the RK11 spec says "[the two extended memory bits] make up a two-bit
> > counter that increments each time the RKBA overflows".
> >
> > The actual error turns out to be slightly different to my guess; there's
> > a spurious overflow from the low 16-bit register to these bits at 017.
> 
> Maybe a problem with E29 or E34 on the M795 module?

I am finding this entire discussion extremely fascinating!
Every day I look forward to reading the latest twists in the
plot.   The ideas, hunches, tests, dead ends, and results are an
excellent example of the debugging process.

I am awaiting the exciting Perry Mason style conclusion, where
the guilty chip stands up and confesses on the stand.  :-)

Alan "Where were you on the night of the crime?" Frisbie

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Jerry Weiss

> it is impressive that UNIX booted successfully without tripping over a
> boundary.

Well, V6 is (or can be configured to be) extraordinarily small, so I'm not
surprised it booted OK without going over the 017 mark.

I have this persistent memory that the -11/40 in the CSR group at MIT had only
3 banks of MM-L (@16KB each) when I first got there! Which is plausible; the
smallest V6 config would have about 22KB of core text, and about 2KB of
initialized data. If you cut all the parameters to the bone (minimal number of
disk buffers, etc) you could probably get away with say 6KB of un-initialized
data. That would leave you 18KB for user programs on such a system, a bit less
than their recommendation of 24KB minimum for users, but probably minimally
useable.

We quickly added more memory, I'm sure, but I don't now remember how/what!
Later on it was converted to an -11/45, and then we got an Able ENABLE, but
that would have been a couple of years later.

 Noel

Re: PDP-11/45 RSTS/E boot problem

[Jerry Weiss via cctalk]

On 2/11/19 12:31 PM, Noel Chiappa via cctalk wrote:

 > From: Jerry Weiss

 > Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K
 > boundaries.

Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219)
from the RC11 controller, and that _can_ cross moby boundaries, so clearly it
has the right overflow output; someone just decided not to implement it - the
DR11-B sets ERROR instead on an address overflow. Wierd.
    Yes the overflow sets error and halts the transfer.  There are 
registers for the extended bits in the DR11B, just missing a few gates 
to increment.   My recollection is that my simple mod wouldn't allow the 
read back of the incremented extended bits, but in my use case this was 
never a problem.



Anyway, it will be interesting to see if RSTS operates correctly once this
problem is fixed...

Noel
  
Yes if turns out the increment was not functional for one or both 
extended address bits, it is impressive that UNIX booted successfully 
without tripping over a boundary.


  Jerry

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Jerry Weiss

> Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K
> boundaries.

Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219)
from the RC11 controller, and that _can_ cross moby boundaries, so clearly it
has the right overflow output; someone just decided not to implement it - the
DR11-B sets ERROR instead on an address overflow. Wierd.

Anyway, it will be interesting to see if RSTS operates correctly once this
problem is fixed...

Noel

 

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 11, 2019, at 1:13 PM, Jerry Weiss  wrote:
> 
> On 2/11/19 11:50 AM, Paul Koning via cctalk wrote:
>>> ...
>> You may be thinking about PC controllers like the floppy controller.  I 
>> can't remember ANY DEC DMA device controller that had boundary crossing 
>> limits of any kind.  It certainly isn't a restriction in the RK11.
>> 
>>  paul
>> 
> Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K 
> boundaries.
> 
> I did however via a single chip "dead bug" modification, modify one to 
> accomplish this.  
>
> Jerry

That's rather shocking.  I meant my comment to apply to every DMA controller, 
not just disks.  I never used the DR11-B, though.  Perhaps there are other 
obscure devices that get this wrong.  But, for example, even devices like 
DMC-11 and TS-11 got it right.

There are of course Q-bus devices that only do a partial address space, but my 
point is that whatever the number of address bits implemented, address 
arithmetic is as a matter of normal design done across all of them, not across 
a subset.

paul

Re: PDP-11/45 RSTS/E boot problem

[Jerry Weiss via cctalk]

On 2/11/19 11:50 AM, Paul Koning via cctalk wrote:

On Feb 11, 2019, at 11:12 AM, Jon Elson via cctalk  
wrote:

On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:

A look at the RK11 registers after the swap-out showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.



OH, BOY!  I think you may have found it.  Likely some disk controllers did NOT 
SUPPORT crossing 64K boundaries!  The diags would not detect that, as it was 
likely expected behavior.  I would suspect the driver would need to break up 
these operations.

You may be thinking about PC controllers like the floppy controller.  I can't 
remember ANY DEC DMA device controller that had boundary crossing limits of any 
kind.  It certainly isn't a restriction in the RK11.

paul

Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K 
boundaries.


I did however via a single chip "dead bug" modification, modify one to 
accomplish this.


    Jerry

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

Yup; specifically, the symptoms are consistent with 'D15 RKBA=ALL 1 L' being 
incorrectly generated at BA 16, causing an increment to EX.MEM, causing a 
skip in the DMA.

So it looks like problem with bit 12 in that carry logic; I'll check E28 and 
E34 when I get back to it tonight, but I have to move the machine around so I 
can climb inside :-)

  --FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Tony Duell via cctalk]

On Mon, Feb 11, 2019 at 6:03 PM Noel Chiappa via cctalk
 wrote:
>
> > From: Jon Elson
>
> > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!
>
> No; the RK11 spec says "[the two extended memory bits] make up a two-bit
> counter that increments each time the RKBA overflows".
>
> The actual error turns out to be slightly different to my guess; there's
> a spurious overflow from the low 16-bit register to these bits at 017.

Maybe a problem with E29 or E34 on the M795 module?

-tony

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Jon Elson

> Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!

No; the RK11 spec says "[the two extended memory bits] make up a two-bit
counter that increments each time the RKBA overflows".

The actual error turns out to be slightly different to my guess; there's
a spurious overflow from the low 16-bit register to these bits at 017.

I can see how the diags didn't catch that one! Unless you try a multi-block
xfer that walks across the boundary A perfect example of Vonada #12.

 Noel

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 11, 2019, at 11:12 AM, Jon Elson via cctalk  
> wrote:
> 
> On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
>> A look at the RK11 registers after the swap-out showed an anomaly; something
>> about the extended memory address bits? (Maybe a multi-block transfer than
>> crosses a 64KB boundary? That would explain the address sensitivity we were
>> seeing.) Hopefully he'll track it to its lair shortly.
>> 
>> 
> OH, BOY!  I think you may have found it.  Likely some disk controllers did 
> NOT SUPPORT crossing 64K boundaries!  The diags would not detect that, as it 
> was likely expected behavior.  I would suspect the driver would need to break 
> up these operations.

You may be thinking about PC controllers like the floppy controller.  I can't 
remember ANY DEC DMA device controller that had boundary crossing limits of any 
kind.  It certainly isn't a restriction in the RK11.

paul

Re: PDP-11/45 RSTS/E boot problem

[Tony Duell via cctalk]

On Mon, Feb 11, 2019 at 4:13 PM Jon Elson via cctalk
 wrote:
>
> On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:
> > A look at the RK11 registers after the swap-out showed an anomaly; something
> > about the extended memory address bits? (Maybe a multi-block transfer than
> > crosses a 64KB boundary? That would explain the address sensitivity we were
> > seeing.) Hopefully he'll track it to its lair shortly.
> >
> >
> OH, BOY!  I think you may have found it.  Likely some disk
> controllers did NOT SUPPORT crossing 64K boundaries!  The
> diags would not detect that, as it was likely expected
> behavior.  I would suspect the driver would need to break up
> these operations.

I _think_ the RK11-C should cross a 64K boundary correctly. There's
an output from the low 16 bits bus address module (M795) on pin BP2
'D15 RKBA=ALL 1 L' (page 27 of the schematic on Bitsavers)  that
goes to the counter that holds the 2 extended bits, pin C1 of the M239
in slot A17 (page 13 of the same .pdf)

[I am working from 'RK11-C_schemFeb1971.pdf' from bitsavers]

Of course if there is a fault in this area then it will not correctly increment
the top 2 bits, but that might give you somewhere to check.

-tony

Re: PDP-11/45 RSTS/E boot problem

[Jon Elson via cctalk]

On 02/11/2019 07:04 AM, Noel Chiappa via cctalk wrote:

A look at the RK11 registers after the swap-out showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.


OH, BOY!  I think you may have found it.  Likely some disk 
controllers did NOT SUPPORT crossing 64K boundaries!  The 
diags would not detect that, as it was likely expected 
behavior.  I would suspect the driver would need to break up 
these operations.


Jon

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Fritz Mueller

> If, as you are suspecting, we find damning evidence pointing
> specifically to the RK11

I got an update from Fritz. As you all will recall, the problem seemed to be
a corrupted 'pure text'. So the question was 'when was it damaged, and how'.

After some confusion caused by different OS images (the 'Ritchie' and
'Wellsch' distros), he managed to get a look at the text in main memory after
it was first read in from the file system, and before it was swapped out (it
was showing up damaged after a swap out/in cycle); it looked good at that
point. The copy written out to the swap disk however, not so good.

A look at the RK11 registers after the swap-out showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.

We also need to characterize exactly what the fault is, because the DEC RK11
diagnostics weren't finding it, so it seems the diagnostic suite could use an
enhancement

Noel

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

>> This seems the best place to start with the LA this weekend then.
> 
> I'm going to respectfully semi-disagree! I think that at this point there's a
> good chance we can localize to within a gate or two before we start applying
> test instruments.

Oh, I agree completely, Noel.  I should have more precisely said "when/if we 
get to the LA this weekend, this seems the place to start."

If, as you are suspecting, we find damning evidence pointing specifically to 
the RK11, I'm going to want to watch it going about its business; the LA will 
be a good tool for that.

And yes, one of the beautiful things about these machines is how far you can 
get with just a set of extenders, a KM11, the front panel, and a 'scope.

  --FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Fritz Mueller

> This seems the best place to start with the LA this weekend then.

I'm going to respectfully semi-disagree! I think that at this point there's a
good chance we can localize to within a gate or two before we start applying
test instuments.

My thinking starts with two pieces of data; i) your discovery that when the
MM trap happens, the end of the pure text segment contains a fragment of code
from 04000 lower in the text, and ii) the data that the location in main
memory where that _should_ have been is full of zeros - i.e. never been
written into.

The latter is, I think, due to the fact that Unix clears all of main memory
on startup; I think it's just chance that that memory hasn't been used yet
for something else, and is still 0's. (Unix does clear main memory in a few
places during regular operation - e.g. when expanding the stack, the newly
added area is 0'd - but in general, e.g. when swapping in a pure text, it
doesn't seem to bother, which makes sense since it's all about to be
over-written anyway.)

Anyway, those two, together with my previous analysis that this was unlikely
to have happened when the text was first being read in from the file, block
by block, lead me to believe that the likely cause is that the BAR on the
RK11 skipped up a whole bunch (setting the 04000 bit at some point) when it
was reading the pure text back in from the swap, and skipped writing into
that zero-filled block of main memory, putting the stuff that should have
gone there up 04000, instead.

(Why it's swapping the text back in is too complicated to be worth explaining
here; anyone who _really_ wants to know should look here:

  http://gunkies.org/wiki/Unix_V6_internals

in the last section, "exec() and pure-text images".)

It's easy to confirm all these suppositions/deductions fairly easily, without
having to connect up, configure, etc the LA: we can just stop the machine
after the text is first read in (in xalloc()) from the file-system, and
confirm that the text looks good there; if so, either the swap-out (albeit
unlikely, since that doesn't account for the 0's) or subsequent swap-in had
an issue. The latter would be easy to confirm: just halt the machine after
the text is swapped in, and see what the RK registers contain.

At that point, as I said, we'll know to within a few gates where the issue
is, and then it'll be time to bring out the LA.

Actually, a plain oscilloscope would do; it's interesting to recollect that
these machines were designed and maintained without benefit of a LA, purely
with an oscilloscope! We're so spoiled now! :-)

Noel

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

>>> How about a Unibus trace? 
>> 
>> I don't think my sad little HP LA has enough buffer for that...
> 
> You could use triggers in innovative ways.

Ah, quite right, gentlemen.  This seems the best place to start with the LA 
this weekend then.

  --FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/7/2019 11:47 AM, Noel Chiappa via cctalk wrote:
> 
> The interesting point is that when V6 first copies the text in from the file
> holding the command (using readi(), Lions 6221 for anyone who's masochistic
> enough to try and actually follow this :-), it reads it in starting from the
> bottom, one disk block at a time (since in V6, files are not stored
> contiguously).
> 

I remember when Lions first showed up.  I have a copy of a copy made
back in the day.

JRJ

Re: PDP-11/45 RSTS/E boot problem

[Mattis Lind via cctalk]

torsdag 7 februari 2019 skrev Fritz Mueller via cctalk <
cctalk@classiccmp.org>:

>
> > How about a Unibus trace?  That would give you the RK11 commands as well
> as the data it sends in response.
>
> I don't think my sad little HP LA has enough buffer for that...


You could use triggers in innovative ways. Maybe trigger on that particular
data on that particular address. What takes place just before this? Is it
DMA or is it the CPU moving the data. Is it just reading out bad or is it
written bad?  That should be possible to figure out. You will probably get
quite far with only 16 data and 16 address bits (if you have the smallest
analyzer). Of course more is better...

/Mattis


>
>--FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

> How about a Unibus trace?  That would give you the RK11 commands as well as 
> the data it sends in response.

I don't think my sad little HP LA has enough buffer for that...

   --FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Paul Koning via cctalk]

> On Feb 7, 2019, at 1:37 PM, Fritz Mueller via cctalk  
> wrote:
> 
> 
>> On Feb 7, 2019, at 9:47 AM, Noel Chiappa via cctalk  
>> wrote:
>> 
>> So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
>> I think. And it wound up at PA:171600 - off by 04000 (higher) - which is
>> obviously an interesting number.
> 
> Thanks, Noel.
> 
>> ...it might be interesting to look at PA:165600 and see what's actually 
>> _there_
> 
> A sea of zeros, as it turns out.
> 
> I'm thinking it might be worth obtaining a full memory dump of the text 
> segment at the point of fault (I can do this with a small toggle-in program 
> to dump it over the serial console), , and then compare that to the complete 
> text section in the ls binary. That would give us more of a clue about 
> whether blocks of memory are duplicated or swapped, what the size, alignment, 
> and stride of the corrupted blocks is, how many there are, etc.
> 
> I'll get an IR trace out this weekend.  Another thing I _could_ do with the 
> LA is an IO command trace on the RK11 (though that's a lot of probes to hook 
> up to get disk address, count, and memory address).

How about a Unibus trace?  That would give you the RK11 commands as well as the 
data it sends in response.

paul

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

> On Feb 7, 2019, at 9:47 AM, Noel Chiappa via cctalk  
> wrote:
> 
> So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
> I think. And it wound up at PA:171600 - off by 04000 (higher) - which is
> obviously an interesting number.

Thanks, Noel.

> ...it might be interesting to look at PA:165600 and see what's actually 
> _there_

A sea of zeros, as it turns out.

I'm thinking it might be worth obtaining a full memory dump of the text segment 
at the point of fault (I can do this with a small toggle-in program to dump it 
over the serial console), , and then compare that to the complete text section 
in the ls binary. That would give us more of a clue about whether blocks of 
memory are duplicated or swapped, what the size, alignment, and stride of the 
corrupted blocks is, how many there are, etc.

I'll get an IR trace out this weekend.  Another thing I _could_ do with the LA 
is an IO command trace on the RK11 (though that's a lot of probes to hook up to 
get disk address, count, and memory address).

  --FritzM.

PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Fritz Mueller

> is it possible for you deduce where Unix _should_ be placing these "bad"
> bits (from file offset octal 4220)?

Yes, it's quite simple: just add the virtual address in the code to the
physical address of the bottom of the text segment (given in UISA0). The VA
is actually 04200, though: the 04220 includes 020 to hold the a.out
header at the start of the command file.

So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
I think. And it wound up at PA:171600 - off by 04000 (higher) - which is
obviously an interesting number.


> Maybe a comparison of addresses where the bits should be, with
> addresses where the "bad" copy ends up, could point us at some particular
> failure modes to check in the KT11, CPU, or RK11...

Here's where it gets 'interesting'.

Executing a command with pure text on V6 is a very complicated process. The
shells fork()s a copy of itself, and does an exec() system call to overlay
the entire memory in the new process with a copy of the command (which sounds
fairly simple, at a high level) - but the code path to do the exec() with a
pure text is incredibly hairy, in detail. In particular, for a variety of
reasons, the memory of the process can get swapped in and out several times
during that. I apparently used to understand how this all worked, see this
message:

  https://minnie.tuhs.org/pipermail/tuhs/2018-February/014299.html

but it's so complicated it's going to take a while to really comprehend
it again. (The little grey cells are aging too, sigh...)

The interesting point is that when V6 first copies the text in from the file
holding the command (using readi(), Lions 6221 for anyone who's masochistic
enough to try and actually follow this :-), it reads it in starting from the
bottom, one disk block at a time (since in V6, files are not stored
contiguously).

So, if it starts from the bottom, and copies the wrong thing from low in the
file _up_ to VA:010200, when it later gets to VA:010200 in the file contents,
that _should_ over-write the stuff that got put there in the wrong place
_earlier_. Unless there's _another_ problem which causes that later write
to _also_ go somewhere wrong...

So, I'm not sure when this trashage is happening, but because of the above,
my _guess_ is that it's in one of the two swap operations on the text (out,
and then back in). (Although it might be interesting to look at PA:165600 and
see what's actually _there_.) Unix does swapping of pure texts in a single,
multi-block transfer (although not always as an integral number of blocks, as
we found out the hard way with the QSIC :-).


So my suspicions have now switched back to the RK11... One way to proceed
would be to stop the system after the pure text is first read in (say around
Lions 4465), and look to see what the text looks like in main memory at
_that_ point. (This will require looking at KT11 registers to see where it's
holding the text segment, first.)

If that all looks good, we'll have to figure out how to stop the system
after the pure text is read back in (which does not happen in exec(),
it's done by the normal system operation to swap in the text and data
of a process which is ready to run).

We could also stop the system after the text is swapped out, and key in
a short (~ a dozen words) program to read the text back in from the
swap device, and examine it - although we'd have to grub around in the
system a bit to figure out where it got written to. (It might be just
easier to stop it at, say, Lions 5196 and look at the arguments on the
kernel stack.)


> a suggestion here to check the KT11 address translation adders ... A
> bug in one of the carry lookahead generators used between the bit
> slices of that adder could cause a mistranslation on only a fairly
> selective subset of virtual addresses

This could be happening, but from the reasoning above about the order that
the blocks of the text are read in, something would have to interfere with
the later read of the higher memory blocks, too, no? So I'd discount the KT11
_for the moment_.

> *IF* that's the case and we can chase the IR trace upstream to the
> place of an unlucky mistranslation, it will be pretty easy to track
> down then in the hw and fix.

It'll be interesting to look at the text after it's read in (i.e. before it's
swapped out). If it's OK there, that's pretty conclusive that it _can't_ be
the KT11 - because from then on, the kernel doesn't _do anything_ to that
binary, except swap it out and in with the RK11. And since those are both
single I/O operations (with swapping on the RK11, at least, which can do
multi-block transfers), _and_ the bottom of the text segment comes in OK (so
the RK11 is being set up with correct disk and main memory addresses for both
the out and in), I can't think of a fault _elsewhere_ in the system that
could cause that 'stuff winds up in the wrong place' error.


I know this is complicated, 

Re: PDP-11/45 RSTS/E boot problem

[Jon Elson via cctalk]

On 02/06/2019 09:11 PM, Noel Chiappa via cctalk wrote:

 > From: Jon Elson

 > I'm thinking it is bad memory. ... I think it is just a bad memory chip

Nothing so simple, I'm afraid! The memory actually contains:

   PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144

and it's _supposed_ to be holding:

   PA:171600: 110024 010400 000167 16 010500 010605 010446 010346

This together with Fritz's discovery of that first 'bad memory' pattern 
_elsewhere_
in the binary for the command makes it look pretty likely that some sort of 
other
error has wound up with stuff being put in the wrong location.

OK, now it is starting to look like an address problem.  
That could actually be several things.
Possibly something going wrong in DMA, and the disk data is 
being written into the wrong place in memory.  If the two 
places the same data show up are related by some simple 
binary transposition, maybe under some cases a write to 
memory gets written simultaneously into two banks of the 
memory.  A memory interference test OUGHT to pick up 
something like that.  It could also be a bus problem, or 
something going haywire in the MMU.


And, one other possibility is that the duplicate data is a 
disk buffer or cache that was then copied to the location to 
be executed.


Jon

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

> Seems a little less-likely to be the problem, given(?) as well that you have 
> fairly consistent (is deterministic overstating it?) behaviour.

Yeah.  We've gotten to the point now where enough layered problems have been 
cleared away that the remaining behavior is quite deterministic.

> If you wanted to test it by experiment, without having to remove the 
> installed Rs, you could test-clip another R in parallel with the 38.4K, 
> probably something around 200K, to shorten the 555 period.

Yes; and I think a quick solder tack for that would even be easier to manage 
than clips in there.  Will give that a go this weekend.

  cheers,
--FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Brent Hilpert via cctalk]

On 2019-Feb-06, at 10:37 PM, Fritz Mueller via cctalk wrote:

>> 4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 
>> 14.5uS from the manual would give 1.86 mS, 7% shy of 2.
>> The schematic specs 1% resistors, and the parts list does appear to spec a 
>> high-tolerance "1%200PPM" cap.
>> 
>> Although there are the internal voltage divider Rs in the 555 which are also 
>> critical for the timing and everything is 40+ years old.
>> 
>> Idle speculation at my distance, we'll see what Fritz observes.
> 
> Brent:  11.8us, 6.4us position 
> Manual: 14.5us, 6.0us positive
> Actual: 15.2us, 8.5us positive
> 
> So yeah, a little pokey there...


15.2uS gives a 1.95mS refresh, so it's awfully close to the 2mS spec, but still 
within.
The datasheet I was looking at doesn't seem to give any spec for tolerance on 
the refresh so one would guess there's a safety margin built into the 2mS spec.

Seems a little less-likely to be the problem, given(?) as well that you have 
fairly consistent (is deterministic overstating it?) behaviour.

If you wanted to test it by experiment, without having to remove the installed 
Rs, you could test-clip another R in parallel with the 38.4K,
probably something around 200K, to shorten the 555 period.

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

> 4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 14.5uS 
> from the manual would give 1.86 mS, 7% shy of 2.
> The schematic specs 1% resistors, and the parts list does appear to spec a 
> high-tolerance "1%200PPM" cap.
> 
> Although there are the internal voltage divider Rs in the 555 which are also 
> critical for the timing and everything is 40+ years old.
> 
> Idle speculation at my distance, we'll see what Fritz observes.

Brent:  11.8us, 6.4us position 
Manual: 14.5us, 6.0us positive
Actual: 15.2us, 8.5us positive

So yeah, a little pokey there...

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

It looks like the question boils down to either "how did that part of
the binary get to that part of memory?", or "how did we end up
executing out of that part of memory?"


More the former, I think...


Noel, is it possible for you deduce where Unix _should_ be placing these 
 "bad" bits (from file offset octal 4220)?


Maybe a comparison of addresses where the bits should be, with addresses 
where the "bad" copy ends up, could point us at some particular failure 
modes to check in the KT11, CPU, or RK11...


--FritzM.

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Fritz Mueller

> It looks like the question boils down to either "how did that part of
> the binary get to that part of memory?", or "how did we end up
> executing out of that part of memory?"

More the former, I think.

UISA0 contains 001614, and physical memory at 0161400 does contain the first
few instructions of the command's binary, so that 01614 is probably correct
for the base address of segment (page) 0, which contains all the code for the
command. (Without looking through the OS's guts, I can't confirm, from interal
data structures, that that's where it decided to put the command's binary.)

The PC at fault time is 010210, which is correct for the frame setup
function, CSV; and looking at the contents of the stack, registers etc makes
it pretty certain it had just done the "JSR R5, CSV" to get there. And
0161400 + 010210 = 0171610, which contains something completely different
from what's in the command binary at 010210!

> Could still be a memory issue _elsewhere_ that lands us there, of
> course... Could also be a translation error lurking in the KT11, or a
> CPU bug not found by any of the DEC diagnostic suites.

Yup. Like I said, good news is we're down to one problem; bad news is it's
a Duesie!

Noel

Re: PDP-11/45 RSTS/E boot problem

[Noel Chiappa via cctalk]

> From: Jon Elson

> I'm thinking it is bad memory. ... I think it is just a bad memory chip

Nothing so simple, I'm afraid! The memory actually contains:

  PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144

and it's _supposed_ to be holding:

  PA:171600: 110024 010400 000167 16 010500 010605 010446 010346

This together with Fritz's discovery of that first 'bad memory' pattern 
_elsewhere_
in the binary for the command makes it look pretty likely that some sort of 
other
error has wound up with stuff being put in the wrong location.

  Noel

Re: PDP-11/45 RSTS/E boot problem

[Fritz Mueller via cctalk]

On 2/6/19 6:25 PM, Jon Elson via cctalk wrote:
I'm thinking it is bad memory.  It seems unlikely bus problems could 
alter only ONE BIT per word, so I think it is just a bad memory chip, 
and finding multiple words where the 01 bit is now turned on sure 
looks like that kind of problem.


So, there was an issue specifically relating to bit 12 on the front 
panel (d'oh!), which I have now cleared up.


Furthermore, the "authoritative" sequence of 16 words obtained from the 
front panel last night, after addressing this issue, is:


PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
PA:171620: 004767 000206 000405 012404 012467 016124 000167 177346

...and, as it turns out, this exact sequence also occurs within the ls 
binary, on disk (per "od"):


0004220 016162 004767 000224 000414 016700 016152 016702 016144
0004240 004767 000206 000405 012404 012467 016124 000167 177346

So, the memory there _seems_ fine with the latest info at our disposal. 
It looks like the question boils down to either "how did that part of 
the binary get to that part of memory?", or "how did we end up executing 
out of that part of memory?"


Could still be a memory issue _elsewhere_ that lands us there, of 
course...  Could also be a translation error lurking in the KT11, or a 
CPU bug not found by any of the DEC diagnostic suites.


I will scope the refresh clock when I get home tonight, and I'm planning 
on hauling out the logic analyzer for an IR trace this weekend...


   --FritzM.


P.S. One idea that popped into my head recently, after a suggestion here 
to check the KT11 address translation adders, and my response "but the 
diagnostics!"...  A bug in one of the carry lookahead generators used 
between the bit slices of that adder could cause a mistranslation on 
only a fairly selective subset of virtual addresses, and this might 
conceivably be missed by the KT11 diagnostics?  *IF* that's the case and 
we can chase the IR trace upstream to the place of an unlucky 
mistranslation, it will be pretty easy to track down then in the hw and fix.

Re: PDP-11/45 RSTS/E boot problem

[Jon Elson via cctalk]

On 02/06/2019 05:39 PM, Fritz Mueller via cctalk wrote:

On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk  
wrote:

Is the schematic available for the memory board at-issue?
Curious myself to see what approach for refresh DEC used.

Yes, here: 
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf

There is also a technical manual adjacent, with circuit descriptions.

I will scope this up tonight and take a look!

Yup, page 6, a 555 RC refresh timer!

Jon

Re: PDP-11/45 RSTS/E boot problem

[Jon Elson via cctalk]

On 02/06/2019 04:24 PM, Brent Hilpert via cctalk wrote:

On 2019-Feb-06, at 1:21 PM, Noel Chiappa via cctalk wrote:

From: Brent Hilpert
what about the refresh circuitry of the memory board?
...
It might also explain why a number of 4116s were (apparently) failing
earlier in the efforts ... replacing them might have just replaced them
with 'slightly better' chips, i.e. with a slightly longer refresh tolerance.

Ooh, excellent idea!


Is the schematic available for the memory board at-issue?
Curious myself to see what approach for refresh DEC used.


Hmm, yes, if the refresh is done by one-shots and RC timing, 
a failed cap could silently kill the refresh trigger.  An 
easy way to check is put something in a few locations and 
halt the CPU for some time (seconds to minutes).  If the 
content is now gone, then the refresh is very likely not 
being done.


Jon

Re: PDP-11/45 RSTS/E boot problem

[Jon Elson via cctalk]

On 02/06/2019 12:53 PM, Noel Chiappa via cctalk wrote:
  


If so, i) we're down to one problem (good news), and our problem turns into
finding out how that section of the code got trashed (bad news).
I'm thinking it is bad memory.  It seems unlikely bus 
problems could alter only ONE BIT per word, so I think it is 
just a bad memory chip, and finding multiple words where the 
01 bit is now turned on sure looks like that kind of 
problem.  It could, of course, be a bad driver or receiver 
on the memory board.  Might also check the other voltage in 
the memory array (+12 or whatever was used internally in the 
particular memory) and also look for degraded caps on the board.


Jon

Re: PDP-11/45 RSTS/E boot problem

[Brent Hilpert via cctalk]

On 2019-Feb-06, at 5:29 PM, Paul Koning wrote:
>> On Feb 6, 2019, at 8:25 PM, Brent Hilpert via cctalk  
>> wrote:
>> On 2019-Feb-06, at 5:11 PM, Fritz Mueller via cctalk wrote:
> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk 
>  wrote:
> 
> Is the schematic available for the memory board at-issue?
> Curious myself to see what approach for refresh DEC used.
 
 Yes, here: 
 http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf
>>> 
>>> For completeness, from the technical manual:
>>> 
>>> "The refresh logic, shown in sheet 6 of the print set, generates REF CLK H 
>>> and the refresh address. Sig- nal REF CLK H is derived from a 555 timer 
>>> (E5) which is set up as a free running oscillator, powered by the + IS V / 
>>> + 12 V module input (V-555). The REF CLK H signal oscillates with a period 
>>> of 14.5us and has a positive pulse width of 6us during each period."
>> 
>> So I could have saved myself some fun if I had read the manual rather than 
>> just looking at the schematic.
>> Not that they're way out of whack, but the mild disparity between the 
>> manual's 14.5uS and my calculated 11.7uS is curious
>> (the calculation being based on the schematic RC values and the 555 
>> equations).
> 
> Perhaps the period was changed in a schematic rev or ECO, and the manual 
> wasn't updated to reflect it.  It would be interesting to check the data 
> sheet for the RAM chip to see what it likes for refresh cycle.  And given 
> that this is an RC oscillator your theory about out of tolerance timing 
> definitely deserves checking.


Checking further..

4116 datasheet specs 2mS, my calcs give a refresh period of 1.5mS, the 14.5uS 
from the manual would give 1.86 mS, 7% shy of 2.
The schematic specs 1% resistors, and the parts list does appear to spec a 
high-tolerance "1%200PPM" cap.

Although there are the internal voltage divider Rs in the 555 which are also 
critical for the timing and everything is 40+ years old.

Idle speculation at my distance, we'll see what Fritz observes.
Could be other problems in the refresh circuitry too, like failed outputs from 
the row counter, etc.

Re: PDP-11/45 RSTS/E boot problem

[Brent Hilpert via cctalk]

On 2019-Feb-06, at 3:39 PM, Fritz Mueller wrote:
>> On Feb 6, 2019, at 2:24 PM, Brent Hilpert via cctalk  
>> wrote:
>> 
>> Is the schematic available for the memory board at-issue?
>> Curious myself to see what approach for refresh DEC used.
> 
> Yes, here: 
> http://bitsavers.trailing-edge.com/pdf/dec/pdp11/memory/MP00672_MS11L_engDrw.pdf
> 
> There is also a technical manual adjacent, with circuit descriptions.
> 
> I will scope this up tonight and take a look!

Mixed up To: fields.
The following was intended to go to the list and was originally sent a moment 
before I saw Fritz's message mentioning the 555:


Ha!, simple free-running 555 oscillator generating the refresh cycles 
(pdf.pg27).

I suspect there is a mistake in the schematic there:
V-555 more likely connects on the other side of R4 (E5.4-C1-R4, rather 
than E5.7-R4-R5)
to make it into the standard 555 astable circuit.

Based on that, calculations indicate that the output from E5 (TP18) should be 
around 85 KHz, cycling 6.4 uS high, 5.3 uS low.
So it's generating a refresh cycle every 11.8 uS. With 7 bits used from counter 
E43 (128 rows) for full refresh, that's a cell refresh
every 1.5mS which (without having checked the 4116 specs) sounds sensible for a 
DRAM from that period.

Note the 555 (E5) is running on +12 or +15V, with a R voltage divider on the 
output before driving into TTL.