20 Feb
2019
20 Feb
'19
10:10 a.m.
On Feb 20, 2019, at 11:57 AM, Charles Anthony
<charles.unix.pro at gmail.com> wrote:
On Wed, Feb 20, 2019 at 5:38 AM Paul Koning <paulkoning at comcast.net> wrote:
You're misinterpreting "spare". MSCP exposes the user address space as
contiguous LBAs, for which it uses 51 sectors per track. The spare sector is used to do
bad sector replacement. That is invisible to users, it doesn't affect the LBA
addressing. dd, like any other host-resident code, sees the user address space. It will
copy MSCP devices correctly.
Yes; I agree that the MSCP conceals the spare sector when RSTS accesses the disk through
MSCP in the case of the *hardware*.
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.
No. The original case isn't an actual RA81 at all, it's a non-DEC device that
emulates an RA81. Emulation means acting like an RA81 from the program point of view,
which means as seen via MSCP. There is no such thing as an RA81 "without... MSCP
controller".
The SIMH MSCP emulation is not doing the spare sector
correctly; it is not including the spare sectors on the RA81 disk image.
It operates correctly because SIMH emulates the program point of view, so it exposes the
user LBA space, not the internal structure. For the same reason, it doesn't emulate
sector headers, ECC codes, or servo fields. None of that is visible to the software.
paul