20 Feb
2019
20 Feb
'19
11:09 a.m.
On Feb 20, 2019, at 1:43 PM, Charles Anthony via
cctalk <cctalk at classiccmp.org> wrote:
On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk <cctalk at classiccmp.org>
wrote:
Your confusion stems from the fact you think of "spare sector" as something that
is visible. It is not. Programs can only deal with program-visible properties of
devices. For MSCP disks, which is what we have here, the only program visible addressing
is LBA addressing. There IS no geometry from the program point of view.
"spare sectors" are an internal detail in the MSCP controller that allows it to
deliver an error-free device. It has no relevance to programmers and it probably
shouldn't have been mentioned in the documentation in the first place.
On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony
via cctalk
<cctalk at classiccmp.org> wrote:
Re-reading the original post, it it not clear to me how the disk write was
accomplished; I am not familiar with the mentioned hardware. If the data
was written to the RA81 with a controller that correctly did the spare
sector mapping, then my spare sector hypothesis is wrong.
However, in the original posters case, the SIMH disk image is being
copied
to the RA81 drive without the benefit of the MSCP
controller (if I
understand correctly). This would lead to track misalignment and could
result in the observed behavior.
How could you possibly write to a real RA81 drive without going
through a real KDA50 or UDA50 MSCP controller? Nothing like that is
happening in the original post. Just the disk size was chosen to be
that of an RA81, and the issue is to exactly match the emulated disk
size to that configured by the hardware, which is an MSCP SCSI
controller and drive in this case.
The reported symptoms sound like a disk geometry
issue; the data passes
through several systems on the way to RSTS, and it seems likely to me that
one of the steps is damaging the data.
No, that's not what the symptoms say. If you were dealing with geometry confusion,
you'd fail much earlier. For example, if you were to take a RSTS system built on an
RP06, and image-copied it to an RM05, it would fit fine (the RM05 is much bigger). And
since the "device cluster size" is 9 for both, the file system would even be
basically valid (apart probably from a too-small storage bitmap, but that wouldn't
prevent reading data).
However, the RM05 wouldn't boot at all, because the boot loader has been told it's
on an RP06 and it would use the RP06 numbers for converting LBA to cylinder, track, sector
values. Since the sectors/track differs (22 vs. 32) all the boot loader reads would go to
the wrong place. It would be loading utter nonsense into memory.
In the original problem, the boot loader worked fine. It loaded all of INIT successfully
(because INIT got far enough to discover the disks and attempt to find INIT.SYS, and it
did so without crashing). You wouldn't get anywhere close to that point if you had a
geometry issue.
paul