On Apr 10, 2026, at 3:39 PM, Terri Kennedy
<terri-hecnet(a)glaver.org> wrote:
On 2026-04-10 09:46, Paul Koning wrote:
Same in RSTS. If FPP exists the kernel will
context switch the FP
state, if the currently executing program has set the flag to ask the
kernel to do that. Apart from that, nothing uses it and the kernel
itself doesn't care about the FPP.
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.
Did the change from CSPCOM to actual BP2 for CUSPs
drag in some
FP stuff? That shouldn't have affected the monitor, though. I'll
need to go look in the FIP source code...
Probably not because those CUSPs had to run on no-float machines.
* For other folks, RSTS/E goes out of its way to keep
most file-
system stuff in 16-bit ints or smaller. This does result in very
large pack cluster sizes on "big" (for the time) disks like the
RP07, to keep the total number of clusters below 65536**. Of
course, when you talk about absolute disk blocks they exceed 16
bits pretty quickly.
** 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.
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.
CIS is used
for memory copy, which happens in the file system cache
code so a malfunctioning MOVC3 will potentially mess up the file
system.
I wonder if that was added in anticipation of the PDP-11/74
(the CIS one, not the renamed 11/70MP).
Probably. I remember that machine sitting just across the lab from ARK, the main RSTS
development machine, and I believe the COBOL-11 team was just down the hall from the RSTS
cubicles.
paul