PDP-11 disk image question

Jerry Weiss jsw at ieee.org
Wed Feb 20 15:07:43 CST 2019

On 2/20/19 1:25 PM, Glen Slick via cctalk wrote:
> On Mon, Feb 18, 2019 at 2:24 PM Bill Gunshannon via cctalk
> <cctalk at classiccmp.org> wrote:
>> Theoretically, the SIMH emulated RA81 and the CMD emulated real
>> disk RA81 should be the same size because they are both supposed
>> to be RA81's.
> I spent the time to get set up and verified that this assumption is
> not correct. The CMD CQD MSCP SCSI controller firmware RA device type
> feature appears to only change the reported MSCP media name string,
> and has no effect on the reported MSCP size and geometry information.
> I tried this on a CMD CQD-420/TM with firmware version (REV. B2L-00).
> As far as I know the CQD-420 and the CQD-220A (but not the original
> CQD-220) are almost identical. I used an IBM DDRS-39130D hard drive
> with a 68-pin / 50-pin adapter. The DDRS-39130D is a native 9GB drive.
> I used sg3-utils / sg_format to soft resize the drive to exactly 2GB
> in capacity, 2,147,483,648 bytes, 4,194,304 blocks.
> ......
Paul K's explanation and Glen's example matches my own experience in 
this area. I don't have a CMD controller, but I move images between SIMH 
and both Emulex UC07 and Dilog SQ706A MSCP/SCSI Controllers. I've used 
RT11, XXDP, RSX11M+ and VAX VMS on both physical hard drives and SCSI2SD 
emulated disks.

The physical SCSI drives I use have SCSI reassign capability. This 
allows the controller/drive to manage media defects.  This is 
transparent to any of the OS'es. The controller presents the disk simply 
as a continuous logical disk of disk blocks and the geometry has no 
effect.    Space reserved for bad block replacement is not visible to 
the OS.

I make sure the number of logical blocks is maintained exactly as I move 
the images back and forth between SIMH and physical Machines. The disk 
type RA90, RA81, etc never makes a difference.  The MSCP controllers 
read the media size directly and report the disk logical capacity to VMS 

If I move an VMS ODS-2 SIMH disk image to a larger SCSI disk drive then 
problems will occur.  For ODS type volumes, my understanding is that 
bitmap.sys file won't have room to manage the extra space.   I also try 
to avoid edge cases for disk sizing that involve powers of two - e.g. 
2**32.   In my general experience, I have found boundary check problems 
in different situations (especially non-Digital).

Disk NASTY$DKA100:, device type DEC RA92, is online, mounted, file-oriented
     device, shareable, error logging is enabled.

     Error count                    0    Operations 
completed               2653
     Owner process                 ""    Owner UIC                      
     Owner process ID        00000000    Dev Prot S:RWPL,O:RWPL,G:R,W
     Reference count               48    Default buffer 
size                 512
     Total blocks             7603200    Sectors per 
track                    63
     Total cylinders              474    Tracks per 
cylinder                 255

     Volume label          "VAXVMS73"    Relative volume 
number                0
     Cluster size                   9    Transaction 
count                   155
     Free blocks              3072564    Maximum files 
allowed            419336
     Extend quantity                5    Mount 
count                           1
     Mount status              System    Cache name "_NASTY$DKA100:XQPCACHE"
     Extent cache size             64    Maximum blocks in extent 
cache   307256
     File ID cache size            64    Blocks currently in extent 
cache 307161
     Quota cache size               0    Maximum buffers in FCP 
cache        557
     Volume owner UIC        [SYSTEM]    Vol Prot 

   Volume Status:  ODS-2, subject to mount verification, protected 
       enabled, file high-water marking, write-through caching enabled.

I don't see a discrepancy on SCSI2SD V5 cards between configuration size 
and VMS reported block,  The size used is recorded on the SCSI2SD V5 
card.  The SCSI2SD V6 adapters store the drive configuration on the last 
block of the microSD and I believe reported capacity is reduced by 1.   
Perhaps the CMD is doing similar to allow the media to be interchanged 
between controllers.


More information about the cctalk mailing list