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.
This is why in SIMH you can use "RAUSER" devices with MSCP, any size you like up
to 8 megablocks. RSTS doesn't limit you to the sizes of the DEC MSCP products, and in
fact you won't find any list of those model codes or any of their attributes in the
RSTS sources.
paul