PDP-11 disk image question

[Paul Koning]

> 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:
> 
>> On Wed, Feb 20, 2019 at 8:57 AM Charles Anthony via cctalk
>> <cctalk at 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