[HECnet] RSTS/E under simh

[Dave McGuire]

On 05/16/2014 05:27 PM, Paul_Koning at Dell.com wrote:
First I need to find the exact size of the drive so I can set
an RAUSER to it.   I can then install RSTS/E *IF* I can get SIMH
to boot and install from the RSTS/E V10.1 tape (which I can't
get it to do).

You mean you have a real drive, and you want to copy it to a
disk image file and configure that as an RA file of
user-specified size? That will work fine.   RSTS can handle disks
of any size up to a limit (the RP07 is somewhat below that limit,
I   d have to dig a bit to find the actual number).   If you can
just dd the disk to a file, that file should serve.

Alternatively, you can always use a larger disk so long as you
don   t cross a power of two.   RSTS addresses disks by    disk
clusters    which are 16 bit numbers, and the file system layout
starts from a given disk cluster size.   So if you have a pack
with 70k sectors, you can drop it into another pack of 90k
sectors     but not in one of 130k sectors because that one has a
DCS double that of the original.

Are you certain that this is the only limitation?   I've had the 
crash-on-boot problems when they were off by quite a bit less than
a power of two.   Since I found that problem the hard way, I always
make images (via simh "rauser=<n>") using the exact size of the
target physical disk.

Certainly matching the size is good.   But I   m pretty sure that what I
described is accurate.

I just did an experiment, with a couple of different disk images.   I
don   t see startup crashes and there should not be any.   (Well, not
unless you mean a failure to start due to a    fatal error   .)

  That's exactly what I mean. ;)   Perhaps not the best terminology.

RSTS accepts a disk with mismatched container size so long as the
disk clustersize is unchanged and the SATT.SYS file is the correct
length.   Actually, the latter condition is sufficient (it implies the
first).   SATT.SYS size is container size divided by pack cluster size
(a parameter set when the pack was initialized), rounded up to an
integer.

  I guess it was borderline when I tripped over it, then.   That seems
odd because it wasn't just a "once in awhile" thing, it was EVERY time.
But I can certainly see it being bad luck.   Now, though, I just find
out the target disk size and make my images exactly the same size, which
I'd do anyway because I'm anal about stuff like that. ;)

If you want to manipulate, or check, RSTS disk images, a useful
utility is    rstsflx    which you can find at
svn://akdesign.dyndns.org/flx/trunk

  That sounds really handy; I will check it out, thanks!

                        -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA