19 Feb
2019
19 Feb
'19
8:51 a.m.
On Tue, Feb 19, 2019 at 6:27 AM Paul Koning <paulkoning at comcast.net> wrote:
spare/track */
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
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 #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.