On Tue, Feb 19, 2019 at 6:27 AM Paul Koning <paulkon...@comcast.net> wrote:
> > > > On Feb 18, 2019, at 11:22 PM, Charles Anthony via cctalk < > cctalk@classiccmp.org> wrote: > > > >> ... > > Looking at the SIMH code: > > > > /* > > type sec surf cyl tpg gpc RCT LBNs > > RA81 51(+1) 14 1258 14 1 2856 891072 > > */ > > > > #define RA81_SECT 51 /* +1 > spare/track */ > > #define RA81_SURF 14 > > #define RA81_CYL 1258 /* 0-1247 user */ > > #define RA81_TPG RA81_SURF > > #define RA81_GPC 1 > > #define RA81_XBN 2436 /* cyl > 1252-1254? */ > > #define RA81_DBN 2436 /* cyl > 1255-1256? */ > > #define RA81_LBN 891072 /* 51*14*1248 */ > > #define RA81_RCTS 2856 /* cyl > 1248-1251? */ > > #define RA81_RCTC 1 > > #define RA81_RBN 17472 /* 1 *14*1248 */ > > > > I am presuming that (without actually checking) that these are the > numbers > > returned to RSTS when it queries the disk; if these numbers are different > > then the h/w, then that could be an issue. I am a bit curious about "+1 > > spare/track" - I wonder if the h/w reports 51 or 52? > > > > -- Charles > > RSTS doesn't care about geometry, though MSCP does return something it > calls geometry, for optimization purposes. All RSTS wants to know is the > device size, in 512-byte blocks. Whatever the controller returns is what > it uses. > > 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