11 Apr
2026
11 Apr
'26
10:16 p.m.
On Apr 10, 2026, at 11:22 PM, Terri Kennedy
<terri-hecnet(a)glaver.org> wrote:
On 2026-04-10 16:36, Paul Koning wrote:
Yup. In fact, Fred Knight was down here at the time on other
RSTS/E business with me and saw it too.
Very curious. The only explanation I can think of is a hardware defect that breaks the
integrity of the integer data path.
On Apr
10, 2026, at 3:39 PM, Terri Kennedy <terri-hecnet(a)glaver.org> wrote:
I definitely had disk block addressing go wonky* in a late V9.x
release. Diagnostics detected a bad FPP and after I replaced it,
RSTS/E (the OS and utilities part, not just user apps) was happy
again.
You mean file system troubles with a bad FPP that went away when the
FPP was fixed? That's very curious, because I know for certain that
there are no FPP instructions anywhere except context switching. ...
True for the most part. Better to say "the _minimum_ cluster
size", as you can initialize an RL02 with cluster size 64 if
you want.
DCS is fixed for a given device type. You're thinking of PCS, the Pack Cluster Size,
which is chosen at file system initialization. The rule is that DCS <= PCS <= 64.
Finally, there is the file cluster size, chosen when the file is created. It defaults to
PCS and is subject to PCS <= FCS <= 128. Directory cluster size is also selectable
as PCS <= DirCS <= 64, except that the MFS (on RDS 1) and GFDs have a minimum
cluster size of 4 because of how the lookup tables are stored.
** If I
were ever going to do a RDS 2, these fields would all be
made larger so that tiny files don't take up a whole 64 blocks.
RSTS addresses
file system elements by 16 bit "device cluster"
numbers. The device cluster size for a given disk is the smallest
power of two such that the number of device clusters fits in 16 bits. The largest
DCS is 64 for reasons having to do with how this stuff is
encoded in various places (it could allow 128 if someone really wanted
it) so the max device size is 2^22 blocks. That means an RA73 just
barely fits within the limit, and anything larger would not work.
Let's not do the stuff like RT-11 did with putting extension
bits in unrelated parts of a data structure because that's where
the unused space was. Although RT-11 finally did give up and
added .DATE4 rather than trying to shoehorn post-Y2K dates into
the existing .DATE.
The trick with a hypothetical RDS 2 is it still has to look
enough like classic RDS 1.x to not break things with assumptions
about cluster size (or even the cluster concept entirely). User
applications "shouldn't" notice (but might require re-linking,
which would imply dealing with things like the Fortran-11 OTS)
but a bunch of stuff in the RSTS/E kit would need to be re-done. The disk
drivers actually take 24 bit block numbers, and file I/O also
uses 24 block numbers just in case you have a crazy large file. RSTS
got "large file" support, meaning more than 64k blocks, quite early
on, I'm not quite sure when. Not in V4 I think, even though it
supported the RP03, but probably soon after.
There's a bunch of mappings which will go from 512-byte LBN
to the appropriate C/H/S for a "classic" drive, or just pass
the LBN in the case of MSCP. I don't know why RSTS/E would use
the FPP if present to do 24-bit math - it isn't _that_ hard to
do math when treating two 16-bit words as a 32-bit value, as
long as you have enough free general registers or are willing
to PUSH/POP to get them. It is certainly possible that the FPP problem also
triggered
issues with non-FP instructions, even though the basic diagnos-
tics for the 11/70 all passed. As they say, "Never test for a
condition you don't know how to handle" (or never expected).
Yes, that would be my guess.
Also, "passes diagnostics" or "fails
diagnostics" is no in-
dication if an operating system will fail (or work) - SIMH
(at least the version used for the PiDP-11) fails just about
every 11/70 diagnostic, but still runs operating systems just
fine.
:-)
Conversely, it was well known that RSTS was a better tool for stress-testing a PDP-11 than
the diagnostics. That's why it was used, configuration permitting, for final test of
about to be shipped customer systems.
...
Did they have the automated "lights off" when you were there?
I remember many an evening phone call with RSTS folks which
would be interrupted by "bleep-it, I have to go turn the lights
back on".
No, I left in 1994 and it wasn't done yet, at least not in Littleton MA. I do
remember that chicanery at ZKO circa 2005 (when EqualLogic moved into that space, by then
repurposed into individual sections for multiple companies).
paul