19 Feb
2019
19 Feb
'19
7:26 p.m.
On Tue, Feb 19, 2019 at 10:14 AM Paul Koning <paulkoning at comcast.net> wrote:
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
INIT.SYS.
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)).
-- Charles
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).