[HECnet] RSTS/E under simh

[Paul_Koning at Dell.com]

On May 15, 2014, at 5:44 PM, Dave McGuire <mcguire at neurotica.com> wrote:

On 05/15/2014 05:28 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   .)

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 thought RSTS would accept a disk so long as the DCS is right but with wrong SATT if mounted read-only.   That turns out to be incorrect, it insists on a good SATT even if it has no need for one (as in the read-only case).   I suspect that   s a leftover from the days before read-only mode was introduced.

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

	paul