PDP-11 disk image question
Charles Anthony
charles.unix.pro at gmail.com
Tue Feb 19 10:51:28 CST 2019
On Tue, Feb 19, 2019 at 6:27 AM Paul Koning <paulkoning at comcast.net> wrote:
>
>
> > On Feb 18, 2019, at 11:22 PM, Charles Anthony via cctalk <
> cctalk at 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
More information about the cctalk
mailing list