> On Feb 20, 2019, at 1:43 PM, Charles Anthony via cctalk
> <cctalk@classiccmp.org> wrote:
>
> On Wed, Feb 20, 2019 at 9:21 AM Glen Slick via cctalk <cctalk@classiccmp.org>
> wrote:
>
>> On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk
>> <cctalk@classiccmp.org> wrote:
>>>
>>> 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.
>>
>
>
> 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.
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.
> 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
