PDP-11 disk image question
charles.unix.pro at gmail.com
Tue Feb 19 21:26:56 CST 2019
On Tue, Feb 19, 2019 at 10:14 AM Paul Koning <paulkoning at comcast.net> wrote:
> > On Feb 19, 2019, at 11:51 AM, Charles Anthony <
> charles.unix.pro at gmail.com> wrote:
> > ...
> > Presumably SIMH is returning RA81_LBN (891072) as the device size; this
> is calculated based on the 51 sectors/track. If the h/w is returning a size
> based on 52, then there is a mismatch which could be the source of the
> problem. It has been hypothesised that the original problem is related to
> SIMH misreporting the disk size; I was trying to point out a possible
> source of error; does anyone know what size the h/w reports?
> > -- Charles
> Some people here probably have an actual drive and can double check.
> Meanwhile, I found the "RA60, RA80, and RA81 disk drives" brochure (DEC,
> August 1982) on Archive.org. It has the details in the back. Page 36
> shows "User data capacity" and says 51 sectors, 14 tracks, 1248 cylinders
> -- that works out to 891072 sectors which is the number SIMH uses.
> So indeed the correct sector count is 51 (the other one is a spare, a
> technique used by DEC as far back as the RM80).
I am concerned that the spare is the issue. If the track has 52 sectors,
and one is reserved as a spare, is that spare included in the LBA
calculation? If it is, then SIMH is wrong; the first sector of the second
track written in the spare sector, throwing all of the remaining data out
of alignment, with the symptom of RSTS booting but not being able to find
If the spare sector exists and SIMH is not allocation space for it, then
the disk image will not copy correctly with 'dd'. (However, dd might be
coereced into doing the right thing with 'dd if=... of=... ibs=26112
obs=26624'; reading 512*51 byte records (a SIMH track) and writing 512*52
byte records (a RA81 h/w track)).
More information about the cctech