20 Feb
2019
20 Feb
'19
10:43 a.m.
On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk <cctalk at classiccmp.org>
wrote:
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.
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.
As I lack experience with or access to the specific hardware, I am
speculating about the exact failure mode. I do however believe that it is
highly likely that disk geometry is the root of the problem. Having no no
further specific ideas about the failure mode, I will shut up now.
-- Charles
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.