On Tue, Feb 19, 2019 at 10:14 AM Paul Koning <paulkon...@comcast.net> wrote:
> > > > On Feb 19, 2019, at 11:51 AM, Charles Anthony < > charles.unix....@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 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